The Art of Stakeholder Presentations

Presentations to stakeholders are a reality on most software initiatives: senior management wants to keep track of your status, stakeholders who are not directly involved on a day-to-day basis need demonstrations of the current version of the system, and other development teams working on systems that integrate with yours need to understand how it works. You could provide documentation for these groups but this often isn’t very effective – if you’re traveling light you may not currently have the documentation that they need. Furthermore, as you’ll read in Agile Documentation, documentation is a very ineffective approach to communication.The bottom line is that you need to be prepared to give presentations to stakeholders, and agile models can and should be a part of your presentations. Here’s how to be more agile:

Consider having a conversation instead of giving a presentation. Which do you find more effective, to talk with someone or to have them “talk at you”?
Minimize the number of presentations that you give. The best presentation is the one that wasn’t held. Presentations should have a clear purpose, a well-defined audience (it should be clear why each person is there), and a justification for why it is required.
Turn the presentation into a working session. You have stakeholders in the room so put them to work. Work with them to identify new requirements, delve into existing requirements, or prioritize your upcoming efforts.
Make stakeholders aware of the costs. Everybody loves fancy slides, but do they realize how much effort it takes to put them together? Do they realize that the time invested in making fancy slides could have been spent on developing software?
Stakeholders decide whether they wish to have a presentation. Like documentation, the decision to hold a presentation to stakeholders is a business one that is the purview of your stakeholders.
Keep it simple. Are your stakeholders interested in the system that you are building for them or in your Microsoft PowerPoint skills? Many people make the mistake of investing significant time preparing “pretty slides” for their presentations. I used to spend hours transcribing hand-drawn diagrams into a drawing tool to make them suitable for inclusion in presentations. Then one day I ran out of time and was forced to simply include a scanned drawing in a presentation. Nobody cared. The world didn’t end. Since then I’ve included more and more hand-drawings in my presentations, and invested fewer effort in transcribing the diagrams, and the world still hasn’t ended. The few times when I’ve received any comments regarding this approach I tell my stakeholders point blank that I had to decide between spending my time drawing pretty pictures and building software, so I naturally choose to build software. Nobody ever complained. In short, apply the principle maximize stakeholder ROI and be smart about what you do.
Minimize the number of people involved in preparation. Do not distract the entire team with the creation of a presentation, it doesn’t have to be a committee-based effort.
Minimize the number of your people attending the presentation. Everybody on your team doesn’t have to attend every single presentation.
Remember that you need to do more than simply present. You also need to prepare for the presentation and often follow-up after it.

Presentations can and should be effective communication opportunities for your team, if you choose to keep them simple.