systematicHR

I was speaking with Donald Glade from Sourcing Analytics the other day and through our discussion I realized I needed to follow-up on my post about “HR Technology Does Not Make Us Strategic.” As I went through my bullets of “dooming HR technology to failure,” I thought that a discussion on why the failures happen might be appropriate. Certainly this is not a comprehensive list:

1. Governance
   • Along with our discussion on strategy, your governance structure really supports the way you will make decisions while on the technology implementation project. Having a place to go to drive key directions is critical.
   • Good governance ties the business strategy into all HR projects from the very beginning. Without this, you might be heading in a direction opposite of what the organization is driving toward.
2. Pre-Planning
   • So you knew you were heavily customizing and your IT department didn’t document well? Have fun during the upgrades!!!
   • You didn’t really think they meant it when the vendor said 1 full FTE in project management, 3 FTE’s in HRIS, 2 in benefits… Nope, they weren’t kidding. If you understaffed or didn’t audit and the data coming back is crap, the vendor is not expected to make your implementation perfect and come up with more resources for free if you are less dedicated to the success of the project than they are.
   • Go live MUST happen January 1. Oh – by the way, it’s already October.
3. Substandard Vendor Selection and Due Diligence You know – sometimes you picked the wrong vendor. If you didn’t tell them up front what your expectations were, or you didn’t take a close enough look under the covers, there is nobody to blame but yourself. A vendor sells to your stated needs. Needs that are unstated are not their fault.
   • As I mentioned in my previous post, I was with a vendor for a long time. I simply can’t tell you how many RFP’s I’ve seen that had nothing to do with the real requirements of the issuing organization. So you got a template off the web, or your consultant did a poor job of discovery and you wind up with RFP responses that are meaningless (but you don’t know it).
   • The vendor either didn’t want you to do a site visit, or you didn’t think it was important enough. Or perhaps you didn’t bring your IT guy out to the hosting center and nobody in HR knew to ask about the disaster recovery plan.
4. Blame Game I don’t know what to say other than this: Stop it already. Look within your organization first. There really is a decent chance your vendor issues are 50% your fault. If you can’t look at your organization objectively, it’s well worth your money to have a 3rd party consultant diagnose the problems for you.
5. OK – Your Vendor Sucks The list of sub-bullets if I was doing sub bullets could be pretty lengthy. Let’s just say that the vendor may have oversold their product, might not have great customer service for whatever reason (see due diligence), or they brought out their worst implementation team. Whatever the story is, sometimes it really is your vendor’s fault.
6. Changing Requirements 3 years down the road, the corporate portal strategy changes. All applications must be compliant with web services standards. oops!!! Or perhaps you just didn’t know you were going to need a really sophisticated learning management system. It’s a headache, but sometimes you just have to go back to the drawing board or purchase point solutions when the vendor can’t keep up with your changing requirements. Have a chat with them and see if they can find ways to support you.
7. All (or some) of the Above Most of the time, it’s this one. Yup – you are both to blame. The sad thing is after a while, both client and vendor are so tired of pointing the finger at each other and not getting anything done, that the easiest thing to do is part ways. When the parting happens, neither side has owned up to the fact that there were real issues that they had control over, and the client goes on to experience the exact same problems with another vendor because they have not fixed the core issue.

What’s my point? Many organizations choose to select a new vendor simply due to perceived service or production problems. Before you make the jump from your current vendor, try to identify if the actions of your organization contribute to or exacerbate the problems. I you find that the answer is true, then correct the issues and give your vendor another chance. If you fail to do so, moving to another vendor will simply put you through the same headaches again. Why? No matter who the vendor is, your organization will still be the root cause of many issues.