You’re a freshly minted data professional.

You’ve scoured the latest LinkedIn and TDS Posts; you’re well informed of the latest trends and data pipelines.

Popular opinion on LinkedIn shows the power of big data (i.e. echo chambers) where you’ll need to slice, dice and analyse every facet of the data. After all, that’s what all great data professionals do…. right?

There’s a sharp difference between best practice and what’s popular and it’s not always clear which path to go towards.

Analytics projects are split into two (2) broad categories:

1) Tangible – Cashable initiative(s) which result in improved cashflow either through A) improved production or B) Cost reductions which reduce unit costs.

2) Intangible – Non-Cashable Initiatives (i.e. Softer, qualitiative measures to track value)

Provided your data problem cannot be aligned with tangible business value or strategic orientation, you have just described a problem you shouldn’t be solving. Yet this happens again and again in organisations that are weary of data transformation initiatives and want simple solutions, not data analytics pipelines that produce numbers out of business context.

So - how do we fix this? Cue the HDEIP Framework.

The HDEIP Framework is a five (5) step problem solving framework that can be adopted to any data problem and any industry to gain clarity on the problem you’re seeking to solve. In short, if your project can’t pass the Hypothesis phase of the HDEIP project, it’s not a project that should be pursued from an analytics lens.

Now let’s unpack the HDEIP Framework and what this means for us as Data Professionals. 

Hypothesis – What is the problem? If you can’t clearly define the problem and how it relates to either financial or non-financial drivers, regrettable as it may be, you shouldn’t be picking up this piece of work.

Now within the Hypothesis phase we have three other tools that we seek to use to flesh out the hypotheses.

These are:

A.    Problem Statement Worksheets

B.    Issue Trees

C.    Value Driver Trees

All three of these tasks are linked together where the problem statement, a SMART Statement, fleshes out the context of the problem that is to be solved alongside six (6) core criterion that help further flesh out the data analytics problem.

Upon completion of the problem statement, this is then disaggregated into a series of issues or hypotheses that can then be independently analysed and prioritised through the use of issue trees and value driver trees. As issue trees provide the visual map for exploration, value-driver trees provide the prioritisation and direction for which avenues should be explored first. Not all issues are equal in size, so it’s important when dealing with time-bound based issues to prioritise your focus based off the value of the issue which is generally established by the commercial analysis / financial teams. 

Data Sourcing – What data do we need to prove or disprove our respective hypotheses? It isn’t sufficient to just take all the data to help prove or disprove your hypotheses. Rather, you should take only the information directly related to proving/disproving your hypotheses as approached to the ‘big data – I’ll take it all’ approach. This approach works fine if you don’t have time bounds on your analysis, but as the majority of your work will be timebound, it’s important that you have a structured and prioritised manner of sourcing only the data you need for your analysis and nothing more.

Exploratory Data Analysis – This is where you explore the data with respect to the issues you defined earlier. One of the most common traps data analysts fall into is the ‘analyse everything’ fallacy. Analysing everything isn’t the answer; rather analysing hypotheses with respect to your issue tree will keep you on track and prevent you from falling into the rabbit-hole trap of analysing data for the sake of analysis.

Insights – This is where we seek to transform and synthesize our exploratory data analysis into insights that align with the businesses underlying strategic objectives.  For example, if your analysis was focused around exploring Airbnb Rentals and identifying a borough that has high revenues for investment purposes, one of your insights might be; “Analysis of the 5 boroughs in New York City yield that 80% ($131M) worth of revenues are concentrated amongst 2 boroughs, Manhattan with $73M and Brooklyn ($59M) , with the remaining 20% split ($32M) across Bronx ($15M), Queens ($10M) and lastly, Staten Island ($7M).” 

Presentation – This is the final phase of the framework, where based off your audience, you’ll create an appropriate story to highlight your insights. The three (3) main presentation styles you’ll be presenting towards will be:

Executive – These presentations are aimed at traditional senior leadership (C-Suite executives and general management) who tend to focus on the larger picture and overall company strategy. When being presented with new information, they will want you to focus on the financial or strategic implications of your analysis and how your findings will impact the business’ profitability or bottom line.

Technical – These presentations should focus on the technical details and technical implementation of your analysis. These audiences are more interested in how your recommendations will be implemented, rather than what your recommendations mean for the business’ bottom line. This means that when you put together a technical presentation, you should focus on actionable next steps, rather than the financial or strategic implications of your findings.

Non-Technical – These presentations should contain information that makes sense to someone without any technical understanding of the material you’re presenting. You’ll give non-technical presentations to everyday stakeholders, executives, or technical stakeholders that have no subject matter expertise. When creating a presentation in this style, it’s important to be mindful of including too much or too little detail. Financial or strategic implications tend to be limited, or if included, will be at a very high-level.

That’s a wrap! Ultimately, if you cannot provide quantifiable context behind why you should pursue a data analytics project – unfortunate as it may be, you shouldn’t.

Analytics starts with value. Not Analytics.

Happy Learning!