‘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 7th 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?
In this article, we will examine:
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:
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?
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:
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, 7th 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:
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.
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, 2nd 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.’
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.
I like this statement and yet… I have two concerns.
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.
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.
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’.
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.
There’s nothing much to add to this one, except that it will lead us to:
Except, PMBOK 7 is extremely weak on change control and neither version control nor configuration management get a mention in the index!
I think there are two big things that are either missing or buried from the PMBOK 7 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.
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’.
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.
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.
This one however is stated simply… but somewhat tautologically. We find that appropriate time was spent if the level of our plans is appropriate.
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.
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.
In the introduction to the Planning Performance Domain, PMBOK 7 highlights (in a box), six definitions of jargon terms:
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.
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, 2nd edition
Mike Clayton, 2017
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.
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.
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’.
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:
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:
There are then 4 parts that cover:
Here are our articles on these topics:
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.
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 last three main sections tackle three aspects of what makes a good plan:
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:
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’.
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:
Yet the authors allocate similar numbers of pages to the other seven performance domains. They didn’t have a chance.
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.
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.
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.
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:
This is simple. Project Planning reaches out and touches every domain of project management. We:
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.
This is a Chapter from the Planning 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.
How to Write a Health & Safety Plan for Your Project | Video
How to Use Machine Learning in Project Estimating, Scheduling, & Planning
How to Create a Project Schedule – 21 Steps in 5 Stages | Video
Project Estimating Skills: How to Master Successful Project Estimation
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.