Nearly 85% of data science projects fail. That statistic from Gartner is one I have seen in every industry event I have ever been to. This number, of course, varies from company to company and industry to industry. You would expect this number to be lower in places like Netflix, with its widely publicised data culture, and higher in more old-fashioned industries with none. However, this number is far too high and risks organisations not realising the value of the data they have. This post sets out four practical examples you can use to embed a data culture within your organisation and start succeeding, or at least fail much faster and move on to the next project.
Action 1 – Find Data Champions
Many hands make light work. Trying to get an organisation to embrace a data culture on your own will be hard, if not impossible. If you can find people ready to go out and spread the word then things will be easier.

Normally, when people think of champions, they think of senior management. However, this shouldn’t be limited to them. One of the biggest data culture successes I had was starting an email impact working group of mostly officers. By judging the performance of emails based on hard data and improving them through testing, our small group grew from the bottom up to cover the whole of the organisation and improve open rates and click throughs by over 50% in the space of a year. If people are enthused at the idea of data and willing to help, then find a role for them, no matter what level of seniority.
Obviously, not everyone is immediately enthusiastic about changing to a data driven approach to work. Otherwise this article would be redundant! Some people will rightfully require some evidence to prove to them that this is a better way of doing things. There are a few ways of doing this. One could involve finding quick wins for that person using data and analytics (a more detailed section on this below). Another could be to talk to them and find out what the blockers are to them embracing a data culture, and working to fix those most important blockers. The more evidence you can provide, the more likely you are to create evangelists.
However you find data champions, just remember to always express your gratitude and find mutual ways of championing each other. These people are helping you to get ever more interesting work and bring value to your organisation, the least you can do is help them to do the same.
Action 2 – Levelling Up
Data should be for everyone. Data democracy is increasingly talked about, although the bulk of this talk is on making tools easier to use. Whilst this is important, approaching data democratisation from the other end can be just as valuable, namely bringing people up to a good level of data literacy. I’ve always found enthusiasm for this approach. On the whole, people are always willing to learn and improve, and data skills are a great CV booster, which doesn’t stop the enthusiasm!
There are many ways of improving data literacy in an organisation. How you approach it depends on people and their time and their current level. You will probably need a mix and match approach to the methods below to tailor learning to those needs.
Training Sessions
First up are the big beast training sessions. This may be for people whose level of data literacy is low or for those who are really interested. Training sessions could cover anything related to the work and data tools, not limited to building dashboards, the fundamentals of SQL, Python or R, Excel, statistics and quantitative research methods or even machine learning depending on how keen people are. Keep the sessions fun and interactive, use prizes for people who finish tasks and try to keep tasks and examples related to the organisation’s data and work. At the end of the session, evaluate how things went and adjust where appropriate. In the past, I’ve found it useful to write detailed session plans and templates for tasks so that anyone on the team can run the session.
Lunch and Learns
A good alternative to formal training sessions are lunch and learn sessions. These are relaxed sessions where people can eat lunch whilst learning about your work and ask questions. These are good for people who don’t have the time to spend in a training session or may already have some level of data literacy. They also have the added benefit of building relationships, getting to know colleagues in a more relaxed setting and people subconsciously linking your work to something good – eating lunch!

Good Documentation
Finally, for those with no time, we have written instructions. This definitely doesn’t mean dense, 100-page user guides that no-one ever reads! In an excellent talk about building dashboards at Spotify, Jacob Olsufka spoke about meeting people where they are when providing instructions, in that case on the dashboards themselves. When building dashboards, I would highly recommend this. Most tools have the ability to create little information pop ups/tool tips which can be used to great effect. If you’re using something like Excel or Google Sheets, then have the instructions clearly written in a text box on the sheet, if your tool is straight up code then have the instructions in the comments or docstrings. The key is always to meet people where they are, not to waste their time burrowing instructions away.
Action 3 – Quick Wins
Quick wins can be great for building relationships and building up the reputation of data in an organisation. As it says on the tin, quick wins are pieces of work that can be done quickly that end in a tangible benefit for the end user. These can be anything from wow moments to little things that save people time or allow them to do their job better. Not only do they buy you time and leeway for more long term work, such as overhauling data infrastructure, but they are often the pieces of work that colleagues remember and associate with you and your team.
You can find quick wins by talking to your colleagues about their work, what their frustrations are, what they wish they had, and matching that to your skillset. If you can match something you’re good at and can do quickly to one of the things on that wishlist, then you have found a quick win.
It can be a depressing cliche for data scientists, but something that always tends to impress colleagues are dashboards. If the database is there, it is pretty straightforward to link a dashboard tool to it and create some visually stunning and interactive dashboards in a short space of time. Colleagues are usually blown away, both by how it looks and how it helps them to know what’s going on and make better decisions. After that you can go back to working on cutting edge NLP tools or multi-armed contextual bandits!
Action 4 – Agile Working (MVPs)
Agile has become a cliche that makes it on to every CEO bingo card. In many places it has been used to mean so many different things, that it has lost all meaning. This is a shame, because there are a few principles that can be taken from Agile methodology to ensure your data project succeeds or fails fast.

One of the principles of Agile is to build a minimum viable product (MVP) which meets the basic needs of the team/organisation and iteratively improve upon it. These builds and iterations are done in fixed periods of time (sprints), normally 2–3 weeks. At the start of the sprint you meet with the people you are doing the work for and agree on a minimum set of deliverables for the sprint. At the end of the sprint you get back together again and decide whether the thing delivered meets the needs well enough to be considered done, or if and where it needs improvements, or if the project is going to work at all and should be discarded.
A good example of Agile is designing a mode of transport for someone to get from their home to their office. In classic project management, the build team would speak to the end user about what they think their needs are, then go away for 3 months and build a car. In that time, the basic needs of the user (getting to work) are unfulfilled. With Agile, the team would build the best thing possible in two weeks that meets the basic need of getting to work, maybe a scooter. At the end of that sprint the person can now get to work and ask for other needs, such as more speed. By the end of the second sprint, the end user has a bicycle and has updated their needs to wanting to expend less energy getting to work. For the next sprint, the team builds a motorbike which the end user loves. They decide a motorbike is perfect for their needs as a car would cost too much to run.
The benefits of Agile over classic project management in the example above are clear. The time to meet all the user needs is much faster, and it allows for people to update their preferences and change course. This doesn’t just work for modes of transport. It should be pretty easy to see how this could be applied to data projects, perhaps when building dashboards or when designing a complex model to predict churn. By building the MVP you can have something useful deployed quickly to production and then continue to iteratively improve until you find the sweet spot where you are providing maximum value to the organisation in the best amount of time.
In Conclusion
There are many great ways of embedding a Data Culture into an organisation. These are four examples I have found to work well. Data is still a relatively new field and there will be some healthy skepticism associated with it. However, the huge amount of value great data and insight can deliver is becoming less and less of a secret, so keep on going and you’ll soon see results!