Leading Indicators and Lagging Indicators in Project Management

For the first time, in the PMBOK® Guide 7th edition, both leading and lagging indicators are introduced as Key Performance Indicators (KPI) for a project. Such indicators are applicable in all aspects of management – project, program, portfolio or risk management. It’s also applicable in Agile management.

Let’s understand them in simplest possible terms. The content of this article has been taken from RMP Live Lessons – Guaranteed Pass.

Indicators

I’ll define an indicator as follows:

“An indicator is something (a result, an event, a statistic) that indicates or signals.”

For example, if you are finding a number of bugs in your team’s deliverables, it indicates a quality problem. Based on it, you can take some actions such as having a more robust definition of done (DoD). 

Taking another example related to our personal lives, if you see a cloudy sky, it indicates that rain may happen next. Based on it, you may choose to take some actions such as taking an umbrella or searching for your raincoat.

The first result (high number of bugs) is a lagging indicator. This is because you came to know about it after the bugs occurred. But the second one is a leading indicator for rain. Because before the event occurred (rain), you came to the possibility of the event happening. 

Now that I’ve introduced two more terms – leading and lagging indicators – let’s understand them in detail. 

Leading Indicators

I’ll slightly change the definition provided by the Project Management Institute (PMI®) and will define it as:

“A leading indicator is a measurable data that helps to anticipate (predict) changes or trends in a project.”

Simply put, a leading indicator is about the future or it indicates the future. 

Some of the examples in management can be the followings:

• Lack of a risk management processes
• Stakeholders who are not available or engaged
• Poorly defined project success criteria
• Size of the project (quantifiable)
• Complexity of the project
• Number of items in progress after taken from the Backlog (quantifiable)

Considering the last example of too many in-progress items indicate a bottleneck in flow of work, or too complex work being taken-up. 

Lagging Indicators

Here too, PMI provides a good definition, but I'll modify a little:

“A lagging indicator is a measurable data that measures deliverables or events in a project.”

Simply put, a lagging indicator is about the past or it gives information about the past. 

Examples of lagging indicators can be:

• Number of deliverables completed (quantifiable)
• Schedule variance (quantifiable)
• Cost variance (quantifiable)
• Amount of resources consumed (quantifiable)

Taking the first example, one can say that if you are completing a good number of deliverables, then the project is progressing well. 

Next, I’m going to relate leading and lagging indicators with preventive and corrective actions, which you have to know as an aspiring PMP, PgMP, or RMP. 

Leading Indicators and Preventive Actions

As defined by PMI:

A preventive action is an intentional activity that ensures the future performance of the project work is aligned with the project management plan. 

For projects in an Agile environment, it'll be your product backlog with the product goal. In other words, the actions should be aligned with the product goal (or release goal or Sprint goal). 

Leading indicators can lead to preventive actions. With it, before the event or condition happens, you can take actions. For example, considering our second example of rain, before the rain event happens, you can take actions such as taking an umbrella.

Lagging Indicators and Corrective Actions

As per PMI: 

A corrective action is an intentional activity that realigns the performance of the project work with the project management plan. 

For projects executed with Agile frameworks, you will be taking actions that realigns with the product goal, release goal or Sprint goal.

Lagging indicators can result in corrective actions. For example, schedule variance is a lagging indicator. If very high variance, you can take actions with techniques such as fast tracking or crashing to improve. 

Comparison – Leading and Lagging Indicators

The comparision with both the differences and commanalities between leading and lagging indicators are shown in the table below.

Both these indicators are part of the Measurement Performance Domain (PD) of the PMBOK Guide, 7th edition. Because these indicators are primarily about measurement. The PMBOK guide prudently notes and I quote verbatim:

“In and of themselves, KPIs are simply measures that have no real use unless and until they are used. Discussing leading and lagging indicators and identifying areas for improvement, as appropriate, can have a positive impact on performance.” 

Indeed, measurements should be used. In my view, as a management professional and leader, you should measure (and use) both leading and lagging indicators. In fact, I'd say it's a best practice to use both in your projects.

References

[1] Project Management Body of Knowledge (PMBOK) Guide, 7th edition, by Project Management Institute

[2] RMP Live Lessons - Guaranteed Pass or Your Money Back, by Satya Narayan Dash 

[3] Article - PMBOK 7th Edition: Principles, Performance Domains and Artifacts – How Do They Plug and Play Together? (Part - 1)

[4] Article - PMBOK 7th Edition: Principles, Performance Domains and Artifacts – How Do They Plug and Play Together? (Part - 2)

PMBOK 7th Edition: Principles, Performance Domains and Artifacts – How Do They Plug and Play Together? (Part - 2)

I'd strongly recommend that you go through the first part of this series on PMBOK's principles (PR) and performanc domains (PD) before proceeding with this one. This part is about artifacts and interactions among the PRs, PDs and Artifacts. 

This series: Part - 1

--

PMBOK7 Artifacts *** UPDATED ***

The way to connect the dots and understand this article is also to know the artifacts. An artifact can be an output, a project document, or even a project deliverable.

Considering risk and uncertainty, we mainly have three artifacts:

• Project Risk Management Plan: How to identify, assess, respond, manage, and monitor the risks in a project.
• Project Risk Register: List of identified risks in a project, also known as the Risk Log.
• Project Risk Report: Summary of individual and overall project risks.  

Similarly, when considering other aspects such as Delivery PD, Project Work PD, or Measurement PD, there can be a number of artifacts.

How Do They All Plug and Play Together? *** UPDATED ***

So far, we learned about the PRs, PDs, and artifacts. The final part of the PMBOK7 puzzle is to understand how all these work in unison. This is how.

• For every project, while all principles are present, a few principles will be predominantly applied.
• The degree of application of the principles and the way they are applied can vary. It can be based on organizational context, deliverables, project team, stakeholders, etc.
• Performance domains are also present in every project, but then again, we don’t focus on all aspects of the PDs throughout the lifecycle of the project.
• The way PDs relate and apply differ for each project.
• Principles chosen for a project guide the behavior of the project team and project stakeholders, whereas performance domains chosen for the project are areas to demonstrate that behavior.
• PRs influence and shape the PDs to achieve desired outcomes
• The artifacts are used, applied, and can also come from the PDs. 
• Models and methods are also applied on the project to achieve desired outcomes. 

An Example – Risk PR, Uncertainty PD and Artifacts

To understand better, let’s combine the Risk PR, Uncertainty PD, and the associated artifacts. I’ll also inform you of the models and methods involved in this interaction, shown in the figure below. 

Let’s interpret the above figure:

• Principles guide the behavior of the people involved in the project. For example, the Risk Principle guides what to do with the uncertainties and risks in the project.
• Domains are broad areas of focus to demonstrate that behavior. For example, the Uncertainty PD is a broad area of focus to demonstrate how risk responses are optimized.
• The Models are applied on the PDs. For example, considering Uncertainty PD, Stacey’s diagram (a complexity model) can be applied. Another complexity model applied is the Cynefin framework.
• The Methods are also applied to the PDs. For example, the probability and impact matrix is a method that can be applied to the Uncertainty PD.
• The deliverables and artifacts are from the PDs. For example, the risk register and risk report are artifacts from the Uncertainty PD.

That’s it! Was it difficult to understand?

If you have read sincerely and understood so far, you have absorbed the very essence of the new PMBOK Guide.

Video – Key Notes on PMBOK7 *** NEW ***

Now, it’s time to note and recap certain key points with respect to the PMBOK7 principles, domains and artifacts. I’ve prepared this below video [duration: 04m:11s] for your understanding. Reference for this video has been taken from my RMP Live Lessons course.

Guidance for PMP and RMP Exams 

The most common questions I receive in my regular interactions with management practitioners are with respect to the RMP and PMP exams. PMBOK, 7th edition has taken a paradigm shift compared to the PMBOK, 6th and the practitioners want to know their usages and needs in the new versions of the PMP exam.

Is PMBOK7 needed for the RMP Exam?

The short answer is yes.

Elaborating further, one of the RMP exam’s explicit reference sources is the new edition of the PMBOK 7th edition, which has a principle-based standard. This is well-complemented with the PMBOK 6th edition, which is a process-based standard. For your RMP exam, you must refer to both, because the main source of the exam is the Foundational Standard for Risk Management in Portfolios, Programs, and Projects, which follows a process-based approach with a set of risk management principles.

Is PMBOK7 needed for the PMP Exam?

The short answer is no.

You’ve probably seen many sites, portals, and exam preparatory courses inform on the PMBOK Guide, 7th edition as a must-read. In reality, at the time this article is written, it’s a should- or could-read. Nevertheless, knowing the latest management principles, practices, and artifacts is a good idea. Recent PMP and RMP success stories in 2023 from my management sessions confirm that.

Conclusion *** UPDATED ***

To wrap up this article, principles by their very nature are self-evident, true, and real. For example, the principle of “Demonstrate leadership behaviors” applies not only to the project manager but also to every team member.

Principles will light up the path for your practices. Why so? Because a project is almost always executed in an uncertain environment. In other words, your path will be uncertain and sometimes dark and you won’t know how to proceed. Principles act like rays of light guiding your path in an uncertain project terrain. While principles are guidelines, practices are real-world usages. These practices are performed with activities and functions in the performance domains that we have reviewed here.

I hope you now have a big picture as well as a zoomed-in view of the PRs, PDs, artifacts, and how they all fit together. As always, your thoughts, views, and comments are welcome. Please share them in the comment section below.

This series is concluded.

This series: Part - 1

—

This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away four years ago on June 11, 2019. It’s a tribute to him, my mother, and their teachings.

Thank you, dear readers, for reading this piece. And, wish you a very happy new year, 2024.

--

This article was first published by MPUG on June 13, 2023. This an updated and refined version. 

References

[1] RMP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] RMP 30/40 Contact Hours with Money Back Guarantee, by Satya Narayan Dash

[3] I Want To Be A RMP: The Plain and Simple Way To Be A RMP, Second edition, by Satya Narayan Dash 

[4] Project Management Body of Knowledge (PMBOK) Guide, 7th Edition, by Project Management Institute (PMI)

PMBOK 7th Edition: Principles, Performance Domains and Artifacts – How Do They Plug and Play Together? (Part - 1)

Over a decade and a half ago my father and mother visited me in a different city, nearly a thousand miles away from home. Being very young, with few years of work experience, I was struggling to cope with the work pressure, compounded by no family or family friends in a new city with a totally different culture, language, food, and even clothing. My father was very concerned and tried to help in as many ways as he could. He even brought breakfast for me. One day, in jest, I told him that I’ll follow a set of principles to make my work and schedule better. A stern and tough father from the outside, but soft inside, he smiled and said: “Can you follow just a few? Try it. It’s hard!”

But why is following a set of principles so hard? As I’ve seen, in project-program-portfolio management, the primary reason is the constraints. For a project, it’s usually the scope, time, and cost, whereas for the programs it’s the delivery of benefits, and for the portfolio, it’s about the value and value optimization, capacity, and capability.  

In addition, saying is always easier than doing. Having principles written in a notebook or project board is always easier than following them. Talking about results from principles is far easier than actually delivering the results!

In this article, however, we will not only learn the principles (PR), performance domains (PD), and associated artifacts, we will also see several examples and applications. Towards the end, I’ll demonstrate how all these fit together. 

This series: Part - 2

PMBOK7 Principles (PR) *** UPDATED ***

A principle is a fundamental norm or truth. Now, before getting into the project management principles (PR) informed in the Project Management Body of Knowledge (PMBOK®) Guide, 7th edition, let’s understand certain top points on these principles of project management.

1. Principles are not prescriptive in nature, unlike the principles in a profession. They are not laws of project management. They are intended to guide the behavior of the team members and stakeholders.
2. Principles of project management serve as guidelines for decision-making and problem-solving in a project.
3. Principles can but don’t necessarily reflect morals. Values defined in PMI®’s Code of Ethics reflect morals. The values of PMI are responsibility, respect, fairness, and honesty.
4. In total, there are four values and 12 principles. The 12 principles are aligned with the four values and complement them, like the principles and values of Agile Manifesto.
5. Principles are internally consistent, meaning that no principles contradict other principles. However, in practice, principles can overlap.

The twelve project management principles (PR) are noted in the below table. Each principle has a principle statement, a principle label, or principle tag(s). I’ve outlined only a simplified part of the principle statement in the table. 

As shown in the above table, there are 12 PRs with principle labels and simplified PR statements. There is also a complete PR statement. For example:

• Complete Principle Statement: Continually evaluate exposure to risk, both opportunities and threats, to maximize positive impacts and minimize negative impacts on the project and its outcomes.
• Simplified Principle Statement: Optimize risk responses.
  It’s the tenth PR in the above table.
• Principle Label/Tag: Risk.

If you are preparing for your Risk Management Professional (PMI-RMP)® or Project Management Professional (PMP)® examinations, you have to remember all the principles, labels and understand the principle statements. Indeed, for latest RMP exam from 2022, the PMBOK 7th edition has been explicitly listed as a reference.

PMBOK7 Performance Domains (PD) *** UPDATED ***

Next, let’s understand the performance domains (PD). PMI defines a PD as follows:

A group of related activities that are critical for the effective delivery of project outcomes.

Simply put, it’s a group of related activities. The top points about the performance domain are the following:

• The PDs are interactive in nature, i.e., all the PDs interact or talk to each other.
• The PDs are interrelated. Not a single PD stands on its own.
• PDs are interdependent. Notice that the word, it’s not dependent on each other or even a better form, i.e., independent of each other, but interdependent, which is the highest form of dependency!
• PDs have outcome-focused measures, not output focused. When we talk of output, it’s usually the end product or service, whereas when we speak of outcome, it’s what one can do with that product or service. 
• PDs overlap and interconnect with each other.
• PDs are present in every project, but the way in which they relate and interact may differ.
• PDs run concurrently in every project – single, multi-phased, or the way value is delivered.

Do note that although the definition of PD refers to a group of interrelated activities, the specific activities to be considered in each PD are determined by organizational context, project, deliverables, project team, and stakeholders, among others.

There are eight performance domains which are outlined in the below table. I’ve simplified the descriptions so they are easier to understand and remember.

As noted earlier, all eight PDs interact with each other, which is depicted in the below figure.

Specifically considering the Uncertainty PD, which is associated with Risk Management, the following figure can be inferred.

As shown, the Uncertainty PD works in collaboration with all other PDs. For example, considering Uncertainty and Measurement PDs, one can have a risk reserve burndown chart, which shows the amount of contingency reserve available compared to the amount of risk remaining in the project. It’s a variant of burndown charts and can be presented in the Dashboard.  

Principles and Performance Domains

Now you may be wondering how the PRs and PDs work together? This concept is very foundational to know as a project, program, portfolio, agile, or risk management practitioner.

The most important aspect of PR and PD synergy is this:

Principles guide the behavior of the people involved in the project. Performance domains, or simply domains, are broad areas of focus to demonstrate that behavior.

This is shown in the below figure.

Let’s take the example of Risk principle (PR – 10) and Uncertainty domain (PD – 8) to understand the above aspect.

The Risk PR guides the behavior of the people involved in the project and advises them to maximize opportunities, minimize threats to the project and optimize risk responses. Among others, the Risk principle also tells us to address risk continually, understand risk parameters such as risk attitude, risk appetite, and risk threshold, and subsequently manage and monitor risks in a project.

However, the Uncertainty PD is the broad area of focus to demonstrate what one learned with the Risk PR. Questions such as:

• How to maximize opportunities?
• How to minimize threats?
• How to plan and optimize the risk responses?
• Should one consider one risk or multiple risks?
• Should one consider individual risks, overall project risks, or both?

These questions are answered through demonstration in the Uncertainty PD. In addition, there are other areas such as volatility, ambiguity, and complexity (from the VUCA acronym) in the Uncertainty PD. Therefore, this PD becomes a “broad area of focus” to apply to the Risk PR.

This series: Part - 2

References

[1] RMP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] RMP 30/40 Contact Hours with Money Back Guarantee, by Satya Narayan Dash

[3] I Want To Be A RMP: The Plain and Simple Way To Be A RMP, Second edition, by Satya Narayan Dash 

[4] Project Management Body of Knowledge (PMBOK) Guide, 7th Edition, by Project Management Institute (PMI)

PMBOK Guide 7th Edition Standard: Principle Application Vs Delivery Capability

Recently, I spoke on the changes happening for the PMBOK® Guide, 7th Edition – Standard, in a webinar conducted globally. (link)

After this session, I had this question offline. 

“Should all the principles be followed for effective delivery? Is there a correlation?”

This question set me thinking about the usage of principles across the delivery spectrum. The standard is currently in draft stage and the principles are outlined there, though it may change. 

Question’s First Part
However, I’m not focused about the number of finalized principles in this post as that will be determined by the team preparing the standard and suggestions, comments from management practitioners. Rather, I’ll be outlining the application of these principles as the first part of the above question goes.

Should all the principles be followed? 

All the principles need not be applied to the same extent in every project delivery, i.e., the degree of application for the principles can vary. 

As per the standard draft, the degree of application of the principles will be influenced by:

• Organizational context,
• Project undertaken,
• Deliverables to be given,
• The team working on the project,
• Stakeholders involved in the project,
• Environmental conditions involved. 

Question’s Second Part
The next part of the question raised was: 

Is there is there a correlation between the principles applied and the ability to deliver? 

This is not mentioned in the standard part of the PMBOK Guide, 7th edition. But, it’s a very interesting question. If you read deeply and look closely at the standard, the degree of application of the principles and project delivery are actually interrelated. 

An Example:
Let’s say a small, simple, organic organization is delivering project to its clients. This organization has few employees – 10 to 15 in number, and the owner of the organization is the manager or leader of the project.

• Do you think this organization will want to apply all the principles completely? 
• Do you think this organization will train the resources on the applicability of the principles?
• What will be the actual value received by principles such as tailoring, assuming that the organization uses very small number of processes? (remember: it’s a small organization) 

You can add other questions in this regard as well. 

However, there will be certain principles which will be of high importance to such organizations. For example, principles such as “Focus on Value” will be of high importance to this organization, other principles such as “Tailor the approach” may not be equally important – and sometimes may have very little usage! 


Four-Quadrant Classification:
Hence, the second part of the question leads to a four-quadrant classification considering two aspects:

• Degree of application of principles (in one axis)
• Delivery capability (in another axis)  

This brings four areas for the organization concerned and they can fall into one of these categories. 

• Low application of Principles, Low Delivery capability (LP, LD)

• Low application of Principles, High Delivery capability (LP, HD)

• High application of Principles, Low Delivery capability (HP, LD)

• High application of Principles, High Delivery capability (HP, HD)

I’ve simplified the shortened versions and in the four classifications shown above:

• P – stands for "degree of principles' application", D – stands for "delivery capability"

This is represented in the below figure. Do note that it's my interpretation and visualization. 

© Satya Narayan Dash. All Rights Reserved.

If you look at the above figure, you can see it’s based on the degree of application and delivery capability, and we have various types of organizations. 

Let’s understand this four-quadrant classification. 

• LP, LD (bott0m-left quadrant): These organizations are small, simple/organic. These organizations don’t have a need to apply all the principles fully, and simultaneously their delivery capabilities will also be low. 

• LP, HD (top-left quadrant): These are mostly start-up organizations, where survival matters a lot, for which they have to deliver frequently – anyway possible and quickly. These organizations, however, don’t apply all the principles to a very high degree.

• HP, LD (bottom-right quadrant): In this case the delivery capability is not of high importance, but it’s important to know the degree of application of principles in a variety of situations or scenarios. In my view, high-end consulting organizations will fall under this category. 

• HP, HD (top-right quadrant): If organizations apply principles to a high degree and also have high delivery capability, I’ll consider them to be matured organizations. By matured, I don’t mean these will be large scale organizations, but they have the ability to deliver in various approaches – be it iterative, traditional, agile, hybrid or any other. These organizations also apply the principles to a high degree. 

This is the first impression I’ve while comparing the degree of application for the principles and the delivery capabilities. As the PMBOK Guide 7th edition comes with more clarity, I may update this figure.

And I welcome your views and thoughts.

References:

[1] Webinar - PMI PMBOK Guide 7th Edition Standard – What’s New? by Satya Narayan Dash, Conducted by Microsoft Project User Group (MPUG)

[2] The Standard for Project Management Exposure Draft for PMBOK Guide 7th Edition, by Project Management Institute (PMI)