Microsoft Dynamics 365 Legal Expertise

Because Dynamics 365 involves a third party implementer, the procurement process has potentially two stands to it: (1) Dynamics 365 vs another core systems solution then (2) which Dynamics 365 partner to select. 

Selecting the right solution requires:
Determining your requirements (all your required business functions and gaps in existing systems). These should be categorised as: (1) essential, (2) future essential, (3) desirable and (4) nice to have.

Assessing potential systems against those requirements and in particular assessing whether they are met:
- Out of the box (within the core solution)
- Through configuration
- Through development
- Through integration with the relevant implementation partner
- Through integration with a third-party solution

We are often brought into negotiations with a supplier after this has been finalised, yet we can add significant value at this stage, not least by controlling the “terms and conditions” that will apply at contract award. 

As with many other core systems providers, an implementation partner needs to be selected. 

Sometimes the answer as to the integration partner is clear where, for example, a sector specific product has been created by a partner and that is the reason Dynamics 365 has been selected in the first place.

In other situations, the selection is generally down to:

- Geographic reach
- Sector experience
- Resources available
- Add-on products developed by the partner

We have been involved with arrangements where: one partner has been replaced with another or the implementation is sufficiently large that the selection of a “prime” contracting partner is backed by a subcontracted secondary partner.

This is the first activity with the selected partner, which sets the expectations between the parties. The aim is to gain as much specificity as possible, acknowledging that the Detailed Design phase goes to a much greater level.  

Key issues are:

• To ensure the scope ties back to the requirements. See Specification vs requirements
• Identify and document any agreed “gaps” against the original requirements (as time moves on and requirements change)
• Confirming what is out of the box vs through configuration vs through development vs through integration  with a third-party solution
• This can and should form part of the main contract, but we do often see this phase started in haste without the right contractual protection. It is possible to pull it back under the wider arrangement but this can be difficult

Detailed design is where the design of the new system is finalised. This essentially covers the contents of blueprinting/scoping, but to a much greater depth, enabling both parties to be able to understand their respective obligations.

It is important to see a detailed and comprehensive RACI matrix (Responsible/ Accountable/ Consulted/ Informed). 

A very common area of dispute comes from a lack of understanding on the part of the customer as to its obligations and “over-optimism” on the part of the implementer in this respect. 

This is where the solution is configured and developed (as applicable) in accordance with the detailed design. 

This may include developing custom modules, integrating with existing systems, and configuring the system to meet specific business requirements.

Once built, the solution needs to be implemented. This involves deploying the new system, migrating data from existing systems, and training users on the new system. 

It is crucial to have a well-defined plan for data migration and user training to ensure a smooth transition. 

There are differing elements to testing, whether (for example): 

• Functional testing
• Load testing
• Penetration testing
• User acceptance testing 

It is important, yet often overlooked, to ensure that:

• It is clear which party is responsible for which elements
• How the acceptance criteria are to be set
• How testing will take place
• How achievement is determined
• What happens if there is a failure

Following successful acceptance testing, a date is agreed for go-live.

This is a short period of support immediately after go-live where typically the original team who implemented the solution remain on the project to monitor and deal with issues. 

We work with clients to ensure hypercare runs for an appropriate period of time, that the right people are made available for hypercare and that appropriate response and resolution targets are applied, together with appropriate consequences for any failures. 

Life isn’t perfect and systems never quite run perfectly!

Ongoing managed support is therefore an important part of the contracting process.

See IT services