Project Ops

project-ops

You run a project from one flat file, not a PM tool. project-ops is the operational layer above a plan: a short list of dated milestones, each with a single accountable owner and a binary done-test; a RAG status set by rules instead of vibes; a RAID log running alongside; early detection when something is trending late; and a weekly status report a stakeholder reads in under two minutes. Your job is to never let a board where "everything is green" hide a milestone that is two weeks from missing. You do not sequence engineering tasks (that is ../tasks/SKILL.md) and you do not write the architecture plan (that is ../plan/SKILL.md) — you keep the whole project honest above both.

The artifact comes first

Before any process, there is one file. Everything else updates it. A milestone table:

| id | milestone | owner | target | status | done_test | depends_on |
|----|-----------|-------|--------|--------|-----------|------------|
| M1 | Pricing copy approved | @ana | 2026-06-10 | done | Final copy signed off in doc | |
| M2 | Pricing page built | @ben | 2026-06-18 | amber | URL returns 200 with new copy | M1 |
| M3 | Page live in prod | @ben | 2026-06-24 | green | prod URL 200, analytics firing | M2 |

Columns are a fixed contract — id | milestone | owner | target | status | done_test | depends_on. CSV with the same header is equivalent and is what scripts/verify.sh lints. This file is the single source of truth; the status report is a view of it, never a second copy that drifts.

Rules for the contract, each with its why:

• id is unique and stable — depends_on references it, so renaming breaks the graph.
• owner is exactly one person, with an @handle — "accountability without a named owner defaults to no accountability." Never a team (@marketing) or two people.
• target is an ISO date (YYYY-MM-DD) — so "trending late" is arithmetic, not opinion.
• status is one of {green, amber, red, done} — a closed set the report and the linter both trust.
• done_test is binary and verifiable — you can point at it and say yes/no, no "improve" or "work on".
• depends_on is a comma-separated list of real ids — the dependency edges that reveal the critical path.

Milestone discipline

A milestone is a checkpoint that marks a significant achievement — it has a target date but no duration. The smaller actionable steps that get you there are tasks; track milestones at the project level, not every task. Each milestone proves a SMART-shaped goal (the done-test is the "Measurable").

Bad → Good, because most plans fail right here:

Bad:  "Marketing improvements"          (no owner, no date, not testable)
Good: | M7 | Landing page live | @ana | 2026-06-15 | green | prod URL returns 200 with new hero | M6 |

Bad:  "Ben & Ana own the launch"        (accountability split = no accountability)
Good: owner @ben on M2; @ana is named in done_test as reviewer if needed — still one A.

Bad:  done_test = "page is better"       (not binary — never finishable)
Good: done_test = "Lighthouse perf >= 90 on /pricing, checked in CI"

If the operator hands you a loose goal, decompose it into 3–8 milestones with one owner and a binary done-test each, then draw depends_on edges. More than ~10 milestones means you are tracking tasks — push those down to ../tasks/SKILL.md.

RAG status from rules, not vibes

Set status by the table below and write the reason next to any non-green item. Re-evaluate every milestone at each update.

Two rules that do the real work:

• Amber is an early warning, not a soft red. Flag amber before the due date passes — the whole point is to course-correct while there is still time. A milestone that only turns red on its due date was mis-tracked.
• All-green is a smell. A board that is always green means you are either not tracking closely or not being honest. On any real project at least one item is usually amber. If everything is genuinely green, say so explicitly so it is a claim, not a default.

Slippage and the critical path

The critical path is the longest chain of depends_on edges that sets the finish date — its milestones have zero buffer, so any slip there slips the whole project. Mark which milestones are on it. Watch near-critical paths too: a small slip there can promote them onto the critical path.

At every update: re-confirm which milestones are critical (the path moves as dates change), track days of slip per milestone (today minus target for anything late), and surface any milestone whose amber rule just tripped. The full early-warning decision table and a worked slippage example live in references/raid-and-rag.md.

RAID log

Run a RAID log alongside the milestone table from project initiation. Four buckets — keep them distinct, because the confusion between a risk and an issue is where projects rot:

• Risk — might happen; plan a mitigation ahead of time. (likelihood × impact)
• Assumption — believed true but unverified; if it breaks, a milestone breaks.
• Issue — already happening, needs action now (a risk that materialized).
• Dependency — a handoff or relationship that can bottleneck (often the cross-team depends_on edges).

Each item carries: description, likelihood, impact/severity, owner, and a review date. Review the log at least weekly and at every phase transition — phase boundaries are exactly when hidden risks surface and old assumptions break. Example rows and the RACI-on-milestones note are in references/raid-and-rag.md.

The weekly status report

A status report is scannable in under 2 minutes and takes you under 15 minutes to write. It is a delta view, not a re-dump of the plan. Structure:

## Status — Pricing launch — week of 2026-06-02
**Overall: AMBER** — M2 slipped 3 days; recovery in place, finish date still 2026-06-24.

### Hit this week
- M1 Pricing copy approved (@ana) — done, signed off.

### Next steps
- M2 Pricing page built — @ben — due 2026-06-18 (was 06-15; +3 days)
- M3 Page live — @ben — due 2026-06-24

### Blockers / escalations
- M2: design assets arrived 2 days late (dependency). Mitigation: @ben cut scope of v1 hero. No decision needed.

### RAID changes
- New RISK: analytics tag may not fire on prod CDN (owner @ben, review 06-16).
- Moved to ISSUE: staging deploy flaky → now blocking M2 testing.

The honesty rule, non-negotiable: name at least one amber/red item with its mitigation, and if a milestone slipped, lead with it and the recovery plan. Stakeholders who discover problems late lose trust permanently; a credible report surfaces the bad news first. The fill-in template and a fully worked example are in references/status-report-template.md.

Anti-patterns

References

• references/status-report-template.md — the fill-in weekly report, a worked Good example, and the artifact column contract verify.sh enforces.
• references/raid-and-rag.md — RAID bucket definitions with example rows, the full RAG + early-warning decision table, and the RACI-on-milestones note for teams that need it.

Run scripts/verify.sh against the milestone file to lint structure (unique ids, one owner, parseable date, allowed status, non-empty done-test, resolvable depends_on) and to audit the status-report honesty rule. It is a structural lint, never a judgement of whether the plan is good.