The Gift that Keeps on Giving – the cost of poor solution design

As the sponsors of too many implementations of CRM have found out, the cost of poor solution design has usually only just started at go-live. Just like ‘pass the parcel’ where there are small gifts at each layer, the surprises caused by poor solution design, keep on coming. Unlike ‘pass the parcel’ you have no idea when they will end, nor what the big surprise will be.

Typically, the symptoms of poor solution design that will show after go live are:

• User adoption difficulties
• Problems when creating or generating reports or otherwise extracting data
• Challenges with making superficially small changes in business processes

When the solution does not take the process flow into consideration, maybe because the focus of any scoping was too data focused, perhaps from paper forms, users will struggle – even if they did receive good end user training. If the training was poor - or missing, these users will almost certainly revert to their previous way of working.  I wrote about this here .

Reports can be problematic when the data structure was ignored. This often occurs because data entry is given too much priority over the ultimate data usage.

I am working with a client who is struggling with this when trying to run campaigns. Although the data is in the system, they are unable to access it without using complex data extraction tools because of how it is structured.

This has turned their CRM into a time-swallowing, data repository.

Another challenge that can arise from poor solution design is a solution that does not take into consideration the natural structure of data.

An example of this that I saw again, recently, is address entry using separate look ups for each of suburb, state and postcode, when these should be linked.

Businesses evolve, and your CRM should evolve with you. However, if you are unfortunate enough to a badly designed solution, you will struggle. It is essential that flexibility is not mistaken for complete freedom. In even the most flexible solution, you still need to follow the rules and use the solution how it was designed to be used.

One example of this, that I saw a few years ago, was where the provided product catalogue had been redeveloped-as the standard approach was deemed ‘too complex’. This new, simpler approach only supported one price per product. This ‘easier-to-use’ model worked –until another department came on board. This new department needed to sell the same products at different prices, but the business management wanted to report on sales by product.

While this selling of a product at different prices, and reporting on overall product sales works wonderfully using the standard functionality, the ‘simplified, easier to use’ version could not achieve this. To make matters worse, by the time the problem was discovered, the new, simplified model had been integrated to the finance system, so the rollback became very expensive. This client paid multiple times for what should have been nothing more than some data import to the standard Dynamics 365 product catalogue. They ended up with the standard functionality, but they got there by a tortuous and expensive route.

Another example of poor solution design that I’m working with, is for a client where their original implementation partner decided to reinvent the standard activities in Dynamics 365. While this was clunky from the outset, the wheels completely came off when they wanted to use Outlook for email activity.

Again, working via Outlook is standard functionality in Dynamics 365, but it did not work in the ‘new, improved’ version provided by this implementation partner. 

Here, once again, my client has paid many times over – in this instance for a brand-new implementation of Dynamics 365. This client has also ended up with the standard functionality, but they also got there by a tortuous and expensive route.

How much does poor solution design cost you?

It is impossible to put a dollar figure on the cost of poor solution design. But, it is rarely small. In the solution design part of a project, particularly in the implementation of a technology such as CRM, small. mistakes can lead to big problems.

Many years ago, when I was working in India, I was told that organisations need to implement CRM three times to get it right. The first two attempts teach what they need to know for the successful third attempt

Some people argue that the inherent flexibility of a technology means that it should be possible to make changes whenever, and some even go as far as using the flexibility as a reason for not completing thorough scoping. While all true CRM technologies are flexible, the flexibility can be abused as the examples of product catalogue and activity redesign given above highlight. The flexibility also should not be used as a way to layer changes onto changes.

Poor design decision can be discovered during:

• Design
• Implementation
• Testing
• Training
• Post go Live

The earlier in the project that an error is found, the easier and cheaper it is to fix – if not fixed here, it can become a chain reaction. After implementation, it becomes potentially, exponentially, more expensive to resolve. This is because the poor design is now embedded into the solution and has influenced many other data and integration decisions. It may also require recreation of training materials and retraining of users. This was seen in the ‘simpler’ product catalogue case study mentioned earlier.

When the mistake is discovered during design, it usually a simple fix. The solution architect, who will have a deep and detailed knowledge of the technology will pick this up.

Problems get past this phase either when there is no (effective) solution architect involved in the design – or when the customer is too dictatorial, and forces decisions without understanding the consequences of those decisions.

The customer is not always right

When I challenge people about their solution design decisions, a common reason given – especially after a poor decision has been discovered - is that a user, or other member of the customer team, asked for it. It is our responsibility as the technical experts, to act as a handbrake, not just to agree to everything that the customer asks for.

When I am asked to implement functionality, I ask the following questions:

• Why do you need this functionality?
• What would be the cost - to the whole organisation - if I did not implement this functionality?

Until I have satisfactory answers to these questions, I do not proceed with the implementation.

A common area of poor solution design is in the sales process. Dynamics 365 – and every other true CRM technology - has a well-structured inbuilt sales process, which now includes a process flow. This inbuilt process starts at lead and passes through opportunity, quote and order to invoice – initial enquiry to money.

However, I have seen too many projects where configuration is done to the lead to make it the vehicle for the entire sales process. This both costs money and denies a huge amount of value that the standard product provides - i.e. you pay more for less functionality!

I am working with a client whose lead has been configured so it is enormous – so enormous and so complex that the users refuse to use it. Instead, they use a portal form – which is still not the best way of meeting this need.

The lead form now contains fields for all the details of the solution that the client requires, and the financial transactions done with the client. This solution also has side-stepped the standard product catalogue.

This organisation is in the throes of moving back to standard functionality, again by a tortuous and expensive route. In this case, I believe that the whole project could have been done in less than half the time, so less than half the cost, and delivered far better results, if the solution had stayed closer to standard.

Here we have an example of the third attempt will get it right – just like I was told in India.

Keep it superbly simple

This is one of the mantras that I teach in our Configuration of Dynamics 365 training. For each business requirement I do the following checks:

1. Is the functionality available as standard?
2. If not, is the functionality available using configuration
3. If not, then use customisation to implement the requirement.

I differentiate between configuration and customisation by the need for code rather than simply using the tools provided within the technology. Customisation requires code while configuration can be done by a power user - who has been trained in the tools available.

This requires the technical team members to also know the standard functionality of the technology – a check that is often omitted. When the functionality is not understood by the technical implementers, there is a tendency to configure for functionality that already exists – as the case studies highlight.

Another challenge is that implementers will over-complicate a solution, and justify this because they are using the provided configuration tools. I require my implementers to justify why they have moved from standard to configuration and configuration to customisation – and you would be well advised taking the same approach.

Many of my training delegates tell me – after their configuration or automation course - that they wish they had done the training much earlier in the project. Had they known earlier in the project what they learnt during their implementation, and even more so what they understood after the training, their implementation would have been smoother, considerably cheaper, and would have delivered better results.

Agile implementation is never a substitution for scoping or requirements workshops

Agile is a very popular way of implementing a solution such as a CRM. However, not every project that calls itself ‘agile’ is really agile. Agile is a methodology, and done properly, it is a fantastic way of implementing CRM. An agile implementation never removes the need for scoping. However, agile is frequently abused and used as an excuse for avoiding scoping. This idea of ‘implement a bit and make changes at the whim of users’, is not agile – it is chaos, or fragile, and it is a fast track to project failure.

As one of the key decision makers in your organisation, you can reduce the chance of this happening by investing in education, so you understand the functionality available before any configuration or customisation is done. By arming yourself with this knowledge you are more able to have meaningful conversations with your implementers.

If you are unlucky – like too many of my clients - and get really poor implementers, the education will help you see this sooner. Some of my clients tell me that they should not have to do this. They are correct - they should not have to do this, but, given the number of projects where poor solution design is foisted upon the client - forewarned is forearmed. Certainly, you must have a process when selecting any implementation partner to ensure that neither the organisation that you choose, or the individuals allocated to your project are likely to do this to you.

In our scoping workshops, we look at:

• Your reasons for implementing CRM, or this improvement to CRM
• Your business processes
• Your reporting requirements
• The users affected by this project

We do this in a workshop environment to avoid the ‘he said / she said’ situation that can arise when individuals are asked separately about their needs from CRM. At the end of the workshop process, your team, comprising key users, not all users, will have mapped out the to-be processes, decided on the majority of the outputs and provided key information about the users and their requirements of CRM.

This level of scoping cannot be done until the participants have some understanding of the standard functionality of your chosen technology.

How to identify a partner who is less likely to create the poor solution design problem

1. Ensure that the partner has a policy of staying as close to standard as possible – and that they can demonstrate this
2. Ensure that their team members are skilled in the selected technology – both functionally and technically - and confirm this for yourself. This point again should not be something that you need to check, but unfortunately it is.
3. Ensure that the partner is comfortable working with a fixed price fixed scope model – and then invest the time in a thorough scoping to create that fixed scope. Implementers who work exclusively on billable time have an interest in creating work, rather than delivering value quickly.  Ensure that the scope is focused on your future business processes – not current processes - and certainly not just on data inputs.

Who is Gill Walker?

Gill Walker is a Dynamics 365 Success Catalyst: a Microsoft Dynamics 365 Trainer, a Speaker on CRM, an Implementation consulting expert. Her Dynamics 365 training and consulting company is Opsis - www.opsis.com.au

• She is a professional trainer who shares her wide knowledge of Microsoft Dynamics 365 with her training delegates – so they can implement and manage their Microsoft Dynamics 365 more easily and effectively;
• She is a speaker who shares her knowledge of varied CRM topics with her audiences;
• She is an author who loves spreading knowledge of CRM and specifically Microsoft Dynamics 365 via articles such as this;
• She is an expert consultant who has been helping her clients with their Microsoft Dynamics 365 (and previously Microsoft Dynamics CRM and Microsoft CRM) challenges since 2002;
• She is a troubleshooter – who helps organisations with their sticky problems.

Please feel free to contact her via linked in (https://www.dhirubhai.net/in/crmconsultant/) or email ([email protected]).