How to Consider All Costs in Database Procurement

Because most charities will only make a significant investment in a new database system every few years, they don't always consider how they need to compare the costs of such purchases. And it is vital that when comparing costs you don't just look at the cost of the software - you must look at far more than that. One useful approach to help with that is to use the Total Cost of Ownership (TCO) cost model. This post provides a basic introduction to this.

Why is TCO Important?
Firstly, you must remember that the new database software is only one element within all your potential costs for a new system, and secondly, that it is not just the initial cost of the system which you need to cost – you should create a TCO for, say, 5 years.

This therefore involves the comparatively simple task of comparing ‘direct’ costs such as software, the supplier’s implementation services, additional hardware etc, but optionally you could also incorporate the more difficult/complex task of additional cost factors such as internal IT HR support costs, electricity, de-commissioning etc. In practise, most charities will find that even if they just compare the more direct costs, that will still help significantly, and it will probably only be the larger organisations or charities who implement  large CRM systems who will incorporate the additional cost factors.

Costs you Should Consider
Below, is a list of ‘direct’ costs which you should definitely be able to calculate when comparing database systems (although different suppliers may of course call them by different terms). Although I would expect most/many to be needed within most CRM projects, you may not need them all or you may of course need other factors not listed here. Use it as an example and basic model – break it down in the best way for you so you can compare and contrast the costs. By doing this, you can compare different suppliers’ costs like-for-like.

The Database Application Software (and associated software)
•    Core software / application software (including the number of concurrent users/seats)
•    Additional modules
•    Customisation / Bespoke programming
•    Reporting software
•    Web software / web services

Implementation
•    Functional Specification / Analysis & Design
•    Installation
•    System configuration / System build
•    Implementation
•    System Integration – including synchronisation with your web site if appropriate
•    Supplier’s Project Management
•    User Acceptance Testing support
•    Training (SuperUser training, end-user training, training materials)
•    Go-live support
•    Data Conversion (estimate or allowance)

Annual Support (Maintenance)
•    Application software Annual cost
•    Additional software annual costs
•    Hosting costs (if applicable)

Third Party software
•    E.g. PAF software, banking software, new Office software needed

Underlying Database software
•    E.g. SQL Server
•    Client Access Licenses

Hardware and associated (operating) software
•    Server(s)
•    Clients
•    Communication links
You might also need/want to add annual maintenance costs for any such hardware and infrastructure.

How to use Your Calculations
Put them all in a spreadsheet, each cost as a row and the different suppliers/options as columns. After doing this, you will have two “broad” costs – a first year cost (initial implementation) and annual costs for each year thereafter. Thus, you can get a 5 year TCO; and thus you may find that what seems to be cheaper/more expensive in the first year may be more expensive/cheaper over the 5 year period!

More Comprehensive TCO
In terms of additional cost factors which help create TCO at a more comprehensive level, you might include the following. Some of these will be the same cost regardless of whichever supplier you select, or they might break-down into a few groups (e.g. hosted vs non-hosted solutions).

•    Purchasing process
•    Operating Costs
•    Project Management
•    Internal IT staff
•    Internal Database/Marketing staff
•    Back-filling for project staff
•    Management time
•    Electricity and air-conditioning requirements
•    Floor space
•    Outage costs
•    Back-up/Recovery cost
•    Risk cost
•    Opportunity cost
•    Additional hardware such as UPS, racks

And a Final Note on Costs
Cost is of course a significant factor in the decision of any procurement for a charity, but please bear in mind it is not the be-all-and-end-all! You need to weigh it up against all the other important factors of any database implementation from functionality and usability through to the supplier itself and how it meets all your needs.

5 Innovative Challenges for Your Database Team for 2011

If you manage a database team, or you are part of a database team at a charity, then why not challenge yourself this year and do something a bit different and innovative! The suggestions below will take time and commitment and maybe even some financial input, but I believe that you and your organisation would get excellent benefits out of them (and slightly different from the norm). They are probably best suited to charities who have a bit of manpower in their database team and a reasonable sized user-base, but even if your organisation doesn’t fit that model then you could still adapt them to your own structure.

And even if you don’t like my suggestions, what about thinking of alternative but new and different challenges of your own? Share any you come up with in the Comments section below this post.

Enjoy!


5 innovative challenges for your database team

1) Hold an Internal User Conference. i.e. In the same way that your database supplier might hold an annual conference for their customers. Put aside a day (or a half day if a whole day is too much) and have a couple of 'streams' of seminars, invite users to speak at some sessions, invite a keynote speaker (try your supplier, ask a funder, invite me!), consider workshops or one-to-one "consultancy sessions" and of course put aside time for coffee and networking. Yes it will definitely take some serious organisation, yes it could cost to do it and yes it could be a challenge to get managers to let all your users go, but, hey, it wouldn't be a challenge otherwise!

2) Spend a day in a data/database department at a commercial organisation, learning what they do and how they practise database management. We can be very insular in the charity sector, and although I know plenty of NFPs who run wonderfully good database teams, we could definitely learn from for-profit companies too. Ask your fundraisers if any of their contacts, sponsors, funders etc might be up for helping, or just use your own contacts – we all have friends who work in large companies and other sectors. One thing you could consider is not simply selecting a company “similar” to your charity, i.e. a bank or a retail organisation. Why not try somewhere completely different? A leisure centre, a construction company, a vet! Surely we can learn something from other such industries. And if you have a large enough database team, send different people to companies in different sectors and then compare notes.

3) Think of new ways to use all the data fields which you already store in your database. I have done this a few times (admittedly with varying degrees of success!) but it’s always interesting, even if it’s just as an ice-breaker for a meeting. For example, why do we store an individual's first name? Just so we can write to them? Boring! Think of something else. How else could we benefit from knowing someone’s first name? How could we use that data/information? And what about your other fields - Date of birth? A job title, zip code/postcode, first gift date etc etc. Brainstorm. Who knows what it could lead to.

4) Dedupe your entire database, just for once! Now that would be a challenge… Can we ever say that we have no dupes in our database?!

5) Do some brand new data analysis on areas never looked at before on your database. So often, database teams are asked to do specific data analysis by fundraisers because of specific campaigns, or because we/they know (or we think we know) that tried and tested analysis techniques work. Which is fine and should of course be followed. But try instead, for example, to test whether there is any correlation between 2 or more factors/data items on your database which your fundraisers have never thought of using/comparing. Compare fields and data against each other, against time, against demographics, income and so on. This might well involve a lot of data mining to come up with anything new and useful, but if you do find something then that might create a whole new fundraising opportunity or income stream. Fundraisers are not data or database experts – you are; so don’t rely on just being reactive to their requests, be pro-active and think of some ideas yourself.

Should I Use The Cloud for my Charity's CRM Applications in 2011?

The Cloud is currently one of the buzzwords in the IT industry and you may well get great benefits from using it. As such, it makes complete sense for you to consider using it for your (new) database – but not blindly forsaking all other considerations. Treat it in the same way as you would any other technology consideration in your procurement process and if it turns out that your new database will be cloud-based then you will have done that in a proper, structured way.



Possible Benefits
The following list details some of the benefits of using the Cloud for a database application in particular, although as you will see, benefits often have considerations attached to them:

• No software installation (although you might still need to do some configuration on your network/PCs, firewall etc to enable your organisation to access the hosting platform);
• Thereafter, easy/automatic (invisible) upgrades, which is a great time-saver. (Although, you might want to consider if that is always a benefit if it means it happens without your knowledge and therefore if you haven’t done any regression testing on your existing system or without the ability to update end-users on changes);
• Richer functionality than has historically been possible with web-based systems: the latest generation of web-based databases are able to utilise far better technology, flexibility and customisation that is starting to really challenge traditional ‘client-based’ database applications that have historically provided richer functionality;
• Access: It will also be easy for anyone in your organisation to access the database from wherever they are (providing they have got at least a broadband connection), so it’s great for charities with multiple/remote offices and home users, and, increasingly now, for those who require mobile access.

And of course there are other benefits which stretch past the database application itself:

• In terms of your IT infrastructure, the Cloud means you don’t need your own database server and all the headaches/upgrades/licensing issues and IT management which comes with that (technological and HR), and can ultimately mean a lower Total Cost of Ownership (though not always!). You can spread the costs more evenly when hosting;
• PC specifications: for “pure” Cloud applications you may not need such high-spec clients as you would do for Windows-based applications, which in turn might mean you can keep your existing PCs for a longer period before needing to upgrade them;
• Scalability: if you need more server space then that can be added in an instant (obviously at a cost!);
• Security: although this has to be a consideration, some data centres will have far better (physical) security than your charity office ever could!

Possible Downsides
But you also need to consider possible issues:

• When thinking of charity-specific requirements, from an application/functionality point of view, you will have less choice of actual databases which are especially written for the Cloud (although you can use your client-based systems and host them off-site instead), and functionality may not be as rich as some of the better client-based/Windows packages – don’t lose sight of this point at any stage;
• Configuration and customisation: hand-in-hand with functionality, but specifically so, is the point that not all web-based solutions will provide the same level of configuration and customisation that can come with Windows packages - of course, some will, and indeed, some Windows-based databases are not that customisable, but if you need this degree of flexibiity then take note;
• Data protection and security does need to be thought through – it isn’t impossible to ensure they are managed but don’t ignore this;
• You will need excellent and fast enough communication links into the Cloud, from all the locations where you want to access the database from - there is nothing more likely to alienate users than a slow database system - and depending on its criticality to you, a high level of service commitment from your comms supplier(s) and maybe even some redundancy;
• Backups: Any good host will not only take backups but probably have mirrored servers and other technology as well to assist when servers do go down. But for good business continuity planning, I wouldn’t just assume that the host will always do back-ups, so instigate your own process even if it is not daily. Plus, if there is a disaster at the host’s site or you run into contractual issues, then you will have a copy of your data – your most valuable asset – to hand if you need it.