Your CRM project doesn’t have to be like this! Magnetism has done many CRM projects that were on-time and on budget. But you will need to be intentional because in general, CRM projects are like most projects and most projects go over budget.
In July 1997, the proposed new Scottish Parliament building in Edinburgh was estimated to cost up to £40 million. By June 1999, the budget for the building was £109 million. In April 2000, legislators imposed a £195 million “cap on costs.” By November 2001, they demanded an estimate of “final cost,” which was set at £241 million. That estimated final cost rose twice in 2002, ending the year at £294.6 million. It rose three more times in 2003, reaching £375.8 million by June. The building was finally completed in 2004 at an ultimate cost of roughly £431 million.
Thinking Fast and Slow, Kahneman, P250
Let’s look at the main reasons why costs blow out and what can be done to prevent this happening.
Under-estimation is deliberate or non-deliberate. You need to find a CRM partner you can trust – one who doesn’t price low to win the job. But it’s not always easy to know for sure that under-estimation is deliberate because non-deliberate under-estimation is very common.
Non-deliberate under-estimation may be due to a simple error or lack of experience or, more likely, due to what Daniel Kahneman refers to as “The Planning Fallacy”. [Chapter 13, Thinking Fast and Slow.] This is an overly optimistic forecast based on best-case scenarios. The solution advocated by Kahneman is for planners and decision-makers to look at similar, historical projects as a starting point for estimation. It’s a great reality check: how much have similar-sized projects cost? You can ask your CRM partner about similar-sized projects. You can ask your IT department. You can ask contacts from other organisations.
Scope creep is the uncontrolled changes or continuous growth in a project's scope which occurs when the scope of a project is not properly defined, documented, or controlled.
It is not at all rare. This is the norm. In fact, I think it is virtually inevitable and, to some extent, should be allowed for.
As your system takes shape and your stakeholders see it, they will start to see ways that it can be changed or improved. No matter how well the project is scoped, it seems we are all smarter at the end of the project than at its beginning.
I recommend a pragmatic approach to scope-changes:
Changes that have low user benefit can safely be left to a phase 2 or enhancements project. The system will work OK without them so let’s not risk increasing project costs or delaying Go-live.
Changes with low project impact and high user value should be implemented. That’s what the change management process is there for. That’s why you should have a contingency budget.
In general, changes with high user benefit and high project disruption should be deferred for a future project. The project should provide sufficient value without the new functionality and trying to include the change will blow your budget and delay Go-live. If, however, something critical has been missed from the requirements, it’s time to re-budget and re-schedule.
Often increased cost is introduced by more complexity as the requirements are unpacked. This could be considered a form of scope creep, but it’s different in that no new requirements are added. It is a common problem.
Of course, if the functional requirements were fully understood and documented, then this problem would be eliminated. But in practice, this rarely happens.
A good Business Analyst or Functional Consultant will discover the business processes, the fundamental requirements and most of the use-cases or scenarios. But maybe not ALL the scenarios. Unfortunately, adding just one more scenario may increase the complexity (hence time, hence cost) more than you might think. In the extreme case, it may mean that the designed solution won’t work and the design needs to be re-worked.
There are steps to mitigate this problem:
For your CRM project to run smoothly, your project team and that of your CRM partner needs to be on the same page. Good communication is critical and in particular, good communication about the intended CRM system is critical. So how well do you know CRM?
Particularly if CRM is new to you or you are moving from a basic, low-powered system to an enterprise-level system, you and your project team cannot be expected to know what the new CRM system is capable of. Your team is likely to interpret the
CRM-speak from your CRM partners through the lens of what they already know and think they understand when they don’t.
I have found that when the key people on a Client’s project team are trained in CRM in the early stages of the project, the project tends to run more smoothly and there are fewer changes. Training is a great way to develop a common understanding of CRM. The Client’s team see how CRM works and can more easily visualise how it can work for them. That clarity means that potential problems are identified and resolved early.