12 Aug 2013

Tips on customer demonstrations during software development (Part 2)

Category:
  • Testing

This blog post is a continuation of the original post with the title: 

Tips on customer demonstrations during software development (Part 1)

Preparation

It is crucial that you know the functionality that you are demonstrating very well.  If you don’t, then it’s better to have someone else do the demo.  If you do not have confidence in showing people around a functional area then you clearly send signals to the customer that they should not have confidence in the deliverable and/or development team.  This may sound obvious but in an agile arena especially, you may not have had much time with the functionality before the customer gets their first glimpse.  A demo should be well structured, planned and rehearsed.  If you are not in the position of being able to answer technical questions resulting from the demo then ensure a suitably qualified colleague is.  Arrange for notes to be taken to record issues that arise.  Above all, run through the practice demo in the exact build and environment that will be used for the actual demo.  So much can change, data you had set up has been changed or is missing, configuration settings have been altered, or new bugs may have been introduced that you are not aware of. If you find a bug just before the demo, then you can make a call on whether you can avoid that specific defect trigger in the demo, cancel, or be on the good foot and point it out to the customer.

Delivery

Structure the demo in such a way that the customer can easily see the actions and consequences of functionality from a use case perspective.  Be measured and controlled; speak clearly, describe your next intended action calmly before proceeding to slowly navigate through, clarify the expected results, show that negative conditions and error handling have been captured in development.  Despite being measured and controlled, you should avoid coming across as too dull and robotic, it is ok to inject some personality into the demo, just take them on a smooth journey rather than the audience struggling to keep up with narrative and rapid mouse clicks that appear disjointed and difficult to follow.  Try to structure the demo so that there is a Q and A session afterwards rather than constant interruptions to the flow of delivery. 

Dealing with problems

There are many issues that can arise when giving a demo.  All should be dealt with calmly and openly.  The worse thing that you can do in a demo is leave the customer with a sense that you are not being honest.

If you know a bug exists in the system, and you know you are likely to encounter it during the demo then be pro-active and inform them.  This is software development, there are always bugs.  If the customer sees a defect in the demo before you, then it is always going to knock confidence in the deliverable.

Despite the design process, the demo is the first glimpse the customer has of a working solution.  They may identify that what is being developed does not meet their needs.  This may be through lack of consultation with all stakeholders or a lack of understanding of requirements from the development team.  Always know what was asked for, let the customer make changes where required but it is very important to recognise when scope creep starts to take place.  Demos are a good opportunity to justify further enhancements so be pro-active in pointing out opportunities or deficiencies where beneficial to do so.

There will undoubtedly be situations where the demo leaves the customer disappointed for a variety of reasons.  In such circumstances; always be professional, make every effort to demonstrate that you fully understand their concerns and discuss a plan of action to remedy the situation.

Go Back

Please enter your details and we will aim to call you back the same day.