Weighted Project Progress & Control Tower

A busy dashboard can still be wrong

A capstone has twenty tracked tasks. Twelve small documentation tasks are complete, so a task-count dashboard says 60% complete. Yet deployment rehearsal, rollback evidence, accessibility QA, integration and final review are still open. Treating every task as equal makes the project look healthier precisely when the high-consequence work is unfinished.

This lesson builds Weighted Learning-Project Progress & Control Tower Contract v1. The contract freezes a declared baseline, assigns a planned weight to each work package before the outcome is known, requires visible completion evidence before weight can be earned, separates progress from schedule/effort variance, exposes critical milestones and risk/forecast state, and records approved baseline revisions without rewriting earlier history.

The strongest successful state is CONTROL_TOWER_REVIEW_REQUIRED. The control tower organizes evidence for a human planning decision; it does not mutate a live project baseline or promise a delivery date.

For: learning-platform engineers, project-control owners, delivery leads, analytics engineers and reviewers. Not for: task-count vanity metrics, hidden reweighting, invented completion evidence, health/workload diagnosis, or contractual delivery commitments.

Route orientation and ownership boundary

MKN-015 owns weighted project-progress evidence and control-tower state. MKN-013 is the hard prerequisite and MKN-014 is the soft prerequisite. MKN-014 owns learning-fatigue/anti-overlearning signals; MKN-016 owns probabilistic effort/ETA. This lesson may consume bounded evidence from those lessons, but it must not diagnose learner health or convert a progress view into an ETA promise.

Foundation learners should follow one frozen baseline from planned weight to earned weight. Repair learners should stop at the first missing evidence dimension. Experienced learners should defend the weight basis, variance interpretation, critical-milestone treatment, change-control revision and historical reconciliation.

Checkpoints: F1 explain why 12/20 tasks is not authoritative progress; F2 reject an attempt to reweight unfinished work after seeing poor progress; F3 approve a scope change, create a new baseline revision and preserve the old percentage as history.

Mental model: baseline → evidence-backed earning → variance → control tower → governed rebaseline

Use this flow:

approved scope → declared weight basis → frozen planned weights → completion evidence → earned weight → weighted progress + schedule/effort variance → milestone/risk/forecast state → human review → governed change request → new baseline revision with old history retained

planned_weight is baseline value assigned before the result is known. earned_weight is recognized only when the work package meets its completion rule and evidence exists. Raw task count is a descriptive statistic, not the progress authority.

Schedule variance and effort/cost variance answer different questions from weighted progress. A project can have a respectable earned percentage and still be late on a critical milestone; or it can be ahead of schedule while consuming much more effort than planned. The control tower keeps those signals decomposed so a single green percentage cannot hide a red milestone.

When scope changes, the old baseline remains immutable history. The approved change creates a new baseline_revision; prior reports are not recalculated as though the new scope had always existed.

Foundation contract: seventeen frozen evidence dimensions

The frozen dimensions are project_id, baseline_id, work_package_id, scope_ref, weight_basis, planned_weight, planned_date, actual_completion_evidence, earned_weight, actual_effort_or_cost, schedule_variance, critical_milestone, risk_state, forecast_state, change_request_ref, baseline_revision, and control_owner.

Minimum invariants:

1. Project, baseline and work-package identity are explicit.
2. Weight basis is declared before earned progress is observed.
3. Planned weights reconcile to the baseline total; they are not silently edited after performance is known.
4. Earned weight cannot exceed planned weight.
5. Earned weight greater than zero requires visible completion evidence.
6. Raw task-count progress is never substituted for weighted progress.
7. Schedule variance and effort/cost evidence remain separate from earned progress.
8. Critical milestone state is visible even when many small tasks are complete.
9. Risk and forecast state remain explicit; missing evidence is not converted to green.
10. Scope-changing requests require approval and a new baseline revision.
11. Revision history preserves the prior baseline and prior progress value.
12. A named control owner and provenance make the bounded decision reproducible.

Deep explanation: borrow measurement discipline, not formal compliance claims

Integrated performance measurement — FACT. The U.S. Department of Energy describes Earned Value Management as integrating scope, schedule and cost/technical accomplishment so current performance can be assessed objectively and future performance can be informed by trends. DOE also emphasizes approved performance baselines and critical milestones. This lesson borrows that measurement discipline for a bounded learning project.

Planned, earned and actual signals — FACT. DOE EVM material distinguishes the value of planned work, the value of work actually completed, and actual cost; comparing them exposes schedule and cost variance. MAKNOW may use non-currency weight points, so the unit is local design rather than a claim of formal EVMS compliance.

Weighted progress — INFERENCE. For a learning capstone, declared weight can represent baseline contribution/risk-bearing importance rather than raw task count. The important property is not the particular numbers but that the basis is declared, reviewable and stable within a baseline revision.

Control-tower gates — DESIGN. MAKNOW requires every reported percentage to reconcile to work-package evidence, revision history and explicit variance/risk/forecast states. Thresholds and labels are local product design, not DOE mandates.

Worked examples: the same project can be 60% by count and 24% by evidence-bearing weight

Example A — baseline. Twelve documentation tasks are complete. Each carries two planned-weight points, so task count is 12/20 = 60%, while earned weight is only 24/100 = 24%. Deployment rehearsal (15), rollback evidence (12), accessibility QA (12), integration (10) and security QA (9) remain open. The control tower reports the weighted percentage, shows task count only as context, and raises a critical-work alert.

Example B — invalid shortcut. After seeing 24%, a team reduces the weights of open critical work and increases the weights of already-complete documentation without an approved scope change. The arithmetic may produce a nicer number, but the baseline has been rewritten after performance was observed. State: HOLD_BASELINE_INTEGRITY.

Example C — governed change. A product feature is removed and a mandatory security review is added. The owner approves CR-017, creates baseline revision 2, recalculates planned weights for the new scope, and retains revision 1 with its historical 24% weighted progress. The new percentage is allowed to differ because the denominator belongs to a new approved baseline, not because history was edited.

Failure modes and the safe states they trigger

• Task-count inflation: many tiny tasks are closed while critical work remains. Keep CONTROL_TOWER_REVIEW_REQUIRED and surface TASK_COUNT_OVERSTATES_PROGRESS.
• Reweight after observing performance: HOLD_BASELINE_INTEGRITY.
• Earned weight without completion evidence: HOLD_COMPLETION_EVIDENCE.
• Earned weight greater than planned weight: HOLD_EARNED_WEIGHT.
• Schedule/effort variance evidence missing: HOLD_VARIANCE_EVIDENCE.
• Scope change not approved: HOLD_CHANGE_CONTROL.
• Approved scope change but baseline revision not advanced/history not preserved: REBASELINE_REQUIRED.
• Risk/forecast state absent: HOLD_FORECAST_STATE.
• Critical milestone identity missing: HOLD_MILESTONE_EVIDENCE.
• Control owner absent: HOLD_CONTROL_OWNER.
• Provenance absent: HOLD_AUDIT_PROVENANCE.

A plausible-looking percentage does not repair a broken evidence chain.

Alternatives and trade-offs

Equal task count. Cheap and easy to explain, but only defensible when work units are genuinely comparable. It is dangerous when ten trivial tasks can outweigh one critical deliverable.

Fixed weighted milestones. Better for heterogeneous work because weight is declared in advance, but the weight basis must be reviewed and change controlled.

Binary 0/100 earning. Strong against subjective percent-complete inflation, but coarse for long work packages. If partial earning is allowed, its objective rule must be explicit before execution.

Effort-weighted progress. Useful when effort is a stable proxy for scope contribution, but effort spent is not automatically value earned. A hard task can consume effort and still fail its completion evidence.

Control-tower composite score. Tempting for executive simplicity, but collapsing scope, schedule, effort, risk and milestone state into one synthetic score can hide the exact signal that needs action. Prefer decomposed evidence plus a bounded review state.

Experienced bridge: four things worth defending

First, defend baseline semantics, not the aesthetic of the dashboard. The denominator must mean the same thing throughout a revision.

Second, defend earning rules. Work earns value because defined completion evidence exists, not because a person typed 90%.

Third, defend variance decomposition. A single progress number cannot answer whether the team is late, overspending effort or carrying unresolved risk.

Fourth, defend history under change. Revision 2 may legitimately produce a different weighted percentage, but revision 1 must remain reconstructable. That is the difference between governed rebaselining and retroactive storytelling.

Guided and independent practice

Guided: open lab://MKN-015/MKN-015-LAB1. Run the baseline fixture. Explain why raw task count is 60% while evidence-backed weighted progress is 24%, then identify which critical milestones keep the state at human review.

Repair: mutate one dimension at a time: remove completion evidence, make earned weight exceed planned weight, erase variance evidence, submit an unapproved change, keep the old revision after an approved scope change, remove risk/forecast state, remove owner or remove provenance. Name the first safe state and the smallest repair.

Independent: use the transfer fixture. A planned feature is removed and a mandatory security review is added. Create revision 2, retain revision 1 history, and recompute the new weighted view without copying the baseline answer.

Verification evidence: what a reviewer must be able to reconstruct

A reviewer must reconstruct the project/baseline identity, every work package and scope reference, the declared weight basis, planned weights, completion evidence, earned weights, actual effort/cost evidence, schedule variance, critical milestone status, risk/forecast state, change request, baseline revision, owner and provenance.

The reviewer should independently recalculate both raw task-count progress and weighted progress. If the dashboard says 60% while the weighted evidence says 24%, both can be mathematically correct but only the latter is authorized as project progress under this baseline.

For a revised baseline, the reviewer must also recover the pre-change baseline and its historical progress. If revision 1 has disappeared or prior percentages have been silently recomputed, the change-control chain is invalid.

Assessment and transfer

S1: explain why completed-task ratio is not authoritative progress when work packages have unequal baseline value. S2: build Weighted Learning-Project Progress & Control Tower Contract v1 for the baseline fixture and reconcile raw count, weighted progress, variance and critical state. S3: reweight unfinished work after seeing poor progress; identify the violated evidence boundary and safe state. S4: remove one planned feature, add a mandatory security review, approve the change and create revision 2 while preserving revision 1 history.

Blocking misconception: “If more than half the tasks are closed, the project is more than half complete.”

AI may organize synthetic evidence and perform deterministic calculations. It may not invent completion evidence, redefine weights after results, approve a change request, mutate a live baseline or claim external delivery commitment.

References, freshness and authority boundary

• DOE Earned Value Management — FACT: EVM integrates scope, schedule and cost/technical accomplishment, supports objective assessment of current performance and informs future performance.
• DOE EVMS implementation guidance — FACT: approved baselines, variance/trend analysis and baseline stability are part of governed project-performance analysis.
• MAKNOW inference/design: non-currency planned-weight points, specific hold states, alert labels and revision workflow are local design choices.

Freshness was rechecked on 2026-09-13 against the current DOE project-management pages. Recheck by 2027-01-15 or earlier if DOE guidance materially changes. The lesson does not claim formal EIA-748/DOE EVMS compliance.