Wednesday, April 11, 2012

15 Questions Fundraising Managers Should Ask About New CRM Projects

Fundraising 
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?

No comments: