7.1 Monitor and Control Project Work

7.1 Monitor and Control Project Work
Inputs Tools & Techniques Outputs

Ongoing oversight of the project to compare actual results to the plan, analyze variances and trends, forecast outcomes, recommend and route changes, and communicate performance so timely corrective and preventive actions can be taken.

Purpose & When to Use

This process keeps the project on course. It gathers performance data, turns it into insights, and drives decisions about corrective actions, risk responses, and change requests. Use it throughout the project, from early execution until closure, and run it on a regular cadence or whenever significant events occur.

  • Confirm work aligns with the approved plan and baselines.
  • Detect variances early and understand their causes.
  • Forecast cost, schedule, and benefit outcomes to support decisions.
  • Recommend actions and route changes through the formal change process.
  • Provide clear performance reporting to stakeholders.

Mini Flow (How It’s Done)

  • Collect current results and observations from execution as raw data.
  • Convert data into information by analyzing scope, schedule, cost, quality, risks, and issues.
  • Compare actuals to baselines; calculate key indicators and trends.
  • Forecast outcomes, such as estimate at completion and expected finish dates.
  • Identify needed actions: corrective, preventive, defect repair, or risk response adjustments.
  • Prepare performance reports that summarize status, variances, forecasts, and recommendations.
  • Submit change requests for any updates that affect baselines or approved plans.
  • After approval, coordinate implementation and update plans and project documents.
  • Communicate results and decisions to stakeholders and capture lessons learned.

Quality & Acceptance Checklist

  • All KPIs and thresholds reviewed; outliers explained with documented root causes.
  • Variance and trend analyses completed for scope, schedule, cost, quality, and benefits.
  • Forecasts updated using consistent methods and current data.
  • Recommended actions are specific, owned, and time-bound.
  • Any baseline or scope change is supported by a submitted and approved change request.
  • Risk and issue logs are current, with priorities, owners, and due dates.
  • Approved changes traced to implementation and verified for effectiveness.
  • Deliverable status aligns with acceptance criteria and quality standards.
  • Stakeholders received clear reports appropriate to their information needs.
  • No baselines updated without formal approval; all updates are version-controlled.

Common Mistakes & Exam Traps

  • Confusing monitoring with doing the work; executing tasks belongs to directing and managing the work.
  • Bypassing the change process; do not rebaseline or adjust scope without formal approval.
  • Reporting data without analysis; exams expect variance, trend, and forecast insights, not raw numbers.
  • Focusing only on schedule and cost; include scope, quality, risks, issues, benefits, and constraints.
  • Implementing fixes immediately; first analyze impact and submit a change request when baselines are affected.
  • Mixing up performance artifacts: data is raw, information is analyzed, reports are formatted for decisions.
  • Ignoring emerging risks or stale issue logs; these must be reviewed and updated regularly.

PMP Example Question

A project shows CPI = 0.80 and SPI = 1.05. The sponsor asks to remove a feature to recover cost. What should the project manager do next?

  1. Submit a change request and evaluate the impact on scope, cost, schedule, and benefits.
  2. Rebaseline the project to reflect the removed feature.
  3. Crash critical path activities to reduce total cost.
  4. Update the risk register only, since schedule is ahead.

Correct Answer: A β€” Submit a change request and evaluate the impact on scope, cost, schedule, and benefits.

Explanation: Scope reductions require the formal change process and impact analysis before rebaselining or implementing. Crashing targets schedule, not cost, and rebaselining comes only after approval.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Seven sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Build the Sprint Reporting System, Not Another Prompt

AI Systems with Claude is our own course for Scrum Masters and Agile Project Managers, taught against one running project across seven sections. You build five working systems and keep them: the sprint report machine, the retro intelligence system, the stakeholder comms engine, the backlog health monitor, and the risk and dependency tracker. Direct from HK School of Management, not on Udemy.

See What Is Included