---
title: "ProjectOps"
slug: projectops
category: product
term_status: ambiguous
evidence_status: verified
summary: "ProjectOps has no settled meaning. On this page it is the operating discipline of running one bounded project under control: agreed baselines for scope, schedule and cost, tolerances, measured variance, honest forecasts and decisions taken at the right level."
audience: [Beginners, Project managers, PMO analysts, Technical leads who run projects, Sponsors and leaders]
last_verified: 2026-10-23
key_takeaways:
  - "\"ProjectOps\" is not a recognised discipline: the nearest uses are Microsoft's Dynamics 365 Project Operations (2020) and a small HubSpot app. The practice behind it, project management and project controls, is established (PMBOK Guide, PRINCE2, ISO 21502)."
  - "A project is controlled through baselines (scope, schedule, cost), tolerances that say who may decide what, and forecasts compared with those baselines; status reports are outputs of that system, not opinions."
  - "The critical path is the longest chain of dependent work; it only means something if the schedule logic is complete, which is why missing links and hard date constraints are the first things to check."
  - "Earned value turns progress into money units: CPI and SPI show efficiency, a range of estimates at completion shows where the project is heading, and earned schedule avoids SPI's drift back to 1.0 on a late project."
  - "A single-point plan built from most-likely durations is usually optimistic; a schedule risk analysis gives a date with a stated confidence, and reference-class data checks the whole estimate from outside."
  - "Status integrity is a control in its own right: define RAG rules in advance, separate self-reported from independently assured ratings, and make bad news cheap to report."
  - "Do not wrap ongoing product work in a project frame: when there is no definable end, fund and run a durable team instead and keep project control for the bounded parts."
related: [agileops, portfolioops, productops, releaseops, procurementops, bizops]
---

## What ProjectOps is

### In 30 seconds

**ProjectOps** has no agreed definition. **On this page it means the operating discipline of running one bounded project under
control:** agreeing what will be delivered, by when and for how much (the baselines); deciding in advance how far each can move
before someone more senior must decide (the tolerances); measuring progress; forecasting honestly; and escalating early when a
forecast breaks a tolerance. It is project management plus the project controls (schedule, cost, risk, change) that make it
measurable.

::: note Three uses of the label
1. **A product name.** Microsoft's *Dynamics 365 Project Operations*, announced for general availability on 1 October 2020,
   "connects sales, resourcing, project management, and finance teams in a single application":[^d365ga][^d365] the commercial
   back office of firms that sell projects.
2. **A small app.** "ProjectOps" by Atlantic Ops is a HubSpot marketplace app that turns "HubSpot Projects into a complete project
   management workspace"; its listing showed fewer than ten installs when checked.[^hubspot]
3. **Plain description.** "Project ops" loosely names whoever runs project mechanics: a project management office (PMO),
   project controls, or the coordinator who keeps plans and logs current.

This page takes the third reading and teaches the established practice under its standard names: an **editorial
distinction** of this Atlas, not an industry definition. Microsoft's product appears in the [tooling landscape](#tooling-landscape).
:::

**For** project managers, PMO analysts, technical leads, sponsors who take escalated decisions, and beginners.

### At a glance

| Item | Summary |
|---|---|
| Term status | **Ambiguous.** No body, standard or certification uses "ProjectOps"; the practice is established as project management (PMBOK Guide, PRINCE2, ISO 21502). |
| Goal | Deliver an agreed outcome within agreed tolerances, and surface early, with options, when that is no longer likely. |
| In scope | Life cycle and stage gates; the triple constraint and tolerances; work breakdown structure (WBS); schedule logic and critical path; schedule risk; RAID log; change control; earned value; status reporting; stakeholders; the project PMO; tools. |
| Out of scope | Choosing and funding projects → [PortfolioOps](../portfolioops/); team cadence and flow → [AgileOps](../agileops/); product discovery → [ProductOps](../productops/); contracts → [ProcurementOps](../procurementops/); company cadence → [BizOps](../bizops/). |
| Prerequisites | Spreadsheets, percentages, basic arithmetic. Python 3 helps for the labs. |
| Key outputs | Charter, WBS, logic-linked schedule, cost baseline, tolerance table, RAID and change logs, stakeholder register, status and exception reports, closure report. |

### The problem it solves

Projects fail in ways that are predictable in kind, if not in size. Bent Flyvbjerg calls the record of large projects the
"iron law of megaprojects": "Over budget, over time, over and over again."[^flyvmega] In 5,392 IT projects, he and co-authors found
that cost overruns follow a power law: many small overruns and a "fat tail" of extreme ones, which managers who assume a
near-normal distribution grossly underestimate.[^flyvit] Two mechanisms recur:

- **Problems are found late.** GAO cites studies of more than 700 US defence programmes showing "limited opportunity for getting a
  program back on track once it is more than 15 percent to 20 percent complete".[^gaocost] Control that starts halfway is
  mostly reporting.
- **Bad news travels slowly.** Research on "runaway" information systems projects describes "the reluctance of organizational
  members to transmit negative information concerning a project and its status" (the "mum effect").[^mum]

| Operating reality | Without project control | With project control |
|---|---|---|
| Scope | Described in a slide; argued about at acceptance | WBS and dictionary; anything not in it is not in the project |
| Dates | A finish date chosen first, plan drawn backwards | Logic-linked schedule; critical path and float known |
| Progress | "80% done" for weeks | Earned value from objective measures |
| Problems | Raised when the date is missed | Forecast breach of a tolerance escalated with options |
| Change | Absorbed silently, then blamed | Logged, assessed for impact, decided at the right level |

### What ProjectOps is not: naming and boundaries

- **Not a product or a tool.** Microsoft Project, Jira or Dynamics 365 host plans; none decides scope or tells the sponsor bad news.
- **Not portfolio management.** Choosing *which* projects to fund and stopping the weakest belongs to
  [PortfolioOps](../portfolioops/). This page starts once a project is mandated and ends at closure and benefits handover.
- **Not agile delivery mechanics.** Scrum events, Kanban flow metrics and team retrospectives belong to [AgileOps](../agileops/).
  A project can use them inside its stages; this page covers the control layer around them.
- **Not operations of a running service.** Operations repeat; a project ends. When work has no definable end, a project frame
  is usually the wrong container (see [when not to use](#when-to-use-and-when-not-to-use)).

## Where it comes from and where it sits

### Origins and evolution

The label is new; the practice is old.

| When | Idea or event |
|---|---|
| Late 1950s | Critical path method (CPM) developed by Morgan R. Walker (DuPont) and James E. Kelley Jr. (Remington Rand); PERT at about the same time by Booz Allen Hamilton and the US Navy[^wikicpm] |
| 1989, 1996 | The UK government adopts PRINCE for IT projects (1989); PRINCE2 launched in 1996[^prince2] |
| 1998 | ANSI and the Electronic Industries Alliance establish a national standard for earned value management systems, EIA-748[^gaocost] |
| From 2003 | Walt Lipke's earned schedule derives time-based schedule indicators from earned value data[^lipke] |
| 2005–2006 | Flyvbjerg and colleagues outline reference class forecasting (2005), building on Kahneman and Tversky's work; a 2006 paper reports its first use in practice[^flyvrcf] |
| 2020 | ISO 21502 replaces ISO 21500:2012 as guidance on project management;[^iso21502] Dynamics 365 Project Operations announced for October[^d365ga] |
| 2023 | PRINCE2 7th edition, adding people and sustainability[^prince2] |
| Nov 2025 | PMBOK Guide Eighth Edition: six principles, seven performance domains, reintroduced process guidance[^pmbok8] |
| 2026 | Agile Practice Guide, Second Edition (July);[^apg2] Project Online retired (30 September);[^poretire] ISO 21502 marked "to be revised"[^iso21502] |

### Glossary and mental model

| Term | Meaning on this page |
|---|---|
| **Project** | PMI: "temporary efforts to create value through unique products, services and processes".[^pmi2024] |
| **Triple constraint** | Scope, time and cost (the "iron triangle"), with quality at the centre; you cannot change budget, schedule or scope "without affecting at least one of the other two".[^msptri] A simplification: tolerances here also cover risk, benefits and sustainability, because a project can hit all three and deliver no benefit. |
| **Baseline** | The approved scope, schedule or cost that performance is measured against; GAO: "subjected to a configuration management control process".[^gaosched] |
| **WBS** | Work breakdown structure: a "product-oriented family tree" of all deliverables.[^nasawbs] |
| **Critical path, float** | The path of longest duration through the schedule; total float is how long an activity can slip before the finish date moves.[^gaosched] |
| **Tolerance** | The delegated room to move on time, cost, scope, quality, risk, benefits or sustainability before an issue must be escalated (management by exception, a PRINCE2 principle).[^prince2] |
| **RAID log** | Risks, assumptions, issues and dependencies kept in one register (some teams add decisions). A common convention, not a standard. |
| **PV, EV, AC, BAC** | Planned value, earned value (the budget of work actually done), actual cost, budget at completion (GAO also uses BCWS, BCWP, ACWP).[^gaocost] |
| **CPI, SPI, TCPI** | EV/AC, EV/PV, and the cost efficiency the remaining work needs to hit a target.[^gaocost] |
| **EAC** | Estimate at completion: cost to date plus a forecast of the remaining work; best produced as a range.[^gaocost] |
| **ES, SPI(t)** | Earned schedule: the time at which the plan expected today's EV; SPI(t) = ES / actual time.[^lipke] |
| **DCA, RAG** | Delivery confidence assessment, rated red, amber or green; NISTA defines it as "an assessment of the likelihood of a project delivering its objectives to time and cost".[^nista] |

**Mental model: a thermostat with a contract.** Baselines are the set point; forecasts are the thermometer; tolerances are the
band in which the project manager adjusts without asking; outside it, the thermostat calls the building's owner (sponsor or
board), who may change the set point through change control. The
[reference architecture](#reference-architecture-the-project-control-loop) draws this loop.

### How ProjectOps relates to other Ops

The boundaries below are this Atlas's editorial distinctions.

| Neighbour | Shared scope | Its unique focus | ProjectOps focus |
|---|---|---|---|
| [PortfolioOps](../portfolioops/) | PMO, funding, prioritisation | Choosing and stopping projects across the portfolio | Running one mandated project; escalating when its case weakens |
| [AgileOps](../agileops/) | Iterations, hybrid delivery | Team cadence, Scrum, Kanban, flow metrics | Baselines, tolerances and forecasts around the team |
| [ProductOps](../productops/) | Roadmaps, launches | Ongoing product line, discovery, analytics | Bounded undertakings with an end; handover to the product |
| [ReleaseOps](../releaseops/) | Go-live | Exposing software changes safely | The cutover milestone and its readiness criteria |
| [ProcurementOps](../procurementops/) | Suppliers | Sourcing, purchase orders, procure-to-pay controls | Supplier milestones and their place in the schedule |
| [BizOps](../bizops/) | Plans and reviews | Company cadence, KPI tree | Status that feeds the business reviews |

::: figure Where ProjectOps sits among the planning and delivery pages
```mermaid
flowchart TB
  BZ["`BizOps:
  company cadence`"] --> PF["`PortfolioOps:
  choose and fund`"]
  PF -->|"mandate"| PJ["`ProjectOps: baselines,
  tolerances, forecasts`"]
  PJ -->|"exceptions, status"| PF
  PC["`ProcurementOps:
  suppliers, contracts`"] --> PJ
  PJ --> AG["`AgileOps:
  team cadence and flow`"]
  PJ --> RL["`ReleaseOps:
  go-live`"]
  PJ -->|"handover"| PR["`ProductOps:
  run the product`"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class PJ core
  class BZ,PF,PC,AG,RL,PR neutral
```
Text equivalent: BizOps sets the company cadence, which feeds PortfolioOps. PortfolioOps chooses and funds a project and
issues its mandate to ProjectOps, which returns exceptions and status. ProcurementOps supplies contracts and suppliers.
ProjectOps works through AgileOps team cadence, hands software go-live to ReleaseOps and hands the result over to ProductOps to
run. Green: this page; grey: neighbours.
:::

## Principles and operating model

### A proposed charter and principles

No "ProjectOps manifesto" exists. The charter below is **this Atlas's proposal**, drawn from the sources cited. PMBOK's
eighth edition names six principles: adopt a holistic view, focus on value, embed quality, lead accountably, integrate
sustainability, and build empowered teams;[^pmbok8] PRINCE2's seven include continued business justification, manage by stages
and manage by exception.[^prince2]

**Mission.** Deliver the agreed outcome within tolerance; when that stops being likely, tell the owners of the money and the
risk early and honestly.

1. **Baseline before you measure.** Without an agreed, versioned baseline there is no variance.
2. **Logic before dates.** Dates come from linked activities; a typed date is a constraint that needs a reason.
3. **Forecast, do not narrate.** Status means "where will we land" against the baseline.
4. **Decide at the level that owns the tolerance.** Inside tolerance the PM acts; outside it, forecasts go up with options.
5. **Ranges, not points.** Estimates and finish dates carry a confidence level.
6. **Make bad news cheap.** RAG rules are written in advance; the first person to report a problem is thanked.
7. **Proportion.** Control effort follows size, novelty and consequence; a two-month internal project does not need EVM.
8. **Finish deliberately.** Handover, acceptance, a benefits owner and lessons that change something are part of the work.

**Non-goals.** A perfect plan; maximum utilisation of people; putting ongoing product work into a project frame.

### Building blocks

| Artefact | What it answers | Owner | Changed by |
|---|---|---|---|
| Charter (project brief, business case) | Why, what outcome, for whom, constraints, who decides | Sponsor | Sponsor or board |
| WBS and WBS dictionary | What exactly is in scope, broken into deliverables | Project manager[^nasawbs] | Change control |
| Schedule (logic-linked) | When, in what order, what drives the finish | Project manager, scheduler | Progress updates; re-baseline via change control |
| Cost baseline and reserves | How much, when spent, what is held back for risk | Project manager, finance | Change control; reserve release rules |
| Tolerance table | How far each target may move before escalation | Sponsor or board | Board |
| RAID log | What could happen, what we assume, what is wrong now, what we depend on | Project manager | Anyone may raise; owner per item |
| Change log | What was asked to change, its impact and the decision | Project manager | Decision authority per tolerance |
| Status and exception reports | Where we will land; whether a tolerance will break | Project manager | Each reporting period; ad hoc for exceptions |
| Closure report and lessons | What was delivered, accepted, handed over, learned | Project manager | Once, at closure |

NASA's handbook describes the WBS as identifying "the hardware, software, services, and all other deliverables required to
achieve an end project objective", including contractors' work: "Work scope not contained in the project WBS should not be
considered part of the project".[^nasawbs] Practitioners call this the 100% rule: each element's children add up to the whole of
it. That makes the WBS the scope boundary and the basis for earned value.

**Example: the WBS of the lab project** (`wbs.csv` in the [control pack](#reference-implementation-a-project-control-pack);
illustrative budgets). Elements are deliverables, not departments; each discrete work package maps to one
[Lab 1](#hands-on-labs) activity and carries its acceptance test.

_Example status: data file, not executed; the budget sums were checked by script._

```csv
wbs_id,deliverable,lab1_activity,budget_usd,accepted_when
1,Leased data centre exited,,600000,all children accepted
1.1,Project management and cutover plan,,60000,children accepted
1.1.1,Project management (level of effort),,45000,closure report accepted
1.1.2,Cutover plan and contracts agreed,A,15000,board approves plan
1.2,Target platform,,300000,children accepted
1.2.1,Hosting and network links in service,B,120000,links pass supplier test
1.2.2,Target environment built,C,180000,build checklist signed
1.3,Data migration,,110000,children accepted
1.3.1,Migration tooling,D,70000,dry run on a test copy
1.3.2,Migration rehearsed,E,40000,rehearsal fits the cutover window
1.4,Service accepted by users,G,30000,UAT exit criteria met
1.5,Support agents trained,F,20000,agents pass assessment
1.6,Service cut over,H,30000,live on the new platform
1.7,Old site closed,I,50000,racks removed; lease and contracts ended
```

The 100% rule in numbers: 1.1.1 + 1.1.2 = 60,000 = 1.1, 1.2.1 + 1.2.2 = 300,000 = 1.2, and the seven children of 1
add up to the 600,000 BAC used in Lab 2. Work package 1.1.1 is level of effort, with no schedule activity, at 7.5% of BAC,
under GAO's 15% scrutiny threshold ([core practices](#core-practices-and-playbooks)).

### Roles, ownership and RACI

Names vary by method: in PRINCE2 a project board directs the project manager, with business, user and supplier interests
represented;[^prince2] UK government major projects have a senior responsible owner (SRO) who reports delivery confidence;[^nista]
many companies simply say "sponsor".

| Role | Accountable for |
|---|---|
| Sponsor or SRO (chairs the board) | Business case, tolerances, decisions outside them, benefits after closure; must be willing to stop the project |
| User and supplier representatives | That the result is usable; that it can be built and supported |
| Project manager | Plans, control within tolerance, honest forecasts, escalation |
| Team leads (team managers) | Work packages: estimates, delivery, progress data |
| Project controls or PMO analyst | Schedule and cost data quality, EV calculation, health checks |
| Finance partner | Actual costs, accruals, capitalisation |

RACI for recurring decisions (R responsible, A accountable, C consulted, I informed):

| Decision or task | Sponsor/board | Project manager | Team leads | PMO analyst | Finance |
|---|---|---|---|---|---|
| Approve charter and tolerances | A | R | C | C | C |
| Approve baselines | A | R | C | C | C |
| Change inside tolerance | I | A/R | C | I | I |
| Change beyond tolerance | A | R | C | C | C |
| Weekly progress and forecast | I | A | R | R | C |
| RAID log upkeep | I | A | R | C | I |
| Stage-gate go / no-go | A/R | R | C | C | C |
| Acceptance and closure | A | R | C | C | I |

### Lifecycle: from mandate to benefits review

PRINCE2's processes run from starting up and initiating through controlling stages and managing stage boundaries to closing,
with the board directing throughout.[^prince2] PMI treats predictive, adaptive and hybrid approaches as per-project choices;[^pmiwhat]
the stage-and-gate skeleton below fits all three, because adaptive teams can deliver inside a stage.

::: figure Project life cycle with stage gates and the exception path
```mermaid
flowchart TB
  M["`Mandate from
  the portfolio`"] --> I["`Initiate: charter,
  WBS, baselines`"]
  I --> G1{{"Gate: approve plan?"}}
  G1 -->|"yes"| S["`Deliver a stage:
  control within tolerance`"]
  G1 -->|"no"| X["Stop or reshape"]
  S --> T{{"Forecast breaks tolerance?"}}
  T -->|"no"| G2{{"Stage gate: next stage?"}}
  T -->|"yes"| E["`Exception report
  with options`"]
  E --> B["`Board decides: new plan,
  change or stop`"]
  B --> S
  B --> X
  X -.->|"reshape"| I
  G2 -->|"more stages"| S
  G2 -->|"last stage done"| C["`Close: accept,
  hand over, lessons`"]
  C --> R["`Benefits review
  by the sponsor`"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class I,S,C,R core
  class G1,T,G2,B decision
  class E,X risk
```
Text equivalent: A mandate from the portfolio leads to initiation (charter, WBS, baselines). At the first gate the board
approves the plan, or stops the project or reshapes it, which sends it back to initiation (dashed line). Each stage is delivered
under control within tolerance. If a forecast breaks a tolerance, an exception report with options goes to the board, which
decides on a new plan, a change or stopping; otherwise the stage gate decides whether to run the next stage. After the last
stage the project closes (acceptance, handover, lessons) and the sponsor later reviews benefits.
:::

Exit criteria keep gates honest: initiation ends when the board approves the baselines; a stage, when its products are
accepted and the next stage is planned; closure, when the sponsor signs off and a named owner takes the benefits. For the
UK's Government Major Projects Portfolio (GMPP: typically projects that need Treasury approval because the budget exceeds a
department's delegated authority and/or the project is "novel, complex, contentious, or requires primary legislation"),
the authority NISTA uses a "five stage gate approach" and reviews projects leaving the GMPP, including "consideration of the
ongoing tracking of project benefits".[^nista]

### Operating model and governance

**Management by exception.** In PRINCE2, as Wikipedia summarises it, a higher level of management delegates authority to a
lower one as tolerances; a tolerance forecast to be exceeded becomes an exception for the level that set it. The seventh edition
has seven tolerance areas: scope, timescale, risk, quality, benefits, cost and sustainability.[^prince2] An illustrative
tolerance table for a mid-sized internal project:

| Area | Project tolerance (board → PM) | Stage tolerance (PM → team lead) | Measured by |
|---|---|---|---|
| Cost | +10% / −5% of BAC | +5% of work-package budget | EAC (Lab 2) |
| Time | +2 weeks on the go-live milestone | +3 days on a work package | Forecast finish; SPI(t) |
| Scope | No "must" requirement removed | Changes to "could" items | Change log |
| Risk | No single risk with expected impact above 5% of BAC | Escalate any new high risk | RAID log |
| Benefits | Business case remains positive | — | Benefits forecast at gates |

**Cadence.** A weekly team checkpoint collects progress and forecast; a fortnightly or monthly highlight report goes to the board;
stage gates decide whether to continue; exception reports go up as soon as a breach is forecast, not at the next meeting.
**Change control** routes every request through one log: impact on scope, schedule, cost, risk and benefits is assessed, then
decided by whoever owns the affected tolerance.

## Architecture and workflow

### Reference architecture: the project control loop

A controlled project is a feedback loop with one rule about who closes it. Its systems are modest; what matters is that they
agree.

::: figure The project control loop and where decisions are made
```mermaid
flowchart TB
  BL["`Baselines: WBS, schedule,
  budget, tolerances`"] --> EX["`Teams do the work
  (any delivery method)`"]
  EX --> MS["`Measure: progress,
  actual cost, risks`"]
  MS --> FC["`Compare and forecast:
  variance, EAC, finish range`"]
  FC --> Q{"Inside tolerance?"}
  Q -->|"yes"| CA["`PM corrective action:
  resequence, reassign`"]
  CA --> EX
  Q -->|"no, forecast breach"| ER["`Exception report
  with options`"]
  ER --> BD["Board decision"]
  BD -->|"approved change"| CC["`Change control:
  re-baseline, log`"]
  CC --> BL
  BD -->|"stop"| ST["Close early"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class BL,EX,MS,FC,CA,CC core
  class Q,BD decision
  class ER,ST risk
```
Text equivalent: Baselines (WBS, schedule, budget, tolerances) guide the teams' work, whatever their method. Progress, actual
cost and risks are measured and compared with the baselines to give variances, an estimate at completion and a finish range.
Inside tolerance, the project manager corrects course (resequencing, reassigning) and work continues. If a breach is forecast,
an exception report with options goes to the board; an approved change passes through change control, which re-baselines and
logs it, or the board stops the project.
:::

| Component | Holds | Integrity check |
|---|---|---|
| Schedule or work tracker | Activities, logic, progress, forecast dates | Every activity linked; no unexplained hard constraints |
| Cost ledger (finance system, timesheets) | Actual cost by work package | Reconciles to finance monthly; accruals included |
| Baseline store | Approved versions of scope, schedule, cost | Every change has a change-log entry |
| RAID and change logs | Risks, assumptions, issues, dependencies; requests, decisions | Owner and review date on every open item |
| Status pack | Variances, EAC range, finish range, RAG with reasons | Generated from the above by written rules (Lab 2) |

The commonest architectural fault is several sources of truth: schedule, tracker and status report each say something
different. GAO makes the point for earned value: implemented correctly, EVM "prevents organizations from managing with one system
and reporting from another".[^gaocost] **Trust boundary:** status flows upwards through people with a stake in how it looks;
[assurance](#assurance-of-the-operating-model) checks it independently.

### End-to-end workflow: one reporting cycle and one exception

**Trigger.** The weekly checkpoint, or any event that changes the forecast (a supplier slip, a failed test, a resignation).

**Happy path.** Team leads update progress and remaining duration; the PMO analyst refreshes schedule and earned value, runs the
[Lab 1](#hands-on-labs) logic checks and publishes the forecast; the project manager acts inside tolerance, records it in the RAID
log and sends the highlight report.

**Exception path.** Below, the refreshed cost EAC breaks the cost tolerance.

::: figure Escalating a forecast breach of the cost tolerance
```mermaid
sequenceDiagram
  autonumber
  participant T as Team leads
  participant P as PM and PMO analyst
  participant B as Project board
  T->>P: Progress, actuals, revised estimates
  P->>T: Ask for cause and recovery options
  T->>P: Cause and three options
  P->>B: Exception report: breach, options, recommendation
  B->>P: Decision: option B, new cost tolerance
  P->>T: Re-baselined plan, change logged
```
Text equivalent: (1) Team leads send progress, actuals and revised estimates to the project manager and PMO. (2) The forecast
shows a breach, so the project manager asks for cause and recovery options, and (3) the team leads return the cause with three
options. (4) The project manager sends the board an exception report with the breach, options and a recommendation. (5) The
board chooses option B with a new cost tolerance. (6) The project manager issues the re-baselined plan and logs the change.
:::

Measure the exception path by two durations: data cut-off to forecast, and forecast breach to board decision. Options include
using reserve, cutting scope, adding time or money, or stopping; a single-option report asks for approval, not a decision.

## Practices, frameworks and tools

### Core practices and playbooks

| Practice | Goal | Owner | Output | Verification |
|---|---|---|---|---|
| Decompose scope | Every deliverable named once | PM with team leads | WBS and dictionary | Children add up to parent; acceptance criteria per work package |
| Build schedule logic | Dates come from dependencies | PM, scheduler | Linked schedule, critical path | No open ends; constraints and lags justified (Lab 1) |
| Estimate in ranges | Honest uncertainty | Team leads | Min / likely / max per activity | Schedule risk analysis (Lab 3); outside-view check |
| Keep the RAID log | Nothing known goes unmanaged | PM | Owned, dated items | No open item without owner and next review date |
| Control change | Scope moves only by decision | PM; authority per tolerance | Change log, new baseline version | Baseline versions match logged decisions |
| Measure progress objectively | Progress you can audit | Team leads, PMO | EV, forecasts (Lab 2) | Earned value from observable completion, not effort spent |
| Report by rule | Status no one can spin | PM | Status with RAG reasons | RAG computed from written thresholds |
| Close deliberately | Value survives the project | PM, sponsor | Handover, lessons, benefits owner | Open items transferred; lessons with an owner |

**Logic first.** GAO's schedule guide asks for all activities to be "logically sequenced and linked" and says "date
constraints and lags should be minimized and justified"; it also flags dangling logic, an activity whose start no predecessor
drives or whose finish drives nothing.[^gaosched] A schedule of typed dates computes no critical path. Logic is necessary but
not sufficient: GAO warns that "the critical path method of scheduling assumes unlimited resources". Its third best practice
assigns resources to all activities; levelling then delays or reassigns work until people are free, so the path that drives
the finish can run through a shared team (GAO's "resource critical path").[^gaosched] Check resource loading before trusting float.

**Measure progress objectively.** GAO lists accepted ways to claim earned value: fixed formulas (0/100, 50/50) for short work
packages, weighted milestones for longer ones, and percent complete only when "based on objective and quantifiable work
completion".[^gaocost] Level-of-effort work (such as management itself) earns value with the passage of time; GAO suggests
scrutinising it when more than 15% of a budget is classified that way.[^gaocost]

**Estimate from outside, too.** Flyvbjerg's reference class forecasting takes the "outside view" in three steps: identify a class
of similar past projects, establish the distribution of their outcomes, and place the new project in it.[^flyvrcf] Use it to
cross-check the bottom-up estimate, not to replace it.

### Stakeholder management: who decides, who must be told

Stakeholders are one of PMBOK's seven performance domains.[^pmbok8] The question: who can stop, change or fund the work, and by when?

1. **Identify and analyse (initiation).** List everyone who can approve, block, fund, use or be harmed by the result. A common
   convention (not a standard) is a power/interest grid: manage closely those high on both, keep the powerful satisfied and the
   interested informed.
2. **Write decision rights down.** For each: what they decide, what they are consulted on, by when. A
   tolerance owner's decisions sit on the critical path of every exception.
3. **Engage on the reporting cadence.** Board: highlight and exception reports; users: accepted increments each stage;
   operations: readiness checks before gates. The register, with a sample row, is in the
   [control pack](#reference-implementation-a-project-control-pack).

Two failure patterns recur. **The sponsor who will not decide:** exceptions wait for weeks. Put a "decision needed by" date on
every exception report, measure decision latency, and escalate to the portfolio forum when they pass. **The hidden veto
holder:** a security team, regulator or works council blocks go-live at acceptance. At initiation ask "who could stop go-live?",
put their criteria into the WBS and invite them to gate reviews.

### Methods, standards and frameworks

| Source | Type | What it gives you | Status (as of October 2026) |
|---|---|---|---|
| PMBOK Guide, 8th ed. (PMI) | Standard and guide | Six principles; seven performance domains (governance, scope, schedule, finance, stakeholders, resources, risk); non-prescriptive processes | Published November 2025[^pmbok8] |
| PRINCE2, 7th ed. | Method | Principles, practices, processes; tolerances; roles; tailoring | 2023; owned by PeopleCert since 2021[^prince2] |
| ISO 21502:2020 | International guidance | Practices for any project "regardless of purpose, delivery approaches, life cycle model" | Marked "to be revised"; draft under development[^iso21502] |
| GAO Schedule Assessment Guide (GAO-16-89G) | Audit criteria | Ten best practices for a reliable schedule | December 2015[^gaosched] |
| GAO Cost Estimating and Assessment Guide (GAO-20-195G) | Audit criteria | Cost estimating, EVM execution, EAC methods | March 2020[^gaocost] |
| EIA-748 | Industry standard (US) | Guidelines for earned value management systems | Revision E, 16 February 2026, listed as current;[^eia748e] GAO's 2020 guide cites revision D (January 2019)[^gaocost] |
| Agile Practice Guide, 2nd ed. (PMI with Agile Alliance) | Guide | Choosing predictive, agile or hybrid life cycles; flow and DORA metrics | Published July 2026[^apg2] |
| GovS 002 Project Delivery (UK) | Mandated in UK government | Expectations for directing and managing portfolios, programmes and projects | Version 2.1, September 2025[^govs002][^govs002lib] |

None of these binds a private company by itself. GovS 002 is "the approved and mandated reference for all government departments
and arm's length bodies" in the UK;[^govs002lib] in the US, GAO reports that OMB has required EVM for all major capital
acquisitions since 2006.[^gaocost] For everyone else they are references to tailor, with a known failure mode: keeping a method's
names and dropping its principles, which Wikipedia's PRINCE2 article calls a "PINO project – PRINCE in Name Only".[^prince2]

### Tooling landscape

| Category | Examples (as of October 2026) | Strengths | Limits and watch-outs |
|---|---|---|---|
| Desktop and server scheduling | Microsoft Project desktop; Project Server Subscription Edition[^poretire] | Full critical path method: zero total slack marks a task critical by default, threshold adjustable; negative slack shown[^mspslack][^mspcp] | Single scheduler bottleneck; weak link to team trackers |
| Cloud work management | Microsoft Planner premium plans (Planner and Project Plan 3 or 5): baselines, Gantt, all four dependency types with automatic rescheduling, critical path in the timeline view;[^poretire][^plannerprem] Jira Plans (Premium and Enterprise): cross-team plans, dependencies, capacity, scenarios[^jiraplans] | Close to where teams work | Jira's cited overview documents no critical-path or float analysis; for float, negative slack and baseline depth, test your tier |
| Open source | OpenProject: Gantt with predecessor and successor relations;[^openproject] baseline comparison (Community edition: changes since yesterday only; other dates need the Enterprise add-on)[^opbaseline] | Self-hosting, no licence lock-in | You run and patch it |
| Professional-services automation | Dynamics 365 Project Operations: quoting, resourcing, time and expense, project accounting[^d365] | Ties delivery to billing and revenue | Built for firms that sell projects; heavy for internal work |
| Spreadsheets and scripts | Any spreadsheet; the labs below | Transparent, auditable formulas | Version control and access are on you |

**Lock-in is a project risk too.** Microsoft announced on 5 September 2025 that Project Online would retire on 30 September 2026
(Project desktop, Project Server and Planner unaffected) and told customers to back up their data.[^poretire] Keep baselines,
logs and status history exportable in open formats.

### Automation and AI

Automation helps where the work is mechanical: pulling actuals, recomputing forecasts, running schedule health checks, drafting
status text from structured data. Examples as of October 2026: Microsoft's Planner Agent (announced in September 2025 as the
Project Manager agent, renamed in 2026) generates tasks, executes assigned tasks and writes status reports, and requires a
Microsoft Copilot licence;[^poretire][^planneragent][^mc1250279][^o365agent] NISTA's "Early Warning System" "uses existing GMPP data to
flag projects at risk of transitioning to a Red rating".[^nista] PMBOK's eighth edition adds coverage of AI.[^pmbok8]

Three limits apply. A model that drafts status from optimistic inputs produces fluent optimism, so keep the RAG rules
deterministic and let AI explain them. An early-warning score is a prompt for a conversation, not a verdict. And anything a model
writes into a baseline or a change log must be approved by the person who owns that tolerance.

## ProjectOps in practice

### Reference implementation: a project control pack

The smallest useful implementation is one versioned file that states the control rules, plus the registers and the schedule it
points to. Writing the rules down before the first report is what makes later status hard to spin. The values are illustrative.

_Example status: syntax-checked (YAML), not executed; it is a configuration you adapt, not a tool._

```yaml
project: exit-leased-data-centre         # illustrative
sponsor: "Director of Infrastructure"
baselines:
  version: 3                             # bumped only by an approved change
  scope: wbs.csv                         # WBS and dictionary
  schedule: network.json                 # logic-linked activities (Lab 1)
  cost: {bac: 600000, currency: USD, management_reserve: 45000}
tolerances:                              # board -> project manager
  cost: {over_pct: 10, under_pct: 5}     # Lab 2 tests over_pct (cost_pct)
  time: {go_live_slip_days: 10}
  scope: "no 'must' requirement removed without board approval"
  risk: "no single risk with expected impact above 5% of BAC"
rag_rules:                               # computed, never typed by hand
  red: "a forecast breaks a tolerance (cost: BAC / CPI; time: IEAC(t))"
  amber: "CPI or SPI(t) < 1.0, or reported EAC fails the TCPI test"
  green: "otherwise"
  tcpi_test: "TCPI to the reported EAC > CPI + 0.05 (GAO rule of thumb)"
cadence:
  checkpoint: weekly                     # team leads -> PM
  highlight_report: fortnightly          # PM -> board
  exception_report: "within 2 working days of a forecast breach"
  schedule_health_check: monthly         # Lab 1 checks, by the PMO
registers:
  raid_log:
    fields: [id, type, description, owner, next_review, status]
    example: [R-07, risk, "network links late; blocks C (critical)", "Infra lead",
              "week 3 checkpoint", open]
  change_log: {fields: [id, request, impact, decided_by, decision, date]}
  stakeholders:
    fields: [name, interest, influence, decides, consulted_on, cadence]
    example: ["Head of Security", "no data exposed in migration", high,
              "go-live security sign-off", "rehearsal plan (E)", "gate reviews"]
```

### Hands-on labs

Three labs on one illustrative project: moving a support platform out of a leased data centre whose lease ends on working day 60.
Python 3 standard library only; no cost, no live system, 30–45 minutes each. Use a new, empty folder. All three scripts
were executed with Python 3.8.10 (the only interpreter available) on 2026-10-23, and use only syntax valid on 3.8 and later; use
a supported Python release. The outputs shown are the actual outputs.

#### Lab 1 (beginner): find the critical path and check the logic

**Objective:** compute early and late dates, total float and the critical path, and catch broken logic before trusting any date.
**Prerequisites:** Python 3. **Risk:** none (local files only).

1. Save the JSON as `network.json` and the script as `cpm.py`.
2. Run `python3 cpm.py network.json; echo $?`.
3. Make a planning decision: the supplier offers an expedited order. Change activity B's `days` from 15 to 9 and run again.
4. Break the logic on purpose: change H's `after` to `["G"]` (so training no longer feeds the cutover) and run again.

::: figure Lab 1 network: the critical path after the expedited order
```mermaid
flowchart TB
  A["A Plan, 10 d"] --> B["B Order links, 9 d"]
  A --> D["D Migration tooling, 12 d"]
  A --> F["F Train agents, 5 d"]
  B --> C["C Build target, 20 d"]
  C --> E["E Rehearse, 8 d"]
  D --> E
  E --> G["G Acceptance test, 6 d"]
  G --> H["H Cut over, 2 d"]
  F --> H
  H --> I["I Decommission, 5 d"]
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class A,B,C,E,G,H,I risk
  class D,F neutral
```
Text equivalent: Activity A (plan, 10 days) precedes B (order network links, 9 days after the expedited order), D (migration
tooling, 12 days) and F (train agents, 5 days). B precedes C (build target, 20 days); C and D both precede E (rehearse, 8 days);
E precedes G (acceptance test, 6 days); G and F both precede H (cut over, 2 days); H precedes I (decommission, 5 days). Red
marks the critical path A, B, C, E, G, H, I (60 days); D and F (grey) have float.
:::

```json
{
  "project": "Exit the leased data centre (illustrative)",
  "deadline_day": 60,
  "activities": {
    "A": {"name": "Plan cutover and contracts", "days": 10, "after": []},
    "B": {"name": "Order hosting and network links", "days": 15, "after": ["A"]},
    "C": {"name": "Build target environment", "days": 20, "after": ["B"]},
    "D": {"name": "Build data-migration tooling", "days": 12, "after": ["A"]},
    "E": {"name": "Rehearse migration", "days": 8, "after": ["C", "D"]},
    "F": {"name": "Train support agents", "days": 5, "after": ["A"]},
    "G": {"name": "User acceptance test", "days": 6, "after": ["E"]},
    "H": {"name": "Cut over", "days": 2, "after": ["G", "F"]},
    "I": {"name": "Decommission old racks", "days": 5, "after": ["H"]}
  }
}
```

_Example status: verified by execution (Python 3.8.10, 2026-10-23)._

```python
"""Critical path, total float and basic logic checks for a small schedule.

Usage: python3 cpm.py network.json
Durations are working days; day 0 is the project start. Finish-to-start
links only. Exit code 1 if the logic is broken (unknown predecessor,
a loop, or more than one open start or end that is not listed under
"justified_open_ends") or the deadline is missed.
"""
import json
import sys


def topo_order(acts):
    order, done, visiting = [], set(), set()

    def visit(k):
        if k in done:
            return
        if k in visiting:
            raise ValueError("loop in logic at " + k)
        visiting.add(k)
        for p in acts[k]["after"]:
            visit(p)
        visiting.discard(k)
        done.add(k)
        order.append(k)

    for k in sorted(acts):
        visit(k)
    return order


def main(path):
    with open(path) as f:
        net = json.load(f)
    acts = net["activities"]
    problems = []
    for k, a in acts.items():
        for p in a["after"]:
            if p not in acts:
                problems.append(f"{k}: unknown predecessor {p}")
    succ = {k: [] for k in acts}
    for k, a in acts.items():
        for p in a["after"]:
            if p in succ:
                succ[p].append(k)
    justified = set(net.get("justified_open_ends", []))  # e.g. hand-offs
    starts = [k for k in acts if not acts[k]["after"] and k not in justified]
    ends = [k for k in acts if not succ[k] and k not in justified]
    if len(starts) > 1:
        problems.append("open starts (no predecessor): " + ", ".join(starts))
    if len(ends) > 1:
        problems.append("open ends (no successor): " + ", ".join(ends))
    if problems:
        print("LOGIC PROBLEMS:\n  " + "\n  ".join(problems))
        return 1
    order = topo_order(acts)
    es, ef = {}, {}
    for k in order:  # forward pass
        es[k] = max([ef[p] for p in acts[k]["after"]], default=0)
        ef[k] = es[k] + acts[k]["days"]
    finish = max(ef.values())
    ls, lf = {}, {}
    for k in reversed(order):  # backward pass
        lf[k] = min([ls[s] for s in succ[k]], default=finish)
        ls[k] = lf[k] - acts[k]["days"]
    print(f"{'id':<3}{'activity':<32}{'dur':>4}{'ES':>4}{'EF':>4}"
          f"{'LS':>4}{'LF':>4}{'float':>6}")
    for k in order:
        tf = ls[k] - es[k]
        mark = " *" if tf == 0 else ""
        print(f"{k:<3}{acts[k]['name']:<32}{acts[k]['days']:>4}{es[k]:>4}"
              f"{ef[k]:>4}{ls[k]:>4}{lf[k]:>4}{tf:>6}{mark}")
    path_ids = [k for k in order if ls[k] == es[k]]
    print(f"\nCritical path: {' -> '.join(path_ids)} ({finish} days)")
    slack = net["deadline_day"] - finish
    print(f"Deadline day {net['deadline_day']}: margin {slack:+d} days")
    return 0 if slack >= 0 else 1


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))
```

**Expected output** (step 2, the exit code, then step 3's last two lines):

```text
id activity                         dur  ES  EF  LS  LF float
A  Plan cutover and contracts        10   0  10   0  10     0 *
B  Order hosting and network links   15  10  25  10  25     0 *
C  Build target environment          20  25  45  25  45     0 *
D  Build data-migration tooling      12  10  22  33  45    23
E  Rehearse migration                 8  45  53  45  53     0 *
F  Train support agents               5  10  15  54  59    44
G  User acceptance test               6  53  59  53  59     0 *
H  Cut over                           2  59  61  59  61     0 *
I  Decommission old racks             5  61  66  61  66     0 *

Critical path: A -> B -> C -> E -> G -> H -> I (66 days)
Deadline day 60: margin -6 days
1

Critical path: A -> B -> C -> E -> G -> H -> I (60 days)
Deadline day 60: margin +0 days
```

Step 4 prints `open ends (no successor): F, I` and exits with 1: training now drives nothing, so a late training course could
never show up as a risk to the cutover. GAO accepts an open end only if "clearly justified" in the schedule documentation, for
example a hand-off to an external partner;[^gaosched] list such cases under `justified_open_ends`. **Undo step 4**
before Lab 3. **Validation:** in step 2 the float of D is 23 days (LS 33 − ES 10) and the critical path sums to 10 + 15 + 20 + 8 +
6 + 2 + 5 = 66 days. **Troubleshooting:** a misspelt predecessor prints `unknown predecessor`; a `KeyError` means an activity
lacks its `days` or `after` field; "loop in logic" means two activities wait for each other. **Teardown:** delete the folder.

**What it teaches.** The plan missed the lease by six days; only shortening a critical activity (B) helped; shortening D or F
would not. A zero margin is not safety (Lab 3). Float also assumes free people. If one team must build both D and C, model
levelling D first by adding `"D"` to C's `after` list: with B at 9 days the run gives 63 days (margin −3), and D, which had
17 days of float on logic alone, becomes critical.

#### Lab 2 (intermediate): earned value status with a rule-based RAG

**Objective:** turn month-3 data into variances, indexes, a range of EACs, TCPI, earned schedule and a RAG status computed from
the tolerances. **Prerequisites:** Python 3; Lab 1 not required.

1. Save `ev.json` and `evm.py`. Run `python3 evm.py ev.json; echo $?`. `eac_reported` is the EAC the project reports to
   its board.
2. Change `ac` to `235000` and run again. Then also change `ev` to `290000`.
3. Test the realism rule: set `ev` 280000, `ac` 295000 and `eac_reported` 600000 (the project still claims "on budget").

```json
{
  "project": "Exit the leased data centre (illustrative)",
  "currency": "USD",
  "bac": 600000,
  "planned_months": 6,
  "pv_cumulative": [80000, 180000, 300000, 420000, 520000, 600000],
  "status_month": 3,
  "ev": 240000,
  "ac": 280000,
  "eac_reported": 640000,
  "tolerance": {"cost_pct": 10, "months": 0.5}
}
```

_Example status: verified by execution (Python 3.8.10, 2026-10-23)._

```python
"""Earned value status: variances, indexes, a range of estimates at
completion (EAC), TCPI, earned schedule, and a rule-based RAG status.

Usage: python3 evm.py ev.json
Formulas follow GAO-20-195G (CPI, SPI, TCPI, index-based EACs) and
Lipke's earned schedule (ES, SPI(t), IEAC(t) = PD / SPI(t)).
RED: a forecast breaks a tolerance (cost: BAC / CPI; time: IEAC(t)).
AMBER: CPI or SPI(t) below 1.0, or the reported EAC fails GAO's realism
test (TCPI to that EAC more than 0.05 above CPI). Exit code 1 on RED.
"""
import json
import sys


def earned_schedule(pv, ev):
    """Months at which the plan expected today's EV (linear interpolation)."""
    prev = 0.0
    for month, cum in enumerate(pv, start=1):
        if ev <= cum:
            return month - 1 + (ev - prev) / (cum - prev)
        prev = cum
    return float(len(pv))


def main(path):
    with open(path) as f:
        d = json.load(f)
    bac, ev, ac = d["bac"], d["ev"], d["ac"]
    at = d["status_month"]
    pv = d["pv_cumulative"][at - 1]
    cpi, spi = ev / ac, ev / pv
    print(f"PV {pv:,}  EV {ev:,}  AC {ac:,}  BAC {bac:,}")
    print(f"CV {ev - ac:+,}  SV {ev - pv:+,}  CPI {cpi:.3f}  SPI {spi:.3f}")
    eacs = {
        "AC + (BAC-EV)          [remaining work at plan]": ac + (bac - ev),
        "BAC / CPI              [cost efficiency persists]": bac / cpi,
        "AC + (BAC-EV)/(CPI*SPI) [cost and schedule drag]":
            ac + (bac - ev) / (cpi * spi),
    }
    for name, value in eacs.items():
        print(f"EAC {name}: {value:,.0f}")
    tol = d["tolerance"]
    cost_limit = bac * (1 + tol["cost_pct"] / 100)
    above = sum(v > cost_limit for v in eacs.values())
    print(f"{above} of {len(eacs)} EACs above cost tolerance {cost_limit:,.0f}")
    eac_rep = d["eac_reported"]
    tcpi_bac = (bac - ev) / (bac - ac)
    tcpi_rep = (bac - ev) / (eac_rep - ac)
    print(f"TCPI to BAC {tcpi_bac:.3f}; to reported EAC {eac_rep:,} "
          f"{tcpi_rep:.3f} (CPI {cpi:.3f})")
    es = earned_schedule(d["pv_cumulative"], ev)
    spi_t = es / at
    ieac_t = d["planned_months"] / spi_t
    print(f"ES {es:.2f} months at AT {at}: SV(t) {es - at:+.2f}  "
          f"SPI(t) {spi_t:.3f}  forecast duration {ieac_t:.1f} months")
    time_limit = d["planned_months"] + tol["months"]
    reasons, notes = [], []
    if bac / cpi > cost_limit:
        reasons.append(f"EAC {bac / cpi:,.0f} > cost tolerance {cost_limit:,.0f}")
    if ieac_t > time_limit:
        reasons.append(f"duration {ieac_t:.1f} > time tolerance {time_limit}")
    if tcpi_rep > cpi + 0.05:
        notes.append(f"reported EAC not credible: TCPI {tcpi_rep:.2f} "
                     f"> CPI {cpi:.2f} + 0.05")
    if reasons:
        status = "RED"
    elif notes or cpi < 1 or spi_t < 1:
        status = "AMBER"
    else:
        status = "GREEN"
    print(f"Status {status}" + "".join("\n  - " + r for r in reasons + notes))
    return 1 if status == "RED" else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))
```

**Expected output** (step 1, then the exit code):

```text
PV 300,000  EV 240,000  AC 280,000  BAC 600,000
CV -40,000  SV -60,000  CPI 0.857  SPI 0.800
EAC AC + (BAC-EV)          [remaining work at plan]: 640,000
EAC BAC / CPI              [cost efficiency persists]: 700,000
EAC AC + (BAC-EV)/(CPI*SPI) [cost and schedule drag]: 805,000
2 of 3 EACs above cost tolerance 660,000
TCPI to BAC 1.125; to reported EAC 640,000 1.000 (CPI 0.857)
ES 2.50 months at AT 3: SV(t) -0.50  SPI(t) 0.833  forecast duration 7.2 months
Status RED
  - EAC 700,000 > cost tolerance 660,000
  - duration 7.2 > time tolerance 6.5
  - reported EAC not credible: TCPI 1.00 > CPI 0.86 + 0.05
1
```

**Validation by hand:** CPI = 240,000 / 280,000 = 0.857; SPI = 240,000 / 300,000 = 0.800. The month-2 plan was 180,000 and
month 3 was 300,000, so ES = 2 + (240,000 − 180,000) / (300,000 − 180,000) = 2.50 months, and SPI(t) = 2.50 / 3 = 0.833.
TCPI to BAC = 360,000 / 320,000 = 1.125: the remaining work would have to run 31% more efficiently to land on budget. In step
2, AC at 235,000 removes the cost breach (BAC / CPI 587,500; only the highest EAC, 675,625, exceeds tolerance) but the time
breach keeps it red; with EV also at 290,000, SPI(t) is 0.972, the forecast 6.2 months, and the status amber (exit 0). Step 3
prints BAC / CPI 632,143 (inside tolerance), forecast 6.4 months, and `AMBER` with "reported EAC not credible: TCPI 1.05 > CPI
0.95 + 0.05". **Troubleshooting:** `ZeroDivisionError` means AC or PV is zero (too early for EV) or AC equals BAC or the reported
EAC. **Teardown:** delete the folder.

**What it teaches.** The EACs are a range, not a menu; GAO calls developing more than one EAC a best practice. Its rule of
thumb, "if the TCPI is more than 5 percentage points higher than the CPI, the EAC is too optimistic", tests a reported EAC's
realism;[^gaocost] this lab uses it for amber and keeps red for forecasts that break a tolerance (this page's adaptation).
Testing TCPI to BAC instead would have turned step 3 red although every EAC is inside tolerance. The red cost rule uses
BAC / CPI, this page's choice: it assumes only that efficiency to date continues.

#### Lab 3 (advanced): how likely is day 60?

**Objective:** run a Monte Carlo schedule risk analysis on the Lab 1 network (with B at 9 days) and read P50, P80 and the
criticality index. **Prerequisites:** Lab 1 completed, with step 3 kept and step 4 undone. `network.json` gives the logic,
`ranges.json` the durations; the script notes any mismatch.

1. Save `ranges.json` (minimum, most likely, maximum days) and `sra.py`.
2. Run `python3 sra.py network.json ranges.json`.
3. Widen D's range to `[10, 12, 36]` and run again; watch D's criticality index.

```json
{
  "A": [9, 10, 14], "B": [8, 9, 15], "C": [18, 20, 30],
  "D": [10, 12, 20], "E": [6, 8, 12], "F": [4, 5, 6],
  "G": [5, 6, 10], "H": [2, 2, 3], "I": [4, 5, 8]
}
```

_Example status: verified by execution (Python 3.8.10, 2026-10-23); the fixed seed makes the numbers repeatable._

```python
"""Monte Carlo schedule risk analysis for the Lab 1 network.

Usage: python3 sra.py network.json ranges.json [runs]
ranges.json gives (minimum, most likely, maximum) days per activity;
each run samples triangular durations and recomputes the forward pass.
Reports the deterministic finish (most likely durations), P50 and P80
finish days, the chance of meeting the deadline, and how often each
activity was on the longest path (its criticality index).
"""
import json
import random
import sys


def forward(acts, order, dur):
    ef, driver = {}, {}
    for k in order:
        preds = acts[k]["after"]
        start = max([ef[p] for p in preds], default=0)
        driver[k] = max(preds, key=lambda p: ef[p]) if preds else None
        ef[k] = start + dur[k]
    last = max(ef, key=ef.get)
    path, k = set(), last
    while k:
        path.add(k)
        k = driver[k]
    return ef[last], path


def main(net_path, ranges_path, runs):
    with open(net_path) as f:
        net = json.load(f)
    with open(ranges_path) as f:
        ranges = json.load(f)
    acts = net["activities"]
    order, seen = [], set()
    while len(order) < len(acts):  # simple topological sort
        before = len(order)
        for k in sorted(acts):
            if k not in seen and all(p in seen for p in acts[k]["after"]):
                order.append(k)
                seen.add(k)
        if len(order) == before:  # nothing placed: bad id or a loop
            stuck = ", ".join(k for k in sorted(acts) if k not in seen)
            sys.exit("unknown predecessor or loop in logic at: " + stuck)
    mode = {k: ranges[k][1] for k in acts}  # durations come from ranges
    for k in acts:
        if mode[k] != acts[k]["days"]:
            print(f"Note: {k} most likely {mode[k]} d, network.json "
                  f"{acts[k]['days']} d; ranges.json is used")
    det, _ = forward(acts, order, mode)
    rng = random.Random(42)  # fixed seed: repeatable output
    finishes, crit = [], {k: 0 for k in acts}
    for _ in range(runs):
        dur = {k: rng.triangular(ranges[k][0], ranges[k][2], ranges[k][1])
               for k in acts}
        finish, path = forward(acts, order, dur)
        finishes.append(finish)
        for k in path:
            crit[k] += 1
    finishes.sort()
    p50 = finishes[int(0.50 * runs)]
    p80 = finishes[int(0.80 * runs)]
    hit = sum(f <= net["deadline_day"] for f in finishes) / runs
    print(f"Deterministic finish: day {det}")
    print(f"P50 day {p50:.1f}   P80 day {p80:.1f}   "
          f"P(finish <= day {net['deadline_day']}) = {hit:.0%}")
    print("Criticality index (share of runs on the longest path):")
    for k in order:
        print(f"  {k} {acts[k]['name']:<32}{crit[k] / runs:>6.0%}")


if __name__ == "__main__":
    n = int(sys.argv[3]) if len(sys.argv) > 3 else 10000
    main(sys.argv[1], sys.argv[2], n)
```

**Expected output** (step 2):

```text
Deterministic finish: day 60
P50 day 67.8   P80 day 71.2   P(finish <= day 60) = 1%
Criticality index (share of runs on the longest path):
  A Plan cutover and contracts        100%
  B Order hosting and network links   100%
  C Build target environment          100%
  D Build data-migration tooling        0%
  E Rehearse migration                100%
  F Train support agents                0%
  G User acceptance test              100%
  H Cut over                          100%
  I Decommission old racks            100%
```

In step 3, D's criticality index rises from 0% to 2% (and B's and C's fall to 98%): a parallel path that is usually safe
sometimes becomes the one that sets the date. **Validation:** no `Note:` lines appear, so the most-likely durations match Lab 1's
network, and the deterministic finish (60) equals Lab 1's step 3. **Troubleshooting:** "unknown predecessor or loop" stops the
run on a bad id or circular logic; if every percentile equals the deterministic finish, the ranges are all `[x, x, x]`.
**Teardown:** delete the folder.

**What it teaches.** The plan built from most-likely durations has about a 1% chance of meeting day 60 under these (invented)
ranges, mostly because each range runs further late than early, so the finish distribution is right-skewed, as GAO says
schedule distributions tend to be; merging paths add "merge bias".[^gaosched] GAO calls the 80th percentile "a conservative
promise date" for some programmes and sizes
contingency as the gap between the deterministic date and the chosen percentile.[^gaosched]

### Use cases and scenarios

All three scenarios are **illustrative**, not descriptions of real organisations.

| Scenario | Context | Approach | Trade-off | Success measure |
|---|---|---|---|---|
| Hard-dated infrastructure exit | Lease ends on a fixed day; hardware lead times | Predictive: full logic, critical path, schedule risk analysis | Scheduling effort; little room for late scope | Cutover by the P80 date; site empty before lease end |
| Fixed budget, open scope | A team builds a new self-service capability | Adaptive inside a cost tolerance; earned value from accepted increments | Scope flexes; date and budget held | Accepted increments per stage; benefits measured after release |
| The project that never ends | "Customer portal phase 4" | Stop the project frame; fund a durable team ([ProductOps](../productops/)) | No end date; needs product metrics | Outcome metrics owned by a product manager |

**Pitfalls.** A vendor's "on track" is weak evidence until acceptance tests pass (supplier milestones and contract terms:
[ProcurementOps](../procurementops/)); team velocity is not earned value. For the never-ending project, Sriram Narayan describes the alternative, product mode, as "durable,
ideate-build-run teams working on a persistent business issue" instead of "temporary, build-only teams", and lists its costs,
such as lower staff utilisation and new silos.[^fowler]

## Measure, govern, pay

### Metrics and KPIs

| KPI | Definition or formula | Data source | Pitfall | Cadence |
|---|---|---|---|---|
| CPI | EV / AC (cumulative and recent periods)[^gaocost] | EV from work packages; AC from ledger | Accruals missing make CPI look good | Each period |
| SPI(t) | ES / AT; forecast duration = planned duration / SPI(t)[^lipke] | PV curve, EV | Cost-based SPI drifts to 1.0 on late projects | Each period |
| EAC range vs tolerance | Lowest and highest index-based EAC against BAC plus tolerance; the red rule uses BAC / CPI | Lab 2 | Reporting only the most pleasant EAC | Each period |
| EAC realism | TCPI to the reported EAC minus CPI; above 0.05 the EAC is "too optimistic" (GAO) | Lab 2 | Testing against BAC and calling a credible overrun red[^gaocost] | Each period |
| Finish-date confidence | Probability of meeting the committed date; P80 date | Lab 3 | Ranges guessed once, never updated | Monthly, and at gates |
| Schedule health | Open ends, unjustified hard constraints, very high float | Lab 1 checks | A clean check on a schedule nobody updates | Monthly |
| Decision latency | Working days from exception report to board decision | Change log | Decisions deferred "to the next board" | Per exception |
| Benefits realised | Measured benefit / benefit in the approved case | Sponsor, after closure | Measured by the team that wants credit | At benefits review |

**Worked calculation (Lab 2, month 3).** CPI 0.857; SPI(t) 0.833; EACs 640,000–805,000 against a 660,000 cost
tolerance; forecast 7.2 months against 6.5 allowed; the reported 640,000 needs a TCPI of 1.000. Red by rule three months before
the planned finish, while options are still cheap.

**Leading and lagging.** Logic quality, estimate ranges, overdue RAID items and decision latency lead; CPI, SPI(t) and
milestones lag; GAO notes that "a negative schedule variance can be a predictor of later cost problems".[^gaocost] Vanity
measures: effort-based percent complete, reports produced, the share of green projects.

### Quality, security, privacy and compliance

- **Quality** is a baseline like the others: acceptance criteria per work package, agreed before work starts, and a quality
  tolerance where trade-offs are allowed.[^prince2]
- **Audit trail.** Every baseline version must trace to a logged decision; keep baselines, change log and status history for the
  retention period your organisation or contract requires.
- **Confidentiality.** Project data holds commercial terms, supplier prices and personal data (timesheets, remarks in RAID
  entries). Limit write access, keep personal data out of shared logs and follow your data-protection rules.
- **Regulated contexts.** Public bodies and contractors may be bound by specific standards (GovS 002 in UK government; EVM
  for major US federal acquisitions);[^govs002][^gaocost] check your jurisdiction and contract.

### Cost, capacity and sustainability

**Contingency and reserve.** Hold contingency for known risks inside the baseline, sized by Lab 3, and a management reserve
outside it that only the sponsor releases, through the change log. **Capacity.** Writing about short activities, GAO warns
that "people are rarely, if ever, 100 percent productive" and puts a productive workday at roughly 60 to 80 percent of eight
hours;[^gaosched] by extension, plans that load everyone at 100% are late by construction. **Cost of control.** Full EVM,
schedule-risk runs and independent assurance cost real effort; spend it where the [decision framework](#decision-framework)
says so. **Sustainability.** PMBOK's eighth edition makes
"integrate sustainability" a principle, and PRINCE2's seventh edition adds sustainability as a tolerance area, so environmental
targets can be escalated like cost or time.[^pmbok8][^prince2]

### Assurance of the operating model

Assurance asks whether the control system tells the truth. Four checks: a monthly schedule health check (Lab 1
plus GAO's ten best practices);[^gaosched] reconciliation of actual cost with the ledger; independent review at major gates by
someone outside the reporting line; and comparing each forecast with what later happened (always beaten or always missed means
bias). The UK's split between self-reported and
independent delivery-confidence ratings for GMPP projects is a public example of the third check.[^nista]

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Finish date never moves, then jumps | Dates typed in; logic missing | Lab 1 checks; count hard constraints | Re-link logic; replace constraints with dependencies | Monthly health check |
| "90% done" for weeks | Effort-based percent complete | Compare EV method with GAO's accepted methods[^gaocost] | Weighted milestones or 0/100 for short packages | Agree EV method per work package at baseline |
| CPI fine, SPI(t) falling | Work started, not finished | Count open work packages and their age | Finish before starting | WIP limits ([AgileOps](../agileops/)) |
| Scope grows, baseline unchanged | Changes accepted informally | Compare delivered items with the WBS | Log retrospectively; re-baseline with board | Change log as the only route for scope |
| Status green, sponsor surprised | RAG by judgement | Compare recent reports with the forecasts behind them | RAG by rule; independent review | Written RAG rules |
| Supplier "on track" until it is not | Self-reported vendor status | Ask for tests passed, items delivered | Milestones tied to acceptance | Acceptance criteria in the contract |

### Worked runbook: the watermelon project

"Watermelon" status is green outside and red inside: the summary hides what the data says.

::: example Illustrative scenario
Month 5 of 9 on a 1.2 million change project. Six highlight reports have been green. A new PMO analyst recomputes earned value from
work-package data: CPI 0.91, SPI(t) 0.86, and the EAC range is 1.28 to 1.41 million against a cost tolerance of 1.30 million.
:::

1. **Contain (day 0).** Publish no further green report. Tell the sponsor in writing today that a breach is likely and options
   follow within two working days.
2. **Verify (days 0–1).** Reconcile AC with the ledger; check how EV was claimed (effort-based percentages are the usual cause);
   run the logic checks; ask for remaining durations as ranges.
3. **Diagnose (days 1–2).** Separate estimate error, unlogged scope growth, productivity (people shared with operations) and risk
   events; each has a different remedy.
4. **Options (day 2).** Cost and date for at least three: re-plan within reserve; cut "could" scope; move the date; stop at the
   next gate. Run Lab 3 on each for a confidence level.
5. **Decide (within a week).** The board chooses; the change log records the new baseline and tolerances.
6. **Prevent.** Adopt written RAG rules, objective EV methods and a monthly independent check of the forecast; record what the
   six green reports were based on as a lesson with an owner. A lesson that causes no change has been identified, not learned,
   as PRINCE2's "learn from experience" principle is summarised.[^prince2]

### Anti-patterns and myths

- **"Adding people will recover the date."** Brooks's law says adding people to a late software project makes it later (under
  certain conditions); Steve McConnell wrote in 1999 that he no longer thought it true as a general rule.[^brooks] Add people
  early, to separable work, or not at all.
- **"The plan is the commitment."** A single-point plan from most-likely durations is the optimistic end of the range (Lab 3).
  Commit to a percentile, not a point.
- **"Agile projects do not need baselines."** One of budget, date or scope is still fixed for the sponsor; the others flex.
- **"More process means more control."** Heavy templates on small projects produce reports, not decisions.
- **"Red means failure."** NISTA notes that red ratings are not unusual early in a GMPP project's life;[^nista] red with options
  is a working control system, while red discovered at the end is a failed one.

## Deciding and adopting

### When to use and when not to use

**Use project control when** the work has a definable end and result, a sponsor who owns the money, a deadline or budget that
matters outside the team, and dependencies across teams or suppliers. **Use it lightly** (charter, linked plan, RAID log,
fortnightly forecast) for small internal projects. **Do not use a project frame** for ongoing product development
or operations with no end; fund a durable team and manage outcomes instead ([ProductOps](../productops/),
[AgileOps](../agileops/)). **Do not use full EVM** where work cannot be budgeted per deliverable or actual costs cannot be
collected per work package; the numbers will be invented. Hidden costs: someone must keep the logic current, and the
sponsor must actually decide.

### Decision framework

::: figure Choosing the container, the life cycle and the depth of control
```mermaid
flowchart TB
  Q1{"Definable end and result?"} -->|"no"| P["`Durable team:
  ProductOps, AgileOps`"]
  Q1 -->|"yes"| Q2{"`Requirements stable,
  late change costly?`"}
  Q2 -->|"yes"| PR["Predictive life cycle"]
  Q2 -->|"partly"| HY["`Hybrid: predictive shell,
  adaptive delivery`"]
  Q2 -->|"no"| AD["`Adaptive inside
  budget tolerance`"]
  PR --> Q3{"Large, novel or high consequence?"}
  HY --> Q3
  AD --> Q3
  Q3 -->|"no"| L["`Light control: charter,
  linked plan, RAID`"]
  Q3 -->|"yes"| F["`Full control: EVM, risk
  analysis, assurance`"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class Q1,Q2,Q3 decision
  class PR,HY,AD,L,F core
  class P neutral
```
Text equivalent: Does the work have a definable end and result? If not, use a durable team (ProductOps, AgileOps). If so, are
requirements stable and late change costly? Yes leads to a predictive life cycle, partly to a hybrid (predictive shell, adaptive
delivery), no to adaptive delivery inside a budget tolerance. Then: is the project large, novel or high-consequence? If not, use
light control (charter, linked plan, RAID log); if so, full control (earned value, schedule risk analysis, independent assurance).
:::

**Assumptions.** The second question follows PMI: predictive when requirements are "well-defined and stable at the beginning",
adaptive when they are "subject to high level of uncertainty and volatility", hybrid in between.[^pmiwhat] A common hybrid runs
hard-dated parts (orders, cutover) predictively around adaptive software delivery. For "large" or "high consequence", ask
whether a 30% overrun would change what the organisation can do next year. Treat IT-heavy projects as riskier than their
budget suggests: Flyvbjerg's data show their cost overruns are fat-tailed.[^flyvit]

### Maturity model

**This Atlas's model**, not an industry standard; assess one project or one PMO's projects.

| Level | Observable behaviour | Evidence | Next step |
|---|---|---|---|
| 1 Ad hoc | Dates chosen first; status by opinion | No baseline versions; no change log | Charter, WBS and a linked plan for the next project |
| 2 Planned | Baselines exist but drift silently | Plan and tracker disagree | Change log as the only route for scope; monthly logic check |
| 3 Controlled | Tolerances, RAG rules, exception reports | Exceptions decided within days | Objective EV methods; forecast ranges |
| 4 Forecasting | EAC ranges, P80 dates, reference-class checks | Forecast error tracked over time | Independent assurance at gates |
| 5 Learning | Lessons change templates and estimates | Estimating data reused; bias falling | Feed portfolio decisions ([PortfolioOps](../portfolioops/)) |

### Adoption roadmap: 30/60/90 days

| Window | Actions | Measure of progress |
|---|---|---|
| Days 1–30 | Pick one live project. Write the control pack. Run Lab 1's checks on its schedule; start one change log. | Every scope change since day 1 logged; no unjustified open ends |
| Days 31–60 | Agree EV methods per work package; produce the first EAC range; compute RAG by rule; run an exception drill with the sponsor. | Status computed from data; decision latency measured |
| Days 61–90 | Run a schedule risk analysis before the next gate; commit the next milestone at a percentile; check forecast history for bias; decide what to standardise. | Committed date carries a confidence; forecast bias known |

## Toolkit

### Checklists

**Initiation readiness**
- [ ] Sponsor named, with authority over budget and scope
- [ ] Charter states outcome, constraints, tolerances and who decides what
- [ ] WBS covers all work, including handover, training and decommissioning
- [ ] Schedule logic-linked; constraints and lags justified in writing
- [ ] Estimates as ranges; deadline committed at a stated confidence

**Each reporting period**
- [ ] Actual cost reconciled with finance; EV claimed by the agreed method
- [ ] Forecasts refreshed; RAG computed from the written rules
- [ ] RAID items past their review date followed up
- [ ] Any forecast breach escalated within the agreed time

**Closure**
- [ ] Products accepted against criteria; open issues transferred to named owners
- [ ] Benefits owner named, with measures and review date
- [ ] Lessons recorded with an owner and the change they should cause

### Templates

_Template status: plain-text forms; adapt the fields to your method._

```text
PROJECT CHARTER (one page)
Project:              Sponsor:             Project manager:
Outcome and benefit:  (what changes, for whom, how measured)
In scope / out of scope:
Baselines:            budget ____  key milestones ____  version __
Tolerances:           cost +__% / -__%   time +__ days   scope ______
Key risks and assumptions (top 5):
Decision rights:      inside tolerance -> PM; outside -> board
Approved by / date:
```

```text
EXCEPTION REPORT
Project / date / author:
Tolerance forecast to break: (area, baseline, forecast, tolerance)
Cause (estimate, scope, productivity, risk event):
Options (at least two, one may be "stop"):
  Option | cost | finish (P50 / P80) | scope | risk | benefits
Recommendation and reason:
Decision needed by (date) and from (who):
```

```text
CHANGE REQUEST
ID / raised by / date:       Description:
Reason:                      Affected WBS elements:
Impact: cost ___  time ___  scope ___  risk ___  benefits ___
Decision level (per tolerance): PM / board
Decision / by / date / new baseline version:
```

### Deep comparisons

How the references in [Methods, standards and frameworks](#methods-standards-and-frameworks) differ in use (editorial judgement):

| | PMBOK Guide (8th ed.) | PRINCE2 (7th ed.) | ISO 21502 | Agile Practice Guide (2nd ed.) |
|---|---|---|---|---|
| Strongest at | Breadth of knowledge areas | Governance: stages, tolerances, roles | Short, neutral vocabulary | Choosing and running adaptive delivery |
| Weaker at | Prescribing one way to run a project | Detailed scheduling technique | Practical detail | Fixed-date, contractual control |

Neighbouring pages are compared in [How ProjectOps relates to other Ops](#how-projectops-relates-to-other-ops).

### FAQ

**Is ProjectOps a job title or a certification?** Neither is established. Related titles exist, such as "PMO operations
manager"; the certifications are for project management (for example PMI's and PRINCE2's).

**Do I need earned value on an agile project?** Only if a sponsor needs cost-to-complete forecasts and you can budget accepted
increments; otherwise a budget burn-up against accepted scope gives most of the signal.

**What is the difference between float and buffer?** Float is computed from the logic (Lab 1) and vanishes when a parallel path
slips; a buffer is time you deliberately add, sized by risk analysis (Lab 3), owned and released.

**Why does SPI say 1.0 on a project that finished late?** Because cost-based SPI compares earned with planned value; at completion
both equal the budget. Lipke notes "SV = 0.0 and SPI = 1.0 at the conclusion of a late project, falsely indicating perfect
performance"; use SPI(t).[^lipke]

**When should a project be stopped?** When the business case no longer holds at the forecast cost and benefits (PRINCE2's
"continued business justification"),[^prince2] or when the outcome is better pursued another way. Stopping is an option in every
exception report.

## Going further

### Advanced topics and emerging direction

- **Established but under-used:** earned schedule for time forecasts;[^lipke] reference class forecasting;[^flyvrcf] integrated
  cost-schedule risk analysis, which GAO compares with EVM-based EACs as a cross-check.[^gaocost]
- **Active change (as of October 2026):** PMBOK 8 reintroduces process guidance in a "non-prescriptive way";[^pmbok8] ISO 21502
  is being revised;[^iso21502] Microsoft's shift from Project Online to Planner premium and the Planner Agent.[^poretire][^planneragent]
- **Speculative:** AI that predicts project failure. NISTA says its early-warning tool "has already proved helpful";[^nista]
  no independent evaluation was found.

### Learning path

| Stage | What to do |
|---|---|
| Prerequisites | Spreadsheets; percentages; reading a simple budget |
| 1-day primer | This page's first three parts; run Lab 1; read GAO's ten schedule best practices[^gaosched] |
| 1 week to 30 days | Labs 2 and 3; write a control pack and WBS for a real project; run it with written RAG rules, tracking forecast error |
| Specialise | Project controls (EVM, schedule risk); a method (PMBOK or PRINCE2); hybrid delivery with [AgileOps](../agileops/); portfolio work in [PortfolioOps](../portfolioops/) |
| Portfolio project | An anonymised forecast-versus-actual history of a finished project, with lessons and resulting changes |

## Wrap-up

### Executive recap and cheat sheet

| Topic | Remember |
|---|---|
| Term | "ProjectOps" is a label, not a discipline; teach and hire for project management and project controls |
| Control system | Baselines, tolerances, forecasts, exceptions, change control |
| Schedule | Logic first; critical path and float from the network; commit at a percentile (P80 is a conservative promise date)[^gaosched] |
| Money | CPI, SPI(t), a range of EACs, a TCPI realism test of the reported EAC[^gaocost][^lipke] |
| Status | RAG by written rule; independent review where stakes are high |
| Watch-outs | Typed dates, effort-based progress, silent scope change, single-point plans |
| When not to | Ongoing product work; tiny tasks; EVM without per-deliverable budgets |

### A judgement call: crash the plan or buy time?

::: example Illustrative scenario
The data-centre exit from the labs. After the expedited order (Lab 1, step 3) the plan finishes exactly on day 60, when the lease
ends. Lab 3 gives that date about a 1% chance; P80 is about day 71. The landlord offers a one-month extension at a known price;
the infrastructure lead proposes paying for a second build crew on activity C instead.
:::

**Option A: crash.** Pay for the second crew to shorten C and keep day 60; it looks decisive. **Option B:
buy time.** Take the extension, commit to the P80 day, and add the crew only if C still dominates the risk.

**How to decide.** Re-run Lab 3 with C as the crew proposal claims. Setting C to 13 days with a range of 12 to 20 in both files
(executed 2026-10-23 with the same seed) lifts the chance of finishing by day 60 from about 1% to about 48%, with P80 at day 63. Crashing
helps, but buys a coin flip on a costly, irreversible deadline, because the other critical activities keep their right-skewed
ranges; and Brooks's warning applies where work cannot be split cleanly.[^brooks]

**Assumptions and uncertainty.** The ranges are invented; real ones come from the teams and a reference class.[^flyvrcf] Without
the extension, A plus scope cuts (decommissioning after the date, if the contract allows) would be the remaining lever. **A
defensible choice:** B, since the extension (about 21 working days) covers the P80 date; add the crew only if it costs less than
the delay it removes. Record the decision and assumptions in the change log.

### Learning objectives and mastery check

After this page you should be able to: **explain** what the label does and does not mean; **build** a logic-linked schedule and
find its critical path; **calculate** CPI, SPI(t), EAC ranges and TCPI; **commit** a date at a stated confidence; **design**
tolerances and written RAG rules; and **decide** whether a project frame fits the work at all.

::: answer Your 66-day schedule has an activity that finishes on day 15 with no successor and 51 days of float. What do you suspect?
Missing logic. High float and an open end usually mean the activity's output feeds nothing in the network; GAO notes that
unreasonably high float "indicates that schedule logic might be missing or invalid".[^gaosched] Link it (training feeds cutover)
and rerun, unless the open end is a justified hand-off.
:::

::: answer Month 4 of 8, schedule on plan, CPI 0.95; the project reports EAC = BAC, which needs a TCPI of 1.06. Red, amber or green?
Amber. GAO's rule of thumb (TCPI more than 5 points above CPI) says the "on budget" EAC is too optimistic, so ask for a realistic
one.[^gaocost] But BAC / CPI is about 5% over budget, inside a +10% tolerance: no tolerance breaks, so it is not red. Report
the EAC range and escalate only if a forecast leaves the tolerance.
:::

::: answer A sponsor asks for "the date". The plan's deterministic finish is day 60; P50 is 68 and P80 is 71. What do you say?
Give the date with its confidence: day 60 is unlikely (about 1% here); day 68 is a coin flip; day 71 is a conservative
commitment. Then show which activities drive the spread (criticality index) and what would change it.
:::

::: answer A team's velocity doubled. Did earned value double?
Not necessarily. Velocity is output in the team's own estimation units, which can inflate; earned value is the budget of
accepted, in-scope work.
:::

::: answer Six green reports, then a red one. What is the first process fix?
Compute status from written rules (EAC range against tolerance, SPI(t), EAC realism) and add periodic independent review. Fix
the reporting system before blaming the individual.
:::

### Conclusion

"ProjectOps" is a word in search of a discipline; the discipline it points to has existed since the critical path method. What
makes it work is a small, honest control loop, summarised in the recap above: run it proportionately, thank whoever reports bad
news first, and drop it where the work has no end.

## Sources and further reading

All sources were opened on 2026-10-23; pages refusing automated access were read from the Internet Archive captures cited.

[^d365]: [Dynamics 365 Project Operations](https://learn.microsoft.com/en-us/dynamics365/project-operations/welcome-to-project-operations) — Microsoft Learn, updated 2026-09-18. Checked 2026-10-23.
[^d365ga]: [Optimize your project-centric business with Dynamics 365 Project Operations](https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2020/09/23/optimize-your-project-centric-business-with-dynamics-365-project-operations/) — Microsoft Dynamics 365 Blog, 2020-09-23. Checked 2026-10-23.
[^hubspot]: [ProjectOps (HubSpot App Marketplace listing)](https://ecosystem.hubspot.com/marketplace/listing/projectops) — Atlantic Ops, current listing. Checked 2026-10-23.
[^pmiwhat]: [What Is Project Management?](https://web.archive.org/web/20261012094302/https://www.pmi.org/about/what-is-project-management) — Project Management Institute (Internet Archive capture of 2026-10-12). Checked 2026-10-23.
[^pmi2024]: [What is Project Management?](https://web.archive.org/web/20240425044910/https://www.pmi.org/about/learn-about-pmi/what-is-project-management) — Project Management Institute (Internet Archive capture of 2024-04-25). Checked 2026-10-23.
[^pmbok8]: [PMBOK Guide](https://web.archive.org/web/20261001053859/https://www.pmi.org/standards/pmbok) — Project Management Institute, Eighth Edition published November 2025 (Internet Archive capture of 2026-10-01). Checked 2026-10-23.
[^apg2]: [Agile Practice Guide](https://web.archive.org/web/20261001135127/https://www.pmi.org/standards/agile) — Project Management Institute with Agile Alliance, Second Edition, July 2026 (Internet Archive capture of 2026-10-01). Checked 2026-10-23.
[^prince2]: [PRINCE2](https://en.wikipedia.org/wiki/PRINCE2) — Wikipedia, current revision (secondary source for the method's structure). Checked 2026-10-23.
[^iso21502]: [ISO 21502:2020 Project, programme and portfolio management — Guidance on project management](https://web.archive.org/web/20261005073541/https://www.iso.org/standard/74947.html) — ISO (Internet Archive capture of 2026-10-05). Checked 2026-10-23.
[^gaosched]: [GAO Schedule Assessment Guide: Best Practices for Project Schedules (GAO-16-89G)](https://web.archive.org/web/20260827092119/https://www.gao.gov/assets/gao-16-89g.pdf) — US Government Accountability Office, December 2015 (Internet Archive copy). Checked 2026-10-23.
[^gaocost]: [Cost Estimating and Assessment Guide (GAO-20-195G)](https://web.archive.org/web/20261011003417/https://www.gao.gov/assets/gao-20-195g.pdf) — US Government Accountability Office, March 2020 (Internet Archive copy). Checked 2026-10-23.
[^lipke]: [Earned Schedule: Schedule Analysis from EVM Measures](https://www.earnedschedule.com/Docs/Earned%20Schedule%20-%20Schedule%20Analysis%20from%20EVM%20Measures.pdf) — Walt Lipke, Project Landscape, July 2008. Checked 2026-10-23.
[^flyvit]: [The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution](https://arxiv.org/abs/2210.01573) — Flyvbjerg, Budzier, Lee, Keil, Lunn, Bester; Journal of Management Information Systems 39(3), 2022 (arXiv). Checked 2026-10-23.
[^flyvmega]: [What You Should Know About Megaprojects, and Why: An Overview](https://arxiv.org/abs/1409.0003) — Bent Flyvbjerg, Project Management Journal, 2014 (arXiv). Checked 2026-10-23.
[^flyvrcf]: [From Nobel Prize to Project Management: Getting Risks Right](https://arxiv.org/abs/1302.3642) — Bent Flyvbjerg, Project Management Journal 37(3), August 2006 (arXiv). Checked 2026-10-23.
[^nista]: [NISTA Major Projects Annual Report 2025-26](https://www.gov.uk/government/publications/nista-major-projects-annual-report-2025-26/nista-major-projects-annual-report-2025-26) — National Infrastructure and Service Transformation Authority, GOV.UK, 2026-07-13. Checked 2026-10-23.
[^govs002]: [Government Functional Standard GovS 002: Project Delivery](https://www.gov.uk/government/publications/project-delivery-functional-standard) — Government Project Delivery and Cabinet Office, GOV.UK, version 2.1, updated 2025-09-17. Checked 2026-10-23.
[^govs002lib]: [Government Functional Standard GovS 002: Project delivery](https://projectdelivery.gov.uk/library-product/government-functional-standard-govs-002-project-delivery/) — Government Project Delivery Function library, version 2.1, 2025-09-01. Checked 2026-10-23.
[^fowler]: [Products Over Projects](https://martinfowler.com/articles/products-over-projects.html) — Sriram Narayan, martinfowler.com, first published 2017-11-16, revised 2018-02-20. Checked 2026-10-23.
[^mum]: [Keeping Mum as the Project Goes Under: Toward an Explanatory Model](https://jmis-web.org/articles/885) — H. Jeff Smith, Mark Keil, Gordon Depledge, Journal of Management Information Systems 18(2), 2001 (abstract). Checked 2026-10-23.
[^poretire]: [Microsoft Project Online is retiring: What you need to know](https://techcommunity.microsoft.com/blog/plannerblog/microsoft-project-online-is-retiring-what-you-need-to-know/4450558) — Microsoft Planner Blog, 2025-09-05. Checked 2026-10-23.
[^mspslack]: [Show slack in your project in Project desktop](https://support.microsoft.com/en-us/project/show-slack-in-your-project-in-project-desktop) — Microsoft Support, undated. Checked 2026-10-23.
[^mspcp]: [Manage your project's critical path](https://support.microsoft.com/en-us/project/manage-your-project-s-critical-path) — Microsoft Support, undated. Checked 2026-10-23.
[^plannerprem]: [Advanced capabilities with premium plans in Planner](https://support.microsoft.com/Planner/teams/advanced-capabilities-with-premium-plans-in-planner) — Microsoft Support, undated. Checked 2026-10-23.
[^planneragent]: [Access Planner Agent](https://support.microsoft.com/planner/copilot/access-planner-agent) — Microsoft Support, undated. Checked 2026-10-23.
[^mc1250279]: [MC1250279 – Microsoft 365 Copilot: Planner Agent rename and rollout to premium and basic plans](https://mc.merill.net/message/MC1250279) — third-party archive of a Microsoft 365 Message Center post, last updated 2026-05-15. Checked 2026-10-23.
[^o365agent]: [Planner Agent Delivers AI Help for Tasks](https://office365itpros.com/2026/03/19/planner-agent/) — Tony Redmond, Office 365 for IT Pros, 2026-03-19 (independent report of MC1250279). Checked 2026-10-23.
[^jiraplans]: [What are plans in Jira Premium?](https://support.atlassian.com/jira-software-cloud/docs/what-is-advanced-roadmaps/) — Atlassian Support, current page. Checked 2026-10-23.
[^openproject]: [Gantt charts](https://www.openproject.org/docs/user-guide/gantt-chart/) — OpenProject documentation, current page. Checked 2026-10-23.
[^opbaseline]: [Baseline comparison](https://www.openproject.org/docs/user-guide/work-packages/baseline-comparison/) — OpenProject documentation, current page. Checked 2026-10-23.
[^msptri]: [The project triangle](https://support.microsoft.com/en-us/office/the-project-triangle-8c892e06-d761-4d40-8e1f-17b33fdcf810) — Microsoft Support, undated. Checked 2026-10-23.
[^eia748e]: [SAE EIA 748E:2026-02-16 Earned Value Management Systems](https://www.dinmedia.de/en/standard/sae-eia-748e/400475249) — DIN Media catalogue listing (status "current"). Checked 2026-10-23.
[^nasawbs]: [NASA Work Breakdown Structure (WBS) Handbook (NASA/SP-20210023927)](https://www.nasa.gov/wp-content/uploads/2023/08/nasa-work-breakdown-structure-handbook.pdf) — NASA, November 2021. Checked 2026-10-23.
[^wikicpm]: [Critical path method](https://en.wikipedia.org/wiki/Critical_path_method) — Wikipedia, current revision. Checked 2026-10-23.
[^brooks]: [Brooks's law](https://en.wikipedia.org/wiki/Brooks%27s_law) — Wikipedia, current revision (summarises Brooks 1975 and McConnell 1999). Checked 2026-10-23.

**Re-check by April 2027:** ISO 21502 revision; EIA-748 revision; Planner and Planner Agent names and licences; Jira Plans tiers.

**Further reading** (not opened for this page): Brooks, *The Mythical Man-Month*; PMI, *Practice Standard for Earned Value
Management*.

**Changelog.** 2026-10-23, r0: first draft (research, ledger, three labs executed, six diagrams); not yet independently reviewed.
2026-10-23, r1: revised after independent review `projectops-r1`: RAG rule uses GAO's TCPI test for EAC realism (amber), not
for red; PRINCE2 wording attributed to Wikipedia's summary; Planner critical path, Planner Agent, EIA-748-E and GovS 002
mandate updated with new sources; stakeholder management and triple constraint added; GMPP scope; lab guards; trimmed.
2026-10-23, r2: after scoring `projectops-score` (91): WBS example with the 100% rule; resource levelling (GAO) and a Lab 1
levelling run; full GMPP criteria; right-skew wording; sample RAID and stakeholder rows; second Planner Agent source; trims.
2026-10-23, post-score polish: OpenProject baseline tier; WBS level of effort split from activity A; manual underspend check;
GAO productivity context; trims.