The Value of Data Science

The Value of Data Science

Posted by Samir Sharma

I recently attended the Big Data & Analytics conference run by Whitehall Media.  Mainly focused on the data science community, however, what I thought would be a very highly technical programme ended up being more about how the business can understand the data science community.  There were many speakers from a range of industries from the big banks to companies focused on the travel market.

One of the major takeaways for me which may not be the biggest thing since sliced bread for you, is the interaction between the business and the data scientist / BI team etc.  Dr Alexander Weiss from get your guide summed up the interaction between the two in the following slide:

What I like about this is its simplicity.  Let’s break it down and look at each of the components:

1. Data Science is a different way of approaching problems.

Before we delve into the above, let’s get an understanding of what data science is – a term used a lot by many people in different ways – the definition below is from Wikipedia:

“Data science is an interdisciplinary field about processes and systems to extract knowledge or insights from data in various forms, either structured or unstructured, which is a continuation of some of the data analysis fields such as statistics, data mining, and predictive analytics, similar to Knowledge Discovery in Databases (KDD).”

Here is my take: “data science is about getting a deeper understanding of data, it’s value and what use it’s going to add to the business entity that is attempting to get benefit from it. Whether it be through a combination of “descriptive”; “predictive” or “prescriptive” analytics.”

What about a “data scientist”?  In my opinion: “a data scientist by and large is a hybrid individual that can leverage very technical tools to extract, organise and mine the data (in whichever format) to gain deep insights into the data, and to play that back to the business in plain business speak – for the main purpose of competitive advantage, understand customers, streamline processes or protect revenues.”

Over to Martin Squires who I must say was one of the best speakers.  Here is his take on the data scientist and the attributes required (it’s a bit skewed as I was at an angle when I took the picture – I think you can make out most of it).  See below:

Apart from the technical bits which are a pre-requisite, in the bottom right-hand corner we see the softer skills required such as – industry knowledge, problem solving skills, able to engage with senior stakeholders, translate data driven insights into decisions & actions and Visual / graphic design.  Ummm you say – there aren’t many people about who can play that role and you are probably right.  It’s very rare to find a data scientist that can cover all these attributes.  I love the fact that the centre piece is “Unicorn” – we are attempting to find something that will never be.

One thing that we do need to look at is the “different way of approaching problems”.  The statement alludes to the fact that as a data scientist there is a fail fast mentality.  Hence we probably need to look at the concept of “Agile Data Science” – the notion is to have open lines of communication with the business.  Taking an initial idea or question(s) the business may have, and start testing this with small amounts of data to ensure that a “Minimum Viable Product” can be created.  This will help initial discussions with the business and provide feedback loops on whether the hypotheses are correct, or they need to be worked on in further detail or scrapped altogether.  This means that we quickly evaluate the idea or question(s) which allows the data scientist to have the dialogue with the business, and refine the idea or question(s) so that another quick test can be undertaken to get us to the answer.  This is all about iteration and making sure that the data supports the hypotheses and the feedback loop with the business makes it real and not an academic exercise.  Agile in itself is about business value and priorities, if we can get this balance correct and deliver the right things to the business, then we can support them in making their business strategy a success.

Arguably, that leads us onto the next point that Dr Weiss makes:

2. As an expert, you need to teach it to your company.

With every new concept there is always an amount of education that comes with it.  The education element here if I am interpreting correctly is very much about how the concept of “agile”.  Many organisations struggle with this notion as most companies still live in the world of the waterfall methodology.  In many ways I should do a comparison of agile vs. waterfall and maybe that’s for another article – this would be far too long if I continued in that vein.  I did allude to agile in the previous point, and will go into it a little bit more now.

Agile basically allows us to build a piece of code, software product, algorithm, dashboard etc. iteratively and within time constraints from the get-go of a project, in small increments rather than leaving it all to the end and building something that bears no resemblance to the initial ask (which is my quick comparison with waterfall).

The basic structure that we follow in any agile project is as follows:

1. Start with your needs – break down what it is that you want to do by business value and priority typically these are known as Epics, themes and user stories – let’s just call this collecting business requirements.
2. For the requirements is the data available, or will it become available during the project or will we need to go and get it from somewhere. We can reprioritise based on the data that is available and out of that the biggest value that can be delivered to the business.
3. Once we know what data we have, we have reprioritised, we can start building a “value roadmap” to ensure we can build value into the project immediately and the business has a view of what they will get immediately etc.
4. Based on the above we start planning our sprints – these are small iterative development cycles where we take the value roadmap and plan what components we will deliver first, second, third etc. based on the work that we have done with priority and value.
5. Once the sprint starts (typically 2-3 weeks) we are into developing, working with the business to ensure we are building to specification and daily stand-ups allow us to capture issues etc. and deal with them.
6. At the end of the sprint we get everyone into a room, demo the product that has been built – there are no surprises as most business people have been along for the journey and the product is signed off.
7. We normally have a reflection of how things worked in the sprint and what learnings can be taken into the next sprint.
8. Now we start the next sprint and we rinse and repeat.

(Now I know I have left out stuff like the velocity of a sprint, test driven development etc.  I just wanted to provide a business view and not get technical).

If you look at this in 2-3 weeks there is a product, something of value aligned to the business needs has been built (value based development) – which means that the developer / data scientist etc. are building something linked to purpose.

In summary, finding the unicorn will be like finding a needle in a hay stack.  Look around your organisation for those that have the particular analytical capabilities.  These are the people that can work with the data and ask the right questions.  In most cases, they can work with the technology teams to decipher what is required.  Getting a combination of business, technology and developers often helps in building small teams to test the hypotheses for the business.

Be practical in your approach and look at business value over delving into development immediately.  If you can isolate data sets, interact with them even through SQL, get some golden nuggets of actionable insights, collaborate effectively with each other to understand value and priorities, and embed a sensible plan, then you are onto a winner!  Making a data science / big data project a success!

Don’t leave the building with an empty promise, your organisation is too precious for you to do that!  Good luck and as ever, if you would like to leave any comments please do below.