REQUIREMENTS, PLAN, BUILD, IMPLEMENT, GO LIVE
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.
Pricing Your Project
We are happy to offer time and materials as well as fixed price proposals, even on relatively small projects where we appreciate some clients want to get to know their supplier before committing too heavily to projects and the team helping implement them.
Whether fixed price or T&M, our projects follow a four stage approach, which we have designed to incorporate the best of traditional methodologies whilst not burdening the project with unnecessary administration.
Time & Material Based Projects
For some clients, the traditional time and materials contract is the best option. Whereas a fixed price contract will require some premium to be added (typically 10% to 15%) to accommodate the extra risk transferred to the supplier, this is not the case with time and materials.
T&M can often suit clients that have specific pieces of work they want their partner to complete for them.
Examples might include:-
Distinct pieces of work such as implementing a feature within a module i.e. Compensation within Human Resources
Reviews of existing business systems i.e. can we do things better such as streamline workflows
Works not associated with D365 such as help with defining business requirements
T& M also tends to suit clients that wish to adopt a blended approach, using their own internal resource alongside our own, cherry picking the areas that their team focus on and calling in our support as and when necessary.
Fixed Cost Projects
Where a fixed cost engagement is preferred it enables clients to know what the implementation will cost and essentially transfer the risk of over run to us.
Fixed price may prove to be more expensive than a T&M arrangement, particularly where the project goes smoothly or where the client takes a close interest in the management of resources as basically effort we as the supplier expected to expend is lessened. Incidentally this type of approach generally lends itself to a good project, the more the client takes on ownership the better they understand their new D365 business solution.
We are generally happy to offer a fixed price proposal based on our methodology as follows.
The planning stage stays the same. This will represent between 5% and 10% of the overall project cost and will enable us to prepare a detailed project plan and costing for the project.
Based on this, we will offer a fixed price proposal for the remaining three stages of the project. So, for example, a typical project might involve an initial planning stage of, say £50,000, which would lead to a fixed price proposal in the region of £450,000.
The fixed price proposal will be based on the project plan and will stipulate in detail the work to be carried out by both sides and the timescales for completion of this work. If our work over runs, then we will absorb the extra cost. If the client’s assigned tasks over run, then this may involve extra costs, re-planning with additional costs been added to the fixed price.
We always strongly emphasise the level of detail that needs to be conducted by the client in ensuring that their requirements are fully detailed, inexperience generally leads to poorly defined or loose requirements which reveal additional work in later stages.
It will be these requirements that will form the basis of our scope of work and its in all our interests to have these well understood from the outset and referenceable against D365, its against these that configuration and build are made, its acceptable to miss a few but too many and plans go awry.
