Writing

A status file for every project

I usually have a dozen or more analytics projects open at once. Most of them are waiting on something: a decision, a credential, a stakeholder’s answer. The cost isn’t the work. It’s remembering where each one stands when I come back to it.

What fixed it for me is small. Every project gets a status file, and the file has the same five parts.

  1. Current status. A few sentences on what is true now, written for someone with no context. Usually that’s me in three weeks.
  2. Open questions. What I don’t know yet, and who can answer it.
  3. Next actions. Concrete steps, in order. “Review the output with the team,” not “continue analysis.”
  4. Blockers. Anything that stops progress regardless of effort, kept separate so it doesn’t hide in the to-do list.
  5. Key files. Where the work lives, so I don’t have to search for it.

Update it when you stop, not when you start

The file is only useful if it’s current, and the only reliable moment to update it is the end of a working session, while the details are still in your head. Two minutes then saves twenty later.

Let it tell you what’s stale

Because the files share a format, a short script can read all of them and print a briefing: what’s blocked, what’s waiting on me, and what hasn’t been touched in a week. I start the day with that list. It’s more accurate than my memory, and less optimistic.

The same habit works in a notebook. The format matters less than the rule: no project gets put down without a note about where to pick it up.