Designing the solution to take maximum advantage of functionality of the technology
When designing how a technology should be configured, or customised, to create the solution required by the business, it is too easy to fall into the trap of having one group of people who know the business communicating with a separate group of people who know the selected technology.
This two-tiered approach is a mistake and often leads to the project costing more. This happens because the two groups are effectively speaking different languages – one is speaking business-speak and the other is speaking techie-speak and so key detail is lost in translation. I have written about an aspect of this here
The way to avoid this project derailer, is to train the key business people in the standard functionality of the selected technology. Once these key people in your project understand the basics of how the technology works, the flow of data through it and where it is strong, they are better able to communicate with your technical team. Then the two groups of people can talk together and then find the low hanging fruit and deliver great results to the organisation.
Some people argue that they do not have the time or the budget for this training, but avoiding it is a false economy, because without it key mistakes are likely to be made which will later need to be unwound. The unwinding will cost more than getting it right first time.
For any business requirement asked of a CRM technology, there will be several ways that it can be resolved, and these different solutions will range from good, or excellent, to poor.
However, only someone who has a broad knowledge of the technology, what it can do and potential problems that may arise later, will be able to find the multiple solutions and then assess them, both from the implementation perspective and the ongoing cost perspective. People lacking the broad knowledge of a technology, tend to fall victim to the 'when all you have is a hammer, every problem looks like a nail' syndrome.
Steering clear of this project issue is achieved by ensuring that all the technology team receive training that not only gives them this broad knowledge but also encourages them to think about several solutions. This is a very different approach to training than training that is primarily aimed at getting people through exams.
As part of the solution selection, a few members of the team should brainstorm possible solutions and then discuss the pros and cons of each solution, both now and later before making their final decision.
Only considering one solution and jumping in and implementing that one solution is a mistake which will make the project budget or the ongoing maintenance of the solution much more expensive, mainly due to rectification of a problem that could have been avoided.
Outsourcing the ownership of the project can happen in either of two ways:
Most people working in this sort of implementation area are aware of the risk of outsourcing the project ownership. However, they only really consider formal outsourcing – overtly handing over the project to a third party. Informal outsourcing is much more insidious, and occurs when the person responsible for the project feels unable to fulfil this role. However, rather than fix the root of the problem, they allow a third party person to take over the control, and pass the communication through them, relegating themselves to barely more than a puppet.
This costly mistake is usually attributed to lack of time. If time is really an issue, this should be resolved by finding additional resources. However, the real issue is often a lack of confidence in their ability to own the project. Providing both training so the project owner has the skills to truly own the project; and the time to fully participate in the training and fulfil the role, will allow the project owner to lead a project that correctly meets the organisation's needs on time and on budget.
After training, testing is the part of the project that most often gets lost – if it was included in the first place.
Some projects try to use 'agile' as an excuse to neither plan the project, nor do thorough testing. This is abuse of the agile technique. Agile, put very simply, is a methodology, where requested features are added to a list, then implemented in chunks, after a review of their business value compared to the implementation cost. Just allowing anyone to request a feature or change and get it implemented there and then, is not agile – it is chaotic - and leads to the idea that agile is fragile. Abused agile is fragile. Robust agile is a great methodology for projects such as CRM implementations or upgrades.
Whether you are using an agile project implementation methodology or a more traditional methodology, testing must be done against the business processes that were the key requirements of the solution. To do this successfully the testers, be they experienced testers or selected users, should be trained in the testing techniques to be used, the functionality of the technology and the processes that have been implemented.
Without this training, it is likely that the testing tests only the more obvious aspects, and fails to get into the nooks and crannies. Or testing is used as an opportunity to add more functionality. Either way, inadequate testing will lead to more issues being found by the users once the solution has gone live. Rectifying issues once the solution is in production is always more risky and expensive than doing the testing that is enabled by the appropriate training.
Most projects do start out with end-user training in the plan. However, if the project runs over time or over budget – which may be because of any of the earlier mistakes – the training is cut.
Sometimes management decide, perhaps aided by a vendor, that the users can 'figure it out for themselves'. This is a massive false economy, but it is commonly seen in these projects
All users deserve the training that gives them the confidence to use the new solution to do their job. When this training disappears from the project, users will do their best, but this rarely delivers a consistent process, and may create unreliable data. If the data is unreliable, one of the key reasons for the implementation may be lost.
There are many sorts of training required during the lifecycle of your CRM project. If your vendor is telling you otherwise, perhaps telling you that their solution is so simple, you probably have some questions to ask of that vendor. This article will give you some ideas to use in those questions.
So, projects of this nature are simple, but they are not easy.
Published by Gill Walker
Gill Walker is many things:
Opsis is an expert Microsoft Dynamics 365 consulting company. Our focus is your Microsoft Dynamics 365 success - not licence sales or billable hours. As Principal Consultant, Gill oversees all business operations and strategic planning and execution, yet she still believes in offering personal attention to each and every client, so as to understand their needs and offer tailored solutions. We are based in Sydney, with clients in Sydney, Canberra, Melbourne, Brisbane and across Australia. We offer Microsoft Dynamics 365 strategy, Microsoft Dynamics 365 scoping, Microsoft Dynamics 365 implementation, Microsoft Dynamics 365 technical support, Microsoft Dynamics 365 advice and guidance, Microsoft Dynamics 365 training and mentoring.