15 Questions Fundraising Managers Should Ask About New CRM Projects

 

Too often, fundraising managers are not close enough to the implementation of a new fundraising database or charity CRM system; sometimes (incorrectly) by the nature of procurement and sometimes (incorrectly) by choice. But for a fundraising system, they are more likely than not going to be the key reason for why it is being implemented, so why wouldn’t they want to get more involved?

So if you are a fundraising manager and there are plans in your organisation for a new fundraising database, then what questions should you ask during the procurement process and before the project kicks-off?

1. How do I know it will meet my requirements? When do you need my input? How will it be documented?
   The most basic of questions. What is the process to capture your requirements and how can you be assured that it will capture all your needs? The latter point may be very difficult but you need to ask. Is all the reliance going to be on you and your team, or is the database/software supplier or a third-party going to be more heavily involved?
2. How will it help my [DM team/Major giving team/etc]?
   Although this goes hand-in-hand with (1) above, there is no harm in asking specifically about how the new system will help your different teams and aspects of fundraising. What are the actual benefits you will get which will have an impact on your fundraising and income?
3. How is the project being managed? What input do you specifically need from me and how often?
   Has the project got a project manager – part-time or dedicated? If not, push for one! And don’t rely on just the supplier being the project manager – that isn’t the same as your organisation having a PM. And will there be a Project Board or steering committee? If so, how will you be involved and when? You need to be involved somehow – at the end of the day, it will be “your” system, so don’t think it will just magically happen without you needing to be involved.
4. What fundraising experience does the software supplier have?
   And not just the supplier as a company, but the staff who will specifically be working on your project. Most “traditional/dedicated” fundraising packages should have staff with plenty of experience, but for the newer, “generic” CRM systems, is that definitely the case? If the answer is “not a lot”, that doesn’t mean you still can’t work with them, but there could well be more dependency on you.
5. Will we need to change our business processes? How will that be decided and when?
   It is highly likely that you will need to at the very least review your business processes. In fact, if the answer to this is “no – you can keep your existing processes”, then this may sound beneficial, but ask yourself, are your existing processes actually the best processes you can have? Why do you have them? Is it because your current fundraising software has forced you into a certain way of working – in which case, why would you necessarily want to carry on with them?
6. How can the software interact with our website? How can we load data from JustGiving/VMG etc?
   This may result in a technical answer so try to get someone to explain (as much as possible) in layman’s terms. At least find out what the options are, the benefits for each option, the different costs, the level of complexity/sophistication and timescales.
7. How will it impact on our other systems and suppliers?
   You are bound to have other software systems which interact with your current database (e.g. PAF software, banking software, Word/Excel etc) and you may well have third-parties who provide you with data files, such as fulfillment houses, data cleaning companies, online websites etc.
8. What training will my team need?
   Ensure you ask this and if in doubt, ask again. Training is often perceived as a double-edged sword by fundraising teams: everyone seems to want it at the start of the project, but when they are later told that they will need 3 days out of the office, this suddenly becomes less attractive/important. Find out, break it down, insist on it, plan for it.
9. What reports/dashboards come as standard with the database software? What skills do we need to create more?
   At the end of the day, if you can’t get the data out of your new system in a meaningful way to show you reports and appropriate information, then why are you using it. Are there any standard reports and dashboards which come with the software, and if so, how flexible and appropriate are they for your needs? And you are bound to want other reports, so who will be creating those? Will you have to rely on the supplier, or can someone in your organisation (your team?) create them?
10. How will testing be done? What input will you require from my team?
    Another thing which everyone knows is essential but somehow gets pushed under the carpet if you are not careful. Find out what the training plan will be and what will be needed from your team and when. How will they be supported. And do you have any “business critical” processes which you will need to be 100% assured of working (e.g. direct debit claims) and if so, how will they be tested and what will the fallback plan be in case they don’t work (even after testing!).
11. What input/time will you need from my team during the implementation and at what stages of the project?
    This should incorporate much of the above (i.e. requirements gathering, testing, training) but it’s very useful to get an overall understanding of the sort of work you and your team will be needed for. Is there going to be any need to back-fill any positions for any part of the project?
12. Do we have a contingency for the budget?
    Sadly, projects do go over-budget, so has this been considered? How was it decided, and how will any contingency be approved during the project?
13. What happens if the project over-runs?
    Again, it is quite feasible that the implementation will take longer than initially envisaged. If this does happen, what will the impact be? Can you carry on using your existing database, and for how long? What are the cost impacts? Will there be any impact on your fundraising or planned activities?
14. How will you keep me updated during the project? How will you keep other stakeholders updated?
    A key thing is to ensure that you – and the other key stakeholders in the project – are continually and regularly kept updated. This doesn’t mean you have to meet every week or receive a 10 page technical report, but you need to know how often you can expect updates, how and what will be in such updates. This does go hand-in-hand with point (3) above on project management, but is one of the most crucial parts of that.
15. What will the supplier’s involvement be after we go-live?
    Once you do go-live with the new system, what will the supplier do. Will they just walk away and let you get on with it? Will they be around for a period of time? What other input and help can they provide over the subsequent months (and years).

And having limited myself to 15 questions, there are in fact many more which now spring to mind. But I hope the above provides a solid base for you to start from.

Anyone else got any more questions which they think are useful for fundraising managers to ask? Or has anyone had any experience of when fundraising managers did/did not get so involved and thus when a project did/did not succeed?

Do fundraisers ever really create queries themselves in fundraising databases?

 

Almost all fundraising/CRM software suppliers promote the fact that a key benefit of their system is that fundraisers and “end users” – i.e. non-database/data-savvy/IT staff – can create their own, especially ad-hoc, queries and reports. And I have always wanted to believe this – and often I do! But is it really the case? Surely it must be possible in 2012 – mustn’t it?

Yes, sometimes
In some organisations I have worked with, it does happen. It tends to be in smaller charities where they don’t have much of a dedicated database/IT team anyway, or where an organisation is fortunate that they have got a fundraiser who “really gets databases” and is comfortable with queries and reports, and who can thus do such work. But sadly, this can be rare.

But it does depend…
Of course, much of this does depend on the complexity of the query required – the question the fundraiser wants to ask – the reason for the question and of course the ease-of-use of the software itself. I know a number of packages where to do comparatively simple queries, many fundraisers are indeed able to use the software’s query/report functionality to do this. And if it is a comparatively simple question such as, say, How many individuals live in London, or how many people have given a donation in the last x months, then that is viable.

Of course, the more pedantic of my readers will – quite rightly! – point out that even that requires some thought; e.g. what if a database stores multiple addresses for individuals, do we really want all individuals, what about deceased/gone aways, and do we mean all donations, what about regular givers/legacies… and so on.

The problem is, it is always about the data
And there-in lies the rub. There are of course many such questions which we should ask about so many of these seemingly simple queries/reports. There is a need to think about this, there is a need to know the data and coding structure on our database, and we do need to consider why we are asking the question at this time. If it is to get rough counts then maybe some of the exclusions matter less (or maybe not…). But if we are producing a report for the Director of Fundraising about income from last year then we need to ensure that we know what we are producing is correct.

And I haven’t even started on the need to add a second variable to a question. E.g. find me everyone who has given a donation last year and who lives in London or Leeds. How many fundraisers and end-users really understand Boolean logic and truly know their ANDs from their ORs. And then of course we have nested brackets…

Some software can help
E.g. simple templates, ‘query-by-form’ (rather than a separate query module), cut-down versions of field lists; and parameters are always useful. i.e. many times a fundraiser wants to ask a similar question on different days but just change the city name, the amount in the donation value field etc. So data people can create a standard query for such a request but include a parameter in the query - so when a fundraiser runs said query, they are prompted to enter the city/donation amount etc on-the-fly without having to 'get under the bonnet' of the query to do so.

But it still comes back to the data…

Hence the central data team
All of the above is why so many organisations still have a central person/data team to create these queries and reports. Because the database/data person does understand these points and therefore, as long as they understand the question the fundraiser is asking (another point altogether…and shows again my point of the need for "bridgers" in our sector) then they should be able to create such queries/reports easily enough. I also know a few organisations who have a ‘data’ person in a fundraising team such as Direct Marketing, so that they can specialise in such requirements. 

Or is your organisation different?
Prove me wrong - please! Leave comments below about how you or the fundraisers/end-users in your charity do create new and even semi-complex queries or reports. I'm sure there's plenty of people who would love to know.

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.