Organising software demonstrations

Software demonstrations can be very impressive, by focusing on the software's strengths and glossing over weaknesses. Beware losing sight of the basics. Will the software actually handle your type of business and its core needs?

It's therefore important to:

1. Have a clear summary of requirements
2. Organise and control the meeting to see how well the software covers those core needs, and flush out any key weaknesses

Essentials

Whether you are changing systems, or trying to make better use of existing systems, it helps to have:

1. Senior management commitment and support
2. A clear vision of scope, benefits and requirements in a "User Requirements Specification"
3. Suitable software and support
4. Implementation experience

These and other key factors are detailed below.

Testing Testing

Custom-written software obviously needs to be tested. But what's needed for software packages?

It's easy to assume that a package will have been thoroughly tested. Sadly it is rare for packaged software to be bug-free for three main reasons:

1. It will be unlikely that the software will have been tested with your specific set of systems parameters.
2. For new versions of software, authors are dependent on end-user "beta" sites that are prepared to test software before general release. The extent and depth of testing is dependent on the organisations involved, and restricted by the time they have available.
3. Not all identified bugs will have been fixed. Are any significant to your business?

Examples of bugs that I've seen go live include:

• Payment generation routine that didn't work. Cheques had to be raised by hand, and the delay meant some supplies were put on stop.
• System set-up problem that resulted in changes being lost. Training sessions became farcical.

Therefore testing of at least the key functions is worthwhile. This also provides the opportunity to develop and test the associated manual procedures. Are instructions clear, concise and complete? Printing can be a problem - does it work as expected?

By collecting representative transactions during production of the User Requirements Specification, the suitability of the software to cover the range of business can be checked. This should include checking if and how to make changes, for example if a customer order has to be changed or corrected.

A testing plan that includes each process, such as product set-up and credit note production, helps to ensure the system will be fit for purpose once implemented.