How to Set up Your Business Intelligence Project for Success

Part 1 of 2

Written by Andrew Corke, Business Intelligence Director at Travelport & Daniel Stankiewicz, Independent Director of Revenue Management
Edited by Laurie Pumper, Communication Director, HEDNA

The vast amount of Data and Visualization options can be overwhelming, often becoming obstacles to  the success of a Business Intelligence (BI) project. This blog suggests guidelines on how to create the circumstances that allow a project to successfully communicate data and measure business metrics, all while managing the expectations of all stakeholders for your next BI project.

Project kick off and structure

The responsibility of a project leader is to handle expectations and keep focused on the goal.  Below are  “must do” actions when creating a Business Intelligence (BI) project:

  1. Understand the business question that you’re trying to solve.
  2. What are the desired business results? (More revenue, less cost, better control of the business.)
  3. Ask your stakeholders as many questions as you can before you look at any data. Then refine what you’re trying to accomplish. It’s easy to keep adding scope—but it’s far more valuable to simplify the questions.
  4. Don’t overcommit—if you need time to evaluate what’s feasible, then please say so. You’re better off taking a few hours or days to validate the project than committing to something you’re not able to deliver.
  5. Make sure you can explain why you’re creating each element of a new project (report / analysis / dashboard), what decisions it will drive, and what’s the business value of getting those decisions right.
  6. Measure, measure, measure—if you have success criteria, make sure to track it.  At your next budget meeting, reporting that metric will make it a lot easier to articulate the value you’ve delivered to the business.
  7. Make sure everyone involved in the project understands the why—if you have developers, architects, or other people helping you deliver, take the time to explain why you’re doing all of this. They should understand as well as you do.
  8. Keep focused on the question you are trying to solve; you can always come back and do more analysis in another effort, but adding extra capability should not compromise delivering the core minimum viable product.
  9. If upstream data development is needed, make sure it is included in the project scope. If you’re interested in gross revenue, make sure you are capturing it. So much rework happens because key elements never made their way into the first stages of data.

Designing analysis, reports and dashboards to provide actionable insights

Keep things as simple as possible.  It’s easy to add more to your goal—but try to see how much you can remove and still answer the question. People’s time is valuable. Don’t make them work harder than they need to find an answer.

Present data from the top down

The starting point should be the answers defined for the project. When presenting data, always start from the top. Most people just want to know what the outcome is going to be and understand how confident they should be in it.

Analysts tend to build up from raw data, then aggregate and transform it to produce insights. They might feel tempted to showcase the granularity of the data, but it’s the validity of the insights that matter. If feasible, build the ability to see the data behind the insights if stakeholders require it or it is within the scope of the project. You may find it fascinating that you’ve used some incredible algorithms and machine learning to create a forecast, but presenting insights is not about showing how clever you are!

Simple visualizations

Keep visualisations simple. If the answer is one number, show one number. Ask yourself, does a complex treemap actually help get the message across or does it just look pretty?

Simplify some more

Once you’re down to a simple solution, simplify some more! Look at each element you’ve got (color, data labels, gridlines, etc.) and ask if they make it easier or harder to understand the point you’re trying to make.

Try the 5 second, 20 second, 60 second test—bring up the report, dashboard, etc. for 5 seconds and hide it, then ask yourself: “what is it communicating?”. If you can see the message, try asking a colleague to do the same. If they get the message, then you probably have something that is really clear. Most people won’t spend a lot of time looking at a report. Following is a guide to help you design your projects to this reality.

5 second reports – something someone gets frequently (for example, overnight sales numbers). They may spend a lot more time to drill into the details if they spot something of interest. However, odds are you only have 5 seconds to flag something they want to look at further.

20 second reports – the next level of data granularity. If someone is looking for certain information, you typically have 20 seconds to get them down the path to an answer. Missing that window is the most common reason for avoidable ad hoc manual report requests coming through to BI teams.

60 second reports – these are generally more about exploring data or searching for opportunities. Less about looking at when to target travellers from Brazil and more about the areas I should focus my marketing efforts on this year.

Delivery method

Think about your delivery method. Push reporting is great, but people rapidly become blind to something arriving in their inbox unless it’s core to their role. Sometimes you can get better engagement by pushing something out weekly or monthly rather than daily. You can often get even better engagement by sending only when there is something significant they need to know. Every time someone receives a report that needs no action, the chances they will engage with future reports goes down. Keep the bulk push reports to a minimum and make sure they pass the 5 second test.

At every stage—from wireframe, proof of concept, to the final design—keep asking “why?”. Does what you’re building help answer the question? If not, backtrack the process and rework it.

Structured vs free from analysis

So far we have focused on answering specific questions. There is value to non-directed analysis without a clear end goal in mind. If you’re lucky enough to work for a company that gives you time for free exploration, make the most of it. Make sure you have a good understanding of how your business operates so you can relate the interesting findings into something that will drive action.

Free exploration may be a great way to break free from current ways of thinking and find new opportunities and insights—but the value to the business will come when you deliver something actionable. If you’re going to do this as part of your role, try to timebox effectively. You don’t want to end up navel-gazing for days, weeks, or months on something that you might find interesting but really won’t lead to action.

Interested in reading more… part 2 soon to come.


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.

Leave a Reply

Your email address will not be published. Required fields are marked *