Recovering and Delivering a Microsoft Dynamics 365 Program

1. Context and program reset

The program had already experienced two unsuccessful vendor-led implementation attempts. Rather than treating the next phase as another technology rollout, the approach was reset around business outcomes, clearer decision rights and a controlled delivery model.

• Re-established business sponsorship, scope and accountability across multiple business units.
• Reframed the work as a business-process, data, integration and adoption program rather than a CRM configuration exercise.
• Defined delivery governance, decision rights, acceptance criteria and escalation paths.
• Introduced stronger vendor risk management where incumbent delivery capability was not sufficient.

2. Discovery, requirements and business process

Discovery focused on how customers moved through the organisation, how service interactions were handled, which processes should be standardised and where local variation was justified.

Requirements and user stories

Functional and non-functional requirements, user stories and acceptance criteria were captured in language business stakeholders could validate.

Sales journey

Lead, opportunity, customer, pipeline and sales-management processes were mapped, including hand-offs between front-office activity and downstream operational systems.

Customer service case management

Case intake, ownership, routing, escalation, service visibility and reporting requirements were defined alongside supporting processes.

Knowledge management

A reusable knowledge-base approach was introduced to improve consistency of responses and support service teams.

Telephony and call-centre integration

The design considered caller context, case handling, call-centre workflows and the connection between telephony and customer-service records.

MVP and phasing

Must-have capability was separated from later optimisation so the program could regain momentum and deliver controlled value.

3. Solution and integration design

Dynamics 365 was treated as one component of a wider enterprise ecosystem. The solution design therefore focused on how customer data, operational data and marketing activity moved across platforms.

• Microsoft Dynamics 365 for sales, marketing and customer-service capability.
• ERP integration connecting customer, quote, order, inventory and operational information.
• MarTech integration supporting marketing automation, campaign activity and customer engagement.
• SQL and related data flows supporting reporting, migration and system integration.
• Security, role design, access controls and separation of responsibilities.
• Master-data and data-quality considerations supporting a trusted customer view.
• Reporting and analytics design providing a more complete view across sales, service and customer interactions.

4. Reporting, analytics and management information

A reporting function was designed alongside the CRM rather than added after go-live. The objective was to provide a consistent view of activity and performance across implemented modules, support line-of-business management and connect customer and operational activity to commercial and financial reporting.

• Cross-module reporting across sales, customer service, marketing and related CRM activity.
• Line-of-business reporting with consistent group definitions and measures.
• CRM activity connected with ERP and operational data to link customer and sales activity to orders, revenue, service delivery and financial outcomes.
• Management information covering pipeline, conversion, customer activity, service levels, case ageing, response and resolution performance, campaign activity and platform adoption.
• Common definitions and data-quality controls to reduce competing versions of the truth.
• Operational reporting for day-to-day management and higher-level reporting for executives, Steering Committee and business leaders.
• Reporting ownership and enhancement moved into the BAU operating model.

5. Vendor, contract and delivery risk management

Where an incumbent supplier could not reliably provide all required capability, the delivery model was supplemented while commercial obligations, risk, performance and continuity were actively managed.

• Clearer milestones, deliverables, acceptance criteria and escalation paths.
• Additional specialist capability where vendor performance or expertise was insufficient.
• Delivery, commercial, continuity and dependency risk managed across vendors and system integrators.
• Reduced concentration risk by retaining critical knowledge and internal ownership of decisions.
• Statements of work, scope, milestones, commercial terms, responsibilities and acceptance criteria reviewed and negotiated.
• Contract changes, scope variation and commercial negotiation managed alongside delivery governance.
• Supplier performance linked to measurable deliverables, service expectations, risk treatment and escalation.

6. Building the program team

The delivery model included deliberate recruitment and capability planning, with temporary and permanent roles used at different stages of the program.

• Temporary and specialist capability recruited for delivery peaks and specific skill gaps.
• Internal capability developed so business and technology teams could increasingly own the platform.
• Roles recruited specifically to support the transition from project delivery into BAU operations.
• Knowledge transfer, documentation and handover structured so temporary or vendor resources could exit without creating operational dependency.

7. Program governance, communication and stakeholder management

Formal project-management disciplines created visibility, clear accountability and predictable decision-making across business, technology, vendors and geographically distributed teams.

• RACI defining who was Responsible, Accountable, Consulted and Informed for key decisions and deliverables.
• Steering Committee / SteerCo cadence for executive decisions, risk acceptance, scope, budget and escalation.
• Matrix management across business functions, technology specialists, vendors and remote team members.
• RAID controls covering Risks, Assumptions, Issues and Dependencies, supported by decision logs and action tracking.
• Integrated delivery plans, milestones, critical-path tracking, change control, status reporting and readiness checkpoints.
• Stakeholder and communication plans defining audience, message, owner, channel and frequency.
• Regular project and workstream forums with documented decisions and controlled communications.

8. Build, integration and validation

• Platform configuration and customisation.
• ERP, MarTech, SQL and related integration development.
• Data cleansing, mapping and migration planning.
• Progressive demonstrations with business stakeholders.
• User Acceptance Testing (UAT) against business processes and acceptance criteria.
• Operational Acceptance Testing (OAT) covering supportability, access, integrations and production readiness.
• Structured defect triage, prioritisation and retesting.
• Readiness criteria covering technology, data, users, vendors and support.

9. Change, training and adoption

Communication, training and adoption were managed as formal workstreams, including support for geographically distributed and remote staff.

• End-user communications covering what was changing, why it mattered, when it would happen, required actions, cutover impacts and support channels.
• Role-based training using real sales and customer-service scenarios rather than generic system demonstrations.
• Remote training and support through virtual sessions, recordings, guides and follow-up clinics.
• Business champions and super users reinforcing local adoption, gathering feedback and providing first-line guidance.
• Readiness and adoption issues tracked, with recurring questions fed into support documentation and the knowledge base.

10. Cutover and go-live

• Sequenced data migration, integration activation, final configuration and production validation.
• Go / no-go criteria and escalation responsibilities.
• Fallback and contingency considerations for critical dependencies.
• Vendor, internal-support and business coverage for the initial production period.
• Targeted cutover communications to users, managers and support teams.

11. Hypercare and stabilisation

Hypercare provided a structured bridge between project delivery and steady-state operation. The objective was not simply to fix defects, but to stabilise the platform, integrations and support model.

• Dedicated issue and defect triage with clear severity and ownership.
• Rapid coordination across business, internal technology and external vendors.
• Monitoring of key integrations and operational workflows.
• Production defects prioritised separately from later enhancements.
• User support, adoption observation and documentation refinement.
• Progressive transfer of operational knowledge to the BAU team.

12. Transition to BAU

BAU transition was designed as part of the program rather than as an activity that started after go-live. The goal was a supportable platform with clear ownership, known dependencies and a sustainable delivery model.

• Defined platform, application and integration ownership.
• Established SLAs, escalation and vendor-support arrangements.
• Completed technical and as-built documentation.
• Transferred knowledge to internal administrators and support roles.
• Embedded change, release and environment-management processes.
• Separated production support from the enhancement backlog.
• Transitioned temporary and specialist delivery roles out as permanent BAU capability became effective.
• Transferred relevant supplier contracts, SLAs, support obligations, escalation paths and commercial knowledge into BAU.
• Established ongoing service-review and vendor-performance cadence.
• Transferred ownership of CRM reporting, KPI definitions, data-quality monitoring and dashboard enhancement into BAU governance.
• Maintained reporting and optimisation backlogs for controlled continuous improvement.

Key lessons