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

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.

While perhaps insuring yourself yourself against poor solution design should not be your responsibility, in reality, it is. The number of projects where significant increased cost is incurred because of poor solution design is huge. In my experience, the vast majority of projects cost far more than they should because of poor design.

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

All of these issues are reasons that we see cited as causes of project failure. I have written about all of these issues elsewhere.

When the solution does not take the process flow into consideration, maybe because the focus of any scoping was too data focussed, 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.  You can read about this here .

Even if you are using the agile methodology, you can only bypass scoping at your peril.  Agile often requires more scoping as scoping should form part of each (or at least most) sprint.  Please do not get entrapped by an implementation partner who claims that scoping is not required because they will work agilely. 

Scoping should do several things including (but not limited to):

• Highlight the key success factors of the project - and these should be communicated to, and understood by, all members of the team;
• Take a future-focussed look at the processes and data flows;
• Look at the reporting that the system will be expected to provide

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

This has turned their CRM into a time-swallowing, data repository, instead of a tool which can improve the business.

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

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.

While this selling of a product at different prices, and reporting on overall product sales works wonderfully using the standard Microsoft Dynamics 365 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 very expensive route.

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 very 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 the organisation what they need to know for the successful third attempt.  Personally, I find this frightening.  There are better ways of learning than completing a failed implementation.  Imagine if we taught our children to cross the road by throwing them out into the traffic!!

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 - like a gentle tap to a domino tile.

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.  Customers should outline business requirements, leaving the design of the solution to deliver those requirements to the solution architect.  This requires that both the technical eam and the cistomer representatives undersrand the difference between a business requirement and a solution to that business requirement.

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!

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 - instead using a myriad of lookups, each to a different custom entity for the components of the solution.

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, so that they can answer 'Is the functionality available as standard?' – a check that is often omitted. When the functionality is not understood by the technical implementers, there is a tendency to configure - or worse still to customise - 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.  In Dynamics 365, like many other areas of life, just because something is possible, does not mean that it is a good idea!

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.  Highlight that you are aware of these poor design risks and ask what the partner's approach would be if such a poor design was used?
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 focussed on your future business processes – not current processes - and certainly not just on data inputs.

How can you protect yourself and your organisation from the ongoing cost of poor solution design?

The simple answer to this is to maintain the complete ownership of the project with internal people. 

• Use third party resources where necessary, but keep the overall management of those resources as an internal responsibility.
• Do not allow your users - at any level - to mandate features which they do not understand.
• Invest in training, so you have the knowledge to spot the problems early in the project and so avoid the increased expense of being bitten later on.

This is not as hard as it sounds - ask me how!