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.
