Back From The Brink

Jyoti Bandopadhyay, VP--IT for Indian company Torrent Power, was a worried man. He was in charge of an ERP implementation for the company, and had spent US$5.5 million on software licensing and US$82 thousand on hardware -- but the project was going nowhere.

And it stayed like that for 18 months.

In the meanwhile, users fumed. "There was much frustration among users," says Bandopadhyay recalling those dark days. They were not the only ones seeing red. Eager to take the business to the next level, the management of the power utility company was not pleased with being shackled down.

A Season of Failure

The inability of Torrent Power's ERP to take launch and its subsequent impact on business was not unique -- it was reflective of a time when ERP projects failed. The end of the century was strewn with examples of bad ERPs causing business damage. Among the most notorious examples included big brands like Hershey's. In November 1999, Hershey's reported a 19 per cent drop in third quarter net earnings, and placed part of the blame on 'computer problems'. The chocolate maker was having issues with its new order-taking and distribution system, a US$112 million combination of ERP, CRM and SCM software.

In the same year and month, Whirlpool blamed a shipment delay in part to its ERP implementation: apparently, orders for quantities smaller than one truckload faced snags in areas of order processing, tracking and invoicing.

But, by far, one of the biggest ERP failures of the time was at pharmaceutical company FoxMeyer. In a study The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP? Judy E. Scott from the University of Texas lists project management problems similar to what Torrent faced. One of the problems, according to Scott, was that FoxMeyer did not have the necessary skills in-house and relied on an external consultant to implement their ERP. At the height of the project there were over 50 consultants at FoxMeyer playing puppeteer-- many of who were inexperienced -- and consultant turnover was high.

The result of the badly put-together project was a disaster of nightmarish proportions. In a case in which the left hand did not know what the right hand was doing, FoxMeyer's systems began doubling all its shipments -- to the same customers, causing huge losses for the company. Thanks to glitches in the ERP system, customers who complained that they had received only a partial order, were sent new consignments. What the folks at FoxMeyer could not know was that the rest of the order had already been shipped -- only, it was going in another truck. Soon unrecoverable shipping errors amounted to the tens of millions. FoxMeyer was forced to file for bankruptcy and the main operating division of the US$5 billion company was sold for a mere $80 million.

Scaling a Mountain

The botched up project at Torrent Power wasn't going to take the then US$1.4 billion power company to the cleaners, but it was definitely proving to be a bug bear to the management.

In the latter end of the 1990's, putting together an ERP was critical to Torrent Power. At that time, the company was in high-growth mode. It had acquired management control of Surat Electricity Company in 1996-97. The company had also bought up The Ahmedabad Electricity Company in 1998-99.

A look at the four years leading up to the beginning of the ERP in 1998 shows how fast the company was adding on substations and business.

This fast growth needed reliable and scalable IT systems to back it up. But, in 1998, Torrent Power was using a spreadsheet-based reporting system, which was not adequate for its functioning or for its future growth plans. "There was no software for accounting, hence accounts were maintained purely on spreadsheets or manually," recalls Bandopadhyay.

"There were islands of departmental information, and the management decided to seek the help of a consultant to implement an ERP solution."

And in that choice lay a seed for disaster.

Page Break

Free Fall

The reasons behind any project's failure are hard to pin down to a single factor. According to Bandopadhyay, Torrent Power's inability to get its ERP off the ground comes down to three factors: a lack of organizational readiness, a lack of consultant experience, and that big project killer: a lack of user adoption.

These challenges overwhelmed the consultants. "The consultants were awarded the project in January 1998," recalls Bandopadhyay. In July of 2000 -- 30 months later -- the consultants were still rolling out modules and running the operational modules in parallel.

The problem, says Bandopadhyay, was that the consultant team was not accustomed to the power utility segment, and because of this, they kept asking for more time to get the project off the ground. They could not close the gap between themselves and their deadline. And as they got more desperate to reach a horizon that never got nearer, they moved away from the safety of the shore. With the pressure to meet finish mounting, the consultants isolated themselves from their users, driving the project on their own.

It was this lack of user involvement that Bandopadhyay says finally brought the project down. "Data entry was being done in parallel for the ERP. Users were frustrated with the dual recording of data and reporting because they had to maintain both systems in sync," he says.

Today, user involvement and change management are project management basics. But a decade ago, it was not such a focal point. Yet, today, it's still hard to bring change into an organization smoothly, which is why the lessons from a decade ago are relevant. By not taking users into the fold, the consultants had seeded failure into the project. "Most of the issues we had were related to the fact that functional users were not involved at the design and development stage by the consultant. They directly showed the software at the time of roll-out and implementation," says Bandopadhyay ruefully.

By the end of 2000, it was beginning to look like a dead-end for the IT team. But they had invested US$21 million and almost three years of their emotion and time and they were going to make a last-ditch attempt to save the project. However, the odds were stacked against them. User resistance, which could have been fixed earlier, had hardened and IT's credibility with the user community of Torrent was low.

Still, they were determined to fix the problem, even if it meant pulling out every last project management stop.

Light at the Tunnel's End

The first thing Bandopadhyay did was to get rid of the consultants. "The users were greatly dissatisfied with the approach of the consultant," Bandopadhyay says.

The move would serve twin purposes: it would hopefully remove an easy target to blame the failure on and more importantly, it would thrust ownership of the project back to the users. "Any ERP implementation should be owned by the functional users and not by a consultant or the IT department," he says.

Getting users to believe in them was not easy, not with an almost-failed project on their hands. But it was equally hard to ignore that the users were their only hope. Hence, says Bandopadhyay, the main objective was to involve user departments including business heads and their teams down the line. "The in-house IT department worked hard to build user confidence," says Bandopadhyay.

To do that, the IT team had a series of meetings with functional users, including people who were doing day-to-day data-entry for each module.

"All users were called together in a big conference room and their issues were discussed in detail. The concern among users was increase in data entry. Finally, with their agreement, a rollout plan was chalked out," says Bandopadhyay. The series of meetings he says, "solved 70 per cent of our issues."

Before he could get there, though, Bandopadhyay and his team set the stage by having meetings in smaller sectional groups. The aim, he says, was to "bring in confidence and a sense of responsibility within each group. And then have a higher-level, cross-functional meeting with each business function head."

Once he had the users on his side, Bandopadhyay set his sights on his next target: top management. "It was discussed with management that, in addition to the huge investments made, a lot of man-hours have already been invested. We also told them that the reason for the project failure was not the ERP software, but the lack of user involvement."

His approach is radically different from the method other CIOs have taken to save projects. Desperate CIOs have been known to leverage top management to whip users into obeying new mandates.

But Bandopadhyay was not going to take that road again. It was a lack of user ownership that had stalled the project the first time and he had learnt a lesson. "Always involve users in the complete lifecycle of a project. The users should own the responsibility of an implementation," he says.

Once this confidence was built, users were ready to take ownership and agreed to a roll-out plan. It was only then that the new plan was presented to management. It was easy to get the formal approval of management once the users were onboard, says Bandopadhyay.

With a groundswell under them, management agreed to Bandopadhyay's plan. "Top management commitment and proper empowerment at each level helped the relevant people drive the project as per schedule," Bandopadhyay points out.

Page Break

Pyramid of Control

The next step before Torrent was to come up with a structure that would ensure successful turnaround. This process would play a significant role in ensuring the successful completion of the project. But before this process was initiated, the newfound buy-in from the staff had to be channelized.

The structure involved a committed, full-time core team -- and since the focus was on the user, this team was to involve all functional users. In order to ensure balance, the team was carefully selected to get a mix of functional and technical resources with complementary skills. This team was to involve itself with business processes since the user-focus mandated the involvement of business process owners.

Then they sought support from data owners to clean the data, converting it as required, and then migrate it. End users were active participants in acceptance testing, training and owning the system.

With this framework of buy-in, Torrent moved ahead. To begin with, the structure added an executive sponsor, who represented the commitment of the top management to the project. The executive sponsor's duty was to define the overall vision of the implementation, ensure support and commitment from individual functional heads, and to participate in -- and authorize -- important communication and change management initiatives across the organization.

Aiding the executive sponsor was a steering committee, which was responsible for the successful completion of the implementation. The committee comprised senior management from Torrent Power and the systems integrator. This committee met regularly to review the status of the project and authorize necessary action for critical project activities.

Special care was also taken to ensure that the steering committee was properly staffed with relevant people. Members of the steering committee had to be nominated by the executive sponsor. To ensure active user participation, the heads of various departments were selected.

To perform the actual implementation, Torrent created a project management team that included a project manager from Torrent and a project manager from the system integrator. Both these project managers had to interact closely with each other -- and with the steering committee -- in order to complete the project.

Below the project managers were the process leaders, whose responsibility was to ensure the successful design and configuration of various modules of the solution in line with business needs. To avoid the problem faced with the consultants -- namely, a lack of core domain expertise in power utility -- these process leaders were specifically chosen after ensuring that they had knowledge of how the organization worked. This was critical because the process leader was responsible for all the divisions and areas that were impacted by a specific set of processes.

Aiding the process leaders were the core team members, who were drawn from all functions where a process was to be implemented. The main aim was to ensure that, between the process team leader and the process team members from Torrent Power, the group must possess adequate knowledge of business processes and issues.

In addition, there was also a data management team from Torrent Power, which was responsible for coordinating all data collection activities pertaining to the implementation.

"IT teams involved all functional people including senior and junior staff. They were requested to work as a team and to treat the project as their own. The challenge was to show management that an internal team could do what a consultant could not," says Bandopadhyay.

Page Break

Soft Landing

This structure helped Torrent break up the implementation into phases. This started with an evaluation phase to provide a business and technical foundation to the ERP system.

A preparation phase defined the scope of the project, and the blueprint phase described the business process requirements of the company.

This was followed by a realization phase that helped conceptualize the business process requirements of the company, a preparation phase that included user training, and finally, a go-live phase would see the transition from the old system to the new.

The turnaround took a mere four months. "The project was taken over by the IT department in December 2000 and went live in April 2001," says Bandopadhyay with pride.

The recovery, however, did not cover all of the original modules. Bandopadhyay says that initially, the consultant had planned the ERP with six modules: purchase order, inventory, accounts payable, general ledger, fixed assets, and job cost. The finance modules including general ledger, accounts payable and fixed assets were discontinued.

"The integration of purchase with accounts payable and general ledger was creating a lot of illogical variance entries," Bandopadhyay says. "These were not acceptable to the accounts department. Reporting was also a major issue with the accounts department, and the financial modules were discontinued."

The success of the project also outweighed other IT priorities. While Bandopadhyay would have preferred zero customization, he was forced to do some tinkering for the purchase module. This was required because the ERP module did not have any provision for taxes and other charges like excise, freight, loading and unloading charges, which are required by Indian regulations. It was painful, but a compromise was made.

Despite this, Bandopadhyay is pleased with the way things have panned out. "When the in-house IT team took charge of the implementation after discontinuing the consultant, they proved themselves by rolling out the implementation in a very short period," he says, his eye clearly on the big picture.

He adds that the organization also benefited from the ERP and "the users' demand for qualitative reports increased to a great extent," he says.

In the end, the project not only made an about-turn, it also marched ahead and raised the bar. And that's hard to top.