Lesson 2 — Monitoring and Control¶
At a glance
- Module: 11 — Metrics, Monitoring & Control
- Level: Advanced
- Estimated time: 40 minutes
- Example project: the analytics dashboard
Learning objectives¶
By the end of this lesson you should be able to:
- Describe the monitoring and control loop and set meaningful tolerances.
- Choose progress measures that resist the failures of percentage complete.
- Distinguish corrective action from replanning and decide which is required.
- Use flow measures — work in progress, cycle time, throughput — as leading indicators.
Prerequisites¶
Introduction¶
Measuring is not controlling. A metric that nobody acts on is a cost. Control is the loop that connects a measurement to a decision and a decision to an effect, and it runs continuously for as long as the project does.
This lesson is about making that loop work: what to compare, when to escalate, what action to take, and how to see trouble early enough for the action to be cheap.
1. The control loop¶
- Compare actual against the baseline.
- Decide whether the difference exceeds tolerance.
- Act — correct, replan, or accept.
- Verify that the action produced the intended effect.
The fourth step is the one most often skipped, and its absence is expensive: a corrective action that was never verified is indistinguishable from no action, so the same deviation is rediscovered later with less time to fix it.
Tolerances make the loop workable. A tolerance is the permitted deviation before escalation. A sponsor might allow ±5% on cost and ±3 days on any milestone. Tolerances enable management by exception: the project manager acts within them and escalates beyond them. Without tolerances, every small deviation either escalates — exhausting the sponsor's attention — or is silently absorbed, which destroys the meaning of the baseline.
2. Progress measures that survive contact¶
| Measure | Strength | Weakness |
|---|---|---|
| Percent complete | Intuitive; cheap | No evidence required; persistently optimistic |
| Milestone progress | Binary and verifiable | Coarse; no early warning |
| Completed items | Verifiable; counts evidence | Needs a stable definition of "item" |
| Burn-up / burn-down | Shows rate and trend visually | Needs a consistent unit |
| Cumulative flow | Exposes queues and WIP growth | Needs disciplined board states |
| Earned value | Combines scope, schedule, and cost | Needs a defensible completion measure |
Percent complete deserves its reputation. It requires no evidence, it is systematically optimistic early, and it tends to stall near 90% for a long time — which is precisely when a warning would be most useful.
Two refinements make counting measures more informative. Use 0/100 (credit only on completion) or 50/50 (half at start, half at completion) rather than a subjective percentage. And watch cycle time — the elapsed time from starting an item to finishing it. A rising cycle time with steady throughput means items are spending longer in the system, which shows up before the delivery date moves.
3. Corrective action or replanning¶
These are different responses to different situations, and confusing them causes either constant replanning or a plan that no longer describes reality.
| Response | What changes | When |
|---|---|---|
| Corrective action | Execution only; the plan stands | A deviation is recoverable with existing scope and resources |
| Replanning | The plan itself — scope, sequence, resources, dates | Forecast finish or cost exceeds tolerance, or approved change alters the baseline |
| Accept | Nothing; the deviation is absorbed | The deviation is within tolerance and not worth the cost of recovery |
Triggers for replanning, agreed in advance, remove panic from the decision: the forecast exceeds tolerance; a materialised risk has schedule impact; an approved change alters scope; or a checkpoint reveals the plan was based on a false assumption.
4. Flow as an early warning system¶
Delivery problems almost always appear first as queues, long before they appear as dates.
| Signal | What it suggests | Cheap response |
|---|---|---|
| Work in progress rising, throughput flat | Work is arriving faster than it finishes | Limit WIP; find the blocking stage |
| Cycle time rising, throughput steady | Items wait longer; a stage is saturated | Add capacity at the bottleneck, not at the start |
| Items ageing in one column | A specialist or approval gate is saturated | Second reviewer, or parallel approval |
| Large batch sizes | Long feedback delay, expensive integration | Reduce batch size |
| Rework rate rising | Quality was traded away earlier | Reinstate prevention; review scope pressure |
The value of these signals is that they are leading: they move while there is still slack in the schedule. A delivery date moving is a lagging indicator, and by the time it moves the options are usually expensive.
Key terms¶
| Term | Meaning |
|---|---|
| Tolerance | Permitted deviation before escalation |
| Management by exception | Acting only on deviations beyond tolerance |
| Corrective action | Fixing execution without changing the plan |
| Replanning | Changing the plan itself |
| Baseline | The approved version against which variance is measured |
| Work in progress (WIP) | Work started but not finished |
| Cycle time | Elapsed time from starting to finishing an item |
| Throughput | Items completed per unit of time |
| Cumulative flow | A chart of items in each state over time |
Worked example¶
Task: control the illustrative analytics dashboard release during weeks 3–8. Figures are invented for teaching.
Step 1 — Set tolerances before they are needed. Cost ±5%; milestone ±3 days; quality: no release with an open severity-1 defect. Agreed in writing with the sponsor, so escalation is a rule rather than a judgement about whether bad news is welcome.
Step 2 — Replace percentage complete. The team reports completed stories verified by acceptance, plus a cumulative flow view. WIP is limited to three items in progress.
Step 3 — Read the leading signal. In week 4, WIP is at its limit and throughput is flat: three stories have been "in review" for seven days. No milestone has moved. The queue has, and the queue is visible earlier. The cause is a single reviewer. The response — a second reviewer — costs nothing on the critical path.
Step 4 — Verify the action worked. In week 5, items in review fall from three to one and throughput rises to four per week. The action is verified, not assumed. Had it not worked, the real constraint was elsewhere, and an unverified action would have left the project waiting for a different fix.
Step 5 — Identify a deviation beyond tolerance. At week 8, earned value gives SPI 0.75 and CPI 0.86 — a forecast cost overrun of about 17%, beyond the ±5% tolerance.
Step 6 — Choose the response. The cause matters. Investigation finds two distinct contributors: an external dependency slip (the interface delay), which is a schedule problem with a schedule response, and a sustained rework rate in the charting module, which is a quality problem caused by pressure applied in week 5. That pressure was a corrective action that worked in the short term and created the rework. It is a real pattern, and recording it is how the next project avoids it.
Step 7 — Replan, and say what changed. Rather than repeat the earlier pressure, the plan changes: the export feature moves out of the release and the team returns to reviewing charting changes. The baseline is updated, the change is communicated, and the change log records the decision. This is replanning, not corrective action, and it is correct to say so.
Step 8 — Escalate on the trend, not the cliff. SPI moved 0.95 → 0.88 → 0.75 across three periods. The trend was visible in week 6, when a decision was still cheap. Reporting the trend is the single highest-value habit in project control.
Common misconceptions¶
“Monitoring is reporting”
Reporting tells people what happened. Monitoring is the comparison against plan, and control is the action that follows. A project that reports diligently and acts on nothing is not controlled.
“All deviations should be corrected”
Correction costs something — money, attention, or quality somewhere else. A deviation within tolerance is often best accepted and watched, and saying so explicitly is better than quietly absorbing it.
“Adding pressure fixes a delay”
Pressure converts a schedule problem into a quality problem, which usually produces a worse schedule problem later. Solve the queue, not the calendar.
Practical activity¶
Build a control loop. For one example project:
- Set tolerances for cost, schedule, and quality, and state who acts within each.
- Choose three progress measures, at least one of which is a leading flow measure, and justify the choice against percentage complete.
- Invent one week's data showing a deviation, and decide whether it requires corrective action, replanning, or acceptance — and say why.
- Define the verification step: how will you know the action worked?
- Write the escalation as a trend rather than a snapshot.
What "good" looks like: tolerances set before any deviation exists, a leading measure chosen deliberately, a correct distinction between corrective action and replanning, and a verification step that could actually fail.
Self-assessment¶
- Why must tolerances be agreed with the sponsor in advance?
- How can rising cycle time warn you earlier than a slipping milestone?
- A deviation of 4% on cost is reported, and tolerance is ±5%. What are the legitimate options?
-
What is the difference between corrective action and replanning?
-
Apply it — progress reporting. For three consecutive weeks a team reports the work package as “90% complete”, while the list of unstarted acceptance tests is unchanged. Cost and schedule are inside their tolerances, so nothing has been escalated.
Hint: A strong answer names the measure that is failing you, how you would replace it, and whether this is corrective action or replanning.
Show answers
- Because a tolerance negotiated at the moment of a deviation is negotiated under pressure, by whoever feels most urgency. Agreeing it in advance makes escalation a rule rather than a judgement about whether bad news is welcome — and it defines what "in tolerance" means.
- Because cycle time measures how long work spends in the system, so it responds to queues and bottlenecks before those queues have consumed enough time to move a milestone date. By the time a milestone moves, the delay has already happened.
- Act within tolerance without escalating — but record it, watch the trend, and correct it if correction is cheap and safe. Or accept it and note the residual. What is not legitimate is to ignore it silently and let it become the first of a series that pushes the project beyond tolerance collectively.
- Corrective action changes only execution; the plan and baseline remain. Replanning changes the plan itself — scope, sequence, resources, or dates — and updates the baseline accordingly.
- Percentage complete is the measure failing here, exactly as the lesson warns: it is unverifiable, it is defined by the person doing the work, and 90% is the number a team reports when the remaining work is the part it does not want to start. Replace it with something countable — acceptance criteria met out of the total, or work packages closed out of those planned — and add a leading indicator such as the count of blocked items or the age of the oldest open item. The flat test list is the real signal, and it should have been escalated earlier, because a measure that cannot move is not evidence of progress. Whether this is corrective action or replanning depends on the cause: if the remaining work is simply slow, replan the remaining sequence and dates (a baseline change at the agreed authority); if the scope grew without anyone noticing, that is a change-control matter. In tolerance on cost and schedule does not mean no action — it means no escalation.
Summary¶
- Control is compare, decide, act, and verify; the verification step is the one usually skipped.
- Pre-agreed tolerances make management by exception possible and give the baseline meaning.
- Prefer verifiable progress measures, and treat percentage complete with suspicion.
- Flow measures — WIP, cycle time, throughput — warn earlier than dates do.
- Distinguish corrective action from replanning, and plan triggers for the latter in advance.
Further learning¶
- Lesson 3 — Change and Configuration Management covers the control that protects the baseline from uncontrolled change.
- A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — monitoring and controlling project work.
- The Principles of Product Development Flow, Donald G. Reinertsen — on queues, batch size, and WIP.
- Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble, and Gene Kim — cycle time and delivery performance.
Next¶
Continue to Lesson 3 — Change and Configuration Management.