Data Analytics Initiatives

Managing Analytics for Success

Ota Novotný, Ondřej Bothe, Ondřej Kubera, David Bednář, Martin Potančok

• Publisher: Auerbach Publications
• Year: 2022
• Print ISBN: 9781032302409
• eBook ISBN: 9781000629347
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

The categorisation of analytical projects could help to simplify complexity reasonably and, at the same time, clarify the critical aspects of analytical initiatives. But how can this complex work be categorized? What makes it so complex?

Data Analytics Initiatives: Managing Analytics for Success emphasizes that each analytics project is different. At the same time, analytics projects have many common aspects, and these features make them unique compared to other projects. Describing these commonalities helps to develop a conceptual understanding of analytical work. However, features specific to each initiative affects the entire analytics project lifecycle. Neglecting them by trying to use general approaches without tailoring them to each project can lead to failure.

In addition to examining typical characteristics of the analytics project and how to categorise them, the book looks at specific types of projects, provides a high-level assessment of their characteristics from a risk perspective, and comments on the most common problems or challenges. The book also presents examples of questions that could be asked of relevant people to analyse an analytics project. These questions help to position properly the project and to find commonalities and general project challenges.

Part one The Framework Definition Part one

1 The three-axis approach to analytics projects

The categorisation of analytical initiatives could help us leverage the knowledge we have already gained and reflect it in our work. Correctly defined categories could help us to simplify the complexity reasonably and, at the same time, understand the critical aspects of analytical work. But how can we do it, and what can make it so complex?

As we mentioned at the beginning, many data analytics projects have been delivered. What we have been thinking about, therefore, is how to leverage the experience they yielded – any lessons learned that could help avoid any type of failure in the future. Once again, we would like to emphasize that we are focusing on project external factors only. Due to this, issues like inexperienced delivery teams are not our focus for now. That being said, we have seen many commonly repeated mistakes that lead at least to complications if not to the project’s failure. After all, the definition of failure could vary, on a scale of stopping the project entirely to using analytics results insufficiently.

Moreover, we believe that many mistakes could be avoided by investing time at the beginning of the project into understanding the project scope and external landscape. Many things are not easily visible (or could be left out intentionally) or deprioritized for the sake of a speedy delivery (or the start of the project). We realize that discussing this in advance is challenging or might not even be considered agile. Still, we believe that it is one of the critical success factors and should be part of the initiation phase of every data analytics project.

The result of such a discussion should be the categorization of the analytics project. The question is what categorization means. The desired outcome is to understand all (or most) aspects of the project from as many perspectives as possible.

We tried to summarize one of the possible approaches in the following chapters. The text aims to guide the reader through the different views on the analytics project, describe the main questions that should be asked and ideally also answered (or at least considered as a potential risk) or even explain some fundamental failures that could occur. Before we jump in, we need to understand that no analytics project is the same as another. Therefore, we need to try to avoid bias based on our experience and answer questions as openly as possible. This approach could even lead to innovating our way of working (WoW).

To describe this way of thinking, we will try to follow the “three-axis approach”. We tried to summarize the different points of view on the analytics project and split various perspectives into three main areas – analytics maturity, IT maturity, and data maturity. We will dive deeper into every area separately, but it is essential not to lose the overall vision. Keep in mind that the combination of the axes is critical. There is no bad or good position on one single axis. What is important is the combination of axes and understanding whether the desired project goal can be delivered easily within the defined combination or whether the expectation (on any level) or the position on any axis needs to be changed.

Moreover, the bigger picture needs to be considered. We focus mainly on the project (whether it is delivered within the waterfall or agile methodology). However, we also need to understand the analytics solution and landscape (this will mainly show in the analytics maturity introduction, but it is also valid for other axes).

The axes do not cover everything. Other aspects are closely connected with the analytics project categorization initially, but even more so with the project/product lifecycle. We will spend some time on these at the end of the book (an example would be a continuous funding challenge).

A project may benefit from following these three axes in a specific order. In any case, you can also leverage this and evaluate your general analytics environment with a focus on one aspect. The recommended “mind flow” is as follows:

Analytics Maturity → Data Maturity → IT Maturity

The reasoning behind this is simple. First, we need to understand what type of analytics we are focusing on. This could significantly influence the required data (it does not necessarily have to be about the data source; for example, the granularity could differ). Later, as soon as we understand the data needed, we can look at the toolset (because it does not necessarily cover only the analytics toolset; steps may also be required just to process/prepare the data for the analytics task itself).

1.1 Axis 1: Analytics Maturity

When it comes to analytics maturity, numerous points of view already exist. The different approaches are often visualized in the form of a chart with various axis definitions (Figure 1.1).

Figure 1.1: Aggregation of the typical visualizations of analytics maturity and the analytics journey

In almost all cases, the “analytics maturity” description is combined with other metrics. Analytics maturity is commonly described as consisting of the following steps:

1. DESCRIPTIVE
   It describes, summarizes, and analyses historical data to answer the question “what happened?”.
2. DIAGNOSTIC
   Based on descriptive analytics, it focuses on the causes, answering the question “why did it happen?”.
3. PREDICTIVE
   It focuses on the future. Based on available data from the past, it tries to answer the question “what could happen?”.
4. PRESCRIPTIVE
   It builds on predictive analytics, with an emphasis on recommending the right and optimal solutions or decisions. It answers the question “what should be done?”.
5. COGNITIVE
   Incorporating previous types of advanced analytics into autonomous systems with a purely data-driven approach supports independent monitoring, decision making, and action. For this reason, some approaches include this category in the previous one. This type of analytics often answers the question “how to adapt to change?”.

It is quite understandable that this describes the complexity of an analytical problem. Yet, the definition of “complexity” can be misleading. Is it the complexity of implementation, the complexity of understanding the business result or the complexity that impacts implementation time? Is it also necessary that an earlier step is finished before we move on to the next one – meaning that before starting a diagnostic project, we need to have completed the descriptive one?

A combination with a second metric could even bring more confusion into this. One of the commonly used combinations is “value”. Is it really the case that cognitive projects generate the most value? Is a “cognitive project” really the gold standard for every single area? And is it possible to implement it at any time? Another possible combination could be created with “complexity”. Once again, what makes the cognitive project the most complex one? Is it really true that predictive projects are more complex than descriptive ones? And what is the measure of complexity – is it the implementation time, any other costs connected with the project, or the experience that the analytics team needs to have?

We have decided to shift the point of view a little. We believe that this project categorization is correct and should be used. However, we want to look at it through the lens of the work that needs to happen. So, the first question is: “What is the business goal of the project?” If we can answer it, can we write it down? We need to be as specific as possible since we need to know the two main features of this work:

1. Is it project- or solution-oriented?
2. Is it ad-hoc or robust?

If we find that what we are talking about is the solution, we can consider dividing the work into more projects. However, this may not necessarily be an effective way to deal with the issue from a project management perspective. We can evaluate different parts separately, but we usually need to “compose” everything back together later. The importance of the “solution versus project” consideration lies in something else, however: we need to understand whether there are any hidden parts that need to be dealt with in order to satisfy the end-user. Therefore, we might start with a scope that is defined as predictive, but to carry that out in an efficient manner, we also need to create reports and integrated data. We therefore identify that the original requirement is a solution that can be subdivided into three projects – predictive, reporting, and data integration. This will help us understand and manage the complexity. Try to answer the following questions:

• — To what analytics solution, product, or service does your analytics project contribute?
• — Which other elements of the analytics landscape play an important role in the case of your project? Which stakeholders, market conditions, etc.?

Let us have a look at some questions that could help us define the analytics scope:

Q: “What is the business goal of the project?”

A: “To have a sales prediction delivered within the next two months.”

This may look like an easy question, but unfortunately, there are many decisions that we cannot make since the answer may have many hidden components. We can use an additional question to clarify:

Q: “Has reporting been established in order to monitor sales?”

A: “Yes.”

Q: “Has a plan for sales been set up?”

A: “Yes.”

Q: “Should we just try to make the prediction to demonstrate it is possible with the available data?”

A: “Yes.”

Q: “Should we create a repeated framework for a prediction that will be run regularly?”

A: “No.”

Q: “How should we share the outputs?”

A: “Presentation.”

Q: “Should we integrate the results of the prediction into some other system?”

A: “No.”

Q: “What is the timetable of the prediction?”

A: “1 year.”

The answers to the questions above will probably move us closer. The business goal could then be: “We would like to test a predictive mechanism for sales.”...

Table of contents

• Cover Page
• Half Title Page
• Title Page
• Copyright Page
• Table of Contents
• Foreword
• About the Authors
• Introduction
• Part one — The Framework Definition
• Part two — The Framework in Context
• Conclusion
• Index of Terms
• Index