One of the projects I had introduced to the guys at Highlands University was nearing completion. Anthony the project lead called me into their office to go over the project and make sure we hit it with the work order. So with work order in hand we started. Unfourtunately the programmer had been working on the site that day so it kept breaking. I recoginized the error was a simple one and told them I wasn't in rush for the project and I could come back tomorrow. I also realized that me sitting there put enough pressure on the programmer so he was unlikely to find the error. Just better to come back when he had time to find the missing bracket (which indeed was the error). So the next day I returned and with work order in hand we go through the site. I thought about the demonstration I saw, which was pretty straightforward, and how many times I had to give a similar demonstration for clients when we completed a project. So I though perhaps I could distill some rough guidelines for a demonstration. Now most of my demonstrations were done for a web site but with a little imagination you can expand them to include product demonstrations as well. Here's Brian's Rough rules for demonstration.
1. Control the demonstration. This means that you shouldn't allow the client to side track the demonstration with questions. This means simply saying,"That's a great question. I would like to handle questions when we get to the end." Make sure though that you write down the clients' question or note it. I suggest writing it down as your mind will be focused on the demonstration. Keeping a question notepad is one way to do it. It is also useful for writing down short notes when the application doesn't quite work as expected. Also don't let the customers randomly monkey around with either the equipment or the site. If you want the customer to try a feature, show the customer the feature you want to demonstrate, show them how to do it and then let them do jsut that feature. It's a product ask for it back so that you "may continue the demonstration".
2. Know your click path. For this latest demonstration we used the work order to drive the feature demonstration. This can sometimes cause problems as certain features are related to each other. It's often more natural to demonstrate certain capabilities when they are clustered together. Find out what will naturally go together when you practice the demonstration. If you are not the developer, then have a developer in the room when you do your first practice session. Some of this advice will actually be helpful as they point out how features may be clustered together.
3. Declare the system "Gold." This is a hard one for developers to resist. Quite often they think they can stuff a feature or finish in time for the demonstration. If developers are working on features before the demonstration you can expect that demonstration to go poorly. If all the promised features are not in this demonstration, let the customer know early so as to minimize the expectations.At some point declare that all work must stop so that you can prepare for the demonstration.
4. Set the expectations. This is an important part of any demonstration. As a demonstration can happen at any point in the development process especially in the XP, you should set the expectation on what the customer is going to see. If demonstrating a specific module, state it at the beginning of the demonstration, "This demonstration will only be covering the customer profile and profile management features." Customers are always going to want to see more so remember point #1.
5. Practice the demosntration. A demonstration is a form of public speaking and you would never think of giving a speech without practicing it once. By practicing the demonstration in front a single person (preferably a developer familar with it) you will certainly feel more comfortable with the system.
6. Developers often do not make the best demonstrators. Why? Because they are extremely familar with the internals of the system they are demonstrating. So they may make leaps or even be tempted to make changes during the demonstration. Remember point #3. No more features.
7. The missing feature. Sometimes you just don't have everything you need for this demonstration. If you forget to mention this during the expectation setting phase of the demonstration, you might be able to get away with dreaded,"In the final version of the system, feature X will happen this way. I am sorry we weren't able to get ready for this demonstration." Of course that feature might not be in the work order, but you can bet the customer will certainly want it. At the final demonstration, the customer will certainly the feature as you mentioned it rather than how the contract reads.
That's all for now. I will update this from time to time. It will be nice to re-visit it now and again.
