“Which AI tools should we be using?”
That is the question I most frequently hear in an initial meeting, and it is almost always the wrong one to ask. Although the answer matters, the problem is that the question suggests the difficulty lies in making the choice. In my experience, the hard part is on both sides of that decision: understanding the kind of work the technology is meant to change, and then getting people to use it when it arrives.
We build with AI and low-code every day. We are a technology consultancy, and we are clear about that. But in the first sessions of most engagements, we hardly talk about products at all.
Technology-first projects fail late, and they fail expensively
Anyone who has worked on a digital programme that has stalled will be familiar with this pattern. A tool is chosen early, usually before it’s clear how the work will actually proceed. Licences are purchased. A pilot version is constructed. It performs well in the demonstration because demonstrations are based on the straightforward, ideal scenario. Then it comes up against the real organisation: the exceptions that had not been recorded, the spreadsheet that turns out to be the actual system of record, and the team that was informed about it sixteen days before the go-live date.
Nothing technically failed. The build worked. What failed was the assumption that the technology was the problem to solve.
Starting with the tool also narrows your options. Once you pick a platform, every problem gets reshaped to fit what it does well. Sometimes that works. More often, it means automating a broken process faster and paying for it.
What we look at before we name a technology
Our consultants start by understanding the organisation, its challenges and its stakeholders, before designing and building anything. In practice, that means four things.
1) The process
Firstly, we look to understand the process as it actually runs, not as it is documented. There is usually a gap, and that’s where the value is. The official process says requests come in through a form. In reality, half of them arrive as emails to one person who has been there for twelve years and knows what to do with them. You cannot automate around that person until you understand what they are actually doing, and neither can an agent.
2) The people
Secondly, we need to understand the people who own the work. Who does the work today, how do they feel about it, and what would make their week better? Adoption is not a training module at the end of a project. It is a design input at the beginning. When the people doing the work help shape the solution, they arrive at go-live already owning it. When they do not, you spend the following six months persuading them.
3) The data
Next, we look at the data underneath it. AI is only as good as what it can see. Before we talk about agents, we want an honest view of what data exists, where it lives, how clean it is, and who can look at it. An AI readiness assessment that audits data, risks and processes is unglamorous work. It also separates a solution that holds up in production from a pilot that quietly gets switched off.
4) The risk
Finally, we try to understand the risk appetite and governance. This matters everywhere, and it matters twice as much in regulated settings. What needs an audit trail? Where does a human have to sign off? What decisions is the organisation genuinely comfortable delegating, and which ones will never be delegated, whatever the technology can do? We put a governance plan in place upfront rather than retrofitting one after somebody asks a difficult question. Guardrails set early are enabling. Guardrails set late are a rebuild.
At this stage, understanding the organisation we are working with doesn’t require knowing whether the answer to their problem might be a custom agent, Power Platform, a low-code app, or a form change. That comes after.
This is not an argument against technology
I want to be clear: the idea of “starting with the problem and not with the tool” might sound like a polite way of avoiding commitment. We are not vague when it comes to technology; we refer to it directly, develop it, and carry out this work quickly once we know what we are going to build.
What matters is the order in which things are presented. The technology should come as a result, not as a starting point. Once we reach the recommendation, we can clearly explain why this particular platform, why this approach, and what it will cost, since the reasoning can be traced back to something real in the business. That also means we are not tied to defending a decision we made before we understood the problem. We work across a range of AI technologies and platforms so the answer can genuinely fit the organisation rather than the other way round.
It also simplifies the commercial discussion. When a prioritised roadmap is developed based on real processes, the client can see which items are worth addressing first, which can be postponed, and which are not worth doing at all. This kind of conversation is far better than one concerning a licence renewal that cannot be justified.
Sometimes the honest answer is “not yet”
The uncomfortable part of working this way is that occasionally the right recommendation is to build less than the client expected, or nothing at all.
We have been in sessions where the best outcome was realising a process needed simplifying before it could be automated. We have advised that the data foundation needed work before agents would produce anything useful. Neither of these is the answer a consultancy is commercially incentivised to give in month one.
We give that advice anyway, because leading with trust and setting realistic expectations is one of our core values at Marra. The alternative is worse for everyone. A project that should not have started is expensive for the client and bad for us. Being honest about readiness early is how you end up with a client who is still working with you three years later.
What starting this way actually gets you
By approaching our work this way, we can get three things to happen consistently.
1) Solutions that get used, because the people who use them were involved from the start. Adoption is not a risk to manage at the end; it is built into the work.
2) Investment that goes where it matters. When you understand the process first, you can tell the difference between what is annoying and what is actually costly. They are often not the same.
3) Capability that stays behind. We work with our customers, not just for them, and we treat handover as something that runs through delivery, not just a milestone at the end. Whether it is upskilling a team, setting up a Centre of Excellence, or making sure someone internal understands how it works, the aim is for the organisation to be more capable after we leave than when we arrived.
Where to start instead
If you are considering AI or automation and the conversation has already turned into a debate about which product to buy, it is worth stepping back. What is the work you want to change? Who does it today? What would need to be true for your team to trust a machine with part of it?
Answer those questions, and the technology decision usually takes care of itself. Skip them, and no amount of technology will save the project.
That is why we don’t start with technology. We start with you.
Written by Ben Dawson, Business Development Executive
If you want help shaping your own AI or digital strategy, our team at Marra is always happy to talk.
