Tools are as old as the road to Rome. And older. And in the hype of digital transformation, the call for tools is only growing. There are more tools than ever and the end is not yet in sight. But in day-to-day practice, organisations continue to struggle with choosing the right tool.

A few myths that I've heard for over twenty years during tool selections that I supervise keep buzzing around. So I thought it was time to name them and hopefully debunk them.

Myth 1 – The IT people are very good at drawing up the requirements

I compare this to letting the mechanic choose your car. Then you get a car with the hood always open, because then he can easily reach it. I can tell you from experience that driving with an open hood is difficult and even dangerous. So don't do that.

Requirements are must haves and wishes that you set for a tool. Functional requirements are about how the tool should work and non-functional requirements set preconditions for the tool itself. Those non-functional requirements are usually drawn up by IT specialists and other specialists such as the privacy officer, and that is completely fine.

But how the tool should help to achieve a goal on a daily basis should really be determined by the people who have to work with that tool every day. If you don't, you will get tool that won't work for these people. Or that only works as it should with a lot of customisation and a lot of hassle. No one will thank you for that.

Myth 2 – Users don't know what they want anyway

Look again at the title of this myth. Why do we say "users" and not "professionals"? People are not users, but professionals. Professionals who are trained and hired to achieve a specific goal. And that tool helps with that. So nobody knows what the tool should be able to do better than the professional.

And let's be honest, how strange does this statement sound: "Professionals don't know what they want!" But by labeling people as users, you implicitly tell them that they are stupid, senseless robots who cannot appreciate 'The System' (with capital letters).

Steve Jobs didn't mean you shouldn't ask people what they want, you just shouldn't literally ask them what the tool should do. And even worse: what the requirements are exactly. People want to achieve a goal in an easy, interesting, fun and preferably also satisfying way. Indeed, you literally still get usable functional requirements from professionals.

So ask them what they do in a day and why. And discuss and observe how things can be improved. Watch what they do and hear what they say. Translate that into scenarios and user stories and discuss it with the professionals. It is then the art - and your profession as a professional - to translate this into requirements.

Myth 3 – If we demand too much, there will soon be no tools

This is another persistent myth that I often hear. First, there are tens of thousands of tools and almost all of those tools have been developed to serve the demands and wishes of the market. The chance that no tool can be found is very small. In my 20+ years of career, I have never experienced it.

And what do you actually ask of a tool? A return trip to Mars? A tool that 'automagically' collects, curates, enriches, publishes all information at the touch of a button and makes it disappear again when the time is right?

In my experience, suppliers in particular assign all kinds of properties to their tool that are at least exaggerated or actually have no useful function at all. It's up to you to push through that.

Myth 4 – If we demand too much, it will take a lot of customisation

This is a myth, but one with a grain of truth. But this is not due to the requirements, but due to the wrong tool you have chosen. The tool cannot do what you want and strangely enough you have chosen a tool that does not meet that requirement at all. Or maybe you already had the tool – see myth 6 – and were forced to take it. Then you do indeed have a problem. But again, it's not your requirements, it's your tool.

If you don't make it clear in the beginning what you all and exactly want, the chance of customisation is huge. You regularly read about these kinds of debacles in the media. Millions and billions that were wasted on customisation, because it was not made clear in the beginning what one really needs.

So please demand as much as you need. Make a distinction between wishes, requirements and essential requirements. In the suppliers' offer you can see what all this should cost and then you can still drop some requirements or negotiate about the price or the way in which the requirement will be met.

Myth 5 – The tool should be easy to use

You can't do anything with these kinds of requirements, but I always see them in a list. This is what you get when you literally ask professionals about their requirements. See also myth 2. And that is of no use to you, because what does "user-friendly" mean? How do you measure that and how do you compare one tool with another on user-friendliness?

And when does the search engine work well? And what the hell is a “top task module”?

A requirement must be SMART, so it must be fully operationalised and clear to everyone, including the supplier. As a professional you can help make each requirement SMART and also determine how you will assess and weigh it.

Myth 6 – You know what? We'll take the free tool we already have

There is a persistent myth – which mainly lives among IT people – that the organisation already has a tool that can do everything and that it is also free. How beautiful can it be? What they just don't tell you - and often don't know either - is that not all modules of that tool have been purchased or licensed. So they often have to be paid extra.

There is no such thing as a tool that can do everything with the push of a magic button. Configuration work is always required and that costs money. And if the tool is actually not suitable, customisation is even required. And that is expensive and very risky. So there is no such thing as free.

It is always wise to first see which tool you already have can meet the requirements. Organisations often use a plethora of tools that only make the tangle of information systems bigger and less manageable. But do assess those existing tools for their suitability and do not use them blindly.

In any case, stick to your functional requirements and also assess the tools you already have for their suitability.

Myth 7 – We choose an open source tool because it is cheaper

Somehow "open source" is still a thing. But open source is just a licensing model. It says nothing about the quality of the tool, either positively or negatively.

That open source is free or at least cheaper is not always true either. Most information management systems are not ready-made systems. So configuration work is always needed and that costs money. you just don't pay for the license of the tool. Although that is no longer necessarily true in recent years, because many open source suppliers offer a paid 'Enterprise' edition in addition to the free 'Community' edition. Because organisations do want support and a guarantee on the tool and that costs money.

Some open source vendors also offer additional modules that are available at a hefty price. I think the writing on the wall is that those modules are not available open source.

Over the years I have supervised many tool selections in which both open source and proprietary tools were candidates. And besides, I've actually never seen significant price differences between these tools. The price is mainly determined by the configuration work and annual maintenance.

This applies to larger environments. Because here comes the disclaimer: for small environments, SaaS or open source tools are often free or dirt cheap.

How to start with a tool selection

In a tool selection, an organisation chooses the digital resources that can contribute to the digital transformation. Tools and technology can support the digital transformation, provided that the right requirements are drawn up and professionals are properly guided in the use of the tools.

The first step in the tool selection is the analysis in which the requirements are determined. Collect the non-functional requirements from IT, Legal, the privacy officer and other specialists. Organise workshops with a representative group of professionals in the organisation and together draw up scenarios of an ideal day and how digital resources can contribute to it. These must then be translated into functional requirements.

Scenarios are the common thread

The scenarios drawn up with the professionals are the common thread in the tool selection and also the implementation and acceptance of the tooling. First, the scenarios are translated into functional requirements.

The scenarios are then used in the tool selection by asking the potential suppliers to work out some scenarios in a demonstration. The professionals present at the demonstration can then assess whether the tooling meets their needs.

But that does not mean that the role of scenarios is over. During implementation, the scenarios are the benchmark against which the implemented tooling is assessed. If the tooling is not yet optimal for the desired scenario, the tool must be refined.

The scenarios also play a role in the training of the professionals in the use of the tooling. A good training is mainly built around the scenarios; they are recognisable to the professionals. This also avoids a boring 'button training'.

The scenarios remain the basis for any optimisation of the tooling. Does the process or the professional's working method change? Then there will first be an adapted scenario as the basis for the adjustment in the tooling. From the professional's perspective.

Want to know more about how to use scenarios in a tool selection? Please contact us at info@timaf.org or fill out the contact form.