Databases > Choosing A Database, Planning A Database

Choosing a database developer

By Lasa Information Systems Team

The process of getting a database built from scratch is fraught with hazard. It's a major project for any agency and shouldn't be undertaken lightly. This provides some general guidance on key issues to consider when choosing a developer.

Preparation

As the saying goes "preparation is everything". Before you even begin the process of choosing a developer there are several things to think about:

Are you sure you can't buy off the shelf?

Before getting a developer to build you a database from scratch, it is essential to properly consider why you want to do this. Have you reviewed existing products to find out if there is anything that could meet your needs? - No database will do everything you want it to do - all have limitations whether off the shelf products or built from scratch - it's important to understand this from the start and be realistic about your expectations.

The benefits of an off the shelf database are that you are getting a proven product, which can be implemented relatively quickly and it is much less demanding of staff time and skills. Database development is a really major project and you need to ensure you have the necessary resources to support it.

Have you decided what your requirements are?

The more time you invest on this will be amply repaid in future. If you don't get this right, your project will be in jeopardy before you even start.

• Concentrate on requirements not on solutions. Say what you want to do in your own words and terms - don't start assuming a particular solution. Many "techies" find it hard to think in terms of requirements - they are so used to dealing with solutions that they can only think in terms of the technical solutions they know - cutting off all other options.
• Consult all those who have knowledge.
• Ensure you have management buy-in.
• Write a clear requirements document or Invitation To Tender (ITT) document - the clearer your requirements document, the easier it will be for a developer to provide what you want.

Do you have a realistic project budget and timetable?

Database developments can be incredibly complex - there is often a mismatch between what an organisation wants from a database and what can realistically be delivered.

Database development takes time and you'll need to make sure you have enough resources dedicated to the process. For example, the database will need to be tested at various stages of development - the timetable and funding for the project need to allow for this.

The organisation and the developer will also need to have a clear understanding of each other's roles and responsibilities. The analogy of getting a builder in to do work can be useful for managing expectations (- the work often ends up costing more and taking longer than you thought!)

If you are determined to go ahead …

The remainder of this article assumes you are determined to go ahead with building your database from scratch (or work with a developer to modify an existing database), and that your organisation has gone through a proper database planning process to produce a clear requirements document. Some of the checkpoints require an evaluation of the answers that a potential developer will give to your hopefully searching questions.

You will need to consider how you are going to do this. Will you use an external consultant or is there someone in house with the experience to carry out this evaluation? If using an external consultant you'll obviously need to budget for their costs as well.

The selection process

There are all kinds of developers out there - from sole traders to large companies with swanky offices and everything in between. There are pros and cons to each and it is impossible to give any hard and fast rules about which type to go for. Generally though, a sensible decision will be based on the size of the organisation, the size of the company doing the development, and the complexity of the project.

The key issues are: Have they done this before? Do they understand what you want? Are they viable - will they be around in three years time? Can they support the database when it's finished? How much will they charge to do the work? It is a good idea to treat the process of finding a developer like you would any other staff recruitment.

The selection process will involve drawing up tender list (- ask everyone you know), sending out requirements document, short listing, interviewing, and making a final decision. The process can be more informal than this but equal opportunities interview techniques work very well - especially as an antidote to cuddly sales staff who will try to sweet talk you.

Tendering

Your requirements document will form the basis of your selection process. You need some form of Invitation to Tender document which incorporates your requirements but also gives the suppliers information about your organisation, your timetable, budget, and the selection process. See the Knowledgebase section on Managing ICT Projects.

Find out what experience the developer has of building and / or evaluating databases.

You need to satisfy yourself that the developer has a track record of doing this kind of work. Check whether this experience includes working with agencies and / or databases similar to your own.

Ask for and take up references

This includes financial and accounting references. You want to be sure the developer will still be around to complete the project. When taking up references from organisations that the developer has previously worked with, make sure you ask some searching questions about their experience of working with the developer:

What were the positive experiences? What problems were there and how easy was it to resolve them? Is the organisation still using the database the developer built? If so, are there any problems or issues with it? If not, what are the reasons for this? Is there anything the organisation would have done differently? etc.

Post development support is a big issue and is clearly one that only previous customers can talk about.

Look at examples of their previous work if possible

How user-friendly are these databases? Could something similar meet your needs? How long did the database take to build? Previous work can only really serve as a guide to what the developer is capable of producing and probably shouldn't be relied upon as a deciding factor.

It is important to understand that each database will also be a learning experience for the developer. However organisations will also need to guard against developers that seek to "experiment" with database projects in order to increase their own knowledge and learning at an agency's expense.

Ensure that the developer understands the needs of the voluntary sector

This is pretty crucial - particularly when it comes to finances. Money for the database project may only be available in stages over a specific period during which it must be spent - going over time may not be an option.

You may wish to think about how to construct funding applications to best meet the requirements of a big development. A developer that normally works with for-profit businesses may not understand the funding structures in the voluntary sector. For example the amount of money available for a project will be comparatively small, once it runs out there is unlikely to be any more - going over-budget is definitely not an option!

Make sure they are someone you can work with

This may be difficult to assess - you may perceive the developer as someone you can work with because they give you all the right signals before they get the contract - once the job has been secured however things might change. This can sometimes be an issue particularly with larger set ups. Hopefully your previous conversations with referees will help you build up a picture of what it's really like working with a particular developer.

Other things to consider include whether they can explain things to you in language you understand, or whether they overwhelm you with technical jargon.

Ask questions about how they will manage the project, and what methodologies they will use (if any) at the interview stage. The developer should be willing to give you a timetable for completing the project. You should make sure this fits in with your needs, but be very realistic about what can be achieved in the time available. If a developer has a lot of other work on, you'll need to be convinced that they have the time to fit in work for your organisation as well.

Determine what support will be provided once the database has been built

You will inevitably need ongoing support for the database once it is finished so the developer needs to be retained for a period after the database has been completed.

It is important to find out early on how much after-sales support and / or training you'll be getting for your money, and what the limitations of this support might be. For example, support may be for a limited time, or for a limited amount of work to iron out any problems, or relatively minor tweaks to improve the database.

It is also important to specify what if any user manuals or other documentation will be included as part of the agreement.

Find out how the developer charges for their work

Some developers charge by the hour - avoid getting locked into hourly rates, as it is much harder to estimate what the final cost will be. Go for a developer that will give you a price for the whole project and who will accept payment in stages according to agreed deliverables.

Once you've chosen a developer …

Once you have selected a developer, you will need to draw up an agreement about how the project will proceed. The agreement may be in the form of a letter or a more formal written contract but it is worth remembering contracts can be difficult to enforce and won't necessarily be of much use if relationships break down.

The project should be broken down into discrete chunks (work packages) with milestones for completion. The agreement should specify sign-off and payment schedules linked to these milestones.

The first stage will be for the developer to produce a functional specification from your requirements document. The functional specification will include examples of what data entry forms and reports will be produced for the database, and some sample screens. Only if the functional specification is OK will you give the developer the go ahead to do the rest of the work.

Database development is a complex and dynamic process, new ideas may come up half way through the project but there may be no extra money available to implement them - you will need to be both flexible and pragmatic. The development phase should also be split into stages. Only move onto the next stage when the previous stage has been completed.

Sound management arrangements are essential if problems are to be avoided. It is worth considering how you will deal with any problems before they occur (including having some agreement on how disputes will be resolved should they arise).

The contact person within the organisation should be clarified and good communication systems and regular reporting meetings set up. Any risks should be identified early on and carefully monitored.

Once the stage-by-stage development has been completed, the database will need to be tested and any "bugs" in the program identified and sorted out.

The next phase is to implement the database. This includes installation, training, support, fault logging, and planning the next version …

Summary

Getting a database built is a challenge for both the organisation and the developer. It's helpful to break the process down into several stages:

• Preparation (deciding what you want, business case for funders and management committee, indicative budget, outline timetable)
• Selection (tendering - writing an ITT and sending it out, interviewing, decision)
• Contractual discussion (timetable payment schedule, communication and project management arrangements)
• Development (starting with the functional specification and sign off, followed by stage by stage development, testing, debugging)
• Implementation (from installation, training and support to planning the next version)

Having a good understanding of the issues involved, being thoroughly prepared, and adopting a step-by-step approach to the whole process of database development should help ensure that your organisation ends up with a database that strongly matches its needs.