5.1 Project Management Plan (PMP) and Deployment Baselines

5.1 Project Management Plan (PMP) and Deployment Baselines

Definition (APM BoK7 glossary): The project management plan (PMP) is the output of the process of integrated planning for a project or programme.

BoK7 defines integrated planning as "the application of management processes that bring together the planning of benefits, success criteria, scope, quality, time, resources, cost, risk, communications, etc. to create the project management plan", and a management plan as "a plan that sets out how an aspect of a project, programme or portfolio will be delivered, for example a configuration management plan. Individual management plans are component parts of the overall project management plan (PMP) that is the output of integrated planning."

So the PMP is not one document among many — it is the integration of all of them, and the governance arrangements with it, into the single reference that directs, executes, monitors and controls the project.

A common misconception in project management is equating the project plan with a simple Gantt chart or schedule. In the Association for Project Management (APM) framework, a schedule is merely one constituent element of a far broader, integrated management framework. Delivering a complex, unique, and transient endeavour requires alignment across scope, time, cost, quality, risk, resources, procurement, and stakeholder communications. The master document that unites these disparate threads into an actionable blueprint is the Project Management Plan (PMP).

Without an approved PMP, a project lacks a documented mandate for execution, clear accountability for deliverables, and an agreed benchmark against which progress, variance, and performance can be objectively measured.

---

Purpose and Strategic Role of the PMP

The PMP serves as the definitive "contract" between the Project Manager, who is responsible for day-to-day delivery, and the Project Sponsor, who governs the project on behalf of the sponsoring organization. Its core purposes include:

1. Establishing the Performance Measurement Baseline: It formalizes the agreed scope, schedule, and cost targets, providing the approved yardstick against which real-time project performance is tracked.
2. Integrating Subsidiary Management Plans: It ensures that individual management domains—such as quality control, risk response, and procurement strategies—are fully synchronized rather than operating as conflicting silos.
3. Defining Project Governance and Control Frameworks: It sets out decision-making thresholds, reporting frequencies, delegated tolerances, and formal escalation mechanisms.
4. Providing a Baseline for Change Control: Any proposed alteration to project scope, milestone dates, or expenditure limits is formally evaluated against the baselines preserved in the PMP.
5. Facilitating Organizational Alignment: It communicates the strategic context, project objectives, and operational boundaries to all internal and external stakeholders, ensuring common expectations.

Authorship, Approval, and Living Document Status

The PMP is developed during the Definition phase of the project life cycle. While the Project Manager leads its authoring with contributions from specialist team leads, technical architects, and schedulers, the Project Manager does not have the authority to unilaterally approve it. Formal approval and sign-off rest solely with the Project Sponsor (often supported by the Project Steering Group or Governance Board) at Gate 2 (the Definition-to-Deployment gate review).

Furthermore, the PMP is a living document. It is not drafted once, locked away in an archive, and forgotten. As the project encounters unforeseen events, emerging risks, or approved client changes during the Deployment phase, the PMP is updated through formal change control. Every revision must be version-controlled, maintaining a transparent audit trail of baseline changes.

---

Core Components of the Project Management Plan

A comprehensive PMP comprises several interrelated subsidiary plans and performance baselines. The table below details these typical components and their specific role in project control:

---

Stakeholder Utilization of the PMP

The PMP is not exclusively designed for the Project Manager. Different stakeholders engage with the PMP to fulfill distinct governance, operational, and assurance duties:

1. The Project Manager

The Project Manager uses the PMP daily as an operational compass. It directs resource deployment, guides task assignments, enables progress tracking against the schedule and cost baselines, and dictates the correct protocol when deviations occur.

2. The Project Sponsor and Steering Committee

The Sponsor relies on the PMP as an instrument of strategic governance. By referencing the agreed governance arrangements, tolerances, and milestone schedules, the Sponsor monitors executive health metrics, reviews exception reports when tolerances are threatened, and confirms whether the project continues to fulfill the approved Business Case.

3. The Project Delivery Team and Specialist Contractors

Team leaders, work package managers, and specialist trade contractors examine the PMP to understand their specific work boundaries (via the WBS), their deliverable acceptance criteria (via the Quality Plan), their required delivery deadlines, and their assigned accountability (via the RACI matrix).

4. The Project Management Office (PMO)

The PMO inspects the PMP to assure adherence to enterprise delivery standards, verify the consistency of estimating models, resolve cross-project resource conflicts across the corporate portfolio, and harvest organizational metrics.

5. Internal and External Auditors

Auditors use the PMP as an evidentiary baseline to assess corporate governance, statutory compliance, health and safety protocols, and financial integrity. They verify whether the project team executed the work in accordance with the documented management procedures approved at Gate 2.

---

The Deployment Baseline Explained

A critical concept within the APM syllabus is the deployment baseline (often termed the Performance Measurement Baseline or PMB).

APM BoK7 (4.2.10): the deployment baseline is the culmination of integrated planning, documented in the integrated project management plan (PMP). BoK7 states that "the deployment baseline and PMP are approved at the decision gate associated with the approval of significant costs on the project", and that the baseline comprises scope, quality, resourced schedule and associated cost. It is "the starting point for progress monitoring and implementation of change control".

Note the four elements. Candidates routinely quote scope, schedule and cost and forget quality — which is exactly the element that varies in an iterative life cycle.

Why Established at the End of Definition?

During the early Concept phase, requirements are fluid, solution architectures are conceptual, and uncertainty is high. Establishing a rigid baseline during Concept is impossible because detailed work packages have not been formulated. Only at the conclusion of the Definition phase—after options appraisal has settled on a preferred solution, detailed requirements have been decomposed into a WBS, and resource costs have been accurately estimated—can an organization commit significant capital. BoK7 adds that it is good practice for an integrated baseline review to be conducted by an independent reviewer: a risk-based review that builds mutual understanding of the risk inherent in the baseline costing and confirms the baseline scope is realistic within the schedule and budget. It also notes that the business case approved at the previous gate will have contained many assumptions, which now need to be clarified or replaced with definite plans.

Approving the deployment baseline at Gate 2 authorizes the project team to commit major financial expenditure and commence physical delivery in the Deployment phase.

Preserving Baseline Integrity Through Change Control

A baseline is not an immovable, permanent monument. Unforeseen geological findings, regulatory changes, or client scope modifications will inevitably arise. However, once established, the deployment baseline cannot be altered casually or informally by the project team. Any adjustment to the baseline requires a formal Change Request that analyzes the holistic impact across the triple constraint (scope, schedule, and budget) and secures written approval from the Project Sponsor. Tracking actual performance against an unauthorized or fluctuating baseline destroys management control.

---

Linear vs. Iterative Deployment Baselines

The structure and governance of a deployment baseline vary significantly depending on whether the project adopts a linear (predictive/waterfall) or an iterative (agile/adaptive) life cycle:

In a linear project (such as building a bridge or civil infrastructure), scope is fixed because the end deliverable can and must be fully specified before construction begins. Consequently, schedule and cost baselines are derived to deliver that exact scope. In contrast, in an iterative project (such as customer-facing digital software), the baseline resources and schedule are determined (a dedicated team working for six two-week sprints), while the achievement of scope and quality may vary from the plan. The baseline in an iterative context reflects the team's capacity and timebox commitments, with requirements prioritised dynamically to maximise the value delivered within the fixed time and resources.