I
jumped right into the topic of product demos last time because it was fresh on
my mind after seeing another bad demo by a vendor. I skipped over the pre-work
of documenting your requirements prior to looking for a new product.
Understand
where you are headed
Prior
to looking for a new product, in our case a Learning Management System (LMS),
our Education team took the extra time and effort to document a 12 - 24 month
roadmap of where they were headed as a team, the types of things they wanted to
offer (instructor-led online classes, on-demand prerecorded classes, integrated
learning opportunities within our core product, etc.) and how they would
measure success. Although time consuming, it was an important exercise to
complete prior to jumping into vendor evaluations.
Identify
your core requirements
The
next step is to take the roadmap of where you're headed and create a list of
functional requirements. Keep the list focused on your core
requirements. Listing every possible feature and function of the "ultimate" product
is unrealistic and will confuse the evaluation process. Focus on the things
unique about your needs in your situation.
If
you have the time, break the list down using the MoSCoW method. Although originally used to
prioritize requirements for new software development I have used it in other
situations. MoSCoW stands for:
M
- Must have
S
- Should have
C - Could have (or Nice to have)
W
- Won't have (I prefer calling it Want to have)
The
Must Haves are self-explanatory. Perhaps you feel the product must be a hosted,
Software as a Service, solution. Then list it in your Must Have column. Avoid
the temptation to place all of your requirements into the Must Have column. The
perfect product simply does not exist, but a product that meets your core
needs, plus some, probably does.
Should
Haves are just beyond your core requirements and may contain features that the
vendor can fulfill through other means. For example, when we first launched
Fellowship One we didn't offer report writing functionality but we provided a
service to create reports for the customer on their behalf for free. (Ultimately,
this has actually helped because many times the church doesn't have the skilled
resources to design the complex reports they desired even if they had report
writing capabilities)
Separating
the Could Haves (Nice to haves) and Want to Haves is difficult. More often than
not, I do tend to lump them together. The items on this list should help to
evaluate where the vendor and product is headed. Is the vendor actively improving
their product? Are they leveraging new
technologies where appropriate?
Share
the list
Now
that you know your core requirements you can probably narrow down your list of possible
vendors significantly by checking their website and evaluating what others say
about them through blogs and product reviews. Once you have a short list (3 to
5) of vendors, then share your list of requirements with them well ahead of
seeing a demo. Then see how they react.
Are they open and honest about any
shortcomings they may have when compared to your list? Did they address your
requirements upfront in their discussions and in their product demo? Do they take the time to understand your
requirement more fully? Or do they simply
stick to their standard demo, unable to waiver from their pre-defined script? How the vendor reacts to your requirements
during the Sales stage will tell you a lot about how attentive they'll be to
your needs once you sign the contract.