How to choose the right work management system

Why use a work management system?

Work management systems are essential tools to make work visible, structured and governable across teams. Many systems explicitly support shared workflows, automation, multiple views, dependencies, permissions and cross-team reporting, combines projects, tasks, dependencies, workload, goals, reporting and workflow automation.

This can be extremely valuable for any company, team or individual.

Considering a 200-person company with Sales, Marketing, Product, Engineering, Operations and Finance. A request might originate in Sales, require Marketing input, then Product approval, Engineering implementation and finally Operations. Without a common work system, a lot of coordination happens through email, Teams/Slack messages, meetings and spreadsheets. A work management system gives the company a shared model that becomes particularly more valuable as the number of relationships between people and tasks grow. The system gives insights like

• Who owns this?
• What exactly needs to happen?
• What is the status?
• What is blocking it?
• When is it due or when can we start?
• What other work depends on it?
• What has already happened?
• And where are we falling behind?

The benefit at its core isn't primarily “task management”, but rather organizational memory and coordination. A work item can be a task, asset, document, purchase or other business object that moves through the organization.

The cost of complexity

Usually smaller companies do not have a coordination problem (yet). Most people face an attention problem: What do I have to do, how and when?

While large work-management platforms optimize the organization around the work. More simple, inbox-oriented systems optimize the individual around the incoming work.

A request for the latest pricing PDF within a 12-person team shouldn't necessarily require creating an issue, selecting a project, assigning a reporter, defining a status, adding a due date and then managing the resulting notifications. People just want to deal with the request. The rest should be optional.

There is a fundamental difference between structuring the work so the organization can coordinate it (platforms like Jira or Asana) and an inbox-oriented system (like Component4) that just say: »Here is everything that has arrived for you. Decide what matters and deal with it.«

Neither is inherently better. It depends on the requirements of your business and team and where the company's complexity comes from.

The cost of complexity in large project-based work management systems can have a negative impact on the overall work experience and might not be worth. Especially for smaller organizations. There are several layers to that cost, that might be great when you need them but are unnecessary when you don't:

• Cognitive overhead: Users must understand all elements of the underlying model and fundamental concepts.
• Administrative overhead: Users must decide which project it belongs to, should it be a task or an issue, or who owns a workflow.
• Behavioral overhead: User start optimizing for the tool not to get work done.
• Implementation overhead: The setup for the work management system gets more complex, too. And it needs constant adjustments.
• Optimization overhead: Workflows and systems get often premature designed to solve hypothetical challenges of the future, they require the extra cost now without benefits.

Ironically, the team can end up spending more time managing the system than the system was supposed to reduce.

Project-based vs Request-based

And not all work is project-shaped but rather request-shaped:

• Can you check this?
• Could you send me that?
• The customer needs an answer.
• Legal needs these numbers.
• Can you approve this?
• Please update the document.

Those things arrive continuously, aren't necessarily linked to a project and are often small enough that work-overhead can quickly accumulate. If you force every incoming request into a project-management paradigm, the company's communication flow is turning into a project database. But an inbox-first work management system like Component4 can instead treat incoming work the way it is: As a stream.

Incoming Understand Decide Do / Delegate / Schedule / Archive

That can be extremely efficient for smaller and even larger teams. Everything that requires your attention arrives in one place. And then the user simply decides to do it now, later, to delegate it, or to put it into waiting.

Why start lightweight?

When something becomes sufficiently complex it can still get promoted into a more structured object and get managed with more demanding project management tools like Microsoft Project, Jira or Asana. This way, additional structure and complexity are only introduced when necessary.

The mistake many implementations make is starting somewhere in the middle and assuming everything belongs there. But if most work can be described as “someone needs to do something”, you should keep it lightweight. Start with a request-oriented inbox-based system like Component4. Then, when required you can still introduce a heavier project-management layer where it is needed.