Should you ever invest in a short-term CRM solution?

 

Every now and then I am asked by a charity if I think it is all right if they buy a database as a “short term solution”. And for short-term, they usually mean “cheap”. This is normally asked because, for whatever reason, they (say they) can’t invest at this moment in what they feel would be a long-term database but they have to have something now.

My instinct is nearly always to say No, that’s not a good idea. But I have been thinking recently if I am always right to say that:

Why I say No
I normally say no to short-term solutions for a number of reasons:

• It will still take a fair amount of your time and effort, assuming you are doing at least a semblance of a requirements gathering and procurement process, and just because you intend to spend less or only see it as being needed short-term, that doesn’t mean it will necessarily take less time or require less effor. In fact, if you are going to put in this time, why not do it “properly” and get a "proper", hopefully long term solution.
• It is quite likely it will cost you more in the long run. Not only will you have to repeat the above process at a later date (i.e. the needs analysis and procurement), but you will have to invest initially in a database and then invest again at a later date – with all the associated professional services – and of course have to pay a second time for data migration. That means it is extremely likely that you will pay more in the long term than you would do if you spent the time, effort and money now to get your ideal system now.
• Short-term can be an excuse for doing things cheaply and therefore not comprehensively – or to put it bluntly – badly. I am often told it “doesn’t matter” because it is “only short-term” and “we will do it properly” when we are ready. That just means poor decisions all round: a potentially poor system, a non-thought through process and on-going business processes and quite possibly, a system which won’t support your fundraising needs even in the short-term.
• Short-term solutions frequently become long-term solutions… How many times have you implemented any sort of system or process as a “short term solution” only to find you are still using it months or years later.

It’s worth asking, Why can’t you get the investment for a long-term solution?
If you are having to think short-term because you haven’t got the budget for a long term solution, then it might be worth going back to your business case and trying to show why it is so important that you do get the correct and necessary budget for your particular needs. Do you need to show your SMT/trustees the benefits you will get? I would always encourage this first.

What about the “But there is new technology happening soon…” question
One reason I am sometimes told that an organisation only wants to invest short-term is because there is some great new technology which is just about to be launched in a few months... Maybe so. The thing is, new technology is being launched every day! If we wait and wait for “the next big thing” then we will wait forever. You have to do a well structured procurement process, invest in a system which (as much as possible) will be "future-proofed" and invested in by the supplier for the foreseeable future and take the plunge.

So, is there ever a reason to say Yes to a short-term solution?
I guess there are a few scenarios I can think of where I would consider saying Yes to short-term:

• If you invest a small amount in a product in the first place which you intend to invest more in later. In fact, this is quite common and in some instances perfectly good business sense. If you need to start using the database in one department/team and then build-up the system across other teams in your organisation then why not. If you only have a small budget now but you can get started with this and apply for a larger budget for the next year, then yes, this is an option. You still need to do all that in a ‘proper, structured’ way, so that you know you are buying a system which will be scalable in the future, but if so then that could be fine. This is therefore not the same as just "buying short term" because what you doing is planning long term in a good, structured way but simply investing less initially.
• If you are, say, a small fundraising department who needs a system now, but where the long term strategy of your charity is a broader organisation-wide CRM system. In which case, as long as your charity recognises they will be spending money later on integrating/moving you to a new system, then short-term thinking could be appropriate.
• There are of course a few good, low-cost fundraising and membership databases for charities and it is better to consider those in a well thought-through process than just buy one for the sake of it.

But what if I really have no budget for a new database?
I know, this is always a potential problem, especially for smaller organisations. And the temptation is therefore to just "get something in now" because we have to have something, and to worry about it later. But, if this really is due to severe budget restrictions, then this doesn't mean you still can't go about procuring a new database using a good process. Read my recent blog post, What should you do if you really have zero budget for a new CRM or Fundraising database?

How not to buy a database (or anything else for that matter!)

Whilst I was preparing recently for a training course I am planning, I came across a couple of videos which I thought gave a neat, humorous insight into what you shouldn’t do when buying a new database (or any other aspect of IT) - but without always using IT to prove my point!

Enjoy!

1) What if there were no stop signs and a major corporation was charged with inventing one?
This shows so many things we should consider - How do we define something where we think we know what we want but where we have to tell someone else who doesn't know what we want, what we want... How not to change your mind half way through a project, how not to over-complicate it. Are we re-inventing the wheel?! Oh, and many more...
 

2) Cartman and South Park conduct a website review meeting

It doesn't have to be a website, but this is. But it has the same message for a database. Think before you start!

Anyone else got any other videos along these lines which you would recommend?

What should I do if my database project is failing?

 

There may be times when your database or CRM implementation (or other projects) may be failing. Or apperar to be failing. In one way or another. In which case, other than obey the first rule of Douglas Adams, what should you do?

• The first thing you should do is ask, What do you mean by failing? Based on what? And who says it is failing? Is it really failing, really out of control, or is it, for example, just a bit behind schedule at the moment but in reality should pick-up fine next month? Do consider carefully if you have proper targets/metrics which say it is definitely failing – if so, then the rest of this post might help. If not, then consider and discuss more why someone thinks it is failing – it may be that it is not as bad as you or they think and/or that it is not being considered in quite the right way...

• However, if the project is failing then you need to pause and review it. i.e. which means, probably interviewing all the relevant parties involved with the project, plus reviewing the business case/PID, the project structure, targets, constraints and anything else similarly relevant. And use an “outsider” to do this review, whether it is someone from within your organisation but not involved with your project or an external person/consultant or maybe even a trustee.
  
  This will mean you can understand what is really happening, what has happened which has meant you are where you are now and hopefully why it has happened; and it will start to mean you can work out what you need to do and change to resolve the failure and hopefully turn the project around. Thus, it will show you not just the analysable, financial status of the project but the possibly more subjective but no less important “cultural status” or “people problems” too.

• Depending on what comes out of that review, you will have different options. Is the original business case, the interpretation of which might mean that the project is now failing, no longer viable or up-to-date? Do you need to go through the correct steps of reviewing/adjusting that? And if so, with what implications? Do you need to change a significant aspect of the project: Resource(s) in the project team – either changing them or supplementing them? The scope – maybe scaling it back? The timeline or expected benefits – re-targeting the project?
  
  Or is it a good idea to review how to move the project on in terms of ‘breaking it down’ into different parts – smaller chunks with smaller goals, scope and budget? Or…

• Or, do you need to consider if you really should can the project now? Is it really beyond repair? And if so, is that necessarily a bad thing?! Maybe your revised requirements or the original business case have changed so much that this really makes sense. Or do you just need to stop, either completely and recognise and accept the project is no longer viable, or alternatively, maybe start again with a similar but new project, implementing the lessons learned from the failed one so that you can do it right this time.
  
  But do also consider: if you do stop now then what is the cost - the real cost? There are not just the sunken costs you have already spent + the commitments you have to make; but ideally you should also add in what the additional expected income was to be if you did finish the project or the savings you planned to get. And compare that total cost to the (possibly new) cost if you did continue. And also, is there any "cost" of lost reputation internally or externally if you stop the project now? Is that acceptable or worse than stopping?

• And if you are using a third-party supplier, which is especially likely in a database implementation, don't immediately just blame the supplier! It may be just as likely (more likely?!) that there are issues with any of the above points I have listed or with your own staff or processes. That said, it may of course be that the supplier really is at fault, in which case you do need to consider what you should do. Can the supplier change enough for your needs? Or do you need to change supplier? What can you rescue from the project which can be re-used either with the same or a different supplier? How can all the above listed ideas and issues be discussed and adjusted with the supplier?

I have been brought in to manage a project where I have indeed recommended we stop there and then. But I have also been with projects where it appeared to be failing but where, with a few changes, we did turn it around and it was successful. And that can be as great an achievement as anything else.

What is the definition of a successful project?

It’s very easy to glibly say a database or CRM project (or any IT project come to that) is or is not successful. Is success really just measured using “the obvious”: being on scope, on budget and on time? No – what really measures the success of a project is the value of the project, the benefits you get out of it. That's how to define and assess a successful project.

Because even if a project is under budget then what does that mean, how does that really help if you don’t get any value out of it! If a budget is run on time when if it has taken 2 years to do it but any other similar project would take 4 months, then is that really successful? Did you even define the scope in the first place or have you just got what you thought was right?

Make sure you know why you are doing the project in the first place, what benefits you really expect to get and how you are going to measure them. And if that sounds like it has come from the book of the bleedin’ obvious then I’m delighted that you think that! Because trust me, there are so many projects that aren’t run that way that if you do manage your project with such abilities then you are half way there already to making it a success.

What you shouldn’t do when someone says: We need to replace our Database

 

If you’ve spent any time working in or with databases, fundraising or marketing then I’ll bet you’ve heard someone say at least once (and probably several times…): "You know what, we really need to replace our database system". So the next time this happens, if you are the person who is expected to take action on this, then this is my advice on what you shouldn’t do…

Immediately agree! Okay, you might (secretly) agree, but before you openly do so, do the following: ask Why. And then ask Why again. And again… you get the picture. My point being that it may well be that it is not the database which is causing the problems. It could be your data – maybe it is not recorded consistently, maybe not recorded at all, maybe it isn’t being used, maybe no-one understands it, and maybe a hundred other data issues too. Or it could be your hardware or IT infrastructure: if your database runs r  e  a  l  l  y   s-l-o-w-l-y, then is it the database’s fault or is your hardware out of date or your internet connection overloaded? Or maybe your business processes have not been re-visited for years, maybe your staff have not been trained appropriately (at all…) or maybe you aren’t using the software in its best way. All these issues can be underlying causes of why that someone thinks your current database "isn't working".

Just blame the software. This follows on from the above. If you find you can’t produce the reports you want or the mailings you need, is this definitely because the software can’t do it? Or is it because you aren’t recording the data appropriately or your staff don’t know how to produce the reports/letters? If someone tells you the database can’t do what they need it to do, then is that definitely the case? Of course, it might be – it might be that your operations or requirements have changed so much since you bought the database that the system genuinely is not right for your needs any more, but don’t take that at face value. And if it turns out that the software does have faults, then try talking to the supplier and other users and see if it can be changed, if there are other modules you didn't know about or if there are third-party options you can use.

Just blame the supplier. This follows on from the above… It is very easy to say that the software supplier is no good, they don’t have a roadmap, their support is rubbish and a dozen other criticisms. But is that definitely the case? If they have other customers and they are happy or can use the database, then what is it about your organisation which means this is not so? Why are you different?



Of course, there will certainly be occasions when the person who said, "we need a new database" may well be right! But if you can do all the above first and as a result prove that really is the case, then that will be the first solid step on the way to a new procurement process.

But don’t let bad internal processes, misunderstood perceptions and poor data hide any underlying issues which you would have whatever database you were using. Get your foundations right first. Your database sits on top of that. And that’s what makes a successful system.