Investing in new technology? Start with the problem, not the platform.

Choosing new software can quickly become a conversation about features. What can the platform do? What does it integrate with? Does it use AI?

These are useful questions, but they’re difficult to answer meaningfully without understanding the work the software needs to support.

For a business-critical platform, that means looking closely at how people actually work: the processes they follow, the exceptions they handle and the problems they need to solve. That understanding should guide both the technology you choose and the changes you ask people to make.

The process on paper is only a starting point

A documented process is a useful starting point, but it may not tell the whole story.

Consider a workflow that looks straightforward on paper. Information comes in, someone reviews it and the task moves to the next stage. In practice, some information might be missing. A decision might need input from another team. An unusual case might require a different approval.

If the software only accommodates the straightforward version, people still have to handle everything else. They might keep a separate spreadsheet, pass information around by email or complete steps outside the system.

People find ways to get the job done, and over time those arrangements can become part of how the business operates, even though they’re missing from the process documentation.

Before choosing new software, it’s worth looking closely at what those workarounds are doing:

• Why does the spreadsheet exist?
• What information is being passed around by email?
• Which decisions happen outside the platform, and who makes them?

The answers can reveal requirements you would otherwise miss. They can also expose steps that nobody needs any more, but that have survived because nobody has had a reason to question them.

Replacing the platform without investigating any of this, simply risks carrying the same problems into a new system.

Prioritise the process, not the software

There will usually be some adjustment involved in introducing new software. Established processes deserve scrutiny too, and a different way of working may be an improvement.

The question is whether you can explain the benefit of the change.

If a new workflow removes repeated data entry or makes approvals easier to follow, there’s a practical reason for people to adopt it. 

If it adds steps simply because the chosen platform can’t accommodate what you need, that deserves a closer look.

Pay attention when discussions about a product increasingly become discussions about working around it:

• What will still need to happen elsewhere?
• Who will maintain the connections between systems?
• Are you resolving an existing difficulty or creating another one?

A content management platform is a useful example. Its feature list might be impressive, but the team still needs to create, review, approve and publish content. Working through that process can tell you more about its suitability than a demonstration of features you may never use.

Sometimes an existing product does the job

None of this means every software decision needs a lengthy discovery exercise or a custom build.

Where the requirement is understood and a ready-made product supports it well, buying can be a sensible choice. You don’t need every available feature, and you don’t need to own or build every part of your technology.

What you do need, is to understand any compromises. You might accept a small change to a process because the product meets your other requirements and is straightforward to manage. Another limitation however, might affect work that is central to the business, making it much harder to justify.

If you know exactly what the software needs to support, you can decide which compromises are acceptable. This helps you distinguish what the organisation needs from what would simply be a “nice to have”.

Don’t make assumptions - talk to the right people

This will sound familiar to most people - the person responsible for a process and the person carrying it out can have very different opinions on what needs changing.

A manager might need better visibility of progress, whilst their team member might be frustrated by entering the same information in several places. Both are valid, and you need to know about these types of niggles before making decisions.

The same conversations should look ahead. Could approval requirements change? Will other teams need access? Are new services likely to introduce different workflows? You can’t anticipate everything, but known areas of change should inform the decisions you make now.

If possible, a prototype gives people something to try. Can they complete the task, and does the new process resolve any prior issues?

When redesigning Certsure’s NICEIC Online Certification System, we mapped how different user groups worked, including their certification workflows, permissions and approval processes. We then used prototypes and proofs of concept to let Certsure validate key workflows before development began.

What should the investment improve?

A new platform brings costs beyond the software itself - time, resource and energy. Change management becomes a task for the managers, whilst teams need to adapt their routines and make time for the transition. There should be a clear explanation of what that effort is expected to achieve, so everyone’s on board. If this is a difficult task, then that’s a red flag - the benefits to investing in a new platform should be obvious to everyone involved!

Whether it’s fewer repeated tasks, clearer approvals or the ability to handle cases that currently need a separate manual process, use the improvements to judge whether the proposed solution is worth the investment. Consider how your teams and business will be impacted by the changes and how it’s going to benefit all.

Improving how the organisation works requires a clear understanding of the processes and behaviours around it.

Start by understanding the problems you’re trying to solve, then choose the technology that solves them.