The Key to Delivering Actionable Insights
Part 2 of 2 — Read part 1: How to Set up Your Business Intelligence Project for Success
Written by Andrew Corke, Business Intelligence Director at Travelport & Daniel Stankiewicz, Independent Director of Revenue Management
Edited by Laurie Pumper, Communication Director, HEDNA
The Business Intelligence (BI) project process is full of pitfalls, but they’re avoidable if managers facilitate communication between project stakeholders to make the discovery phase as complete as possible. Additionally, a project manager must be able to anticipate the data requirements to successfully lay the foundation for any project-critical data systems.
Common project failures
BI projects are often destined to fail when the necessary data is not designed for capture in the initial phases. Then the data can’t be turned into business actions. Those actions are generally business decisions such as:
- Pricing / Revenue Management, e.g. should we increase / decrease price?
- Strategic Decisions, e.g. should we open / close a new location?
- Marketing, e.g. when is the right time to market a destination to attract the type of customer I’m targeting?
The focus of this piece is the final stage of the BI chain. That may seem like a strange place to start, but it’s a common failure point. When you develop new solutions or data systems, this should be your starting point and north star.
Too often in data, we adopt the approach of “if we build it they will come.” We assume that if we can capture high volumes of data and give decision makers access, we will get good results. That’s rarely the case. Such an approach can lead to underused BI systems or bad decisions due to data presented in an unclear or even misleading way.
When Simon Sinek wrote Start with Why, he wasn’t thinking about data or insight processes, but it also applies. In fact, we could even go further and say that insight-based solutions start, build and deliver based on the question “why.”
Data can feed many business operations: a machine learning or artificial intelligence process to determine the optimum offer to display; providing data to a revenue manager to set pricing policy; or a senior executive who decides the company’s expansion plans for the next 3 years.The ultimate goal of data in business is to drive decisions. We forget that at our own peril.
Having worked in analytics for 17+ years, Andrew has met and worked with many analysts. One commonality all good analysts share is a sense of curiosity. When they find one answer, their focus shifts to the next question they can answer. That is their greatest strength—it helps them find answers and insights other people would miss. However, it is also their greatest weakness; great analysts may not know when to stop and realize they have enough to answer the original question. There is a constant desire to increase the confidence level or create an answer that’s a tiny bit more accurate.
The key to success
The key to avoiding project failure is to focus on the end user and the decision being made. Often requirements come in the form of “I need x data point” or a sketch of the tables / charts someone wants. Analysts should never be afraid to ask why! By understanding what decision is being made, analysts can ensure that every decision they make is focused around providing the best possible answer to a question.
That applies right through from data architecture and engineering, data science, and BI. Everyone in the value chain should be able to explain what they are doing and the impact it will have on the business. Not only does this help ensure actionable deliverables, it’s also a great source of motivation and new ideas. Even someone with a job title of architect or developer may have ideas about how to analyze and provide more value back to the business. Andrew has been amazed by the ideas that developers bring to the table if you just take the time to sit down with them and explain why you’re building this new data process.
This all starts with stakeholders who are comfortable with an analyst asking the why. Analysts may be a little afraid to ask someone, particularly when that person is at a senior exec level and you’re a new analyst. While some people will resist and push someone to just deliver what is asked for, they are far fewer than most of us analysts think.
In our experience, the vast majority are actually happy to explain their aims to analysts, when approached sensitively . Remember, you’re not asking senior executives to justify what they’re asking for, but to share some of their business expertise with you.
This conversation needs openness and trust among the data / BI / analytics teams and stakeholders. hat’s where good leadership plays a significant role on both sides. A data leader who can foster a culture where analysts, developers and business stakeholders work together collaboratively on clearly aligned objectives is more than likely to create a good analytics team. When we recruit, we always look at technical skills such as SQL, R, Python, and BI front-end expertise — but softer relationship skills are often missing despite forming a key part of a modern analyst’s role.
An example of using WHY? to deliver actionable insights
Good analytics deliver by focusing on creating the right insight at the right time for the right audience.
Don’t just throw data at people. That’s like someone asking for a house and you giving them a pile of bricks. An analyst should strive to transform raw data into an answer for the end user. An elegant insight solution has the minimum detail needed for someone to confidently make a decision; it should be as easy to absorb as possible. The guiding principle should always be “what can I take away without compromising the value,” not “what else can I add?”.
This all comes back to the initial “Why.” If you’re clear on the objective you can keep your analysis focused. When huge datasets are pushed over to the business, most commonly it’s because the analyst isn’t sure what question they’re trying to answer. Therefore they’re trying to answer any question they can think of, and analysts can think of a lot of questions!
Example of questioning, using a focused insight approach
Stakeholder: I’m looking for a lead time analysis out of Asia to our key destinations.
Analyst: OK, we can help with that. Can you give me a little more detail on what you want to do? Is it about planning marketing, pricing, etc.?
Stakeholder: I’m looking at a marketing campaign to target wealthier travellers coming from Asian markets to try improving our average daily rate.
Analyst: Thanks — that helps; are you looking across all of Asia or just certain markets?
Stakeholder: Well, the brief was all of Asia, but really I’m focusing on China, Japan and India as the key source markets.
Analyst: OK, and in terms of key destinations am I right in thinking that’s Europe?
Stakeholder: Yes that’s right — UK, Ireland and Germany.
Analyst: OK, that all makes sense. Given you’re looking at higher ADRs, should we look at segmenting out travellers that typically book higher-end properties or travel business class?
Stakeholder: I hadn’t thought about that level of detail, but that would be great!
Analyst: One last question: when do you want to run the campaign, and is there a particular stay window you’re trying to boost?
Stakeholder: Our marketing budget runs to the end of the year, so we’ll need to get the ad spend in by then — but we’re looking at pushing longer-term growth. So there’s not really a specific window we’re trying to fill.
For the sake of a two-minute conversation we now have the real focus and can concentrate on the source markets and destinations that really matter. By understanding how the analysis will be used, we can work with our colleagues through the data and focus on higher ADR business.
Rather than delivering a huge report on multiple sheets with different booking / stay dates, we deliver a clear view that can be absorbed in a few seconds, showing the optimal time to market to those three markets before the end of the year to drive high ADR business.
Clearly, this is a simplified example. But the same principles apply to that quick one-off analysis right through to building out entire new BI systems. As projects get larger and start to have more architectural involvement with data capture and processing, it may be necessary to consult several groups with different questions. We’re not looking at building out solutions that only work for one use case. The balance is trying to create flexible solutions that do answer the questions you’re looking for, and perhaps help in other areas. At a minimum viable product level, the solution must at least the questions you’re setting out to answer!
Conclusion
A Business Intelligence project involves a lot of technical work completed by many individual contributors. It can be easy to forget that the success of a BI project also relies on the soft skills of the project manager, who can make sure that the project scope and expectations are well understood by all stakeholders. In the end, it’s the project manager’s responsibility to leverage the technical and people management skills to unlock the full potential of a BI project.
Read part 1: How to Set up Your Business Intelligence Project for Success
HEDNA Hotel Analytics Working Group
The Hotel Analytics Working Group raises awareness of the opportunities data analysis brings to optimize cost and conversion and thereby empower hoteliers to collect, store, analyze and action their data to make intelligent decisions about their distribution strategies. The group is currently Co-chaired by Matthew Goulden at OTA Insight, Connie Marianacci at Accor and Anisha Yadav at Revinate. Click here to find out more and how to join as a HEDNA member.