How should you conduct a project management software demonstration? How can you obtain the most value from it and have it be a productive session instead of a useless dog and pony show?

In our last post, I suggested that you use BOTH a software demonstration and a trial (when possible) to evaluate software. They both have value. In this post, let's delve into software demonstrations.



General Observations

Software demonstrations should be a two way street. They should not be a session where the vendor simply shows all of the "cool things" the software can do. They also should not be a customer asking the vendor to show this and show that without the vendor being able to interject anything. This is an opportunity for the customer to learn from the vendor how they can achieve their objectives, for the vendor to learn from the customer in more detail what the objectives are, and for both parties to learn how the other party conducts itself and how to work with that party. It really can be a great opportunity.

Project management software demonstrations are often done remotely via an online web meeting. Gone are the days of a sales person (or team) coming on site to conduct a demonstration. That does happen, but unless it is a high-end item, it is rare. That is good and bad. It makes it easy to setup a demonstration and to quickly pass information. However, there is nothing quite like meeting face to face. Nevertheless, that is how things work today.

The Don'ts of Software Demonstrations
1. Do not ask for a software demonstration without communicating your needs and requirements to the vendor. What are they going to show you? The only thing they can show you is a dog and pony show which is of limited value to you. Software today can be varied and have a lot of options. If the vendor doesn't know what to show you, you may or may not see what you need to see.

2. Do not fail to invite the right people to the demo. If you are following a good process, make sure that the right people are in the demo so that they can also observe, learn, and ask questions. It may be appropriate to sometimes walk through an initial demonstration and then if it "passes" bring in a broader group. However, make sure that you are not asking for multiple demos just because you forgot to include someone.

3. Do not schedule a demonstration without the time to digest it. Don't have it scheduled up against two other meetings. You will lose a lot of the focus and value.

The Do's of Demonstrations
1. Communicate your requirements and objectives to the vendor. Tell them what you would like to see. Do this before the demo so that the vendor has a chance to digest it and plan for it. Some vendors will not do this, but some are very interested in helping you meet your objectives.

2. Better yet, communicate a process flow to the vendor. What do you see your process being? What is the process for starting a new project? How will progress be reported? Do not communicate how the tool will work - that's for the vendor to recommend. So you may need to be somewhat generic - but focus on the overall process you'd like to see.

3. Schedule enough time. Depending on the software, a demonstration could last from 30 minutes to a couple of hours. The project management software demonstrations we do typically last less than an hour, but you are still talking an hour or more when you start digging into deeper questions or more complex requirements. You should also have some time after the demo to summarize what you've learned and collect feedback from people. This should be done immediately after you get off of the phone.

4. Update your comparison chart with the information that you have gleaned from the demonstration. Include information on how easy the vendor was to work with, were they flexible, did they try and work with us or were they just trying to sell software?

5. Try to have demos from multiple vendors scheduled closely together. If you space them too far apart, they will start to blur together and you will forget key aspects unless you are very good at documentation.

6. Be prepared to have two demos for a single software tool. The first demo may be good, but the second demo should be great because both parties should understand the requirements and needs better. The second demo should be very close to the actual process you would use after implementing the software.

Follow those principles for a productive, value-added experience.