The common reflex: looking for the tool before understanding the need
In every profession, one reflex persists:
👉 We start by looking for a tool… before even clarifying the need.
- “We need a good planning tool.”
- “Do you know a simple software to manage our tasks?”
- “Let's try this one — it has good reviews.”
But we forget to ask:
- What exactly do we want to steer?
- What kinds of decisions do we need to make?
- Which elements are critical to track in our context?
The danger? Choosing a tool that's appealing in the short term but unsuited in the long term. Or worse: using a lightweight tool to mask heavy problems.
Get the order right: need ➡ use ➡ tool
A tool is only a means at the service of a use, itself dictated by a real need.
🔁 Reverse the usual chain:
- Need: What problem are we trying to solve?
- Use: Which method, which steps, which key data?
- Tool: Which software or support translates this efficiently?
It's a posture change. But it is fundamental if we want to avoid trends or ineffective gadgets.
Second difficulty: even when the right tool exists, are we ready to make the effort?
Even starting from the need, another difficulty appears: some tools have all the necessary features… but require effort to be used effectively.
A good example? Microsoft Project.
Often perceived as:
- Complex,
- Outdated,
- Reserved for “trained project managers”.
And yet, it lets you:
- Manage a multi-project portfolio,
- Consolidate a workload plan,
- Track progress rigorously,
- Model dependencies, calendars, shared resources.
Functions that no “modern” tool truly offers as a whole. But its austere look, its demanding logic and learning curve put people off.
So, second dilemma: Even when the solution exists… are we ready to make the effort to use it?
It's not a software question, it's a posture question
This double dilemma — means before need, then rejection of effort — explains a large share of tooling failures in organisations.
🔹 We seek a “simple” tool before laying out the real constraints.
🔹 And when a tool can answer them, we reject it because it requires too much commitment.
The consequence? We often pick what's easy to adopt… rather than what's useful to decide.
Conclusion: two good questions to ask before choosing
- Have I really defined my need before looking for a solution?
- Am I ready to make a minimum effort to use a demanding but relevant tool?
True maturity in project management, like elsewhere, doesn't come from the choice of tool. It comes from clarity of need… and the courage of reasoned effort.