Database Suppliers

Ten steps to choosing a database supplier

1. See whether someone from outside your organisation can help you run the process, such as a project manager from the local council who has delivered database-related projects.
2. Start by writing the clearest database plan you can – a bit like a job description. Keep it simple but focused on what you require.
3. Use the NCVO preferred suppliers directory and feedback from contacts to draw up a list of possible suppliers. Advertise the main details through email lists and on your website and invite people to email you if they are interested.
4. Send your current database plan to potential developers and suppliers and ask for a written response to how they will meet your needs. Set a deadline and indicate interview dates. Invite informal contact beforehand, if you think you will have time to deal with it.
5. Compile a shortlist in the same way that you would to fill a staff post. Identify the ones you think fit the budget and your needs, and then interview them. Two or three should be enough, although seeing more may help clarify your requirements.
6. Involve a small but diverse group in the interview process, including someone who will be putting data into the system as well as someone who will be using the reports.
7. Use the interview to decide whether they understand your needs and have the project management skills, technical solutions and experience to meet them. See the note below on ‘What to look for in a database supplier’.
8. Remember that you don’t have to make a final decision at the interview. You can follow up specific questions with each supplier, or ask them to resubmit their bid to reflect any changes you now realise that you need to make. You may ask for a further presentation, or bring the panel together again informally to review any follow-up information submitted.
9. Even if the interview goes well, always check with referees about how happy they are with what they got for their money.
10. Once you’ve selected someone, draw up an agreement about how the project will proceed, in the form of a letter of agreement or written contract. An initial project plan will show key phases and milestones for completion, as well as a payment schedule, and may be included in the submission for the tender. This may be used to reach final agreement, but never start work until it has beenfully updated and agreed by both parties.

Key questions for any database developer include:

• Have they done this before?
• Do they understand what you want?
• Can they deliver what you need?
• Can they support the database when it's finished?
• How much will they charge?
• Can you work with them?

What to look for in a database supplier

It is important that you review the work of anyone who is selling you a database, whether theyare building something from scratch or adapting an off the shelf solution.Although some of yourrequirements may be technical, such as whether it requires a server, or whether your existingcomputers will support it, the review is an opportunity to look at other issues:

• Can you see work they have done for otherVCOs?
• Do the screens seem easy to navigate?
• Are reports easy to set up and then print or export? Can they be adapted by the user? Ask tosee how easy it is to change the reports, or have a go yourself if you can.
• Who picks up the bill if deadlines are missed?
• Do they use a language you understand, or overwhelm you with technical jargon?
• How will they manage the project? How will progress be monitored?
• Do they have time to fit in your work? If they’re offering a discount, will you be a lowerpriority?
• What user manuals or training will you get for your money?
• What is their hourly rate for any work outside the scope of this project?

Once you've chosen your solution

Deciding what you want and who will deliver it is just the start of the process.

The next stage is for the developer to produce a functional specification, listing the key tasks that drive the system and details of what is required on each data entry form and report. It may also include sample screens. Only when the functional specification is agreed will the developer start the detailed development work.

Don’t take a quick look and think ‘Oh, we can sort that out later’, because this specification will be the blueprint for the whole system. Allow time to involve the people who will be using the system and check details thoroughly.

Database development is a complex and dynamic process so new ideas may come up during the project. All changes need to be agreed in detail and could take extra time, and therefore money. You and the developer need to be pragmatic about what can be achieved within your budget.

Clearly identify key people involved in decision making and make sure they get regular progress reports about how things are going. Identify risks as early as possible, consider contingencies and be prepared to change track to ensure the best use of resources.

Above all, don’t avoid problems if they arise. You should expect some difficult choices to be made, where conflicting needs cannot be reconciled. Use the objectives in your database plan to guide priorities: which option will deliver the most important benefits?

Once built, testing is crucial and must involve the people who will use the database. Ask them to carry out the tasks in the specification, and allow plenty of time to deal with bugs. Errors that you ignore now will be embedded in your organisation’s work until further development can take place.

Once you agree that everything works the way you planned you can complete the implementation process.This includes installation, training, ongoing technical support, fault logging and a review. And then you can start planning the next version.