Post Chronology

March 2024
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031

InFullBloom Archives

Categories

Speaking Engagements

UPCOMING
Predict and Prepare sponsored by Workday 12/16

PAST BUT AVAILABLE FOR REPLAY
The Bill Kutik Radio Show® #171, 2/15
The Bill Kutik Radio Show® #160, 8/14
The Bill Kutik Radio Show® #145, 1/14
Workday Predict and Prepare Webinar, 12/10/2013
The Bill Kutik Radio Show® #134, 8/13
CXOTalk: Naomi Bloom, Nenshad Bardoliwalla, and Michael Krigsman, 3/15/2013
Drive Thru HR, 12/17/12
The Bill Kutik Radio Show® #110, 8/12
Webinar Sponsored by Workday: "Follow the Yellow Brick Road to Business Value," 5/3/12 Audio/Whitepaper
Webinar Sponsored by Workday: "Predict and Prepare," 12/7/11
HR Happy Hour - Episode 118 - 'Work and the Future of Work', 9/23/11
The Bill Kutik Radio Show® #87, 9/11
Keynote, Connections Ultimate Partner Forum, 3/9-12/11
"Convergence in Bloom" Webcast and accompanying white paper, sponsored by ADP, 9/21/10
The Bill Kutik Radio Show® #63, 9/10
Keynote for Workforce Management's first ever virtual HR technology conference, 6/8/10
Knowledge Infusion Webinar, 6/3/10
Webinar Sponsored by Workday: "Predict and Prepare," 12/8/09
Webinar Sponsored by Workday: "Preparing to Lead the Recovery," 11/19/09 Audio/Powerpoint
"Enterprise unplugged: Riffing on failure and performance," a Michael Krigsman podcast 11/9/09
The Bill Kutik Radio Show® #39, 10/09
Workday SOR Webinar, 8/25/09
The Bill Kutik Radio Show® #15, 10/08

PAST BUT NO REPLAY AVAILABLE
Keynote, HR Tech Europe, Amsterdam, 10/25-26/12
Master Panel, HR Technology, Chicago, 10/9/012
Keynote, Workforce Magazine HR Tech Week, 6/6/12
Webcast Sponsored by Workday: "Building a Solid Business Case for HR Technology Change," 5/31/12
Keynote, Saba Global Summit, Miami, 3/19-22/12
Workday Rising, Las Vegas, 10/24-27/11
HR Technology, Las Vegas 10/3-5/11
HR Florida, Orlando 8/29-31/11
Boussias Communications HR Effectiveness Forum, Athens, Greece 6/16-17/11
HR Demo Show, Las Vegas 5/24-26/11
Workday Rising, 10/11/10
HRO Summit, 10/22/09
HR Technology, Keynote and Panel, 10/2/09

Adventures of Bloom & Wallace

a work in progress

Let’s Kill Off RFPs!

Remember This HRM Software RFP?

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.

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!

9 comments to Let’s Kill Off RFPs!

  • […] 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 […]

  • Naomi Bloom

    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…

  • Naomi Bloom

    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.

Leave a Reply