Monitor & Control in PM²: keeping a project in control, not merely updated
Thirteenth article in the “Learning PM² Through a Project” series
A project is not under control simply because the Project Manager sends a status report every Friday. It is under control when the team systematically compares reality with the approved plan, understands deviations, and takes proportionate action.
In PM², Monitor & Control is a set of cross-cutting activities. It accompanies the project from initiation to closing; it is neither a phase after Executing nor an administrative exercise.
The core idea
The logic is always the same:
- define an approved baseline: plans, requirements, costs, schedule, quality and acceptance criteria;
- measure the actual situation;
- assess deviation, risks and impact;
- act, record the decision and communicate with stakeholders.
Without a baseline, calling something “late” or “over budget” is only a perception.
Monitoring and controlling are not the same
| Activity | Question it answers | Example |
|---|---|---|
| Monitoring | Where are we compared with the plan? | The beta release is 60% complete; the plan expected 80%. |
| Controlling | What do we do to bring the project back within acceptable limits? | Reallocate capacity, re-plan a dependency, or submit a change to the appropriate decision-making level. |
Monitoring produces evidence; controlling turns that evidence into a decision or action. A report without follow-up is incomplete monitoring, not control.
What Monitor & Control covers in PM²
PM² groups together the management activities that keep the project governable:
| Area | What is checked or managed |
|---|---|
| Performance | overall status, forecasts, deviations and reporting |
| Schedule and cost | progress against schedule and budget; corrective actions |
| Stakeholders | expectations, engagement, communication and resistance |
| Requirements and change | traceability, impact assessment, approval and Change Log |
| Risks | probability, impact, response and Risk Log updates |
| Issues and decisions | current problems, owners, due dates, escalation and Decision Log |
| Quality and acceptance | deliverable compliance and acceptance criteria |
| Transition, business implementation and outsourcing | operational readiness, adoption and suppliers |
This does not mean applying every practice with the same intensity. The PM tailors them to project complexity and risk, while retaining traceability for material decisions.
The practical control loop
flowchart TD
A[Approved baseline] --> B[Collect actual data]
B --> C[Assess deviation and impact]
C --> D{Within tolerance?}
D -- Yes --> E[Record and communicate]
D -- No --> F[Correct or propose change]
F --> G[Decision and controlled update]
G --> E
Tolerances make the process workable: the PM manages what is within delegated authority; when a deviation exceeds agreed limits, it is brought to the role or body with the required authority. Escalation is not abandoning responsibility: the PM prepares the analysis, options and recommendation.
Change, risk and issue: the distinction to remember
| Term | What it is | Annotatio example |
|---|---|---|
| Risk | An uncertain event that may affect the project if it occurs. | The push-notification provider may change policy before go-live. |
| Issue | A current or already occurred problem. | Android notifications no longer reach some devices. |
| Change | A request to modify an already approved project element. | The client asks for recurring bookings in the current release, although they were outside scope. |
The correct mental sequence is: a risk may materialise and become an issue; a change request may arise to resolve an issue, but it is not automatically approved.
Managing change: saying yes is not enough
A useful change request is logged and assessed before a decision. Assessment considers at least the impact on:
- scope and requirements;
- schedule and dependencies;
- effort and cost;
- quality, security and risks;
- expected benefits and priorities.
Only after approval are relevant plans and baselines updated in a controlled way. If every urgent request goes directly into development, that is not agility; it is loss of governance.
The Annotatio case: a report that leads to decisions
The plan for Smart Bookings targets a late-June release with push notifications, a waiting list and a manager dashboard. In mid-June, the PM finds that:
- the waiting list is ready;
- push notifications have an Android defect;
- the manager also requests CSV export of attendance, which is outside scope;
- testing with two gyms shows insufficient training for collaborators.
Correct management is not a single red status. It means distinguishing and treating each item:
| Evidence | Type | Action |
|---|---|---|
| Android push defect | Issue | Technical owner, root-cause analysis, due date and correction verification. |
| CSV export | Change request | Estimate the impact; decide to include, defer, or substitute another feature. |
| Insufficient training | Adoption/benefits risk, evidenced by testing | Update the business implementation plan and prepare short training before go-live. |
The PM updates reports and logs; the PO/BM decide on priorities and acceptable business impact; the SP assesses solution feasibility and capacity. This turns project status into a basis for decisions, not a bulletin.
Do not confuse these
| Statement | Why it is wrong |
|---|---|
| “Monitor & Control happens after Executing.” | It is cross-cutting and applies throughout the lifecycle. |
| “An issue is a very serious risk.” | No. An issue is real; a risk is uncertain. Severity and probability are separate dimensions. |
| “Every client request is an approved change.” | It is a request to assess and decide according to governance. |
| “The Change Log is just bureaucracy.” | It preserves rationale, impact, decision and traceability of changes. |
Three questions to anchor it
- Which baseline are you using to say that a project is late?
- When should the PM handle a deviation and when does it need escalation?
- Is the request a risk, an issue or a change request? Why?
Flashcards
Q: What does Monitor & Control do in PM²?
A: It compares actuals with baselines, manages deviations, risks, issues and changes, and enables timely decisions.
Q: What is the key difference between a risk and an issue?
A: A risk is uncertain and future; an issue is current or has already occurred.
Q: What must happen before a change is incorporated into the plan?
A: It must be logged, impact-assessed, decided by the competent authority, and followed by a controlled update of the relevant baselines.
Exam-style question
A supplier says that a component may not be available on time. The PM records it as an issue and immediately changes the release date.
What is the best correction?
Answer: the possible unavailability is first a risk, because it has not happened yet. The PM should assess probability, impact and response; any change to the release baseline then requires the analysis and approval required by governance.
Source
The concepts and activities in this article are based on the Monitor & Control chapter of the European Commission’s PM² Methodology Guide 3.1.
The next article will focus on the Project Work Plan: turning scope, deliverables, activities, estimates and dependencies into a plan that can actually be used.