Buying new software? How to clearly map out what you need

Say you’ve been working with software for a while. Some things work well, but you often find yourself thinking: surely this could be easier? Or you want to move on from a system that no longer fits the way your organisation works, or that doesn’t meet your requirements for data security. So you decide: let’s find something new.

The temptation is to start scheduling demos right away. What are the options? What does it cost? When can we go live? What are similar organisations doing? Understandable, because you want to get moving. But chances are you’ll end up buying another system that looks like the answer to all your problems at first glance, and then reveals its gaps soon enough.

That is why step 1 of the step-by-step guide—mapping out what you need—is not a formality. It is the prerequisite for a successful process.

Start with the problem, not the solution

Take your mission and annual goals as a starting point. What does your organisation want to achieve, and how does your current system relate to that? Does it help you reach those goals, or does it get in the way?

Then look at the specific bottlenecks. Where does the system get stuck? What takes too much time? Where are the missed opportunities?

Write it down, without pointing to a solution yet. “We want a new CRM” is not a problem description. “We can’t link our audience data to our ticketing data, so we have to compile every report manually” is. The sharper the problem, the more focused the search.

Gather diverse input

One of the most valuable things you can do at this stage is bring together people who don’t normally sit at the same table. The colleague who uses the system every day knows things management doesn’t. A colleague from another department who uses the same system in a completely different way sees something else again. And the volunteer who occasionally has access notices things nobody else does. Even colleagues who don’t (yet) use the system directly can sometimes offer valuable input.

Bring people together from different levels and departments. Don’t think of it as a meeting, but an exploration. Take a concrete process as your starting point and describe the different phases everyone goes through, and which tools or software they use along the way. At this stage, nothing is too small or too obvious to mention. The step that’s so self-evident nobody mentions it is exactly the one that causes confusion later in the process. Build as complete a picture as possible of how you work now. For example, setting up a theatre production, from grant application to aftermailing, or an exhibition from idea to opening. Which steps do you go through? Who is involved, and when? How does one department get information from another, and at what point?

Where are the detours, the workarounds, the moments of frustration? Where do you switch from one system to another? Get out your flipchart or whiteboard and post-its and make it visual. These conversations yield information you won’t find anywhere else. Plan time for them on purpose.

Then look at what’s already in the system and what isn’t. Which steps currently happen outside the system, via email, a spreadsheet, an app? Write that down too. Those are exactly the points where a new system can make a difference.

The end result is a shared overview of how you work now: which phases there are, where information is passed from hand to hand, and where the gaps are. That overview is the basis for everything that follows.

Tip: use a TRIZ to discover what you no longer want

At Tò Mò, we like to use TRIZ at this stage, a working method in which you turn a question on its head. Instead of “what do we want from our new software?”, you ask “what qualities should our new software absolutely not have?” The outcomes form a good basis for your knock-out criteria and wishlist.

That negative inventory may sound like a waste of time, but it produces surprisingly sharp insights. What you don’t want is often easier to name than what you do want, and it helps the team make conscious choices rather than unconsciously repeating the familiar in a new guise.

Want to know more about TRIZ and how to use it step by step with your team? Read our blog “Getting started with TRIZ”.

Map out your stakeholders and timeline

Who is affected by the purchase of new software? Think beyond direct users. Who needs access? Who supplies data and who retrieves it? Are there external parties (visitors, partners, volunteers) who do or see something via the system? And who needs to sign off before you can make a decision?

Make it concrete: take a sheet of paper, or your flipchart or whiteboard, and put everyone on it who has something to do with the system. For each person or group, note the following: what do they do in the system, what do they contribute, and what do they take from it? Then divide them into two categories: who uses the system daily, and who only occasionally? That quickly shows you where the dependencies lie.

A stakeholder analysis doesn’t need to be extensive; a simple list of names, roles and their relationship to the system is enough. But anyone who discovers too late that a particular colleague or external party also depends on the system risks having to go back to the drawing board after the purchase.

Also think early on about when you want to go live. Are there fixed moments in the year to take into account, such as a busy season or a funding deadline? Setting a target date early on prevents the process from dragging on.

Ready for the next step

Once step 1 is complete, you’ll have a clear picture of the problem you want to solve, a shared understanding within the team of how you work now, an overview of who is involved, and an initial sense of the timeline. You can use this to draw up your knock-out criteria and wishlist, and then build the benchmark.

Those steps run much more smoothly when everyone has the same starting point. And the demos that follow are no longer an introduction to what software can do in general, but a targeted test of whether this specific system fits your specific situation.

This blog is part of our step-by-step guide to purchasing new software. Read here the full guide, from this first step through knock-out criteria to demos and implementation.

Afbeelding: Fabrizio Matarese / https://betterimagesofai.org / https://creativecommons.org/licenses/by/4.0/