Contents

The Background
Challenges
Reasons Attributed to Failure
Preparatory Plan
Plan Execution
Real Reasons for Failure
Lessons Learnt

Summary:

This is a real life case story of how a failed PeopleSoft ERP Implementation which had not delivered the results and was in doldrums was brought back on track. There was widespread dissatisfaction with the software and the consultants who had implemented the software. When I took over PeopleSoft ERP, three years' books of accounts globally had not been closed in the system. Data was extracted to excel sheets and then after due modifications, the final books had been prepared for three years. The data on PeopleSoft was not reliable for direct reporting. Needless to say, great opportunity was lost to use the vast data available in the system for critical decision support reporting.

As Head of Global Software department, when I took over the PeopleSoft implementation, there was widespread dissatisfaction about the ERP. PeopleSoft Finance and HR modules were implemented about three years back and both had serious issues. The data in Finance was never current so no reports were being taken from PeopleSoft. All finance reports were prepared in excel. HR too was in a mess, which was evident from the fact that no one was ever sure of a simple figure like the exact employee headcount in the company. So, though both modules were on the system and supposed to have been implemented and rolled out, no one trusted the data and all reporting was manual and "outside the system".

I will discuss how the derailed Financial Accounting implementation was set right in this article. How confidence was gained on the Headcount data in the HR PeopleSoft system is discussed in another case story.

Allegations were being made for the wrong selection or for improper implementation by IBM, who were the PeopleSoft implementer.  PeopleSoft had been implemented in all the global locations of the company. Most significantly, books had not been closed for three years globally on the system. Obviously, when the data on the system was not current or matching the reality, no useful reports were being derived from the system. All reporting and statutory books of accounts were produced using excel after extracting data from PeopleSoft and then doing "God-knows-what" on the data! You can imagine what great opportunity was lost to utilize the huge repertoire of useful data for critical business decisions.

Comments    Top

Challenges - Status When I Took Over

As stated earlier, the books of accounts were not closed  in the system worldwide for the last three years. Reports were generated outside the system using excel. Probing into the reason why this situation had precipitated, I was told that certain documents were pending and year end entries were also not made. 

Serious concerns were being aired that we did not have PeopleSoft experts in Finance department. A senior experienced person at VP/AVP level was recruited, but he left in a short period. Serious concerns were also being expressed for lack of PeopleSoft technical expertise in IT department. There were strong demands to either recruit an experienced PeopleSoft manager in IT department and send a few folks for training which was quite an expense. Technical PeopleSoft trained senior people were either not available or too expensive. 

I realized that process discipline was an issue. Vouchers were not entered on time and were pending. Most of the statutory record was in excel, which was prepared after extracting the data out of PeopleSoft and then modifying it for the "necessary" corrections due to pending vouchers not entered in the system. This provided great security risk.

To make matters worse, the version of PeopleSoft which we were using was about to go "out of support" by the vendor (Oracle). Oracle had announced a new version of PeopleSoft, and also announced that they would be stopping the support very soon for the older version which we were running. Which meant that we had to upgrade to the new version, but version upgrade could not be thought of unless we closed all our books which were pending for three years.

Reasons Attributed to Failure

Comments    Top

Plan for Worldwide Closure of Accounts

A new CFO (Chief Financial Officer) had recently joined us. I had an extensive dialog with the CFO. First, I clearly told him that this situation we were in was simply unacceptable - a situation where we could not trust the PeopleSoft data and could not get reports direct from PeopleSoft.  Data was handled in excel which was very unreliable and risky. I insisted that we should get "untouched-by-hand" reports from PeopleSoft.

I convinced the CFO that we had to reach a situation where all data in PeopleSoft reflected the "current real scenario", so that we could directly access instant reports from the system. This meant that all books for the past three years had to be closed and in future too books had to be closed promptly. All transactions had to be captured as they happened and no delay in entry could be tolerated. Delays which were attributed to non receipt of certain document could also not be tolerated. His Finance experts had to find a "valid" method to handle this situation using accepted financial practices (probably by making provisional entries and later making corrective or reversal entries), but no delays could be tolerated.

I forewarned the CFO that this was a major project and that he had to own and lead the project of closure of books globally. 

I created a six-months detailed action plan to be driven by CFO and monitored by me and my team. I assured the CFO that my team would provide the full technical support, product know-how and project management support. But he had to drive the Finance team worldwide to act as per our agreed project plan.  In the absesnse of suitable resources, I had to pick up one of my existing Project Managers (who was managing bespoke development projects and had no prior expertise in PeopleSoft), and made him incharge of PoepleSoft project. He was also mandated to develop PeopleSoft expertise and to train the existing team which at that time could not boast of real expertise. 

I convinced the CFO that there was a need for discipline to close books every month.

I did not recruit a PeopleSoft expert in my team but bestowed trust on one of my managers to develop the expertise and the team. He did a wonderful job and did not betray my trust. I created an expert out of my own team and he also created a good team. I had  someone very reliable to consult, to learn from and to brainstorm with whenever I had to make important decisions during challenging situations of the project.

Plan Execution

A detailed plan was laid out with clear roles and responsibilities, clear assignments of duties and authority strucures. We got into weekly global conference calls chaired by the CFO and attended by CFO, his global representatives who were part of the team and my own team. I facilitated the execution of the plan, but the CFO drove it. Since IT cannot exert the authority on the people who had to execute the plan, I  used the authority of CFO to drive it.

The books of accounts world-wide were closed and processes were put in place to ensure that books were regularly closed every month. 

I created an expert in PeopleSoft out of a regular Project Manager who had no prior experience in PeopleSoft. He trained and empowered the existing team. We had outsourced PeopleSoft consultants. I reduced the number of external consultants as I created my own experts from within the existing team and saved on the cost of the consultants.

We were not only able to close the books which were open for three years, we also put in place a process to ensure timely entry of data and closure of books. We also started our work for the next project of PeopleSoft version upgrade and made sure that we did the upgrade with minimum customizations.

Comments    Top

Real Reasons for Failure (on Hindsight)

"Blame it on the Implementer" Attitude

On hindsight, it does appear that the implementation and the team set up to run the implemented system was not appropriate. But unlike what was common belief within the company, the culrpit for ERP failure was not IBM (our ERP Implementer) alone. Our company  was equally responsible for the mess that we were in. As is often the case, all blame was being put on the implementer. In fact the implementation team leader who had implemented the system about four years ago had even shared his feelings with me - he almost cried on my shoulders when I joined. He said that the consultant is being made the culprit, but there were serious shortcomings from the company too. I could very well empathise with him.

Absense of CIO/Change Manager Role

Not many companies and CEOs recognize the fact that ERP implementation is a special skill. A CIO who has been involved in Software implementations (and not one who has been mainly focussing on infrastructure management) usually has the right change management skills apart from the technical skills to manage and steer an ERP implementation.

The primary blame on the part of our company was that it had not provided a strong and capable person as the Head of PeopleSoft implementation project when the implementation was taken up about four years ago. It is difficult to believe, but I was told that the Head of Audit was made responsible for PeopleSoft Project just because he had worked in a software company before. This is a typical mistake most top management teams commit - there is a misconception that  anybody with little software background can handle a ERP project. The ERP Implementation skill, the process knowledge, the people knowledge and the change management knowledge are never recognized as prerequisites for ERP implementation. 

What was stranger was that Audit Head was given this responsibility in spite of the fact that there was a full fledged IT department, and senior capable persons in IT department were available at our US office to Head this project. Audit person was not so conversant with the dynamics of push and pull of ERP Implementation.

Too Much Customization

Accounts department users were too reluctant to accept the processes defined in PeopleSoft. They asked for customizations and the consultant agreed. As a result there was too much of customization. There was no senior person from IT to question the demands for customization. The Audit head who was leading this project was not only not capable of doing this, he probably did not even understand the serious  implications of excessive customisations. The processes could have been re-engineered to suit the product. The team under the Audit head was too weak to resist the customization demands of the user departments. He could not insist that the team deliberated on alternate re-engineered processes before deciding to customize.

This again is the role that an ideal CIO who is a good Change Manager and process/people expert can play.

Lack of Process Discipline after Implementation

Even after going live on PeopleSoft, need for process discipline was never emphasised and enforced (and probably never even understood).  There was no involvement of top management, and no one emphasized on the need to drive process discipline. 

The top management and the senior management in Finance department did not realize that there were other people-related issues which could be cause of failure. If the system failed, they thought that it had to be because the product was not good, or the consultant did not do a good job. The critical role of the user department in ensuring process discipline was neither recognized not emphasized.

There was no PeopleSoft expertise in IT department. IT department should have created experts and got some members fully in the driver's seat during the implementation process itself when the IBM consultants were around.

Lessons Learnt

  IT department cannot exert any authority on user managers. IT department needs to take the Head of User Department into confidence and use the authority of the User Head to drive the change.

  Discipline has to be enforced from the top. People will always find ways to break the discipline initially as it looks easier, and any change is unsettling. Only when discipline becomes a way of life, life becomes easier than it was when discipline was not there (which looked easier initially). Entropy is always preferred.

  Nothing is so difficult to learn even for ordinary people. It is a mindset issue. It is possible to make experts out of very ordinary people. The obstacle is in the Manager's mind - the supervising manager limits the creativity of his wards by believing that it is too difficult to learn and that you need trained experts from the market.

   Such complex projects often present very challenging situations which need quick and effective decision making. Managers and heads of projects often need to depend on inputs from expert in the team to provide inputs for decision making. It is important to have technical experts in the team. It is possible to create experts within the team if there are none if the manager thinks positively and trusts people.

  The need for a skilled "IT-Driven Change Management Expert" (not just Change Management Expert) is never recognized by most top management teams when they embark on ERP implementation project.

  CEOs need to recognize the fact that ERP implementation is a special skill. A CIO, who has the right change management skills, business process re-engineering skills and people skills apart from the technical skills to manage and steer an ERP implementation, usually foots the bill.

  IT department should not only provide the technical expertise, they should be experts on IT-Driven Change management, people behavior and psychology of change.

  You will notice that the skills required here to bring back ERP implementation on track are not specific to PeopleSoft or SAP, or any other specific ERP package. The skills required are common to all ERPs.

  I was operating at a level where it is immaterial whether it is PeopleSoft, SAP or any other ERP. The people and change management strategies are the same for all ERPs and same whether it is a ERP or a lowly payroll application implementation. You need technical experts to run the show. But that expert need not be the manager himself. If the manager is the technical expert then s/he will not have the time nor inclination to do the strategic role. I had to combine the technical and strategic roles. I was able to do a perfect balance of the two and do justice to both.

  I was able to create a PeopleSoft expert and hence I did not need to overspend my time and attention on technology. Experts can be created. The problem is not of lack of talent but lack of trust on the part of the managers.

  When required, I was comfortable doing a deep dive in technology by involving my technical expert. I learnt from my experts, did a deep dive and came out of it. If managers are not comfortable with technology, they hardly can do technology deep dives and operate only at strategic levels. If they are obsessed with technology, they cannot come out of technical deep dives. They will be too engrossed in technology and ignore the strategic work that they are required to do. Managers need to strike a judicious balance.

(Keywords: failed ERP Implementation, Steering a failed ERP back on Track, Steering a failed ERP out of the Woods, dissatisfied ERP Customer, PeopleSoft ERP, ERP Implimentation Strategy, Process Issues in ERP Implementation, People Issues in ERP, Finance ERP, Behavioral IT)

More Articles on Team Development
From Fresh Graduate Trainee to Expert
My Success Stories