If you jump straight into building or implementing something without a written plan, you will almost certainly waste time, overspend, and deliver the wrong thing. A project management plan (PMP) is your single source of truth that answers the five Ws: who, what, when, where, and why — plus how much it costs and what could go wrong. For the PK0-005 exam, you need to know exactly what goes into a PMP and why each piece matters, because they will test you on the difference between the plan itself and the individual planning documents that feed into it.
Jump to a section
A simple way to picture Project Planning Fundamentals
The driveway of a suburban house, early on a Saturday morning. You've agreed to drive your family and three friends from Manchester to Edinburgh for a long weekend. You don't just turn the key and go. You sit everyone down in the kitchen with a notepad.
First, you define the goal: get to Edinburgh Castle by 2 PM on Saturday. That's your project objective. Next, you figure out the scope — who's coming (four people, one dog, luggage for three days), what you're doing (visiting the castle, a ghost tour, and a Sunday lunch), and what you're not doing (no detour to the Lake District, no shopping malls). You write this down as your plan.
Then you list the tasks: book the car, check the tyres, pack snacks, load the boot, navigate the M6, find parking. Each task has an owner (you drive, your partner navigates, the kids handle snacks). You estimate time: driving is 4 hours, but with a break and traffic, you budget 6 hours. You identify risks: road closures, bad weather, someone getting carsick — and plan mitigations: check traffic apps, bring sick bags, pack an extra jumper.
Finally, you check the budget: fuel, parking, tolls, lunch, and entry fees. You document all of this, not in your head, but on a shared Google Doc everyone can see. That document is your project management plan — the single source of truth for how the trip will happen, who does what, and what success looks like. Without it, you'd argue about routes, run out of cash, and miss the castle tour. With it, everyone knows their job, the budget is set, and the trip runs smoothly.
A project management plan (PMP) is a formal, approved document that defines how a project is executed, monitored, controlled, and closed. Think of it as the master blueprint for a construction project — it contains or references every other planning document. It is not the same as the project schedule or the budget; it is the umbrella document that gathers them all together.
The purpose of the PMP is simple: to ensure everyone involved — the project manager, the team, stakeholders, and sponsors — shares a common understanding of the project. Without it, people make assumptions that lead to conflict, missed deadlines, and budget overruns.
The PMP includes several key components, which the exam calls 'subsidiary plans' or 'baselines'. Here are the most important ones:
Scope baseline: this consists of the scope statement (what is and is not included), the work breakdown structure (WBS — a hierarchical breakdown of all work), and the WBS dictionary (detailed descriptions of each work package). The scope baseline is the agreed boundary of the project. Any change to what the project delivers must be formally evaluated against this baseline.
Schedule baseline: this is the approved version of the project schedule, including start and finish dates for each activity. Once approved, it becomes the benchmark against which you measure progress. If a task finishes three days late, you know exactly how far off track you are.
Cost baseline: this is the approved budget, usually broken down by time period (e.g., monthly spending limits). It is the yardstick for cost performance. You compare actual spending against this baseline to spot overspends early.
Beyond baselines, the PMP also includes subsidiary management plans. These are documents that explain how specific aspects of the project will be handled:
Requirements management plan: describes how you will collect, analyse, document, and manage project requirements. For example, if you are building a website, this plan says 'We will interview five users, write user stories, and prioritise them by business value'.
Risk management plan: defines how you will identify, assess, and respond to risks. It includes the risk register (a list of identified risks with their probability and impact) and risk response strategies (avoid, mitigate, transfer, or accept).
Communication management plan: specifies who needs what information, when, and how. For instance, the project sponsor gets a one-page status report every Monday at 9 AM, while the development team gets a daily stand-up meeting.
Quality management plan: defines what quality means for this project and how you will ensure it. If the project delivers a mobile app, the quality plan might say 'All buttons must respond within 200 milliseconds'.
Stakeholder engagement plan: identifies all stakeholders (anyone affected by the project) and outlines how to engage them. A crucial stakeholder like a senior manager might need a monthly face-to-face update, while a customer representative might need weekly email summaries.
The PMP also includes the change management plan, which defines how changes to the project will be requested, reviewed, and approved. In projects, change is inevitable. A proper change management process prevents 'scope creep' – the slow, uncontrolled growth of what the project delivers, which is a leading cause of project failure.
Why does the PMP exist? Before professional project management became standard, teams would start building with only a vague idea of what was needed. They would discover halfway through that they were building the wrong thing, or that they had run out of money. The PMP replaces chaos with clarity. It forces you to think through every major aspect before committing resources.
In the real world, the PMP is not a static document. It can be updated through formal change requests. But once a baseline (scope, schedule, cost) is approved, changes require a formal review. This keeps the project under control.
For the PK0-005 exam, the critical distinction is this: the project management plan is the master document. It contains or references baselines and subsidiary plans. It is not the same as the project charter (which authorises the project), the WBS (which is part of scope baseline), or the schedule (which is part of schedule baseline). Remember: charter comes first, then planning produces the PMP, and the PMP guides execution.
Define the project scope
First, you document what the project will deliver and, critically, what it will not deliver. This becomes the scope statement. You also break the full scope down using the work breakdown structure (WBS) into smaller, manageable work packages. This step creates the scope baseline, which prevents scope creep later.
Develop the schedule baseline
Using the WBS, you estimate the duration of each work package, sequence them in logical order, and assign resources. The final approved schedule with start and end dates becomes the schedule baseline. This lets you track whether you are on time or falling behind.
Establish the cost baseline
You estimate the cost of each work package, including labour, materials, software, and any contingency reserves. The sum of these costs, approved by the sponsor, forms the cost baseline. This allows you to measure cost performance against the approved budget.
Create subsidiary management plans
You develop separate plans for managing risk, quality, communication, stakeholder engagement, requirements, and changes. Each plan defines processes, roles, and templates. For example, the risk management plan includes a risk register template and defines how risks will be prioritised.
Assemble and approve the project management plan
You compile all the baselines and subsidiary plans into a single document (or a set of linked documents) that becomes the PMP. You then present it to key stakeholders and the sponsor for formal approval. Once approved, the PMP becomes the authoritative guide for executing, monitoring, and controlling the project.
Establish change control procedures
You define how changes to the PMP or its baselines will be requested, reviewed, and approved. This typically involves a change request form and a change control board (CCB). This step ensures that any deviations from the plan are controlled and documented.
Let us walk through a real-world IT scenario. A company called GreenLeaf Gardening decides to build a mobile app that lets customers order plants and book gardening services. The senior manager (sponsor) has approved the project charter, and now the project manager needs to create the project management plan.
Step one: the project manager sits down with the key stakeholders — the head of sales, the lead developer, the customer support manager, and a representative from the finance team. They start by defining the scope. They agree that the app must let users browse plants, place orders, and schedule a gardener. They explicitly decide what is out of scope: the app will not include a loyalty programme, a blog, or any integration with accounting software. This becomes the scope statement.
Step two: the lead developer breaks the work down using a work breakdown structure (WBS). The highest level might be 'Frontend', 'Backend', 'Database', 'Testing', and 'Deployment'. Under 'Frontend', the developer lists 'Login screen', 'Plant catalogue', 'Order form', and 'Profile page'. Each of these is further broken down into specific tasks like 'Write code for plant catalogue search' or 'Create error message for invalid delivery address'. This WBS, along with the scope statement and a dictionary that explains each task, forms the scope baseline.
Step three: the project manager builds the schedule. Using the WBS, they estimate how long each task will take, sequence them in order (you cannot test before you code), and assign team members. The schedule baseline is the final approved version: 'Frontend login screen complete by April 10, backend order API complete by April 15, integration testing complete by May 1.'
Step four: the finance team provides cost estimates for developer time, software licences, cloud hosting, and user testing. The project manager adds a 10% contingency reserve for unexpected costs (a risk response). The approved budget — broken down by month — becomes the cost baseline.
Now the project manager assembles the subsidiary plans. For risk management, they identify the top three risks:
- A key developer might leave mid-project (mitigation: cross-train a second developer). - The app might fail to load during peak demand (mitigation: use auto-scaling cloud infrastructure). - The payment processor might have an outage (response: accept the risk and communicate to users with a 'retry later' message). These are documented in the risk register, which is part of the risk management plan.
For communication, the project manager defines:
- Weekly 30-minute status video call with the development team. - Bi-weekly 15-minute email update to the sponsor. - Monthly 1-hour stakeholder meeting with all key stakeholders. This is the communication management plan.
The project manager then organises all these documents into a single project management plan. They store it in a shared drive that everyone can access. Whenever someone suggests a new feature — like adding a blog — the project manager checks whether it is in scope. If not, they follow the change management process: the requester fills out a change request form, the project manager analyses the impact on cost and schedule, and a change control board (usually the sponsor and key stakeholders) decides whether to approve it.
In practice, the project management plan acts as the 'rulebook' for the project. When arguments arise — 'I thought we were adding a loyalty programme' — the project manager points to the scope baseline. When a developer says a task will take longer than planned, the project manager compares against the schedule baseline. When spending exceeds the monthly budget, they flag it against the cost baseline.
Without this plan, GreenLeaf would likely face scope creep, budget overruns, and a delayed launch. With it, they have a clear framework for making decisions, resolving disputes, and delivering the app on time and within budget.
The PK0-005 exam tests your understanding of project planning fundamentals in several specific ways. Here is exactly what you need to know.
First, the exam will ask you to identify which document or plan is used for a specific purpose. For example, a question might say: 'A project manager needs to determine how often stakeholders will receive project status updates. Which plan should they reference?' The correct answer is the communication management plan. The trap they set is offering the stakeholder engagement plan or the risk management plan as distractors. Remember: communication management plan deals with the 'what, when, and how' of information; stakeholder engagement plan deals with 'how to engage and manage expectations'.
Second, the exam loves testing the difference between baselines and subsidiary plans. A typical question: 'A project team realises a task will finish three weeks later than originally approved. Which document would the project manager use to measure this variance?' The answer is the schedule baseline. The trap: they might offer the project schedule (the unapproved version) or the WBS (which shows work breakdown, not dates). Remember: baselines are the approved versions that you compare against.
Third, they will test the relationship between the project charter and the project management plan. The charter authorises the project and names the project manager. The PMP is built during the planning phase and guides execution. The exam might say: 'Which document is produced first?' or 'Which document contains the high-level budget?' (the charter contains a high-level budget; the PMP contains the detailed cost baseline). Trap: many students confuse the two, thinking the PMP comes before the charter. It does not.
Fourth, the exam will test the components of the scope baseline. The scope baseline has three parts: the scope statement, the work breakdown structure (WBS), and the WBS dictionary. A common exam question: 'Which of the following is NOT part of the scope baseline?' offering options like the WBS, the scope statement, the WBS dictionary, and the project schedule. The answer is the project schedule. Trap: they might list the WBS dictionary, which sounds made up but is real.
Fifth, they test the concept of the work breakdown structure (WBS) itself. The WBS is a hierarchical decomposition of all work required to complete the project. It does NOT show dependencies or timelines — those are in the schedule. A question might ask: 'What is the primary purpose of the WBS?' Answer: to break the project into manageable work packages. Trap: they might say 'to show task dependencies' or 'to assign resources' — those are secondary uses, not the primary purpose.
Sixth, the exam will include questions about change management. The change management plan, which is part of the PMP, defines the process for evaluating and approving changes. A typical question: 'A stakeholder wants to add a new feature. Who approves the change?' The answer depends on your organisation's change control board (CCB), but the process is defined in the change management plan. Trap: they might say 'the project manager' unilaterally approves changes, but in most formal processes, the project manager reviews and presents the change to the CCB.
Seventh, they test risk management. The risk register is a key document within the risk management plan. They might ask: 'What is the difference between a risk and an issue?' A risk is a potential problem that has not happened yet; an issue is a problem that has already occurred. Trap: they offer 'both are the same' or 'a risk becomes an issue after a change request'.
Finally, they test the importance of stakeholder engagement. The stakeholder engagement plan identifies stakeholders and outlines strategies to keep them informed and involved. A question might ask: 'A project manager discovers that a key stakeholder is resistant to the project. Which plan should the project manager update?' Answer: the stakeholder engagement plan. Trap: communication management plan (which is related but focuses on information distribution, not engagement strategies).
In summary, memorise the differences between baselines and subsidiary plans, know what belongs in each plan, and understand that the PMP is the master document that contains or references everything else. The exam will give you scenario-based questions where you must pick the correct document or process. Practise by reading scenario descriptions and asking yourself: 'Which plan does this relate to?'
The project management plan (PMP) is the master document that integrates all subsidiary plans, baselines, and processes for a project.
A baseline is an approved version of a plan (scope, schedule, or cost) that you compare actual performance against.
The scope baseline consists of the scope statement, the work breakdown structure (WBS), and the WBS dictionary.
The schedule baseline shows the approved start and finish dates for project activities.
The cost baseline represents the approved budget, typically broken down by time period.
Subsidiary management plans — such as risk, communication, quality, and stakeholder engagement plans — define how specific aspects of the project will be managed.
The project charter authorises the project and is created before the PMP; the PMP is created during the planning phase.
Change requests are the formal way to modify the PMP or its baselines, and they must follow the change management plan.
The work breakdown structure (WBS) decomposes project work into manageable work packages, but does not show task order or timing.
Every project, regardless of complexity, benefits from a documented PMP to align stakeholders, control scope, and manage risk.
These come up on the exam all the time. Here's how to tell them apart.
Project Charter
Created during project initiation
Contains high-level information, not detailed plans
Authorises the project and names the project manager
Project Management Plan
Created during project planning
Contains detailed baselines and subsidiary plans
Guides execution, monitoring, and control of the project
Work Breakdown Structure (WBS)
Breaks work into hierarchical components
Does not include task durations or order
Forms part of the scope baseline
Project Schedule
Shows task sequences and timelines
Includes start and finish dates
Forms part of the schedule baseline
Scope Baseline
Includes scope statement, WBS, and WBS dictionary
Defines what the project will deliver
Changes require formal change requests
Cost Baseline
Shows the approved budget over time
Defines how much the project will cost
Changes require formal change requests
Risk
A potential problem that has not occurred yet
Has a probability and impact rating
Documented in the risk register
Issue
A problem that has already occurred
Requires immediate action or escalation
Documented in the issue log
Communication Management Plan
Focuses on what information is shared, how, and when
Defines distribution methods (email, meetings, dashboards)
Answers 'who gets what and when'
Stakeholder Engagement Plan
Focuses on building relationships and managing expectations
Identifies stakeholder attitudes and influence
Answers 'how to keep stakeholders supportive'
Mistake
The project management plan is the same as the project schedule.
Correct
The project management plan is the master document that contains or references many subsidiary plans, including the schedule baseline. The schedule is just one part of the plan.
Beginners often hear 'plan' and think of a timeline or Gantt chart, but the PMP is much broader — it covers scope, cost, quality, risk, communication, and more.
Mistake
Once the project management plan is approved, it can never change.
Correct
The PMP can be updated through formal change requests. Changes to baselines (scope, schedule, cost) require review and approval by the change control board.
Because the word 'plan' sounds fixed, many assume it is rigid. In reality, projects are dynamic, and the PMP is a living document that evolves with proper governance.
Mistake
The project charter and the project management plan are the same document.
Correct
The project charter authorises the project and provides high-level information. The PMP is created during planning and provides detailed guidance for execution. They are distinct documents created at different times.
Both documents are created early in the project lifecycle, so beginners conflate them. But the charter comes first (during initiation), while the PMP comes later (during planning).
Mistake
The work breakdown structure (WBS) is a list of tasks in order of completion.
Correct
The WBS is a hierarchical breakdown of all work, but it does not show the sequence or dependencies of tasks. The schedule (such as a Gantt chart) shows the order and timing.
New learners see the WBS as a numbered list and assume it implies order. In reality, the WBS is a decomposition tool, not a sequencing tool.
Mistake
The risk management plan is only created if the project is high-risk.
Correct
Every project, regardless of size or risk level, should have a risk management plan as part of the PMP. It defines the process for identifying, analysing, and responding to risks proactively.
Beginners think risk management is optional or only for complex projects. The exam expects you to know that it is a standard component of the PMP for all projects.
Mistake
The communication management plan and the stakeholder engagement plan are identical.
Correct
The communication management plan focuses on the 'what, when, and how' of information distribution. The stakeholder engagement plan focuses on identifying stakeholders and developing strategies to manage their expectations and involvement.
Both involve stakeholders, so beginners think they are the same. However, engagement is about building relationships and buy-in, while communication is about logistics of information sharing.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The project charter is a high-level document that authorises the project and names the project manager. The project management plan is a detailed document created during planning that explains how the project will be executed, monitored, and controlled. The charter comes first; the PMP comes next.
No. The work breakdown structure (WBS) breaks the project work into smaller pieces but does not show when they will be done or in what order. The schedule shows the timing and sequence of tasks. They are related but different documents.
Yes — the PMP should be tailored to the project's size and complexity, but every project benefits from having a documented plan. A small project might have a shorter PMP, but it should still cover scope, schedule, cost, risk, and communication.
Changes are handled through the change management process. Someone submits a change request, the project manager evaluates the impact on baselines, and a change control board (or the sponsor in smaller projects) decides whether to approve it. Approved changes update the PMP and its baselines.
A baseline is an approved version of a plan — such as the scope baseline, schedule baseline, or cost baseline — that you use as a benchmark to measure actual performance. Any difference between actual results and the baseline is called a variance.
Proactive risk management saves time and money. By identifying risks early, you can prevent them or reduce their impact. The risk management plan ensures you have a consistent process for doing this, rather than reacting to crises after they occur.
You've finished Project Planning Fundamentals. Continue through the PK0-005 study guide to build a complete picture of the exam.
Done with this chapter?