Project Management skill for Codex

A project is under control when everyone can answer four questions the same way: what are we delivering and what are we not, who is accountable for each piece, what is the next milestone and how confident are we, and what is most likely to make us late. The plan is a living document that is cheaper to update than to ignore.

Workflow

• Write the charter and get the sponsor to approve scope and success criteria
• Break work into deliverables, then tasks small enough to estimate (1-5 days)
• Map dependencies and identify the critical path
• Estimate in ranges; set milestones with confidence levels
• Build the RACI for deliverables and decisions
• Open the risk register and decision log
• Set the cadence: weekly status, change control, milestone reviews
• Close with a retrospective and handover

Read existing artifacts first: tickets, roadmap, PRDs, previous status reports, and AGENTS.md or team docs for the tracking tool in use. Plans that duplicate the tracker by hand drift within a week; link to it instead.

Charter (one page)

# <Project> - charter v<n>, <date>
**Sponsor:** <name> | **Project lead:** <name>
**Problem / goal:** <why this project, in two sentences>
**Success criteria:** <measurable, e.g. "all EU customers migrated to eu-west-1 with
zero data loss and under 15 minutes downtime each, by 2027-03-31">
**In scope:** <bullets>
**Out of scope (non-goals):** <bullets - as important as scope>
**Constraints:** <budget, deadline drivers, regulatory, people>
**Key milestones:** <3-6 dated milestones>
**Stakeholders:** <who must be consulted or informed>
**Top risks:** <3, linked to register>

Breakdown, dependencies and critical path

• Decompose by deliverable (what exists at the end), not by department.
• Each task: owner, estimate range, dependencies, definition of done.
• The critical path is the longest chain of dependent tasks; any slip on it moves the end date. Name it in every status report.
• Make external dependencies explicit (vendor, legal review, another team’s release) and give each an owner on your side who chases it.

Visualise with Mermaid (renders in GitHub, GitLab and many doc tools):

gantt
    title EU region migration
    dateFormat YYYY-MM-DD
    section Infrastructure
    Provision eu-west-1          :infra, 2026-11-02, 10d
    Replication setup            :repl, after infra, 8d
    section Application
    Region-aware config          :cfg, 2026-11-02, 12d
    section Migration
    Pilot customers              :milestone, pilot, after repl cfg, 0d
    Batch migration              :batch, after pilot, 20d

Estimating

• Give ranges, not points: best / likely / worst. A three-point estimate (best + 4 x likely + worst) / 6 is a reasonable expected value; the spread tells you the risk.
• Add explicit buffers at milestones rather than padding each task; padded tasks expand to fill the time.
• State confidence with every date: “Beta 2026-12-10, 70% confident; 90% confident by 2026-12-20.”
• Re-estimate when scope changes or after the first 20% of work; early velocity is the best data you will get.

RACI

Deliverable / decision	Priya (PM)	Sam (Eng lead)	Ana (Security)	Lee (Support)	Sponsor
Migration runbook	C	A	C	I	I
Customer communications	A	C	I	R	I
Go / no-go per batch	R	C	C	I	A
Data residency sign-off	I	C	A	I	I

R = does the work, A = accountable (exactly one per row, can say yes or no), C = consulted before, I = informed after. Checks: one A per row; no row without an R; nobody is A on everything; a person with many Cs is a bottleneck.

Risks, decisions and changes

Risk register:

| ID | Risk (cause -> event -> impact) | Likelihood 1-5 | Impact 1-5 | Score | Owner | Mitigation | Trigger | Status |
|---|---|---|---|---|---|---|---|---|
| R1 | Replication lag under peak load -> cutover window overruns -> SLA breach | 3 | 4 | 12 | Sam | load test at 2x peak by 11-20 | lag > 30 s in test | open |

Review top risks weekly; a risk with no mitigation and no owner is just a worry.

Decision log: date, decision, decider, options considered, link to memo. Stops the same question being reopened.

Change control: any change to scope, date or budget is written as a request with impact on schedule and cost, approved by the sponsor (or the A for that deliverable), and recorded.

Status report

Weekly, same format, same day. RAG must have written criteria or it becomes mood:

Colour	Meaning
Green	Next milestone on track within buffer; no unmitigated high risks
Amber	Milestone at risk; recovery plan exists and needs no sponsor decision
Red	Milestone will be missed without a decision, scope change or resources from sponsor

# <Project> status - week of <date> - overall: AMBER (was GREEN)
**Next milestone:** Pilot customers migrated - planned 11-27, forecast 12-02 (70%)
**Why amber:** replication setup slipped 3 days; on critical path.
**Ask:** none this week | <decision needed, from whom, by when>

**Done this week:** <3-5 bullets, outcomes not activities>
**Next week:** <3-5 bullets>
**Top risks:** R1 (12, mitigation in progress), R4 (new)
**Changes approved:** <CR id and summary>
**Metrics:** <tasks done / total, burn-up link, budget used>

Lead with the ask. A red status without an ask is a complaint; a red with a clear decision request is useful.

Pulling status from GitHub

When work lives in GitHub issues (network and gh auth required):

gh issue list --milestone "Pilot" --state all --json number,title,state,assignees,labels --limit 200
gh issue list --label blocked --state open --json number,title,assignees
gh pr list --search "milestone:Pilot is:merged" --json number,title,mergedAt

Summarise counts and blockers; never close, reassign or relabel issues without the user’s approval.

Rescuing a slipping project

1. Re-baseline honestly: remaining work, current velocity, real dependencies.
2. Present options to the sponsor with consequences: cut scope (name what), move the date (to when, with what confidence), add people (only helps for parallelisable work with onboarding capacity), accept more risk (which one).
3. Get one option decided and recorded; update the plan and communicate the new baseline.

Gotchas

• “Done” without a definition of done leads to 90%-complete tasks for weeks.
• Status reports written from memory; generate them from the tracker and the risk register.
• Dependencies on teams that never agreed to the dates. Confirm and record their commitment.
• Watermelon reporting: green on the outside, red inside. Use the written RAG criteria.
• Holidays, on-call rotations and other projects consume capacity; plan at 60-70% of nominal availability per person.

Output

Charter, plan (tasks with owners, estimates, dependencies; Mermaid Gantt), RACI, risk register, decision log, status report template filled for the current week.