Running a project in one place: how to stop reconstructing status from four systems

It is 4:10 on a Thursday and your director sends five words: "quick status on billing migration?" She wants something for tomorrow's staff meeting.

You are running this project. Nobody knows it better. You still cannot answer in under twenty minutes.

The scope cut is in a Slack thread from three weeks ago, twelve messages down, underneath an argument about naming. The reason for the cut came out of a meeting on October 1, and the note for that meeting reads "discussed phasing" and nothing else. The rollout dates live in a spreadsheet Marcus owns. Two of the four open questions exist only in your head. The tracker has every ticket, accurate about what is being built and silent about why any of it changed.

At 4:31 you send three sentences. They are probably correct. You are not confident enough to say so, so you end with "as far as I know."

The reconstruction tax

Every time someone asks where a project stands, somebody rebuilds the answer from scratch out of systems that each hold one piece of it. That rebuild is the reconstruction tax.

It is charged to the person carrying the most context, whose time you least want spent on retrieval. It is charged at the worst moment, because nobody asks for status on a quiet Tuesday; they ask forty minutes before a meeting or an hour after something went wrong. And the output is thrown away: you assemble twenty minutes of state, compress it into three sentences, send it, and close the tabs. Next Thursday someone asks again. Twice a month is a light rate for anything a director is watching, and at that rate a six-month project absorbs two dozen rebuilds of the same paragraph.

This is not a symptom of disorganization. Well-run projects pay it too. It is a symptom of a project having no single surface, which is the default condition of almost every project at almost every company.

Why project context fragments by default

The reason is not that people choose badly. It is that each tool a project touches is excellent at one kind of content and bad at the kind sitting next to it.

Chat captures the discussion and loses the decision. A Slack thread is the highest-fidelity record of how a group reasoned through a problem and the worst place to store the conclusion. The decision is the last message in a thread of forty, formatted identically to the thirty-nine before it, findable only by someone who already knows it exists.

Documents capture the artifact and lose the reasoning. A spec describes the current plan. It gets rewritten as the plan changes, which is correct, and the rewriting destroys the record of what the plan used to be. Six weeks later someone asks why you are not doing the second phase, and the document contains no trace of one ever having existed.

The calendar captures when things happened and nothing about what came out. Your calendar knows a 45-minute billing migration review took place on October 1 with five people in it. It does not know that the review is where the phasing decision got made. The calendar is a complete index with no contents.

Task trackers capture the what and lose the why. A ticket describes work to be done, precisely, in the vocabulary of implementation. Ask a tracker why something was closed as won't-do in July and you get a one-line comment at best.

Nothing is wrong with any of these tools; each is close to optimal for what it captures. The fragmentation is emergent, the product of four locally correct choices made by different people at different times, none of whom was deciding where project context should live. That is why it never feels like anyone's fault and why nobody fixes it.

What fills the gap is memory. Daniel Wegner's work on transactive memory describes what groups do instead of writing things down: each person holds a slice, and the group keeps a rough directory of who holds which slice. A project with no surface runs on this almost entirely, and it holds until the holder is on vacation, changes teams, or is the person being asked for the status.

What a project surface actually has to hold

A project is not a folder of documents. It is a moving thing, and the surface representing it has to hold five kinds of content. Most project pages hold two.

The state. Where this stands, in one paragraph, with a date on it. This answers the 4:10 Thursday question directly, and it is the one almost nobody maintains.

The decisions. What was decided, when, and why. The most valuable and most commonly lost artifact on any project, and one whose value is asymmetric in time: worth almost nothing the week it is written, worth an hour of argument six months later when someone proposes the thing you already rejected. The format is a solved problem: one dated line per decision, what was chosen, what was rejected, and what would make you revisit it. What matters here is that the project gets its own.

The open questions. What is unresolved, who owns resolving it, and by when. An open question with no owner is not a question, it is a wish. Putting a name next to each one is where most of the value is, because it converts ambient anxiety into either a task or a decision.

The commitments. Tasks with owners and dates. Your tracker probably does this well, so point at it rather than duplicating it, but the surface still has to hold the commitments that never become tickets: the promise to talk to legal, the follow-up with the vendor, the thing Dana said she would confirm.

The record. The meetings, linked to what came out of them. Not transcripts. One line per meeting with the date, who was there, and the one or two things that changed as a result. This is what makes a decision defensible when someone challenges it, and it works best when the note and the calendar event are the same object rather than two things you reconcile by date.

The state paragraph is the whole trick

If you adopt one thing here, adopt this: put a paragraph at the top of the surface saying where the project stands, date it, and rewrite it rather than appending to it.

Rewriting is the part people resist and the part that matters. The instinct with any running document is to append, because appending is safe and preserves history. For this artifact it is exactly wrong. A log of past states does not answer "where does this stand." It hands the reader raw material and asks them to derive the answer, which is the reconstruction tax again, moved from your Thursday afternoon to theirs. The state paragraph is a cache, and a cache that keeps all its old values is not a cache. It is a log, and it fails at the one job it has.

The decision log directly below it takes the opposite rule: append, never edit. Its value comes from entries being immutable and dated. "October 13: cut phase two from Q4 scope. Vendor rate limits made that path unviable before February, and shipping phase one on time beat slipping both. Revisit if the limits are raised." Edit that later to match what you now believe and you have destroyed the reason you kept it. When someone proposes phase two again in March, you do not want your current opinion. You want what you knew in October, including the part you turned out to be wrong about. One artifact answers "what is true now" and gets rewritten; one answers "what was true then, and why" and gets appended. Mixing them produces a page that does neither job, which is what most project pages are.

A good state paragraph runs four to six sentences and takes ninety seconds to write. "As of October 23: phase one is in staging, on track for the November 6 cutover. The vendor rate limit issue from early October is resolved. Two risks remain: finance has not signed off on the reconciliation report, and we have not tested a rollback under load. Marcus owns the load test, due October 30." Anyone can now answer for you, which is the actual goal. The surface should make you replaceable as a status source.

How the surface changes across a project's life

The shape is not constant, and treating it as constant is why most project pages die in week three.

At the start it is sparse, and that is correct. A new project has one paragraph of state, three open questions, no decisions, and two meetings. Do not build a template with eleven headings for it. Empty sections train people to skim the page, and a page people skim is a page nobody updates. Start with the state and the open questions; add sections when you have content for them.

In the middle it is dense and needs pruning, not just adding. By week six the open questions list has fourteen items, four of which were answered in a meeting nobody logged. The work in the middle of a project is mostly deletion: closing questions, promoting the resolved ones into the decision log, rewriting the state so it describes October rather than September.

At the end almost everyone stops updating and walks away. The project ships, the channel goes quiet, and the surface freezes three weeks stale and slightly wrong forever. This is the most expensive omission in the lifecycle, because the closeout is what makes the next similar project cheaper. Twenty minutes at the end buys back days at the start of the next one.

The closeout is short and specific. Rewrite the state paragraph one last time in past tense: what shipped, when, and what did not make it. Then add three things. What you would do the same way. What you would do differently, stated as a change to the process rather than a regret. And the estimate gap: what you thought this would take, what it actually took, and the specific reason for the difference. That last item is the only reliable way any organization gets better at estimating, and it is impossible to reconstruct three months later.

The single-surface protocol

Three moves, all of which fit inside the time you already spend answering status questions.

1. The ten-minute setup. Once, at kickoff, or today on a project already running. Create one page with five headings: State, Decisions, Open questions, Commitments, Meetings. Write the state paragraph first, dated, even if it is bad. Then spend four minutes on archaeology: scroll the project channel and the last two meeting notes and pull out every decision you find, one line each, date and choice and reason. Three to six is a normal haul, and at least one will be a decision you had forgotten was made. Then list every open question you can name and put a person next to each. If you cannot name an owner, you have found the most important item on the page.

2. The Friday five. Five minutes, same time every week, on the calendar as a real recurring event. Rewrite the state paragraph from scratch; do not edit last week's. Move any question answered this week into the decision log with its reasoning. Add new questions. Check the commitments for dates that have passed. Five minutes is a constraint, not an aspiration: if the update takes twenty, the surface has turned into a document, and documents do not get maintained.

3. The closeout. Thirty minutes in the final week, scheduled while the project is still alive, because it will never get scheduled afterward. Run the four items above, then link the page from wherever the next person will look.

Run this for three weeks. The test is simple: the next time someone asks where the project stands, you answer by copying a paragraph.

Frequently asked questions

My team already uses Jira, Notion, or Linear. Is this a replacement? No. This is the layer above whatever you use, and it is deliberately small. Your tracker holds commitments better than a page ever will.

The gap is narrower than it used to be. Linear ships project updates: the owner writes an update and marks the project on track, at risk, or off track. That covers a real part of this, and if your team lives in Linear you should be using it. But updates arrive as a feed of dated entries, which makes them a decision log with a health flag on it rather than a paragraph you rewrite. The current-state job wants a field that gets overwritten, which is what Linear's project description is for. Jira gives you a board, Notion gives you a status property and a progress bar, and all three describe the work rather than the situation the work is in. The surface points at the tracker and owns the state, the decisions, and the open questions.

Who maintains it? One person, named, and it is whoever answers the status question today. Shared ownership is the failure mode: a surface three people are responsible for is a surface with a nine-day-old state paragraph. Everyone else contributes to the record and the open questions. Only the owner rewrites the state.

What about a project with six people versus one with sixty? The surface is the same; what changes is who reads it. On a six-person project it mostly replaces your own memory, and the decision log carries most of the value. On a sixty-person project it is a broadcast channel, and the state paragraph carries most of the value, because it is the only thing preventing forty separate reconstruction requests. Sixty-person projects also need a sub-surface per workstream, each with its own state paragraph, plus a top-level paragraph that is a synthesis rather than a concatenation.

Is this not just a project management tool with extra steps? Project management tools model work as a graph of tasks with owners, dependencies, and dates. That model captures roughly one of the five things on this list. The four it does not capture, the state, the reasoning, the unresolved, and the record, are the four that make up the twenty-minute reconstruction. A Gantt chart has never once answered "why did we cut that."

How is this different from a weekly note? The weekly note is time-scoped: everything you are doing this week across every project, and next week you start a fresh one. The project surface is project-scoped and persistent, holding one project from kickoff to closeout across forty weeks if it takes that long. The weekly note points at the projects; the projects hold the durable record. Where all of it gets filed is a third question, covered in the WLCS note organization system.

Closing thought

"Where does this stand" is not an interruption. It is the project asking whether anyone is holding it in one piece. If the answer takes twenty minutes of archaeology, the honest reading is that nobody is, and the reconstruction you do on Thursday afternoon is the only moment the whole project exists in one place at one time. That should not be a moment. It should be a paragraph.

Try the ten-minute setup on one active project, in whatever tool you already use. Five headings and a dated paragraph at the top work in any notes app, and the discipline matters far more than the software. Do put the Friday five on the calendar as a real recurring event, though. Unscheduled maintenance does not happen.

If you use nocal, a Space is where this lives: the project's notes, meetings, and tasks on one surface, tasks in the sidebar, meeting notes attached to the events they came from. The state paragraph goes at the top of the space's note.

The mechanics are identical anywhere else. Only the number of tabs changes.