Three Project Tools, One Team: How It Happens

Ask a thirty-person company what it uses to track work and you get a pause, then a list. Engineering is in one tool. Marketing has boards in another. Someone in operations built something elaborate in a third. Every one of those decisions was correct for the team that made it. Together they mean that the only way to see what the company is doing this week is for somebody to open three tools on a Monday morning and type the answer into a slide.

This sprawl is different from the sales or support stacks, where the tools were bought to do different jobs. Here, three products do substantially the same job, and the company runs all three anyway.

The mechanism is local adoption. A project tool needs no procurement, no integration and no permission. One person starts a board, invites four colleagues, and a team has standardised on something before anyone senior hears about it. Repeat twice more and you have this.

Which is why the usual framing, that somebody made a bad decision, is wrong and unhelpful. Nobody decided. Three groups solved their own problem competently and nothing existed to coordinate them.

Entry-tier pricing from the registry our comparison pages use, at ten people.

$2,160 a year is not nothing, and it is also not the reason to do anything about this. Compared with the sales stack or the support stack, project tools are cheap, and one of the three frequently costs nothing at all, which is precisely why it never appears in a cost review.

The obvious move is to pick one and migrate. It fails more often than it works, for reasons worth understanding before trying.

Project tools are personal. People develop real workflow habits and asking them to change how they organise their day gets a stronger reaction than changing a CRM. This is not irrationality; it is that the tool is genuinely load-bearing for them.

The tools are not actually equivalent. A kanban board and a hierarchical task system encode different assumptions about how work flows. Migrating is not an export and import, it is a translation that loses something.

There is no forcing function. Nothing breaks. Nobody gets a bill that shocks them. The project is always worth doing and never urgent, so it is proposed every year and scheduled for after the current quarter.

The approach that works is gradual and starts by solving the actual problem rather than the visible one.

Fix visibility before you fix tools. If leadership can see across all three, the urgency drops and you buy time to do the rest properly. This is often enough on its own for smaller companies.

Pick the tool with the most existing users, not the best one. The migration cost is dominated by how many people have to change, and the second-best tool that most people already use beats the best tool nobody uses.

Move one team at a time, starting with the willing. One successful migration produces internal advocates, and advocates move the next team more effectively than a mandate.

Do not migrate history you will never open. Most completed work from two years ago is archive, not data. Export it, put it somewhere, and do not spend a fortnight recreating it.

Let the last team take longer. There is always one holdout with a genuine reason. Forcing them produces a public failure; leaving them for a quarter usually ends with them moving voluntarily.

The honest section, because consolidating for its own sake is its own kind of waste.

Genuinely different work is fine on different tools. Engineering running sprints and marketing running a content calendar are not doing the same thing. Forcing both into one shape usually makes one of them worse.

Few handoffs means little cost. The pain of sprawl is concentrated at the boundaries. Teams that rarely depend on each other pay very little for using different tools.

If the rollup exists, the problem is mostly solved. The thing you actually needed was a single view. If you have one that is not assembled by hand, plurality below it matters much less.

The general sequence for this kind of project is in the GTM stack consolidation playbook, and the individual comparisons are on the Trello, Asana and ClickUp pages. What is specific here is that the cost is attention rather than money, which is why this stack survives every budget review and still slows the company down.