Why SAP HR/Payroll Projects Fail

Two SAP HR/Payroll project failures have been in the news recently - Queensland Health and Marin County. That reminded me of a couple earlier failures that were reported in the news - LA Unified School District and State of California. Now, one can argue if these are really failures; employees are getting paid in three of the four cases after intense work to get things corrected. I count it a failure if a project gets public press time for not working out, and all four of these qualify on that measure.

On the one hand, I am puzzled by these failures. SAP HR/Payroll has been implemented thousands of times, at many firms that are larger and more complex. On the other hand, I'm not surprised at all. Successful SAP HR/Payroll projects are complex and require a lot of detailed work. And it is very interesting that all four of these examples are in public sector organizations. For-profit and private-sector implementations have, I'm sure, failed now and then. But the last one I remember is at Hershey Foods in 2002. Is this a public sector problem, a consulting problem, a software problem?

SAP HR/Payroll has been implemented at other public sector organizations - universities, cities, Federal agencies, school districts, and so on. The first one I know of went live in 1998 and is still going strong.

Although the SAP HR/Payroll software has certainly had its growing pains, it does work. It's not the easiest or most intuitive software around, yet it does work for thousands of SAP customers around the world.

In my opinion, project failures start and end with the consulting firm. We can say all we want to about customers not doing their fair share or not being ready for or agreeable to change. We can point to software defects and shortcomings, which are real. However, if consultants 'give professional advice' then it is our responsibility to call attention to issues that affect our client's success. If the software has critical errors or functional gaps, then maybe that software isn't right, or ready, for our client. If our client isn't ready for the amount of change that a new software package will bring to their organization, then maybe the scope of the change needs to be narrowed to what can be handled. If our client is not willing to pay for qualified and experienced implementation resources - or we are not willing to staff the project with such resources - then perhaps expectations need to be managed to line up with capabilities.

One of the biggest obstacles for implementation projects, regardless of the software package or industry, is the conflict between the consulting firm's goals for giving good advice vs. making a profit. There are tensions between those two: when the good advice is to cut scope, spend more on implementation resources, or invest more in change management then it is likely that profit will decrease.

Most times, experienced consulting firms know how to plan a project so that they can both provide good advice and make a profit. However, as the four cases mentioned at the beginning illustrate, that is not always the case.

up
187 users have voted.