How we deliver

The method is ordinary. The discipline is where projects are won.

Nothing below is novel — it is close to what Microsoft's own implementation guidance recommends. What separates a system people use from one they abandon is whether a partner actually holds the line on it when a deadline gets tight.

The phases

Four phases, and we stay past the fourth.

Each phase ends with something you can review, challenge and sign — not a status percentage.

Discover

Process walkthroughs with the people who do the work, not only the people who sponsor the project. Data quality profiling on your real records. Licence and environment review. Integration inventory.

2–3 weeks

Design

Solution architecture, Dataverse data model, security and sharing model, integration design, reporting design and a governance model. Reviewed with your IT and signed off before build starts.

2–4 weeks

Build & validate

Two-week sprints, each ending in a working environment your users open themselves. Migration rehearsed at least twice with reconciliation. UAT scripts written with your users, executed by them.

6–16 weeks

Adopt & evolve

Role-based training, hypercare at the desk, adoption metrics reviewed monthly against a baseline, then a quarterly release cadence that keeps up with Microsoft's two waves a year.

Ongoing
Delivery timeline showing four phases — Discover two to three weeks, Design two to four weeks, Build and validate six to sixteen weeks, Adopt and evolve ongoing — each with its deliverables listed underneath.
Indicative durations for a first production rollout covering one business unit. Phased rollouts to further entities run shorter, because the design work is already done.
Deliverables

What you actually receive, phase by phase.

Discovery report
Current-state process maps, a prioritised gap list, a data quality assessment with record counts and defect rates, a licence position and cost model, and a costed roadmap sequenced by return. Yours to keep whether or not you continue with us.
Solution design document
Entity relationship model, security roles and business unit structure, integration interface specifications, environment and ALM strategy, and reporting design. Enough detail that another developer could build from it.
Sprint demonstrations
A working environment at the end of every sprint, with a demo script and a decision log. Requirements change in the demo, not in a change request three months later.
Migration reconciliation
Row counts, exception reports, and a business sign-off per entity before go-live. Plus a documented rollback that we have actually tested.
Handover pack
Managed solutions, source-controlled configuration, admin runbook, integration credentials inventory, and a documented environment strategy. Delivered as standard, not billed as an extra.
Adoption baseline
Agreed usage and outcome metrics captured before go-live, then reported monthly. Without a baseline, "adoption is improving" is an opinion.
Governance

The engineering discipline that keeps change cheap after year one.

Most of what makes an inherited Dynamics environment expensive to change was decided in the first month of its original build, by someone under time pressure who thought it would not matter.

  • Environment strategySeparate development, test and production, with an agreed promotion path. No configuring directly in production, ever.
  • Managed solutions and layeringPublisher prefix, solution segmentation and dependency discipline, so components can be removed as cleanly as they were added.
  • Source control and pipelinesConfiguration in Git, automated deployment through Azure DevOps or GitHub. A release should be boring.
  • Configure first, code only when justifiedCustom code is a liability with a maintenance cost. We write it when the platform genuinely cannot express the requirement, and we document why.
  • Release wave readinessMicrosoft ships two major waves a year. We test them against your environment in a sandbox before they reach your users, not after.
  • Data loss prevention and tenant policyConnector policies, environment maker roles and sharing limits agreed with your IT before citizen development spreads.
Environment and release pipeline diagram: development with unmanaged solutions, test and UAT with managed solutions, then production deployed by pipeline, underpinned by solution layering, Git source control, automated deployment, DLP policy and release-wave testing.
The environment strategy we set up in week one. It is the single decision that most determines what a change costs you in year three.
Engagement models

Three ways to work with us. All of them priced before you commit.

Fixed-scope package

A defined outcome for a defined price: a discovery workshop, a single-module deployment, an accelerator fit, a health check on an inherited environment. You know the number before you commit the budget.

Best when you need a first result to justify a larger programme.

Programme delivery

Multi-module, multi-phase rollouts with a named architect, a delivery lead and a steering cadence. Scope managed sprint by sprint against a roadmap agreed at the start.

Best when several business units go live over twelve to eighteen months.

Managed support & evolution

Tiered support with defined response targets, a monthly enhancement allowance, release wave testing, licence optimisation reviews and a named consultant who knows your environment.

Best when you have a live system and no internal Dynamics capability — or want to build one.

Straight answers

Things you would find out eventually.

We do not resell licences at a markup
Buy from Microsoft or your CSP. We will advise on the cheapest compliant configuration, including cases where a Power Apps licence covers what you were about to buy a Dynamics 365 licence for.
We work in Customer Engagement, not Finance or Business Central
Sales, Customer Service, Field Service, Customer Insights, Dataverse and Power Platform. For ERP we integrate to your existing platform or work alongside your ERP partner. We would rather be excellent at one half than adequate at both.
We will tell you when the answer is not Dynamics
Sometimes the problem is process, or data, or a much smaller tool. Recommending a platform that will not pay for itself buys us one project and costs us a reference.
The person who scopes it is the person who builds it
No offshore handover after signature, no account manager relaying questions. The team is small deliberately.
Everything is built to be handed over
Managed solutions, documentation, source control, admin runbook. If you take the system in-house or move partners, it transfers cleanly. We would rather earn the renewal than hold the keys.
We take over other partners' work
Health check first — architecture, solution layering, data quality, licence position and technical debt — with a written remediation plan and a cost. Then you decide.
Start here

Begin with discovery. Keep the roadmap either way.

Two to three weeks, fixed price. Process maps, a data quality assessment, a licence position and a costed roadmap. If you take it to another partner, it still works — that is the point.