Information Technology Reference
In-Depth Information
One is often forced to demonstrate an application that is not fully
ready. The point to keep in mind is that impressions matter, as marketing
folks know well. If the product is in bad shape, do not try to arrange a
demo. Users will nod their agreement that they understand that it is a
work in progress, yet get apprehensive that the software is “in bad shape.”
This can have adverse side effects on the projects. Just as there is a point
at which an application is ready for release, there also is a point at which
an application is ready for demo — and not before.
Demos must be done in very controlled environments. Some points
to be aware of include:
Understand clearly what the demonstration is set up for. Is it to
show that progress is being made, or is it part of the requirements
validation process? Modulate discussions accordingly.
Test what you are demonstrating a few times and stick to the script.
A demo does not always show all the features in the application.
Decide on what you are going to show and show only that. It is
tempting to get carried away and click at something that you think
“should work” but have not tested yourself.
Control the demo environment strictly. Set up the environment
early. Do not change demo machines at the last minute. Keep
proven user IDs for the demo. Select parameters (date ranges,
customer IDs, etc.) for reports and queries that you know will
return good data.
Take detailed notes. If it is a demo to an important audience, have
other team members in the room take notes, as it is very difficult
to do the demo, handle questions, and take notes at the same
time. The note-taker and the person doing the demo should pay
close attention to nonverbal reactions to what is being shown.
Do set the expectations of what will be seen and what will not
be shown before the demo. If the reports are not being shown,
say explicitly that the reports are not yet ready and will not be
shown in that day's demo. Let the users not find that out after
going through the entire session expecting reports to be shown at
the end. If there are known bugs that the developers are working
on, let them know about it when you come to that portion of the
demo.
Provide basic information about the environment you are demon-
strating. Are you showing the Development, QA, UAT, or the
production versions? Which database is being accessed? What
placeholders are in place? For example, messages on screens, logos,
etc. might be placeholders, and the live system would have dif-
ferent content. Explain where the differences are between the demo
