R2ISC Associates

Scripted Demonstration

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:


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: 

  1. Sign on as John Smith

  2. Try to access the BANK file (this should be denied)

  3. Try to access the EMPLOYEE file (this should be allowed)

  4. Try to access a record on the EMPLOYEE file (PAY field should not appear)

  5. Try to access John Smith's record (should not appear)

  6. Try to access the ACCOUNTS-PAYABLE file (allowed)

  7. Try to update or add to the file (denied)


Home  | Services | R2ISC Process R2ISC Matrix | Links  | FAQ  

White Papers | Contact Us | Services