5 mistakes with which you screw up every purchase of a requirements management tool

We sit down with our team at least once a month and we look at the latest sales figures.

The same picture has been the same for years: At least four out of five people who are interested in our requirements management tool do not ultimately buy.

And not because we are so bad and they choose a market competitor (on the contrary, we win the race in over 75% of the cases), but because simply no solid basis for decision-making can be created to be able to purchase any requirements management tool at all. The reasons for this are almost always homemade.

And that's sad, because these companies could benefit massively from an RM tool like our ReqSuite® and get rid of many of their problems once and for all.

So what is going wrong and why is it failing?

In discussions with well over 1,000 interested parties, the following 5 mistakes emerged as a recurring showstopper. These are therefore facts and not individual polemical opinions.

So if you want to prevent yourself from buying an RM tool, then make at least one of these mistakes. 😉

Otherwise, follow our relevant learnings.

‍

1. No commitment from above

The number 1 showstopper: A motivated employee, sometimes only recently with the company, sees the need for an RM tool and sets out to search. However, bosses (and especially management) do not know anything about it (or are not yet convinced), but they are trying the revolution from below.

We: “Is the management behind it? ”

They: “Not yet, but when I see it and I like it, I can definitely convince my boss to spend money on it. ”

‍

It would be great. We can count on one hand the cases where this has ever worked.

Learning

Make sure you have an explicit one first “Yes” from management for an RM tool and actively involve decision makers in the selection process. Otherwise, you just waste your time and, in the worst case, build up resistance against yourself and your honorable project, which won't disappear anytime soon.

‍

2. Get focused on features

Interested party is completely focused on individual features and absolutely wants to have it this way and that. When asked why he needs it, there is often no plausible answer. The big picture of why an RM tool is generally needed and what should be improved as a result cannot be explained either.

We: “What are the current challenges why an RM tool could help you? ”

They: “We need an XYZ interface and a view to compare documents. ”

‍

It's like when you go to a doctor and can't tell him what symptoms you have, but you know exactly which medications or therapies you would like to have.

Learning

Primarily understand why you need an RM tool and what should improve as a result. Don't get too focused on that “How”. Otherwise, you are hastily ruling out useful solutions and may even opt for the wrong product that scores points with your favorite feature, but is otherwise of little use for what would really help you.

‍

3. Want to “play around”

Interested party absolutely wants a test account and “Play around a bit yourself”. When asked what exactly he wants to try out, the answer is that he wants to see “whether it suits us”. In itself, a valid requirement that also works with many software products, but is pushed to its limits when it comes to process-oriented applications such as RM tools.

Why?

Because an RM tool isn't off-the-shelf software that you use the way it comes out of the box. The success and benefits of a requirements management tool depend largely on how the tool is configured for the individual context and need (even if it is just terminology).

A test version that does not reflect your own context therefore makes no sense and experience has shown that it creates more uncertainties than it provides clarity. To claim or offer otherwise is simply dubious.

Learning

Get personal advice from an expert and outline individual customization options for your company. And if that's not enough for you, invest in a real, individual pilot, in which you get the tool set up the way you need it. Only then can you really judge whether it fits or not.

‍

4. Selection with question lists

Interested party sends a multi-page Excel spreadsheet and asks to answer the questions. Decisions would then be made on this basis. Or even: “Send me a product brochure and an offer for x licenses. ”

Seriously?

If you want to buy a new car, do you also send a questionnaire to all car dealers in the region and decide what to buy on this basis?

Of course not. Especially because everyone answers the same thing to 80% of the questions anyway.

Then why choose a mission-critical tool in this way?

Learning

If you're already prepared to spend several thousand euros on an RM tool, then invest time in choosing it. Talk personally to the manufacturers who are suitable for you and get detailed advice and show you everything in detail. This not only gives you technical information and insights, but also a sense of the provider's expertise and reliability — something you can never verify with your lists.

‍

5. Don't have a project to implement

Interested parties often see the benefits of a requirements management tool and set out to search, even if they currently have no project at all in which the tool could be used.

However, introducing a tool without a specific project is like practicing a skill without a real use case — there is no practical relevance. You have no real requirements, no real processes, and usually no resources to test the tool and check its efficiency. As a result, the introduction is dragged out unnecessarily and the added value of the tool is not really recognized at all.

And worst of all: As soon as a real project comes along, you are under pressure to integrate the tool into the real work process in the shortest possible time without having tested it in a real scenario beforehand. This causes more stress and effort than integrating it into an existing or future project right from the start.

Learning

A requirements management tool should not be introduced in a vacuum. It takes a specific projectto immediately show the added value it provides. The best introduction is always one that hand in hand with practice works — this is how the tool is correctly understood and used right from the start.