Databases > Planning A Database

Working with a database developer - a developer's view

By Margot Lunnon

Getting a database developed from scratch is a major undertaking. Freelance database consultant Margot Lunnon gives a developer's view of what is needed for a successful working relationship during the database development process.

As one who has been doing database work with voluntary and public sector organisations for over 15 years I write with experience and feeling.

I look back on databases I have built with a mixture of reassurance and shame: they were really not bad, but some of them could have been a lot better.

Different developers work in different ways. Some of us like to visits clients fortnightly to show what we have done and solicit feedback; this strengthens human relationships and the users' commitment to the database, but is time-consuming and hence expensive. Others let longer intervals elapse before visiting with a more fully developed version.

The central ingredients, in my view, are these: clarity about requirements, the right liaison person, an organisation that holds together, and realism about the scale of the undertaking.

Clarity About Requirements

One big factor is whether the database being commissioned is the first one the organisation has had.

If it is, they will be working in (relative) ignorance of the pros and cons of databases, and we both know they will get a better job when eventually they are ready to commission their second database.

On the first database, they will to a large extent be relying on me to brief them about what the database can / cannot / should / should not be expected to do. I will do my best, but I work better when there is informed feedback coming to me from the client.

My own preferred method, where the database being built is the first one, is largely to mock up something for the client to comment on. One reason for this, as opposed to a statement of needs to which I have not been a party, is that none of the crucial terms is unambiguous. I have heard even specialists talk about records being sorted when I would have said they were being selected. I have had clients talk to me about outputs when I would have called the statistics being produced performance indicators. If there is something on a screen to look at there is less scope for misunderstanding.

However, not all database builders will take this line; many will use examples of their own prior work to help the client build up a specification which they can then go away and fulfil, not returning to the client until there is a fairly well-behaved first version for them to start using.0

What is really not on is to build a database when the client is not familiar even with the work which the database is to support. This can happen when a project is very new. In such circumstances I would recommend them to buy an off-the-shelf package which is in the right ballpark for their work, spending as little as feasible (by which I means hundreds of pounds rather than thousands) and using it as best they can for the first year while the work settles down.

The Right Liaison Person

A major factor if not THE major factor settling how good the final database is is the client contact I work with most.

The best person I have worked with was an office manager who loved messing about with Access. His organisation had had a database for some years, so he knew what Access could do; he also knew his organisation well and his records inside out and backwards. He was also trusted by his colleagues and had good social skills. His approach to me was always to imply that he believed I could do a better job with the database in any particular respect if I put my mind to it.  When the database misbehaved, he was willing to try a process of elimination to try to isolate what might be going wrong. For him I tried and tried and tried!

A more typical example, perhaps, of the good liaison person was a young woman at an umbrella organisation. There I did not at first have a formal liaison person, and relied unwisely on a committee member who knew the work of the organisation and also knew what computers can do, but who was in some respects mistrusted by the staff.

When we all concluded this was a bad idea, the organisation chose for me an admin worker, a person who knew the work of the organisation and was trusted by her colleagues even though she was very junior. The support from her senior colleagues was of course crucial; nothing is more demoralising fro a developer than knowing that the top brass neither know nor care what is going on. She liked computers and had a feel for what they could do; she had very good social skills and again was able to imply to me that of course I could find a solution if I wanted to badly enough.

A less satisfactory organisation, from my point of view, set up for me a liaison group, which met roughly fortnightly. I never knew who would attend; it included people from three teams, of whom only one was an admin worker and one a team leader; the IT support person for the organisation was part time and was not a member; messages routinely failed to get through from the person I told to the person who needed to know; and so on.

A project on which I look back with shame, and blame to some extent myself, was one where the database was meant to generate statistics which the client organisations could hand on to their (shared) funder. Only at the very last minute did the clients get the message across to me that the statistical reports they wanted must be in precisely the form that the funder demanded; they did not want to have to do any compilation whatever. Given that none of the three organisations had conveyed this to me earlier, I can only think I must somehow have been making it impossible for them to tell me.

To sum up, the liaison person needs to:

• Be trusted by her colleagues and be able to get cooperation from them
• Have a feel for what computers can do
• Have the social skills to coax the developer into more and better efforts
• Be methodical.

An organisation that holds together

I have more than once built a database for an organisation where, in the end, the proportion of what I built that was actually used was, let us say, two-thirds.

Keying into a database is boring and time-consuming; the staff involved will either have to think it worthwhile in terms of the yield it gives them, or their managers will have to motivate them to do the keying. Had my clients been more realistic about the keying they were prepared to do, they could have had a more modest database that cost less, or one where the extra effort went instead into making it more foolproof.

I sometimes liken organisations to a series of pistons; it ought to be the case that the amount of shove you put in at one end is equalled by the amount of effect you get out at the other end. It never is; but sometimes the lost effort seems large. One organisation delayed confirming my contract for several months while they made a decision about buying new equipment. The contract then ran for about five months, but the new equipment was never bought. The organisation lost a major grant in the midst of this time, and it was agreed that a sensible fallback would be to get better screens and more memory for the existing machines; but this never happened either. Meanwhile one team whose grant had not been cut did get new machines, and consequently got a later version of Access.  I said I did not want to support two versions of Access, but some while later the organisation was still running two versions of Access and could not say when this would change.

Realism about the scale of the undertaking

Anyone who follows the press will appreciate that very many database projects (in all sectors) fail altogether.

In the voluntary sector, the sums of money involved are less than salaries but more than most other things; and if staff time were calculated in the failure, cost would be double the seeming bottom line.

An organisation that does not want to be a party to such a failure must appreciate the scale of what it is taking on.

On more than one occasion I have won a contract in competition with others because I have appeared to be the person who could start and finish first. In the case I am thinking of, I started work in the particular May, saying that the database could be finished by August. In the event, it was declared finished the following April.

I held things up to some extent; the principal cause of the delays was staff unavailability to test the various aspects of the system. This was not for the most part a case of disinclination, but there were holidays and workload issues…

At the end I said to them "If I had told you at the outset that this database would take a year to do, would I have got the contract?" They replied, "No."

If an organisation can say to itself, "This big database is going to take a year to develop and is going to involve work all along the way that will never seem to be the most pressing thing to do", it would get a markedly better outcome. Having prepared themselves for a long haul, they could be more patient and persistent with the effort involved, be unworried about temporary failures, and could recognise real gains when gains occurred.