Skip to Content

Who Is To Blame When an SAP Payroll Project Fails?

There have been several high profile SAP Payroll failures over the past few years in the United States at places such as the State of California, National GridKentucky Government, City of Portland, LA School District, City of San Diego, California Judicial Council, Marin County and an epic train wreck happening down under at Queensland Health. I thought this imagine was great as all too often successful projects are not celebrated or even acknowledged in the public domain but everyone hears about the failures.


For the past 15 years one of the main areas within the SAP Human Capital Management I have specialized in is US Payroll having taken part in 20+ projects in various stages such as full implementations, production support and disaster recovery. While I have not personally been involved in any of the projects listed above it upsets me that after all this years we are still having major failures that are costing customers (and citizens) millions of dollars. Steve Bogner, who is a well known SAP Payroll expert, and I recently recorded a podcast talking about some of the key areas that people tend to blame when a SAP Payroll project fails and if it is similar to what we have seen on the ground. The major areas we covered in our 30 minute conversation was what role the SAP Payroll software has in these failures, Finding the Right Consultants and Software Integrators, Customer Responsibility, Project Management, Importance of Testing and how this impacts the new SuccessFactors “Cloud” Payroll offering.

Podcast – How you can avoid a SAP Project Failure

This topic is has added importance when you consider that the New SuccessFactors Employee Central Payroll Offering is at the core the exact same SAP Payroll mentioned above only hosted by SuccessFactors so these exact same risks are in play. The bottom line as Naomi Bloom so eloquently stated in a recent blog there is no stars in a failed implementation and often there is lots of blame to go around. It is shameful after all these years and collective wisdom that we are still seeing these messy high profile project failures as it doesn’t have to be that way. Steve and I believe customers can significantly lower their risk by focusing on the areas above and we even put our money where our mouth is at the 26 minute mark of the podcast 🙂

You can follow me on Twitter at SAP_Jarret

You must be Logged on to comment or reply to a post.
  • Hi Jarret,

    Great podcast. I'm not SAP-HCM/Payroll specialist so whatever little I say here may or may not be relevant. One difference I notice between payroll & other modules is the level of accuracy needed. Payroll it seems has three unique requirements:

    1. Payroll affects everyone in the company. (Like 'always', 'everyone' may not be accurate but very close I guess).
    2. As you said in the podcast, 10 cents difference in pay check may create a lot of chaos in the company whereas in other modules, write-off is not uncommon.
    3. Time/date of processing is more critical in payroll whereas in other modules, delay in processing may not create a huge inconvenience to the customers. For example, sometimes public corporations delay the release of earnings report. They may be required to pay penalty for releasing the report late but the impact is normally not felt widely. In Payroll, if paycheck is delayed, it'll not only make employees unhappy but may require lot more efforts & money to calculate the penalty etc.

    When data is migrated from old system to SAP or other systems, in my opinion, data quality requirements is more stringent in payroll.

    Best regards,


    • Thanks for the comment Bala and you are correct that the level of accuracy and firm check dates needed for SAP Payroll really set it aside when combined with the personal impact an employee feels when getting an incorrect paycheck.

      Your point on data migration is a good one that we only touched upon briefly in the podcast but since payroll relies on accurate time management data, personal administration, organizational management there is a reliance on that information and on many occasions the errors in payroll are not payroll's fault per say (ie wrong Overtime Hour calculation).

      That said there have been many high profile, complex and successful Payroll implementations within the US and abroad so there is no reason why customers should expect any less.

  • Hi Jarret,

    Thanks for your inputs and I would feel the failure of  payroll Implementation depends on following factors.

    For SAP Payroll Consultant.

    1. Lack of Core knowledge on Understanding of Payroll System and its Statutory Compliance.
    2. Lack of Effective Communication and Explanation in Laymen Terms to the Customer about SAP Payroll System and How the System can meet their Requirements and Statutory compliance.
    3. Lack of Proper Documentations such as AS-IS, TO-BE and BBP.
    4. Lack of Pro-activeness in User Acceptance Test.

    For Customer.

    1. Lack of Involvement of a Customer in the Project, thinking that they don't have much role in the implementation and it is a job of SAP Consultant.
    2. Unwilling to listen to SAP Consultants and having "Do what I Say" attitude.
    3. Lack of interest in User Acceptance Test.

    Would appreciate your suggestions.

    Best Regards

    Udaya Kumar.

  • Jarret, these are govermental bodies. Do you see a pattern?

    Most project difficulties are due to high expectations of the Customer, and the low standards of the System Integartor. Combine that with lack of oversight of these two stakeholders and you have a powerful combination of lack of transparency for the customer and management by change order by the SI.

    • Thanks for the comment James and I agree that the government entities (especially in California) seem to have more issues but there are a great success stories like the State of NC as well (and many others).  Did you happen to see this regarding the "Task Force" findings as obvious the oversight which you mention was VERY lacking.

      I can tell you with 100% certainty that it was NOT the SAP Payroll software that was part of the failure for being unable to meet the requirements as the SAP solution is the most flexible that I have seen from any large enterprise vendor. That said with flexibility comes some big responsibility from customers & consultant to handle that "power" responsible or the consequences can be pretty harsh.

      Where SAP DOES take a huge part in the failure as they were the SI using SAP Consulting Services for the State of California. How bad does it look when SAP can't implement SAP software for their customers (regardless of the circumstances).

      On a side here is a very good article (and comment thread) from a few years back.



  • Nice Podcast. I totally agree  most of the payroll projects fail due to lack of right consultants doing the requirement gathering, understanding the intergrations and nailing this down at BBP level . At times this is also with some customers who dont engage right resources from Business.

    We are ultimaterly loosing the customer credibilty when we fail and giving scope to other competetive products like workday  .. I heard many small and medium size companies are looking at workday these days..

    • Thanks Jyothi and regarding Workday even though they only have a payroll solution for 2 countries (US/Canada) their average customers in 2012 was ~20K employees and they are very competitive to SAP in the Large Enterprise HCM space.

  • Hi Jarrett,

    Thank you for this really useful article. Even though I work in SAP for another country so my reality is different , I would like to mention that no matter how successfull a SAP project turns out, the failed ones will always be the most remembered because it´s our  human nature and it´s hard to change.

    I am  new in the field (2 years and a half of experience) but I had the opportunity to be on the both sides (failed and successfull projects) and in my modest opinion here´s what I think:

    Successfull projects

    - Great project leaders (people management, client management skills)
    - Good specialists (excelent team players, client management skills )
    - Great time (Gantt) and knowledge management
    - Involved clientes, assigned teams for the implementation project (expert users in the field)

    Failed projects:

    - Regular project leaders  
    - Excelent specialists (lack of  soft skills)
    - Unreal  time planning
    - User assignation (50%)

    Of course this is not everyting, but my point:  It´s not about the tool (SAP) it´s about how we sell it and manage it. Most of the time we have experts Consultants (technically) in the field but with a huge lack of soft skills and  there is where I´ve seen SAP professionals failing the most.

    • Thanks for the comment Ana and you touched upon of the things we talked about in the podcast. 

      It has always been a pet peeve of mine that successful SAP projects are not more celebrated within the media to counter the failures but i dont see that changing anytime soon.  That said I believe SAP Payroll failures can be avoided all together if customers and SI's each do their part.

  • Jarret,

    I've worked in SAP for 15 years and represent an SI that has been involved with the "rescue" efforts of a few of those Payroll projects mentioned to turn them around after they failed so I'll cross-post to share some qualified insights of my own here to add on to what Ana Maria described above where I agree that it was not the software that was the problem:

    1. Failed project management - this happens on big IT projects, not just SAP or ERP projects. Big projects have so many variables but this has been cited before as the root cause for some of these failures whether it be cost, time or scope that was not managed properly. This can be as simple or as complex as you make it but it is a science (when you remove all the fluff). That said, project management and projects are subject to external macro and micro constraints that cannot be ignored and need to be constantly factored in, here are some examples following.

    2. Engagement model - most of these public sector engagements are fixed price, fixed scope and unfortunately this sometimes encourages bad behavior with some SI vendors who promise the world to win the work but then aggressively manage scope with a change order mentality that often undermines the expectations of the client who was looking for a partner to guide them. This is a tricky one to remedy in the public sector space given the need to forecast budgets and leads to the next point

    3. Vendor selection/Tendering process - having the vendor selection process managed by an independant 3rd party (e.g. Gartner) on behalf of the client and defined in explicit detail upfront is something I've seen work very well. Suddenly the client has an impartial but qualified view and is educated enough to define the right level of detail in evaluating incumbent SI vendors and the SI vendor benefits from the client more clearly understanding what they need and the end result is a closer match between expectations.

    4. Lack of appropriate expertise - failure to deliver the expectations and defined project deliverables. SAP Payroll as you know is not forgiving by nature, either the amounts are correct or they are not. What makes public sector payroll so interesting, especially at the State level is the need to combine/integrate business rules for a large number of bargaining units and to do so consistently and repeatedly so that people don't get underpaid, overpaid or not paid at all.

    Sidebar: Having one of SAP's own consulting teams fail to deliver a functioning payroll as you noted in your comments back to Jim above you could argue is inexcusable and in principle alone I agree, but again each project has it's unique people and variables involved so I'm sure it is not a one-sided conversation.

    One correction: the reference to California Judicial Council's failed SAP Payroll project was actually a bespoke case management initiative (CCMS). There was indeed a SAP implementation that had issues initially but that is now successful.



  • I finally got to listen to this today and I totally agree with the comments regarding lack of project management.  For some reason we don't talk about project management skills in the SAP Community but it can make or break a project.

    I wrote about this almost three years ago on SCN - check this link

    I don't have the details on what happened in the State of California but as an SAP Payroll user today I like that I can change my deductions, retirement plan contributions, enter time, leave requests, see the team calendar all through SAP's Employee Self-Service.

    As a finance person I like that SAP Payroll integrates seamless with FI and Funds Management (SAP's Public Sector finance solution).

    I wasn't here for the SAP payroll implementation at my current company but I know that no one complains about the implementation partner and from all indications the project ran smoothly.

    Hopefully we won't hear about too many more SAP payroll failures in the future.



    • Thanks for the comment Tammy and definitely agree that project management can make or break a project and it is the complex projects that often need it the most.

      Like you I hope we don't hear about many more SAP Payroll failures as both Steve and I feel they can be avoided.

  • Great comments and analysis folks! Based on my recent experience Down under i would like to add Stakeholder management as a key area for a projects success. I have seen a project being derailed by the Business on some pretext or the other when there was no strong stakeholder management involved though the best of SAP talent avaliable  were working on the project and i have seen another project go over the line in record time because the Client had a strong steering committe and change team in place who effectively pushed the solution through the organisation and made sure the SAP team had everything needed in place for a succesful go -live.

    • Great point Harris as a strong and engaged steering committee can help make some of the tough decision that can have big ramification on the overall project. I remember at one company there was a requirement to build a new complex function (code that sits inside of the payroll schema) to automate a process for 5 people. I still remember the steering committee saying "Are we willing to risk paying 40K people correctly to automate this for 5 people when the manual workaround will still pay them correctly at take less than 1hr per month). Sometimes common sense can get lost on projects when you are in the weeds which is a where a strong steering committee can make a big difference.