What I've Written About So Far in 2012: According to Wordle

Just for fun, I plugged all my blog posts I've written so far this year into Wordle, and the above word cloud is what came out.

It's mostly what I would expect although I'm a bit disappointed that words such as 'support', 'costs' and 'processes' are so small - and maybe 'data' and 'people' should be larger. But I'm glad that (apart from my more obvious keywords) that 'suppliers', 'requirements' and 'need' stand out.

Only pay for your new database if objectives are met? How does that sound?!

Cloud CRM Supplier, Workbooks.com, recently announced an innovative approach to implementation pricing: Customers now pay half project fees upfront and if objectives are not met then they do not pay the remainder. And I’m wondering if this is a model which could be brought to CRM and fundraising database implementations in the NFP sector?

Of course there are challenges to this approach, the most obvious being, How do you set the objectives so that they are appropriate and fair to both the vendor and client? And measurable.

Workbooks.com say about this process: “SME CRM projects often fail because businesses struggle to set goals [so] Workbooks helps set objectives.” Which rings true. But set the objectives too "low", which of course the supplier should be able to meet more easily, and the client won’t get any business benefits from the implementation; too “high” objectives and the supplier won’t be able to meet them and thus it won’t work for them (or the client...)

You also have the potential issue of a client not "working hard enough" during the implementation so that objectives are not met and thus they don’t have to pay half the fees. And although that is possible, I think this might be mitigated and “self policed” by the client’s management team wanting to see results from their investment as soon as possible and not expecting there to be delays in benefits because of lack of impetus. And if there is a proven, expected ROI from the implementation (perhaps more likely in commercial CRM implementations than nonprofits) then why would a client want to delay that? This though, is a risk I suspect the supplier might have to accept.

On the other hand, a client also has the risk that a supplier might just focus their efforts on the key deliverables which would mean the objectives would be met and not "care" about other aspects of the project; but, providing those objectives are good for the client and mutually desirable to both parties, then that might be no bad thing as a starting point.

Indeed, the potential benefits of this approach are attractive. In theory, such a process could therefore mean you could get a very good scenario: because the client is of course going to want to get as much benefit as they can out of the implementation, and therefore be keen on pushing the supplier to provide “higher” objectives, but if the supplier keeps this in check so that the targets are achievable (and therefore they will get paid) then the client should also implement something which is not beyond their means. And over-expectations and under-achievements are the bain of many a CRM implementation.

It should also give clients some belief in the supplier's workload and project approach. If a supplier doesn’t match-up to expectations then of course they won’t get that part of the payment. That said, I suspect many clients would rather the supplier did meet their objectives and would rather they didn’t have to chase the supplier to do the work, even if there is a financial benefit to them if the supplier stalls.

I also wonder whether this model takes a step towards the mythical “partnership” which CRM suppliers love to talk about during sales processes, because this model would have to be a partnership for both parties to benefit appropriately.

The key to the success or otherwise of this approach is of course the ability to set the correct, achievable, beneficial and measurable objectives/goals/benefits of the CRM implementation. But that really shouldn’t be beyond the wit of smart and willing people who all ultimately want the same goal.

So, fundraising database suppliers, charity CRM solution providers, what do you think?! Have I missed any critical points? And who’s up for it…?!

Is There Any Need to Develop Bespoke Database Applications anymore?

I was interested to see a recent article on ComputerWorld which detailed how the charity, Freedom from Torture has developed a bespoke case management system because they couldn't find an off-the-shelf system which was suitable for their needs.

Now, I of course have no knowledge of the charity's requirements, so it might well be the case that they did need to develop their own system and it sounds as though they have ended up with a good solution for their needs.

But what is interesting is that, for database applications such as this, the bespoke approach is becoming a rare occurrence these days, primarily because of the flexibility, adaptability and affordability of many "generic" CRM systems which are now available to charities and NFPs.

The rise of the CRM system
I have discussed before on this blog how systems such as Salesforce, Microsoft CRM Dynamics, SugarCRM, civiCRM and others are all great solutions which, although they have their roots in sales and contact management from years ago, have progressed way beyond that now and have been enthusiastically embraced by the nonprofit sector worldwide (and by other vertical sectors too) because they can be adapted to so many requirements which are essentially based around contact management - but of course can provide so much more around that, be it fundraising and income, membership, volunteer management, case management and so on.

This is the case for large NFPs such as Barnardo's and the Alzheimers Society, who are both implementing Salesforce for their 'cause related' database, and there are many, many small charities who are using all these systems for all sorts of applications and requirements. And just recently, I was talking with a senior manager of another large UK charity who are considering using one of the above CRM systems for their entire volunteer management because it will be so much easier to do than write one from scratch - and that will support part of their core work.

There are also many examples of companies who have developed 'templates' for various charity requirements on these CRM systems - and I know of at least two companies (HomelessLink and Vera Solutions) who have developed case management systems based on the Salesforce platform.

The Probable Decline of Bespoke Database Developments...
So whilst I appreciate that bespoke database solutions are not going to disappear overnight, and there may be good reasons and occasions when they could be right to use - and I am sure that there will still be thousands of Microsoft Access implementations in the sector for years to come - I would still almost always at least consider first if a charity could use a generic CRM system as the benefits are so great: speed of implementation, flexibility, third-party apps and tools, reporting, email integration are just a few which immediately spring to mind; plus, importantly, a better chance of future-proofing (and future enhancements) and, of course the bottom line, they can very well be more cost-effective.

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.