Presentations to project
stakeholders are a reality on most software projects:
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
Documentation, documentation is a very ineffective approach to
bottom line is that you need to be prepared to give
presentations to project 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
- Turn the presentation into a
working session. You have project stakeholders in the room so
put them to work. Work with them to identify new requirements,
delve into existing requirements, or prioritize your
- 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 project 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 project
stakeholders point blank that I had to decide
between spending my time drawing pretty pictures and
building software, so I naturally choose to build
ever complained. In short, apply the principle maximize
stakeholder ROI and be smart about what
- 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
Presentations can and should be effective
communication opportunities for your project team, if
you choose to keep them simple.