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.

We’re going to unsubscribe you, unless...

I received a clever email today (at least, I think it's clever!) which has the subject line, "We’re going to unsubscribe you, unless..." At first, because the subject text drew my eye, I thought it must be spam, but then I looked at the sender and realised it was from the British Library (BL), who I am a subscriber to. So why was it clever? Well I think it was smart because of the following:

First, interestingly, "mild panic" set in. (Well, okay, not quite panic, but you know what I mean). What was I going to be missing?! What was I about to be unsubscribed from without me knowing? So I opened the email. And once my heart-rate had returned to normal, I realised it was the BL informing me that because I hadn't opened one of their regular emails for some time, they were going to unsubscribe me unless I specifically clicked on a button to remain subscribed. And I quite liked that. It made me wonder initially why I wasn't opening their emails and if I did really want to continue to be subscribed. So I clicked and did re-subscribe.

Why even do this?
Now, I guess some people might question why the BL bother doing this. After all, each email only costs a few pence to send so why not just keep me on the list. After all, one day I might open it and take some action. Which is how I know many fundraisers see such email lists. The more names the better. Never mind if it isn't really what the supporter is interested in reading anymore, and never mind that the open rate is 0.00-whatever. Just keep sending everyone the emails just in case…

However, personally, I think this is a great exercise in promoting supporter choice, which is something I quite believe in. Surely it makes more sense to only be sending emails to people who want to receive them. Surely it provides a better ROI - after all, even if each email only costs a few pence to send, thousands of such emails will add-up each time they are sent, and they are likely to be sent many times during the year. So the total cost will add up.

And, by getting people to re-confirm their subscription, by definition you have someone who has taken a positive action to remain interested, and that in itself could be an interesting segment to approach. Now you know something more about them. Maybe you could send them an initial "welcome back" email with a particular message or options to take? Maybe they could be allocated a different customer journey? As yet, I haven't received anything like that from the BL but I will wait to see. (I was also slightly disappointed that the email click-through was to a generic page on the BL website rather than a 'Great, thanks for doing that - now have you thought about…' type page).

The Technical SideOf course, to do this, it takes one critical technical thing: an email marketing system (EMS) which can monitor if someone doesn't open an email; and alongside that, a database - whether within the EMS or in a separate CRM - which the marketers can query in order to find out which people they should target with such a message - which people have not opened x emails within the last y months/campaigns etc. And of course, a database where, if I am subscribed to several different emails from the organisation, then it needs to be able to not blanket unsubscribe me but just opt me out of this specific email campaign.
It’s a great example of the digital world with a smart database and with some savvy marketing users coming together to try this out. Kudos to the BL.

Is there any place for the Long ITT anymore?

 

The short answer
No.

The only slightly less short answer
No, except when you have to, such as OJEU or similar requirements.

The Full Answer
Okay, let's address this question properly. First of all, what do I mean by a "Long Tick-box ITT"? Well, pretty much as it sounds: it's when you devise hundreds and hundreds of questions, mostly about functionality, and ask suppliers to respond to your Invitation to Tender (ITT) document by asking them to tick a box which says if they can meet that requirement. Often, this will be a MoSCoW method (or similar): Must have, Should have, Could Have, Won't. (Never underestimate how much IT loves its acronyms and pseudo-acronyms). And then sometimes one asks if they can do it 'Out of the box' or 'with customisation' or 'not at all' - or similar. Thus, the suppliers tick these boxes, you add-up their scores, sometimes weight the questions with more/less importance and hey presto, we have a winner. Or at least a short-list which you can then invite in for a demo.

But it's really not as simple as that. In the first place, suppliers have been known (shock horror) to stretch the truth when ticking boxes and interpret a question so they can say yes they can do it when maybe they can't really... And in some ways, that's understandable as writing such questions so they are non-ambiguous can be difficult.

Plus, completely understandably these days, 'generic' CRM suppliers can probably say with (almost?!) complete honesty that they can do all almost all of a CRM ITT's requirements because their systems have been designed for exactly that flexibility. But that still doesn't mean they are necessarily right for you to buy.

And it doesn't tell you anything about how they would do it, or if they do it well, or if they understand the question and so on. Okay, so some of that can be addressed at a software demonstration but by that point you may have knocked out a good option (supplier) without knowing it, or you might find a supplier is actually completely inappropriate for your organisation or requirements. It's just a non-efficient method.

In fact, the time it takes for this whole process is a looooong time. A long time for you to create the initial document, a long time for the supplier to answer and a long time for you and your colleagues to read all the responses and mark them.

Couldn't there be a better way of using your time? In my opinion, yes. Personally, when I help charities with a procurement, I prefer more 'open' tender documents (aka RFP - Request for Proposal), asking for more expansive responses, possibly with the inclusion of process diagrams and a more interactive approach with the suppliers all round.

And I'm not completely against including a few lists here or there in the RFP of specific requirements which you must have - especially where they are especially important. But I don't ask suppliers to tick each bullet point.

Clearly, there is a lot more to the whole procurement process than just the above - but super-long ITTs? No, not for me. I don't think they help you select the best supplier for you. Which is ultimately what you want.