Web Hosting

The scripted demo is the heart and soul of the evaluation process. What's the difference between a sales presentation (a canned demo) and a scripted demo? In a canned sales demo, you typically see only what the salesperson wants you to see. Salespeople usually spend a significant amount of time focusing on what they feel are the product's strong points, glossing over any shortcomings. By requesting a scripted demo, you detail to them what functionality is important to you and what you want to see. This puts you in the driver's seat and evens the playing field. Since all of the vendors will be addressing all of the same scenarios in the script, it will be easier for your team to evaluate each vendor's ability to meet your company's needs.

Let's look at the scripted demo in some detail. In order for the vendor to provide an effective scripted demo, you need to develop an accurate script for them to follow. You will need to draft a scenario that describes your problem and your needs. You do this by examining the business functions you want to address. Next, you'll need to describe what these tasks are and how they are currently done, and then describe how you envision them in the desired state using the vendor's solution—that is, your expected results. (Refer to Table 1 for examples of scripted scenarios).

(Click here for larger version)

Table 1. Sample scripted scenario (Collaborative Solutions Consulting, 2007)

In drafting your scripts, you'll combine the results of your UNA with any additional input from the user groups. Make sure these scripts represent real-world, daily scenarios. Even though these demos should be scheduled as daylong events, the demos will not be able to demonstrate every scenario in human resources (HR) and payroll. Focus on the processes that represent the most important functions, as well as the painful manual processes that you really need to automate. Here is a shortlist of considerations based on some typical scenarios:

• How does the vendor provide online help?
  
  
• How can workflow automation (with approvals) streamline your current processes to increase productivity and improve efficiency?
  
  
• How will the vendor's solution interface with other systems in your organization to improve data integrity and reduce redundant data entry?
  
  
• How does the vendor's solution handle what-if modeling?
  
  
• How does the new system handle “a day in the life of …” functionality for the HR and payroll staff? For example, how does it handle everything from a line manager opening a requisition, to scheduling interviews, all the way to taking applicant data and automatically converting it to employee data without having to re-key the information?

The RFI (including the scripted scenarios) should be sent to the vendors on a staggered schedule, providing each vendor about two weeks to prepare for the demo (counting back from the date the demo is scheduled). This approach ensures that no favoritism is shown to the final vendor. If you don't schedule in this way, the first vendor may have two to three weeks to prepare, while vendors scheduled for later may wind up with two or more additional weeks to get ready for their demos, putting the first vendor at a possible disadvantage.

You'll need to make it perfectly clear to all of the vendors that they may only demo functionality that has been released for general availability (GA). They should be instructed to not demo beta releases or versions that are still in testing. If you are interested in future functionality, try to program time at the end of the day so there is no possibility of erroneously believing that it is delivered with the current release the vendor is offering. Also, tell vendors that if they make any customizations to their delivered systems to accommodate any of the scripted scenarios, they must disclose this to your team, along with the estimated effort (time, resources, and funding) required to provide this capability on your system.

Demo Evaluations

Next, you'll need to provide the attendees a demo score sheet to use to evaluate each vendor's demonstration. The score sheet should outline the business functions being addressed, such as applicant tracking and recruiting, onboarding, benefits administration, training administration, payroll, etc. You will also need to provide a short description of the scripted scenarios, a description of your desired results, and a blank column for each vendor so that the evaluators can jot down their notes and scores regarding their impressions of how each vendor solved each scenario.

When all of the demos are completed, your decision should be based on the following:

• the functionality of the software;
• the degree to which it satisfied the needs of each user;
• the technical infrastructure required to operate and deploy the software;
• platform and database compatibility (if applicable); and
• adequacy of the hosting solution (if applicable).

Note that at this stage, cost should not be a driving factor because it has a tendency to cloud the evaluation process. At this point, your prime objective is to find a solution that satisfies the above criteria. Most of the vendors in a specific tier will be within the same or similar price range (depending on whether the cost is per module or based on a bundled solution). Once you've determined which vendor best meets your needs, it will then be up to you to build your best business case to support your decision. Pricing will be included with the vendor's response to the RFI.

Evaluating the Vendor's RFI Responses

Evaluating the RFI response is perhaps the most laborious and dreaded task of the entire evaluation process. RFI responses typically come in one or two binders, containing everything from marketing collateral and testimonial to detailed technical specifications and pricing. I recommend that you break down the response and delegate the reviews or comments to each of functional or technical sections addressed in the RFI. Then you should schedule a session that brings all of the reviewers together in an open forum to discuss their findings and concerns.

Now that the demos are complete and you have reviewed the responses to your RFI, it's time to tally up the scores from the scripted demo score sheets (along with any weighted factors you may have assigned) and review the comments collected. This will provide you with a mathematically derived, objective winner. This usually—but not always—corresponds with the popular vote. If it doesn't, you'll need to discuss why there is disparity. By this time, you should have produced a hierarchical listing of software (from most desirable to least desirable).

Dollars and Sense

Eventually, someone will ask the all-important question: “How much is this going to cost us?” At this point, you will have all of the vendors' pricing structures in a comparison spreadsheet. The pricing that was requested should reflect the total cost of ownership, including required hardware and software, maintenance, implementation, training, and hosting. If you don't have carte blanche (full power to decide)—and you probably won't—you will have to make a solid business case to support and justify your selection.

First, you'll want to explain that the proposed HRMS-payroll system is not simply a repository of mandated personnel- and payroll-related information. The system should be viewed as an essential management tool that can be used by all decision makers in developing the organization's key strategies and business goals.

It will be your responsibility to demonstrate how the system will provide management with tools to perform staff budgeting and forecasting better and faster, as well as what-if analysis for compensation and benefits. You will need to show how the entire HRMS-payroll staff will be able to work more efficiently and be more productive through the automation of many of the current manual and repetitive tasks. If all of these factors are addressed and considered, your organization's key decision makers should see a greater necessity for the preferred system, even if it is more expensive than the other systems evaluated.

To prevent your case from being rejected, you need to develop a strategy that will capture the hard costs and savings of a new system in addition to its soft costs and savings.

Hard costs are relatively easy to define and include software, related hardware (including new workstations), maintenance fees, training costs, and consulting fees (for the implementation). Hard savings can be calculated in reduced head count; outsourced functions brought back in house; funds saved by not having to maintain an archaic legacy system; reduced printing and mailing costs through Web-based, self-service benefits open enrollment instead of paper enrollment; and the elimination of interactive voice response (IVR) and paper forms to make changes to employee records in favor of the new employee and manager self-service.

Soft costs and soft savings are tougher to get your hands around. Soft costs are incurred when an organization doesn't implement a new system that allows it to realize soft savings, such as

• the use of effective dating (which streamlines the process of time-sensitive data entry, especially pay- and benefits-related data, such as benefits deductions and pay increases);
  
  
• the use of online performance appraisal processing (which streamlines the process, reduces the likelihood of forgotten appraisals, and provides timely input to payroll for raises);
  
  
• the ability to use what-if analysis in forecasting staffing needs and budget analysis;
  
  
• the automation of benefits enrollment by employees using self-service, so that this information does not have to be captured on paper and then keyed into the legacy system by the HR or benefits staff.

If it wasn't clearly defined in the response to your RFI (and some vendors are very good at glossing over some of the more obscure costs), you'll want to ensure that you ask vendors these questions:

• Is the listed price for the software based on a la carte selection (the total of each separate price of each feature or function) of the modules you picked or a bundled pricing strategy?
  
  
• If it is not a bundled price, what is the vendor's per module pricing strategy, and what is its multiple product discount?
  
  
• Is the pricing based on actual named users, an unlimited user's license, or the number of active employees tracked in the database?
  
  
• Does the listed price include installation of the software and implementation of the system?
  
  
• Does the price include a fit/gap analysis or design sessions?
  
  
• Are the fees for software application maintenance listed as separate line items?
  
  
• Will you require any third party or ancillary software or hardware, such as scanners for resume processing, time card readers for time capture, or special printers for printing paychecks in house?
  
  
• How did the vendor price the development of required electronic interfaces?
  
  
• Did you receive a separate cost breakout for data conversion?
  
  
• Does the cost of the system include vendor-conducted application training?
  
  
• Has the cost of any additional hardware been factored in (that is, new database, Web, or application servers; upgraded or new workstations; additional bandwidth of Web access for self-service, etc.)?

Reference Checks and Site Visits

No software package or implementation is without flaws. It doesn't cost you anything (other than a few long-distance phone charges) to speak with someone who has implemented your preferred software package. Ask your software vendor for several references, preferably organizations that are within your industry and similar in size. Ensure that you speak with representatives from both sides of the house—functional and technical—in order to get the full story. Ask them questions that will make a difference in a successful implementation. You'll want to focus on the following key points:

• performance issues of the system;
• duration of the implementation (from installation to going live);
• challenges encountered during the implementation;
• adequacy of the training provided by the vendor; and
• vendor support during and after the implementation.

Along with the reference checks, try to visit at least one site in person. Seeing your preferred software solution in action has much more impact than seeing it as a demo. In addition, speaking with actual users will provide you with considerable insight into the general direction of your future implementation and operations. Take advantage of this opportunity to absorb everything you can. By hearing the trials and tribulations of other organizations' projects, you may be able to capitalize on their errors and learn from them.

Conclusion

As the title of this article suggests, “it ain't rocket science,” but evaluating and selecting a new HRMS-payroll software solution does require a considerable amount of planning, execution, and monitoring. If you put together a solid plan and follow it, you can make the right decision regarding your next system.