Let’s Kill Off RFPs!

 By: In Full Bloom - Naomi Wallace http://infullbloom.us/?p=602

In an earlier post, I suggested the use of scripted scenario demos to determine the fit between HRM software and an organization’s needs. But what are scripted scenarios and demos based on them? How do you create effective scenarios? And how do you avoid scenario overkill?


Scripted scenarios are very much like mini-Harvard MBA case studies in which you describe a specific business context, place a business situation within that context, and then ask questions about how the offered software would respond to that business situation. But instead of prospective software vendors submitting written answers to your questions, vendors are required to demonstrate exactly how their software responds. This type of scenario is called a scripted scenario because it provides a script for the vendor’s demonstration, not in terms of the mechanics but in terms of the customer’s view of the requested capabilities.

Think of these scenarios as calling for an automated dialogue between the customer, who might be an employee, contingent worker, manager, HR professional, or any other HRM stakeholder/user, and the vendor’s software. The most effective scenarios are those which not only demonstrate needed user capabilities but also help to differentiate between vendor products. And the secret to avoiding scenario overkill is to know, based upon considerable knowledge of HRM, the HRMDS and the competitive landscape of vendors, what can be safely assumed about vendor products, and what must be tested. For example, if the vendor is a long-established, national payroll software vendor, it’s reasonably safe to assume that their software can calculate accurately most withholding taxes (always being wary of some of the more obscure US local taxes and reciprocity agreements). But if you’re looking at talent management software, where beauty is definitely in the eye of the beholder and there is a rapidly evolving set of customer expectations, you will need to probe deeply to get at the heart of what a vendor can and cannot do.

A scripted scenarios package will be used internally and externally, but with certain details “hidden” in the external presentation. The initial sections are:

•Scenarios context — this is a short writeup describing the organization which will be the context for all of the scenarios which follow. It’s really a mini-version of your real organization provided as a microcosm within which the scenarios make sense. I find that it’s usually easier to write the scenarios first, at least in rough draft, and then collect here all of the facts that you found yourself repeating in more than one scenario as well as all of the other information that an outsider would need to make sense of your scenarios.

•Terms of reference — this is a glossary for terms used in the scenarios, whether industry or organization-specific, for which you’ve developed very precise definitions. What is an employee? A competency? A business unit? A cost center? If you’re using B&W’s HRM Business Model “Starter Kit” or the work of the HR-XML Consortium, you can include the relevant concepts and terminology here. Rather than presume that every reader will understand your terms as you intend them to be used, it’s best to define them here.

Then, for each included scenario, provide the:

•Context — the business context specific to this scenario;

•Scenario — the actual scenario;

•Basic demonstration points – with the expected business value or result by item or group because these are the specific points that the provider must demonstrate credibly to remain in the running;

•Extended demonstration points – with the expected business value or results by item or group because these are the specific points whose demonstration by a provider will help illuminate their competitive advantages;

•Evaluation expectations — this section is to be shared only internally and with evaluators because it describes how you will interpret what you see in the provider’s demo. What are you hoping to see and why? Are there particular architectural behaviors that you’re trying to illuminate? Specific underlying data structures or processes for which you’re looking? And don’t forget response times, elapsed times to closure, and response quality; and

•Evaluation notes — to be completed during evaluations and shared only internally and with evaluators.

Wrapped around your scenario package will be the processes and additional materials you use to identify potential providers, create your short list, orchestrate the scripted scenario demos, orchestrate your evaluation based on those demos, and then proceed through the rest of the vendor evaluation process. Whatever the rest of your software evaluation and “acquisition” process, an excellent scripted scenario package provides a solid foundation for comparing offerings as well as understanding the strengths and limitations of specific offerings. It’s easy to promise results; it’s much harder to demonstrate them.

You can use my “killer” scenarios from this recent post, as well as many more that I’ve written about in articles you can find on this blog and that I’ll be writing about in future posts, to get under the skin of and differentiate among current HRM software products. Always include those HRM business processes, business rules and data which have been a source of unneeded variability, complexity, misinterpretation, administrative effort and/or confusion, high cost, and/or personal frustration. Scripted scenarios should be very specific to your organization and expanded as needed to hit your HRM “hot buttons.” They must also be fleshed out so that evaluators really understand what each scenario means and what you’re expecting to see.

The bottom line. These aren’t easy to write well, and some vendors would much prefer to give you their boilerplate responses to the boilerplate RFPs that outdated consultants continue to favor rather than do the heavy lifting of setting up and demoing your scenarios. But the time you spend putting your scenario package together is time very well spent. Not only will scripted scenario demos help you make more informed package selections but they will also help you understand and plan for the implementation to come. So let’s get started!