If it isn't in the project's home, it doesn't exist
Every project produces information. Who's involved and what they expect. The plan and its milestones. Risks, issues, decisions, meeting notes, status reports. A few weeks in, it's spread across email threads, chat messages, slide decks and a couple of people's heads. Then someone asks where the project stands, and the only way to find out is to organize a meeting.
In this article, I want to show you what information a project produces and how to organize it so you always know where things stand. It's a project management article first: where does a project's information live, and who keeps it current?
It comes down to three ideas:
- One home, written down. If it isn't in the project's home, it doesn't exist.
- Document for the next person. Documentation is part of done.
- Know where things stand, in layers. A board for the detail, a summary for the big picture.
In my previous article, I shared a one-pager every project needs: the finish line, the deliverables, the why, the scope, the owner, the status and the next action. That one-pager sits at the top of the project's home. This article covers everything underneath it.
One home, written down
My rule is simple: if it isn't in the project's home, it doesn't exist. Every project needs a single source of truth, and everything else should link to it. GitLab applies the same idea to its whole company and calls it "handbook first": write the answer down in the handbook, then link to it instead of answering the same question again.
The home can be a note, a wiki page, a shared document or a folder with an index page. What matters is that there's exactly one entry point, and that everyone knows where it is. It can hold everything, or be a reliable index that points to where each piece lives. An index only works if it stays current.
When I wrote about building a product from idea to code in 2022, that's how we organized the work. We had a shared space whose homepage listed three things: the current focus, the next steps and the open questions. As I wrote at the time: "This space acts as our single source of truth to this project. It's the entry point to everything else."
Conversations will still happen in chat, by email and in meetings. That's fine, as long as their (useful) outcome goes back to the home. In 2020, I described how I took notes at work: my paper notebook was personal, so I couldn't share it with anyone. After a meeting, tasks went to the issue tracker, and meeting minutes went to a wiki page "for everyone to see". Your private notes work the same way. They're useful to you, but they aren't the project's memory.
And don't misunderstand me. As I explained in my previous article, the idea is not necessarily to store everything in ONE location, but to have a SINGLE place where you can go and find anything, whether it's right there or somewhere else.
Writing things down also forces you to think, as I mentioned last time. Frederick Brooks made that point in The Mythical Man-Month (chapter 10, "The Documentary Hypothesis"): "writing the decisions down is essential. Only when one writes do the gaps appear and the inconsistencies protrude."
The same structure for every project
One more recommendation: use the same organization for all your projects. When every project has the same folders, subfolders and documentation sections, in the same order, you know where to look the moment you open one. That helps when you hop from one project to another during the week, and even more when you come back to a project after a long time.
The simplest way to get there is to start every project from the same template: the one-pager, then the same sections underneath. For files, pick one method and stick to it. The PARA method is a good example (I explain it in this article): each project gets its own folder under Projects, with the same subfolders inside for presentations, meeting notes, resources, the project charter, and so on.
The structure doesn't need to be clever. A simple one you use everywhere beats a perfect one that changes from project to project. Just make sure you improve your template over time so it remains relevant, and keep ongoing projects aligned too. Don't be too "religious" about it, though.
What about search?
Some people skip organization altogether. Dickie Bush keeps his to-dos, documents, meeting notes and project plans in a single notes app. He doesn't organize them; he relies on the search bar to find what he needs.
When you're alone and you know what you're looking for, that can work. A team is different. Someone who joined last week doesn't know which decisions were made, what they were called, or that a risk was already spotted. You can't search for something you don't know exists. A project home lets people find things without knowing what to search for.
What lives in the project home
Beyond the one-pager, most projects produce the same types of information. Here's why each one matters, where it lives and the minimum to keep. Short things that change rarely are sections of the home itself. Long or recurring ones (meeting notes, reports) get their own pages, linked from the home.
| Information | Why it matters | Where it lives | The minimum to keep |
|---|---|---|---|
| Stakeholders and team | You need to know who to inform, who decides and who to ask | A section of the home | Name, role, and what each person needs from the project or decides about it |
| Plan and timeline | It's the snapshot you compare reality against | A section of the home | Milestones with target dates, the next milestone, dependencies on other people or teams |
| Risks and issues | A risk might happen; an issue already has. Both need someone watching them | A section of the home | One line per item, with an owner, a mitigation and a status |
| Decisions | Without a record, settled questions get debated again and the reasons get lost | A decision log in the home | What was decided, why, the alternatives, when, and what it affects |
| Meeting notes | A meeting that leaves no notes leaves no decisions and no follow-up either | One page per meeting, linked from the home | Date, attendees, decisions taken, actions with owners |
| Progress and reports | They show how the project evolved, and where it is today | A dated progress log, plus each executive summary | One dated line per notable change; past summaries kept |
| Lessons learned | Your next project should start smarter than this one | A section of the home | What worked, what didn't, what you'd change, written as you go |
Meeting pages record a ton of useful information, but people won't read them all. Copy the decisions taken in a meeting into the decision log, and put the actions on the board. Meeting pages remain there as "evidence" and as reference.
For technical projects, Architecture Decision Records (ADRs) (Michael Nygard, 2011) are a well-known version of the decision log. Meetings only produce decisions when they're designed to. A RACI Matrix helps settle who decides what. And a Pre-mortem helps you find risks early.
Document for the next person
The second idea: documentation is part of done.
In 2020, I wrote an article about the bus factor for team leaders and managers. The bus factor is the number of people who can disappear before a project gets stuck. One of my recommendations was fresh documentation, and here's what I wrote: "Documentation needs to be a priority and part of the definition of done. You just can't accept a situation where important information only exists in the head of some team member."
In practice, that means a Definition of Done that includes the documentation. The decision is in the log, the process is written down, and the home reflects the change. If the knowledge only lives in someone's head, the work isn't finished.
And documentation is the whole team's responsibility. Not only the project manager's, the technical lead's or the architect's: everyone contributes. Whenever you do something, make sure it's properly documented. Whenever you notice something wrong or outdated, either fix it or let its owner know. It's not about nitpicking. It's part of what "done" means on a project.
Too often, I've seen people invest heavily in getting everything else right, then skip the documentation or push it back to "later". Often, later never comes. Or it comes at the very end, when there's no time left, and the job gets done sloppily. That's a failure. When deadlines get tight, documentation is usually the first thing to go, unless someone on the team defends its importance.
The form matters less. In the same article, I listed wiki pages, documents on a shared drive, schemas, videos and specifications, then added: "Use whatever makes sense, but ensure that it can easily be found from a single source of truth."
Freshness matters a lot, though. I also wrote that "having out of date documentation is downright dangerous". People trust what's written. A stale plan or an owner who left months ago sends them in the wrong direction. So keep relevant information up to date, and prune what's outdated or irrelevant. When something changes, update the home in the same step instead of "later".
Who's the next person? A new team member. Someone replacing a colleague who left. The sponsor catching up before a steering meeting. Or you, three months from now, trying to remember why you chose this approach. When knowledge lives only in people's heads (Tribal Knowledge, Tacit knowledge), every departure takes a piece of it away (Knowledge Drain).
Two habits help. Document more than you feel like you need to; what's obvious to you isn't obvious to someone coming from elsewhere (that's the curse of knowledge). And avoid job protection: keeping knowledge to yourself so you stay indispensable hurts the team. A Team onboarding document is a good place to practice: ask every newcomer to fix what was wrong or missing, so it stays relevant for the next one.
Also, you can use the "fresh eyes" of new team members to get a critical look at what you have in place. Oftentimes, we're so used to our situations that we fail to notice the issues.
The bus factor article also covers the practices that reduce that risk directly: backups, rotation, pair work and knowledge transfer sessions.
Know where things stand, in layers
The third idea: anyone involved should be able to tell where the project stands without calling a meeting. That takes at least two main layers of visibility, both kept up to date, at different rhythms.
The bottom layer: the board
The bottom layer is a Kanban board or a task list. Each item has (at least) a description, a status and an owner. Whoever does the work updates it, continuously: when they start something, when they finish it, when they're blocked. That turns the board into an information radiator: it shows the state of the work without anyone having to ask.
The board is mostly for the people doing the work. It answers "who's working on what, and what's stuck?". It contains all the details at the lowest level the team needs.
The top layer: the executive summary
A sponsor or a steering committee won't read dozens of cards to find out whether the project is on track. They need a summary, updated weekly or before each steering meeting. Here's what goes in it:
# <Project name>: status on <date>
- Overall status: <red, amber or green>, because <one line>
- Progress vs plan: <milestones reached>; next: <milestone> on <date> (<how confident you are in that date>)
- Top risks and issues (three at most): <item>, owner <name>, mitigation <what you're doing about it>
- Decisions or help needed: <what>, from <whom>, by <when>
- How the plan needs to evolve: <what you've learned that changes the plan>The red, amber or green rating is often called a RAG status. Always put the one-line reason next to the color.
The last line is the agile part. Plans change as you learn, and that's healthy (the Agile Manifesto values "responding to change over following a plan"). But changing the plan of a project others depend on needs management and stakeholder buy-in. Ask for it in the summary, as soon as you see that the plan needs to change.
The two layers have to agree. Write the summary from the board and the home, never from memory. If the board shows blocked items the summary doesn't mention, fix the summary.
That's also why alignment is critical between whoever is the project manager and the team. Both need to stay in sync so that whatever ends up in a management summary matches the shared vision and the reality. And it goes both ways.
Three angles on the same information
The home, the documentation and the two layers apply to every project. Who maintains what depends on where you sit.
If you're a solo creator
Nobody asks you for a status report, so it's tempting to keep everything in your head. Don't. Your next person is you, coming back to a paused project months later.
Keep a lightweight home: the one-pager, a short decision log and a dated progress log. You can skip the executive summary; the status and the next action on the one-pager are enough when you're the only reader.
If you're a project or program manager
The home and the executive summary are yours. Others contribute, but you keep them current, and you make documentation part of the Definition of Done for the whole team. When a deliverable is "done" but the project documentation hasn't changed, it isn't done yet. Ask for the update when the work is delivered, while people still remember the details.
If you're a project team member
You own the bottom layer for your own work. Keep your items on the board current, with a status that reflects reality. Documenting your work is part of your job, not the project manager's. When you take part in a decision, or learn something the next person will need, write it back to the home. When you spot something wrong or outdated, fix it or tell its owner.
This applies to junior team members too. Give feedback, share your ideas, and let people know when something's wrong, whatever your role or seniority. A good team is a safe place where everyone can speak up, and it needs that to keep its documentation (and everything else) honest.
Conclusion
Project information is only useful if people can find it and trust it. Give every project one home, organized the same way every time, make documentation part of done, and keep two layers of visibility: a board updated by whoever does the work, and a summary updated every week or so.
Start with your current project. Could a new team member find its plan, its open risks and its last decisions without asking anyone? If not, that's the first thing to fix.
This article covers where a project's information lives. The Knowledge Worker Kit has a whole part on organizing projects, and others on planning and prioritization and on task management:
Knowledge Forge •Richard ElliottThat's it for today! ✨
Go Further
Sébastien Dubois •Sebastien Dubois
Sébastien Dubois •Sebastien Dubois
Sébastien Dubois •Sebastien DuboisKeep reading
Subscription details
You are receiving this because you are a free subscriber to Sébastien Dubois.
Email: [subscriber]
Member since: 19 October 2026
Passion makes all the difference.