Plan and run a project
A project plan has one job: make the work visible enough that problems are found while they are still cheap. It is not a document produced to satisfy someone, and a plan that is written once and never opened has cost time and delivered nothing.
The test for every part of a plan: would anyone act differently because of this. A Gantt chart nobody reads fails it. A named owner on a task fails it if the task was going to happen anyway. A dependency nobody had noticed passes it easily.
Ask these eight questions first
Do not put dates on anything until these are answered. Almost every late project is a scope problem wearing a schedule problem’s clothes, and the scope problem is visible in the answers to questions 1, 2 and 6.
1. What is being delivered? As things that exist at the end, not activities
2. How do you know each one is done, and who accepts it?
3. What is the deadline, and what is driving it?
4. Who is on the team, and how much of their week is genuinely on this?
5. What do you need from the client or a third party, and by when?
6. What is explicitly not in scope?
7. What have projects like this gone wrong on before?
8. Which task tool are you using?
Question 2 is load bearing. A deliverable with no acceptance criteria and no named acceptor is one that is never formally accepted and never formally rejected, so the project never ends and the final payment never falls due.
Question 3 needs its second half asked. A deadline with a real driver behind it, a lease, an audit, a season, is a constraint to plan around. A deadline with nothing behind it is a preference, and knowing which one you have changes what you do when the plan does not fit.
Question 4 is answered optimistically by default. A full time person delivers three to four days of project work per week, and somebody split across two projects delivers considerably less than half of each. Ask for the real figure, then discount it.
Question 5 is the largest category of real project risk and the one least likely to be volunteered, because the team drawing the plan is thinking about their own work. Approvals, access, deliveries and other people’s availability are where projects lose weeks.
Scope first, and in writing
Almost every late project is a scope problem wearing a schedule problem’s clothes. Before any dates:
- What is being delivered. As deliverables, things that exist at the end and can be pointed at. Not activities
- What is explicitly not
- What “done” means for each deliverable. Objective enough that two people would agree
- Who accepts it, by name, and how long they have to do so
That last one prevents the most common quiet failure in project work: a deliverable that is never formally accepted and never formally rejected, so the project never ends and the final payment never falls due. Give acceptance a window, and say that silence past it counts as acceptance.
Where the project is for a client, this belongs in a signed statement of work with an explicit exclusions list, an assumptions list carrying the numeric ones, and a written change procedure agreed before anything changes. The same discipline applies to internal projects, where it is skipped far more often and costs just as much.
Break it down
Decompose until every task is something one person can finish in half a day to three days.
- Larger than that and you cannot tell whether it is on track. A two week task is 70% done for a fortnight
- Smaller than that and the plan becomes admin. You spend more time updating than working
Every task has: a verb, one owner, an estimate, and what has to finish before it can start. A task with no owner does not get done. A task with two owners does not get done either.
Decompose from the deliverable backwards, not from the calendar forwards. Ask what has to be true for this deliverable to exist, then what has to be true for that. Planning forwards from today invents work that fills the time available.
Estimating
The uncomfortable part, and the part that decides whether the plan is fiction. Method in references/estimating.md.
Three things that fix most estimating:
Estimate ranges, not points. “Three to five days” is honest. “Four days” pretends to a precision nobody has, and then gets treated as a commitment.
Ask the person who will do the work. An estimate made by someone else is a target, and people do not defend targets they did not set.
Use how long the last one took. Where jobs and tasks are tracked, the actual duration of comparable past work is the best estimating data available, and it is almost never consulted. The gap between what was estimated and what was taken, over the last ten projects, is the single most useful number in the business.
Buffer the project, not each task. Padding every task hides the padding and it gets consumed anyway, because work expands. One visible buffer at the end, sized at 15% to 25% of the total, is honest and defensible, and everyone can see when it is being spent.
Dependencies and the critical path
The sequence matters more than the durations.
- Mark what must finish before what can start. Most schedule failures are a dependency nobody wrote down
- Find the longest chain. That is the critical path, and it is the project’s duration. Work not on it has slack
- Improving anything off the critical path changes nothing. This is the most useful thing in scheduling and the most commonly ignored
- Client and third party dependencies go on the plan, with dates, not in prose. A project delayed by late approval should be visibly delayed by late approval
Approvals, deliveries, permits and other people’s availability are where real projects lose weeks, and they are the items least likely to appear in a plan drawn by the team doing the work.
Set it up in the tool
The plan lives in the task tool, not in a document. A plan in a document is out of date within a week and everyone knows it, which is why nobody opens it.
asana_create_project asana_create_task
clickup_create_task clickup_create_list
monday_create_item monday_create_board
jira_create_issue
trello_create_card trello_create_list
Set up rules:
- One project, one board. Split across two tools and neither is true
- Every task has an owner and a due date. No exceptions. An unassigned task is a wish
- Status means something specific. Define what “in progress” and “blocked” mean once, and hold to it
- Blocked is a status, and it is loud. The most valuable thing a task tool does is surface blocked work on the day it blocks, not at the weekly meeting
- Do not build a board with forty columns. Every column is a status someone has to maintain. Four or five
Status reporting
Weekly, short, same format, same day. Detail and a template in references/status-reporting.md.
The only format worth using:
Status Green / Amber / Red, and the word is a judgement, not a calculation
Done What finished this week
Next What finishes next week
Blocked What is stuck, who can unstick it, by when
Decisions What I need from you, by when
Say amber early. A project that goes from green to red in one week was amber for three weeks and nobody said so. The purpose of status reporting is entirely to surface problems while they are cheap, and a report that is green until it is a disaster has actively caused harm.
Decisions needed is the most valuable section and the one usually missing. Most projects wait on people, not on work.
Risks
Four to six real ones, reviewed weekly. Method in references/risk-register.md.
A risk register with twenty generic entries is a document nobody reads. Six specific risks, each with an owner, a trigger and a response, changes decisions.
The difference between a risk and an issue: a risk might happen, an issue already has. A risk that has occurred should be moved to issues and managed, not left on the risk list where it looks handled.
Rules
- Plan to the deliverable, not to the calendar
- One owner per task. Shared ownership is no ownership
- Update the plan, or stop pretending to have one. A plan that does not match reality is worse than none, because decisions get made from it
- Re plan when it changes materially. Twice in a project is normal. Once a week means the plan was never real
- Protect the critical path. Everything else has slack by definition
- Say the bad news early, plainly, with a proposal. “We are two weeks behind, here are three options” is a competent update. “We are still tracking to plan” from a project that is not is the thing that ends relationships
- Close it properly. Acceptance, final invoice, handover, and a short retrospective. Projects that trail off never get invoiced cleanly and never get learned from
What not to do
- Do not build a plan to a deadline that was set before the scope. Say what the date implies: a reduced scope, more people, or a missed date. Choosing is the client’s decision, making the choice invisible is your failure
- Do not pad every task. One visible buffer
- Do not confuse a task list with a plan. A plan has dependencies and a critical path. A task list has neither, which is why it always looks achievable
- Do not report percent complete. It is unfalsifiable and always 80%. Report what is finished and what is next
- Do not run status meetings that read out the board. Everyone can read the board. Meet about the blocked items and the decisions
- Do not skip the retrospective because the project went well. The ones that go well are where the repeatable practice is
Templates: assets/project-plan-template.md and assets/status-report-template.md.
Reference files
Everything the skill tells your AI to read, exactly as it ships in the zip.
references/estimating.md 6.1 KB
# Estimating
The part that decides whether the plan is a plan or a work of fiction.
## Why estimates are wrong in one direction
Estimates are not randomly wrong. They are systematically short, and the reasons are structural rather than personal:
| Cause | What it looks like |
|---|---|
| The happy path is imagined | Nobody pictures the third round of feedback |
| Interruption is excluded | The estimate assumes uninterrupted work that never happens |
| Coordination is invisible | Two people take longer than one person twice |
| Setup and handover are forgotten | The work is estimated, the wrapping is not |
| Optimism is rewarded | A short estimate wins the argument in the room |
| The unknown is excluded | You cannot estimate work you have not thought of, and it exists |
Knowing the bias is directional is what makes it correctable. A team that is consistently 40% short can apply 1.4 and be roughly right, which is far better than trying to be accurate task by task.
## Estimate in ranges
```
Best case 2 days everything goes right
Likely 4 days what usually happens
Worst case 10 days the known ways this goes wrong
```
A useful weighting is `(best + 4 × likely + worst) / 6`, which gives 4.7 days here. The arithmetic matters less than the conversation: **the gap between likely and worst case is the risk**, and a task where worst is five times likely is a task nobody understands yet.
Those are the tasks to decompose further, or to spike with a short piece of investigation before committing to anything.
**Never report the best case as the estimate.** It is the number people remember and the one they plan around.
## Ask the person doing the work
An estimate produced by a manager is a target. People do not defend targets they did not set, and they do not raise the alarm when a target they never believed starts slipping.
If the person doing the work is unknown at planning time, estimate for an average person doing it, and revisit when it is assigned. A task estimated for a senior and given to a junior has a different duration, and pretending otherwise is how a plan quietly becomes wrong.
## Use the history
The best estimating data in any business is how long comparable work actually took, and it is almost never consulted.
```
asana_list_tasks completed, with dates
clickup_list_tasks
jira_search_issues resolved, with time tracking
servicem8_list_job_activities hours actually worked on comparable jobs
```
Two numbers worth extracting:
**Your estimation factor.** Across the last ten to twenty completed projects, total actual divided by total estimated. If it is 1.4, you are 40% short and you now have a correction that works better than trying harder.
**The spread.** A factor of 1.4 with everything between 1.3 and 1.5 means you can plan confidently. A factor of 1.4 with a spread from 0.8 to 3.0 means the average is meaningless and the real problem is that some category of work is not understood. Find which category.
## What gets forgotten
Run this list against any estimate before committing:
- [ ] Setup, environment, access, accounts
- [ ] Waiting for other people. Approvals, deliveries, availability
- [ ] Review cycles. How many rounds, realistically, not ideally
- [ ] Rework after review
- [ ] Testing, checking, verification
- [ ] Documentation and handover
- [ ] The kick off and status meetings themselves
- [ ] Travel and site time
- [ ] Onboarding anyone new to the project
- [ ] The last 10%, which routinely takes 30% of the time
Review cycles are the single largest omission in client work. One round is assumed, three is normal, and each round has a waiting period attached that is longer than the work in it.
## Elapsed time is not effort
Four days of effort is not four days of elapsed time. It is four days of effort spread across the working week of someone who has other work, meetings, and a day off.
A rough rule: **a full time person delivers three to four days of project work per week.** Someone splitting across two projects delivers considerably less than half of each, because switching has a cost.
Plan in effort, schedule in elapsed time, and keep them clearly separate. Conflating them is why plans that are correct in effort finish weeks late.
## Buffer the project, not the task
Padding every task is the standard approach and it fails for two reasons: the padding is invisible, so nobody can tell what the real estimate was, and it gets consumed anyway, because work expands to fill the time available.
**One buffer, at the end, visible.** Sized at 15% to 25% of the total for familiar work, more for unfamiliar.
The advantage is that spending it is a visible event. When the buffer is down to two days in week three, everybody can see it, and that is a conversation that happens in time to do something. Padding hidden in forty tasks produces no such signal.
## Estimating to a fixed deadline
Frequently the deadline arrives before the scope. The estimate then has a different job: saying what the date implies.
Do the estimate honestly first, in isolation, then compare. If the honest estimate exceeds the deadline, there are only four levers:
1. **Reduce scope.** Usually the right answer, and usually available
2. **Add people.** Works early, does not work late, and never works linearly
3. **Extend the date**
4. **Reduce quality.** Happens by default when nobody chooses, which is the worst way for it to happen
**Present the choice, do not absorb it.** A plan that silently commits to an impossible date has converted a scheduling problem into a trust problem, and the second one is much harder to recover from.
## Track the error
After each project, one line:
```
Project Estimated Actual Factor
Bellhaven fit out 34 d 47 d 1.38
Corrigan upgrade 12 d 14 d 1.17
Maple Ridge 20 d 38 d 1.90
```
Three of these tell you almost nothing. Fifteen make you good at estimating, in a way no amount of care on any single estimate can.
Then look at the outliers. Maple Ridge at 1.90 has a reason, and the reason is usually a category of work, a type of client, or a dependency shape that repeats.
references/risk-register.md 4.5 KB
# The risk register
A risk register with twenty generic entries is a document produced to show that risk was considered. Six specific ones, reviewed weekly, change decisions. Aim for the second.
## Risk versus issue
- A **risk** might happen
- An **issue** already has
When a risk occurs, move it to issues and manage it. Leaving it on the risk list, where it now reads as anticipated, is how a live problem goes unmanaged for a fortnight because everyone assumes it is covered.
## What a real entry contains
```
RISK The ceiling grid subcontractor slips
IMPACT Level 3 rough in cannot start. This is the critical path,
so the finish date moves day for day
LIKELIHOOD Medium. They were 4 days late on level 2
TRIGGER Grid not started by 18 March
RESPONSE Weekly confirmation from Kane. If not started by 18 March,
bring forward the level 4 works and resequence
OWNER Ben
REVIEWED 14 March
```
The two fields that make it useful are **trigger** and **response**, and they are the two usually missing.
**A trigger is an observable event with a date.** "If it gets worse" is not a trigger. "Not started by 18 March" is. Without one, nobody knows when to act, so nobody does, and the register documents a risk right up until it becomes an issue.
**A response is what you will do,** decided now while there is time to think. "Monitor" is not a response. Deciding the resequence in advance means it takes an hour on 18 March instead of a week.
## Scoring
Enough to rank, no more. Elaborate scoring produces precision that does not exist and consumes the attention the register needs.
| | Low | Medium | High |
|---|---|---|---|
| **Likelihood** | Unlikely | Could go either way | Expect it |
| **Impact** | Absorbed | Date, cost or scope moves | The project fails |
High and high goes to the top. Low and low does not belong on the register at all.
**Impact is more useful than likelihood** for ranking, because an unlikely thing that ends the project deserves a response and a likely thing that costs half a day does not.
## Where to find the real ones
Generic registers come from a template. Real ones come from asking:
- **What has gone wrong on the last three projects like this?** The best source, and rarely consulted
- **What is on the critical path that we do not control?** Third parties, approvals, deliveries, permits
- **What are we doing for the first time?**
- **What did somebody mention in passing and then drop?** The offhand remark in a kick off is very often the risk
- **What would make this fail completely?** Ask the question directly. People know
- **Who is the single point of failure?** Usually one person, and usually everyone knows who
## Client and third party dependencies
The largest category of real project risk, and the one least likely to be written down, because the team drawing the plan is thinking about their own work.
Every dependency on someone outside the team is a risk. Approvals, sign offs, access, deliveries, decisions, other contractors. Put them on the plan with dates and on the register with triggers.
Say the consequence once, in the kick off, calmly: "if sign off takes more than five days, the finish moves day for day". Stated in advance it is a shared constraint. Stated after the fact it is an excuse, and it will be heard as one.
## Reviewing
Weekly, in the same pass as the status report. Five minutes:
- [ ] Has any trigger fired? If so, act, and move it to issues
- [ ] Has anything become more or less likely?
- [ ] Anything new this week?
- [ ] Anything that has passed and can be closed?
**Close risks that have passed.** A register that only grows stops being read. Closing an entry is also useful information: the thing you were worried about did not happen, and knowing which worries turn out to be unfounded makes the next register better.
## What not to do
- **Do not list risks with no owner.** Ownerless risks are not monitored
- **Do not write "monitor" as a response.** It means nobody has decided anything
- **Do not keep a register nobody reads.** If it is not reviewed weekly, it is not doing its job, and the honest move is to cut it to four items that are
- **Do not hide risks from the client.** A risk raised early is competence. The same risk discovered by them after it happened is something else
- **Do not confuse a risk with a complaint.** "The client is slow" is not a risk entry. "Approval taking more than 5 days moves the finish date, trigger 18 March" is the same observation made useful
references/status-reporting.md 5.4 KB
# Status reporting
The purpose is to surface problems while they are still cheap. Everything else about a status report is secondary, and any report that does not do this has negative value, because it creates the impression of oversight without providing any.
## The format
Weekly, same day, same shape, one page. Longer is not more informative, it is less read.
```
PROJECT Bellhaven fit out
WEEK ending 14 March
STATUS AMBER
ON TRACK FOR 28 April (was 21 April)
DONE THIS WEEK
Electrical rough in complete, levels 1 and 2
Switchboard delivered and stored on site
NEXT WEEK
Rough in, level 3
Data cabling starts, subject to the ceiling grid
BLOCKED
Ceiling grid on level 3 is 6 days behind. Owner: Kane at Vertex.
Chased 12 March, promised 18 March. This is the critical path.
DECISIONS NEEDED
Light fitting substitution, original is 9 weeks out. Two options
attached, roughly equal cost. Need a decision by 19 March or the
finish date moves again.
RISKS
If the grid slips past 18 March the 28 April date is not achievable.
```
Five sections. Every one of them is something a reader can act on.
## Status is a judgement, not a calculation
| | Means |
|---|---|
| **Green** | On track. No action needed from anyone reading this |
| **Amber** | At risk, or dependent on something outside my control. Action may be needed |
| **Red** | The date, scope or budget will not be met. A decision is needed now |
**Amber is the one that matters, and it is the one people avoid.** A project that goes green to red in a single week was amber for three weeks and nobody said so.
The reason people avoid amber is that it feels like an admission. It is the opposite: amber raised early, with a proposal attached, is what competence looks like. Red arriving without warning is what it does not.
**A useful rule: if you would be uncomfortable being asked "are you sure that is green", it is amber.**
## Do not report percent complete
It is unfalsifiable, it is always 80%, and it is the mechanism by which a project is 90% complete for six weeks.
Report what is **finished** and what is **next**. Finished is binary and checkable. If a deliverable list is needed, report it as a count of deliverables accepted out of the total, which is also binary.
## Blocked
The highest value section, and it needs three things or it does nothing:
1. **What is stuck**
2. **Who can unstick it**, by name, not by department
3. **By when**, or the consequence
"Waiting on client feedback" is not a blocker report. "Waiting on sign off from Dana, requested 8 March, chased 12 March. If it is not in by 18 March the finish date moves" is.
**Escalate on a schedule, not on feeling.** Raised in the report, chased once directly, then escalated. A blocker that appears in four consecutive reports and is never escalated has taught everyone that the report is decorative.
## Decisions needed
The most valuable section and the one most often missing. Most projects wait on people rather than on work.
Each decision needs the options, a recommendation, and a date by which it is needed. Presenting a decision without a recommendation pushes the work back to the reader, who has less context than you.
```
DECISION Light fitting substitution
WHY Original is 9 weeks out, we need them in 3
OPTIONS A: substitute, $400 more, available now (recommended)
B: hold the original, finish moves 4 weeks
NEEDED BY 19 March, or the date moves regardless
```
"Or the date moves regardless" is the sentence that gets decisions made. It states the cost of not deciding, which is the cost people ignore.
## Frequency and audience
| Audience | How often | What they want |
|---|---|---|
| The team | Daily, briefly | Blockers, today's work |
| The client or sponsor | Weekly | Status, decisions needed, dates |
| An executive above them | Monthly, or by exception | Dates, money, exceptions only |
**Never let the weekly report be the first time bad news is delivered.** If the date has moved, that is a phone call, today, followed by the report. Burying a slipped date in the fourth line of a weekly email is how a manageable problem becomes a trust problem.
## Status meetings
If the meeting reads the board aloud, cancel it. Everyone can read the board, and reading it aloud takes the time that should have been spent on the two items that need discussion.
A status meeting is worth having when it is about:
- Blocked items that need a decision in the room
- A trade off somebody has to choose
- Something that is easier to resolve by talking than by writing
Fifteen minutes, standing up, for most projects. The written report carries the information, and the meeting exists for the parts that need a conversation.
## Closing the project
The last status report is the close out, and it is worth writing properly:
- What was delivered, against what was agreed
- What changed along the way, and why
- Final dates and costs against the original
- What is outstanding, if anything, and who owns it
- Handover: who supports this now, and how
Then a short retrospective, separately, with the team. Three questions: what worked, what did not, what we do differently next time. Half an hour, written down, read before the next project starts.
**Do this for the projects that went well too.** The ones that went badly teach you what to avoid. The ones that went well are where the repeatable practice is, and nobody ever looks.
assets/project-plan-template.md 3.4 KB
---
title: Project plan
subtitle: <Project name>
client: <Client, or Internal>
author: <Project owner>
date: <Month Year>
version: <1.0>
---
<!-- The plan lives in the task tool. This document exists for the parts a task
tool holds badly: scope, acceptance, dependencies and the buffer. Write it
once, agree it, then work from the board. -->
## 1. What this is
<Two or three lines. What the project is for, in business terms. Not the method.>
| | |
|---|---|
| Sponsor | <Who wants this and can decide> |
| Project owner | <One name> |
| Start | |
| Target finish | |
| Budget | |
## 2. Deliverables
<Things that exist at the end and can be pointed at. Not activities.>
| # | Deliverable | Done means | Accepted by | Due |
|---|---|---|---|---|
| D1 | | <Objective enough that two people would agree> | <Name> | |
| D2 | | | | |
| D3 | | | | |
**Acceptance.** <Name> has <5> working days from delivery to accept or to state in writing what does not meet the criteria. A deliverable not rejected in writing within that window is accepted.
<That sentence prevents the most common quiet failure in project work: a
deliverable never formally accepted and never formally rejected, so the project
never ends and the final payment never falls due.>
## 3. Not in scope
- <Everything a reasonable person might assume is included and is not>
- <>
## 4. The work
<Decompose until every task is half a day to three days for one person. Larger and
you cannot tell whether it is on track. Smaller and the plan becomes admin.>
| # | Task | Owner | Estimate | Depends on |
|---|---|---|---:|---|
| 1 | | | <d> | |
| 2 | | | | <1> |
| 3 | | | | <1> |
**Critical path:** <the longest chain of dependent tasks. This is the project's
duration. Work off it has slack, and improving it changes nothing.>
## 5. Dependencies on other people
<The largest category of real project risk and the one least likely to be written
down. Approvals, access, deliveries, decisions, other contractors.>
| We need | From | By | If it is late |
|---|---|---|---|
| | | | <Say the consequence once, now, calmly> |
| | | | |
## 6. Schedule
| Phase | Starts | Ends | Deliverables |
|---|---|---|---|
| | | | |
| | | | |
| **Buffer** | | | <15% to 25% of the total, visible, at the end> |
<One buffer, not padding in every task. Spending it is then a visible event that
prompts a conversation in time to act.>
## 7. Team
| Person | Role | Availability |
|---|---|---|
| | | <Days per week actually on this. A full time person delivers 3 to 4 days of project work per week> |
## 8. Risks
<Four to six real ones. Trigger and response are the fields that make an entry
useful and the two usually missing.>
| Risk | Impact | Likelihood | Trigger | Response | Owner |
|---|---|---|---|---|---|
| | | | <An observable event with a date> | <What you will do. Never "monitor"> | |
| | | | | | |
## 9. How we will work
| | |
|---|---|
| Task tool | <Where the live plan lives> |
| Status report | <Weekly, day, to whom> |
| Escalation | <Who, and when> |
| Change control | <Any scope change is written, costed and approved before work starts> |
## 10. Done
The project is complete when:
- [ ] All deliverables accepted
- [ ] Final invoice issued
- [ ] Handover complete, with a named ongoing owner
- [ ] Retrospective held and written up
<Do the retrospective even when it went well. The projects that go badly teach you
what to avoid. The ones that go well are where the repeatable practice is.>
assets/status-report-template.md 1.5 KB
# Status report
<!-- Weekly, same day, same shape, one page. Longer is not more informative. -->
| | |
|---|---|
| Project | |
| Week ending | |
| Reported by | |
| **Status** | **Green / Amber / Red** |
| On track for | <date> <(was <date>) if it has moved> |
<Status is a judgement, not a calculation. If you would be uncomfortable being
asked "are you sure that is green", it is amber. A project that goes green to red
in one week was amber for three weeks and nobody said so.>
## Done this week
- <Finished, not in progress. Binary and checkable>
- <>
## Next week
- <>
- <>
## Blocked
<Three things or it does nothing: what is stuck, who can unstick it by name, and
by when or the consequence.>
| What is stuck | Who can unstick it | By when | Consequence if not |
|---|---|---|---|
| | | | |
## Decisions needed
<The most valuable section and the most often missing. Most projects wait on
people, not on work. Give options and a recommendation, not a question.>
| Decision | Options | Recommended | Needed by |
|---|---|---|---|
| | A: <br>B: | | <date, and what happens if it is missed> |
## Risks
<Only ones that changed this week, or whose trigger is close. The full register
lives separately.>
| Risk | Trigger | Response |
|---|---|---|
| | | |
## Numbers
| | Planned | Actual | |
|---|---:|---:|---|
| Deliverables accepted | | | <of total> |
| Days elapsed | | | |
| Budget spent | | | |
| Buffer remaining | | | <days of the original buffer> |
<Do not report percent complete. It is unfalsifiable and always 80%.>
