DYNAMICS 365 CRM CONSULTING
Top 8 Reasons Projects Fail
Background
Systems Projects in General and CRM Projects in particular are notorious for their high failure rate. Fortunately, there are a few common reasons why these projects fail and some straightforward ways to mitigate the
associated risks. Read on to learn more about maximizing your chances of success.
Risk #1 – Scope Creep
Modern CRM systems are incredibly flexible and powerful, so the temptation often arises to do ‘extra’ stuff. Add another table or field to track that extra bit of customer data? Sure – no problem! Automate a few more processes or approvals? Why not!?
Implications
- Delays to the schedule – which can delay the expected ROI
- Increased cost – if the scope changes, the cost changes
- Increased risk – more features mean more things that can go wrong
- User adoption can actually suffer – changing too much at once can make it harder for the users to adapt and adopt the new system
While these extra things might be valuable and worthwhile when considered in isolation, adding things that are not strictly necessary has multiple downstream implications:
Example
These days everyone is jumping on the AI bandwagon. With Dynamics 365 that might mean the use of Copilot, which is powerful, actually useful (yes, really!), and some of which is included at no charge in existing licenses. Depending on the nature of your implementation, however, Copilot might best be put off to ‘Phase II’.
Mitigation
DON’T DO IT! Seriously, though, it is important to consider all the implications of changes before adding them into a project mid-stream. There are often changes that make sense because the benefit is big enough (or the change is absolutely necessary – see Unknown Unknowns). If you can manage without it for now, however, consider leaving the change out until all the essential features are implemented and your team is fully up and running.
Risk #2 – Unknown Unknowns
Unknown unknowns are similar to Scope Creep but are caused by gaps in the requirements that no-one knew were even there. As such, they are harder to predict, but you can predict that most projects will have some.
Implications
Sometimes unknown unknowns turn into regular scope creep and can be managed the same way. Other times, the discovery of a new unknown means a critical change is necessary in order for the solution to work in the real world. These kinds of critical changes have to be addressed and cannot be put off to ‘Phase II’ to they will impact the scope, budget and/or timeline.
Example
The classic scenario is when we get to training the end users and they go “well that ain’t gonna work” or “that’s not how we really do it”.
Mitigation
Dominic makes consultation with the End Users a core part of our process. We get ‘Coal Face’ users who actually perform the daily/weekly/monthly tasks involved right from the Discovery stage (or even earlier) so we gather practical information on how the system should work in the real world. You can contribute to this mitigation by making sure a good representative selection of your end users are involved (not just the ones with a technical bent, for example) and by creating an environment around the project where input and criticism are expected and encouraged.
Risk #3 – Adoption, Adoption, Adoption
Techie people often mistakenly equate “the system works” with “the system works for the client”. Getting the technical connections and flows and data validations and so on and so forth all working is just part of the battle. In fact, it is usually not even the most important part. What is critical is that all the appropriate users at your organization are enthusiastically and consistently using the system.
Implications
Why is it so important? Because the value of a good system is inherently linked to the idea that everyone can rely on the information therein being the most accurate information available. Management must be confident they can rely on analyses based on that information, Salespeople rely on the fact that all communications with their clients/prospects is there so they can determine the correct next action, and Service people need to know they have a complete history of the interactions with the customer.
Example
If Sally the Salesperson follows up with a prospect only to find that her colleague Jim the Joker already talked to them (but did not update the system), she looks foolish and wastes her time.
Similarly, if Mary the Manager is tasked with forecasting sales for the next quarter, she needs a complete view of everything in the pipeline, so she does not have to contact all of her reports to check what their opportunities really are.
Mitigation
First and foremost, the company and all senior management (whether they are directly involved in the systems project or not) must be 100% supportive of the new system. If there is any light shining through cracks in the determination of the organization, some end users will take advantage of the opportunity to resist change.
It is also important that the end users feel some ownership of the project themselves. That does not mean they get to design it, but their input should be actively and sincerely sought out and they should be kept in the loop as to how the new solution is shaping up throughout the process.
Surprise is the enemy of adoption.
Risk #4 – Timeline
People and organizations both have limited attention spans. If a project drags on for too long, it will lose momentum, and the team will start to believe (consciously or subconsciously) that it is never really going to happen.
Implications
Things can quickly slip down the priority list to the point where the project slows down to a crawl or even a standstill. If that happens, it can lead to a vicious circle of ever decreasing focus and expectations
Example
Although we recognize that everyone has ‘a day job’ in addition to the tasks they must take on during a new system implementation, we see all too often a tendency to procrastinate or de-prioritize the project in favour of more pressing concerns. The temptation to focus on other things, particularly when the target Go Live date is still months away, can be great.
Timeline is sometimes the flip side of Scope – if your projected timeline is more than six months away, you might be biting off more than you can chew.
Mitigation
Timeline is affected by two of the same factors as Adoption and Scope Creep. If management maintains an enthusiastic focus and non-essential changes are kept aside, the project will have the best chance of completing on time and on budget. Dominic suggests that projects should last no more than 6 months whenever possible.
Risk #5 – Communication
A lack of communication or miscommunication can lead to a variety of issues affecting the success of a project. Communication between the client and the implementer (e.g. Dominic) is obviously essential so that the implementer has a proper understanding of what the client needs and what is most important to their business, their processes and their people. It is also vital that the different stakeholders within an organization are on the same page.
Implications
Our experience has shown that sometimes managers and senior executives are unaware of important details about how the end users actually complete their daily/weekly/monthly tasks. That is not to say that management is not paying attention – far from it – but there are often problems that have been solved by those at the coal face and knowledge of those ‘gotchas’ or workarounds have naturally not percolated up the chain.
Example
If end users currently have a process that includes jotting down a reference number so they can go into a different system and retrieve something using that reference, there may be a key link that is needed in the new system to provide a similar cross-reference (hopefully without post-it notes!).
Mitigation
Regular, open and honest communication. Your organization should have a steering committee or similar group representing all the stakeholders in the new system that meets regularly with the implementation team. Communication is one reason why Dominic uses an Agile Methodology which includes relatively short ‘sprints’ ending with a review with the client to see if the project is on track and make course corrections early to head off later problems.
Risk #6 – Support from IT
Even with Cloud/SaaS solutions, getting buy-in and support from the internal IT department is important. Without IT on board, things can get really jammed up.
Implications
Right from the outset of most systems projects there will be IT tasks to be completed before much progress can be made. Security issues will need to be addressed. Sandboxes will need to be setup and connections will need to be made. Without enthusiastic support from IT (and a consistent message from Management), seemingly small tasks can bring everything to a grinding halt.
Remember – IT is like electricity. Sometimes you forget it is there, but when it stops working, you really miss it!
Example
Some IT Departments are very Security Conscious. That is generally a good thing; however, there does also need to be a willingness to provide appropriate access or configurations to your solution providers so they can properly do their job. If IT does not want to give your consultants a login with administrator level permissions for connecting to something important, which is not at all unreasonable, they DO need to set that connection up for the system to use without sharing the credentials with outsiders.
Mitigation
Often it comes down to communication again. Make sure you know in advance how IT wants to handle any of their tasks in relation to your project (do they want to be in the meetings or would they prefer just a list of requirements sent to them). Also, communicate that the project is important, and it needs their support along with everyone else’s.
Risk #7 – No ‘Super Users’
We strongly recommend that even in a small group, two or three members of your team be identified as ‘Super Users’. This is different from System Administrators, although often they overlap. ‘Super Users’ are the internal champions that will be involved throughout the project giving input, learning all the details, and taking the advanced classes so they really understand how it all works. If you do not identify two or more Super Users right at the start of the project, then essential knowledge can ‘fall through the cracks’ because there is no-one whose clear responsibility it is to gather that wisdom for the future. We recommend at least two so that they can cover for each other and essential skills do not disappear if one leaves your organization.
Implications
When you do have Super Users or have insufficiently knowledgeable Super Users, the rest of your team has nowhere to go internally for help. Your implementation partner should, of course, support all your users, BUT neither you nor your implementers want a free-for-all with everyone phoning/emailing/testing the external Help Desk. Your regular users are also much more likely to feel comfortable and be able to communicate clearly with your own internal Super Users because they really speak your language.
Example
When we rely solely on group training, a lot of detail is not effectively retained. Your end users will need training and that usually means classes or groups, but if there are also Super Users who have been involved throughout the process (in effect, they have had more detailed one-on-one training) then they can provide an important safety net for the other users and for new users.
Mitigation
Identify at least two team members and give them the support necessary for them to commit the time required to be involved with the project right from day one. You may need to backfill capacity to cover their normal daily tasks, so they have the time for participating in the project as Super Users. Ideally, they should be ‘coal face’ people, not supervisors or executives. Tell them explicitly that they have this new role and let all the users know that the Super Users are there to support them.
Risk #8 – Weak Test Planning
Testing is something that everybody pays lip service to, but sometimes we do not follow through like we should. To help ensure that your testing is both thorough and appropriate, a good Test Plan is a must.
Implications
When testing is too much of an afterthought, the system might ‘pass with flying colors’ but when the rubber hits the road you fund that it does not handle some crucial real-world situations. Fixing these problems during or after Go Live is painful and can be expensive. Customer Service, efficiency, and quality may all suffer as a result.
Example
If the testing just covers normal and/or simple scenarios, no-one really knows how it will manage the 10%, 5%, even 2% of situations that are a little out of the ordinary. That small percentage, however, can quickly become a big problem.
When automating order processing, for example, what should the system do when the customer’s order will put them over their credit limit? In the old, manual process, a human can figure out something sensible, call the customer, call finance to approve an override, whatever. For an automated system, that order will likely get rejected. If the system does not manage that edge case quickly and appropriately (perhaps just by notifying a human), you might have an unhappy customer when you did not need to.
Mitigation
So, what is a good Test Plan? It is actually not that hard.
A good Test Plan just requires that representative users at all levels (but particularly the End Users who are doing the day-to-day heavy lifting) create some stories that focus on the problems they encounter during their day/week/month.
If you can get them to literally write short stories about problems they typically encounter, your implementers can turn those into Test Plans that will properly put the new system through its paces. Something like this (for each problem) is all that is needed:
“Jane orders some widgets online but her company is always close to their credit limit so I have to phone her and process a payment before we can release the order”