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.

No More Chinese Walls

 

Sometimes, users will tell me, "I'm happy for my contacts' records to be held on the database, but I don't want anyone else to see them. At all." Which rather makes my heart sink - as this almost completely defeats the object of having the records on the database in the first place. It’s a scenario known as a "Chinese Wall":  And I don't want to have to climb it.

To clarify, a Chinese Wall means that if, say, the Celebrity department are managing Richard Branson, and thus they obviously need to access his supporter record on the database, if the Community Fundraising team were to search for Richard Branson then they wouldn't even see that his record was on the database at all. Period. To them, he doesn't exist on the system full stop.

The problem with this is several-fold
These are just some of the issues with this:

• First, if the Community Fundraising team do have a genuine reason to need to view/add data about Richard Branson, then if they don't know he already has a record on the database then they will add a new one - a duplicate record.
• Secondly, both teams, including the Celebrity department, will be none the wiser that the other team has or is building a relationship with the charity. This can clearly lead to all sorts of problems, from multiple communications, multiple asks, embarrassment, DP issues and so on.
• What if the Corporate team then look at the Virgin Group's record. Are they allowed to see that Richard Branson is the Founder of Virgin? One would presume so. But if they then try to click-through to his record, they'll find they can't. Is that a good thing? So will they keep information on Branson on some other part of the Virgin record?
• What is Mr Branson phoned Supporter Care for some reason, and they couldn't see his record or his interaction & involvement with the charity? And yes, okay, I realise that specific scenario is unlikely but other VIPs etc might well do.
• Or what if someone else in the charity is going to meet his spouse, who may not be managed by the Celebrity department? Are they allowed to see Richard Branson is married to her? Surely yes; but then… [return to above…]

I know some teams who "own" records like this say, Oh, well, all the other users have to do if they come across Branson is come and talk to us. But that of course presumes everyone else knows Branson already has a relationship with the charity, that they will do that, that they can be bothered to do that, that someone in the Celebrity team is available to talk… And okay, Richard Branson may be a well-known person in the charity, but what about the other celebrities/VIPs who are not? And if a Chinese Wall stretches to cover us more common folk then this doesn't even bear thinking about.

So what to do instead

When this request does happen, I try to dig further to see what the user really means, and usually it is one of the following points:

• I don't want other users to contact my records; and/or:
• I don’t want other users to see sensitive information about my contacts.

Both are potentially reasonable requests, but in both instances there are better ways to address the issue than just completely blocking access. I say "potentially" because the first point above, that you don't want someone else to contact your records, is something I bang on about a lot. Firstly, they are not "your" records - see my other blog on that - and secondly, if everyone in the charity does agree that you are the best relationship manager for such contacts then that still doesn’t mean that you should blanket stop other people from seeing such records.

Instead, for both instances, the first thing that can be done is that the record can be flagged as such, with whatever appropriate code/wording which will help everyone in the charity understand the relationship. And ensure processes are in place to manage that.

Secondly, protecting sensitive information such as Richard Branson's giving history or personal phone number, is clearly an important point, but what the database should do is still give limited access to such contacts' records so that other people can see they do exist on the database and understand the relationship, and simply block the sensitive information so that only those users who should be able to see it can see it. That's a far more effective and open approach.

This is my belief anyway.

The only walls I want to see on a fundraising database are Kim Wall, Roger Water's Wall, Max Wall, Wall's Ice Cream… [that's enough Walls - Ed].

But no Chinese Walls thank you.

Data Dictionary Example Content

 

Following my last post on why a data dictionary is so useful, I have provided below some specific information you might want to store in a data dictionary. For a simple dictionary, you probably don't need to record everything listed below (although for larger systems you might even want more?) - it of course depends on your specific needs and issues. But hopefully this is a good start.

Fields - broken down by "area" of the database or by table

(e.g. if you are using a traditional fundraising database, then you might break it down by screen; if you have a bespoke SQL database then by table. Whatever makes sense and means you can find this information simply later on).

• Data element name
• Field name
• Field label if different
• Description/Meaning (in English, not technical)
• Active? (i.e. is it still being used or is it just historic data)
• Data Type
• Data source (e.g. if it uses a Lookup table - cf below)
• Max/Min length
• Default value
• Mandatory?
• Unique?
• Hidden?
• Calculated field? (e.g. Age, Total Donations)
• Causes dependency on
• Dependent on
• Other Business Rules/validation rules
• Security notes
• Primary Key/Foreign Key - if appropriate for more technical requirements

Lookup Tables

aka Drop-down lists, picklists, reference data etc.

• Table name
• Description/Meaning (in English, not technical)
• Field(s) where it is used
• All values - cf below

Each value in a Lookup table

• Value
• Meaning
• Active? (i.e. is it still being used or is it just historic data)
• Causes dependency on
• Dependent on

And possibly other similar attributes to the Fields above

You can of course add Entity Relationship Diagrams (ERDs) which can be very useful and show the relationships between the tables.

Why a Data Dictionary is So Useful During a Data Migration

Whilst working recently on a long, rather drawn-out database implementation and data migration project, it became clear as to how useful a better data dictionary would have been for the project. And if you are unsure what a data dictionary is, then the definition provided by the IBM Dictionary of Computing (via Wikipedia) is a good one: "a centralized repository of information about data such as meaning, relationships to other data, origin, usage, and format."

Why? Because on all projects, and especially the longer, more complex, larger ones with multiple team members (and team members who may join half way through), someone somewhere will eventually ask about your current system with questions such as: What does this field do? What does this value mean? How does this field relate to that other table we have? And so on.

And if you have a data dictionary then you can answer that! Sounds simple, and it is (if time consuming), but you might be surprised (or maybe you aren't…) at how few organisations have such a document. You will also continue to find it useful once you are up and running with your new database - it's not just for data migrations - e.g. for reports, trainers, integration projects, development projects, for new database managers and technical staff etc.

So if you haven't got a data dictionary, then as soon as you start a new database project, even at the stage of requirements gathering, business analysis, investigation phase and the like, start one. And if you have got one, check and update it. It will save you a whole heap of time later.

And if you haven't created a data dictionary before then in my next post, I will provide an example of the sort of elements you could store in one.

Does it matter if a Fundraising database supplier doesn’t understand Fundraising?

The more I work on fundraising software procurement and implementation projects, the more I ask this question: how much does the supplier's experience of fundraising matter?

For years, this hasn't been such a relevant question, at least when purchasing packages as opposed to bespoke systems, because most new fundraising database systems were supplied by companies who either specialised in the sector or who at least had a dedicated department who did so. Of course one would find companies and individuals with more or less knowledge or experience but nearly all had some. And also you could see the evidence of some of their claims with their software.

But now with the prevalence of the newer CRM systems, this is a more poignant question. Now, in theory, any company who sells Salesforce, MS Dynamics and the like, can at least promote themselves as a partner who can provide a fundraising solution. So does that matter? What are the problems with that? Or actually, are there even benefits of using a supplier with less sector knowledge?

The reasons that a supplier's knowledge does matter are comparatively easy to identify:

• Charities are different to commercial organisations. That might sound an obvious thing to say, and in some ways it isn't 100% true for fundraising - after all, we're managing contacts, building relationships, running events and "selling" in the same way as a business is, just philanthropically. But there are of course many distinct differences and approaches - and one of the most significant is that several commercial CRM suppliers I have worked with have been amazed at the sheer breadth of activities which charities manage in comparison to their size. And thus their internal complexity increases. This isn't always a good thing of course, but it's a fact.
• Any supplier in any sector who can bring experience of working with your peers will surely add something to the project. They won't just be implementing software, but should be able to suggest ideas and approaches that have worked for other charities.
• You don't have to explain what Gift Aid is, how direct debits work, why relationship fundraising is important, who JustGiving are and so on. They will know that already. And why should you have to pay a company to teach them all that?!
• They won't try to take you down a route which isn't right for a not-for-profit organisation, or overly try to enforce their concepts from other sectors which they might believe are right but which they don't actually have experience of doing in the NFP sector.
• Many of the traditional fundraising database suppliers have ex-charity employees in their implementation and support teams, and that can be a great benefit as they can bring real-life and hands-on experience of using that system.
• All this should hopefully increase benefits, reduce risk, reduce the project timescale and as a result, keep costs down.

That said, one would hope that any company who understands CRM, has good business analysts, can empathise with your organisation and bring great technology skills should be able to manage a lot of the above even without specific fundraising sector knowledge. And in some instances that can be true. Sadly not always, but sometimes.

On the other hand, I also have to say that one of the great things which has happened primarily as a result of the newer, generic CRM systems now flooding the charity sector, is that we are getting a whole new view and different insight into charitable activities. I have been saying for years how insular we can be as a sector (myself included on occasions!) and so surely I should celebrate newer entrants with fresh thoughts and ideas?

So what can a company with less fundraising experience bring to the table?

• They can challenge a charity's pre-conceived ideas that the only way to do something is how they do it now. Okay, a fundraising-knowledgeable supplier should be able to do the same, but as more of an outsider, a company with less knowledge can ask what might seem like basic questions - and some may well be! - but some might just make us think that little bit differently and hence start to get a whole new advantage in an area.
• They will bring good business practises which some of the sector may not have followed before.
• They could bring commercial ideas to the table. This may be something of an anathema to some organisations, but for others, it might even help fundraising.
• They will have a wider knowledge of multiple sectors and industries, and be able to provide input in all sorts of ways which we might never have thought of before. I have always thought that the fundraising technology sector should be able to learn more from other businesses so this is an opportunity to do so.
• They should - the ones you invite as a possible supplier - "get CRM". And that's definitely a good thing.

My Conclusion

I am a bit torn. I already embrace new CRM systems into the sector and I really want to embrace the suppliers with them. And some are good - some very good. But some have their issues too.

Not that the traditional fundraising database suppliers are perfect - I've worked with enough to see holes and problems with their approach, fundraising knowledge and understanding of technology.

But on balance, I still need to be shown by any "non-sector" supplier that they do know, have knowledge of or can learn about fundraising and the charity sector. I will always remain open and encourage suppliers to provide that to my clients and me, and if they can do, fantastic, they're in the melting pot. But if they can't then I need to question if working with them is going to help or hinder the fundraising database implementation.