How do you compare like-for-like on CRM Suppliers’ Professional Services?

 

I’ve recently had several discussions with charities and database suppliers about how difficult it can be to compare different suppliers’ Professional Services during a database procurement. This is partly in terms of comparing the specific services/options they are offering, but of course it is often about being able to compare like-for-like in terms of cost.

The charities have thus been confused or surprised that one supplier can claim to do something so much more cheaply than another; and some of the suppliers have themselves been cheesed off that a competitor has quoted so much less when they really believe that their competitor can't come close to offering the same services as they are doing with such a budget. (Some database suppliers do have a fair idea of what some of their competitors charge for services). Which, sadly, can entice the first supplier to 'minimise' their options too when they know they should be recommending the charity buys more. And thus the charity can't compare all the suppliers' professional services equally.

This is of course one reason as to why some charities use consultants to help them with procurement because consultants do such work more often and can thus help their client compare like-for-like and with the knowledge of how specific suppliers work.


So, for the benefit of all, I've listed here a few tips as to how I approach this potential conundrum and some specific things to look out for.

• Comparing like-for-like is important as much as possible. I understand this is the core of the matter but the important thing is to break down the suppliers' services costs into comparable sections; e.g. Specification, Development, Deployment, Data Migration, Post go-live support, Project Management etc. It is quite likely that different suppliers may have different terms for the same thing (e.g. discovery phase or requirements document; configuration or development) but you need to understand that and thus be able to compare apples with apples. Ask suppliers to detail what they are actually offering in their written proposal and that should help you. But be aware that, say, if one company is offering 2 days training and another 10 days then that isn’t truly like-for-like, and the question therefore is whether one is under-estimating or the other over-estimating, or whether both could be right! See below for more thoughts on that awkward point.

• Ensure you include/consider all possible costs for all suppliers – even if some suppliers haven’t included them in their quotes/proposals. Some such costs will definitely be needed for all suppliers’ proposals (e.g. training, data migration), so if a supplier has not quoted for such an item at all, then ask them why not or make an allowance. That said, some costs may not be critical for all implementations (e.g. additional report writing, even go-live support for smaller projects) so in some instances it may genuinely be that some solutions will require different services.

• Comparing ‘traditional’, dedicated fundraising packages vs ‘generic’ CRM systems. I wrote a whole series of blogs recently about this, but in terms of professional services, for the “average size charity”, it might well be that some of the services required for the CRM systems are not needed at the same detail by fundraising package suppliers – and thus this aspect of the CRM systems will either genuinely be or appear to be more expensive. For example, a fundraising package may have Gift Aid, Prospect Management and income structure all built-in as standard, but some CRM systems may need to be configured or bespoked to manage these needs. (NB: this doesn’t make one better or worse! Again, read my blog posts giving a far more comprehensive comparison).
  
  Likewise, because CRM systems by their definition will need more configuration (but probably will have cheaper license costs), it may be more difficult for CRM suppliers to give accurate (or even ball-park) figures at the time of a proposal. They are more likely to need to do more work with your charity before they can provide such costs, and sometimes that discovery or feasibility work will be chargeable. Nothing (necessarily) wrong with that – but you need to build it into your cost comparison.

• Training: There can be all sorts of different ways of quoting for training, aside from the fact that one supplier may, say, recommend 3 days and another 12 days. For example, on/off-site training; user vs admin/power-users; “generic system training” (e.g. Salesforce admin training) vs system-specific; training all users vs train-the-trainer approach; and so on. Check each quote. And see below about my thoughts on dramatically different recommendations of, say, the number of days required.

• Integration with your website: Integrating with your website to automate data integration with your fundraising database for online donations, event registrations etc can really vary in the functionality being offered, the simplicity, ability, technical approach, comprehensiveness, customisation, automation and, thus, cost. Check out exactly what each supplier is or is not quoting for and how accurate they feel they are being about such pricing.

• Remember other integration; e.g. third-party software, data feeds etc. If one supplier does include integration costs and another does not, then check with the one who has not as to why not. It might be that some such costs are standard functionality and are thus not needed, or it might be a package offering they are providing; or they might have “forgotten” or just not included it.
  
  Integration can be one of the most expensive aspects of any implementation so don’t brush this under the carpet.

• Data Migration. This is one of the hardest costs to compare. It is one of the hardest areas for any supplier to provide a quote on unless they spend some time looking at your data or unless they have a standard cost and just accept that they may spend more time on some project than others in doing this work. Although I would personally be cautious of that approach as I would be wary of what they were really offering and at what level of quality. I personally prefer quotes specifically oriented at my client's requirements.
  
  You can therefore take the estimate the supplier has given you and balance that against the other suppliers, but I would also talk further to any supplier who has quoted significantly less than the others. Why have they done that? What does/doesn’t it include? Do you have simple or complex data? A single or multiple sources? Are they allowing for multiple trial migrations as part of the project and thus charging less/more? And so on.
  
  One simple if crude approach, unless you have solid reasons to think otherwise, is to take the highest quote of all your suppliers and put that against them all. This takes this out of the equation in terms of pure costs.

• Of course, some systems will be different. Some will require less or more configuration, even if both are fundraising packages. Some may require less/more training, and so on. Talk to the suppliers, talk to their customers when you take references, talk to other charities online, at events etc.

• Some suppliers are more/less expensive. Some will have different day rates, some will insist on more project management, some will have pre-configured solutions/templates, some will offer discounts. And so on and so on…

A good rule of thumb is: if one supplier has quoted for a specific service but another has not, then ask yourself - and then probably the second supplier - why this is. There may be a good reason for it - e.g. it may be incorporated in another cost - but if it is needed and they haven't included it in their costs then bear that in mind...

In general, if one company quotes a lot less the other(s)…
… then go back and ask them about it. There’s nothing wrong with telling them that other suppliers (although I wouldn’t personally, necessarily say the names of such suppliers) have quoted for a lot more, so why are they quoting so much less. They might be able to explain why you need less development time, or their in-house knowledge of your current system means that they know they can do something in less days; their software might be much simpler/limited in terms of functionality/customisation etc so they might really not need to do so much work on it (although you then need to remember that when comparing different systems...); or, for example, it might be that they genuinely believe you don’t need so much training.

Or it might be that they had a caveat somewhere else in their proposal which stated they were only offering x days training and that you would need more if you wanted X,Y,Z… You’ll then at least be able to compare better, and you can then decide if that was a genuine oversight by that company or whether it was bit disingenuous.

Do not assume that if company X has said you only need 10 days of their time, and company Y and Z have both said you’ll need 30, then X will ultimately be cheaper or better or right for you. Of course they may be - but it may be that they are offering less, both in terms of work and functionality, or they may be implying you “might” need more but haven’t included that in their “core costs”.

Why it is a Bad Idea to have “Phase 2” of a CRM Implementation (andPhase 3, 4, 5…)

When you implement a new fundraising database or CRM system, you will always have requirements and wishes which you will want to implement after your initial go-live – often, many such wishes!
Traditionally, this has been managed by breaking down a project into “Phases”. Phase 1 is the initial implementation, i.e. the build-up to your “go-live” with the new database, and then you plan to implement Phase 2, Phase 3 and so on.

But I think this is a bad idea and we should look at alternative approaches.

The problem with Phase 2, 3 etc
Why? Because the problem with this is that, so often, Phase 2 and other subsequent phases just don’t happen. Or if they do, then they are either nothing like they were originally envisaged, they don't achieve the benefits that were planned or they are cut right back so much that they are barely recognisable as a "Phase" at all.

And why does that happen? Because during the initial implementation, there is all the drive, adrenalin and organisation about the lead-up to go-live and all the impetus which goes with that - and then (understandably) after that has happened, there is a huge sigh of relief and people just get on with what are/were doing. And what was for that first part of the project, quite possibly, a significant project team with senior management support and understanding, is no longer a recognised unit - but whoever is left is still, somehow expected to get on with Phase 2.

And then there is the minor inconvenience of a budget. Whereas most (well ... some) organisations recognise the need to get the database up and running and therefore allocate an appropriate budget for that project, once that has happened, the concept of allocating yet more, possibly still quite significant money towards a Phase 2 (and maybe Phase 3, 4…) is harder to swallow.

It is also quite feasible that, once you have gone live with your new database, that the things you originally thought were important for Phase 2, are now no longer the priority. But you have designed and planned (and budgeted) for the implementation in that way.

Breaking down a Project is Good
One thing I should clarify is that I am not suggesting that the concept of breaking down a project into smaller bite-sized chunks is a bad idea – it isn’t. It’s a good idea. You can’t and shouldn’t implement everything you want on day one in "Phase 1", for so many reasons (e.g. manageability, cost flow, learning what the software can really do, dependencies, timescales, future changes etc).

And therefore we should be planning to go-live with a defined scope; and other functionality and benefits should of course be left for after that.

The Alternative: On-Going Development
A better idea than Phase 2 etc is to create a “road-map” for “On-going Development”. This means creating a list of all the additional benefits and functions which you already knew about before you started the initial implementation but which were not included in it, and adding to that any requirements which are de-scoped during the initial phase for whatever reason, and any new requirements and wishes which are discovered during that phase.

Thus, you will have a list which you can then prioritise into a road-map and plan to start to develop and implement from now on.

The beauty of this is that you can allocate priorities of desire, benefits, costs, timescales, resource requirements, complexity, risk etc and thus agree which things should be developed first and which should be left til later.

And if another new requirement comes along after a few weeks/months, then you can slot that into the road-map depending on its benefit, urgency, resource requirements etc – and in comparison to all the other things on your list. If it is more important then something else will have to give way. But you won't have to "wait for the end of Phase 2" or stop and then re-start Phase 2 later. (Phase 2a, 2b anyone?) You can also adjust the road-map if, say, your software supplier brings out new features or modules which can replace or complement your planned developments.

Some readers may recognise this as form of Agile Development, and whilst it has similarities, I’m not suggesting that you need to follow an Agile format (i.e. sprints, scrums etc). But the basis of the benefits of this approach and Agile are indeed similar.

The need for Enlightened and Involved Senior Management
Of course, you’ll still need a budget and you will still need x people to do this. And you will be asking for a budget for which you can't necessarily say up-front will bring Specific Benefit A or Function B. So it needs the support of an SMT who are willing to trust whoever is in charge of this (see below). But the good thing is that you will be using your budget and resources in the best, most appropriate and most efficient way for your organisation as it stands at any one moment – rather than keeping to some Phased plan which you came up with ages ago and which you feel bound to keep to because that was someone’s plan.

One way in which you can manage all this is to create a Database Development Team which can meet, say, quarterly and discuss the road-map and determine the priorities for the next quarter/year as appropriate. And if you include in this team the Business and the IT team (i.e. fundraising/finance staff etc and database/IT staff) then everyone will be able to make their point about what is needed, what the benefits are, the time and resources which will be needed and so on.

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.