I am in the final stages of prep for my and Trish McFarlane's SHRM Presentation tomorrow on HR Technology Implementations which means that lately I have spent more time thinking about technology projects these last few weeks than I have in a while.
And while the presentation tomorrow won't specifically cover the reasons why projects typically fail, the idea of why HR (or any other enterprise technology) projects fail has crossed my mind more than a few times as we have prepped for the session tomorrow.
So since nothing matters unless it is blogged about, and since I have been thinking a lot about my experiences (successes and failures) with HR and other tech projects, I offer up for your consideration the Top Three reasons that HR tech projects can fail. Again, this is based on my experiences over the years, not on any official research or survey data. But I guess in a way it is a survey of sorts. Just with a smaller sample size, just me. So n = 1.
1. Scope Issues - The project starts out as something simple, even manageable, say a new Applicant Tracking System for the USA offices. But then someone realizes the new technology has new hire onboarding capability and even integrates with third-party content systems to serve up learning content and wouldn't it be great to include these functions in addition to the ATS? And oh, since we are at it, why don't we lump in the Europe and Asia Pacific offices as well? And then suddenly the simple, scope controlled project is now a little out of control. And in my experience expansions of project scope are almost never met with commensurate expansion of things like time, budget, and resources. So projects that were staffed and planned for X become inadequate when the project becomes X + 1 (or 2 or 3).
2. Internal Resource Availability - This happens all the time. Let's say the project is the implementation of a new Payroll system, but many organizations will not dedicate the Payroll Manager 100% to the project, as she has her 'real' job to do. Sure, the project team has access to the Payroll Manager, but it is never enough, and the Payroll Manager is always getting dragged back into the day-to-day issues of her real job. So the project team has to wait around and waste time trying to figure out what they actually can get done. Pro Tip: find some way to backfill at least 50% of the job duties of important internal resources while the project is being implemented. Find a temp, find another less critical internal resource to step in, whatever. But so much time and money is lost on projects because expensive consultants and integration folks can't get access to the needed internal resources when they need them.
3. The 'We have to do it this way' guy - This last one is harder to spot initially than items 1 and 2, but is no less destructive. This is the manager or process owner that simply WILL NOT COMPROMISE on his or her pet issues, specifically ones where the new system/process requires some flexibility. I am not talking about mission-critical or must-have bits of functionality, but rather small things like titles, labels, or how a particular process flow works. The 'We have to do it this way' guy uses these issues as kind of a wedge to try and derail the process and project overall. And once this guy starts to get some traction, he will try to recruit others to his cause, and suddenly the project team has to justify their approached and decisions about every last little thing.
There are lots more ways that projects can run off of the rails, but these three are really the most common ones in my experience. Tomorrow at SHRM Trish and I will talk about these issues as well as a few others - hope to see some of you there!