For almost any business, collecting data is a core element of what they do. Whether its customer address details, sales figures, expenses records or stock inventories, almost every business collects and retains a significant amount of data. This applies to small traders and international companies alike, but is also just as true of the charitable and philanthropic worlds. A grantmaker, for example, may choose to record information about grant recipients, locations and amounts of money given at a basic level, but choosing exactly what to record, when and why is a more complex question. Even something as seemingly straightforward as a location can be more complex than you might think – a postcode is great, but what about countries that don’t use postcodes? You could record latitude and longitude, but that’s going to take you a while to find out. And is a grant recipient organisation always based where it does its work? Many large NGOs may be based in European capitals, but their work extends right across the globe. It would be entirely possible to support development projects in Africa, but for each and every one of your grant recipients to be based in London, Washington DC and Geneva.
These are just some of the complexities that very quickly surfaced at a workshop I attended yesterday. The objective was to help another UK grantmaker reflect on its approach to data with the ultimate goal of creating a new core data standard for use across the organisation. With multiple programmes and work that stretches right across the UK, defining ‘core’ data for them is a real challenge. What’s core for one programme may be peripheral to another and what’s legally required in Scotland, say, might be irrelevant to the organisation’s work in Wales.
So what are some of the ways in which you can start to separate out and think about these challenges?
- Commonality: Data should probably only be considered core if it is common across all your activities. If it is specific to only a handful of programmes or locations, it is not core data. It can be recorded where it really is required, but as an add-on, rather than a core piece of data.
- Obligation: In much the same way as companies in the UK need to file their accounts with Companies House, so charities and grantmakers are subject to legal regulations from other bodies. Thinking about the data that you are legally required to collect can be a good starting point for a data standard.
- Feasibility: Data that is unfeasible to collect can be discarded from the start. If it’s too time-consuming or burdensome to collect or report, don’t bother. It’s making a rod for your own back.
- Usefulness: We probably all know someone who refuses to throw anything away on the pretext of ‘you never know when it will come in use’. Yet they are the people who collect some much stuff that it is all but impossible for them to find something useful when they need it. A similar test can be applied to data – if you collect it, will you use it? If you can’t provide a compelling argument as to why it’s needed, drop it!
- User focus: Key to answering many of the above questions is to think about who’s using your data. Is it for internal use or will you be providing access to external users – other charities, academics, think tanks…? Determining what they need now could help you avoid major headaches in the future.
The above is by no means an exhaustive list, but is an indication of some of the issues that organisations might want to consider when looking to create their own data standard (or columns on a spreadsheet, as may be more apt). But above all else, you should realise that this is a collaborative effort and not something that should be left to management alone or delegated to your IT team. It’s a process that works best when you speak to people both inside and outside your own circle.