A topic came up in a project meeting I'm involved in: our project management tools are a mess.
Here's the situation:
- One team uses Redmine (with no one maintaining the database)
- Another team uses Azure DevOps (but can't fully utilize its features)
- About 30 people total
- We want to visualize productivity across teams, but the tools are fragmented
Someone suggested unifying the tools. But which one should we choose? I started digging into this and wanted to share what I learned.
Why There's No "Perfect" Tool
While researching, I realized something: every project management tool has trade-offs.
Redmine is flexible but has an outdated UI. Azure DevOps is comprehensive but complex. Jira is powerful but heavy and expensive. GitHub Projects is simple but limited.
Why is this? I think there are a few reasons.
Project management tools serve multiple audiences: developers want Git integration, managers want progress visualization, executives want high-level dashboards. When you try to satisfy everyone, things get complicated.
There's also a trade-off between flexibility and usability. More customizable means more complex setup. Simpler means less flexibility.
And honestly, sometimes the problem isn't the tool—it's the project itself. Poor communication, unclear requirements, unrealistic schedules. No tool can fix those fundamental issues.
How to Make the Decision
Instead of looking for the "perfect" tool, I think we should look for the "most suitable tool for our team right now."
To do that, we need to clarify the specific problems we're facing:
- Redmine's unmaintained database → security and data loss risks
- Azure DevOps being underutilized → wasted learning costs
- Fragmented tools → can't visualize across teams
We also need to decide whose pain is most acceptable. Developer productivity? Manager visibility? Executive decision-making speed?
And we need to estimate migration costs—not just license fees and migration work, but also the temporary productivity drop while everyone learns the new tool. This turned out to be more important than I thought. Lost customizations, broken workflows, training time—these hidden costs add up.
Linear: A New Option
During my research, I came across Linear.
It's a relatively new tool (founded in 2019) that's designed to be simple with a low learning curve. But it still has the features needed for cross-team visibility. It's not as complex as Azure DevOps, so there's less risk of "not being able to use it."
For a 30-person team, it costs around $2,880-$5,040 per year. Compared to Redmine maintenance costs (which can be $1,000-$3,000/month if outsourced) and Azure DevOps licenses, unifying on Linear might actually reduce total costs.
Other options include GitHub Projects (nearly free if you already use GitHub, but weak reporting) and Jira (feature-rich but expensive and complex, with the risk of "not being able to use it" again).
Given the experience of "can't fully utilize Azure DevOps," a simpler tool seemed more appropriate.
I Tried It Out
After organizing my thoughts, I decided to try Linear myself.
The free plan was enough to test it out with no risk. I wanted to check: how smooth is issue creation, how does the kanban board feel, can I create cross-project views, can I see metrics like cycle time and completion rate?
To be honest, I'm still figuring this out.
I've only used it a little, so my honest reaction is "what's supposed to be good about this?" It does seem to run lighter than Azure DevOps or Redmine, but I haven't used it enough to really judge. It's not in Japanese, so there might be a learning curve for the whole team.
Maybe I'll understand its value as I use it more.
No Answer Yet
As I write this, I haven't made any decisions. I'm not in a position to make major decisions anyway—I just wanted to understand how it works.
Maybe this will lead to meaningful discussion in the meeting, maybe it won't. But I figured I can't start anything without knowing how the tool actually works, so I just tried it out.
With project management tools, I think someone always has to compromise. There's no perfect tool. So how do we decide?
What I thought about while gathering information:
- What are the specific current problems?
- Whose pain is most acceptable?
- Balance of migration costs vs. value gained
- Trade-off between simplicity and features
But I don't know if this is the right approach. My thinking might change after actually using it more.
More thoughts on technical decision-making processes at:
https://tielec.blog/
Top comments (1)
The bigger risk isn’t choosing the “wrong” tool — it’s letting the tool dictate the way the project runs. Start with how decisions actually get made, then pick the tool that gets out of the way.