Why Database Implementations Should Not be a Democracy

 

I fully believe in democracy - except when it comes to implementing databases. In which instance, one needs more of an approach of meritocracy with a touch of geniocracy but with a democratic input. (And maybe even some technocracy, which I never even knew really existed until I started researching this blog!).

But enough with the 'ocracies. What I am really saying is that there needs to be nominated, manageably-sized teams who are involved with and run database projects. When I hear of a project where everyone is trying to get involved, especially at the very top level or at the level of Subject Matter Expert, then I worry that is a recipe for disaster.

Why? Because when decisions need to be made, which they do all the time in projects, you need key people who are decision makers and who, yes, can take input and advice from other people, but who do not rely on waiting for lots of other people to actually make the decisions.

And if all this sounds like common sense to you and you are wondering why I am bothering to write this blog then fantastic! You can stop reading now! Unfortunately, in my experience, this is not always the case…

What you do need
You need a top-level Project Board (aka steering committee etc) but that needs to be a small group of key, high-level individuals who have the power to make decisions. And yes, you need input from Subject Matter Experts who already do the day-to-day work on the existing database(s) and who can provide the detailed input into what is needed in the new system.

But what you don't need and shouldn't have is a large team at either of these levels. That just won't work.

Have a large team at the top and you'll just get in-fighting, no decisions being made, or being made very slowly, and potentially a watered-down system which tries to cater for everyone by not being good enough for anyone. And it will almost certainly take much longer and cost much more…

And you certainly don't want so many Subject Matter Experts (SME) that you never get agreement on what people do or what they want to do. There can't be that many "experts". Build a hierarchy here so that we maintain the democratic input and the SME (or few SMEs) of each team can get input from their team members but when you hold design sessions, the SME can bring all that knowledge to the table.

In terms of the 'middle layer', what you need is a manageable project team who can do the day-to-day work on the project, with a strong project manager. I'm tempted to say that this too shouldn't be an uncontrollable size or that will get out of hand and everyone will abstain from responsibility. But in practise, at least in the NFP sector, it is a rare project that has too many people on a project team!

But don't try to make it a full democracy at every stage.

Unfortunately, many database implementations appear to be run as a kakistocracy. It's a real word - look it up if you don't know it; then you'll understand what I mean.