Why do major HR system implementations fail to deliver as promised?

@RZampetti put a question out into the "Twittersphere" recently about HR System Implementations...

He asked 'Why do major HR system implementations fail 2 deliver as promised?' is it due to 'Wrong technology?' or 'Lack governance?'

DiscussHR offers up the following thoughts on why they fail to deliver..

1. Underestimating the need for change management & engagement

2. Poor end user training

3. over-engineering of business processes

What do you think?

Couple more

- Stakeholder buy-in / commitment / follow through

- Scope creep

- Business case stated ROI not quantified – MUST be tangible numbers

- Project not branded correctly.. or not at all

- Impacted population not identified or communicated to effectively

- Testing an afterthought or rushed.. includes User Testing

- Issues, risks and plans for mitigation not identified upfront

- Decisions slow or by consensus – A project is not a democracy

- Resources allocated more than 100%, including client resources

- Critical Path not defined / followed

- Timely, accurate and relevant reporting not produced post go-live

- Roles and responsibilities not identified/communicated when planning

- Biting off too much, big bang is feasible but hard to complete successfully

- People showing up to meetings late (ok, more of a pet peeve)

- Change Management not given enough resources (people, time, money), I know it was mentioned before but it bears mentioning again.. and again

Post go-live

So many excellent reasons as to the cause of failure, rather than repeat any of them, I would add a couple of examples that I have seen.  Honestly, these failure reasons are just as applicable to accounting, order entry, or procurement systems projects as well as HR

One issue I have seen is the project team and consultants especially taking the 'Go-live' milestone as the de-facto end of the project, and some kind of indicator of ultimate success. When in fact though 'go-live' is a huge milestone, there is still usually much important work to do. Many organizations, particularly after having fought through a long, costly, and difficuly project simply want to pause and take a deep breath after go-live, but in doing so run the risk of slow adoption, end user dissatisfcation, or other issues.  

Another problem I have seen is 'partial commitment'.  I have seen a Manager Self-Service automation project fail due to this.  The organization claims to be 100% behind the project, but once the first stumbing block appears, and someone influential in the organization speaks out against the project, the leadership seems to crumble, and if the project continues it only does half-heartedly. Either the organization is behind the project, and the associated change to processes, or they are not.  Trying to play both sides is a recipe for failure.

Unquestioned or unchallenged assumptions

Completely agree with the prior postings. I would add that as part of stakeholder engagement, it is critical to flush out all assumptions that anyone has about the technology, processes, readiness, etc.  This is especially critical if there are multiple vendors assisting with the implementation process (e.g., consultants, content vendors, technology vendors, etc.).  It is critical for ALL parties to present and validate any and all assumptions they are making about every aspect of the project.  These include, but are not limited to:

  • End game objectives
  • Condition of deliverables from different parties - content, configuration, etc., INCLDING the objectives and assumptions under which those deliverables were developed
  • Definitions of "best practices"
  • Organizational "sacred cows"
  • Decision making processes
  • Decision owners

 

Suzanne Rumsey

Principal Consultant,
Knowledge Infusion

My choices actually were...

For the sake of completeness, let me start by pointing out that I initially sent out 5 tweets asking the question, "Why do major HR system implementations fail to deliver as promised?".  In each I posited a series of typical reasons given and I wanted my audience to choose among these (or others) for the ones they felt were the most prevalent causes of failure.  Here is the original list: 

  1. Poor initial business case?
  2. Bad requirements?
  3. Ineffective process design?
  4. Inadequate testing and user acceptance?
  5. Inexperienced programmers?
  6. Amateur project mgmt?
  7. Wrong technology?
  8. Lack of governance?
  9. Ineffective or nonexistent change management?
  10. Other: _______________

Let me add for starters, that in my 18 years of experience I have seen all of these issues (and more) arise.  But number 9 (ineffective or nonexistent change management) seems to trump all the others in the cases I've studied.

A frequently cited survey of CIOs conducted by Deloitte and Touche yield some interesting insights.  What do CIOs give as reasons (not just for HR, but for large scale system changes in general)?

Graph

http://twitpic.com/a48yi

Denis W BarnardCEO

Denis W BarnardCEO HRcomparison Ltd (http://www.hrcomparison.com)

 

In short form:

a) Lack of thought-through business case 

b) Lack of vision about what the system can & will do

c) Basic lack of understanding in HR about software systems and the rudimentary logic behind them(how's this for a system requirement I have seen more than once: "push-button reporting" )

d) Failure to select correct system because of b) plus poor research, poor knowledge, risk-averse (and therefore expensive) selection, sticking to big names

e) Failure to secure proper client-side project management / vendor liaison ""I know" chirps the HR Manager "I'll be the Project Manager")

f) Failure to think through the basics: Data Cleanse, Rules, and Processes prior to configuring the new system

g) Failure to take advantage of full training for all personnel involved

plus two other factors:

Are the staff in the HR department up to making the system work?

Usually the bean counters are so taken away by the cost of the project that they skimp on the peripherals including Project Management and Training 

I'm happy to expand or illustrate on any of the above (and this list is not exhaustive!) but didn't want to bore the reader. This has been accumulated over 20 years working with HRIS and nearly 100 projects 

 Cheers - Denis