There's a pattern we see on almost every troubled ERP project, and it starts in the very first workshops. A team of consultants sits down with the business and asks: "Tell us about your current processes." It sounds reasonable. It's how most Dynamics 365 partners begin an implementation. And it's one of the most damaging things you can do to a project.
When you start from the incumbent process — the way the business works today on their legacy system — you set off a chain reaction that inflates scope, manufactures false gaps, and fills the backlog with wish-list items that have nothing to do with what the new system actually needs to deliver. The project hasn't even reached configuration yet, and it's already heading for trouble.
At Veriland, we take a fundamentally different approach. We don't start with your old process. We start with the product.
Here's what happens when you begin an implementation by documenting the business's current ways of working.
The consultants run workshops. The business describes how they process a sales order, how they handle goods receipt, how they approve purchase invoices. Every quirk, every workaround, every exception that's evolved over ten or fifteen years of working on Sage, NAV, or a legacy system gets captured in detail. The output is a thick requirements document full of "as-is" processes that the new system is expected to replicate.
This creates three problems that compound each other.
First, it manufactures gaps that don't actually exist. When you document a process designed around the limitations of a legacy system and then compare it against Dynamics 365, almost everything looks like a gap. The business describes their three-step manual workaround for inter-company transactions. The consultant writes it down as a requirement. Nobody pauses to ask whether D365 handles inter-company natively — because nobody has opened the product yet. The "gap" isn't a real gap. It's a legacy workaround being treated as a requirement.
We've seen projects where half the identified "gaps" were processes that D365 handles out of the box, often better than the workaround the business had been using for years. But because the starting point was the old process, each one was logged as a customisation or configuration item. Scope inflated. Budgets stretched. And the business ended up paying to rebuild limitations they should have been leaving behind.
Second, it sets false expectations. When you ask a business to describe their ideal process without showing them what the product can do, you're inviting a wish list. "We'd like automated three-way matching with a custom tolerance by supplier category." "We need a dashboard that shows real-time margin by project, by region, by quarter." These aren't unreasonable things to want — but they're requests made in a vacuum, without any understanding of what D365 already provides or what's proportionate for the business.
By the time the delivery team starts configuration, they're working against a requirements document full of aspirational features that were never grounded in the product. Some are already available as standard functionality. Others would require expensive customisation for marginal benefit. But they're all in the spec now, and removing them feels like a concession.
Third, it delays the only conversation that matters. The question isn't "what do you do today?" The question is "what can D365 do for you out of the box, and where does it genuinely fall short?" You can only answer that question with the product in front of you. Every week spent documenting incumbent processes is a week the business isn't seeing the system they've chosen — and a week where expectations are drifting further from reality.
The core problem: Focusing on the incumbent process treats the implementation as a blank-canvas design exercise — even though the business has already chosen a platform. The product isn't a blank canvas. It's a working system with hundreds of standard processes ready to go.
At Veriland, we never leave the product outside the room. From the very first working sessions, we demonstrate processes on D365 itself.
We don't ask the business to describe their procure-to-pay cycle in the abstract. We open Dynamics 365, walk through the standard procure-to-pay flow, and say: "This is how the system handles it. Let's see how your process maps to this."
This changes the entire dynamic. The business isn't describing processes from memory and hoping the system can match them. They're watching their workflows play out on screen, in real time, on the product they've already committed to. They can see immediately what works, what needs adjusting, and where there's a genuine gap — not a manufactured one.
When gaps surface this way, they're real. A finance controller watches the standard AP flow in Business Central and says: "We need the purchase order to route to a different approver above a certain threshold." That's concrete and testable. We can assess it on the spot — does D365's built-in approval workflow already handle this? Is it a configuration change? A small extension? The conversation is grounded in what the product actually does, not in what someone wrote in a document three weeks ago.
Just as importantly, this approach eliminates the wish list before it starts. When the business can see what the system provides as standard — automated bank reconciliation, built-in dimensions for reporting, Copilot-assisted invoice matching — they don't need to invent requirements for things that already exist. And when they see a process working well out of the box, they don't add unnecessary complexity by trying to bend it back towards their legacy way of working.
This is the core of Veriland's Sure Step 365 methodology: we iterate the business process alongside the solution.
In a traditional project, the process is defined up front and the build is expected to deliver against it. In our approach, the process and the solution evolve together through short, repeated cycles of demonstration and feedback.
Sure Step 365 structures the Build phase as a series of iterations. Each iteration follows a tight loop: Analysis, Design, Development, and Iteration Testing. At the end of every iteration, the customer sees a functional demo — on the actual system, with their data, against their processes.
But here's the important part: each iteration isn't just a chance to review what's been built. It's a chance for the business to refine how they want to work, informed by what they've just seen the system do.
A finance director who's been running Sage for fifteen years can describe their current month-end close in detail. But they can't describe the process they'd actually prefer — because they've never seen the alternative. When we show them how D365 handles period-end routines, with built-in reversals, automated accruals, and dimension-based reporting, they often realise their "requirement" was really a workaround for something their old system couldn't do.
This is what we mean by iterating the business process. The customer's understanding of what they need sharpens with every iteration, because they're seeing real functionality, not reading about theoretical designs. Requirements that seemed essential in week one get dropped by week four — not because we've cut scope, but because the business has learned that the product handles it differently and better.
Key principle: People don't know what they want until they see it. Showing the product first means requirements are informed by reality, not assumptions.
Every D365 implementation has gaps. The question isn't whether they exist, but when and how you discover them — and whether the gaps you're managing are real or manufactured.
In a process-led project, gap analysis happens on paper. The consultants compare the documented requirements against a feature matrix and produce a list. Some of these "gaps" evaporate the moment someone opens the system and demonstrates the relevant functionality. Others are genuine but poorly understood, because nobody has seen them in context. The gap register fills up with items of wildly different sizes and importance, all treated with equal seriousness.
In a product-led project, gaps surface naturally and in context. When we demo the configured procurement process and the customer identifies a real divergence, we can assess it immediately. How does it interact with the rest of the workflow? Is it a configuration adjustment, a small extension, or a genuine customisation? Is it worth the cost, or can the business adapt?
Sure Step 365 builds this into every iteration through fit demos and functional demos at each gate. These aren't optional progress updates — they're formal checkpoints where the customer validates the solution against their actual processes, raises genuine gaps, and approves the direction before the next iteration begins. Gaps are caught early, sized accurately, and resolved in context.
The result is a gap register that's smaller, more accurate, and far more manageable than one produced by comparing paper requirements against a feature list.
This entire approach rests on one principle: configure first.
Before any iteration begins, Sure Step 365 includes a Solution Modelling phase where we build a baseline configuration using out-of-the-box D365 functionality mapped to the customer's core processes. This isn't a prototype or a demo environment. It's a working configuration that the customer can see and interact with — and it becomes the foundation everything else builds on.
Starting from what the product gives you as standard means the conversation is always grounded in reality. The business can see how D365 handles their core processes before anyone talks about customisation. Extensions are only built where there's a validated gap between what the product does and what the business genuinely needs. And those extensions are built on top of standard functionality, not instead of it.
This protects the business in the long term too. Standard configurations are easier to upgrade, easier to support, and more predictable in production. The more you deviate from the product, the more expensive every future update becomes. Starting from the product and customising only where necessary isn't just a delivery methodology — it's a long-term cost strategy.
One concern businesses sometimes raise about iterative delivery is whether it stays controlled. If we're constantly iterating, who's managing scope, budget, and timeline?
Sure Step 365 addresses this through an embedded governance framework with a clear committee structure: a Steering Committee for strategic decisions, an Operating Committee for delivery decisions, and a Solution Management board for technical design authority. The iteration gates — the fit demos and Go/No-Go checkpoints — are themselves governance mechanisms. They ensure the project stays aligned with expectations at every stage without burying the team in status reports and change control boards.
The result is a project that feels controlled and predictable to the executive sponsor, while remaining responsive and adaptive for the delivery team.
The most expensive mistake in a Dynamics 365 implementation isn't missing a requirement. It's starting from the wrong place.
When you begin with the incumbent process, you inherit every workaround, every limitation, and every assumption from the old system — and you carry them all into the new one. You manufacture gaps that aren't real. You invite wish lists that aren't grounded. And you delay the moment the business actually sees what they're getting.
When you begin with the product, everything changes. Gaps are real. Expectations are calibrated. The business sees how D365 works from day one, and their processes evolve alongside the solution rather than being defined in a vacuum months before anyone opens the system.
This is what Veriland's Sure Step 365 methodology delivers: a configure-first, product-led, iterative approach that keeps the customer connected to the real solution from the first week to go-live.
If you're evaluating Dynamics 365 partners, ask one question: "When will we see the product?" If the answer is "after the analysis phase," keep looking.
Book a discovery call and we'll walk you through our Sure Step 365 methodology — with the product in the room, from day one.
Or call us directly: 01625 569 777
