How to Make the Most of Vendor
Demos
Reprinted from "IT Selection Strategies"
If you’ve ever had a vacuum cleaner salesman pour
sand on your carpet, you know
the power of a good demo. A compelling demo can make even the most
ordinary household appliance seem irresistible. Unlike vacuum cleaners,
computer systems are very costly and play a major role in the success of
your organization. Taking control of the demo process is critical to avoid
being "sold" a system based on superior sales ability.
The best way to take charge of the demo process is to
create a structured demo format, says Alan Ladd, a health care information
management consultant and president of The Ladd Group, Inc. Ladd always sends
vendors a script several weeks before the scheduled demo, describing which
features should be demonstrated.
In the case of a
hospital system, for instance, vendors might be asked to show how their system
works from admission to discharge. "We’ll ask them to admit a patient, show
how demographic information is captured, have them transfer a patient from one
bed to another, order lab and X-ray, generate a bill... whatever is important
to the selection team," says Ladd.
Without a structured approach, the committee ends up
comparing "apples to grapefruits" and is often confused by lengthy, disparate
presentations. "The baffle factor will leave you brain dead," he warns.
Before showing off their
system, Ladd asks vendors to give a background of their company and product,
including company history, corporate philosophy and culture, how much money is
spent on research and development, and the maturity level of the product being
demonstrated.
After the demo is
finished, Ladd says a polite goodbye to the vendor’s demo team and asks the
selection committee to remain in the room. While their memory is still fresh,
each participant completes a one-page evaluation form, ranking key features on
a scale of 1 to 5. Later, the forms are analyzed in a spreadsheet.
When looking at functionality, "the most important
thing is to see if the system can do it," says Ladd. "But it’s also important
to see whether it takes one screen or seven to perform the process."
The instant evaluation helps ensure that selection
team members don’t confuse competing systems, says Ladd. "Otherwise you find
yourself asking, ‘Now, which system did that?’"
Other tips from Ladd:
Limit demos
to three to four hours. Vendors can stray from the scripted features if
time permits, but time constraints help them stay focused.
Selection team members
should include a cross section of users, managers and technical people.
Have the same team members evaluate all demos.
Don’t allow vendor reps to
outnumber selection team members.
Ask vendors to use a
projector so everyone can see what’s being shown.
Save the demos for your
final two to five vendors--preferably only two or three. Use the RFP
process first to narrow down the pack.
Inform vendors they will be
evaluated on all the items in the script.
Don't allow vendors to demo
a product that is not currently ready for installation... no vaporware!
Don't make the demo the sole
determinant of your selection decision. The RFP, site visits, references
and other criteria should also play key roles.
Ladd’s structured approach helps ensure a fair and
quantifiable way to evaluate demos. But sometimes vendors do not provide
an accurate view of their product, whether deliberately or by accident.
Since most vendors are honest and straightforward, it’s unfair for a less
scrupulous vendor to gain an advantage.
Though detecting half truths or misinformation can
require the sleuthing skills of a Sherlock Holmes, you can avoid being misled
with some tips from experienced IT professionals:
Compare the RFP to the demo.
Let the vendors know beforehand they will be eliminated if they cannot prove
the functionality promised in their RFP responses. If the software must be
customized to perform a certain function, this should be clearly indicated in
their response.
Request that the vendor click on an icon or
button you are curious about. In some
cases, the demo is a shell that does not accurately reflect the software, and
clicking on a dummy icon will expose this.
Show vs. describe.
Don’t allow the vendor to tell you how something works in the actual
software.... ask them to show you. It could be the functionality is not really
there, so unless you see it, don’t believe it.
Beware of vaporware.
Unless you want to be a beta site, ask if the version being demoed is the one
that is currently available. Also, make sure the demoed version is the same as
the one used for the RFP.
Upgrade vs. New.
If you agree to view a demo of an upgraded version of the software, request a
document from the vendor outlining all the differences between the new version
and previous release. If the software is written in a different programming
language, it is essentially a new application and may not be sufficiently
tested. It may also be harder to find users of the new system for references
and site visits.
Listen to the techies.
Many demo teams will have at least one technical rep, who is the most likely
to give you accurate information. Since that person may have to provide
support to you after the sale, he will not want to mislead you about product
capabilities.
Keep your ears open. If members of
the demo team interrupt or contradict each other, chances are you are not
being told the "whole truth." For instance, your concerns about hardware
platforms or interfaces may initially be addressed by a newer member of the
team, then glossed over by a more seasoned rep.
Ask lots of questions.
The more questions you ask, the more likely you’ll
uncover contradictions. Also, active participation will help you stay awake
during lengthy demo sessions!
Leave time for hands-on.
Arrange for at least a half hour of "test driving" in
which members of your selection team can get behind the computer and determine
firsthand the system’s flow, ease of use and access to information.
Copyright 2003 On-Line
Consultant Software
|
|
Searching for complex application software or an enterprise
system?