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.
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.
No comments:
Post a Comment