Databases > Planning A Database, Choosing A Database

Dealing with a dead database – a database development case study

By Nicole Aebi-Moyo

How do you decide what to do with your dead database? This article takes a look at the Medical Women’s Federation’s experience of database development. What processes did they go through? How did they choose a solution? What alternatives are there?

Introduction

The Medical Women’s Federation is a small organisation with two members of staff and just over 1000 members. Their aims are to advance the personal and professional development of women in medicine, to change discriminatory attitudes and practices and to work on behalf of patients. Nearly 10 years ago, a volunteer developed a database for them using Filemaker Pro. The database was their pride and joy: it allowed them to efficiently process their membership applications and renewals, and create their annual directory of members.

However, over time, the database was gradually modified by a succession of office staff and the developer had long gone. So after nearly ten years of service, they had a database that caused them headache and grief and meant they couldn’t be sure they were processing their membership scheme accurately.

After considering all their possible options, they chose an independent developer they felt confident working with to develop a bespoke, simple database. Here’s how they went about it.

Set a rough budget

The first thing to do was convince their board of trustees to spend some money. Putting together a business case that talked about improved efficiency and increased income from membership convinced the board to say yes, and to set a maximum budget of £1000.

Defining the project brief

Having attended the Women’s Resource Centre’s training course on Choosing a Database, they knew they needed to work out what it was they wanted a new database to do.

The staff audited every single process in the office and produced flow-charts:

• how was a new membership enquiry dealt with;
• what happened when a new direct debit form came in;
• what information did they want to send to members;

and so on.

They also looked at the other functions of the office to see what could fit into a database: press contacts; grant holder’s details; potential members; the list grew.

Using all of this information, they developed a database brief (or tender) that included:

1. information on the MWF itself (history, aims, size, etc);
2. a brief outline of the problem;
3. information on what they wanted from a new database;
4. the budget they had to spend;
5. an approximate timeline for finding a solution.

With their membership year running from January to December, timing was crucial. They needed to be sure a new solution would be in place before the end of the year or they’d have real problems processing 1000 membership renewal forms all at once.

Investigating potential solutions

They concentrated on three possible solutions:

1. find a Filemaker developer and get them to fix their current database;
2. buy something ‘off-the-shelf’ that they could customise to their needs;
3. find a database developer willing to develop them a database for £1000.

1. Fixing their current database

Initially, finding a Filemaker developer proved tricky. A quick post to a discussion board generated a few replies, but digging behind the scenes at the profiles suggested they perhaps weren’t the best choice for MWF: “As well as developing databases, I like drinking beer and looking at beautiful women” said one biography. Hmm…

2. Buying off the shelf

They had a look at a number of products but without the time or the knowledge to really look into what each was capable of doing, they couldn’t be sure that what they ended up with would really work. They felt nervous about trying to make a decision and implement a solution themselves.

3. Find a database developer

They asked everyone they could think of for possible contacts including:

1. their board;
2. their colleagues in other organisations
3. the ICT Hub Suppliers Directory
4. they also considered recruiting a volunteer from IT4Communities

They were reluctant to use a volunteer again after the last one disappeared just when they needed them, so option 4 wasn’t considered.

Although MWF decided against using volunteers for their project, many organisations have had great success with volunteers. You might consider using a volunteer to help define your requirements, write a brief with you, or research your options. Consider where some expert help might be useful and contact IT4Communities  to see if they can help. They’ll be able to offer you advice about when it’s appropriate or not to use volunteers. See also the article Working with ICT volunteers.

From the contacts that they found, they produced a list of possible developers and sent out the project brief they’d developed earlier. Now they just had to wait for a response.

Choosing a solution

Many of the developers they contacted simply didn’t respond. Some responded by saying there was nothing they could do within the budget they had. Then within the space of a couple of days, they got two quotes that seemed reasonable. One from someone suggesting a solution designed using access; and another suggesting a Filemaker solution. And all within the £1000 budget that they had. Great, now they had a choice.

They called both developers in for interview, to talk over their suggested solutions and to show them their current database. Eventually they decided to go with the Filemaker developer as they felt they could work with them better and they knew the software well. After checking references, they were off!

Working with a developer

The first thing was to sign contracts and agree a timeline for delivery.

The contract included a clause outlining who would own the design of the database at the end of the process and what would happen should the relationship breakdown.

The timeline outlined the key tasks and steps in the process along with who was responsible for doing what. It also included agreed sign-off points with interim payments and a date for final delivery. An excerpt of the agreement is below:
 

Timelines

What	Who	When
Meet to agree contracts and timeline	All	Week 1
Meet to review information audit and review requirements	Developer, admin staff	Week 1
Create a paper-based database	Developer	Week 2
Review paper-based database	Developer, admin staff	Week 3
Develop database based on paper version	Developer	Weeks 3-6

 

Implementation and Training

The final stage in the process was to install the database and transfer the existing data across. The MWF office staff had spent quite a bit of time tidying up the data in the old database, but there were inevitably still things to sort out in the transfer. But the developer and the administrator worked together and used this as a learning/training opportunity. By the end of the day, the database had been installed, data transferred, most of tidying up was completed and a list of snags and work still to be done made.

The brief had required that time be allowed after installation to identify bugs and trouble-shoot so the minor snags weren’t a problem. And the planning and audit that MWF and the developer had been involved in meant that the database as developed was very fit for purpose.

Once the team were happy, the snags had been sorted and the data was all in place, the developer handed over the finished user manual. An administrator manual outlined the key architecture of the database so that any future developers could work with the database to make changes.

Support

The tender included 3 months of support and minor amendments but did not include an element of on-going support. However, there have been one or two small questions about the use of the database and the developer has been more than happy to deal with these small niggles. Not every developer will work like this, so do make sure that the support you want is included in any quote you receive.

Summary

1. Start by defining your problem
2. Get your board involved
3. Set a budget
4. Define a project brief – look at your processes and do an audit
5. Investigate potential solutions – assess the risks and benefits of each
6. Send out your project brief
7. Interview potential suppliers
8. Choose a solution
9. Agree a contract and timeline
10. Tidy up your data (if you already have some!)
11. Ensure you get the solution you need by building in some time for fixing snags
12. Think about your support options
13. Get documentation from your developer – a user manual and development specification so that others can work on your database

Database suppliers

There are hundreds! Some examples of the most relevant and largest suppliers for voluntary and community sector organisations are listed below, but the list is by no means exhaustive. For a more complete list, visit IT for Charities and see the ICT Hub Suppliers Directory.

 

Examples Of Database Suppliers

Company	Product	Contact Details	Used By:	Approx Cost*
ITSorted	contactLINK	www.ITsorted.org.uk	Low-tech, low-cost solution for small to medium-sized organisations	From £400
3rd Base	VolBase	www.volbase.co.uk	Several CVSs in Gloucestershire	From £2700
Esit	ThankQ	www.esit.co.uk	NAVCA (National Association for Voluntary and Community Action)	From £4000
Blackbaud Europe	Raiser’s Edge	www.blackbaud.co.uk	Action for Southern Africa and many others for fundraising especially	From £7000
Fisk Brett	Progress	www.fiskbrett.co.uk	Women’s Resource Centre	From £9000
Infoworks	Bespoke products	www.infoworks.co.uk	Bespoke databases	From £15,000

 

*Note: these costs do not include training, support or any on-going costs of licensing.