Before You Switch Project Management Tools, Try These 5 Things
Here’s how it typically starts.
“I put the update in Monday.com”.
“Oh, I didn’t see it. I didn’t check there.”
(this goes on for awhile until there’s a major fire because someone missed an update in Monday.com).
Leadership is furious. They need a reason for the failure. “Nobody uses Monday.com,” the team explains to leadership.
Leadership sets out to find a new tool. A better tool. A tool that will fix this issue once and for all.
Can we tell you a secret?
The project management tool you choose doesn’t matter as much as you think. At their core, they all do the same thing, albeit some are better at certain things than others.
The issue at its core is, if the behavior around the tool isn’t tended to, the workspace becomes a graveyard for tasks, status updates, and expectations.
We get approached weekly with people asking us to help them migrate project management tools. Which, we can do all day long. We’ve done plenty of project management tool implementations (one of our best was a migration from Trello to Monday.dev).
But when we’re approached for this, one of our first questions is always: “What is going to be different in this new tool?”
Why does switching project management tools not always fix delivery problems?
Switching tools feels like enormous progress. It’s a very clear initiative with a tight scope and a clear starting and ending point. But it’s a high cost for very little guaranteed output.
Time to rebuild every project, template, and integration in the new tool
Every person on the team has to learn new screens and new habits, while still delivering client work
Comments, files, and decisions rarely move over cleanly, it’s the most difficult part of a migration and losing that context can be critical to client work
And the part nobody ever wants to hear?
All the habits you had in the old tool just accompany you into your journey with the new tool. If work was being submitted through chat channels before, a new tool isn’t going to just magically solve that. If people weren’t checking Monday.com for statuses, they sure aren’t going to magically start checking ClickUp.
Things get better at first and usually any new behavior lasts less than a month. Or the habits only survive until the first fire.
Why does this happen?
Because there’s nothing wrong with the tool you chose. We just need to make that tool work. And how we make that happen is through behavioral change and change management.
The majority of project management tools are built out in one of two ways:
You roll with the tools default interface and just force your tasks into it
You mirror your org chart and build out spaces for Design, Development, and Accounts, with no strategy on how to integrate them
Practically, these make sense. But they rarely reflect how work is moving through your business from signed contract to achieved outcome. And because of this, updating the tool just becomes one more annoying task on your teams to-do list. Since it doesn’t help them do their work, it’s very difficult to drive consistent adoption.
5 Things to Try Before Changing Project Management Tools
#1 | Focus on behavior first
Instead of trying out all the AI features, setting up a dozen automations, or adding a dozen fields, or integrating every single tool right off the bat, we got to focus on the “how” first.
In the world of software development, we use the term “MVP” a lot, or minimum viable product. Strip back your vision for the PM tool and just pick 2-3 behaviors the entire team has to commit to, just to start. For example:
Every task has one owner and a due date
If you are the owner of a task, you are responsible for updating the status of that every Friday by noon
You start with those 2-3 behaviors for the first couple of weeks. If your team can’t handle the basics, no feature is going to improve that. (If the team is pushing back on the process itself, we wrote about that in Why Your Team Keeps Ignoring the Process You Built.)
How do you know it works?
When someone asks “Where are we at with this project?” they can get the information in an accurate and timely manner from the tool instead of interrupting someone with a chat or unprompted call.
#2 | Work can only come in one way
90% of workflow issues start upstream, with how work enters the business. And the majority of companies we encounter have requests coming in through a variety of channels:
Chats
Emails
Break room convos
Client calls
These are the types of requests that don’t make it into the tool, or do you make it in, but they come in way too late and the context is missing.
When work can come in from anywhere, you’ve essentially quadrupled the amount of communication channels to triage and monitor.
If you create a hard boundary that there is only one intake path, things start to clean up rather quickly. In a project management tool, a clean way of doing this is through a intake form. The form has to be short but strict enough that people can’t just dump every idea they’ve ever had in there: what’s needed, who needs it, by when, and where the context lives.
How do you know it works?
You have a clean list of intake requests and can quickly see everything your team has been asked to do this week. It allows your team to prioritize and create shared focus.
#3 | Organize around how work is done, not around the org chart
If you want to see how you’re progressing towards a client outcome, but have to look in three different places to see what design is up to, what account managers have flagged, and what your engineers are doing, that’s how things get dropped and miscommunications happen.
It makes sense when you’re building it out, because design has a different workflow than engineering. But if teams share work and have dependencies on each other, then a department-first structure complicates every project and your reporting.
Try structuring your tool around the thing you deliver and sell. For most firms, that means organizing by client or project at the top, with each department's work living inside it. Use assignees and tags to show who owns what, not separate spaces. Keep departmental views for workload, but build them as filtered views that pull from the projects. Don't make them separate homes for the work.
How do you know it works?
Anyone can open one project and see every task, every owner, and every handoff in one place.
#4 | Cut the number of statuses you use
If you have six different statuses “Not Started” “Planning” “In Progress” “Executing” “Live” “Measuring” “Complete” “Blocked”, this isn’t doable and creates a significant amount of administrative work for your teams. The statuses lose their meaning.
We see people start adding these statuses over time because teams felt like their steps weren’t accounted for. Or they thought another status would help reporting, or help things not get dropped.
You should only have statuses that trigger an action for a clearly defined owner. Start as simply as possible. A simple structure:
To Do: accepted and scheduled.
In Progress: someone is actively working on it.
In Review: ready for a named reviewer.
Done.
How do you know it works?
You can scan a project's statuses and know exactly where to step in.
#5 | Build a dashboard that actually replaces your weekly status call
Status calls exist because leadership is in the dark and kept having to ask about where things are at in chat threads and emails. Your tool should contain all of this data, you just need to funnel it all into a visual that answers the questions most commonly asked.
Workspaces are often designed for the doers, not the decision-makers. You must have some designing your project management tool with both parties in mind. When designing the skeleton of your tool make sure it can answer:
What is due this week?
What’s on track?
What’s overdue or waiting on someone?
Who is overloaded?
Then use the tool capabilities (nearly every tool can do this) to consolidate those questions into a visual dashboard.
How do you know it’s working?
Status calls are either removed from the calendar or they focus on decisions, instead of droning on about updates and reasons things aren’t done yet.
When should you switch project management tools?
To be clear, we're not against switching. Sometimes it's the right move.
Here's when we'd tell a client to go ahead:
The tool can't do something you need. Client access, permission levels, or resource planning at your size. If it's a real requirement and not a nice-to-have, that's a fair reason.
The cost no longer makes sense. Pricing that worked at 10 people can look very different at 40.
The decision is being made above you. A merger or a parent company standardizing on one tool isn't a fight worth having.
If none of those apply, it's likely a setup problem. And setup problems are faster and cheaper to fix than migrations.
Before you purchase a new project management tool, ask yourself this
How many of these sound familiar?
Features nobody uses, and basics nobody follows
Work arriving from everywhere except the tool
Projects split across department spaces
More statuses than anyone can define
Leadership still asking for updates in meetings
If you checked three or more, don't switch. Rebuild.
At The 128 Collective, we work inside the tool you already pay for and change how your team uses it, so it finally does what you bought it to do.
Thinking about switching? Get a second opinion before you migrate.
