Building a presentation - Part 3

Let's continue on my building a presentation series with the next stage which is to map out and plan my presentation using the information gathered previously in the 1st and 2nd articles. To recap, the objective of my presentation is to introduce requirements management techniques and Telelogic DOORS to a team that is skeptical of the software tool.

Assemble the material
I've looked through my existing material and saw a decent PowerPoint presentation titled Clarity in my esnips.com account. There were also, earlier incarnations of requirements management presentations I had laying around. I'm sure I can reuse some of this material.

I am definitely going to have to come up with some demonstration scripts and new slides to show benefits etc...

Major components to present
Here is a summary of the major components I want to include in my presentation:

• A demo of loading an MS Word requirements document into Telelogic DOORS. All of their requirements exist in this format. This will show how requirements can be migrated into the software package.
• A demo showing traceability and its application to a project. Traceability is what will allow this team to assess the impact of a change.
• A demo illustrating how to export requirements from Telelogic DOORS to a more readable MS Word format. Before I go through this demonstration, I will show them requirements from a project that does this without telling them. This demo will bookend the presentation with the first demo.
• Tips on how to get the most out of requirements management. To ensure clarity, modularity and make requirements testable.

Map the material to an appropriate presentation style
In a previous post, "Use the right presentation style to convey your message," I wrote about some templates for presentations. One of them, "selling an idea," seems to fit in with my objective. Based on that format, I will lay out my presentation as follows:

• A simple statement of purpose. To show how good requirement management practices and requirements management software can benefit the execution of projects.
• An articulation of the audience's needs. Currently there is little / no documentation. The team has a difficult time assessing the impact of a change in requirements.
• An illustration of the features of good requirements management practices. What are traceability, modularity, verifiability and clarity?
• The benefits that can be realized by the team. What benefits do these features yield? Let's load in a requirements document to the product.
• What's wrong with the status quo? We need to change because we have difficulty understanding the impact of a change in requirements. What does this change affect? Who knows!?
• Reconfirmation of the benefits. Now let's manipulate some of the requirements within the product and show how we can understand the impact.
• What we need to do to benefit. What steps do we need to take to improve?
• Complete the 'sale.'

Next steps

1. Assemble the material as per my plan.
2. Follow presentation best practices.
   
3. Give a quick rendition of my presentation to one of the individuals helping set up the meeting. This will ensure that my presentation speaks to them.