12 Key Lessons From My Last CRM Project

On the twelfth day of Christmas, my truelove gave to me... Twelve Key Lessons I Learned From Managing My Last CRM Project

I thought I would finish this set of blog posts with a quick-fire set of some of the most important lessons I learned from the last CRM project I managed. Each point really deserves its own dedicated blog post, but I hope they provide a succinct set of tips in themselves:

• Configuration not Customisation where possible: I have blogged about this before and it remains true. The more you can Configure and use the software's built-in tools and GUI to configure and define your system, the better. Each bit of Customised code will add cost, time, risk, pain and something you should try to avoid unless you can see real benefits, at least during implementation.
• Don't try to re-create your existing database: It is so easy to go down the path of replicating exactly what you do now but just in a new CRM system, when what you should be trying to do is use the functionality and approach and benefits of the new CRM system. If you have bought system X then use it as it was meant to be used. Long-term that will set you up so much better.
• Yes, ask users what they want, but then start with a simple base configuration and go from there: i.e. don't try to do every little single thing which users ask for, don't try to change every form on every screen for n different teams, don't bend and change the software in complicated ways when you are still learning and building it. Instead, get the basic requirements, use the software in as simple way as possible to get a starting point and then show the users that - if there are then things which you really have to change then you can consider them at that point or even post-live.
• Don’t under-estimate the challenge of data integration: Integration is hard, no matter how you do it. Think of all those external data sources you need to import, that other system you want to share data with/update from your new system. It takes time, effort and money. Some suppliers may have starting points for some things such as JustGiving etc and that's good, but you may still need to change things.
• Treat reporting as its own workstream: Reports are always one of the things in a project where you start off with great intentions and then as the project goes on, you can find they slip down the order of priority. I would recommend managing them in a dedicated workstream, with a dedicated member of staff leading on them. Remember: reports are one of the key reasons you have a fundraising/CRM system in the first place!
• Work hard at supplier relationships: At some point in your implementation, it is highly likely that something will go wrong and you will need to discuss something painful with your supplier. The better your relationship with your supplier at that point, the more likely you will be able to come to a mutually satisfactory conclusion. It needs work but it's worth it.
• Consider a Product Owner/Solution Owner: In a large CRM project with a significant timeline and budget, consider including a role of Solution Owner (aka Product Owner). This is a role for someone who understands not only the charity's requirements and strategies but also fundraising/charity requirements more generally, as well as CRM software and technology. The reason for this is because the implementation of sophisticated, flexible (and often expensive) CRM software systems is of course not just about the software but about building/configuring and using it with the people and processes in mind - and understanding the whole approach, design, dependencies and implications of design. The role provides a central point of contact for design understanding and fundamental decision making.
• You will always need more people on your team: As the project progresses, you will no doubt find that you could do with more people working on your project, although it could be that you don't know all the exact roles when you start the project. So think about this up-front, budget for it and bring on some roles as you go through the project. Ideally, have a budget for future roles but have an agreement with your project board that you can define the actual roles later. And backfill if you can - always good to up-skill both the people you bring on to the project and the staff who step-up to do the BAU whilst those other people are on the CRM team.
• Think about the post-live structure of your database support team ahead of time: It could well be that the roles you have in your current database support/CRM team will be different to those which you will need with your new CRM/fundraising system, especially if you are moving from a traditional/proprietary software to a CRM Platform,  Think about this as far ahead as possible and make plans.
• You can mix-and-match your approaches to cost within the project: There is always the question of whether you should go for a Time and Materials (T and M) or a Fixed Cost budget. In fact, you could mix and match even in the same project. For example, some of the development work might be T and M but the data migration could be a fixed cost. Etc.
• Post-Live: Use a Roadmap, not Phases. I will point you to my older blog post on this as the principle still stands. I believe that having a roadmap approach to post-live development is far better and more efficient than the concept of Phase 2, Phase 3 etc.
• The importance of fun in internal comms: When you are engaging all your users, staff and stakeholders with your regular communications (which you have planned, yes?), then think of the one word which many people would describe such comms. Go on, close your eyes now and do it... Okay, got that word? Was it... "Boring"?! Sorry, that is often how it is! So make your internal comms more fun: whether it is with more innovative emails, interactive demos, screens in the staff room, lunchtime meetings with food, competitions with chocolate... It doesn't matter so much what it is, but try to think what would make you read something you didn't want to read and do that.

Not blaming the client: the supplier's responsibility when implementing CRM systems

 

Every now and then on database implementation projects, I'm aware of suppliers who try to pass the buck once too much and maybe try to overly blame the client when the project isn't going well. And I have one fundamental issue with this: the supplier is the expert who will have implemented dozens and maybe hundreds (thousands?) of similar systems - the client will hopefully only do this once every five to ten years. So doesn't the supplier have an additional responsibility?

Now. I do realise that it isn't quite as cut-and-dry as that. I know of charities who have blamed the supplier when things have gone wrong, or accused them of things when I am pretty sure that the supplier would never have advocated such an approach. Or the charity itself should have considered something, requested something, put something in place or, most commonly, committed more and/or more appropriate resources to the project. And yes, it should be a partnership between supplier and client. So I completely accept that the supplier cannot be and should not be responsible for all aspects of the project.

But I do get annoyed when a supplier blames far too much on the client. Or when they do not explain things better to a charity, when a supplier goes off down a route of development which clearly isn't appropriate for a charity, or when the charity is expected to 'sign off' design issues early on in an implementation and when the implications of any decisions are not truly understood by a charity - and yet the supplier should have the experience to really emphasise more to the charity just what they should be doing and what might happen if they don't do that. And if the charity still decides not to follow their advice, then fair enough. But the supplier has to take some responsibility.

The trouble is, as I said above, if a charity is only implementing a fundraising database/CRM systems once every few years, and even if they are employing a database manager or similar who has maybe done a similar implementation once or twice before, they still won't have the experience which the supplier has. So how can they really understand the full implications of any decision unless the supplier makes it really clear to them?

On the other hand...
So if I am saying all this then it is probably only fair if I also address one question which a supplier could quite understandably ask me: if a charity does ignore their advice then what should I do? With the extreme question, should we even walk away from the project?

Clearly one hopes it is a rare thing for a project to reach such a point that a supplier has to consider this. I have had a wee rant above about what I believe suppliers should do, but I also hope that most of the time - with good, reputable suppliers - this just means that if they do see a charity doing things the wrong way then they at least discuss this with the client. If necessary, one might want to pause the project, try to get it back on track, work out how it can be managed better (by both sides?) as it continues, but I would hope that all such considerations are held before anything more drastic is done.

And walk away? There would of course be all sorts of contractual issues, unless one side just accepts the lost income, but it is an interesting ethical question. I'm sure we would all prefer that the supplier - and client - worked hard to turn the project around, but yes, maybe there is a time when it is right to sever ties mid-way through an implementation. But that's tough.

Trying to avoid this in the first place
So what can we do to try to avoid reaching such an impasse? The first thing the charity can do - and possibly the supplier to - is undertake a through procurement and, if appropriate, an immediate design/discovery phase after that with the preferred supplier. This may open up areas which are currently misunderstood, show other areas which need to be hammered down, raise issues of resourcing, budget, responsibilities etc. I know several suppliers who insist on such phases now in CRM projects.

Designated project roles can also help; a project manager on the client's side is of course important and even a Solution Owner role might be another answer; early and comprehensive training of the project team could help; documentation showing deliverables and responsibilities; or documentation full stop can help. If we have good, agreed, well structured documentation showing what has been requested, agreed, designed, planned, deferred and so on, then that in itself can help prevent (some of) the 'but you said...' issues.

Even implementing using agile project management can alleviate some of these issues, although I have equally found that agile can be an excuse that just because a decision was made a few sprints ago, now we have to change it because 'new requirements' have come to light, when in actual fact it was just a poor decision/recommendation in the original sprint...


But I still sometimes have to come back to the supplier's responsibility as well. As I say, they are the CRM experts, they are the ones who know what has gone well and gone badly before - and those that understand this will be the good ones who will succeed in the sector. And we all know how important reputation is in the sector. That alone should be enough to encourage them to uphold this approach.

The Challenge of Secure Communication Records in a Single, Shared database

 

Most database systems can record contact/communication history with your contacts, prospects, donors, benefactors et al. i.e. letters/emails, meetings, phone calls, services used etc. But what if your organisation and security needs mean that only some of your users should only see some such communication records?

Let me give 2 examples:

• If John Smith is a major donor, then you will want your major donor fundraisers to be able to see the communication record of the important meeting you had with John last week; but what if the detail in that meeting was so sensitive that you don't want fundraisers in other teams to be able to see it?
• Or, what if you are using your database for benefactors as well as donors, and what if Jane Smith is both a donor and a benefactor - thus, if you add a communication about Jane which only your charity's "Services' users" should be able to see, maybe a Counselling Session she attended, then how do you stop the fundraisers from seeing the fact she attended that session?

Now, some database systems offer functionality around security so that they can completely hide such communications from specific users. However, if you completely hide all such communications, then what about the following case: a fundraiser opens Jane's record and because he can't see that Jane had 3 communications in the last month with your charity's service users, he thus has an incomplete picture of Jane's interaction with you and might therefore approach Jane with insufficient or inappropriate knowledge.

And if they can't see the total communication history, and you are basing any appeal letters, event invites on recent or total communications made, then such analysis may be skewed.

So, how do we show all database users that some sort of contact/communication was made with a donor/contact, but only show relevant users the details of such communication?

It isn't necessarily as easy as it might first sound. Many systems have "one line" (summary) overviews on a Communication History form showing all communications at a 'top level', and then you drill-down (double-click) into each instance to see the details of a particular communication made. So at the most basic level, you want to stop some users from being able to drill-down into the separate communications where they are of Type X etc. This might be possible in some databases.

But taking this a step further: if you, say, have the communication "subject" or communication "type" on that one-line overview, even those few words might tell the "wrong" users too much about that communication - especially in the example of where donors and benefactors are all held on the same database; in that instance, even a subject such as "Counselling Session" might be considered inappropriate for fundraisers to see.

So, ideally, you want one user to see a view where the subject/type is the full details, but another user should only see that "some form" of communication was made but not the details. That can be trickier than it sounds for database developers.

So I throw this question out to you all: if you use a database where this problem has arisen and has been resolved, then do let me know how in the comments below. Or if you are a database supplier who has got around this problem, tell us how in the comments below. Or if you have ideas/thoughts on any of this, or further examples of similar issues, again, add them below. I'd love to hear more.

Should We Be Buying Fundraising Software Anymore?

The case for not using fundraising software per se...
It is highly likely that on your fundraising database, you will have donors or prospects who also have at least one other "type" of connection with your organisation. e.g. they may have bought products of some sort from you, they could be a ticket buyer, they might be a benefactor, a trustee, a volunteer, a subscriber/user of your website and so on. In which case, you may also hold their details on another database as well.

So if that's the case, then should we really be buying fundraising software anymore or should we be buying an organisation-wide system which can manage all this information?

Because the problems with having "isolated" fundraising databases include the following:

• They only store fundraising-related information about your donors/prospects and so you don't know about their wider engagement with your charity. In which case you don't have the full picture which means you might not be getting the most out of them - or helping them as best they want to be helped - or you might be communicating with them inappropriately.
• You might be writing to or contacting them at the same time as someone else in your organisation is also doing so - you can't manage an organisation-wide communication strategy or central contact management if you don’t know and can't control what other teams in your charity are doing.
• Having isolated systems (fundraising and other) engenders the "But it's my data…" paradox and problem. (Why a "paradox"? Read my previous blog post on what to say when someone says "It's my data"...)
• It is harder to do organisation-wide data analysis and marketing.
• And if you do want to "integrate" systems - make different systems "talk to each other" - then sadly that really isn't as easy or as cheap as you might hope or be lead to believe. Even integrating two databases is tough, let alone multiple systems.

On the other hand...
But if it is that simple, that obvious, then why is there still such a market for fundraising software and why don't all charities start to use a single, centralised database. Unfortunately, it isn't that simple.

• Specialist functionality: Fundraising needs specialist functionality in their database, from income processing, Gift Aid and managing direct debits, through to relationship management and prospect research. And other areas of your charity will need specialist functionality in their databases too: trading, websites, management of your services/service delivery and so on. And one, central, large database system may not be able to manage all that - or if it can, then can it do so with the same high levels of functionality that 'best of breed' systems can do?
• Data/database/organisation/change management. Having one, large database makes data management and change management a lot more difficult, involved and time-consuming. If you only have fundraisers to think about then any change or new data item only needs to be considered for them. But if you have more teams and users, then it will be far more work when considering and then implementing any such changes. Similarly: where would the database management reside for a charity-wide system? It probably isn't appropriate for fundraising to manage such a broad database and, often, IT aren't really the best people to do this sort of thing. You could have a dedicated "CRM" department but that's probably only cost-effective and practical in larger charities.
• Budgets/Organisation policies. Many charities have budgets specifically for each particular department so if you want to buy an organisation-wide system then that needs to be addressed.
• It's hard work! Organisation-wide systems take a lot of work, time, effort, resources, discussion, buy-in and money. And often present a riskier proposition.
• They aren't always appropriate. For some charities, it might be appropriate to completely separate the departments and functions and thus the databases. I think this is getting less common but it could be the case. Of course, even if it is right for one organisation, that doesn't necessarily make it right for another. Organisation size can play a part - smaller charities might actually find it easier to create a single, central database than larger NFPs.

But still - will we buying Fundraising Software? Should we...?
Having said all that, none of the above are necessarily reasons not to consider an organisation-wide database, they just need to be understood and planned for. And if it is the right route for your organisation and you can plan for and implement it successfully then it could well offer you significant benefits.

It's also true that some of the 'traditional' fundraising database suppliers are getting smarter and are offering systems which can manage more (much more in some cases) than just fundraising functionality. That may well be an option for some charities.

But in the meantime, whilst we are still working around some of the issues listed above, we will still be buying fundraising software at least for now.

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?

A CRM Database Doesn’t Mean You Can Now Do CRM

This is a brief, simple message: just because you have a CRM database does not mean you can automatically "do CRM". CRM (Customer Relationship Management) is not about software – CRM is a policy and a practise and a whole culture – not (just) a database. In fact, it is possibly one of the most abused terms in the IT industry and has been used to describe so much software that a few years ago had a completely different moniker.

That said, the good news is that if you are a NFP organisation then it is highly likely that you already practise good CRM – if you look after your clients, manage your donors, communicate well with your supporters then you are more than half way there. I believe that, in some ways, charities have been ahead of the commercial sector for years in terms of “CRM”, as charities have always known how important it is to look after their supporters and stakeholders.

So, yes, a good database will of course help your CRM strategy. It should do loads of things for you: keep contact information up-to-date, enable you to understand your supporters better, help you communicate with them better, in a more targeted and efficient way, record their correspondence with you, record all their activity with you, mean you can interact with them online and offline and store centrally all such interactions, allow you to allow them to tell you what they want to hear from you…

But don’t let any software vendor tell you that if you buy their database then you will immediately, magically be able to “do better CRM”. It is your organisation and their approach which defines that. The database will help but CRM database software will not automatically implement CRM at your organisation.

Top 10 Benefits of Project Management

I have been fortunate to have been a project manager at several leading charities over the last few years, mostly on database and CRM implementations, but also on other IT and finance projects. Here is my list of the key benefits I believe a good project manager should bring to any similar project:

• The project team and staff will know what is going on and what is expected of them. This is possibly the most important aspect of any PM’s role – without this, there is a high potential for lack of leadership and the project failing.
• The bottom line: a project manager must monitor, maintain and know the overall and current state of the project budget, timescale, resources required and deliverables and produce the associated reporting to the project board. This is clearly a key aspect for any PM.
• Maintaining an up-to-date project plan, including milestones. (NB: It is usually not sufficient to solely use a project plan provided by a software supplier as inevitably that does not incorporate all the internal needs and issues which the client has).
• Keep the project board up-to-date with monthly meetings and (usually) more regular highlight reports. A good PM can also work with the project board when it comes to discussing and making decisions on the project when it is not going as well as it should be.
• Co-ordination and centralisation. With a large project, it is imperative that everything is fed through a central resource and everyone knows how to do this.
• Monitoring resource allocation: Whilst the PM is not responsible for the actual resource allocation, it is important that they monitor how resources are being allocated and ensure that necessary resources have been planned for.
• Communication: not just with the project board and the immediate project team, but with the users and potentially a wider audience to keep all interested stakeholders up-to-date.
• Task dependencies: A key aspect of a project is that many tasks are dependent on other earlier tasks or must be started/completed before other tasks can happen. Again, this is something which needs to be monitored and understood.
• Risk assessment and issues management. This is a critical requirement and incorporates maintaining a risk register and issues log; and if it doesn’t go quite as far as being a ‘trouble-shooter’ then it certainly involves identifying and understanding the risks when trouble might appear.
• Prevent (un-authorised) scope creep.
• Supplier liaison/management and co-ordination

Okay, if you counted, then you will see there are 11 benefits – sorry, I just had to sneak them all in!

16 Ways to Improve User Buy-in

Many database implementations are planned and considered with some input from the end-users, but if the project is a long implementation or there are many end-users who thus may not be involved day-to-day, then there is a risk that such individuals may become disillusioned or disenfranchised from the project.

Here’s a few bullet points (in no particular order) to help encourage user buy-in to a project:

• Continual communication: probably the simplest and quickest but unfortunately the most under-utilised. It doesn’t need to be much, e.g. a regular email to the end-users and/or through their managers, updates on your intranet, brief presentation at team meetings etc, they all help. And you can get feedback from the users too. In addition, many of the points below by their very inference are continual communication, but having a structured approach can really help.

• Involvement at design stage: Do involve key users at the time you are designing the database, whether it is the customisation of a package or the detailed design of a bespoke system. This may sound obvious (even necessary! I hope so) but it works. And do plan ahead for any such involvement; I find users really enjoy and want to get involved but not if you ask them to do 2 four hour workshops next week when they are just about to launch a new campaign!

• Demos of the software & opportunities for hands-on experiences during the implementation: Show the software to the users – it’s a great way to get them excited about the new database and even if you do an initial demo at an early stage, then you can ask for their feedback and comments and make them feel even more involved.

• Assurance of training: It’s always one of the top 3 questions from users – What sort of training will we have? So give them details as soon as you know, and even before that, pre-empt the questions by assuring users that training will be provided.

• Ask for ideas – during implementation and after go-live: Continue to ask the users what they would really like, although you’ll need to this in a ‘controlled environment’. If you let them ask for anything and expect everything then that can be worse than not asking at all, so do communicate that ideas will be considered but may not all be implemented.

• Keeping promises, so don’t over-promise! Hand-in-hand with the above, and in general, keep your promises but don’t over-promise. A slightly trite phrase is ‘Under promise and over deliver’ and even if I don’t like that specific thought process, the underlying concept is reasonable.

• Remember, What are the benefits to them? When you’re selling a new database to the users, what are the benefits that they are going to get themselves? It should of course be the case that the organisation will benefit from a new database, and although that should ultimately mean the users will too, it can also mean that processes may change, more data entry may be needed etc. So, identify specific benefits which the users will get and communicate those. That will help them understand the need for any changes which they don’t like so much.

• Pro-actively address the common objection of “I don’t know what I want from the database because I don’t know what a database can do” – because it’s (usually) a fair point. Don’t just ask, ‘What do you want the database to do?’ because many users quite simply will not know the capabilities of a database. If they have not had experience of a really good system then they may not be aware of all the benefits they can get from one. Instead, ask ‘What do you do in your job?’, ‘What are the problems you have?’, ‘What would make your life easier?’ and so on. Classic business analysis.

• Stories of how other charities have benefited from it: Find out how other charities have benefited from the same database as you are implementing and tell your users.

• Quick wins: It’s a slightly hackneyed expression, but can be very useful. If there are Quick Wins which you can implement when you do go-live then try to do those. It will show how the new database can help and keep up enthusiasm.

• Listen! And acknowledge.

• Automation: In pure technical terms, automating a process is one of the best benefits many users can have. For example, instead of having to enter a donation, then open Word, cut-and-paste an address, write the letter, insert the donation amount etc - automate it. Yes that is basic but even basic automation helps. And if you can automate even more complicated tasks then that’s even better.

• Excite the users by implementing one or two really ‘whizzy’ things! E.g. Maps with donor details plotted on them, analytical graphs they haven’t seen before, automation and interaction with the web. It’s going to vary between organisations as to just what is considered whizzy, but by doing just a few high-tech things early on after go-live, it does get people excited.

• Involvement at Testing. Again, I would hope this is a given, but do involve your users at the time of testing. It isn’t the most exciting of tasks but it encourages adoption and involvement.

• Competitions: I have known charities who have run competitions during their implementations. For example, every week/month during the implementation phase, they send out an email with a question which relates to the project and to which the users will know the answer if they have got involved, if they check the intranet for updates etc. The charity then does a random draw and the winner gets a prize. A very small prize to start with but as they progress through the project, so the questions get more involved (e.g. when training users, ask specific questions about functionality) and one charity even finished their competition by giving the lucky winner an extra day’s leave.

• Be realistic about implementing new changes. Having said all the above, be aware that implementing a new database is a time-consuming experience. Don’t expect to implement lots of new things on day one of go-live. Make sure you get the basics right and plan any key changes carefully. Users will thank you for that.

Anyone else got any suggestions?

How England Could Have Won The World Cup If Only They Had Used a Fundraising Database

Forget about goal-line technology or dodgy refereeing. Don't worry about lacklustre performances or inept defending. (Actually, do worry about inept defending - that was indefensible). And who cares about whether Lampard can play with Gerrard, or whether Rooney plays better with Heskey?

Well, actually, maybe we should care about that last point. Because that does matter - and England could have understood that, and really could have won the World Cup, if only they had used a database, preferably a fundraising database. Honestly. Don’t believe me? Then read on...

The thing is, fundraising, like football, is a contact sport. It is all about relationships and communication, action and analysis, pitches, targets, goals... I could go on. And yes, they are both about the money. But it is also about research and tactics. England just needed to understand how they should be playing each match based on their previous games. And the best way to understand that? Data analysis. More accurately, data analysis on a relationship management database.

Because a fundraising database could hold all the information which don Fabio could ever have wished to have known. All the players would be Contacts (date of birth, club, number of games etc), their past matches would be Communication History, and any half-decent database (Brian) would be able to record plenty of additional match info on that history, like the opponent, quality, performance, passes made etc. Heck, it could even record strikers' goals on the Donation records, and by doing that use all those lovely reports showing performance and goal analysis... I would say that the database could even record how much each player earns, although I realise we might need to extend the field lengths for that.

But the coup-de-grâce is of course that the fundraising database could hold all the relationships between the players. Who plays with who, who was playing with who, what position, how long and so on. And then, of course, with a quick Crystal Report here and a nifty pivot table there, one could compare all that data with the Communication History and Goals, analyse it against the opposition, and do predictive analysis to see how England should play against the USA, Germany or the mighty Slovenia. And then we would know that Lampard can play with Gerrard, as long as Gerrard plays in the hole, and David James plays well in goal when he has Terry and Rio in front of him, and only a fool would take off Defoe and bring on Heskey with 15 minutes to go when we need to score 3 goals. And, thus, understand exactly from history what we should do in the future.

Football: it’s a simple game.

If you have read this far (well done!) and are hoping for a serious point, well okay, here you go. My point here is that as users of fundraising databases, we should sometimes stretch our minds and think outside the box to consider if we could actually use the systems for just a bit more than we are doing right now. (Although, Frank, if you are reading this, next time you are outside the box, please think about 6 inches lower). Why should we just have to record basic donor information and their gifts, who they know and what events they quite like attending. What else could we record? (And yes, yes, I know there is that pesky little thing called the data protection act, but that aside...) How else could we be using our databases to really push the boundaries and truly help the fundraisers and decision makers see data differently and give us an advantage over other, competitive campaigns.

Anyone got any thoughts or ideas? Not on fundraising, of course, but on how we could use the fundraising database to help ensure England win the next World Cup? Anyone? Please?

How to Manage Software Presentations During a Procurement Process: Part 2

This is the second part of my blog about how to manage the presentation process within a procurement process. In my previous post, I detailed how I suggest using pre-demo meetings before such demonstrations, so in this blog I explain how I would manage the presentation itself and provide a list of questions you could consider asking the suppliers at the demos.

For the presentation itself, if possible, ask each supplier to structure their presentation in the same way. For example, an initial few minutes on the supplier, then a demo of the software, and then Q&A. And within the demo, it can be useful to ask each supplier to show how they would approach a set of the same requirements. Thus, if there are, say, half a dozen specific issues which you want to cover and ensure the software supplier can manage for you, then ask to see how they would approach them. This way, you can see clear differences (or similarities) as to how each supplier works and you might well learn some interesting and different thoughts and approaches along the way.

Of course, you need to allow for some flexibility. Some suppliers might suggest they initially give you an overall picture of the software before showing you individual elements which you have asked for, and that is probably fair. After all, you aren't trying to trick them, you are trying to ensure the software is right for you, and if that is the way that the supplier thinks is best then let them do it. And if they then veer off-track and simply don't follow you requests, then you can consider whether that is a black mark against them for the whole process.

When it comes to questions you could ask the suppliers, then of course you will need to cover at least the functionality and/or services you are looking for. But there are many more questions you could ask which could help you and give you an insight into the supplier, their solution and their whole approach. The following are some of my favourites which I have built-up over the years:

• What doesn’t your quote include? [This is an interesting and useful question as it should re-enforce for you and the supplier exactly what is involved]
• What does your Support Contract/Cost include? [e.g. Does it include: unlimited phone calls to their help-line? All new versions/upgrades?]
• Do you offer a guaranteed response time when I ring up for support?
• How do you record/manage bug reports / Do you have a structured process for when things go wrong?
• How do you provide fixes?
• How often do you release new versions/upgrades, and how are they distributed?
• How do you manage Quality Assurance (QA)? What are your internal testing processes?
• Do you provide remote support? Is this charged for?
• Do you have a user group?
• Can I speak to/visit some reference sites?
• And more general questions about the company such as its size, age, goals etc.

Some specific questions you could ask are:
• Can I speak to one of your clients who used to be unhappy but who you managed to 'turn around' and make them happy? [When I was a salesman years ago, this was one of the most insightful questions I was ever asked; any supplier can give you at least some references who are happy with them, and no-one is going to give you references who hate them! So something like this sort of question is fair to the supplier, lets the supplier show you what they are made of but still gives you good client feedback]
• What could you improve in your software? (What are your weaknesses?)
• Who do you consider are your major competitors?
• What is the main thing that sets you apart from your competitors?
• Can we meet other people in your company? Can we visit your offices?
• What are your future plans?
• How do you keep up-to-date with new technology?

It can be a difficult skill, but it is often what a salesperson doesn't say which is just as revealing as what they do say (e.g. especially if you ask what the weaknesses are in their product!). Listen out for when they avoid answering any particular question, ask it again if you feel it is valid to do so, but either way, note what happened and you can consider later if there is anything you thus need to be concerned about.

Communication is at the Heart of all Good Relationships

Does your charity have a communication strategy? Do you ensure that one person will not receive two (or more) letters from your organisation on the same day (and maybe even from different departments)? Do you respond in the way your donors/contacts want you to? Do you let supporters opt-in to just the information they want to receive?

If not, then it's probably time you did.

Whether you run multiple database systems (and by that I mean databases, spreadsheets, email lists and all the rest) or you have a single, centralised database, either way this applies to you. If you have multiple systems then you must ensure that individual staff members cannot simply decide off their own back that they are going to do a mail-shot from their system, and if you have a single database, then although you will be able to enforce some control, you could have just as many problems with individual users demanding to use the data for their marketing and communications.

If you don't control this then your supporters and donors will get annoyed and that isn't going to help you at all.

Do consider if you can offer your contacts the opportunity to opt-in to just what they want to receive and hear about. E.g. specific events/types of event, fundraising requests, volunteering opportunities, generic newsletters, emergency appeals and so on. And how - email, letter, telephone. It can be quite a scary thought that you will no longer be able to contact everyone about everything but it will work better for you. You will be targeting your supporters better and more appropriately, you will lower your costs, you should get better response rates, you should get happier supporters and you will be working more efficiently.

Communication is at the heart of all good relationships – including yours and your supporters.