In my experience,
digital transformation projects rarely fail because the tech wasn’t right.
Platforms such as
Microsoft Dynamics 365, the
Power Platform and
Azure are more than capable of supporting complex organisations.
Where things tend to go wrong is much earlier… in the initial requirements document.
In the briefing meeting.
In the exact moment a consultancy nods and says, “
yeah, we can do that” without checking.
You see, from the client’s perspective, that agreement is going to feel reassuring, even capable.
But agreement without interrogation will lock in the very constraints a transformation was meant to remove.
That’s why the best consultancies won’t just say yes.
They’ll ask what problems led them here.
They’ll question whether current processes deserve to be preserved.
They’ll test assumptions before they write one line of code.
There’s a reason I’ve built FormusPro’s approach to this as a hybrid-model.
All of our consultants, by design, combine deep platform expertise with operational and real-world experience.
Many have worked inside the
sectors they now support.
They understand not only how systems function, but how organisations behave. Both how and
why. That perspective makes it easier to challenge constructively, because the challenge is grounded in lived experience rather than theory. It’s never about being difficult.
It’s about building the right solution, not just delivering the requested one.
When Requirements Reflect The Past, Not The Future
One of the most common things I see, over and over, is organisations that try and define their requirements based on how things currently work.
That should make sense though, right?
You document the current process. You identify pain points. You ask the new system to handle them better.
But see, buried inside those requirements are years of compromise.
And those compromises can introduce a wide range of issues. Manual checks that were introduced because a previous system couldn’t validate properly. Approval layers that were added after one mistake. Reports that exist because no one trusted the data.
Over time, those workarounds start to feel normal. They even get written into process documents.
Instead of asking, “
what would good look like if we started again?”, the project becomes, “
how do we replicate exactly what we have in a new platform?”
I’ve seen organisations invest heavily in modern systems only to recreate the same bottlenecks, the same duplicated effort and the same reporting friction they were trying to escape.
Not because the platform couldn’t do better.
But because no one stopped to question whether the existing processes deserved to survive.
The Difference Between Delivery And Direction
To my mind, it’s a crystal-clear distinction.
There’s consultancies out there that deliver what’s written and there’s those that help shape what should be written in the first place.
Order takers focus on scope. If the requirement is documented and approved, it gets built. Their responsibility ends at delivery.
But a strategic partner should take a much broader view. They should be interested in outcomes before ever looking at features. They should want to understand what the organisation is trying to protect, what it’s trying to improve and mostly importantly, what it wants to achieve.
And look, that doesn’t mean resisting every request. Far from it.
It just means understanding the consequence of accepting them first.
For example, customisation vs out-of-the-box feel like personalised flexibility.
In reality, it often introduces unnecessary maintenance overhead, upgraded friction and long-term costs that are almost never obvious during implementation.
An experienced partner will explain those trade-offs. Not to slow you down, or charge you extra. Quite the opposite. It will speed your implementation up and save you money, in both the mid and long term.
How Challenging Requirements Early Saves Time And Money
There’s an annoying misconception that challenging requirements slows a project down.
As I’ve said, it’s actually the opposite is usually true.
When long held assumptions get tested early, unnecessary complexities fall away before they make it into new implementations.
You can make a decision once, and not have to revisit it six months later. Trade-offs are also understood before they get embedded in workflows and integrations.
I’ve always found that the most expensive changes in any programme are the ones made after build has started.
By that point, documentation has been signed off, dependencies have formed and confidence is tied to visible progress. Even small alterations ripple through testing, training and data structures.
An example of this could be a simple customisation.
It’ll begin with good intentions. It’ll make a process feel unique or more streamlined. And it will accomplish that.
But each layer of custom logic only increases the maintenance overhead and complicates upgrades. It reduces flexibility when you evolve.
What felt like a good idea during implementation becomes friction over time because it wasn’t planned for.
When requirements are challenged early, those layers get examined before they harden. Some remain, because they’re genuinely necessary. Others fall away because they were compensating for limitations that no longer exist. The result isn’t a stripped-down system. It’s a cleaner one.
Time is saved because fewer revisions are required. Budget is protected because complexity is reduced before it multiplies. And the organisation is left with a platform that can adapt, rather than one that needs constant adjustment.
What A Constructive Challenge Actually Looks Like
Let’s address the elephant in the room.
The word challenge sounds confrontational.
It suggests we’re out there saying “
no, we’re not doing that”.
That isn’t what this is about.
A constructive challenge is actually a lot simpler than that. It’s us asking:
“Why do you want that?” “What outcome are we trying to protect here?”
“If we removed this step entirely, what would actually break?”
“Is this process unique, or is it compensating for an old limitation?” The goal is never for us to prove a requirement wrong.
It’s to test whether it still serves your needs. Our questioning is grounded in deep sector knowledge and operational experience, so it should feel collaborative, not combative.
In workshops, constructive challenge often reveals interesting things….
A report exists because the data was once unreliable. An approval stage was introduced after a single high-profile mistake. A manual check compensates for a validation rule that no longer applies.
Once those origins are understood, better decisions can be made.
Sometimes the requirement stays. Sometimes it’s simplified. Occasionally it disappears entirely. But you get to move forward consciously, not by default.
Final Thoughts
As I said right at the beginning, Digital transformation is rarely limited by tech.
More often than not, it’s limited by the thinking that surrounds it.
Following this model, requirements feel more productive. Implementation meetings are shorter and projects move faster.
The best consultancies (cough, FormusPro, cough) understand that their (our) role isn’t simply to deliver what’s requested.
It’s to improve the quality of what gets requested in the first place.
It requires judgement. It requires empathy. And occasionally, it requires slowing the room down.
But when our challenge is constructive and grounded in real-world experience, it protects time, budget and long-term flexibility.
If your partner never pushes back, it may be worth asking why.
Because the right partner isn’t there to bake in old problems.
They’re there to solve them.
