[MUSIC] Remember the best presentation you've seen and the worse. You'll notice that the best presentations always share characteristics. Good presentations are very often story driven. The presenter tells a story that you want to follow. In contrast, poor and boring presentations are not. For instance, particularly when dealing with technical topics, if you are presented with a list of results without any relationship whatsoever, or the presenter starts focusing on technical details that nobody cares about, they are likely stop paying attention. When you'll be presenting the results of your own analysis, it's tempting to forget that you're not talking or hearing your own voice but to pass a message, and accordingly you shouldn't focus on what you want to say about your work: for instance, how technical it was or how difficult some of the analyses were, but focus on the key messages you want to convey to your audience. And so, a good business analytics story has a good beginning. And I'm not talking about an opening joke. Even if that could work, I'm talking about starting your presentation with a relevent, to the point, hookup. For instance, there is no need to start lingering about the history of the company or its sector in general. Imagine that you're talking to your client as a consultant. He probably knows his own company better than you. Instead, you should directly identify the issue at hand in a quantitative and visual way to convince your audience that what you will be presenting will be worth their time. For instance, what's the pain point you want to solve? Are you trying to induce employees' attrition? Say it directly and give us a number indicating how serious the problem is. Even better, show us a graph about the number of people leaving each year. Are you trying to serve your customer better? Why is it important? Is it because a recent satisfaction survey was terrible? Are we losing market shares? Use quantitative information as soon as possible to demonstrate the relevance of what you will address later in the presentation. It may be a pain point: something to solve, or it may be an opportunity to take. But it cannot look like you're playing with data for the fun of it. If there is a reason why we're listening to you, we should know it within the first 30 seconds, and by the way, don't forget to address it by the end of your presentation. I very often see presentations that claim that they would address a first issue and we're actually addressing another one as the story progresses. A great storyteller always delivers what was promised or foreshadowed. Now as a matter of fact, in practice, the key issue of the presentation is very often discovered the other way around. The pain point or opportunity that you will be presenting at the very beginning of your presentation will usually only be identified within the course of your analysis after you've concluded your analysis! What happens is that while analyzing the data you will discover opportunities to take or problems to solve only after a while. But when you present your work, it shouldn't follow the order of the different actions you've taken in the course of your analysis! It should be restructured after you've come to your conclusions to ensure that everything you do from the beginning to the end looks like it has been aimed at addressing the issue raised in the introduction. Even though, when you've done your analysis, the issue was only identified AFTER your conclusions. You should approach the structure of your presentation as a storyteller. It's the story you want to tell that drives the structure of the presentation, not the way you've analyzed the data. And when you 're presenting your conclusions and your recommendations, don't forget that a manager has limited resource and time. At the end of the day, she can only focus on what's expected to have the maximum impact on the smallest effort. Remember what we said about the need for efficiency in most of the modules. Keep it in mind when you're writing your own recommendations. You need to focus on the most efficient actions to take. So once you've understood what are the actions that could solve the issue you've raised, you need to make sure to prioritise those actions according to their efficiency. Do not make an unordered list of all the actions that could be taken. Present the quick wins or the low hanging fruit first. Those actions that could be taken easily, because needing little effort, but that would have a huge positive impact on your business. And only then explain what should be done in the long run that will be impactful as well. But that may require more effort and at the end you'll probably decide to discard the less impactful or unrealistic recommendations in any case. If it doesn't sound relevant or easy to do on paper, it will probably be worse in practice. And so you need to connect logically the issue that you've raised to the conclusions that you've drawn. Since we're dealing with business analytics you need to explain why you need the data you've collected to address the issue, and why the methodology you've chosen is relevant. That doesn't mean that you need to enter into all the little gory details of your approach, but it means that your presentation should be self-contained. It should contain everything needed to understand the why, the what, and the whole of your results. I very often do the test of the executive assistant. Does a smart executive assistant understand your analysis? Someone who knows the business, but is not a computer scientist or statistician. If the answer is no, work on your presentation until it's clear enough and the story flows well. Remember something, the point is not to show how smart you are and how advanced your methodology is. The point is to obtain the buy-in from your audiance. And nobody likes to feel stupid or to listen to the bragging of the first of the class. Be as clear and to the point as possible. It's in your own interests. In the same fashion, do not start explaining in detail why something didn't work. Very often,in the course of your work, you will start conducting analyses that will be fruitless! It's very frustrating. And it's very tempting to explain at length afterwards that you've worked for so many hours on something that has been shown to be irrelevant in the end. Sometimes, if it may indeed be a question raised by the audience but is not really relevant for your conclusions, you may decide to keep it in (the) appendix. That's fine. But if it's not really relevant for your story, discard it and move on. Just say "one could have made this analysis, we did it and it didn't work because of X" and then go on with the rest of your storyline. I know it will be difficult to let go because you suffered on the task, but unfortunately nobody else than you cares. So don't spoil your story with details that are irrelevant for your audience. And that is actually the question that should drive everything else. What is relevant for your audience and what's not? And that depends on who is in front of you. So who is your audience? It is an executive? Be very concise with one or two executive summary slides emphasizing what should be done and what will be the expected benefit. Is it a technical person? Then you should take the opposite direction and you may want to describe the methodology in detail. The same goes for the style. Some people like that you start from the big picture and zoom into the details on the afterwards. And some people, instead, like that you do the opposite. Build your story piece by piece and present the overall conclusions only at the end. To wrap up on the storytelling, let's say that your presentation shouldn't look like a list or a series of analysis conducted separately. A bunch of interesting facts, but not really related whatsoever. It's a story.So start first with the pain point to solve or an opportunity to take Think of a good movie you've seen recently. It probably starts with an average Joe who is suddenly in front of a problem. You should have the same type of hook up. Then explain how you approached it. Describe the data, but only what's relevant for your analysis. Do not waste too much time on what didn't work and focus on having a flow of insights that follow each other and make sense. You want to attain your conclusions logically and propose recommendations that will look like there is almost no other common sense actions to take than those that you propose. And the way you will tell your story will depend on your audience. What's relevent for them and what's not? Some rationales will resonate better to a certain type of audience while others won’t. If you do your homework and adapt to your audience by telling your story, most of the stakeholders will buy-in your recommendations by the end of your presentation. What you want to obtain is a shared representation of your reality between you and your audience. This is a key success factor in getting people to move in the same direction. And it will work even better if they feel they participate in the reflection and come to the right conclusions by themselves.
