Learning From How a Toyota Supplier Saved $1 million by Updating Its Tech Infrastructure

 

My second post in an on-going series of blogs on lessons we can learn from commercial sector technology implementations.

---

A recent article on TechRepublic shows how Toyota supplier, AW North Carolina (AWNC) spent $1.2m on new Cisco equipment, which has led to significant savings for them. Few charities will invest that amount in a new CRM system, but some of the approach which AWNC took provides us with very useful ideas for the benefits which charities may get from new CRM implementations, often regardless of size.


1) "Downtime at AWNC costs $272,000 an hour, so it's crucial to get systems up and running as quickly as possible. Any downtime, particularly in shipping, is incredibly detrimental."

Okay, so it's unlikely that a CRM system being down for an hour at a charity would have quite such high costs! However, downtime due to a poor or unsupported system or inadequate IT infrastructure is not always factored in to a charity's view on whether they need a new CRM/fundraising system.

So consider: what would it mean to your staff if they couldn't access their database for an hour? Probably, it wouldn't be terrible for most fundraisers/staff, they could cope for that time, although Supporter Services would no doubt find it awkward for managing in-coming phone calls. But what about half a day? Now staff will be getting more anxious, a backlog of income processing might build up, supporter services are finding it more difficult and major donor fundraisers can't see their contacts' details. What about a full day? Much harder now: thank you letters might be delayed, management for a forthcoming event becomes much harder, and what would happen if that day happened to be the day when you were due to do your Direct Debit claim?

So it's not just the cost of a new CRM system - all this needs to be considered when looking at investment.

2) "As a result of the new technology, AWNC avoided maintenance costs on the old equipment of $1 million in the first nine months the system was in place"

Again, unlikely for most charities that they will save $1m in nine months due to replacing a CRM/fundraising system, but I have come across several NFPs who are paying existing suppliers ridiculously high annual maintenance costs for what they are getting, even without upgrades and developments. And/or they have to have specialist, higher paid staff for their current, old system because there are so few people who can support it. So even if it is going to cost you £x to invest in a new CRM system, what are your savings going to be in the first 12 months? (In the next 5 years?) Forget "possible extra income" benefits for a moment, these figures are hard cost savings.

3) "About 40% of the savings will be ongoing and realized annually."

We forget this sometimes, that savings (and benefits of course) will not just be the first year, but over the following five to seven years. So in addition to point (2) above on immediate savings, what other costs will be lowered or made more efficient by a new system? Lower staff costs? Or maybe, the same staff costs but those staff being far more efficient, productive and proactive? Time-savings from quicker processes? Time-savings (and better productivity) from simpler, quicker development tools? Development you can do in-house now rather than having to always go to an expensive software supplier?

4) "It was very clear... that the infrastructure was not keeping current with where the world had gone."

We're all aware that digital is where fundraising is going. Yes, there will still be plenty of 'traditional' or offline income coming in for some years to come, but that appears to be declining, and GDPR/DP issues could be forcing our hand in terms of reducing direct marketing. There is a point when you do need to review how and whether your existing CRM/fundraising system can support you and provide additional benefits with your future fundraising plans because of changes in the outside world.

5) "It's common in a manufacturing plant to avoid buying new equipment in a misguided attempt to save money, with IT teams not realizing that the operational costs to troubleshoot problems and the associated downtime in a factory environment can result in even higher costs."

I love this! How many of you have suffered from this problem with your antiquated or unsupported fundraising databases?! (And it's kind of reassuring that commercial organisations have this problem too!)

6) "The big push for last year was solidifying the environment, and this year is all about pushing out into the applications and into the manufacturing space to impact yield inventory."

This is just a small point to show that any new CRM implementation does not have to be rolled out to everyone or to manage all potential benefits immediately. Plan for future expansions in the subsequent years after your immediate go-live - you don't need to, and shouldn't try to do everything on day one.

What Small Charities Need to Know about CRM Systems: Free ebook

I have just published a new, free ebook:  What Small Charities Need to Know about CRM Systems. Buying a new CRM system or fundraising database can be a daunting experience for any NFP organisation, let alone a small charity. And although I publish a lot of information on this blog which I hope is useful for all charities, there are some points which I think smaller organisations need to particularly be aware of or specifically consider. So I have brought these issues together into a new, free ebook.

Which in some ways was quite difficult! Because when I read back over my blog posts, so many more of them are equally appropriate for small charities too! I have therefore limited myself to just twelve areas which I believe should give a small charity a solid understanding of what they need to know about CRM systems and fundraising databases. But if you want to know more, then there's lots more on all my other blog posts.

Who this Book is Intended For
The book has been produced for people whose day job is not the procurement or implementation of new databases - which for small charities is probably almost everyone! And you do not have to be technical to understand it. It is for fundraising managers, chief executives, trustees, fundraisers, office managers, volunteers and those working in supporter services, but of course I hope it is equally useful for database staff and charity IT staff too.

If there are any points you think I should have included in this book then feel free to add them in the comments below.

How to Download the Book
You can download the book from my website: http://www.itforcharities.co.uk/free-ebooks/.

Integration: One of the NFP Sector's Top Technology Trends for the Next Few Years

 

The Access Group recently published their top 5 tech trends for charities with one of them being Integration. This is something which I completely agree with. Not integration as in integrating a database with Word/Excel or with PAF software etc, but integration of systems and data flows. For example: integrating your fundraising database and your website; integrating data files to/from your fulfilment house(s); integrating third-party giving websites with your database; integrating your database and your finance system. And so on.

Why? Because these are some of the best uses of technology in order to get some huge benefits. Automation, time-saving, efficiencies, better use of staff time, data accuracy, data up-to-dateness, quicker decision making, better and quicker reporting, better and quicker analysis, smoother changes for new systems, even improving your competitive edge; and so on. There are just so many things which data/system integration of this ilk can help.

Unfortunately to achieve this is not always so easy. Even with today's more contemporary, open systems. Most charities do not have the resources of commercial organisations who can throw money and teams at such problems, buying in such skills if necessary. And not just for the initial implementation of such integrations, but the on-going maintenance and future changes too. Most charities will of course have limited budgets and resources and unfortunately the time and effort needed to implement integration in any better way than "importing a csv file" often restricts them from doing so. Hence, the "importing a csv file" route is still so common.

But hope is on the increasingly nearer horizon. Systems are standardising, APIs are more available and third-party integration tools are more accessible and far more flexible and smarter than in years past. Even native data loaders in the latest fundraising/CRM systems are better than they used to be if you do have to go down that route.

And I think charities and NFPs are starting to really understand the benefits of such integration, and therefore they are committing budget and resources to such tasks. And that's fantastic. I really hope that over the next few years we are increasingly going to see huge steps in improving integration at NFPs. Assuming so, that is going to bring some wonderful benefits.

What is the best CRM Database for a Small distributed charity or a solo fundraiser?

 

A couple of questions I am regularly asked are: "I am looking for a CRM/fundraising package for a small charity with no central office. So, no server and we probably need something to work across Windows and Mac." And it must be simple to use... Similarly, "What is the best database for a solo fundraiser?" So, I thought I should try to answer these questions here. I will address the 'small distributed charity' first as much of that applies to solo fundraisers too, and then add a shorter, second post with additional details on databases for solo fundraisers.

First: Get your main IT infrastructure sorted out
This is important. Especially if you don't have a central office, and the route you take may partially influence your decisions on which is the best fundraising/CRM system for you. So, first of all, if you haven't done so already, make sure your email system, file access, website etc are all part of a solid strategic approach.

Second: Remember, it's still important to know your fundamental database requirements
This is the same for any database procurement and just because you are a smaller organisation doesn't mean you should completely ignore it. So do document what you want the system to do, even if it's just in a brief Word document. That will help you focus on what is most important to you and you can then weigh-up the system options later. And remember, whatever database you buy, the data you put in it, the business processes and training you put behind it, and the fundraising strategy it is supporting are all more important than the software itself. You can have the best database in the world but it won't help if your data is rubbish, you don't adapt your processes and so on.

You also need to bear in mind just how much time and effort you can or want to allocate to managing your CRM/fundraising database. Remember that all systems will require some initial work, regardless of what the salespeople say! You will have to consider the configuration, maybe data migration, how and where you are going to store your data, how external data files will be loaded, how training will be done, how you will maintain look-up tables to ensure good data consistency and so on. And even though you are a small charity, there could still be a number of people who might well want to access and use your database, especially if it is not just for fundraising. In which case do remember the need to have someone who is data/database savvy so that they can manage these issues.

All that said, I do realise that for many small organisations, your requirements will be similar and comparatively fundamental, so I will use that assumption in the rest of this post. Plus, I am restricting examples of systems to those which should be within the budget of a small charity.

Oh, And it Must Be Simple to Use...
This is possibly one of the most frequently used statements which small (and large!) charities use. So it is important to realise that CRM and fundraising databases are not as simple conceptually as Excel, Outlook etc. They will take time to learn, they will need some looking after and the likelihood is it will cost money to do all that. Sorry. There is no easy answer to that. Software is getting easier to use and more intuitive but at the end of the day some of that is still down to individual preferences and interpretation. Just don't under-estimate the work involved in getting going if you haven't used a CRM system before.

Two technological approaches: Hosting and SAAS
Fundamentally, you have 2 technology approaches which may influence which databases you consider, and which technology is right for you will partially depend on your IT infrastructure. ¹

SAAS stands for Software-as-a-Service, where a supplier provides a database which you can access as simply as gmail etc, and from any browser without the need for any additional software. Most such solutions are only offered this way (with a few exceptions); i.e. not with an alternative "on premise" option.

Hosting is similar but one-step removed, where your database will be "hosted" on a remote server in a secure data centre somewhere (i.e. you still won't need a server in your own office to make this work). This is usually done for software which has not been written specifically to run directly through a browser and thus it still needs to be stored on a specific server somewhere. Thus for hosting, a supplier will most likely host the database on the supplier's own server and you access it remotely from your office/home. (Additionally, most such suppliers will also offer clients the option of letting you install their database on your charity's own server).

In theory, you could take any fundraising database and host it on your own server anywhere - but to do that, I would recommend that you need to have taken the IT infrastructure route which already supports that. i.e. you are already using a company to do this for some/all of your other files/software applications.


Examples
Examples of SAAS databases are Salesforce, Microsoft CRM Dynamics, Workbooks and companies offering 'templated' versions of these. Plus, fundraising systems such as eTapestry or DonorPerfect.

With hosting, you have a wider option of solutions. As I mentioned, you could look at almost any database, but some companies already offer Hosted solutions as part of their portfolio, mostly through third-party partners; e.g. CiviCRM, Advantage NFP, thankQ. (Remember these are products more applicable to small charities - there are many more options for larger organisations).

And if as a small charity you have more severe budgetary issues, then the following posts I have written before might also help you: What should you do if you really have zero budget for a new CRM or Fundraising database? and Why Free Software Doesn’t Mean Zero Cost.

---

1. More technology-savvy readers will no doubt realise I have greatly simplified these descriptions, so please forgive any gross over-simplifications! If you feel I have really misrepresented anything then please let me know by email or in the comments below - thanks.

Should organisations choose a CRM platform before a supplier?

 

With the emergence of the generic CRM systems and the reduction in the number of viable proprietary fundraising databases, an interesting question is arising: should charities now be choosing a CRM platform before even looking at which specific supplier/partner they want?

It is a process which some companies in the commercial sector have already been practising for years. For some companies, they will decide first on whether Salesforce, Microsoft Dynamics, SugarCRM etc are the best fit for them, and only then will they search for a specific partner who can help them implement a new CRM system on that chosen platform.

For charities, however, at least until recently, because the options have primarily been about comparing different proprietary fundraising database suppliers (e.g. Blackbaud, thankQ, Redbourn, ACS etc), this has not been an approach we have taken. That said, there will of course have been some technological decisions: the system must be SQL Server, or it must be Oracle; it must be dot net or it must run on Linux etc. Or even, it should be open-source. And so on. So it's not a completely alien idea.

It's just that with the new CRM systems, the platform choice can be far more "business-oriented"; i.e. if we do decide that platform X is the right solution for us - and if that platform is one of the generic CRM systems - then we now have the choice of talking to numerous companies about how they would implement that, looking at whether we want a templated version or start out-of-the-box, develop in-house or with a partner, and so on.

But additionally, if as a charity you do want to be considering a platform first, you also need to consider the proprietary solution as one of those platforms - and (probably) not just one such solution but the concept as a whole. As I have discussed many times in my blogs, there is no simple right and wrong as to whether you should select a traditional fundraising database or a CRM solution. If you do select a proprietary solution then you will (almost certainly) implement it with that system's software author and that has its pros and cons. If you go with a CRM solution, then using a business partner of that software author (or even doing it in-house) also has its benefits and downsides.

Personally, at the moment, I think choosing a platform first is a difficult approach to take for all but a few, probably larger charities who already have a detailed, well thought through technology plan and IT strategy. Especially at an early stage in a procurement project when you are still trying to understand the differences, the benefits of all solutions, the impact on your organisation and so on. I think there would have to be clear reasons for you to only look at the traditional fundraising databases, or decide not to look at those at all. You might dismiss one option or one supplier etc as you progress your procurement, but I believe you need to understand what all options can offer before going solely down one route. So at the moment that will usually mean keeping them all in the hat until you are ready to shorten your choices to the final few.

The need for The Solution Owner role when implementing CRM systems

 

For many years, I have discussed and promoted the need for a Project Manager (PM) for organisations who are implementing new fundraising databases and CRM systems. But I've been very aware that, sometimes for mid-size installations and definitely for large implementations, that there is an additional role - or skill-set - which is required and which goes beyond what a traditional PM would normally offer, although sometimes it falls on the PM. Which is the need for someone to become a central 'hub' to the project in terms of understanding the holistic solution - not the PM aspects. i.e. The Solution Owner.

The key thing for such a role is that it should be someone who understands (or can learn to understand) not only the charity's requirements and strategies but 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. Something I discuss constantly.

This means that when someone on the project, or a user or manager in the charity, has a question as to how the solution will work or how something fits in, or queries what will happen if we change something or what it will mean if something is left out and so on, then that person can be in a position where they can provide an answer - or know who they should ask in order to get an answer. It's a key need.

Ultimately, the role provides the charity with a central point of contact for design understanding and fundamental decision making and would usually also help provide requirements information.

Clearly this is not just Project Management. Historically, when I have done all this, I have called myself a 'Project Manager Plus'. But the more I have worked on implementing larger fundraising databases and with the new 'CRM' systems, the more I have realised just what a critical role this 'Plus' bit is in any such implementation (whoever does it!).

Recently, whilst working on one project, this specific role - the 'plus' bit - was described to me as The Solution Owner, and this struck a cord with me - it is indeed what I think such projects need. (On top of the project manager, business analysts, trainers etc, as appropriate, depending on project size and complexity).

One thing I should emphasise is that this is not a technical role, not a Solution Architect, nor a post-implementation Solution Owner (a role you do sometimes see advertised for), where it is more likely that it will need someone who is closer to the technical aspects of the system.

And as I stated above, the principle thing is that such a role should ideally be someone who understands the business - fundraising - and technology too. That way, they can help the charity and advise them on specific options as the project progresses.

I've also come to the conclusion that this is an especially indispensable role when implementing the (new) CRM systems where you can do so much with such systems and where it is not just a matter of configuring an existing vertical sector solution (such as a fundraising or membership package) - although it is by no means exclusively a requirement for CRM. Without such input, there is a real danger that you could go off down one route without understanding the implications, that you could over-customise a system too much when a simpler, alternative option could have been better, or you could lose track of just what is dependent on what and what interacts with what, which a central resource should be able to resolve. And the project team, client-side and supplier-side, will not have a single point of reference to help co-ordinate central requirements.

The Solution Owner is, IMHO, becoming a pivotal role for CRM and database implementations and is only likely to become more so.

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.

Should you ever invest in a short-term CRM solution?

 

Every now and then I am asked by a charity if I think it is all right if they buy a database as a “short term solution”. And for short-term, they usually mean “cheap”. This is normally asked because, for whatever reason, they (say they) can’t invest at this moment in what they feel would be a long-term database but they have to have something now.

My instinct is nearly always to say No, that’s not a good idea. But I have been thinking recently if I am always right to say that:

Why I say No
I normally say no to short-term solutions for a number of reasons:

• It will still take a fair amount of your time and effort, assuming you are doing at least a semblance of a requirements gathering and procurement process, and just because you intend to spend less or only see it as being needed short-term, that doesn’t mean it will necessarily take less time or require less effor. In fact, if you are going to put in this time, why not do it “properly” and get a "proper", hopefully long term solution.
• It is quite likely it will cost you more in the long run. Not only will you have to repeat the above process at a later date (i.e. the needs analysis and procurement), but you will have to invest initially in a database and then invest again at a later date – with all the associated professional services – and of course have to pay a second time for data migration. That means it is extremely likely that you will pay more in the long term than you would do if you spent the time, effort and money now to get your ideal system now.
• Short-term can be an excuse for doing things cheaply and therefore not comprehensively – or to put it bluntly – badly. I am often told it “doesn’t matter” because it is “only short-term” and “we will do it properly” when we are ready. That just means poor decisions all round: a potentially poor system, a non-thought through process and on-going business processes and quite possibly, a system which won’t support your fundraising needs even in the short-term.
• Short-term solutions frequently become long-term solutions… How many times have you implemented any sort of system or process as a “short term solution” only to find you are still using it months or years later.

It’s worth asking, Why can’t you get the investment for a long-term solution?
If you are having to think short-term because you haven’t got the budget for a long term solution, then it might be worth going back to your business case and trying to show why it is so important that you do get the correct and necessary budget for your particular needs. Do you need to show your SMT/trustees the benefits you will get? I would always encourage this first.

What about the “But there is new technology happening soon…” question
One reason I am sometimes told that an organisation only wants to invest short-term is because there is some great new technology which is just about to be launched in a few months... Maybe so. The thing is, new technology is being launched every day! If we wait and wait for “the next big thing” then we will wait forever. You have to do a well structured procurement process, invest in a system which (as much as possible) will be "future-proofed" and invested in by the supplier for the foreseeable future and take the plunge.

So, is there ever a reason to say Yes to a short-term solution?
I guess there are a few scenarios I can think of where I would consider saying Yes to short-term:

• If you invest a small amount in a product in the first place which you intend to invest more in later. In fact, this is quite common and in some instances perfectly good business sense. If you need to start using the database in one department/team and then build-up the system across other teams in your organisation then why not. If you only have a small budget now but you can get started with this and apply for a larger budget for the next year, then yes, this is an option. You still need to do all that in a ‘proper, structured’ way, so that you know you are buying a system which will be scalable in the future, but if so then that could be fine. This is therefore not the same as just "buying short term" because what you doing is planning long term in a good, structured way but simply investing less initially.
• If you are, say, a small fundraising department who needs a system now, but where the long term strategy of your charity is a broader organisation-wide CRM system. In which case, as long as your charity recognises they will be spending money later on integrating/moving you to a new system, then short-term thinking could be appropriate.
• There are of course a few good, low-cost fundraising and membership databases for charities and it is better to consider those in a well thought-through process than just buy one for the sake of it.

But what if I really have no budget for a new database?
I know, this is always a potential problem, especially for smaller organisations. And the temptation is therefore to just "get something in now" because we have to have something, and to worry about it later. But, if this really is due to severe budget restrictions, then this doesn't mean you still can't go about procuring a new database using a good process. Read my recent blog post, What should you do if you really have zero budget for a new CRM or Fundraising database?

It's not the technology that's difficult, it's Everything Else

I recently visited a comparatively small charity who wanted to extend the use of their fundraising database beyond the fundraising and marketing department. It soon became clear from our meeting that there was no problem with the technology in terms of doing that, they have a good fundraising package and it can certainly manage the other departments’ requirements.

But what was also evident quite quickly was that the main problems with the project would be the non-technology aspects: some objections from other people, training, data migration, standardising codes and terminology, adjusting business processes, finance flows, data protection, the time it would take other departments to enter what they saw as less useful data, record ownership, user licenses, ensuring new users attend workshops, planning future communications, budget… and so on and so on.

All of which just went to re-enforce my understanding and belief about all such CRM implementations in that the technology is the simpler part and the People, Processes and Everything Else is always the challenge. (NB: I’m not saying technology is necessarily simple, just simpler…).

This is of course what I have been banging on about recently to anyone who will listen (and, as anyone who knows me will testify, I can go on a bit…!) and my apologies if I am starting to sound like a broken record. But I hope that if I keep doing so, then even if just a few organisations who read this take on board the message and thus plan their future database and CRM implementations with this in mind, then that will make me feel much happier.

9 Guaranteed Ways to Improve the Use of Your Database : Part 2

This is the second part of my blog on guaranteed (really!) ways to improve the use of your database. (But please do refer to my first part for a couple of caveats on the Ease, Time and Cost points...)

6. Instigate a structured training (and learning) culture

One of the most common complaints from end-users of CRM systems is that they have not received sufficient training. The training may have come from the person who’s job they were replacing, it may have come from someone else entirely who knows a bit about the system, it may come from someone who has been at the charity for years and is still following processes which are way out of date. Or they may have just been given an old, dog-eared collection of papers and told that is the user manual – or they may not have had any training at all!

If you want your database to be better then you need people to use it as it is intended. And therefore you need to train them. Properly. By people who know what the database should be doing, who know what the latest processes are, who have the time to train someone, who are happy and comfortable training someone - and, of course, training someone who has the time and inclination to learn. Being trained on your organisation’s database should be part of someone’s induction plan when they join your charity.

I also distinguish between a 'training' and a 'learning' culture: individuals should be encouraged to learn more about the system(s) they are using. This isn’t necessarily easy! Why should they bother learning something or asking more about something or wanting to improve something if it doesn’t help them with their job? So make it so that such practise does help them with their job. If they can’t do something on the database then encourage them not to remain quiet but to tell someone. If they have a good idea then get them to tell someone. The more people learn about what is possible on a database then the more they, you and the organisation will get out of it.

Ease: No technical skills, but needs Senior Management support

Time: On-going

Cost: Free

7. Create reports (and dashboards) your users and managers really want

If you really want to improve the use of your database, then you need to give users and managers information which they really want. So ask them what information they want, ask them what would really help them in their every-day role and with their strategic role, ask them what is most important to them and what they have always wanted to know! You might want to “manage expectations” around this by explaining that you might not give them what they want tomorrow... but you will try! You might also find that they can’t get such reports because no-one is collecting the data they want. So they can then help you rectify that.

Then create reports which they can use. And dashboards – managers love dashboards.

Ease: Needs technical skills

Time: Each report might take from a day to many days!

Cost: Free if you can do it internally (Otherwise you'll need to pay someone)

8. Create a Business Analyst role

This is one of the best ways you can get more out of your data and database, but it is also one of the more expensive. Human Resources always is. But what a Business Analyst (BA) will bring you to your organisation, if you don’t akready have one, might change and improve the way you do things so that they will more than pay back their salary.

Because what a good BA can do is go out to the users and discuss their needs, ask the managers what information they want, examine the procedures and processes you have, work on strategic documents with your staff, analyse data, analyse the database, produce options for change, make recommendations and help implement. They can act as the “bridge” between your database team and your users.

I realise this might sound like some “impossible creature” to some people, but really, they can be one of the most important roles in any organisation. To have someone who understands data and databases and what they can and can’t do, but can talk to your users and understand their business is gold-dust. If you find someone who can do this for you, hang on to them!

I should also say that although I use the term "Business Analyst" and define it here as a specific role, if you have someone who can do this sort of work even if they are formally called the "Database Manager" or any other similar position, then that is just as valuable. It's the skills and process which are important, not the job title per se.

Ease: Can be quite difficult to find someone good

Time: Permanent role

Cost: Expensive, as in you need a full-time employee on a reasonable salary

9. Get rid of any Data Ownership hang-ups

I’ve blogged about this before, so to summarise here:

Many charities are now moving away from "data silos" and the concept of "owning one's records". Which is great news and about time. So the next time one of your users/colleagues/staff says to you, "I don’t want my contacts to be stored on a central database because I don't want anyone else to be able to contact them…" then this is the response I recommend you give them:

The fundamental problem with this is that if they don't store their contacts on the central database (and instead, for example, keep them stored in Excel) then, in actual fact, it will be impossible for them to stop anyone else contacting them - assuming that such contacts have - or will have - other relationships with your organisation which are already stored on the central database. For example, if your user is the events manager, then if any of their event registrants are also donors, volunteers, prospects, on other mailing lists etc and as such they are already stored on the central database, then how can the events manager stop them being mailed? No-one using the central database will know that they are also on the separate events spreadsheet. Moreover, they will probably need to be contacted sometimes by other users anyway.

And anyway, it isn’t “my data”, it is the charity’s data. Start using it for the holistic benefit of the charity.

Ease: In theory easy, but you get stubborn individuals!

Time: Instant to instigate, may take time for everyone to buy-in

Cost: Free

I hope you find all these suggestions useful. They really will improve your database if you put them into practise in a structured and considered way.

And if you have any other suggestions then by all means leave a comment below.

Don't Shoot The Database (Or Me, Please)

There are only so many times that I can take being told that a database is rubbish when actually it has nothing to do with the poor database, and everything to do with how an organisation is working. This was brought home to me again recently when I was asked by two organisations how they could improve the usage of their databases.

The first was a small charity who were using a good, industry standard package for their fundraising operations, but, they said, "it just isn't helping us". So what sort of fundraising do you do, I asked. "Well," they said, "we don't really have a plan as such. Last year the chief exec's daughter did a door drop to a few hundred houses in Hampstead, and this year we thought we might do some DM, but we're not too sure yet."

And you think the database is rubbish?! Please. If you don't have a fundraising strategy, if you don't know what sort of fundraising you will be doing, then how can you blame the database for not helping you? Yes, I know that part of my job as a consultant is to ask questions and dig deeper and find out if there really is more to it than they are initially saying, and of course I should help explain what a database can do; and I have no problem with anyone who says "I don't know exactly what I want from the database because I don't know what it is capable of," - that is indeed my job to help elucidate - but don't attack the database if you don't even know what sort of fundraising you are going to be doing in the first place!

The second case was a mid-size membership department in a larger organisation. They too told me their database wasn't supporting their operations and to be fair to them, it isn't the best system I have seen. But when I started to ask questions as to how their operations worked, it soon became apparent that there were distinct political issues between the membership and development departments. Not only that, but membership income was dropping, the benefits system they offered was in a bit of a mess and even their IT department was refusing to help because the membership department were buying their own equipment regardless of the organisation's overall strategy.

But, again, it was the database's fault! Now, yes, I realise that this was probably as much a frustrated rant on their behalf as opposed to necessarily a real belief that the database wasn't supporting them, but it doesn't help them or me if the IT systems are blamed when it is the underlying organisational system that really needs addressing first.

What both the above cases help emphasise is one of my most fundamental beliefs about why a database is or is not successful for an organisation: unless you have got a sound fundraising strategy, membership strategy, IT strategy, communication plan, organisational structure, solid management and so on, then it doesn't really matter if you have the best database in the world – it won't be able to help you in any meaningful way, or at least as well as it could be doing, until all these underlying factors are put in place. I know (at least I hope) this sounds obvious, but clearly it had slipped the mind of the above two organisations.

So go ahead, slag off your database if you want to, but, please, have a good look around you just before you do...