How to Ensure Your CRM Project Comes in on Budget

John Eccles, 11 December 2015

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.

Avoid Under-estimation

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.

Manage Scope Creep

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:

Document requirements thoroughly at the start of the project (the Analysis phase) in terms of what the system has to do – but not down to the detailed specifications of every field and layout of every form.
Categorise changes in terms of benefit to users and impact on project

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.

Mitigate Emerging Detail

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:

Get an experienced Business Analyst or Functional Consultant
Ask the question: “Have we covered all the scenarios?”
Ensure there is sufficient time and budget for the crucial Analysis phase. I am sure many scenarios are missed because of time and budget pressure at Analysis.
Be pragmatic about changes from scenarios. Perhaps some scenarios can be covered outside of the system or in a manual way in the system until a future phase.

Close the CRM Understanding Gap

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.