Three ways that poor design leads to budget blowout on CRM projects

There are many downsides if you end up with a poor solution design in Microsoft Dynamics 365 - and other line of business software products. The greatest of these downsides is budget blowout - potentially massive budget blowout.  How much did it cost to make the bridge useable and safe?

The problems caused by poor design may surface early on in the project but more often later in the project.

Three ways that poor design leads to budget blowout are:

1. Increased data storage costs;
2. Increased support costs for several reasons, including longer times for incoming support people to understand the solution, more complex integrations and perhaps longer to implement in the first place;
3. Slowing down users and perhaps significantly reducing adoption, which can be a massive business cost

In my work helping organisations to improve their Microsoft Dynamics 365, I see a lot of poor design. The root cause of poor design is usually one or both of two factors:

• Lack of knowledge of the technology
• An unwillingness, or inability, to establish the actual business requirement, preferring instead to simply take instructions.

Perhaps the commonest aspect of poor design that I see is unnecessary custom fields. I am working with a client whose D365 CRM has about a thousand custom fields between the contact, account, lead and opportunity. Custom fields cost in data storage - even when they are unused!

When I analysed the usage of these fields, most of them are only populated in about 1% of records. The majority of them can be replaced with other functionality, including:

• existing standard fields
• calculated fields
• views
• mapping
• quick view forms and
• automation

A few years ago, I was working on another project and the CIO behaved as though adding fields was the first choice - perhaps the only choice - for configuration.

Achieving a solution that avoids these high - potentially very high - costs requires:

• A project lead / Solution Architect who knows the functionality of Dynamics 365
• An implementation team which is willing to get to a genuine business requirement – not just take instructions
• A willingness from the business including the CIO / CTO / tech lead to listen to alternative approaches and understand the impacts of their ultimate decisions