Presentations - what data to present and how (contd..)

In the previous post (Data and graphs in a presentation), we talked about some of the data elements and graphs that would be shown in a presentation; such information is generated from a number of factors, the level to which these need to be shown as well as the detail depends on the audience of the presentation.
In this post, we talk about something that needs careful planning while making a presentation. When you have information and are able to show data and make great graphs, there is a tendency in most cases to do over-kill by trying to present too much data in the form of graphs. This is especially problematic when you are presenting to people who are senior to you and really do not have the time or the effort to go through multiple graphs that are presenting information that is similar. For example, if you are presenting on the current status of your project, especially with respect to the development phase of your project, the maximum focus would be on the defects - and there can be incredible amounts of data that is generated during this phase. For you and your colleagues who are working day in and day out on these defects, a lot of the data may seem relevant. But if you try and present too many graphs, even if they are packaged in a great way, it would still be over-kill. I have seen a case where the audience soon started saying, "Next, next" as soon as they saw another graph.
Such a reaction from an audience means that you have practically lost them. You have to focus on the key data details that you need to present (and I am not trying to tell you what this key data is); talk to your colleagues, get presentations made by other teams, talk to somebody who is more senior and would have attended such presentations, and so on. Make sure that you have done this homework. In one presentation, I saw around 15 different graphs on defects and defect resolution, this was way too much.
Try to finalize on a small number of graphs that you will have in your presentation, it is fine for you to have more detailed graphs in another presentation or in another appendix. There is a small chance that somebody will ask for more data or will get curious about another metric, and having that graph handy shows that you are well prepared and ready for the presentation (at the same time, don't go overboard and have dozens and dozens of graphs ready, those don't give that good an impression though). In fact, during the presentation, you can talk about the key data points for which you are presenting graphs and mention that there are additional graphs available if somebody wants more data (and these graphs should typically be those that your team is anyhow generating for keeping track of defect or coding or other metrics).

Presentations - what data to present and how

This topic is actually a full book, since it depends on the type of presentation, the target audience, etc. For example, if you are presenting to senior management, you would try to keep bullet points and graphs of data along with conclusions (and keep all the detailed information on your fingertips since you would not know who could ask what question about which part of the presentation). If you are presenting to colleagues and team members, high level summary may still be presented, but a lot more data analysis, a lot more talking about the data analysis, shortcomings, etc need to be talked about - in some cases, follow up meetings with select members of the audience may need to be set as well. When people ask questions, the questions may be more exact about specific points of the data or the analysis and it helps to have all the information as required on your finger tips.
However, suppose we are planning the presentation, need to figure out what kind of data to present, what are the graphs that may be required, all of these need to be figured and finalized before the data needs to be presented. There are many ways in which this sort of initial presentation needs to designed.
- Design what is the information you need to present, which in turn drives the data elements you need to have as part of your graphs. For example, if you are presenting on the current status of an ongoing project, one important data point would be the number of defects that are being found and fixed over a period of time. There may be ways of presenting this data in terms of the actual graph, including contrasting with similar data from previous versions, but you have an idea of the data points that need to be there in the graphs.
- Discussions with fellow presenters. In our case, when we had to make a presentation, it was on behalf of the team, so the fellow presenters would be colleagues (I was a project manager, so involved other other project managers, involved the heads of the development and testing team) with whom you could have extensive discussions on what is the kind of information or data points that need to be presented, along with the level of detail.
- In a number of cases (atleast in my case), my boss was ultimately the person assigned the responsibility for the team, so even though we would be making the presentation, the boss held a fair degree of responsibility. You can be sure that if your presentation made some boo-boo, there might be some (or many) uncomfortable words with the boss and a loss in the amount of trust that was given to you.

Once you are done with the kind of data to show as well as the kind of graphs and data analysis, there needs to be atleast a couple of presentations with the team and the boss as a sort of practise runs. You would not believe how a very confident team, well happy with their presentation, was shaken with some of the questions (genuine ones) that somehow needed a modification of the presentation, whether these be the graphs or the talking points.