Project Monitoring and Control: A Practical PM Guide
Project monitoring and control is the ongoing process of measuring project performance against approved baselines, identifying variances, and authorizing corrective or preventive actions to keep the project on track. It runs in parallel with execution, not after it. Three things to do right now:
- Pull your current scope, schedule, and cost baselines and confirm they are formally approved and accessible to the team.
- Pick three KPIs to track this week: Schedule Performance Index (SPI), Cost Performance Index (CPI), and open-risk count.
- Book your next review meeting within five business days and assign one person to own the status report.
Those three steps turn monitoring from an intention into a system. The rest of this guide shows you how to build that system properly.
Key Takeaways
Effective project monitoring and control requires baselines, defined thresholds, clear ownership, and a repeating review cycle, not just a status report template.
| Point | Details |
|---|---|
| Start with locked baselines | Approved scope, schedule, and cost baselines are the reference point for every variance calculation. |
| Track SPI and CPI weekly | An SPI or CPI below 0.85 for two consecutive periods is a red-zone trigger requiring sponsor escalation. |
| Define thresholds before execution begins | Variance thresholds and escalation paths agreed during planning make monitoring an actionable system, not paperwork. |
| Use milestone-based EV measurement | Binary completion signals (deliverable accepted or not) produce more reliable EV data than self-reported percent complete. |
| Manaxo centralizes monitoring in one platform | Manaxo automates KPI alerts, change request routing, and role-based reporting so PMs spend less time consolidating and more time deciding. |
Table of Contents
- What does project monitoring and control actually cover?
- Why does monitoring and control matter for project outcomes?
- What are the seven types of project monitoring?
- How do you run a 6-step monitoring and control process?
- What KPIs and EVM formulas should you track?
- Which tool categories accelerate accurate monitoring?
- How do you handle change control and scope management?
- Who owns monitoring? Roles, RACI, and escalation paths
- What does a practical daily, weekly, and monthly cadence look like?
- What does empirical research say about corrective actions and variation?
- The part of monitoring most teams get wrong
- How Manaxo helps you put monitoring into practice
- Sources
What does project monitoring and control actually cover?
The formal term in project management is the Monitoring and Controlling Process Group, defined by PMI as the set of processes that track, review, and regulate the progress and performance of a project. Where execution is about doing the work, monitoring is about observing it and comparing what you see to what you planned.
The feedback loop looks like this: you collect performance data, compare it to your baselines, identify any variance, assess whether that variance is significant, and then either accept it or authorize a change. That loop repeats continuously throughout the project lifecycle, not just at milestones.
The six core areas tracked in any complete monitoring system generally include scope, schedule, cost, quality, risk, and stakeholder engagement, addressing whether deliverables meet requirements, timelines are met, budgets are maintained, quality standards are achieved, risks are managed, and communication is effective.
According to PMI’s learning library, monitoring translates raw execution data into knowledge, and that knowledge is what allows a project manager to distinguish between noise and a genuine problem. Not every deviation warrants action. Common-cause variation, the normal fluctuation you would expect in any complex work, should be observed but not over-corrected. Special-cause variation, a signal that something structurally different is happening, is what justifies a formal corrective action.
Pro Tip: Before your first monitoring cycle, write down what “normal” looks like for your project. The distinction matters more than the number itself.
Why does monitoring and control matter for project outcomes?
Projects fail in predictable ways: scope expands quietly, costs drift before anyone notices, and risks that were logged but never reviewed materialize at the worst possible moment. Disciplined monitoring closes each of those gaps early, when the cost of correction is still manageable.
The primary benefits are concrete:
- Earlier corrective action: Catching variances early in the project lifecycle reduces correction costs.
- Baseline adherence: Formal monitoring supports delivery within scope, schedule, and budget.
- Risk reduction: Regular risk reviews help identify and mitigate emerging threats.
- Stakeholder confidence: Transparent reporting fosters trust among sponsors and clients.
For example, regular tracking of cost performance allows identification and mitigation of issues before they escalate, reducing delays and cost overruns.
PMI’s 2023 Pulse of the Profession report finds that organizations with disciplined measurement and governance practices recover more quickly from deviations and achieve materially higher project success rates than those without them.
The implication is not that monitoring guarantees success. It is that without it, you are flying without instruments.
What are the seven types of project monitoring?
Not every project needs all seven types running at full intensity simultaneously. The list below gives you the full set; the guidance after each entry tells you when to prioritize it.
- Schedule monitoring: Tracks activity completion against the baseline timeline. Essential on every project; the primary signal is SPI falling below 0.90.
- Cost/EVM monitoring: Uses Earned Value Management to compare planned value, earned value, and actual cost. Critical on fixed-price or budget-constrained projects; watch CPI trending below 1.0 for two consecutive periods.
- Quality monitoring: Verifies that deliverables meet acceptance criteria through reviews, testing, and audits. Non-negotiable on regulated or client-facing deliverables; the signal is defect rate or rework volume climbing.
- Risk monitoring: Reviews the risk register for probability/impact changes and new risks. Prioritize this on projects with high uncertainty or external dependencies; the signal is a risk moving from “low” to “high” without a mitigation plan in place.
- Scope/configuration monitoring: Tracks approved scope against what is actually being built or delivered. Critical when requirements are complex or the client has a history of change requests; the signal is unlogged work appearing in sprint backlogs or delivery plans.
- Resource utilization monitoring: Measures whether people and equipment are allocated and performing as planned. Most important on resource-constrained projects; the signal is a key resource consistently over-allocated or under-delivering.
- Stakeholder and communications monitoring: Checks whether the right people are receiving the right information at the right frequency. Prioritize on projects with multiple sponsors or politically sensitive stakeholders; the signal is a sponsor raising a concern in a steering meeting that should have been addressed two weeks earlier.
Pro Tip: On a small project with a team of five or fewer, collapse this list to three: schedule, cost, and risk. Add quality if the deliverable has formal acceptance criteria. Add scope if the client has already changed their mind once. Complexity earns the full seven; simplicity does not.
How do you run a 6-step monitoring and control process?
The process below is sequential within each monitoring cycle, but the cycles themselves overlap with execution continuously. Think of it as a weekly rhythm, not a one-time event.
The six steps
- Establish baselines. Before the first cycle, lock the approved scope baseline (WBS and WBS dictionary), schedule baseline (Gantt or network diagram with critical path), and cost baseline (time-phased budget). These are your reference points for every variance calculation.
- Collect performance data. Gather actuals: hours logged, costs incurred, tasks completed, defects found, risks updated. The data source matters. Self-reported percent-complete is notoriously unreliable; prefer milestone-based or deliverable-based completion signals.
- Analyze variance. Compare actuals to baselines. Calculate SPI and CPI (formulas in the next section). Flag any variance that exceeds your predefined thresholds. Practitioner guidance consistently shows that thresholds defined during planning, not during execution, are what make monitoring an actionable system rather than a paperwork exercise.
- Review risks and issues. Walk the risk register. Update probability and impact ratings. Confirm that mitigation actions are on track. Log any new issues that emerged since the last cycle.
- Decide and authorize corrective or preventive actions. For variances that exceed thresholds, determine the response: re-sequence activities, add resources, reduce scope, or escalate. Document the decision and, where the response affects the approved baseline, initiate a formal change request.
- Follow up and rebaseline if needed. Confirm that authorized actions were implemented. If an approved change materially alters the project, update the baselines so future variance calculations remain meaningful.
Startup checklist before your first monitoring cycle
Complete these before the project moves into execution:
- Approved scope, schedule, and cost baselines saved in a shared, version-controlled location
- KPIs selected and formulas agreed with the sponsor
- Data collection owners assigned for each KPI
- Variance thresholds documented (see examples below)
- Reporting templates built and distributed
- Review meeting cadence booked in team calendars
- Escalation path agreed with the sponsor in writing
Variance threshold examples
Meeting cadence
| Meeting type | Frequency | Primary purpose |
|---|---|---|
| Team standup | Daily | Surface blockers; confirm daily priorities |
| Status review | Weekly | Review KPIs; update risk register; assign actions |
| Steering/sponsor update | Monthly | Report on trends; seek decisions on escalated issues |
| Lessons learned | Per phase | Capture what to improve before the next phase |
Pro Tip: Keep the weekly status review to 45 minutes by circulating the dashboard 24 hours in advance. The meeting is for decisions, not data recitation.
What KPIs and EVM formulas should you track?
Earned Value Management (EVM) is the most widely used quantitative framework for project performance tracking. It combines scope, schedule, and cost into three core measurements and derives two performance indexes from them.
Core EVM KPI table
| KPI | Definition | Formula | When to use |
|---|---|---|---|
| Planned Value (PV) | Budgeted cost of work scheduled to date | From baseline | Always; it is the denominator for SPI |
| Earned Value (EV) | Budgeted cost of work actually completed | % complete × BAC | Always; the numerator for both indexes |
| Actual Cost (AC) | Real cost incurred to date | From accounting/timesheets | Always; denominator for CPI |
| Schedule Performance Index (SPI) | Schedule efficiency | EV ÷ PV | Every project with a time baseline |
| Cost Performance Index (CPI) | Cost efficiency | EV ÷ AC | Every project with a cost baseline |
| Schedule Variance (SV) | Schedule deviation in dollars | EV − PV | When you need a dollar-denominated gap |
| Cost Variance (CV) | Cost deviation in dollars | EV − AC | When you need a dollar-denominated gap |
| Variance at Completion (VAC) | Projected over/under-run | BAC − EAC | When forecasting final cost |
| Estimate at Completion (EAC) | Forecast final cost | AC + (BAC − EV) ÷ CPI | When current CPI is expected to continue |
BAC = Budget at Completion (total approved budget)
Worked example
A software project has a total budget (BAC) of $200,000. At the end of month three:
- PV: $80,000 (the baseline said $80K of work should be done by now)
- EV: $68,000 (only $68K of work has actually been completed)
- AC: $75,000 (the team has spent $75K so far)
SPI = EV ÷ PV = $68,000 ÷ $80,000 = 0.85
The project is completing only 85 cents of scheduled work for every dollar of time elapsed. It is running behind schedule.
CPI = EV ÷ AC = $68,000 ÷ $75,000 = 0.91
The project is getting $0.91 of value for every dollar spent. It is over-running on cost.
Both indexes are below 1.0 and below the amber threshold of 0.85 for SPI. That combination triggers an escalation to the sponsor under the threshold table above.
EAC = AC + (BAC − EV) ÷ CPI = $75,000 + ($200,000 − $68,000) ÷ 0.91 = $75,000 + $145,055 = $220,055
The project is forecast to cost approximately $220,000 against a $200,000 budget, a $20,000 overrun.
Pro Tip: Avoid using simple percent-complete estimates provided by team members as your EV basis. They are almost always optimistic. Use milestone-based measurement (0/100 or 20/80 rules) or deliverable acceptance as your completion signal instead. For employee performance tracking that feeds into project KPIs, the same principle applies: measure outputs, not effort.
Which tool categories accelerate accurate monitoring?
No single tool does everything well. The practical approach is to understand the categories, select one tool per category that fits your scale, and connect them through APIs or a shared data layer, leveraging technical SEO tools proven in marketing and analytics for automated monitoring and alerting.
Tool categories to consider
- Scheduling and EVM engines: Tools that hold your baseline schedule, calculate critical path, and compute EV metrics automatically when you log actuals. They are the backbone of schedule and cost monitoring.
- Issue and risk log tools: Structured registers that track probability, impact, owner, and mitigation status. A spreadsheet works for small projects; a dedicated module works better at scale.
- Project dashboards and BI: Visualization layers that surface SPI, CPI, open risks, and milestone status in real time. S-curves comparing planned vs. actual progress give sponsors an immediate read on schedule health.
- Time tracking tools: The source of actual hours, which feed both cost and resource utilization calculations. Accuracy here determines the accuracy of every EVM metric downstream.
- Configuration and version control: Tracks approved scope documents, baseline files, and change logs so you always know what the current approved version is.
- Reporting and BI platforms: Aggregate data from multiple sources into executive dashboards. Useful when the project spans multiple systems or teams.
Dashboard feature checklist
Before selecting or building a monitoring dashboard, confirm it can do the following:
- Display SPI and CPI with trend lines, not just point-in-time values
- Show milestone status (on track, at risk, delayed) at a glance
- Surface open risks above a defined impact threshold
- Flag budget consumption rate against the time-phased baseline
- Allow drill-down from summary to task level
- Support role-based views (team member, PM, sponsor)
- Send automated alerts when a KPI crosses a threshold
Automation patterns that reduce manual work
The highest-value automations in project monitoring follow a simple trigger-action pattern:
- Threshold breach → alert: When SPI drops below 0.90, the system notifies the PM and logs the event.
- New risk logged → review task created: When a risk is added with “high” impact, a review task is automatically assigned to the risk owner.
- Change request submitted → impact assessment task created: When a change request enters the system, an assessment task is routed to the relevant workstream leads.
- Weekly data snapshot → status report draft generated: Actuals pulled from time tracking and scheduling tools populate a report template automatically.
For SMB teams evaluating project management tools, the most important selection criterion is whether the tool supports a single source of truth. Disconnected spreadsheets and siloed apps force manual consolidation, which introduces lag and errors into every monitoring cycle. API availability and real-time data feeds are the two technical requirements that separate a genuine monitoring platform from a glorified task list.
How do you handle change control and scope management?
Monitoring triggers formal change control when performance trends fall outside acceptable variance. That is not optional. A PM who absorbs out-of-tolerance variances without a formal change request is allowing uncontrolled scope creep or budget blowout to accumulate silently.
End-to-end change control workflow
-
Request: Any stakeholder submits a change request using a standard form that captures the proposed change, reason, and requestor.
-
Impact assessment: The PM and relevant workstream leads assess the effect on scope, schedule, cost, quality, and risk. This step should have a defined turnaround time, typically 48–72 hours for minor changes.
-
Approval: The change is reviewed against the approval threshold matrix (see below) and approved, rejected, or deferred by the appropriate authority.
-
Implementation: Approved changes are added to the project plan, baselines are updated if required, and the team is notified.
-
Log: Every change request, regardless of outcome, is recorded in the change log with its decision and rationale.
Approval threshold examples
Red flags that require immediate escalation
- CPI or SPI below 0.85 for two consecutive reporting periods
- A critical-path activity delayed by more than five business days with no recovery plan
- A high-impact risk with no assigned owner or mitigation action
- A change request that would increase total project cost by more than 5% of BAC
- A stakeholder formally withdrawing support or raising a governance concern
Pro Tip: Log every rejected change request, not just approved ones. Rejected requests are evidence that scope was defended. They also protect the PM if a stakeholder later claims a feature was always in scope.
Who owns monitoring? Roles, RACI, and escalation paths
Monitoring without clear ownership is just reporting. The RACI below assigns accountability for the core monitoring activities so nothing falls through the gaps.
RACI for key monitoring activities
R = Responsible, A = Accountable, C = Consulted, I = Informed
Escalation ladder
- PM level: Handles all green and amber variances, minor change requests, and routine risk updates without escalation.
- Sponsor level: Engaged when a metric enters the red zone, when a material change request requires approval, or when a risk moves to “high” with no mitigation in place.
- Steering committee level: Convened for major changes, sustained red-zone performance over two periods, or a fundamental threat to project viability (budget exhaustion, regulatory issue, key resource loss).
Communication responsibilities
Stakeholder communication is not a courtesy; it is a monitoring output. The frequency and format should match the audience’s decision-making role:
- Team members: Daily standup or async update; focus on blockers and daily priorities.
- Project manager: Weekly KPI dashboard; full picture of schedule, cost, risk, and issues.
- Sponsor: Bi-weekly or monthly summary; trend lines, escalated items, and decisions needed.
- Steering committee: Monthly or milestone-based; executive summary with variance narrative and forward-looking risk assessment.
For distributed or remote teams, managing remote team workflows with clear async reporting structures reduces the communication overhead without sacrificing visibility.
What does a practical daily, weekly, and monthly cadence look like?
Cadence is where monitoring theory becomes operational reality. The table below gives you a starting template; adjust frequencies based on project risk and complexity.
Monitoring cadence and meeting templates
| Meeting | Frequency | Attendees | Primary agenda items |
|---|---|---|---|
| Daily standup | Daily | Team members, Team Lead | Yesterday’s progress; today’s plan; blockers |
| Weekly status review | Weekly (45 min) | PM, Team Leads | KPI review; risk register update; action item review; change log |
| Sponsor update | Bi-weekly or monthly | PM, Sponsor | Trend summary; escalated issues; decisions needed; next milestone |
| Steering committee | Monthly or milestone-based | PM, Sponsor, Steering members | Executive summary; major variances; change approvals; go/no-go decisions |
| Phase retrospective | End of each phase | Full team | What worked; what to improve; lessons for next phase |
Status report checklist (weekly)
Include these elements in every weekly status report:
- Project name, reporting period, and report date
- Overall RAG status (Red/Amber/Green) with one-sentence rationale
- SPI and CPI values with trend direction (up, flat, down)
- Milestone status: completed this period, due next period, at risk
- Top three open risks with current probability/impact and mitigation status
- Open issues requiring PM or sponsor decision
- Change log summary: requests submitted, approved, rejected this period
- Actions from last meeting: owner, due date, status
Essential dashboard widgets by audience
Team level: Task completion rate, open blockers, days until next milestone, individual workload vs. capacity.
PM level: SPI and CPI trend charts, milestone Gantt with critical path highlighted, risk heat map, budget burn rate vs. time-phased baseline, open change requests.
Sponsor level: Overall RAG status, cost forecast vs. budget (EAC vs. BAC), schedule forecast vs. baseline, top three risks, key decisions pending.
Business reporting tools that support role-based views let each audience see exactly what they need without requiring the PM to build three separate reports manually.
What does empirical research say about corrective actions and variation?
The practical heuristics below are grounded in research, not convention. They change how you make decisions under pressure.
Budget-release timing and corrective-action policy
An empirical study calibrated against 97 real projects found that budget-release timing and the choice of corrective-action policy, specifically whether to crash activities (add resources to shorten duration) or fast-track them (overlap sequential activities), materially affect control outcomes. Critically, the effectiveness of each policy depends on the project’s network topology and activity-duration dependencies. There is no universal best answer.
The practical heuristics that follow from this research:
- Crash when: Activities are on the critical path, have high resource flexibility, and the network has few parallel paths. Adding resources to a bottleneck task with clear scope boundaries tends to recover schedule without introducing rework.
- Fast-track when: Activities have low interdependency risk and the team has capacity to manage parallel workstreams. Fast-tracking on tightly coupled activities increases rework risk and can make the schedule worse.
- Release budget incrementally rather than front-loading it. Projects that release budget in phases tied to milestone completion show better cost control than those that make the full budget available at the start.
Common-cause vs. special-cause variation
PMI’s guidance draws a clear line between common-cause variation (the normal statistical noise in any project) and special-cause variation (a signal that something structurally different is happening). Acting on common-cause variation wastes time and can destabilize a project that is actually performing within normal bounds. The discipline is in distinguishing the two.
A practical rule: if a metric fluctuates within your green zone over three consecutive periods, it is almost certainly common-cause. If it moves outside the green zone once and stays there, or moves sharply in a single period, treat it as special-cause and investigate.
Automation use cases that operationalize these heuristics
An integrated platform can encode these heuristics as automated rules:
- Consecutive-period alert: If SPI or CPI stays below 0.90 for two reporting periods, automatically create a corrective-action task assigned to the PM and notify the sponsor.
- Budget burn rate alert: If actual spend exceeds the time-phased baseline by more than 5% in any two-week window, trigger an impact assessment workflow.
- Risk escalation trigger: If a risk’s impact score crosses a defined threshold, automatically route it to the sponsor’s review queue.
Pro Tip: Set your automation thresholds slightly tighter than your escalation thresholds. An automated alert at CPI 0.90 gives you time to investigate before the metric hits the 0.85 escalation trigger. The gap between alert and escalation is your response window.
The part of monitoring most teams get wrong
Most teams treat monitoring as a reporting obligation. They collect data, build a status report, send it to the sponsor, and move on. The report becomes a ritual rather than a decision tool, and the project drifts.
The real function of monitoring is to compress the time between a variance appearing and a corrective action being authorized. Every day that passes between detecting a problem and acting on it costs more than the day before. A CPI of 0.87 in week six is a manageable problem. The same CPI in week twenty, unaddressed, is a project in serious trouble.
Two quick wins for teams that are struggling with this right now:
- Replace percent-complete estimates with milestone-based completion. Assign each task a binary status: either the defined deliverable is accepted, or it is not. This single change eliminates the most common source of false-positive progress data and makes your EV calculations trustworthy.
- Predefine one escalation trigger with the sponsor before the next monitoring cycle. Agree on a specific threshold, say CPI below 0.90 for two consecutive weeks, that automatically puts an item on the sponsor’s agenda. This removes the political friction of deciding whether a variance is “bad enough” to escalate and makes the PM’s authority to act explicit.
Neither of these requires new tools or a process overhaul. Both can be in place before your next weekly review.

How Manaxo helps you put monitoring into practice
Running a monitoring system across disconnected spreadsheets, email threads, and separate scheduling tools is where most of the manual work lives. The PM spends hours consolidating data that should already be in one place.
Manaxo’s integrated project management platform connects scheduling, cost tracking, risk logs, and team reporting in a single cloud-based environment. When a team member logs hours, the cost and EV calculations update automatically. When a KPI crosses a threshold, an alert fires and a corrective-action task is created without manual intervention. A change request submitted in the system routes to the right approver based on the threshold matrix you configure at project initiation.
For SMBs that need project visibility without a dedicated PMO, that kind of automation turns a five-step manual process into a single dashboard view. Sponsors get role-based reports without the PM rebuilding the same data three different ways.

See what the platform can do for your projects at Manaxo’s pricing page and start a free trial.
Sources
- How do you know the status of your project? — PMI Learning Library
- Project monitoring and control with an empirically grounded budget-release model — ScienceDirect
- Monitoring and Controlling in Project Management — Project Management Formula
- Project Monitoring & Control — ProjectEngineer



