There are often tricky moments in a project scoping conversation where someone puts us on the spot and wants us to say, “Yes, we can do that.”
And we usually can – that’s not the issue. The question is whether it’s in the client’s best interests for us to. Saying yes without asking why is how problems get baked into projects.
Requirements go unchallenged, assumptions carry forward. and decisions that deserved a proper conversation get waved through without one.
That’s what effective scoping avoids. If it feels a bit uncomfortable, that’s usually a sign it’s working.
Why “That’s How We’ve Always Done It” Is a Warning Sign
When we sit down with a new client, they’ll have a list with detailed requirements and process diagrams ready to hand over.
But these describe how things work today, and buried inside might be years of compromise.
A manual approval step that was added after a mistake three years ago.
Spreadsheets that exist because nobody trusted the old system’s reporting.
A process someone described as “unique” that could be handled by prebuilt functionality at a fraction of the time and cost.
These workarounds become invisible over time. They get written into process documents and treated as fixed requirements. Nobody questions them because nobody remembers why they exist.
Projects that go wrong rarely fail because of technology. The bigger risk is carrying over legacy practices unchallenged and missing the opportunity to reset and identify better ways of working.
Our job is to ask:
Why does this step exist?
Is it a genuine requirement or an inherited workaround?
How could this be achieved more effectively?
The Consequences Nobody Mentioned
When I speak to people who come to ServerSys from another partner, I often hear the phrase: “I wish someone had told us that before.”
No one mentioned that a bespoke customisation might need to be reworked when Microsoft released an update.
Or that data storage and retention practices would result in unnecessary Dataverse costs.
And integration approaches that have caused maintenance headaches for years.
The partner delivered what was asked for, ticked the boxes, and moved on. We take a different approach that might involve saying, “You could do this, but…”
We’re not trying to slow things down or create extra work. This is about making sure you have the facts before committing to decisions that can have long-term consequences, particularly in solution architecture.
Our consultants are inquisitive and know the technology well enough to see around corners. The people who design your solution are actively involved in the build process. That continuity matters because context doesn’t get lost in a handover document.
Starting Smaller to Get There Faster
I’ve learned (the hard way, on more than one occasion) that big, ambitious projects carry big risks.
A scoping exercise that produces an 18-month delivery plan should prompt everyone to pause. Not because the ambition is wrong, but because a lot can happen in this time.
People leave, goals change, and priorities shift. Requirements that were locked in month one might look different by month six.
That’s why we favour a phased approach. Get a well-scoped first phase into people’s hands within weeks, not quarters. Deliver working capability early, so teams can see real value, give feedback, and build confidence in the direction of travel.
This approach reduces risks, controls costs and builds the business case for further development. Each phase builds on the last, informed by what you’ve learned rather than what you assumed at the start.
Getting the Hard Conversations Right
Challenging a client’s thinking isn’t comfortable.
Nobody wants to hear that a carefully prepared requirement needs rethinking. And as a consultant, telling someone their approach might be flawed takes confidence that only comes from experience.
You only earn the right to push back by demonstrating that you understand the business, not by assuming you know better.
The best scoping conversations are the ones that feel like a proper back-and-forth discussion. Lots of ideas with honest, constructive exchanges. These sessions are where the hard yards are done, laying the foundation for smoother delivery.
It might look like extra work at the front end. But it saves time, protects budgets, and means fewer surprises later.
Getting it right the first time, getting there quickly, and building value in each phase are our goals.
Here’s a question worth considering.
When was the last time your technology partner pushed back on something you asked for?
If the answer is never, it might be worth asking why.
How We Help
ServerSys works with organisations across the UK to scope, design, and deliver Dynamics 365, web portals and Power Platform solutions.
If you’d like to discuss your next project, please get in touch.
