One "killer" scenario was me owning this cycle in college.
Finding best fit HRM software starts with knowing your organization’s needs and then “trying on” software via scripted scenario demos (I’ll get to that methodology in another post), looking for the best fit at the combination of time/money/risk/management attention/etc. that you’re willing to invest. Exploring that fit is the purpose of Naomi’s “killer” scenarios.
Naomi’s “killer” scenarios are those business situations (which modelers call use cases) which poke at the places where HRM software is most often weak, poorly thought out, inadequately tested, improperly modeled, suffering from poor architecture, etc. etc. They’re the corner cases that HR pros deal with on a regular basis, using manual workarounds of all flavors to cope when their software doesn’t.
Since one goal of most HRM software evaluations is to automate more fully the in-scope processes and business rules, it’s best to know up front where each product runs out of steam or worse. When carefully selected, with malice of forethought as are all of mine, “killer” scenarios reveal not only the functionality matches and mismatches between your needs and a vendor’s software but also the architectural weakness of that software. Getting at those architectural weaknesses is critical because, while vendors can often mitigate functionality mismatches, at least in the short run, they’re pretty much stuck with their architectural capabilities until they do a generational redesign — and so are you.
But where to start? This post focuses on one specific area of the fit question: to what extent does the HRM software in question make the same assumptions about workers and the organization of work as you do? Rather than checking out the plain vanilla stuff, which most reputable vendors handle well enough, “killer” scenarios focus on the kinds of workers and working arrangements that may once have been one-off exceptions or prevalent in very limited settings but which have become a common part of doing business. For a core HRMS, some challenging examples could include:
- Field sales or service employees whose migratory work locations ensure that their pay is taxable by more than one jurisdiction during a payroll period?
- Employees who are paid at different rates during the payroll period depending on what specific work they were doing at a particular time?
- Employees who telecommute and/or work exclusively from their homes which then become a work site for various regulations?
- When actually employed (WAE) employees who are paid on an hourly basis when they are called in to work, and are then paid at the rate that’s relevant for the work they are doing, but who also receive a pay period stipend and some benefits in exchange for holding themselves available?
- Employees who are handicapped in such a way that a government agency subsidizes a portion of their wages and/or benefits?
- Non-employee members of your workforce, from PEO-provided dual employment workers to independent contractors to leased employees to those consultants who never seem to leave, for whom you need to capture time and expense information as well as the details of what work these non-employees did in order to produce accurate headcount reports, forecast workloads, and determine the actual costs of getting work done via various staffing strategies? and
- All manner of changes to these arrangements during a payroll period as well as retrospectively, retroactively, and prospectively (as in forecasting)?
Today’s organizations rely increasingly on these and many more variations on the kinds of workers and working arrangements in order to deliver needed products and services as efficiently as possible and with agility to address changing business conditions. It’s a very dated notion to presume that our workforce consists solely of our own employees, that they work at a fixed organizational location, and are paid on either a fixed salary or fixed hourly rate basis for each pay period. But there is both commercial HRM software as well as proprietary outsourcing provider platforms designed around these outdated assumptions and then jury-rigged to accommodate some of the newer approaches.
With respect to the organization of work, some of the “killer” possibilities, again for a core HRMS, could include:
- Retail or other standalone operations (think chain restaurants, branch banking, chain hotels/motels, copy centers or gasoline stations or drying cleaning shops) that depend on having many part-time positions to meet the flow of work at each work location? With work locations which are near enough to one another to be within easy commute distance? With a target workforce which would prefer to have full-time pay and benefits even if it means taking two part-time positions, which could be at different work locations, even crossing business units and/or income taxing jurisdictions? With each such part-time position having its own performance evaluation, payroll cycle, work rules, and attendance standards?
- Organizing the work in teams, which may have multiple reporting lines, including “dotted” lines, rather than in strict hierarchical sections, departments and divisions? Teams that are led by an official manager or more or less self-directed? Teams come into being around projects or ongoing and organized around customers, transaction types, sales regions, etc.? Team-related work schedules, work rules, incentive compensation plans and work environment programs?
- Conducting business via matrices that allow you to organize simultaneously by country/geography, product line, customer/customer industry, and/or distribution channels? Employees organized within these matrices with a primary position that has adjunct responsibilities or with a series of assignments within the broader context of a position? With accounting for fully loaded labor costs across the various dimensions of these organizational matrices?
- Making use of those ancillary work roles to which we’re all assigned today but which don’t affect how we’re paid or how our labor costs are accounted for but which do require access to particular HRM delivery system capabilities, e.g. committee member who need access to committee distribution lists and member contact information, floor safety coordinators who need access to health and safety information on specific individuals as well to the details of who is working where at a particular time, and members of cross-functional teams who need training related to the project as well as tools for monitoring project resources and progress?
- One individual playing multiple concurrent work roles within the organization and one or more concurrent relationship roles with respect to the organization as a whole?
- Two or more individuals sharing the responsibilities of one position? and
- All manner of changes to these organizational designs and reporting relationships during a payroll period as well as retrospectively, retroactively, and prospectively (as in forecasting)?
Clearly HRM software must be able to hire/contract for, provide self service to, deliver compliance for, recognize, deal with, report on, payroll, and manage (in terms of the day-to-day work) all of the quite common variations described here — and cope with changes to these variations that occur during a payroll period as well as retrospectively, retroactively, and prospectively. If you really want to go for the throat, include a “killer” scenario in which one of these arrangements is permitted in some organizational units but not in others and then change those applicability rules retroactively.
The bottom line. There is simply no better way to evaluate the fit of software to your organization’s HRM and overall business needs than to craft and execute a series of scripted scenario demos. With great software, which is supported by an interrogatory configurator, prospects can do much of this scripted scenario execution themselves, without much vendor involvement, as suggested by my colleague Jim Holincheck in his referenced blog post. But whatever the sales cycle or demo tools, unless you’ve laid out your own scenarios and seen them executed, there’s no way to tell how, with what ease/robustness/required manual steps/etc. the candidate software will meet your business needs.