We use cookies to help us provide you with the best experience, improve and tailor our services, and carry out our marketing activities. For more information, including how to manage your cookie settings, see our privacy notice.


Skip to content. | Skip to navigation

Community-made content which you can improve Case study from our community

How to plan a good database

All organisations are required to collect information on a wide range of activities; it often feels like we spend more and more time processing data than delivering the activities. However with a good database or CRM (Constituent Relationship Management) system in place this task wil be made simpler and the data it provides will be more powerful to you.

Always start with a good plan and be very clear about your requirements. Be sure of the questions the database is designed to answer. The best place to start is actually at the end - ask yourself what you’re trying to find out, what your database can tell you and how it will help your work.

Get the process right first, then the database suppliers and systems can be selected later. Our How-To guide on choosing a database supplier will be useful in this process.

Things you'll need

  • Existing data and information needed for the new database.
  • Agreement about the reports and data files that the system will produce.

Set aside enough time

Whether it is a member of staff, volunteer or consultant leading the project, the amount of time taken for planning is often underestimated. Before you get to the technical details, you need to think through the commitment you’re making and be sure you have the budget and support you need.

Be realistic about the time needed to co-ordinate the initial planning process and collect information about the needs of those who will be using the database. This includes:

  • staff time to develop the database plan
  • the cost of buying or building the database
  • cleansing and preparing data to be uploaded to the new database
  • entering data from manual forms or transfering from an exisiting database
  • staff time to test the database
  • training staff to use the database
  • time to manage, maintain and productively make use of the database.

Budgeting for a new database

Start by identifying the problem that needs to be solved and the benefits the database will bring, such as saving staff time, improving the quality of service, or delivering monitoring information to funders. The value of these potential benefits will help set an initial budget, which can then be modified as you talk to suppliers and contractors. Speak to people from other organisations to see whether you have got the figure about right.

The process of agreeing the budget is the opportunity to make sure you have the clear support and involvement of senior management and trustees. Developing a new database can’t be seen as simply a technical issue – it is likely to affect the whole organisation and it needs senior-level support. This top-level focus will be vital once the development process becomes more technically driven.

Be clear what the contract with the supplier includes and doesn't include. Ask them who owns the data and reports you have developed. Check for any hidden charges in your subscription should you need to make changes in the future to a field or add a new report.


What to include

A database plan is the starting point for building your own DIY database, or will be used as the brief when approaching a database developer or supplier. Its main purpose is to summarise what you require, and it should be written in plain language with any technical jargon either avoided or explained.

Spending time on the planning process ensures that you have a clear idea of the type of database your organisation needs, can afford and is able to support. A simple plan should consider the following points and questions:

  • Current position
    Your organisation's overall objectives, a review of what you already have, how you currently collect information, reports you produce and the benefits a new database will offer.
  • Information flow
    Determine what data you need to collect and who collects it – including partners. Ask who requires reports and what reports do they need. What are the on-line queries you expect to make of the data and information held on the database?
  • Timescale/budget
    Your initial estimate of timescale and budget will become more and more accurate as the planning process continues.
  • Who is involved?
    Who is leading the project? Who will use the database? Who will maintain it? What skills do they have? Include staff, volunteers, partners, other suppliers, etc.
  • Hardware and software requirements
    Any limits created by your current set-up, such as the age of the computers, or whether they are PCs or Macs, and whether they have Windows or Linux installed? Do you have a network, or any remote workers? Is there a budget for upgrades? Should you adopt a on-premise database on your own server or use a cloud-based database provider?
  • Data Cleansing and Migration
    Is all the data you need in a machine readable form? Is it accurate and up to date? Will a data cleaning task be needed? Agree a comprehensive procedure for transfering data into the new database.
  • Training
    Which staff will need training in the use of the system? How will training be delivered?
  • Support
    May include installing upgrades, adding new features or troubleshooting. Suppliers or developers may offer telephone support, but charge extra for on-site help. If you are building your own system, who will be available for ongoing support? Do you have a warranty period to resolve any monor glitches you encounter?

Good project management

Being thoroughly prepared and adopting a step by step approach to the process of database development should help you end up with a database that meets your needs:

  • Preparation
    Decide what you want, prepare a business case for funders and your management committee, agree indicative budget, outline timetable and the scope of the project.
  • Selection
    Write an initial project plan as a brief for the tender process, and use interviews to select a contractor. Talk to other organisations who already use the database to hear their opinion.
  • Contractual discussion
    Agree what will be delivered when, payment schedule, project management arrangements, roles and responsibilities, and dispute processes.
  • Development
    Functional specification is agreed and signed off, stage by stage development, progress reports, testing, debugging.
  • Implementation
    Installation, data migration, training and ongoing support.
  • Review
    Lessons learned and plans for the next version.

Further information

Useful guides for extra reading from Idealware

Data Migration - What is involved and how to manage it.


Page last edited May 12, 2019 History

Help us to improve this page – give us feedback.