Skip to Content

Payroll Implementation Failures. Why?

I am just back from holidays and catching up on what has been making news whilst I have been away. The item that caught my attention was an article by Chris Megerian in the Los Angeles Times and his comments concerning the issues confronting an SAP payroll implementation for the Californian Government. The project has been going for many years with the original SI being replaced by SAP in 2010. It is way over budget, five years overdue and in danger of collapsing according to the article.

Being based in Queensland, Australia, this sounded very similar to the Queensland Health Payroll project, except instead of the implementation project collapsing, Queensland Health went live and then collapsed. So why do projects fail? I have been implementing SAP since 1996 and have complete faith that the SAP payroll solution is not the issue. I’m not saying that everything that SAP delivers is always correct but when there is an issue it is resolved and normally in a timely manner.

There are the obvious reasons for failure including items such as:

  • Wrong product selected for the business needs
  • Lack of detailed business requirements
  • Reluctance to modify business processes when appropriate
  • Implementation partner not guiding, working with and communicating with the client
  • Scope creep
  • Lack of change management
  • Lack of training
  • Lack of testing, etc

These hopefully need no explanation (well maybe they do, given the number of poor implementations) but I would like to concentrate on just a couple of items I believe may lead to issues with implementations. Please note, though, I am not saying that any of the above items were evident in the two implementations mentioned in the opening paragraphs. This also applies to the paragraphs which follow.

The first thing that annoys me is consultancy firms winning tenders by supplying CV’s for their more experienced consultants and then populating the project with somewhat more junior consultants. This has a number of issues. The client is not receiving the quality service they expected to receive, not just with configuration skills but also possibly with business experience and knowledge built up over a period of time. It is also not fair for junior consultants to be placed in this position. They should be nurtured and trained with experienced people around them so, in time, they can take lead roles and support others who are just starting out in our profession.

The second thing that annoys me is the utilization of off shore people to reduce costs. This may or may not be an issue for other modules but payroll is its own unique beast with particular characteristics for each country. I am not saying the off shore people do not have the configuration ability or the attitude required to perform the task but it is the communication required to ensure the client’s needs are being met that can cause issues. It is difficult enough for consultants living within the country to grasp some of the little nuances that may exist within legislation, awards, enterprise bargaining agreements, grandfather clauses, etc. let alone consultants who are not on site and are configuring based upon documentation they have received for a client they are not engaging with. The people who perform the role of the “go-between” for these projects definitely earn their money.

The successful implementations are based on more than money and skills. There needs to be that element of trust between the client and the implementation partner. How can there be trust when the first thing the implementation partner does is replace nominated staff with other names. How can there be trust when the client doesn’t know the people building their system because they sit in an office somewhere in another part of the world. This may change over time with the arrival of SaaS products but for now, payroll is delivered on-premise, and that is where the nominated consultant should be.

In closing, I hope that 2013 sees more publicity given to the projects that go well and less front page stories of failed implementations.

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

    Great blog and you touch on some of the problems that customers face. Blogs like this can help educate customers and always go down well with community. You read my blog on SuccessFactors and SAP HCM Consulting that also highlighted a few concerns and ways that customers can find experienced consultants and Jarret Pazahanick has written a flew blogs that can help customers.

    However, it’s really tough for customers when they are presented with CVs of experienced consultants but don’t realize they got juniors instead. Jarret does a great job in his blog Seven Tips to ensure you hire the Right Consultant, but sometimes customers don’t have a yardstick to compare against.

    Keep up the good work!


  • Hi Paul.

    Fully agree with your observations – these things do happen, and clearly contribute to some of the problems with payroll implementations, if not actual wholescale failures.

    my experience is that at the time of writing the proposal, a potential team is assembled and their CVs included in the document as representative samples of the kind of skills available with the company. But by the time the bid is won, several months later, it is observed that none of them are available anymore. Maybe part of this is because of a process issue – typically a dedicated Pre-Sales team takes care of proposals, and they may not have up to date information about available resources.. But then – do they have enough people with equivalent skills to replace them? Mysteriously a vast army of freshly recruited people with little or no experience is assembled to man these projects. and they in turn flood the scn forums with questions on how to do stuff. Some of these do indeed pick up the trade as they go along, and become experienced process consultants – at which point of time, they move on – they don’t stay with the same company anymore, as clearly they have better opportunities elsewhere… At any given point of time, it appears that a particular SI will always have a small handful of experienced consultants and large number of inexperienced people.And they don’t seem to mind this much as it improves their cost structure and makes the proposal cost effective. And so it goes on.

    A Project team assembled with a large proportion of experienced consultants will probably not win the bid as they are going to be priced much higher.

    Maybe SAP certification can be used as a differentiator, if relatively junior consultants are to be used. – Unfortunately, in recent times, this has got diluted.

    • Hi Harish,

      Your experience is not unusual. Many firms win the bid and then move in less experienced consultants. I don’t think it is a timing issue but more calculated to increase profits.

      Hopefully this blog will reach potential clients so they are forewarned about what can happen with implementation partners replacing consultants.


  • Hi Paul,

    Thanks for tackling this thorny issue.

    Harish’s comment about perhaps using SAP certification as a differentiator if relatively junior consultants are to be used reminds me of Balaji Parsewar’s blog in the SAP Community Network Career Center How we all can bring transparency to SAP job market? (URL posted here with his permission). I note especially his points 1- Priority for SAP certified consultants at the time of recruitment, 4 – Skills Registry, and 5 – Fresher drive for certified consultants.


  • One of the issues I see – A LOT – in my role for SAP Education is customers and partners failing to invest in training their people.  Although Training is mentioned as a single item above – correct training will also help customers understand some of the other issues in the list.

    Often training is something which is considered as an afterthought on projects or is handed to an internal team who are more experienced with training people how to use that new release of MS Office.  (not exactly the same skill set required – “er.. so when are we going to write the SAP course?)

    There is a perception that SAP training is expensive which I believe is one of the biggest fallacies in our industry. The cost of training someone to really understand SAP is minimal when you look at daily consultancy rates. It makes much more sense to have one of the customers own team trained properly than to pay for one or two consultancy days as the knowledge stays within the organisation.

    The other factor I see a lot in – shall we say – the less successful projects is that the customer is told “don’t worry about training – its much more efficient to do Knowledge Transfer during the project. Our consultants can handle that”. I had a customer once who told me that for their two year long HCM business transformation project they would not be including any formal training plan for the project team as they had factored in an hour a week of Knowledge Transfer from their SI.

    Almost exactly two years later I met the same customer again when they came back to us asking for a full, costly, remedial training programme to be put together. This is only a single example of course but if they had budgeted a small amount for training in the first place then their KT strategy may have worked a lot better and they certainly would have saved themselves a lot of time and money.

    The irony in this for me is that of all people, teams working on HR implementations  HR ought to understand the value of investing in people.

    Great Post btw Paul!

    • Hi Chris,

      You make some very valuable points and I agree that training is overlooked by many organisations. When our company presents a proposal to a prospective client we include training as part of that proposal. For a new client wanting an implementation we will include a trainer as part of the team and they are therefore involved through the realisation and well aware of the business requirements and processes. This allows for a great training package to be provided to the client.

      The other area besides training that the client doesn’t focus enough time and energy on, is change management. Similar to training this is vital for the acceptance of the system as there is normally reluctance by the employees of an organisation to accept change. Perhaps if someone with a change management background that has read this article may like to add their comments, similar to Chris.

      Kind Regards


  • Paul,

    Nice blog.

    While some of the reasons you listed are really true, not all of them may be applicable in all cases. I had been part of SAP HCM projects, small and large across geographies both Onsite and Onsite-Offshore models and in different capacities.

    While Onsite-Offshore does raise challenges, it has become an inevitable part of the equation. As a result, the focus should be on how to overcome the challenge and mitigate the risks. Big or small projects, the costs are an important factor and the world looks at saving money.

    I have seen projects struggling even in a 100% Onsite model. And not for reasons of Vendor’s consultants. Currently i am observing a project (neither me nor my company is involved with) which is going on for 18 months and it is 100% onsite with all local consultants. Already there is a talk of postponing by 1 more quarter !!

    In my opinion, the following issues occur in general in ERP projects:

    a) Inadequate attention given to requirements study;

    b) Underestimating the need for comprehensive testing & training;

    c) Completely neglecting / underestimating Data Migration efforts

    Apart from the above, Payroll projects suffer particularly for the following reasons :

    1) Unrealistic estimation / thrust on timelines;

    2) Resources from customer side not allocating 100% time to the project;

    3) Trying to bring in legacy practices into SAP Payroll;

    4) In the name of Testing, giving undue focus to Parallel runs and not on how the payroll should be behaving in different scenarios;

    Even if a partner is honest enough to convey the impractical expectations, the answer had more or less been “well, this is what we want to achieve and the vendor who is able to achieve this will get the order” !!!

    So what do customer companies end up with? A huge pile up of responsibilities and activities of their side, which they can never achieve within the time frame required by the implementation partner. A complete breakdown of communication where each side tries to outdo each other in pointing out delays by the other side.

    Testing – Imagine running only parallel runs. I had a project where the existing legacy payroll was making very minute errors. This was found out when reconciliation of results was done between SAP Payroll and legacy results. Individually those errors in calculation logic were not big. But over a period of time, the amounts were quite high. And SAP Payroll was calculating correctly. It was a big dilemma for the customer to go back and admit mistakes in payroll and not knowing how many years it was going on. Result – they ended up matching SAP Payroll to make the same mistakes as their legacy. And project got extended by 4 months !

    Requirements – I had a project where the customer SME just sent the Union Agreement than explaining the payroll processes or rules. Fortunately the customer management listened to us and both consultants and customer SME sat together and came up with a Requirements document. I shudder to imagine what would have happened if they didn’t listen to us.

    Blaming a vendor is easy. Blaming a model is easy. But we need to realise that vendors also have their reputation at stake don’t want projects to fail. And having selected the vendor based on various parameters, the customer companies also will have to live upto their side of the bargain.

    The fundamental question in any ERP project should be about the motivation to go for ERP. If the motivation is to retire multiple systems then you can be 70% sure that the project will surely have overruns. Because the business users interests are in ensuring things run the same way in the new system. No amount of Change Management will reduce the probability.



    • Hi Venkat,

      Thanks for your input. It is great to get comments from other professionals which add to the discussion. I totally agree that when a business just wants to replicate their old processes on a new system without a review there will be problems. The one thing that is required by all parties is open and honest communication, particularly when the implementation partner (who supposedly has been engaged because of their experience) observes major issues. Unfortunately the making of a profit sometimes inhibits this communication for some.

      Kind Regards