In the first installment of this series, I provided a few observations -- and referenced some useful observations from Gartner's Debbie Wilson -- on the ideal place for fitting product demonstrations into procurement/sourcing technology selection. In this second post, I'll share handful of lessons I've learned over the years to get the most out of demonstrations in a real-world situation (i.e., when you're the prospect contemplating the purchase of a solution rather than how technology vendors typically brief or educate analysts and channels about their products, in a far more generic manner, except when based on an actual prospect/customer evaluation).
To begin, I think the key to getting the most from demonstrations is to require vendors to demonstrate a range of product responses to actual business scenarios. In other words, take the concept a step further beyond what Debbie recommends in her previously referenced post (which is nearly right on the money). My colleague and friend Brian Sommer of firm Vital Analysis and ZD Net fame, suggests that the only way to learn about provider solutions are to request a series of demonstrations based on specifically prescribed scenarios.
Brian suggests in one such guide, "Business case scenarios are a technique used to identify particularly difficult, unusual or complex business problems and relate them to solutions providers. When used in software selections, scenarios help focus software demonstrations away from mundane, non-differentiated function and feature demonstrations. Instead, the value of scenarios comes from the focus they provide on the most important business problems of the customer. When all providers are required to respond to the same scenarios, it prevents the providers from showing the functions and features they want to demonstrate and makes them respond to the scenarios that matter to you."
Brian also suggests that, "scenarios work best when they are developed across many dimensions. Each scenario should originate from a given role or perspective within the company. Scenarios should consider a number of environmental, process, technology and strategy issues. The more complete a scenario is the more valuable it becomes. Great scenarios clearly communicate a key business problem. The more specificity a scenario contains, the better a provider can respond to it."
Further, "Scenarios effectively highlight how different providers' solutions will (or will not) solve material business issues of your firm. The chief alternative to scenarios is the function/feature checklist. While these can be scored and weighted, this technique does little to illustrate the lack of elegance present in some solutions. More to the point, function and feature checklists do little to illuminate how a process works but scenarios do. If you want to see how a prospective provider handles some of your more vexing project-based processes, document them in a scenario. A checklist provides a glimpse into a process' components provided you knew to list them all."
Stay tuned for the next installment in this mini-series when we look at how to write a scenario, using the sourcing area as an example. And in the meantime, if you're either a practitioner or a vendor/consultant looking to hire an adviser to help you (or your client) create the right set of scenarios to think through complex issues, I can't recommend anyone more than Brian Sommer. You can reach him directly: brian (at) vitalanalysis (dot) com.