How to catch up on a project after months away

The project didn't change while you were gone. Your memory of it did. Here's the reconstruction method that works — and the reason it takes half a day when it should take a question.

A client goes quiet in April. In August the sponsor writes: "Good news — we're moving. Can you pick up where we left off Thursday?" Or you come back from four weeks away to an account you last touched in spring, and it is now the thing on Monday's agenda. Either way the situation is the same: every file still exists, every thread is still there, and you have no working memory of what was agreed, what was still open, or why you chose the option you chose.

The instinct is to open the folder and start reading forward. Don't. Reading four months chronologically means living through every problem that has since resolved itself, and it produces recognition rather than recall — you'll nod at each message and still not be able to say, on Thursday, what you committed to. What follows is the reconstruction that actually works, in order, and then the honest part: it only ever works as well as what you kept.

1. Find the last decision, not the last message

The newest email in a project thread is almost always logistics. Somebody resent a deck, somebody moved a call, somebody added a colleague. It tells you where the conversation stopped, not where the work stands, and starting there is how people end up confidently briefed on the wrong thing.

What you want is the last thing that was agreed: a scope, a number, a date, an owner. Two moves find it quickly:

• Search your own sent mail before anything else. On most engagements you were the one who wrote the confirmation — "to confirm what we agreed this morning…" — so your outbox holds the decisions in cleaner form than the inbox holds them. Filter to the client's domain, take the final three weeks before you stepped away, and read only what you wrote.
• Search for the words decisions leave behind. Agreed, confirmed, approved, signed off, as discussed, go ahead, revised. These terms are how commitments get phrased in writing, and searching for them is what collapses a long thread down to the few messages that actually changed something.

When you find it, note the date. That decision is your anchor: everything before it is history you don't need, and everything after it is either execution of it or drift from it.

2. Rebuild the timeline from what was agreed

Now build the artefact. One document, one dated line per decision, oldest first — not a summary of the project, a ledger of its commitments:

• Date. When it was decided, not when it was mentioned.
• The decision, in the client's terms. "Pilot extended to March at the current rate" beats "discussed timeline."
• Who made it. Decisions have owners, and owners leave companies — which matters in section three.
• Where it's recorded. The thread, the document, the note. So the next person who asks gets a link instead of your recollection.

A long engagement compresses much further than it feels like it should. That compression is the whole point: it is what you'll actually hold in your head on Thursday, and it's reusable — the same ledger answers the question again in November when the project goes quiet a second time. If you keep a running record per client, this is where it goes; the discipline is the same one that keeps several client relationships from blurring into each other.

Two things you should deliberately not do here. Don't summarise the discussion — nobody needs to relive the debate about the two options, only the option chosen. And don't trust file names: final_v3_revised is the version somebody last touched, not necessarily the version anybody agreed to. Match documents to decisions by date, not by label.

3. Mark what has gone stale

A four-month-old timeline is a set of facts with different shelf lives. Take a second pass and label each line one of three ways: still true, expired, or unknown. The third label is the valuable one — unknown is your question list, and knowing what you don't know is the difference between walking in prepared and walking in exposed.

4. Work out what changed while you were gone

Reconstruction tells you where you left it. Now close the gap between then and now, in ascending order of what it costs other people:

• The record. Filter everything on the project touched after your last active day, then read only the items that land on one of your timeline lines. Everything else is noise you can safely skip — the point of the ledger is that it tells you what to ignore.
• The people. Fifteen minutes with whoever held the relationship. Ask two closed questions — "what got decided while I was out?" and "what's stuck?" — because "can you catch me up?" produces a story, and you need a list. Take the answers straight onto the timeline.
• The world. The client's own news: a reorganisation, a funding round, a weak quarter, a new competitor. This invalidates more of your timeline than any internal thread will, and it's the one input nobody thinks to check when picking up a project after a long break.

5. Open with your understanding, not with a question

The last step is the one that protects the relationship. Before the meeting, send five dated lines: "Here's where I believe things stand — pilot extended to March, scope as of the 14 April note, the data question still open with Jordan. Tell me what I've got wrong."

Asking for corrections costs the other side two minutes; asking to be briefed costs them twenty and quietly tells them you lost the thread. It also surfaces the expired lines before you act on them, which is the actual risk of returning to a project after months — not that you know nothing, but that you confidently know something that stopped being true in June.

Where the standard advice runs out

Everything above works. It's also worth being honest about what it costs and where it fails, because both are structural.

The cost is the searching. Producing a short ledger takes half a day of scrolling, and nearly all of it is spent on messages you'll discard on sight. The value density of a project archive is brutal — most of what you read exists only so that you can rule it out.

The failure is worse, and it's the one nobody writes about. A thread records what was said, not what was decided. The real decision usually happened on a call — that's where clients change their minds — and the email afterwards says "great, as discussed, we'll proceed" without saying what was discussed. Four months later that sentence is unreadable. The same goes for the reason behind a choice: the timeline can tell you that you recommended option B, and almost never tells you why option A was rejected, which is precisely what you'll be asked on Thursday.

So the reconstruction is only ever as good as what you kept. Where you wrote something down, you can rebuild. Where you didn't, no amount of searching helps — and picking up a project after a long break is the moment you discover which of the two you did.

What changes if the record was kept as you went

This is the problem Equerry is built for. Keep the method above — the ledger is worth having either way. What changes is where the half-day goes, because the record you're searching was kept deliberately while the work was live:

• Put it on the thread while the project is live, not when it wakes up. Your Equerry address — mark@mail.getequerry.app, for instance — sits on the client threads as one more recipient, and a forward does the same job for the thread you never thought to copy it on, or the recap your meeting-notes app sends after a call. Everyone you've already approved on a thread keeps landing while you're not looking. Anyone new — the replacement sponsor, the procurement lead who appears in June — asks you once, with a single approval tap, and that tap is worth knowing about here: nobody answers approvals during a four-month silence, and one left unanswered lapses rather than waits. Who joined while you were gone is a decision you make on the way back in.
• Say the decision out loud the moment it's made. The reason behind a choice is the one thing a thread never carries. A minute of dictation on the way out of the room — "Acme: rate holds, pilot runs to March, Jordan owns the data pull, they turned down the phased option because of their audit timing" — is the sentence the email afterwards will never contain, and it's what makes "why not option A?" answerable in August. A typed note, a photograph of the whiteboard, or the signed page as a PDF all land the same way.
• Ask the ledger question instead of scrolling for it. "What did we agree on the Acme scope before April, and what's moved since?" When an answer draws on your notes, emails or the web, it shows where it came from — the message, note or memo — so you can open the original and read the sentence for yourself. That step earns its keep on an old project more than anywhere else: a fact from April deserves checking rather than repeating.
• Test the awkward ones privately. "Did anyone ever answer my question about the data feed?" is a question you can put to your own archive and one you'd rather not put to a client. That gap is the whole difference between re-asking and remembering.
• Let the first morning back open with a brief. A Morning Brief lands at whatever hour you set it, drawing on today's calendar and the replies that arrived since the last one — so the day the project restarts begins with a read rather than a search.
• What it sees, and what it doesn't. There's no connection to your mailbox: the threads you CC or forward are the only mail it ever reads. Beyond those it holds what you saved — notes, voice memos, photographs, documents — and it reads the calendar on your iPhone, which is how a brief knows what today looks like. Everything it remembers is listed for you to open and delete, one item at a time.

The shift isn't a tidier archive. It's that the four-month gap stops being a reconstruction project. You kept the decisions as they happened, in the form they actually occurred — a spoken sentence after a call, a forwarded thread, a photographed page — and coming back to the project becomes a question you ask rather than a morning you lose.

If your work runs on engagements that go quiet and come back, the habit worth building is the small one: record the decision when it's made, not when you need it. A shorter gap is a different job — two weeks away leaves you a backlog to clear rather than a record to rebuild, which is catching up on email after a holiday. Otherwise: how to hold on to what was actually decided in a meeting, or how to keep track of what's still waiting on whom once the project restarts.

Last updated 2026-08-29.