Three essential things to think about if you want to gain business value through data projects

My name is Stefan Buhrmann, and I work as the Lead for the Data & Organization division at Aurai. My division aids in aiding technical data teams in achieving projects that are both successful in terms of business value and in organizational traction. In this blog I will address some of the challenges data projects face and how we address them.

Project success

I founded the Data & Organization division within Aurai because I noticed that usually when a project fails, the reason rarely is of a technical nature. To support my findings, I also quote some studies in this blog. Even though some are not from the latest studies, I still find them to be true today.

How do you align business stakeholders with data teams? Many organizations struggle with combining what they already do well with what they aspire to do well. The first reflex many managers that aspire putting together a data team have is to find as many skilled data engineers, machine learning engineers and data scientists as they can, make a good selection of candidates, hire them and implement a predetermined backlog for the team to develop. Sounds about right. But what happens when the answer to the question whether or not your historical data allows you to predict future events is ‘no’? Will you just bail on the entire project? This is where Data & Organization comes in! Read more to learn how.

  1. Interpreting value

So often have I heard machine learning engineers complain about inadequate data quality for their models. The big issue here is a matter of tunnel vision. Is developing your initial use case the only way of adding value or is there a question behind the question? Is your use case one of many possible ways to achieve a team’s goals? How are these team goals determined anyway? What are the underlying issues behind the question? Good question!

It is important to always know your business goals and strategic goals when working on a project. For example: when you are looking to train a model for predictive maintenance, is the business goal to predict malfunctions or is the business goal to save money by optimizing maintenance? Or might the business goal be saving time for mechanical engineers because there is a personnel shortage? These things determine a project’s success in a big way. Many times, because one of our main principles is ‘fail fast’, we are able to find out as quickly as possible if a use case is feasible and if not, to quickly pivot in order to still add business value. Determining this project definition is one of the things my team, Data & Organization, facilitates. We help consistently align business value for data teams through proper scoping. Because we are strategic consultants with a deep understanding of data, we are capable of connecting business to tech and safeguard the added value of our projects.


  1. Interpreting data

Even though the quote seems a bit dated, I still see this occur far too frequently. Oftentimes, a dataset does not allow a data or machine learning engineer to immediately interpret it by themselves. There is a gap to be bridged between the data team and the business stakeholders. My team, Data & Organization, aims to be this bridge. Because the business stakeholders understand how the data expresses itself in the field, we make sure they are well aligned with the project so we are able to look beyond the raw numbers to interpret this data. As you might already know, data has little intrinsic business value, it is what you do with data that creates value!


  1. Integration in business workflows

A final big impediment in the success of data projects I want to address in this blog is integrating the data project in the business stakeholder’s workflow. Let’s, for consistency’s sake, say you successfully develop a predictive maintenance model. If the planning division behind the mechanical engineers just continues business as usual, your project will still not add value to the organization. In order to scope and execute a successful project, business stakeholders need to be included in the project from the get go. Because business actively participates in the scoping process, you know what problems to actually solve. Another big plus is: who hates their own idea? Since the business stakeholders are included from the jump you have their support and you know how this matches up with the way they currently do things. Developing on an island rarely makes your solution match the mainland infrastructure!

If you have questions or if you would like to challenge the simplifications I have made for this blog I welcome you to reach out to me.

Stay tuned for our following use cases that will further illustrate the principles I explained in this post!