Download How to plan a good database

How to Guides
How to plan a good database
A good database will always start with a good plan. You need to be clear about the questions it 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.
1 Budgeting your 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
staff time to test the database
training staff to use the database
time to manage, maintain and use the database
2 Budgeting
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.
3 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 and either avoid or explain any technical
jargon.
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 would include:







Current position
Your organisation's overall objectives, a review of what you already have, the benefits a new
database will offer
Information flow
What data you need to collect and who collects it – including partners. Who requires reports
and what reports do they need.
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? Includes 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?
Training
Which staff will need training in the use of the system? How will it 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?
4 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.
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, training and ongoing support.
Review
Lessons learned and plans for the next version.
Source:
This how-to guide was created by Max Wellings This guide has also been edited by KHNP member, KHNP
member and KHNP member
Date: 20th December 2013