Making demos to our clients is an important part of my job as a project manager. There are many books, publications and tutorials on how to make good presentations, but still many times I had the feeling I could’ve done it better. No matter how much you’ve been reading about making good demos, I think this is something in which you improve by experience.
Though there are general rules and guidelines that you have to follow, it is important to identify the specifics of what you have to present and who your audience is. For example, it makes a big difference whether it is a PowerPoint presentation or a live demo of the software project which is still far from complete. I will go into some of the essentials and problems I encountered in my practice, and give some suggestions that might help you doing a good demo.
Get info in advance
The first demo I made was for a client who I hadn’t met personally before, we worked remotely via e-mails and Skype. I have good communication skills, have some experience in making presentations, I know the project in least details and I can answer most of the questions, I am not a native English speaker, but neither the client is – so what more you need to do it well. Turned out more was needed. As this was our first project with this client, there were managers on the demo, not only the people who would directly use the product. And the managers were not interested in the details and how exactly something worked, they needed a bigger picture and confidence that the product is stable, with all the requested functionality and ready to go live on time. All the stuff I wanted to show and was proud of because it took us so much efforts to implement it, was irrelevant for this audience – some of them looked decently bored of all those details. I could’ve done it much better with a short PowerPoint presentation showing only the overview of the product.
The lesson learnt is to get as much as possible details about the audience, their expectations and how the demo will be organized, especially when you are doing it for a big project with various stakeholders involved. I am always trying to know the following in advance:
- How many people will be on the demo – it makes a difference if they are 2 or 22
- Who are these people – users, what types of users, especially when the system has different types of users doing completely different things, managers, project manager from the client side, developers working on some parts of the system
- Is there some conflict of interests – I once had to make a demo of a new system to users who were absolutely against using it, they were telling me all the time that they have so much other work that they don’t have any time whatsoever to enter all this data in the system. During the development I had met with two representatives of the client who were very enthusiastic about the project so I didn’t expect such a reaction.
- What are the expectations of the audience – if there is a discrepancy of what they expect and what I present, that might have a serious impact.
- How long the demo will be – if it is an 1-hour demo I do it in a different way than if it is a few hours demo.
- What is the equipment for the demo – a beamer, a TV screen or whatever. I’ve experienced quite often a hassle going on because my laptop cannot be connected to the beamer, or the screen resolution is not OK, or there are strong security rules in this company and I cannot use Internet
Even if I am working on a daily basis on the project and feel comfortable I know all the details, I prepare the demo and never rely on improvising. It might happen that things go into completely different direction when you show the demo. It is not unusual situation in the software industry – there was no spec, just some vague requirements interpreted in some way by the development team and the users are completely surprised at what they see. And of course, no matter how well I have prepared, this will not help – I have to improvise and try to convince the users that it is not so far from what they expected and with some rework, they can have it their way. But preparing the demo in all the details helps a lot.
Do it locally
- I always do demos locally – on my laptop. By locally I mean I have everything installed – SQL server, .Net framework, Visual Studio or whatever is necessary. In most cases, the users will not notice that the URL in the browser is localhost but I normally tell them that I am doing it locally because there are some new nice features done in the last minute which I can show them only on my laptop. And they like to hear that.
- For most of the demos, I ask the developers to prepare a setup for restoring the database so I can show different scenarios without spending too much time to fill in data.
Prepare meaningful data
It is quite time-consuming and sometimes not easy to prepare that but it is very important for the demo. The users expect to see their stuff, not loremipsum, or item 1, user 2 or whatever you just quickly type. Normally I am trying to create some real data as much as possible so they recognize what they see. Our Dutch clients will not understand a Bulgarian address format or a Bulgarian name – they cannot recognize which is the first and last name. So I’d better browse the Internet and find some Dutch names and addresses. On my last project I used names and pictures of popular actors for the users in the system and it was fun for everyone – “Let’s see how many trips Angelina Jolie has made, now let’s check what Brad Pitt is doing”.
Language and user interface
- Texts and messages. When you display the interface to the users they expect to see familiar definitions and terms. Though English is a kind of a standard in software development if it is not your users’ native language, you can get into funny situations. I was showing the interface of a big business system with many specific terms in English and at some point I saw puzzled faces. Most of the people couldn’t match the English translations we made to the terms and definitions they are using so they were wondering what these things are for and why important fields are missing. It is not always easy but I am trying to switch to the native language of the users whenever possible.
- User Interface. No matter how much complex business logic or data layer or n-tier architecture the system has, users will see the interface, not how much logic there is behind clicking a button which generates the reports they need. When I am preparing a demo, I’d better skip some functionality than show unfinished screens with default controls and sloppy menus and buttons.
Make it a team effort
Presenting the work of a whole team to the client is a critical part of a software project and it should be a “joint venture”, not one man show. Though I am the person who will do it, the whole team is involved. I’ve got many good advises and ideas from the developers and everyone feels responsible for the success or failure of the demo.
Tested and practiced
- Have a tested version. It is not always possible but I am trying to have a version for the demo on which development is not done in the last minute. The risk that a new feature can break an existing functionality which is already tested is high. So if some things are important for the demo I ask the team to do them earlier because often what is a minor detail for a developer, is an extremely important feature for the client.
- Prepare a script what to show. A demo goes much smoother and keeps me on the safe side when I prepare a scenario. Not that I am writing down all the things I am going to say but I make a list with what I will show in what order. Sometimes users start discussions when they see a feature, and it can take quite some time before you get back to the demo. The list will help you continue and prevents from missing to show an important feature.
- Your demo is well prepared, all set and ready but when you go to the client it does not go so smooth. You are looking for words, you are a kind of embarrassed to talk before all those people, you make wrong clicks. It happens to everyone in the beginning. For my first presentation I wrote down all the things I planned to say. Then my boss told me that it’s good but I have to learn it by heart and practice it many times in front of the mirror. I was sure it’s unnecessary but the first time I stood up in front of the mirror, I hardly remembered how to start. Whenever there is a chance to practice the demo – do it, helps a lot.
Tell them what they will see
Before I start the demo, I usually make a short overview what I am going to show, which features are finished and which still not, I also explain that I have a pre-defined data set and will restore the data so I can show as much as possible scenarios and cases.
A demo to the users should be addressed more as a dialogue than a monologue. This is the right time and place to get as much as possible feedback from the users. No matter how many sessions were made for defining the requirements (if such were done at all), it’s completely different when they see something ready. So if they have questions or suggestions, I encourage them to ask and talk. I prefer to do it during the demo, not to make the demo and then discuss – it is easier for them to give feedback immediately on a feature they see. I often hear that things which I considered completely unimportant are of critical importance for them, and vice versa – I am so proud of some fancy features we did, but they are not so much impressed.
Just listen and write down
What normally will happen is that users will start discussing new features or just ask why this is not there as they thought it is obvious it should be. It’s definitely not the right time and place to discuss that it was not specified and it is a change request and will be additionally estimated and planned. The person who explains a new request might not participated in defining the initial requirements. I am just making notes and asking questions to make it clear or to check if there is no contradiction with a previous requirement – happens quite often.
Speak their language
In custom software development, one of the big challenges is that in each project you go in different business areas and you have to learn and get knowledge. When you make a demo to a user group, they expect that you know and respect what they are doing. Often they will start discussing or explaining stuff which is not important for the development of the system, but it is not a good idea to tell them you don’t need those details. All the information I am getting at some moment can turn valuable and helps getting solid knowledge in the area.
Some of the demos I have to make are a day long so there are coffee breaks and lunch breaks. I try to use those breaks to talk informally with the users. Sometimes they approach me and start complaining about what is not OK with the current system they use, what problems they have and any other interesting stuff which can be of help.
Deal with the slips
No matter how well you are prepared, always something may go wrong. Everyone knows this is a demo so bugs and crashes are possible but still you have to react if this happens and keep the confidence of the people there.
If the system crashes I would say that those features I am just presenting were done lately and are not so extensively tested but in general it will work like requested and they will see it in the next test version we are going to deploy after the demo.
Though I am usually trying to keep to the prepared scenarios, someone will ask to try something different and it can go wrong. Then I’ll say – Good job, you found a bug we’ve missed! You have to join our team to help us. And the guy is so proud. In the next such situation the reaction will be – “Wow, I found a bug! I am good”
Good humor and assuring the audience that this is a small issue which will be quickly fixed is the way I am trying to approach those not so bright moments in any live demo.
Body and verbal language
Most of the demos with clients I am sitting behind the laptop, but still the body language is important as the users are looking at you, not at the screen all the time. I am trying to not gesticulate too much which I am doing in everyday life, to sit upright, to look at different people but always at someone while I am explaining something and not to look all the time on the screen.
Another thing I am careful about is the speed of talking and going through the demo. Sometimes I just forget that this is a new system for those people and they haven’t clicked and try it days and days on as I did so they can be easily lost.
When you make a demo, your attitude to what you are presenting is easily noticeable to the audience. If you care about that project, it will show. Maybe it is not relevant in any case, but when I am enthusiastic and when I believe that this is a good system we are developing, I can easily transfer my excitement to the users and convince them that though it is still not finished this is exactly the system they need.