R2ISC Associates |
Unfortunately
most demonstrations tend to be nothing more than glorified sales
presentations put on by a clever sales representative.
The salesperson will try to control the demonstration by showing
off what their system does best, glossing over its imperfections.
If you raise a question about a feature or function that the
software package does not have the salesperson may say, "lets leave that for
later", but unfortunately later may never come because you may have
forgotten about it or its time to leave and the salesperson will tell you,
"trust me". If the
demonstration is conducted by a good salesperson, by the end of the
demonstration you are left with a warm feeling regarding the package and
the sales representative. But
there is one thing that you do not get out of the demonstration whether or not the package being demonstrated meets your
company's needs.
In order to turn the demonstration from a sales pitch to a tool for determining if the software package meets your requirements, you must take control of the demonstration. To do so you must tell the vendor exactly what you expect to see during the demonstration, and how it will be judged. You tell the vendor what you want to see by giving them a "script" to follow:
The script should follow the normal flow of business events
Every
feature and function that you require should be included in the
script
The
data to be used in the demonstration should be real company data
This
will allow personnel attending the demonstration to feel more at home and
better able to concentrate on the package's features and functions.
The data can be entered by the vendor in advance of the
demonstration from files you provided. Make sure that you provide enough data to show each required
function.
For
example, suppose that a firm requires a package that will permit an
employee to sign onto the system and access the ACCOUNTS-PAYABLE file
without being able to update it. Also,
the employee is allowed to access the EMPLOYEE file but should not be
allowed to see his own record or the PAY field on other records.
Finally, the employee should not be able to access the BANK file at
all.
A script for this portion of the requirements, dealing with security, would read as follows:
Sign
on as John Smith
Try
to access the BANK file (this should be denied)
Try
to access the EMPLOYEE file (this should be allowed)
Try
to access a record on the EMPLOYEE file (PAY field should not appear)
Try
to access John Smith's record (should not appear)
Try
to access the ACCOUNTS-PAYABLE file (allowed)
Try
to update or add to the file (denied)