Why disability databases are like fur seals
Need a fundraising database? No problem. There are plenty on the market to choose from. Ring around a few mates and you’re likely to find the same names popping up again and again. From the time you start thinking about a new fundraising database, to having it installed with all your data converted you could have given birth to a sheep or a goat. In less time that it takes for a human baby to grow you can have your fundraising database safely settled into it’s new nursey.
Yet there are two sides to most not for profit Organisations. The funds and the services. If a database for your fundraising team is as quick as having a goat, how long does it take to get one for your client services department? In my experience, 9 months can come and go and there’s still no database. That’s right. If you’re planning on birthing a client services database, then start making friends with fur seals, giraffes and elephant mothers-to-be as these will be in your mother’s group. I hope for your sake that it isn’t as long as the elephant (22 months).
Part of the problem here is that there are no usual suspects. Ring around other Not for profit Organisations and you will probably hang up empty handed.
Of course, I’ve made a huge assumption here. I’m thinking that fellow charities must be using a database to track their service provision. In your quick ring around and you may find out that the ‘database’ is the paper file. The ‘database’ is a few excel spreadsheets. Or my personal favourite, the ‘database’ is something that Jane’s husband made up in two days in Access because Jane’s husband is ‘good with computers.’ Does anyone know how to change it? Yes – Jane’s husband does. Oh great. Let’s hope Jane and her husband never get a divorce.
A year in the making
So where’s the good news? I thought I had it. I thought (stupidly) that because it took twice as long to implement a client services database that it meant it would all go twice as smoothly. Twice as long means twice as good, right? Wrong!
The issues of data quality that exist with most fundraising database transfers weren’t going to plague me. After all, we had hardly any data as it was all in those paper files.
The data quality curse
Yet it seems the data quality curse knows no limits. The same curse which causes your fundraising team to put Mr & Mrs Jones on one client record, infects the clinical department as well. I’m hoping that I have the power to stop it before it gets too bad but the signs are all there.
Take this simple example. The humble look-up list. When you open your fundraising database and pull down the ‘Title’ field, if it’s been through multiple data conversions without a data tyrant at work, you’ll have an abundance of choice. In addition to the usual Mr, Mrs, Miss and Ms, it’s likely you have Rev and Reverend, Sister and Sisters, Mr&Mrs, Mr/s, Householders and my favourite Mr 7 Mrs (where someone forgot to press Shift for the ampersand).
In the case of Title, there are standards. It’s easy for a data monkey to come up and fix them all up, however what does one do for diagnosis? Or disability?
Other. It’s the answer to everything. When you just can’t decide, go with Other. If I had money for every time someone had asked, why can’t we just have Other and then write what it is, I’d be buying a house with a pool big enough to house a fur seal.
To be fair, some of these things aren’t easy. While there is an Australian standard for language and country of birth and ethnicity and god knows what else, there is not one of recognised ‘disabilities’. Or at least not one I can find. (For anyone looking the best I can find is a list from the Department of Family and Community Services of conditions recognised as eligibility for the carer’s pension. And if anyone has found one on the Australian Bureau of Statistics, or elsewhere, please send me a link!)
Another little trick the data quality curse has up it’s sleeve, is the multi-talented data field. This is a little like a bunyip, a yowie or a yeti. It must exist as people talk about it but I’ve yet to see one! It’s that field that magically transforms itself as the user’s will. When people don’t feel like typing a date, it undergoes a metamorphosis and becomes a text field. Just the other day we were having a discussion about when we should enter a date and someone came up with an ‘exception to the rule’. As it was a date field, their usual request of Other was null and void. Instead they called in the multi-talented data field and suggested they just put an asterisk after the date. Never mind that a date field doesn’t allow such deviation… the multi-talented data field lives on and intuitively changes itself to allow such a thing. Pity it doesn’t also create a data dictionary definition which explains what the asterisk actually means.
But there is one more trick the data quality curse has up its sleeve. Worse that ‘Other’ in look-up lists and data fields which can magically transform themselves from date to text is the third weapon in the arsenal. The shoehorn.
This has to be one of the most used and most spectacular methods of creating a big data quality issue. It’s when you don’t have a home for something in your database, so you find another field you aren’t using and you shoehorn the data into it. This is common when Jane’s husband built the thing and now he has run off with the massage therapist to outer Mongolia and no one knows how to change anything. This is how you end up putting the mobile phone number in the medical record number box. Or the word deceased in the title field as he forgot that us humans are mortal. And if you’re looking for the name of the next of kin, try location. Obvious really.
Posted on June 24, 2012, in Data, Disability, Fundraising, Not for Profit and tagged Charities, Data cleansing, Data quality, database, fundraising, Nonprofit organization. Bookmark the permalink. 2 Comments.