Implementing A Cloud HR Solution: 6 Lessons I Learned The Hard Way

Steve Borg

I have worked on the customer side in one of the earliest and largest implementations of an end-to-end cloud HR system, as well as with other customers doing the same. Both experiences have given me some key insights into common considerations when tackling a project.

While every business or project is different, I have found a number of commonalities across projects, so I’d like to share some lessons I have learned along the way to help others who are about to embark on their own cloud journey.

1. We don’t know what we don’t know

This is probably the most common statement I hear from customers, and I even thought or said it myself on more than one occasion. This is closely followed by “Surely we are not the first to want to do this!” or “How have others done this before?”

My advice on this is: First, choose who will help you with your implementation carefully.

Look for experience in the team—not just on the system build, but also people with experience in HR, process design, and change management. Be clear up front what your expectations are on thought leadership and how delivery of this will be measured.

Look for someone to join your team who has done this before. Also take the time to broaden who you ask for advice. When you are in the trenches of an implementation, with deadlines and deliverables looming, it can be difficult to lift your head up, but you’ll benefit from it. Why limit yourself to the experience of the implementations your consultants have done when there is a community of thousands of customers globally who have been where you are now? Who better to talk the language of a customer than another customer?

2. Remember why you bought it

There are a number of reasons why companies choose to go on this journey. These range from “We don’t actually have a system; we are still on paper,” or “Our current systems don’t talk to each other,” to “We are navigating a business transformation and we need a system that can support us end-to-end.”

Remember this when you are embarking on your design. The system is not the silver bullet for all your current business challenges. It is, however, an enabler to better business outcomes. You have this unique opportunity to look at what you do and how you do it. Take the time to challenge what you do today. It is a wasted investment if all you do is take your existing processes, systems, and forms and put them in the cloud. Consider what could be done differently. Try to achieve simplicity.

One principle we used—and I encourage others to do the same—is to design the system and process for the good employee, the good line manager, and the good HR business partner. Most people don’t come to work to find the loophole or wrought the system, so why build in complexity for the 1 percent of times something might happen? Rather than bog it down with too many layers of approval or checks and balances, manage those rare exceptions when they happen and treat them as just that: exceptions.

3. Find the balance between business-led and solution-led processes

It is easy to fall into the trap of what the system can do and turn everything on because it looks exciting and is built on best practices. As mentioned above, there needs to be a balance between driving improvements in your business and considering what the business is ready for from a change and maturity perspective. Remember, the system can grow with you over time.

Ensuring you have a strong system owner is key for your ongoing success.

This person needs to be the lead in achieving this balance. They need to understand what the business and HR strategies are and be able to translate them into how the various modules can enable and support these strategies. As such, the system owner or lead must also be able to articulate (when appropriate) what the modules future direction looks like and why that direction is being developed. In some cases your business could benefit from the system influencing the organization’s overall HR strategy. A recent example of this could be the changes to performance and goals.

4. Give yourself time

One of the most common misconceptions I see is the idea because you’re working on a cloud implementation you should do it fast.

Take should and replace it with can!

Ask yourself: Is that pace right for your business? I understand that in today’s fast-moving world, which is dominated by being first to market and controlling or minimising cost, there is a drive to do things faster. I also recognise that when these products are sold to you this concept is always at the forefront, and often that is because one of the first questions asked by prospective customers: “How many weeks does it take to turn that module on?”

While a particular timeline quoted may be possible and have been successfully done before, the question you need to ask yourself is: Can you and your business do it that quickly? In most cases, the implementation or technical team can build it that fast if you can provide them with the design decisions and data that quickly.

And that is where the challenge lies: Having sufficient time to understand the business requirements, get stakeholder agreement on key decision points, and then test the system to ensure it meets your business’s needs. Then there’s the time it takes to do proper communication and change management, with an often widespread and diverse end user group. By rushing these steps, you are simply reducing the benefit you could gain from taking an iterative approach to the design.

5. Share your design early

There is no point in rolling out cloud technology and keeping on-premise thinking. One mistake I made with the first module I worked on was designing the solution with my team in a somewhat closed shop—the first time the output was shared broadly was at UAT.

We involved key stakeholders in gathering requirements, and the project team was made up of subject-matter experts who understood not only the challenges faced with the legacy system but also the business they supported and strategy of where we wanted to go. We also did a lot of show-and-tell and “demoed” the design—but we could have and should have done more.

On reflection, I likely subconsciously drove this behaviour because we didn’t want to share anything that wasn’t perfectly polished and complete. Why? I wanted to protect the brand of our system, the project, my team, and my own personal brand. I worried that if something didn’t quite look right or wasn’t ready yet, it would be received poorly and we would be behind before we even began.

In reality, however, the rollout was successful, although there were some challenges at go-live that could have been avoided had we shared more. One way to achieve that would be to include usability testing by bringing together real end users to experience the newly designed system and process before the design is finalised.

6. Go-live is only the beginning

Ensure thaf you have revisited your measures of adoption and measures of success prior to go-live. Make sure you have baseline data of how long things took and/or how often they were done using the old system.

In addition, be sure that you have the tools in place to measure the improvements in the new system. I have found that some people have short memories regarding how difficult things used to be, so it is important to show the benefits offered by the new system. That way you can measure and demonstrate the value realised as well as celebrate your wins.

Be sure you plan for the transition from “project” to “business as usual.” A period of hyper-care for key processes and users makes for a smoother and faster transition. Also, where possible, retaining key members from the project into BAU roles helps with knowledge retention.

An agile approach doesn’t mean all rules go out the window. This includes the need for good documentation. As issue that has come up time and time again is the benefit of documenting not only what you did or how it was configured, but why. This is especially important over time as team members change.

For example, knowing we set X code to only 6 digits because Y downstream system can only handle 6 digits, or that you have this process in place because that module isn’t turned on yet, is invaluable information to have in 6, 12, or 18 months’ time when system or process improvements are being considered.

Finally, I encourage all of you who are on any stage of your digital HR transformation to get out there and talk to others. Remember, you’re never really finished, so there is always something to be shared and learned!

For more insight on HR technology, see “Gutting” The Guesswork Out Of HR Decision Making.


Steve Borg

About Steve Borg

Steve Borg is a Customer Engagement Executive (CEE) with SAP SuccessFactors. Steve is an experienced HR practitioner with over 15 years experience in generalist and specialty roles across a number of industries including finance, manufacturing and retail. Steve has also had the privilege of working on a major end to end implementation of SuccessFactors as a customer, implementing over this time, Employee Central including Cloud Payroll, Recruitment, Performance and Goals, Succession, Learning, Compensation, Variable Pay and Workforce Analytics . Steve now helps existing SuccessFactors’ customers align their technology with their business strategy to maximize the value they yield from their investments as it relates to the SuccessFactors software and services.