Putting a value on your data

I know you’re tired of reading about GDPR already, so I’ll keep this brief.

There has been a huge amount written on this topic in the last few months, just look at the Google trends chart:

Screenshot (6)

This can make GDPR seem like an avalanche that is about to hit, and I’ve heard a number of people talking about ‘delete to be on the safe side’ as an appropriate GDPR strategy. ‘

Better safe than sorry’ etc…

Now, for some businesses this may be appropriate, but if you are running a small non-profit or charity I’d urge you to think hard before going down the baby/bathwater route.

I can’t advise you on implementing full GDPR policies and procedures in this post, but I can give you a pointer towards one factor that is often overlooked, and which can help you avoid the baby/bathwater mistake.

Put a value on your data

If you look at all your data and ask a few simple questions you will have a more useful segmentation of the data you care about, the data you don’t care about, and the data that is so burdensome that you likely should go down the deletion route:

  1. Is the data directly used in your service provision?
  2. Do you use and update the data regularly?

Both of these questions can be answered on a sliding scale. Quickly sketch out the following grid with four boxes:


Now write every bundle of data into the box that best represents how it is used. You likely have a dataset of users to whom you send information. If this is a core part of the service you provide then that dataset goes in box 1, top right.

In contrast, you may have a dataset of everyone that ever served as a trustee for similar sized organisations in the UK. While that data is interesting, could be useful for networking, and perhaps took time to acquire – it’s likely not core to your operations and is infrequently used. That dataset goes in box 3.

Ignore sunk cost

It’s tempting to look at the cost of acquisition of a dataset in this context. “But we spent so long building that trustee list”. Resist this temptation. If the data has little or no utility to your core operations – it should go in box 3 or 4.

Assigning ‘data care’ resources

This process can dramatically reduce the volume of data that you hold by focusing on the core value of the data in terms of service provision. This can make the care and maintenance of the data more achievable.

  • Box 1 – Start here. Focus all your efforts on ensuring that  you are fully compliant for this data, as you likely can’t operate without it.
  • Box 2 – In most cases you should treat this as Box 1. If you are truly resource constrained however, make sure everything in box 1 is handled as a priority before tackling box 2.
  • Box 3 – This is easy. There will be data in here that you simply don’t need. Delete it.
  • Box 4 – This is more tricky, and is likely a bigger question that simply one of data retention. If this data isn’t related to service delivery, but you use it a lot, what is it? This might be a sign that some of your operations need to be re-thought. Are you using resource on ‘nice to have’ services, rather than on core work?

It doesn’t eliminate the need to be GDPR compliant, but it likely simplifies the requirement, and protects against valuable data being lost or overlooked in the process.

Finally – a quick note on fundraising. I would count fundraising as a core service of the organisation, so use the same process as above for any donor datasets.

Comms > Code

Your approach to communications in your project influences success more than code and data. 

I often kick off a hack weekend with an assurance to participants that everyone has something vital to contribute, and not being able to code isn’t an inhibitor to being able to contribute to a project.

I’m sure no one believes me. I’m sure they think I’m just being nice.

I’m not.

The truth is that the single biggest contributor to any project is communication, not code. Being able to convey to users what the project does, why they should care and how they can take part are vital aspects that are often overlooked. So let’s break down the what, why and how a little.

What the project does

There are two parts to this – and one often gets forgotten. What the project does in terms of features, and what the project does in terms of objectives and outcomes. A project to make it easier to find public transport options could be described as “making it easier to get the bus”, and it should also be described as “increasing mobility options for area X” or indeed “save the Polar Bears by reducing transportation carbon emissions”.

Why they should care

No one cares about databases or apps. Which is why it’s so important to look past your features, to the underlying cause.

Typically people will care more about the bigger goal, and are therefore more likely to give your project attention. Who doesn’t want to save the Polar Bears?

Identify your Polar Bear and talk about it.

How they can take part

Nothing makes people care about a project like feeling involved. Tweeting a request for information can be a quick, simple, low barrier option that is available even in the first hour of a project. Publishing a survey, asking for relevant stories, and even asking for volunteers is all worthwhile – as long as you’ve given your audience a reason to care first.

Building a broader team of supporters and test users around your project is vital to creating long term momentum. Lower the barriers to engagement – offer really simple tasks that people can complete so that they feel invested.

At a recent codethecity one of the requests was as simple as “hey friends, could you send me a photo of any drinks cans that are near you please?” Within minutes the photos started flowing.

Find that simplest contribution and reach out broadly, and early.

Project impact

So how does this impact a project? Projects are enabled by technology, but they are driven by people. The more people you have behind your project the faster you can drive.

It’s as simple as that.