Hello and welcome to another Parallel Project Training podcast. These podcasts are linked to the APM PMQ syllabus for exams starting in September 2024. My name is Ruth Phillips, and I’m here with Lisa Regan, one of Parallel’s senior project trainers. Welcome to the podcast, Lisa.
Hi, Ruth. It’s great to be here.
Today’s topic is integrated planning, which is both an exciting and crucial subject for us to discuss. I always say, if you don’t enjoy planning in project management, you’re probably in the wrong job.
Absolutely, this is our bread and butter, isn’t it?
It really is. Let’s start by looking at the syllabus. The learning objective states that we need to understand that integrated planning involves incorporating multiple plans and processes into an integrated project management plan, or PMP, as we might call it.
Before we delve into the details of the PMP, Lisa, could you clarify the difference between a plan and a schedule? I think there’s often some confusion between the two.
Certainly. In the APM’s world, when they refer to the PMP, or project management plan, they’re talking about a collection of documents, not just the schedule, which is essentially the Gantt chart—tasks over time. The PMP, however, encompasses a wide range of documents, not just the schedule.
That really clears things up because, as you said, people often mistake a simple timeline for a full plan. But what we’re discussing here, and the clue is probably in the word ‘integrated’, is a comprehensive suite of plans and processes that collectively outline what we’re going to do on a project.
Exactly. Our first learning outcome is to understand the formats for an effective integrated project management plan and its typical contents. So, let’s talk about what this plan entails.
As I mentioned, the PMP is a collection of documents. I always imagine it as a large folder containing everything you’ll need to manage your project. The contents can be split in two ways because it’s a massive list. One way to break it down is to consider the key elements: the who, the when, the what, and the how much.
For example, the ‘what’ in the PMP refers to the scope—so things like the Work Breakdown Structure (WBS), Product Breakdown Structure, specifications, and constraints. The ‘how much’ is about the budget, including the Cost Breakdown Structure and any earned value details. The ‘when’ is the schedule—the Gantt chart we mentioned earlier. The ‘who’ relates to the Organisation Breakdown Structure, which can be cross-referenced with the WBS to produce the Responsibility Assignment Matrix.
It’s a lot to consider. But for me, the ‘how’ is the most significant part—the quality plan, risk plan, change plan, and so on. Essentially, if it ends with ‘plan’, it’s likely part of the PMP.
Yes, and we mustn’t forget the ‘why’, which comes from the business case—the project’s justification. Then there’s the ‘where’, which becomes relevant if your project spans multiple locations or continents.
The final element is the agreement, which we’ll discuss shortly. The agreement is the deployment baseline, and when you move into deployment, that baseline is where you start from. Any changes must go through the change process within the linear lifecycle.
Apologies for the lengthy explanation, Ruth, but it’s all about answering those essential questions. The PMP is a single, central source of information about how we’re going to execute the project.
Who is responsible for developing the PMP, and where does that information come from?
The PMP is the project manager’s responsibility. We discussed in another podcast how the business case is the sponsor’s responsibility, developed during the concept phase. Similarly, the PMP is under the project manager’s remit and is put together during the definition phase, where all the detailed plans are consolidated.
Another way to categorise the information within the PMP is into live documents and reference documents. The APM calls them policies and procedures. These are the documents that sit on a shelf and are rarely referred to, whereas the schedule and logs are updated as the project progresses—things like the risk register and the Gantt chart.
I like that distinction. As an engineer, I appreciate a clear separation in my mind. I’ve also heard it referred to as static and dynamic, but it’s the same idea—policies and procedures are more static, while live documents are dynamic and regularly updated.
Yes, it’s just another way to slice the information. So, the syllabus asks us to understand the format of an effective integrated project management plan. What might this look like in practice?
That’s a good question. It could mean electronic format or paper, depending on the project. For some projects, everything is entirely electronic. However, in more traditional setups, you might still find paper copies or even recordings of meetings. It really depends on the project’s size, complexity, and whether you’re working with external partners or just internally.
I’ve also used project management tools that handle some of this for me. When they say ‘know the format’, it’s challenging to pin down because it’s project-dependent.
Absolutely. But I think the key word here is ‘effective’. We can produce all of this information, but what makes it effective is its role as a communication tool. The PMP is all about keeping stakeholders informed and engaged.
That’s an excellent point. If you don’t understand why you’re compiling all this information or how it will be communicated, it’s just administration and not effective. I’ve heard people describe the PMP as a ‘contract’ in the same way that the business case is a contract between the sponsor and the organisation.
Yes, exactly. The PMP is essentially the project manager saying to the sponsor, ‘This is what I’m going to do, this is how I’m going to deliver it, and I’ll keep you updated against this plan.’
That brings us to our second learning outcome: understanding the importance of producing an integrated project management plan. What would happen if we didn’t have one?
Chaos! It would quickly spiral into chaos because the PMP is the single source of truth. These days, most documents are kept online, and anyone can access them at any time to see where we’re up to and what’s happening next. It ensures everyone gets the same message, which is crucial in a project environment where teams are temporary and people come and go.
Without a PMP, you lose control very quickly. The library of information within the PMP provides the answers to what we agreed to do, why, and when it’s supposed to happen. If things change, it’s essential to keep the PMP updated; otherwise, the project could spiral into chaos.
I like that phrase, ‘spiralling into chaos’. One last point—can you explain the concept of the PMP as a deployment baseline?
Sure. The deployment baseline is essentially the reference point in the deployment phase of the lifecycle. When we talk about a baseline, we’re talking about a line in the sand, a reference level. How do you know how well you’re doing on a project? You look back to the details in the PMP to see where you should be at a given time and compare it to where you actually are.
It allows you to monitor and control the project. For example, if you’re in week three and someone asks how you’re doing, you check the PMP to see what was planned for week three and measure progress against it. The PMP as a deployment baseline is not just about monitoring; it’s also crucial for managing change.
That makes sense. It’s a snapshot that we can always refer back to and say, ‘This is what we planned, and this is how it’s actually going.’
Exactly. It’s also essential for audits. The PMP is your evidence, your backbone for managing the project. When conducting reviews, all the information you need is in the PMP, and you compare it against that baseline to see where you stand.
It’s absolutely fundamental to project management.
Indeed. The business case is key for the sponsor, and the PMP is key for the project manager. It’s a cascade—the sponsor outlines the project and its goals, and the project manager develops the PMP to detail how those goals will be achieved.
That’s it. The business case gives the overview, and the PMP provides the detailed plan, sometimes down to day-to-day tasks.
We’ve had a great discussion about integrated planning and the PMP. We’ve covered its format, how to make it effective, its typical contents, responsibilities, and the importance of producing it, along with the concept of the deployment baseline. That’s quite a lot!
Thanks, Lisa. It’s been a really insightful conversation.
Thank you, Ruth. Bye.
