Planning Performance Domain: How to Plan a Solution to Meet Your Goals

‘Prior Planning and Preparation Prevents P*** Poor Performance’. I believe that’s a common saying in the British Army and, doubtless, many other places. The purpose of planning is to figure out how to achieve what you want to achieve. As a result, planning is a key element of Project Management. So, the Planning Performance Domain of the 7^th Edition of the PMI’s Guide to the Project Management Body of Knowledge (PMBOK Guide) must be central. 

The content is vitally important to us, as project managers. Therefore, we must set the standard high. So, what does the Planning Performance Domain section of PMBOK 7 contain? And, how well does it meet my standards?

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

What is the Planning Domain?

The Planning Domain of Project Management contains all the knowledge necessary to create and maintain a plan for the successful delivery of a project. And the challenge is that it needs to address both:

1. Highly planned, predictive projects, and
2. Highly adaptive, agile projects

And, of course, it also needs to accommodate everything in between. Because, after all, ‘all project management is agile project management.’

This, and the centrality of planning to the discipline of project management, places a large burden on any articulation of such a wide and consequential endeavor as articulating the whole ‘planning domain’. How will the PMI’s first attempt, in PMBOK 7, match up to the task?

The PMBOK Definition of the Planning Performance Domain

My first impression is that the authors of PMBOK 7 have adopted a rather odd definition of this performance domain. It’s not that it’s wrong. I just feel it’s:

• Quirky in its emphasis
• Wordy in its execution, and
• Downright hard to read

What do you think?

‘The Planning Performance Domain addresses activities and functions associated with the initial, ongoing, and evolving organization and coordination necessary for delivering project deliverables and outcomes.’

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

This strays from a more common definition of what planning is, in its emphasis. It defines planning in terms of organization and coordination. However, this emphasis is very much consistent with the mission I infer that the PMBOK 7 authors set themselves. That is, to work at a high level of principles and abstraction. 

To me, that is laudable. I like ideas. It falls down because the PMBOK Guide needs, fundamentally, to serve:

• Practitioners, who want to get stuff done
• Learners, who want to understand the fundamentals

I should also say, however, that I do like the use of the word ‘evolving’ to remind us that plans are never set in stone.

Our Proposed Definition of the Planning Performance Domain

I would define planning in this way:

‘Planning: creating a method or process to achieve your goals.’

Indeed, in my guide to Project Management terminology, ‘Be on the Inside: Decode the Jargon of Project Management’, I define:

‘Plans: Plans set out how you intend to deliver your project.  They address the three project elements: tasks, time, and resources, and describe what needs to be done, how it will be done, when, by whom, with what assets and materials, and how it will be paid for.’

Be on the Inside: Decode the Jargon of Project Management, 2^nd edition
Mike Clayton, 2017

From these, I suggest the following revised definition of the Planning Performance Domain:

‘The Planning Performance Domain contains the knowledge to create and maintain the methods and processes to deliver your project.’

The Expected Outcomes for the Planning 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. The project progresses in an organized, coordinated, and deliberate manner.
2. There is a holistic approach to delivering the project outcomes.
3. Evolving information is elaborated to produce the deliverables and outcomes for which the project was undertaken.
4. Time spent planning is appropriate to the situation.
5. Planning information is sufficient to manage stakeholder expectations.
6. There is a process for the adaptation of plans throughout the project based on emerging and changing needs or conditions.

Let’s take a look at these in turn.

An Organized, Coordinated, and Deliberate Manner 

I like this statement and yet… I have two concerns. 

1. I know this is a valuable outcome, but cannot help feeling it lies there, unjustified. I’d prefer if PMI had led with the sentiment that good planning increases the chances of project success.
2. This feels like a poke at Agile Purists who can sometimes argue against any planning at all. In this sense, I support the statement, but some will argue that a well-structured Agile process with minimal planning can also deliver a project that progresses in an organized, coordinated, and deliberate manner.

Holistic Approach

Here is another ‘motherhood and apple pie’ statement that everyone will see as a self-evident good. Don’t we want everything to be holistic? Come on, PMI… Take the trouble to articulate why this matters, and to justify that it does.

Evolving Information

There is nothing wrong with the sentiment here. Indeed, above, I picked out the word ‘evolving’ as a real strength of the PMBOK 7 definition of the Planning Domain. However, this feels like an overcomplicated way of saying we use new information to update and improve our plans.

Time Spent on Planning

This outcome speaks to tailoring and, as stated here, is exactly right. How could it not be? But, we’ll see later that PMBOK 7 does not take an even-handed approach in defining ‘appropriate’.

Meeting Stakeholder Expectations

Absolutely. Here is a video in which I define the key deliverable of your project plan as… confidence.

What I would have liked is for the authors, who seem to have had this in mind, to be more explicit about it.

Adaptation Process

There’s nothing much to add to this one, except that it will lead us to:

• Change Control for the substance of changes to your plans
• Version Control for tracking the changed documents
• Configuration Management for tracking changes to your products

Except, PMBOK 7 is extremely weak on change control and neither version control nor configuration management get a mention in the index!

So, what is missing?

I think there are two big things that are either missing or buried from the PMBOK 7 outcomes from the planning performance domain:

1. The Missing: Probability of Success
   I would like to see PMI be bolder. I would lead with a clear statement that good planning increases the probability of project success. That success is the outcome of effective execution of the planning performance domain.
2. The Buried: Confidence
   Planning outputs do need to help us to manage stakeholder expectations. But, I would go further. The single most important product of the planning process is confidence. Confidence among the stakeholders and confidence within your team.

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

An Organized, Coordinated, and Deliberate Manner 

The check on this is the project’s performance against planning metrics. This endorses my feeling that this is (or should be) explicitly about performance, rather than the proxy of ‘organized, coordinated, and deliberate’.

Holistic Approach

This refers to ensuring that all aspects of your plan (schedule, budget, resourcing, procurement) are properly coordinated to avoid gaps, overlaps and duplications*, or misalignments. Here, the check offers us clarity of the value of a holistic approach.

* I added ‘overlaps and duplications’, which PMBOK 7 omits.

Evolving Information

Here, PMBOK 7 adopts a wordy way of saying (I think) that the current state of your plans needs to maintain confidence that you will deliver value. Frankly, this section seems to me to be a bit of a mess.

Time Spent on Planning

This one however is stated simply… but somewhat tautologically. We find that appropriate time was spent if the level of our plans is appropriate. 

Meeting Stakeholder Expectations

This check shifts the focus to your stakeholder communications and therefore puts the burden on your stakeholder communications plan. This is a more restricted check than I would like. And is also alarming given the paucity of content in the main section, about your communications plan, as I will describe below.

Adaptation Process

This, appropriately, refers to the use of backlogs for adaptive projects and change control for more predictive ones. But continues to omit reference to version control and configuration management.

Important Definitions within the Planning Performance Domain

In the introduction to the Planning Performance Domain, PMBOK 7 highlights (in a box), six definitions of jargon terms:

• Three about Estimating:
  Estimate, Accuracy, and Precision I will consider these below. These are good definitions, in my view.
• Two about Schedule compression:
  Crashing and Fast Tracking. Again, I’ll consider them below. These are poor er definitions that PMBOK 7 offers in its main discussion of these terms. They are, in my view, overly abbreviated.
• And Budget, which is a good definition

What I question here is which definitions the PMI has chosen. There are so many jargon terms in the world of planning, what were the selection criteria.

For example:

• Does the box need to define precision and accuracy? They are both important fundamental concepts, but the main text describes them very well. Likewise crashing and fast-tracking.
• On the other hand, where is a definition of baseline or dependency – equally or, arguably, more fundamental concepts? The latter is described in the main section; the former is not.
• Why is budget defined, but not schedule?

I believe when I cite quotes from PMBOK 7, I am doing so as fair use for educational purposes. But I also suspect that sharing all six of the definitions here would put me at risk of stretching that principle in this case.

So, here instead, are some definitions from my own ‘Be on the Inside: Decode the Jargon of Project Management’:

‘Estimate: An informed quantitative prediction of an element of your project such as time, effort, resource requirement, or cost.’

‘Crashing: Making compromises to advance work ahead of schedule, or to catch up a significant delay.’

‘Fast-tracking: Working on tasks in parallel to reduce the time needed to deliver a project.’

‘Budget: A financial statement of the estimated costs for completing all or a part of the project. By analogy it is also possible to create resource and time budgets.’

‘Schedule: The time component of your project plan, showing when activities are due to start and finish.’

‘Baseline Plan: A formally committed plan that has been signed off. It is used as the basis for monitoring progress and the success of your project.’

‘Dependency: Some tasks can get done at any time and are independent of other activities.  Others are linked to events like the start or completion of other tasks. These linkages are called dependencies.’

Be on the Inside: Decode the Jargon of Project Management, 2^nd edition
Mike Clayton, 2017

Basic Principles of the Planning Domain

PMBOK 7 sets out the purpose of planning nicely – and implies a better definition than it gives formally. It is to ‘develop an approach to create the project deliverables’ It goes on to remind us of the link between deliverables and outcomes. 

Triple Bottom Line

There is an interesting box that suggests that financial benefits may not be all we are interested in and that we may be motivated by ‘the triple bottom line’ of Profit, People, and Planet. PMI describes these as financial, social, and environmental impacts. I discuss this in my book on stakeholder engagement, The Influence Agenda.

Appropriate Amount of Time Spent Planning

Who can argue that we should spend the appropriate amount of time on planning? The question is: ‘how much time is appropriate?’

PMBOK 7 seems to argue solely against spending too much time. The nub of its argument is the sentence: ‘It is inefficient to spend more time planning than is needed.’ That is, self-evidently, true.

But is also true that rushed planning, with the hope that moving as quickly as possible to delivery can result in confusion, mistakes, and the need for rework.

PMI: if you are going to state the obvious, you need to do more work to properly set some parameters around the wooly word ‘appropriate’.

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

PMBOK 7 gives us eight sections describing the components of the Planning Performance Domain. The overview at the start, and the interactions section and checking table at the end add three subsections to make up the full 11.

The first of the eight is:

Planning Variables 

This is a good section that accounts for more content than the rest of the chapter put together. It seems that this is what the authors think planning is really about. 

It has a good introduction on tailoring your planning to your:

• Development approach
• Project and the deliverables it needs to create
• Organization and its governance and cultural requirements
• Market and the pressures the competitive environment imposes
• Legal and regulatory frameworks

There are then 4 parts that cover:

1. The link between planning and delivery
   This discusses scope (in the broadest of outlines) and how the choice of predictive or adaptive delivery drives your high-level planning approach. This section misses the importance of milestone planning for tightly time-driven projects.
2. Estimating
   An excellent account of the basic principles of estimating, which is the best part of this whole domain. If only it drew the link to section 4.4.2 of the Models, Methods, and Artifacts chapter of PMBOK 7, which lists a range of estimating methods.
3. Schedules
   There is a decent description of the scheduling process and good descriptions of key terms like: lags and leads, crashing and fast-tracking, and different types of dependency, including types of task dependencies and external dependencies. Curiously, there is no mention of baselines at all.
4. Budget
   This is the weakest of the four and I find it rather lacking.

Learn More about these Processes

Here are our articles on these topics:

• Project Planning Process: Navigate the Many Steps You Need
• Project Planning Process – How to Build Effective Project Plans | Video
• 12 Project Planning Mistakes… and How to Fix Them
• Capabilities Based Planning: A Primer
• Project Estimation: Master the Art and Craft
• Make Your Project Estimation More Reliable, Using the PERT Method
• How to Estimate Project Costs | Video
• Project Scheduling: Your Essential Guide
• 3 Ways to Produce Your Next Project Budget
• How to Anticipate Future Budget Challenges to Your Project | Video
• Pressure to Reduce Your Project Budget | Video

The Next Six Sections

The next five sections all cover important components of a good plan. Yet they all do so in a way that is consistently weak, with little more than an introduction to the topic, with an average of two paragraphs each.

However, we have a comprehensive article on each.

• Project Team Composition and Structure
  We have many resources on teams, but the most relevant article for this section is: Complete Primer on the 6 Themes of Project Human Resource Management
• Communication
  Again, we have a huge amount of content on different aspects of project communications, but start with: How to Get Project Communications Management Right… Every Time
• Physical Resources
  Project Resource Management: Part 1 of Your Comprehensive Guide
• Procurement
  Project Procurement Management [All the basics you need to know]
• Changes
  Project Change Control: What You Need to Know to Make it Effective

Hang on a Minute Mike…

Hold on, I hear you say… Aren’t Team Focus, Communication, Physical Resources, and Procurement covered in the next Performance Domain, Project Work?

Well, yes they are. But, with the exception of Procurement, they receive no more love there than they do here. Get ready for some familiar critiques in the next of these articles!

The Final Two Sections

The last three main sections tackle three aspects of what makes a good plan:

1. Metrics
   Describes the importance of metrics in assessing performance. And has a throwaway reference to baselines. This ends with the obvious link to the Measurement Performance Domain.
2. Alignment
   Describes the need to integrate activities and artifacts throughout the project and with other projects in any program or portfolio. Is this stating the obvious or a helpful reminder and prompt? I think the latter, because it reminds us of the absence of any other mention of Project Integration, which was one of the 10 Knowledge Areas of previous PMBOK Gide editions.

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

In this case, I find it difficult. If all the content were of the quality of section 2.4.2, Planning Variables, I’d definitely award the Performance Domain a ‘Good’. But it most certainly is not.

Indeed, most of the rest of the main sections are ‘Poor’ at best and maybe even ‘Lacking’. Here is an example where I wonder what the best form of average is. If I choose a mean and weight by content, I get to ‘Okay’. But, if I average by taking the mode or even the mean, weighted number of sections, I would struggle between Lacking and Poor.

So, I am going with my gut. All of my ratings are subjective, but this one feels more so than others. I am going to score the PMBOK 7 Planning Performance Domain a skinny 2. I rate this performance domain as Poor – ‘a lot of work needed’.

Strengths of The PMBOK 7 Planning Domain

Without a doubt, the subsections on estimating and scheduling, along with the introduction to the Planning variables section are good, closing in on excellent. 

But I cannot find much else to like about this domain. The problem is that it is a huge topic, which encompasses six or maybe 7 of the 10 Knowledge Areas of earlier PMBOK Guides:

1. Integration Management
2. Schedule Management
3. Cost Management
4. Resource Management
5. Communications Management
6. Procurement Management 
7. (Scope Management is mostly covered in the Delivery Domain)

Yet the authors allocate similar numbers of pages to the other seven performance domains. They didn’t have a chance.

Weaknesses of The PMBOK 7 Planning Domain

Of course, the outcome of this observation is that every other section is weak. So, I shan’t harp on that chord. I will also avoid repeating some of the smaller criticisms I have made along the way.

Instead, let me tackle its weaknesses from two other directions.

1: Coherence

This chapter has something of the feeling of a camel – designed by a committee. It is nowhere near as coherent as the plans is encourages us to create. It feels like the authors have prioritized one part of the planning process at the cost of the others. And then, they have created a patchwork of disjointed comments about the other components, with no unity or, dare I say, holistic approach.

2: Agile vs Predictive PM

The whole section doesn’t say much about planning in an agile project environment. But, by not wanting to overplay the need for planning as a casual acknowledgment of this, it seems therefore to short-change the planning needs of a largely predictive project.

Rather than being an equal assessment of planning on both ends of the spectrum, we have poor service to each.

What Else We Should Include in the Planning Performance Domain?

My favorite part of these reviews is to ask, ‘what else would I have included?’ And, in this domain, there is little to say. If we accept what it includes without concern for the paucity of discussion, most aspects of planning are here. So, some of my suggestions are of secondary significance.

Missing, or substantially absent, however, are:

• Scoping as a part of the planning process
• The use of milestones
• Reference to Rick and contingency planning
• The Business Case or Benefits Case
• Planning horizons and rolling planning
• Responsibilities for the planning process – and sign-off
• Different formats for documenting project plans
• Control points within the plans (maybe they are implied in the metrics section)
• Resource levelling and smoothing

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

This is simple. Project Planning reaches out and touches every domain of project management. We:

• Plan Stakeholder Engagement
• Deploy our Team to create, maintain, and execute the plan
• Build our plans on the Development Approach and Life Cycle we select
• Use our plans to guide Delivery
• Incorporate the metrics in our plans to enable Measurement
• Subject out plans to risk management to account for Uncertainty

What are your Thoughts about the Planning Performance Domain?

Please share what you think of the way PMI has handles the Planning 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 Planning volume of our Kindle Exclusive Project Management Domains ebook series.