|BACK | Key Success Factors | IT for Business | people issues in IT | other articles on IT | My IT Strategy | Download articles|
Steering a Failed PeopleSoft ERP Implementation back on Track
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".
Challenges - Status When I Took Over
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 for FailureVarious reasons were being attributed for the sorry state of our ERP system.
The most common reason was that PeopleSoft ERP was not suitable for us. Massive customizations had been made to suit our requirements, but that was still not enough to match our requirements.
Most people felt that we did not have expertise in PeopleSoft in the Finance Department. Another common reason attributed to the failure of ERP was that we did not have expertise in PeopleSoft in IT Department. We were unable to attract the right talent.
Most people also complained that our implementation partner IBM had not done a good job.
Plan for Worldwide Closure of Accounts
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.
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.
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.
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
Real Reasons for
Failure (on Hindsight)
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
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.
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
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
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.
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.
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.
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)
HomeFrom Bench to COE