Implementation Methodology
Understand.
Design.
Prove.
Then go live.
UncertaintyControlled delivery
A successful implementation is not created by moving quickly through project phases. It is created by reducing uncertainty at the right points. We structure delivery so business decisions, solution design, data, testing, commercial scope and readiness become clearer before the organisation commits to go-live.
The project should become more certain as delivery progresses, not less.
A project should not reach UAT still trying to discover what the solution is supposed to be.
Analysis should reduce process uncertainty. Design should reduce solution uncertainty. CRP and playback should reduce interpretation risk. Testing should reduce delivery risk. Cutover planning should reduce operational risk. Go-live should therefore be the result of evidence, not optimism.
The delivery model
Ten stages, sized to the risk in front of us.
The disciplines stay consistent. The depth does not. We do not force every project into the same duration.
Mobilise
Ownership, governance and the decision model.
Understand
How the business actually operates today.
Design
Business intent, expressed so it can be challenged.
Validate
Design playback before more is built.
Configure & build
What was agreed, with change visible.
Migrate
Data becomes more trusted with each rehearsal.
Prove
Testing that follows the business process.
Prepare
Readiness, training, cutover and fallback.
Go live
A decision made on evidence.
Stabilise & hand over
Hypercare, then a real handover to support.
Depth depends on
- Scope
- Complexity
- Platform
- Data
- Integration
- Industry
- Readiness
- Risk
Cross-cutting workstreams
Some work runs across every stage, not inside one of them.
Data, integration, security, adoption, testing and commercial control are continuous. Treating them as late-stage tasks is one of the most common causes of delivery surprise.
Data
Profiling, ownership, cleansing and rehearsal start early, not at the point of cutover.
Integration
Dependencies and authoritative sources are agreed before build assumes them.
Security and access
Roles, permissions and segregation of duties are designed, not retrofitted.
Adoption
Communication, process understanding and enablement run from Understand onward.
Testing and quality
Evidence accumulates through the programme rather than arriving in one phase.
Commercial and scope control
Change, assumptions and contingency stay visible to the people funding the work.
Delivery assurance
Someone should be checking the delivery, not only running it.
Delivery assurance is a separate discipline from delivery management. It exists so that quality, evidence and risk are examined independently of the pressure to keep moving.
- Is the reported status supported by evidence?
- Are decisions being made, or deferred quietly?
- Is scope moving without a commercial conversation?
- Is testing proving business process or configuration?
- Is data readiness real or assumed?
- Are customer-side dependencies being met?
Assurance is not additional reporting. It is the deliberate act of checking whether the reported position is the real one.
Confidence gates
Four points where continuing should be a decision.
A gate is not a document review. It is a moment where the programme can be stopped, re-scoped or re-planned before cost is committed further.
Gate 1
Before mobilisation completes
Scope and commitment are qualified
The programme confirms what is being delivered, what is assumed and who is accountable, before significant cost is committed.
Confirmed at this gate
- Outcomes stated in business terms
- Scope, exclusions and assumptions written down
- Governance and decision-makers named
- Customer capacity honestly assessed
Decision
Proceed as planned · Re-scope before mobilising further · Re-sequence into a smaller first release
Gate 2
After design playback
Design is validated, not assumed
The design is confirmed against how the business actually operates, before build volume increases.
Confirmed at this gate
- Playback accepted by process owners
- Fit-to-standard decisions recorded
- Extension and integration intent understood
- Known gaps carried as decisions, not silence
Decision
Proceed to build · Revisit design in the affected areas · Change control where scope has moved
Gate 3
After the pilot and user acceptance testing
The solution is proven end to end
Evidence shows the business process running with representative data and the relevant integrations.
Confirmed at this gate
- Integrated pilot completed against real scenarios
- Acceptance testing evidence recorded
- Defect position understood by severity
- Migration rehearsal results reconciled
Decision
Proceed to go-live preparation · Extend proof in specific areas · Re-plan where evidence does not support the date
Gate 4
Before cutover, and before support transition
Go-live is a decision, and so is handover
Readiness is assessed across solution, data, integration, security, people, process and support. Handover happens on conditions, not on a countdown.
Confirmed at this gate
- Cutover and fallback rehearsed
- Business readiness confirmed by owners
- Support model and severity definitions agreed
- Hypercare exit criteria met before transition
Decision
Go live as planned · Defer with a clear reason and a new date · Go live with agreed, recorded residual risk
Business outcome control
A delivered system is not automatically a delivered outcome.
Outcomes are defined at the start, expressed in measures the business already recognises, and reviewed after go-live rather than assumed.
Define
Outcomes stated in measures the business already uses.
Baseline
Where those measures sit today, before change.
Design for
Design decisions traced to the outcomes they serve.
Protect
Change control tests whether an outcome is at risk.
Prove
Testing includes the processes the outcomes depend on.
Review
Measured after go-live, once operation is steady.
Measured business benefit depends on decisions and operating changes the customer owns, so we do not guarantee financial outcomes. We do make the intended outcomes explicit, and we make it visible when the programme is drifting away from them.
Shared responsibility
Delivery is joint. So is the risk of it not working.
Most implementation difficulty traces back to responsibilities that were assumed rather than agreed. These are stated at the start.
- Delivery method, plan and governance discipline
- Solution design, configuration and extension quality
- Migration approach, tooling and reconciliation evidence
- Testing approach and defect management
- Making risk, decisions and scope change visible
- Honest status, including when it is unwelcome
Where customer capacity is genuinely limited, that should change the plan, not quietly become a delivery risk.
1. Mobilise
Make ownership clear before delivery becomes busy.
Governance starts on day one, because the decisions start on day one.
- Kick-off and objectives
- Scope and governance
- Roles and decision model
- RAID
- Environments and licensing
- Project tooling and communication
- Workstreams and initial plan
Decision control
Every decision has a question, an owner and a date.
Most delivery surprises are not technical. They are decisions that were never made, or never recorded.
Question
Named, dated and understood.
Options
Including the option of not doing it.
Recommendation
Ours, with the reasoning shown.
Owner
A person, not a committee.
Decision
Recorded, with the date it was made.
Impact
Scope, cost, timeline and dependency.
Action
What now changes in the plan.
- Decision
- Owner
- Required by
- Impact if delayed
- Status
- A delayed decision is still a project event. It should be visible.
A delayed decision is still a project event. It should be visible.
2. Understand
Start with how the business actually operates.
Workshops exist to understand the business, not to document the legacy system or demonstrate features.
- Current process and pain points
- Controls and roles
- Data, systems and reports
- Interfaces and exceptions
- Volume and risk
- Future goals
The project should not automatically digitise the current process because it already exists.
3. Design
Convert business intent into a solution people can challenge.
Design is where complexity should surface, while changing it is still an argument rather than an invoice.
- Process and platform
- Configuration and data
- Security and integration
- Reporting and customisation
- ISV, automation and AI
- Operational ownership
Design should make complexity visible before development makes it expensive.
Fit / gap
Not every gap should become development.
Each requirement resolves to one of six outcomes, recorded with the reasoning.
Fit
Standard capability supports the requirement.
Configure
Standard capability requires controlled setup.
Extend
A justified extension is required.
ISV
Specialist capability may be more appropriate.
Process change
The business process should change instead.
Out of scope
Not part of the agreed release.
4. Validate
Show the customer what has been understood before more is built.
Design playback validates the interpretation and the future design early. It happens before significant build. The Integrated Conference Room Pilot comes later, once there is configured capability, representative data and the relevant integrations to prove an end-to-end process.
- Process walkthrough
- Configuration concept
- Data and integration
- Security and reporting
- Exceptions
- Decisions and open questions
A playback validates interpretation. A pilot proves the process. They are two different events, and we do not use one name for both.
5. Configure & build
Build what has been agreed. Keep change visible.
Parallel workstreams move quickly. Traceability is what keeps them honest.
- Configuration
- Development
- Integration
- Reports
- Power Platform
- Data
- Security
- Automation
- ISV configuration
Commercial control
A useful change process answers more than “can we build it?”
It answers what it costs, what it delays, what it touches, and who decided.
Request
Raised by somebody, for a reason.
Business reason
What outcome does it protect?
Scope impact
What else does it touch?
Cost and effort
Stated before, not invoiced after.
Timeline impact
Including the knock-on effects.
Dependencies
Data, integration, testing, training.
Decision
Taken by a named owner.
Deliver
Planned in, not squeezed in.
Clarification
No material scope change.
Defect
Agreed capability does not work as designed.
Change
A new or materially changed requirement.
Out-of-scope request
Reasonable, but not included in the current release.
A change can be reasonable and still need a commercial decision.
The same distinction between clarification, defect, change and out-of-scope request carries across into support, so nothing is reclassified quietly at handover.
Treatment outcomes
Not every new requirement becomes paid customisation.
Once a request is classified, there is more than one honest way to resolve it.
Absorb
Handled inside the agreed scope where it is genuinely minor.
Trade
Included by removing or deferring something of similar size.
Defer
Moved to a governed post-go-live backlog with an owner.
Price
Agreed as a change with cost, effort and timeline stated.
Decline
Declined with the reason recorded, not quietly dropped.
Commercial transparency
Leadership should see the commercial position, not reconstruct it.
What appears in programme reporting depends on the contract model and what has been agreed with you. These are the areas commercial reporting can cover.
- Position against the agreed commercial baseline
- Approved changes and their cumulative effect
- Assumptions that have not held
- Contingency use and remaining contingency
- Dependencies affecting cost or date
Fixed commercial commitment depends on qualified scope, assumptions and customer responsibilities.
6. Migrate
Data should become more trusted with each rehearsal.
Migration, integration and security run as delivery workstreams, not as tasks discovered near cutover.
Profile
Measure it before promising anything.
Clean
The business decides what is correct.
Map
Legacy structure meets the future design.
Rehearse
More than once, and timed.
Validate
Users check real scenarios.
Reconcile
A provable bridge from source to target.
Cut over
The approved final load.
- DM1: core master data
- DM2: master data plus open operational data
- Full rehearsal: representative cutover volume and sequence
- Final migration: the approved cutover load
- Names and the number of cycles change by project. Three is not a universal rule.
7. Prove
Testing should answer increasingly difficult questions.
Do not only test whether a sales order can be created. Test whether a real order moves from customer request through availability, picking, shipment, invoice and reporting.
Developer / configuration test
Does the component work?
Functional test
Does the requirement work?
Integration test
Do connected systems behave correctly?
FAT
Does the configured solution operate as intended?
Integrated CRP
Does the end-to-end process make sense to the business, with real data and integrations?
UAT
Can the customer demonstrate readiness to use it?
Cutover validation
Did the production transition work?
The testing depth is scaled to the risk, but testing is not removed simply to make delivery appear faster. Smaller projects should not carry duplicated stages for their own sake.
Integrated Conference Room Pilot
Prove the representative end-to-end process before UAT.
The Integrated Conference Room Pilot uses sufficiently configured capability, representative data and the relevant integrations. It sits after build and internal proof, and before user acceptance testing.
- Sufficiently configured capability
- Representative business data
- The integrations the process depends on
- Real scenarios chosen by the business
- The people who will run the process
A CRP should feel like the business process, not a software tour.
- Confirms configured and developed capability against agreed requirements before customer UAT
- Configuration, customisation, integration, reports, security and negative scenarios
- Smaller projects should not carry duplicated stages for their own sake
Underneath the test plan
Non-functional testing follows the qualified operating risk.
Not every programme needs every test. Where the operating risk justifies it, these areas are planned deliberately rather than discovered in production.
Testing should prove the business process, not only the configuration.
Change and adoption
Adoption runs throughout, not at the end.
People adopt a process they understand. They resist a system they were shown once. Adoption work starts during Understand and continues well beyond go-live.
Understand
Who is affected, and how their work changes.
Design
Process owners involved while decisions are open.
Prepare
Communication, champions and role-based training.
Go live
Support at the point of use, not only a helpdesk.
Embed
Reinforcement, refresher training and new starters.
- Process training and role-based training
- Super users
- Scenario-based training
- Work instructions and recorded content
- Knowledge base and practice time
- Users should learn the process, not memorise navigation
Deployment is not adoption.
8. Prepare, 9. Go live
Go-live should be a decision, taken on evidence.
Readiness is assessed across solution, data, integration, security, people, process, support and timing, and the cutover is rehearsed before it matters.
- Solution readiness
- Data readiness
- Integration readiness
- Security readiness
- People readiness
- Process readiness
- Support readiness
- Business readiness for the timing itself
Go-live pressure should not convert unresolved risk into accepted risk by default.
What go-live represents
One go-live, a first release, or one wave of several.
Go-live may represent the complete programme, a controlled first operational release or one wave of a broader rollout. Where a wider footprint is involved, a programme may prove a common design first and extend through separately qualified waves. Not every customer needs waves, and we do not publish wave counts or durations.
01
Prove
Establish a common design in one representative area.
02
Template
Agree what is standard and what is genuinely local.
03
Qualify
Each wave is assessed on its own readiness.
04
Extend
Deploy the proven pattern to the next scope.
05
Stabilise
Each wave stabilises before the next begins.
06
Improve
Template updated from what each wave teaches.
10. Stabilise & hand over
The project ends properly, or it does not really end.
The quality of an implementation becomes most visible after go-live, when real users, real data and real operational pressures meet the solution.
Hypercare
Heightened attention immediately after go-live, with faster routes to the people who built it.
Stabilisation
Fix, tune and clarify. Most week-one issues are process, data or training, not code.
Handover to support
Documented solution, known issues, owners and a real transition, not a silent exit.
Continuous improvement
The backlog deliberately deferred at go-live becomes an improvement plan, not a grievance list.
Hypercare exit
Hypercare ends on conditions, not on a countdown.
Hypercare ends when the agreed transition conditions are met, not simply because a fixed number of days has passed. The conditions themselves are agreed per programme, alongside the support model.
- Critical and high defects resolved or accepted
- Period-end or equivalent cycle completed where relevant
- Reconciliation and reporting confirmed by the business
- Users operating without daily project intervention
- Documentation and known issues handed over
- Support model, contacts and severities agreed
After go-live
Go-live is an implementation milestone. It is not the business outcome.
The lifecycle continues, and deferred requirements become a governed improvement backlog rather than an uncontrolled extension of the implementation. None of the later stages is mandatory.
Stabilise
Hypercare, with the delivery team still close.
Hand over
Transition to support on agreed conditions.
Review
Outcomes reviewed once operation is steady.
Improve
The deferred backlog becomes governed improvement.
Expand
Further scope, only where the case is real.
How this connects
The same disciplines, applied at different intensities.
Transformation, recovery, acceleration and improvement are different starting points, not different standards.
Transform / Implement
The full model, applied to a programme that is replacing or rebuilding the operating platform.
Recover
When delivery has lost control, we usually find missing decisions, unmanaged scope and untested data.
RAPID
The same disciplines, compressed, where scope, data and readiness genuinely support acceleration.
Optimise
Smaller changes on a live platform still need design, testing, decisions and a release.
Delivery in practice
Customer experience of delivery with InteliSense.
Published customer videos describe implementing Dynamics 365 with us, in the customers' own words. They are evidence of those customers' experience rather than proof of every stage described on this page.
80% of our business comes from existing customers and referrals.
Hill & Smith's published story title includes a five-month statement. That is their published story, not a standard implementation duration, and we do not present it as one. We do not claim these videos prove CRP quality, testing depth, on-time or on-budget performance, accelerated delivery, recovery or support outcomes, because the published material does not state that.
Check the fit
Where should your delivery conversation start?
Five short questions. The result is a suggested starting point rather than a diagnosis of your project or a commercial commitment.
Indicative signal
Answer the questions and we will show a likely starting point. This is a suggested next route rather than a diagnosis of your project. Please keep every answer at organisational level: no customer, personal, patient or case information.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Common questions
Questions leaders ask about delivery.
Implementation & delivery assurance
Is your project becoming more certain, or less?
Whether you are about to start, part-way through, or trying to regain control of a delivery that has drifted, we can walk through the decisions, scope, data and testing evidence with you.