Careful how you flick those switches: Implementing HR Tech has its challenges (surprise!)

HR technology implementations are a money-hungry challenge. They routinely fail to deliver on time, on budget or to the vision prescribed in the business case. I have seen and been part of some that have succeeded, and watched with a sense of foreboding as many have trended in the wrong direction.

There are some things to look out for and ways to mitigate these challenges.

Risk: Software Before Approach

“We are implementing a technology-driven solution”. It’s the mantra of those that were burnt by over-customisation in the 2000’s. That left a bad-taste in the mouth of many a HR leader, and for good reason. Customising SAP, PeopleSoft or a less common externally-hosted LMS or RTS really did set the company up for massive cost and heartache for many, many years to come.

The other driver of this mandate is a misunderstanding of HRIS cloud-solutions; a view that they come ready to be put into action, out-of-the-box.

Today’s cloud solutions are different (on the whole), from both the traditional on-premise challenges, and from those early 'out-of-the-box' cloud dreams. They have a locked-down base, which you can’t (or shouldn’t) really customise, and a configuration layer that requires a great understanding of your own principles, processes (to some degree) and experience requirements. They very rarely ‘just work’ and actually need to be configured to suit your needs. Configuration might just be flicking switches, but those switches have a great impact on the employee experience.

The directive of ‘software-first’ can, if not mitigated, lead to:

1. Poorly understood experience priorities. What kind of things should a line manager be able to do? What about a 2 up manager? What should have to be done centrally? Without knowing this, you can end up with misaligned experiences across different HR modules, at best, and a huge amount of re-work and delays, at worst.
2. A solution built on HR ideals, not on ‘experience priorities’. It might be that for an outcome to be absolutely perfect it requires visibility of a large amount of data and three sign-off points, but a time-poor leader could easily be put off by such an experience and simply not engage effectively with the process at all!
3. A very clunky process, driven by what implementation partners have seen in other environments, loosely jammed into your environment (which is different!).

This risk can be mitigated:

Experience / Design Principles: Regardless of the off-the-shelf readiness of the solution at hand, define the experience principles that are important to your company, and maintain an ongoing conversation of how you are empowering those experiences. This means treating them like a company values roll-out: communicate, reinforce and embed an understanding of those principles. Experience principles can be as simple as,

• “Line Managers should have full control over employee data, not limited to learning and development, but across remuneration and other functions. We will monitor, not enforce, changes to employee information.” And / or:
• “Line Managers should spend no more than five minutes on any single management activity in the HRIS.”

This requires a conversation, after every design session, where the team is asked “Have we enabled Line Managers to lead their team, within their time constraints?”, for example.

Define the Approach Independently: Today’s solutions are adaptable, for the most part. If we understand the high level flow of information and roles / responsibilities, this will enable the highest possible return on the solution. Don’t bother with every process step, because this will be influenced by system functionality, but understand:

• The role of business leadership by understanding their responsibilities: Are they responsible for understanding how the remuneration budget is being dispersed, for example?
• The role of the HR / People team. Do they govern activity? Administer / approve certain types of tasks? What about the partnering team, do they actively report on pr enforce activity in the business?
• What control do Line Managers have in your environment? What type of tasks (not specifics) should they be able to do?

Induct your Vendor / Implementation Partner: Your implementation team is rotating from their last project, with a couple of days break / prep in between. They are coming in with a time-tested formula and believe they know best how to get you to your goal on time, in budget, i.e. they are going to embrace you with their process, perhaps before they understand the environment they are dealing with. Enforce and include in your scope the time to share with them (in addition to the standard induction items):

• Your Experience/Design Principles. Explain that they are equally responsible for bringing these experiences to life.
• Your Approach, defined as discussed above.

Stay flexible: It matters less what the actual steps or screens are, and more what experience you are creating. Don't get hung up on the small stuff: This is where the technology often should dictate the solution.

Risk: Enterprise-Aligned Software Choice

In many organisations the technology team is strategically aligned with a behemoth vendor that supplies Finance, Procurement and HR software. It’s hard to argue with the principle of aligning your HR software with those functions, on the face of it, but it can lead to some worrying consequences when a mandate such as “we will not deviate from x solution” is issued:

1. Inability to identify large gaps in capability. If you are looking at a full-scale HRIS implementation, aligned to the Enterprise Architecture Roadmap, the process may not be conducive to understanding that the proposed solution does not include an effective compliance learning solution, for example. Compliance learning is not sexy and may not be of immediate concern during the development of a huge business case. It will have huge impacts on the business, though.
2. Licensing of software that will never be used. Licensing an inadequate module, up to three years in advance, can be costly. While a mandate may be issued on Day 1, by Day 1000 some 100 days may have been spent on justifying a third-party, non-platform solution. That’s time, as well as real money, wasted.

Mitigation approaches include:

1. A principled approach that says that all requirements should, as a started point, be solved with the platform of choice, complemented by a governance mechanism to ensure that deviations are well vetted, by the right expertise, but not simply road-blocked. Road-blocking costs time and money and can bury a sound rationale.
2. Don’t over-commit to the vendor. If possible, implement stage-gating, with known consequences for all parties if they desired software choices change.

Risk: Over-Promising by Vendors

It’s an obvious risk, that we all know well, that we can still fall victim to. The primary reason that I see is this: Software vendors have their best people involved in the pre-sales process, with time to contemplate ‘possibilities’, but not necessarily certainties. For example, if asked “Can your solution seamlessly lead employees from performance outcomes to development plans, then on to the learning options available to them?”, a vendor might, after some reflection (this is a warning sign), “Yes, you could provide links between those processes, even though they are in different modules.” Issues with this kind of statement include:

• ‘Could’. It could also make me a roast dinner, with the right process support!
• ‘Links’ (or a similar limiting statement). This rarely indicates a seamless experience and instead hints at a broken flow.
• ‘Different modules’. In this example, the experience might not be enabled due to the order of deployment of the different modules.

Taking all this into account, the pre-sales team may articulate something that absolutely is possible, but the post-sales implementation team might lack the expertise and experience to actually execute on the requirement. The complicated ‘potential’ method can be lost in the noise between idea and delivery, leading to disappointment and a sense of dishonesty / mistreatment building in your stakeholders.

Mitigation:

Simply ask “Has this exact thing been delivered before, and can I see it?” If the answer is “no, not quite”, don’t believe it. Assume that you are going to have to develop a work-around to the requirement, or choose another platform. Anyway, complicated configurations that use cloud HRIS tools in an unusual way are almost always dumped, either during the implementation, or during the next iterative development project.

Risk: Ineffective Mix of Expertise

This can manifest in a number of ways, including:

1. A dedicated team of project and technology professionals, who have ‘done this before’ on ‘similar projects in other parts of the organisation’, without being complemented by HR technology professionals. These teams lack the contextual knowledge of HR that enables us to problem solve on the run, understanding the interdependencies of different HR domains, e.g. between Recruitment, onboarding and learning.
2. Over-reliance on HR professionals / middle managers, with limited understanding of what is required to land a technology solution. In this circumstance, the hunt for perfection can often derail the project. The fact is that sometimes you need to get the tech deployed, try it out and refine from there, accepting that you will learn, in part, from trial and error. This is hard for some HR experts to accept.

Mitigation:

1. Effective governance that includes the right sort of expertise in the right conversations. This means a mix of leadership levels involved in your steering committee (or other governance mechanisms), with adequate voice given to those close enough to the action to understand the impacts on the quality of the process and the impacts on the project timeline / cost. Avoid providing too much responsibility to those lower-level HR leaders, and avoid the project team escalating the Steering Committee to a level that has no real idea what they are talking about (a common tactic to limit the perceived interference of committees!).
2. Project and business responsibilities need to be segregated. The Project Manager’s role is to manage their resources and vendors to the scope that has been agreed. The business stakeholder’s responsibility is to define the requirements and develop business readiness. These are different responsibilities, with different drivers / priorities, that report separately to the Sponsor. Where these lines blur and, say, the PM starts re-defining the scope, much chaos will ensue!

Of course, there are so many other things that can go wrong (or go right -- I'm aware this is a glass-half-empty article!). These are the things that come to mind for me - and the mitigation strategies have served me well in the past. If you'd like to discuss further, please feel free to comment or drop me a line.

Andrew Smith is a HR professional with leadership experience across HR technology, analytics, strategy and planning, in some of Australia's largest corporations.

https://www.linkedin.com/pulse/careful-how-you-flick-those-switches-implementing-hr-tech-smith