Some time ago, I had the opportunity to work with a client who had almost a year ago purchased a truly state-of-the-art workforce analytics solution. They had worked with the vendor to configure the system, ship data to the vendor's cloud environment, configure and test the system, train end users in the capabilities of the tool, and with great fanfare launch the solution to the HR organization.
The Iceberg Appears
However, in spite of all of their best efforts, they were unable to get much of what they needed from their new system. They expected that-given the work that had been accomplished in launching the system-that it was simply a matter of getting the right person with the right skills–an “expert” (me)-to extract the right information.
Unfortunately, they were wrong. Of the list of metrics they wished to obtain, I was able to extract approximately 50 percent of the metrics and visualization they desired. The remainder was unobtainable-due to the following:
• Planning and Requirements Development: They had acquired and "built" a system without a clear "end" in mind. They simply didn’t have much of what they wanted–it hadn’t been built to produce what was needed.
• Data: Because of the above, they didn’t have much of the data they needed to generate the output desired.
• Configuration: Because the project team hadn’t gathered stakeholder requirements, necessary data wasn’t loaded and the system wasn’t properly configured. Truly, in putting “garbage” in, they were destined to get “garbage” out (or at least little of what they desired).
• Testing and Training: It was clear that the system had not been fully tested, as evidenced from a number of defects or issues identified through my work. In addition, training provided to end users was insufficient to accomplish the desired outcomes. They had to hire someone–me– to overcome their lack of training. Even I couldn’t overcome fundamental issues with the system–issues that should have been surfaced when it was tested prior to implementation.
The inherent limitations of the "finished" system set the stage for a candid-and uncomfortable discussion with the client. Senior stakeholders believed that they were able to get what they wanted-and needed-for their "customers". Project team members felt that they had done what they were asked to do, not considering that there is so much more to standing up a technology solution than simply extracting data from existing system, aggregating that data in the vendor's cloud environment, and being able to visualize that the data is in the vendor's system. The vendor felt that they had provided what they were asked to provide-and any issues experienced by the client was not due to limitations or issues with their technology.
In the case of most HR technology projects, HR is the "owner", the "benefactor", and primarily the resource leveraged to effect the implementation
What’s the Remedy?
When HR projects don’t meet their planned (or unplanned, but required) objectives, it’s easy for stakeholders to resort to finger-pointing. We minimize this, and maximize the probability of HR tech project success when we:
Clearly distinguish who “owns” the project. In the case of HR technology, the logical owner would be of course the HR. Although other stakeholders–Information Technology, Procurement, and business leaders, to name a few can make invaluable contributions, the project must have one (and only one) “quarterback”. For HR tech projects, this should be HR.
Engage the Appropriate Stakeholders in the Project-in the Right Roles and with the Right Responsibilities. Make sure you have a "mix" of people with diverse backgrounds, perspectives, and capabilities. A visionary group of HR leaders can define aspirations for a new technology, but others at a more tactical level must ensure that such aspirations can be translated into reality. A room full of data "wonks" will build a great system that no one else can understand or use. Getting the right teams–executive sponsorship, steering committee, and tactical project team members–is essential to succeeding in every subsequent step.
Translate the vision for the organization’s objectives–the “future state”, if you will–into clear, objective technological requirements. Stakeholders need to have a clear, compelling vision of what the future state will be post-implementation. It's critical to have all requirements documented in advance of beginning configuration-and being able to articulate the business rationale for these requirements. It eliminates "nice, but never used"-before it gets built.
Appreciate that no technology vendor is able to meet all current and future business requirements. Consequently, the focus is not on the “perfect” solution, but rather the “best” possible solution. Strong leaders clearly comprehend the capabilities and limitations of the proposed technology solution.
Prioritize the achievable key requirements and ensure that the data required to generate these is accessible and in a condition sufficient to make it usable. Lock scope once this is completed. Many good projects have been run aground as a result of poor prioritization and "scope creep". Don't let it happen.
Recognize that "go live" or "launch" is not the end of the project, but rather the end of a phase.I'm forever amazed that organizations believe you can implement HR technology, and then walk away. Implementation is about launching an operational system. Optimization is equally critical. It is about taking that basic system and making it work for the business. Whatever you do at "go live", don't quit.
So, Who's to Blame When HR Tech Projects Don’t Deliver?
Invariably, when projects don't deliver what stakeholders want (as is often the case), the inclination of many is to find fault and if politics dictate-throw someone(s) "under the bus".
That “someone” can be one or more of several parties including the vendor, consultant(s), Information Technology, Procurement, and of course HR. However, if HR stakeholders truly practice due diligence and undertake the actions I’ve outlined above, the probability of “failure” and self-protective tendency to blame others is minimized (if not outright eliminated).
In the case of most HR technology projects, HR is the “owner”, the “benefactor”, and primarily the resource leveraged to effect the implementation. If HR truly operates as the project “quarterback”, HR also owns the outcomes of the project. Sure, it’s convenient to have other parties to blame, but abdication of “ownership” whether at the beginning, middle, or end of a project doesn’t address the fundamental need: a successful HR technology project.