The stages of an AX Software implementation typically are;

Requirements

The first stage always has to be a review of the requirements, you may think they are already detailed enough but often what can be listed as a single requirement will break down into multiple requirement instances, impacting multiple areas of Dynamics D365 each requiring their own distinct piece of work.

Plan

All have to be built into the plan, each will have effort associated with them, discussion to determine best approach, often system configuration, workshops to proof the solution, documentation, testing etc…

Simply put everything takes time, time costs money and its better to do as much of it right in the first instance than have to revisit and potentially redesign what has already been done if something has been overlooked.

The planning stage takes all the requirements and provisions time for all the activities and matches these to the people doing the work, if the timeline does not fit into plan something has to change, you can change the time line, drop things from the requirement list or increase the resource.

Ultimately the agreed plan will be the output all parties work to, it reflects the budget, the deliverables and timeline, it is the essential backbone of the implementation project. The plan can be in the form of the traditional MS Project form, something more abbreviated or Dev Ops but it has to be controlled with changes agreed by all parties and all workstreams duly informed.

You often hear terms such as Waterfall project plans or Agile, the fact is there are advantages to both and interestingly some workstreams benefit from a mix of the two (HR for example – call and we can explain) but put simply you start with a plan and execute against the latest version of it.

The planning approach is something partners and clients agree upon sometimes there just isn’t the appetite or budget to accommodate the type of approach preferred and we frequently end up with something in the middle ‘Wagile’ been the term there!

Build & Playback

Following the plan build commences, nowadays Sprints are a typical way in which plans are manifested into configuration and build, following which D365 will be demonstrated to the client team where key areas of functionality, configuration and solution specification confirmed.

Gaps in standard functionality, with review and confirmation informing all what the eventual build will consist of.

If the company is distributed across multiple locations and territories, then discussions will include the functional requirements in the local offices, considering how the existing systems currently operate, the local market demands and balancing this against the advantages of standardisation.

These discussions will also incorporate legal structure and types of entities (incl. branches, JV’s, dormant, earn-outs etc.), management and group reporting.

Implement

Once any iterations of earlier stages have been completed, the business is ready to begin to implement. The tasks and activities associated with this stage will have been refined in the Plan and many will already have commenced been worked upon consecutively with other workstream activities e.g. data migration preparation such as cleansing etc

It all culminates in a period of User Acceptance Testing (UAT) where a subset of the entire solution is tested by the users before been signed off ready for go-live

Go-Live

On successful completion of UAT the business is ready to cutover to go-live operations, data is migrated from old systems to new, users provided with security and access profiles, balances and open transactions checked and confirmed. Again all the activities and tasks will reside in the plan and be ticked off as completed.
Typically a period of hyper-care will accompany go-live where consultants are on hand to sort those inevitable issues that will arise, a month is normal but the rate at which the issues list disappears is the health barometer here.

Reviews

Each of the above stages will have a review phase, essential to monitor the progress of the overall programme. Constantly monitoring progress removes hidden surprises and informs all as to the status, whether further information has come to light, if there are challenges to overcome, impact on timeline and budget.

It has to be clearly understood at all times and by all stakeholders where the programme/project stands in terms of its goals, objectives, timeline and budget.

Summary

The above is not by any means a definitive list of all that goes into a Dynamics implementation but lays out the logical steps in a project.