Remember This HRM Software RFP?
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.
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!
[…] object diagrams (which are impenetrable for all but the fully initiated), is to use case-based (aka scenario-based) product evaluation, that’s clearly the only way to […]
[…] stage of being interfaced and given a more or less common user experience? This is where those “killer” scenarios (and do search my blog on that phrase to find many posts covering the actual scenarios) come in […]
[…] you can get right here. But you will need to learn how to turn these scenario topics into full scenarios and to conduct a full HRM delivery system platform lifecycle, from HRM and HRMDS strategy to […]
[…] next at the Carnival Naomi Bloom suggests we rid ourselves of those pesky RFP’s; a scenario package she says, is the way to […]
I found it interesting that Garrett posted the entirety of his own blog’s latest post here rather than providing just the link, but I appreciate his taking the time to comment. There’s clearly more on his mind than my suggestion that RFPs are a poor mechanism for assessing HRM software or even BPO capabilities and fit, so I’ll look forward to his elaboration on his blog of the several project failure themes in his comment here.
The scenario as well as the RFP approach has been around a lot longer than any of us — think Leonardo da Vinci… As long as the needs of the object (in this case, HRM) are being met (as opposed to desires and wants), scenario thinking has created many innovative approaches, solutions, services and products. And so hasn’t a well formed RFP… It is not the tools that makes or breaks a project – you can have all the right tools and still have a failed project…
When basic needs are overlooked and replaced or conjoined with desires and wants for the business, everything starts to get muddy and the dominoes can start to fall. There is also the issue of proper assessment from the very beginning. Too many times the assessment lacks proper discernment – the approach used is full of knowledge and can lack the wisdom of experience. With as many resources in the HRM field, you would think this is not a problem but too many think inside the box as it is more comfortable there…
For more than 18 years, my company has been called in more often than not to put out a fire that is blazing from the lack of focus of the basic business needs as well as a poorly performed needs assessment that set dominoes falling everywhere. We walk in and the client as well as their provider wants to get everything back on track. As the needs assessment come before the RFI, before the RFP and is early stages of the scenario thinking, the leverage point is found with the quality of the needs assessment…
No matter what approach is used – RFI / RFP and/or scenario — sticking to the basics with discernment always keeps everything and everyone on track. My own company has an approach that has been honed to just do that and is a combination of all three.
Dismissing the RFP outright (as well as the undervalued RFI)? There is a tendency to look at the tool that is not working properly as the problem rather than asking if the tool being used properly… Every tool has its demands and needs, and every time the tool is not giving the desired results we blame the tool and not the means in which that tool is being applied and dismiss the demands we wish to ignore as not relevant to the project. Many approaches start their focus on the middle, top or bottom while the bottom is usually ignored in too many cases we have seen (middle management, C-level and end users)… Make things painful enough for any of the three and the triple-braided cord of productivity at all three levels that can be had is broken…
Every tool today is not new — it has been revamped, re-invented, remolded into something different… We have tools that work when they are applied properly and many just say someone is skilled or lucky for a project to come to fruition successfully. What lacks in the projects that have the right tools is the wisdom to apply and use the tools properly… this is true for both the client and the provider. Too much faith is placed on knowledge too much dismissal is given to the experienced. Stand back long enough and we all see everyone return to the basics at a much later date.
The lack of proper discernment between what is and what is not a need for the business is more the reason for failures than anything else… I am a private pilot and the planes have all the right tools we need yet the monthly NSFB reports indicates more often than not that an accident was pilot error and not the fault of the tools used by the pilot. Business is no different…
Focus on discernment is not something we learn in college, from textbooks, from the web — we learn it through knowledge and experience… whether it be our own experience or the experience of others, discernment takes development… For my money? Merge scenario, RFI and RFP anytime… with a heavy dose of discernment throughout the project…
Tim, I’ve used scenarios for more than twenty years to (1) develop HRM business models and strategies, (2) develop HRM delivery system business models, strategies, and designs, (3) to evaluate/select/implement HRM software and BPO, (4) to design/develop specific HRM plans/policies/business rules/processes/workflows/you name it, and all of this has been done using a Scenarios “Starter Kit,” which can be deployed without too much specialized knowledge of domain models, and my much, much larger and licensable HRM Business Model “Starter Kit,” which does take much more training/specialized KSAOCs to use effectively. These same scenarios are the basis of the use cases that my software vendor clients develop as the product definition and so on. Scenarios are a terrific foundation for so much of what we do, and I really appreciate your feedback. Talk to you soon. Naomi
[…] Bloom’s recent posts (here and here) on scripted scenarios were a good memory jog to write this post. I have thought a […]
Naomi, I really like this idea. I’ve been using scenarios in my outsourcing advisory work for some time for three purposes:
1) as part of selection processes – helps support or even cut down those dreaded RFPs
2) as part of due diligence – helps expose misunderstandings wilful or otherwise
3) as part of making the contract work – building mutual understanding between teams of how to work
It’s a really good way to expose, for example, the boundaries of what triggers a change control process, or how a service issue would trigger a diagnosis and continuous improvement action.
I like your structure Naomi, thanks for sharing.