There is considerable research reporting on excessive failure rates of many business initiatives, most recently “digital transformation” and “data projects”.

A recent article by Adrian Mitchell got me back on this track. His article entitled “5 reasons why 80% of data and insight projects fail” is worth a read.

Before, you reach for the keyboard to challenge this claim, it is clear that these “disappointments” are not related to “abject total failure” alone, but to the much more pernicious result of “failing to meet customer/stakeholder expectations”.

In any business, if you do not meet or exceed your customer expectations for a transaction or relationship you have, at the very least, created a “learning opportunity” which we should grasp with both hands. The project “After Action Review” or AAR is a great stimulus to achieve this.

Often, we find that the expectations were too high, often fuelled by the Dunning Kruger style cognitive biases, or that the planned/expected timescale was too short to achieve the outcome, or that there were key elements of the plan that we did not really understand at the outset.

I continue to discuss, in multiple forms, the lessons we can learn about this phenomenon as it relates to digital transformation and as they relate to any large-scale IT enabled change.

But the evidence I see is that the “disappointment” number is closer to the 95% mark. 

Why is that?

The article below argues that the 5 key reasons are;

1. Wrong questions get asked
2. Collaboration between (data) analysts and business customers is low
3. Data project insight isn’t clearly communicated to the right stakeholders
4. Data projects aren’t discoverable
5. There are no systems and standardisations in place

The problem I have with the article is that it is based on research with “data professionals”, when the “failure” perception should be gauged with the Business Customer. Of course, if the artisans are saying that 80% of data projects fail, would you expect that the customer rating to be higher or lower?

But Adrian’s article did make me reconsider my views of why the results of data initiatives are often so disappointing from a business perspective. It is more subtle, nuanced and complex in my experience and observation. There are four big reasons;

1. Data initiatives usually start with a request for data about a topic, theme or issue. But they often do not define the end-state business outcome required, or “what good looks like”. For example, a request based on data about customers may overlook the fact that the desired outcome may be specifically focussed on informing or validating a current financial year forecast. Without understanding the detail of this, the “data wrangling” may produce accurate, but unhelpful, results. I cant count the number of times where data scientists have told me ” but the algorithm was right, it did what it was meant to”. This is somewhat akin to a surgeon announcing that “the operation was successful, but the patient died”.                                                                                                                                        
2. Closely related to point 1 above, collaboration between data analysts and business stakeholders may be intense, but often the collaboration is focussed on the wrong thing. The data analyst wants to know about the data and what the customer wants from it, but the business outcome is often “process focussed” and a critical nuance can easily be missed.                                                                                                                                                                                                                                                                                   
3. Where is the data to be sourced? It is increasingly common with today’s hub and spoke technology architecture (counterintuitively perhaps) that process data is increaisngly duplicated across different systems and databases. And that is before we even worry about data lakes or BI hubs. Where is the master “single source of truth”? It often depends on the status of specific data items and the stage of the business process being diagniosed. For example, it is common for Supplier Invoices to exist in a Procurement or P2P Suite, as well as in the ERP ,  an e-invoicing service and an invoice workflow management system. At any point in time, the current true relevant business condition may be found in different sources of the “same” data.                                                                                       
4. Semantics. What does the data actually MEAN? It is easy to make assumptions that data instances reflect the expected meaning. But there are still many organizations that encode important categorization concepts into such things as supplier numbers, customer ids, even order numbers. For example, we see data from enterprise workflow engines that imply an error or pause condition, but the context of that data is often lost. What choices did the participant in the workflow have? Was this just the “least worst” option to select from a drop down list? It is critical to understand what the data means which usually requires a deeper understanding of the source actoivity or event, who or what created the data and in what circumstances and context.

These are critical topics for data scientists, analysts and their leaders, BI teams, process mining experts, CIOs, and line of business managers, operational teams and subject matter experts, all trying to drive enhanced process performance, customer value and effectiveness in the organisation.

If you socialise both the 4 critical success factors form the business perspective with Adrain’s 5, you have a pretty good 9 step model to socialise and brainstirm how to increase your team or organization’s perfiormance with data initoiatives.

For “performance” read “enhanced business outcomes”.

You can read Adrian’s source article here. . . .