How long does it take to implement a new database?

... and the Influence of Project Scope

 

One of the hardest things about implementing a new CRM system or fundraising database is going at the right pace: too fast and you may rush things, forget something, not do enough testing etc; but too slow and you can lose impetus and enthusiasm – “sorry, why are we doing this project, again?” It’s a tough call.

Historically, I’ve found that charities start such projects with too tight a timescale and don’t leave themselves enough time to get it right, but then often relax such time constraints too much so that they leave themselves in danger of losing all the goodwill and excitement which they had when the project commenced. (Although some organisations do do the opposite!)

And by “implementing a new system”, I am specifically referring to what we can loosely call “Phase 1” or “going live”, which means starting to use the new database in a live environment for the first time and stopping the use of any old database. Thereafter, of course, after we “go live” there could well be more “phases” (although more about that below...).

Perhaps unsurprisingly, one of the things we can do to help us understand how long it should take is to review and understand the project scope, so here’s a few things to consider which might help you get this right. (NB: I'm aware there are clearly other factors which influence timescales, from the type of software to resource availability and  budget, but scope is still one of the most central points to consider).

Go Back to Your Business Case for the Scope

You do need to consider what you said you would achieve in your Business Case. If there are some things in that which you now feel you can’t do in an “acceptable” timescale, then you might need to get any changes approved, but you need to be at least laying the foundations for why you initially decided that a new system was required.

What you must do in Phase 1

The new system needs to deliver some tangible benefits and manage key and critical business requirements. This doesn’t mean implementing all your wishes on day 1, and it doesn’t even necessarily mean replicating everything which you can do now in your existing database - but you need to ensure that it can: meet any fundamental operational requirements (e.g. processing donations, producing acknowledgement letters, recording basic information etc); manage any business critical processes (e.g. making direct debit claims, providing mailing files/letters for appeals); and (almost certainly) ensure that it can do regular, automated tasks such as importing third-party data feeds, produce Gift Aid R68 claims etc. I say almost certainly because, for example, if you can’t do a Gift Aid claim immediately, then you can still do that x weeks/months later and still claim the same gift aid (assuming it isn’t the end of the financial year and thus you miss a 4 year back-claim).

Enabling Reporting in Phase 1

If you don’t provide reports then people will very quickly question the benefit of the new system. You can of course technically go-live without producing reports, but if you do then so much of the benefits from any database will be lost. It may be that you can’t immediately produce all reports on your wish-list, but that’s okay as long as you plan their delivery over the weeks/months to come.

Keeping it Vanilla

I’ve written previously about the benefits of keeping your initial implementation as “vanilla” as possible and not being drawn into designing complicated customisations which will take time, cost money and increase risk. This will help maintain a useful, structured timescale.

Planning Post-Go-Live Development

If you do cut-back on the scope of the project to get an earlier go-live date, then make sure you plan and communicate when you are going to implement those things which were left out of “Phase 1”. And my recommendation is not to do this as “Phase 2”, “Phase 3” etc, but to move into an “On-going Development” phase, whereby the other items are planned for in this way.

Try to include some Quick-Wins which will Inspire and Excite

If you can do, include a few really inspiring things which will get people excited about using the new database. What this is will of course depend on what your organisation has had before, your users and their expectations! It might be something as simple as introducing mail-merges which do conditional merges and produce different letters; it might be mapping your donors on a Google map; or it might be automating something which has previously taken a long time to do manually.

Don't tie the project to "fake dates"

So often it is the case that charities say they must go live by date X. Often because someone senior has said that this must happen - but without considering any of the above, or other issues, and without really understanding what is involved. If you originally believed you had a 9 month project, but for whatever reason, you start 2 months late, then why should it suddenly be viable to make it a 7 month project?

Similarly, be aware of - but be careful of - dates in the year for when you must do it by; e.g. end of financial year, before a large campaign etc. There may well be good reasons for considering such dates as part of the project plan, and if you can do and if it is correct to work them into the project then that's fine. But if they constrict the project too much then don't let them over-rule everything else.

Understand availability and restrictions on your staff's time

Very often a supplier can work more quickly than the client, and charities often find that the amount of work needed to implement a CRM system is far more than they expected. So don't under-estimate the amount of work it will take your key users especially, and either allow them time to do their Business As Usual as well, or back-fill (some of) their work.