HR technology is touted as an essential tool for strategic HR, but justifying the cost of systems has become problematic for executives
In the past few years, some HR departments that bought new HR systems have been left with the distinct feeling that all of the headaches and hard work may not have been worth it after all. They are not seeing the expected return on investment (ROI).
That is not because it does not exist. It is more likely that organizations aren’t looking in the right spots to find it. Or, they are taking a wrong approach to maximize the return. Here are some reasons why.
Business case
Most organizations don’t create a complete business case for the acquisition or implementation for software. In fact, many organizations don’t regularly produce a business case for any significant expenditure. Why? Because completing a full analysis of existing business processes and systems is time-consuming.
Further, many organizations don’t have staff with the skills to do the necessary analysis. And believe consultants are too costly. True, the costs of a consultant may seem daunting, but the truth is most HR professionals will select and implement new software only once in a career. Selection and implementation is almost always a new experience. This may sound suspect coming from a consultant, but using a consultant whose primary focus is software selection is often an excellent investment, with a tangible return.
Key predictable benefits include increases in efficiency and effectiveness. Accepted ratios, such as net present value, internal rate of return, pay-back period, and cost of money, only produce accurate values if the original assumptions and numbers are also accurate, which is more likely with a consultant expert at divining these figures.
There is another common problem to drafting a clear business case. Very few organizations have extensive human resource, payroll or human resource management metrics. Without objective metrics before implementation it is very difficult to say if there is a real return after.
Is the organization tracking the quality, quantity, cost or time of various HR or payroll processes? Are best standards of practice or metrics being used?
And even if the organization has metrics, are they used to create quantifiable measures so that success can be measured? Without specific targets success becomes very difficult to demonstrate.
And what about achieving ROI through HR staff reductions? There are some organizations that are over-staffed and will be able to reduce costs and head count through automation. But in most cases the organization is already operating at reduced levels. Rather than eliminating salary, it is often more realistic to assume that staff, or the costs of staff, are re-allocated to less administrative, more value-added functions.
Productivity gains through improved efficiency and effectiveness don’t accrue automatically. The software is merely a tool. The real challenge lies in using the software and restructured business processes together as they were intended to be used. Benefits don’t necessarily come from a simple reduction in HR head count.
When an organization does create a business case, it is often slanted to support project acceptance. Future benefits are exaggerated while costs are minimized. This is not done maliciously. It’s just that staff who prepare the business case always want to see the project approved.
Aside from misconceptions about staff reduction, the most common problem is when organizations take too narrow a view of the costs of a new system, limiting the estimations to the licence and basic implementation. A more thorough approach takes into account the complete cost of ownership, including hardware (multiple new servers, for example), databases, customization (there is almost always some), maintenance and a more complete view of training (see below).
HRIS versus HRMS
Did the organization only look for a human resources information system (HRIS) used strictly by HR and payroll? If it is, it’s likely that the selection process focused on HR and payroll issues, and not on general business challenges. That isolates HR instead of making it more integrated with the rest of the organization. HR professionals need to be working with their colleagues across the organization to help solve complicated human resource challenges. This usually requires a human resource management system (HRMS), which enables some degree of self-service.
What does the absence of self-service mean for ROI? Perhaps the most important is that managers won’t be using the software. This is a missed opportunity to have managers easily and efficiently do more HR administration tasks, freeing HR departments to dedicate time and effort to human resource management rather than administration.
Software selection process
Choosing the right software in the first place is an essential prerequisite for meaningful ROI; thus the selection process should be viewed as all important. Mistakes here can leave the company with software that does not deliver what the organization needs most and, therefore, is unable to effect the meaningful change that makes new technology worth the investment.
Often the selection team jumps into a software demonstration without involving staff throughout the organization in developing a set of detailed requirements.
Looking at new software offerings is fun and interesting. But it is usually a bad place to start. Instead of first determining the wants and needs of the organization, seeing a demo tends to push the client into defining requirements based on a vendor’s software. That makes it very difficult to compare other software.
Once it is time to go through a demonstration, several vendors should be brought in so that apples can be compared to apples.
There are many good products on the market. None of them are perfect, and they all have their own eccentricities and methods of handling certain situations. Technical approaches vary widely and pricing even more so.
Real-life scenarios should be used to test the software. About 90 per cent of any organization’s requirements are likely standard; after all, there are only so many ways to hire or pay a person. It is the other 10 per cent that needs clear focus.
What are the conditions imposed by a labour contract, by an acquisition or by old equipment? These situations should be outlined in detail so that it is clear whether or not the software can handle it. If not, the company has to ask if the cost of customization is worth it or what business processes must be changed.
There are three general strategies used in software acquisition. The first is to buy “vanilla” software — software that requires nothing added to the core offering.
The second is to get software that meets some needs and then either customize it extensively, or supplement it with specialty software.
In both these cases the primary problem is there is no strong match between requirements and the selected software. The likely motive is to minimize costs.
People think they can spend the minimum now and fill the gaps later, with future software development or another product, often from a different vendor. These price-based decisions are often false-economy and usually end badly.
The third — and best alternative — is to plan on a vanilla implementation, recognizing that some limited customization will be required. Minimal customization is a goal worth pursuing because any change to the software increases the maintenance.
In most cases business processes can be altered to minimize changes to the software. But there are times when only software change will accomplish the desired results, and therefore the expected ROI. That should, however, be an infrequent recourse.
When considering new software it is important not to become overly fixated on the sticker price. It should go without saying that organizations should pay only what they can afford for anything, particularly software. But there will be other costs involved to make the software as effective as possible.
Many organizations that spend the entire budget for the core product leave little or nothing in the bank for implementation issues, which may require new hardware or training.
And remember to do sufficient reference checking. Every vendor that has been in business has references — both good and bad. Usually most of the bad references reflect a poor implementation, which should be pinned on the client organization, not the vendor.
Implementation
Many organizations spend too much time and all their money just acquiring software, and end up with problems in implementation.
When organizing implementation, it’s important to accurately plan and budget the entire implementation. Often the business case is completed before a detailed implementation plan is created.
This forces the project manager into shoe-horning the implementation plan into unrealistic timelines, and results in final tasks being under-funded and rushed.
It is important to take enough time to restructure business processes and, wherever possible, keep software customization to a minimum.
Implementing new software without reviewing and changing business processes is a waste of money. But many organizations skip business process change to implement more quickly. Such decisions represent false economy.
Staff should also get training that covers the restructured business processes, software operations and how the two will now be integrated. But the reality is training is very often badly done.
Typical software implementation projects run over budget and longer than expected and, as one of the last considerations before “going live,” training is often rushed and under-funded. Most significantly, it is usually focused on the software, and not the entire package of software plus business processes.
Organizations buying a new system must be prepared to take the time necessary to implement properly. The bulk of implementation may only take 12 to 26 weeks, but in terms of doing a complete job most successful organizations report that complete implementation should take at least two years.
Unless the organization is replacing one robust system with another (which raises its own set of issues) new systems usually call for changes to the organizational structure to support the new system.
The roles and responsibilities should include a functional help line, report support, ongoing testing (of new releases), and so on. How well this is done can make a big difference in the day-to-day operation of the system, and therefore the hard and soft pay back.
If you don’t know where you are going, then one road is as good as another. Organizations that expect to realize a positive, or better yet, a significantly positive ROI from a new HRMS need to approach the entire project professionally. Proper preparation will yield realistic expectations and tools to measure success.
Ian Turnbull is managing partner of Laird & Greer Management Consultants. He is past-president of both the Canadian Council of Human Resource Associations and the International Association for Human Resource Information Management. He may be reached at [email protected] or (416) 618-0052.
That is not because it does not exist. It is more likely that organizations aren’t looking in the right spots to find it. Or, they are taking a wrong approach to maximize the return. Here are some reasons why.
Business case
Most organizations don’t create a complete business case for the acquisition or implementation for software. In fact, many organizations don’t regularly produce a business case for any significant expenditure. Why? Because completing a full analysis of existing business processes and systems is time-consuming.
Further, many organizations don’t have staff with the skills to do the necessary analysis. And believe consultants are too costly. True, the costs of a consultant may seem daunting, but the truth is most HR professionals will select and implement new software only once in a career. Selection and implementation is almost always a new experience. This may sound suspect coming from a consultant, but using a consultant whose primary focus is software selection is often an excellent investment, with a tangible return.
Key predictable benefits include increases in efficiency and effectiveness. Accepted ratios, such as net present value, internal rate of return, pay-back period, and cost of money, only produce accurate values if the original assumptions and numbers are also accurate, which is more likely with a consultant expert at divining these figures.
There is another common problem to drafting a clear business case. Very few organizations have extensive human resource, payroll or human resource management metrics. Without objective metrics before implementation it is very difficult to say if there is a real return after.
Is the organization tracking the quality, quantity, cost or time of various HR or payroll processes? Are best standards of practice or metrics being used?
And even if the organization has metrics, are they used to create quantifiable measures so that success can be measured? Without specific targets success becomes very difficult to demonstrate.
And what about achieving ROI through HR staff reductions? There are some organizations that are over-staffed and will be able to reduce costs and head count through automation. But in most cases the organization is already operating at reduced levels. Rather than eliminating salary, it is often more realistic to assume that staff, or the costs of staff, are re-allocated to less administrative, more value-added functions.
Productivity gains through improved efficiency and effectiveness don’t accrue automatically. The software is merely a tool. The real challenge lies in using the software and restructured business processes together as they were intended to be used. Benefits don’t necessarily come from a simple reduction in HR head count.
When an organization does create a business case, it is often slanted to support project acceptance. Future benefits are exaggerated while costs are minimized. This is not done maliciously. It’s just that staff who prepare the business case always want to see the project approved.
Aside from misconceptions about staff reduction, the most common problem is when organizations take too narrow a view of the costs of a new system, limiting the estimations to the licence and basic implementation. A more thorough approach takes into account the complete cost of ownership, including hardware (multiple new servers, for example), databases, customization (there is almost always some), maintenance and a more complete view of training (see below).
HRIS versus HRMS
Did the organization only look for a human resources information system (HRIS) used strictly by HR and payroll? If it is, it’s likely that the selection process focused on HR and payroll issues, and not on general business challenges. That isolates HR instead of making it more integrated with the rest of the organization. HR professionals need to be working with their colleagues across the organization to help solve complicated human resource challenges. This usually requires a human resource management system (HRMS), which enables some degree of self-service.
What does the absence of self-service mean for ROI? Perhaps the most important is that managers won’t be using the software. This is a missed opportunity to have managers easily and efficiently do more HR administration tasks, freeing HR departments to dedicate time and effort to human resource management rather than administration.
Software selection process
Choosing the right software in the first place is an essential prerequisite for meaningful ROI; thus the selection process should be viewed as all important. Mistakes here can leave the company with software that does not deliver what the organization needs most and, therefore, is unable to effect the meaningful change that makes new technology worth the investment.
Often the selection team jumps into a software demonstration without involving staff throughout the organization in developing a set of detailed requirements.
Looking at new software offerings is fun and interesting. But it is usually a bad place to start. Instead of first determining the wants and needs of the organization, seeing a demo tends to push the client into defining requirements based on a vendor’s software. That makes it very difficult to compare other software.
Once it is time to go through a demonstration, several vendors should be brought in so that apples can be compared to apples.
There are many good products on the market. None of them are perfect, and they all have their own eccentricities and methods of handling certain situations. Technical approaches vary widely and pricing even more so.
Real-life scenarios should be used to test the software. About 90 per cent of any organization’s requirements are likely standard; after all, there are only so many ways to hire or pay a person. It is the other 10 per cent that needs clear focus.
What are the conditions imposed by a labour contract, by an acquisition or by old equipment? These situations should be outlined in detail so that it is clear whether or not the software can handle it. If not, the company has to ask if the cost of customization is worth it or what business processes must be changed.
There are three general strategies used in software acquisition. The first is to buy “vanilla” software — software that requires nothing added to the core offering.
The second is to get software that meets some needs and then either customize it extensively, or supplement it with specialty software.
In both these cases the primary problem is there is no strong match between requirements and the selected software. The likely motive is to minimize costs.
People think they can spend the minimum now and fill the gaps later, with future software development or another product, often from a different vendor. These price-based decisions are often false-economy and usually end badly.
The third — and best alternative — is to plan on a vanilla implementation, recognizing that some limited customization will be required. Minimal customization is a goal worth pursuing because any change to the software increases the maintenance.
In most cases business processes can be altered to minimize changes to the software. But there are times when only software change will accomplish the desired results, and therefore the expected ROI. That should, however, be an infrequent recourse.
When considering new software it is important not to become overly fixated on the sticker price. It should go without saying that organizations should pay only what they can afford for anything, particularly software. But there will be other costs involved to make the software as effective as possible.
Many organizations that spend the entire budget for the core product leave little or nothing in the bank for implementation issues, which may require new hardware or training.
And remember to do sufficient reference checking. Every vendor that has been in business has references — both good and bad. Usually most of the bad references reflect a poor implementation, which should be pinned on the client organization, not the vendor.
Implementation
Many organizations spend too much time and all their money just acquiring software, and end up with problems in implementation.
When organizing implementation, it’s important to accurately plan and budget the entire implementation. Often the business case is completed before a detailed implementation plan is created.
This forces the project manager into shoe-horning the implementation plan into unrealistic timelines, and results in final tasks being under-funded and rushed.
It is important to take enough time to restructure business processes and, wherever possible, keep software customization to a minimum.
Implementing new software without reviewing and changing business processes is a waste of money. But many organizations skip business process change to implement more quickly. Such decisions represent false economy.
Staff should also get training that covers the restructured business processes, software operations and how the two will now be integrated. But the reality is training is very often badly done.
Typical software implementation projects run over budget and longer than expected and, as one of the last considerations before “going live,” training is often rushed and under-funded. Most significantly, it is usually focused on the software, and not the entire package of software plus business processes.
Organizations buying a new system must be prepared to take the time necessary to implement properly. The bulk of implementation may only take 12 to 26 weeks, but in terms of doing a complete job most successful organizations report that complete implementation should take at least two years.
Unless the organization is replacing one robust system with another (which raises its own set of issues) new systems usually call for changes to the organizational structure to support the new system.
The roles and responsibilities should include a functional help line, report support, ongoing testing (of new releases), and so on. How well this is done can make a big difference in the day-to-day operation of the system, and therefore the hard and soft pay back.
If you don’t know where you are going, then one road is as good as another. Organizations that expect to realize a positive, or better yet, a significantly positive ROI from a new HRMS need to approach the entire project professionally. Proper preparation will yield realistic expectations and tools to measure success.
Ian Turnbull is managing partner of Laird & Greer Management Consultants. He is past-president of both the Canadian Council of Human Resource Associations and the International Association for Human Resource Information Management. He may be reached at [email protected] or (416) 618-0052.