But I only wanted a database?... It’s a bit more complicated than that….

"Very well, Sir. Our takeaway databases come in 3 sizes:  Ultimately frustrating; Soon to be chaotic;  Complete and utter disaster....

“Be careful what you ask for. The prescription might be more than you anticipated.

"Good morning, I would like a database please! And can I have it to take away as I'm in rather a hurry." 

“Very well Sir. Our takeaway databases come in 3 sizes:

·         Ultimately frustrating

·         Soon to be chaotic

·         Complete and utter disaster....”

The means to justify the ends

Does your organisational report card read like this?

“Works hard, lacks focus, can't demonstrate progress.”

Do you remember the days when you could buy a database off the shelf and all you needed to worry about was whether it differentiated home and work phone numbers?

In these days of increasing transparency, performance management, complex stakeholder relationships and on-demand reporting, your data needs far more TLC ('tender loving care' – you don’t see that in a data dictionary very often). To give it that TLC, data needs a good home and that home is your database.

·         “Now sir. What's your data for?”

·         “I don't know, I just collect it....”

If only there was a better way…

Well there is, but be careful what you wish for...

The ingredients of a good database (and how to make it come to pass)...

Business analysis and process re-engineering – the secret to a successful database lies with a good business analysis. Mapping and then optimising processes, understanding why you do what you do and whether it’s the right thing to do and the right way to do it. Too often rushed, this is the firm foundation to your project. Dig deep and understand the basic pathways of how you use data to reach decisions and be a better organisation.

Planning – a database will take time, capacity and commitment. So you need to plan. Decide who will lead, what external support you need and who else does what. Create deadlines, a project schedule of what gets done when and by who. Fail to plan and you plan to fail they say. They’re right. You really can’t wing this unless you want the project to run on for years.

Data model and information architecture – what are you collecting, why are you collecting it, how does each piece/set of data relate to each other, what do you want to get out at the end of the day/month/year. Think of this as optimising data collection (inputs), data management (what you do with it) and reporting (outputs). The latter will undoubtedly be streamlined and made easier and yes, you are going to have to review those forms you’ve been using for the last ten years and work out exactly why you ask that question in box 23. After all, you don’t want all your data disappearing into a black hole. 

Technical requirements – variously called technical specification, functional specification, requirements analysis. It’s what the system must do – specifying the technical detail of the tool and the functional operation. A set of functions and characteristics of the technology which supports you to record data, store it, process it and re-purpose it. Make sure your requirements are SMART and especially specific. After all, without this how does your supplier or developer know what you want (slap on the wrist for anyone who says “because I mentioned it in a meeting three months ago”)? How do you measure the success of the system against its intended success criteria? How do you know you got what you paid for? What do you mean, you don’t do that?

Cleaning data – oh the drama! Do we really have six different phone numbers, four email addresses and three house addresses for Mrs Miggins? Which is our most up to date? Is Mrs Miggins the same as Ms Miggins or Mrs Miggggins? You’re going to have to tidy up and clean your data before it goes into your new system otherwise you’ll just pollute the shiny new tool. No, the database won’t do it for you. You put garbage in, you get shinier garbage out but it’s still garbage. This will undoubtedly take a lot longer than you expect so start early and be conscientious. Don’t just dump it on a junior who can’t say no.

Integration with other technology – “So they fill in a form on our website, it gets emailed to the admin team who print it out and type it into an Excel spreadsheet. Then they email it around the organisation at the end of the week.” Oh. My. (Substitute relevant exclamation/deity here!) Now you should have picked this up in Business Analysis whilst you were optimising processes but if not now is the time to make sure your database integrates with other tools and the requirements of how you operate. With communication tools (bulk email, texting), with your website, for remote access, for security purposes. After all, you wouldn’t drive a Ferrari down a farm track towing a caravan – yes, that is an analogy for how your systems talk to (or rather ignore) each other.

The change project – “They all said they want it so it will just work.” Oh no it won’t. “It’s much better than the last one we had.” It still needs to be managed. A database project is a change project. You need to engage users, to carry out a well planned and deliberate and effective implementation, to manage the transition. You need to address the three areas of emotional drivers, intellectual (rational) drivers and showing the way (ideally in baby steps). There’s a reason the ‘Change Curve’ mirrors the ‘Seven Stages of Grief’. Fail to plan and manage change and you’ll fall headlong down that curve and stay at the bottom. Plenty of database projects end in grief.

Training – “But everything’s intuitive these days!” Not quite. Your database is (I hope) a powerful tool. It has the capability to do great things with data (reducing those 2 to 3 days a month your admin person spent pulling together the management report). It needs to be used correctly and that requires training. Everyone will need to learn the right way to use it and how to use it well - effectively and efficiently - otherwise they will start to hate it. Then they will start to hate you. Then they will stop being effective at anything. See also ‘Death Spiral of Organisations – Going Bust Quickly But Not Quietly’.

Testing – “But it should just work.” Yes, and the sun should shine in Summer but some of us carry an umbrella just in case. You will have customised the system for you. Your organisation will have very specific ways of working. Your data will have been imported into its new home. You need to check this all works the way it was intended to work before letting too many users on it and finding it’s broken (only a bit broken but still broken). Testing comes in two flavours: system admin testing (the geeks who try to break it early) and user acceptance testing (a select group of staff who follow a test script to prove it works and then spend a bit more time messing with it trying to prove it doesn’t). If it passes the test then you can let it off its leash. If it doesn’t then fix it and test again. Rinse, repeat.

With ongoing support – The most excellently planned, brilliantly implemented database project (you did do everything I recommended above didn’t you?) is destined for failure without ongoing support. You need commitment from the organisational leaders, someone to do things and a reasonable ‘guard dog’ to make sure commitments and accountabilities are upheld. Decide where you need expert help and get it. Remember, a database is for several years not just the backend of this financial year. Like Peter the Polar Bear, if you don’t look after your environment you get diminishing returns.

A good reason – well, yes, hopefully you had a good reason before you started. This is the foundation of the database – why you need one. A database should be ‘purpose driven’ not knee jerk. It should meet specific needs. It should, in and of itself when well used, be worthy of outcomes. Buying one in a hurry to empty the budget before the end of the financial year is the action of a fool. You wouldn’t do that, would you?

Policies – oh the rules and regulations. Databases are a real opportunity for bureaucrats and detail obsessed administrators. Can’t live with them? You certainly can’t live without them! Keep it light touch. Set principles and intended outcomes alongside some specific rules and protocols. It’s important that you have a standard naming convention for e.g.  ‘University of’ but remember that the more rules you have, the more joy your users will take in ignoring them or breaking them. And don’t forget that data protection, privacy and security impose certain legal responsibilities.

Establish new ways of working – heard the one about the new database that was implemented on top of the old processes? Of course you have. You need to make the database relevant to users but relevant to the ‘new world’ not what you used to do because it was comfortable. Some things may be harder and more time consuming but there will be clear business benefits for a large proportion of staff (if not, you got something badly wrong in the analysis at the beginning).

In summary, you only need to worry about five things in a database project:

·         People – the who

·         Technology – the what

·         Processes – the how

·         Data – another what

·         Change – another how

Seriously, how hard can it be? Anyone would think you needed help and a consultant…

Dr Simon Davey is available to help negotiate leaders and organisations through the seven stages of grief - I mean change... - and to provide counselling for those who messed up the first time.

Freeman Dr Simon Davey – www.drsimondavey.com - @drsimondavey