Organizational Memory
Project systems card, MethodKit for Memory & Reminiscence
Card 52 of 66 · MethodKit for Memory & Reminiscence
  • ThemeOperations & Process
  • CardCard 52 of 66
  • Questions5 to explore
Operations & Process

Project systems

Docs, todos, CRMs & project management

The tools the organization uses to track work are themselves part of the organizational memory, and they are often in a state that only the person who set them up fully understands.

Project management tools, task trackers, CRMs, documentation platforms, and shared drives accumulate structure over time: folders, tags, pipelines, custom fields, naming conventions. That structure embeds decisions about how work is organized, and when it is not explained anywhere, new people either misuse the system or build their own parallel one.

The question is not which tools to use but how and why the current setup works the way it does: what goes where, what the naming conventions are, which integrations matter, and who is responsible for maintaining the structure.

Project systems also tend to drift. A system that was set up carefully two years ago may have been patched, extended, and partly abandoned in ways that make it hard for anyone to use reliably. Knowing the current state, accurately, is more useful than inheriting an optimistic picture.

What to capture

For this part of the company brain, what is worth writing down and keeping current. The goal is not a complete archive but a living record that new people can read and returning people can trust.

Tool inventory

A list of the tools in use for project management, task tracking, documentation, and CRM, with a note on what each one is used for and who the administrator is.

Structure & conventions

The key structural choices in each tool: how projects or folders are organized, naming conventions, what tags or fields mean, and where the main views live.

Integrations & automations

Any connections between tools or automated workflows, where they are documented, and who to contact when they break.

Access & admin

Who has admin access to each tool, how new users are added, and where the credentials or account information is stored.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

  1. Which tools are the authoritative home for active projects, tasks, and customer relationships, and do people actually use them that way?

  2. What are the structural conventions in each tool, and are they written down anywhere that new people can find?

  3. Who administers each tool, and what happens to access and setup if that person leaves?

  4. Are there integrations or automations between tools that people rely on, and is anyone responsible for maintaining them?

  5. Which tools are being used less than intended, and what does that reveal about where the real workflows actually happen?

Things to notice

  • Project systems that look organized from the outside often have significant disorder underneath; the folders exist but the naming is inconsistent, the tags are no longer meaningful, or half the active projects are not in the system at all.
  • Automations set up by one person and not documented are a quiet risk; they run reliably until they break, and when they break nobody knows what they were doing.
  • The gap between the intended use of a tool and its actual use is often large; documenting the intended use without acknowledging the gap can mislead new people who then waste time trying to work a system that is not how the team actually operates.