Task management

Task management is the tool class that holds accountable work: who is responsible for what, by when, and in what state.

Role in TFW

Task management is the source of truth for accountable work on a topic. It holds owners, status, dates, dependencies, and completion conditions.

It also holds the Focus System, which explains why the work matters. The Focus System has four levels:

Each level links to the level above it with a contributes to link. Objectives, intentions, and strategies are ongoing. They use a lifecycle status, not a closed status. Action records use the action workflow statuses.

In many organizations, the list of projects in the task management tool also serves as the registry: the list of topics that exist, with their codes and names.

Task management is not the source of truth for long explanations, large files, or conversation. Put a long explanation in the knowledge base and link to it. Put a file in document storage and link to it.

One topic’s surface

The example topic Example Co Operations (topic code EXOP) has one task management surface.

• Container. One project.
• Name and key. The project name is Example Co Operations. The project key is EXOP, the topic code. Every record in the project then carries the code, for example EXOP-42.
• Structure. The record types that the organization uses for the Focus System and for action records. Use the same types and the same workflow in every topic’s project where you can, so that people and AI agents can read every project the same way.
• Permissions. The project is visible to the participants inside the topic’s access boundary, granted through the topic’s group where the product supports groups.
• Maintainer. One named maintainer keeps the project’s name, key, configuration, and permissions correct.

Rules

• Each topic has one project. Do not create a second project for a subproject; use a strategy or a parent record inside the topic’s project.
• The project key is the topic code. If the product cannot use the code, record the key it uses as an alias.
• Put each record in its home topic. A record that relates to other topics links to them; it is not copied.
• Use the most specific valid topic. Do not put work in a broad general project.
• Each task has one accountable owner and a completion condition.
• A decision records the choice, the rationale, the person who made it, and the date.
• Keep descriptions short. State the intent, scope, current decision, dependencies, and links to evidence. Link to long content.
• Use the native fields for status, priority, rank, and due dates. Do not encode them in titles or labels.
• Link each action record to the strategy it contributes to.
• When a result comes out of chat, email, or a meeting, record it here and post the link back to the conversation.

Common mistakes

• Tasks that live only in chat. A commitment made in a chat thread and not recorded here is not tracked.
• Closing strategies. A strategy is ongoing. Closing it when one set of tasks is done removes the context for the next set.
• One project per initiative. Many short-lived projects split a topic’s work. Use records inside the topic’s project.
• Long narratives in descriptions. A record with pages of text is hard to scan. Move the text to the knowledge base and link to it.
• Different configurations in every project. If each project uses different record types and statuses, reports and agents cannot compare them.
• Inventing a project key. A key that does not match the topic code creates a second name for the topic. If a new topic is needed, report a registry gap and wait for approval.

Tools

• Jira: How to set up and maintain one topic's task management surface as a Jira project whose key is the topic code.

Other products in this class follow the same rules.