Monitoring and Controlling Process Group: 12 Processes, Change Control and Earned Value

What the process group is

Abdullah Oguz’s open textbook Project Management (chapter 11) describes monitoring and controlling as regularly measuring project progress to make sure it meets objectives and current organizational needs. It also covers deciding what corrective action is needed, when, and who must take it.

This group does not wait for the end. It runs alongside initiating, planning and executing from start to finish, and feeds closing with accepted deliverables. For how the groups fit the life cycle, see the 5 phases of project management.

A note on editions. The 12 processes below are from the Sixth Edition (2017). PMI’s page for the Eighth Edition (November 2025) says process guidance was reintroduced in a non-prescriptive way and does not describe the five groups by name. The monitoring ideas, such as baselines, variance and change control, apply either way. Confirm which edition your course or exam uses.

All 12 processes

The list follows the Visual Paradigm guide to PMBOK 6 knowledge areas and 49 processes. The “what it does” column is our plain-English summary.

The same guide notes that Control Resources is new in the Sixth Edition, and that three older “Control” processes were renamed “Monitor” (Communications, Risks and Stakeholder Engagement). Older study material may use the earlier names.

Monitoring vs controlling, and the three report types

The Oguz textbook separates the two jobs. We have paraphrased its lists below.

• Monitoring means collecting performance data, producing performance measures, and reporting performance information.
• Controlling means comparing actual with planned performance, analyzing variances, and recommending corrective action.

The textbook also makes a simple point worth remembering: the team cannot control well if it has not monitored properly. Bad data gives bad decisions.

It names three kinds of report:

• Status report: where the project stands at a point in time.
• Progress report: what the team has accomplished during a period.
• Forecast report: expected future status, based on current status and known trends.

How often you report depends on the project’s priority and length. Stakeholders with high power and high interest should get more information, more often. For ready-made indicators, see project management metrics and 5 useful metrics.

Baselines and variance

You cannot control what you have not baselined. The Oguz textbook states that a strong baseline is a key factor in project success, because actual performance is compared against it.

In PMBOK terms there are three baselines, all set during planning:

• Scope baseline: the approved scope statement, WBS and WBS dictionary.
• Schedule baseline: the approved schedule.
• Cost baseline: the approved time-phased budget.

A variance is the gap between planned and actual. Small variances are normal. What matters is the trend and whether the gap will break a constraint. Together these baselines hold the “iron triangle” of scope, time and cost; see the iron triangle.

Integrated change control

Changes will come. The risk is not change itself but uncontrolled change, which is how scope creep starts. Perform Integrated Change Control is the process that reviews every change request and decides its fate.

A typical flow, in our words:

1. Raise it. Anyone can submit a change request in writing.
2. Log it. Record it in a change log with an ID, date and owner.
3. Assess the impact. Check scope, schedule, cost, quality, risk and resources.
4. Decide. The sponsor or change control board approves, rejects or defers it.
5. Implement and update. If approved, update the plan and baselines, and tell stakeholders.
6. Verify. Confirm the change did what was intended.

Small projects often skip the board and let the sponsor decide. Larger ones set thresholds, for example that the project manager can approve changes under a set cost or day count, while anything bigger goes up. Agree the thresholds in the plan before you need them.

Earned value formulas

Earned value management (EVM) compares three numbers in money terms, so schedule and cost can be measured on one scale. The formulas below are the standard ones. We cross-checked them against the ProjectEngineer guide to earned value formulas.

The right EAC formula depends on why you are off track. Pick the one that matches your honest view of the cause, and say which one you used in the report.

Worked example

Take the small website project from our planning process group guide: 24 days and a work budget of $13,200. To keep the maths simple, we use $13,200 as BAC and leave out the contingency. Check how your organization treats reserves in BAC.

All numbers below are our illustration, not real project data. Assume day 12 of 24, and for simplicity that planned work accrues evenly.

What it tells the manager.

• The team has earned 80% of the planned value (SPI 0.80), and each $1 of budgeted work is costing about $1.17 (CPI 0.86).
• If this pace continues, the project ends about $2,200 over. If the overrun was a one-off, about $880 over.
• To finish on budget, the team must earn $1.13 of work for every $1 spent on the rest of the job (TCPI 1.13). Having run at 0.86 so far, that is a big ask.

The next move is a conversation, not a formula: find out why, then pick a response. Options include removing scope through change control, adding resources, or asking the sponsor to approve more budget.

A caution. EVM measures progress only as well as you measure percent complete. Vague claims such as “90% done” ruin the numbers. Many teams use simple rules, for example counting a task as complete only when it is finished and accepted.

Controlling the schedule

SPI shows how much work is behind. It does not show whether the end date is at risk. For that, look at the critical path from the planning stage. A delay on the critical path moves the finish date day for day. A delay on a task with float may not matter at all.

If the end date is at risk, two standard options exist:

• Crashing: add resources to critical-path tasks to shorten them. It usually costs more.
• Fast tracking: run tasks in parallel that were planned in sequence. It usually increases risk and rework.

Trimming scope is a third option, and the one most often forgotten. Every one of these is a change, so run it through change control. For the communication side, see how to improve project communication.

Validate Scope vs Control Quality

These two are often confused, since both check deliverables.

• Control Quality checks whether the deliverable meets the quality requirements. It is usually done by the team or a quality function, and usually comes first.
• Validate Scope asks the customer or sponsor to formally accept the deliverable.

Think of it this way: one asks “did we build it right?” and the other asks “is it what you wanted?” Capture acceptance in writing. It protects both sides and gives closing a clean start. Clear requirements make acceptance far easier.

Status report template

Keep it to one page. Put the decisions needed near the top if the status is amber or red. Who gets the report should come from your responsibility assignment matrix and communications plan.

Monitoring in agile and hybrid projects

Agile teams monitor too, but with shorter loops. Our summary of common practice: the team reviews progress at the end of each short iteration, uses simple visuals such as task boards and burndown charts, and re-orders priorities as new information arrives. Changes to the backlog are handled by the product owner rather than a formal board.

Hybrid projects often keep a fixed budget and milestones, with agile tracking inside them. Earned value still works at the project level if work is valued consistently. See the use of agile project management.

Common mistakes

• Reporting activity, not progress. Hours worked are not work finished.
• No baseline. Without one, you cannot tell whether you are off track.
• Hiding bad news. Late warnings leave fewer options. Raise problems early with a proposed fix.
• Informal changes. “Quick favors” add up to major scope growth.
• Trusting one metric. Check SPI and CPI together with the critical path, risks and stakeholder feedback.
• Never updating the plan. After an approved change, update the baselines and documents.
• Skipping acceptance. Without sign-off, disputes appear at the end.

Many of these also show up in why projects fail. If you are studying for the exam, our PMP exam prep course guide explains what to look for in a course.

Frequently asked questions

What is the monitoring and controlling process group?

The PMBOK process group that tracks, reviews and regulates project progress and performance, identifies needed changes, and starts the matching changes.

How many processes are in monitoring and controlling?

12 in the PMBOK Guide, Sixth Edition, out of 49 processes in total.

What is the difference between monitoring and controlling?

Monitoring collects and reports performance information. Controlling compares it with the plan, analyzes variances and recommends or takes corrective action.

What is integrated change control?

The process of reviewing all change requests and deciding to approve, reject or defer them, while managing changes to baselines and the plan.

What do CPI and SPI mean?

CPI is earned value divided by actual cost. SPI is earned value divided by planned value. Below 1 means over budget or behind schedule. Above 1 means better than planned.

What is the difference between Validate Scope and Control Quality?

Control Quality checks that deliverables meet the quality requirements. Validate Scope gets the customer or sponsor to formally accept them.

Does monitoring end before closing?

No. It runs through the whole project and hands accepted deliverables to closing.