8/7/2019 Lifeson - Failure Case Study

1/4

System Failure Case Study: Replicating the Old in New Systems

Making a new system conform to the "old ways" of an existing system will ensurefailure.

Editor's Note:

What does a Fortune 500 company implementing a multimillion dollar enterprise systemhave in common with a 150-person firm building its own system? In each case, theorganization failed to activate and utilize its system as initially conceived by seniormanagement.

In his new book, Why New Systems Fail, author Phil Simon examines why three in fivenew systems experience major problems from the onset, from missing deadlines andexceeding budgets to failing to deliver expected functionality.

The case study presented here, adapted from Simon's book, illustrates one mistakeenterprises make when they want their new systems mimic an existing system ratherthan taking advantage of new features and functionality.

- - -

The following case study shows what happens when an organization rips out the guts ofa new system to have it mimic its predecessor. It proves that nothing good can comefrom such an endeavor.

Background

With over 50,000 employees across the globe, Lifeson is a large manufacturer thatlacked a central repository of information about its employees. Simple questions suchas "How many employees work here?" took weeks to answer. By the time that thenumber was calculated, it was doubtless incorrect. Also, relatively straightforwardadministrative processes, such as awarding employee bonuses and stock options, tooknearly six months, thus crippling any attempt by the HR department to function as atruly strategic partner. How could it? It was too tied up in basic administration and didnot have meaningful employee data, much less the means to analyze it.

From a systems perspective, Lifeson was a mess. For years, management created

disparate "Band-Aid" systems for very specific purposes. The following facts put itsinternal systems architecture into context:

Lifeson maintained over fifteen different homegrown HR and payroll applications. Even within the narrow area of employee compensation, data was widely

dispersed. One system housed annual merit increases while others containedbonuses and stock options. Foreign Service National and employee payroll datawere stored in two totally disconnected systems.

8/7/2019 Lifeson - Failure Case Study

2/4

Many individual employees kept separate spreadsheets and standalonedatabases containing information on employee skills, training courses, and thelike.

Within the main legacy system, end users processed three out of every five HRand payroll transactions retroactively. In other words, Lifeson administrative

personnel failed 60 percent of the time.

Reporting was less than ideal, as one can imagine. With so much data stored in somany different systems, most report requests were routed to IT. Also, as one wouldexpect, end-users often would have to submit report requests multiple times becausethe reports contained data that did not match their initial requests. Even when the ITfolks got it right, the data were at best inconsistent and, at worst, incomplete andinaccurate.

In the late-1990s, Lifeson finally decided to implement a Tier 1 ERP, using a phasedapproach. At least Lifeson didn't attempt to do it all at once, a massive undertaking.

Lifeson selected a boutique firm with both technical and functional expertise: JordanConsultants.

Implementation Issues

The implementation started internationally. Lifeson wanted to activate domestic sitesafter other parts of the globe were already live. In retrospect, this approach allowedmany of Lifeson's key domestic players -- against the project from the get-go -- to delaymaking important decisions and face the reality of the new system. Many of them hopedthat the project would never gain any traction internationally and the project would justgo away.

A Campaign of Misinformation Leads to Successful Internal Sabotage

Through a campaign of misinformation, opponents of the new system were able, atleast partially, to sabotage the project from the start. Rather than change businessprocesses and retire systems that had well outlived their usefulness, Lifesonmanagement had Jordan consultants dramatically customize the ERP, making itbasically another system in the company's labyrinth. In other words, Jordan insertedadditional code, screens, and batch jobs specifically to retrieve data from -- and senddata to -- Lifeson's existing array of systems. The ERP would house certain data butwould not actually create or alter it; it would simply be one big storage facility that would

typically be out of synch with Lifeson's other systems. Not exactly the best way toguarantee a positive ROI!

Aside from failing to deal with obstinate managers, Lifeson's top brass made a numberof other critical errors in the planning phase of the project. Lifeson failed to create acentral authority or committee within the company with the requisite "teeth" for holdingthe regions accountable to some type of data standard. For the most part, each regionof the globe marched to the beat of its own drummer. This gave additional ammunition

8/7/2019 Lifeson - Failure Case Study

3/4

to those vehemently opposed to the new system. As they saw it, if things were alreadyspiraling out of control internationally, why should Lifeson extend the project to theU.S.?

To say that everyone was "on board" with the new system at Lifeson could not have

been further from the truth. A few heavy hitters saw the new ERP as a means to "blowup" the eye chart of internal systems that had evolved over the years. These peoplewere few and far between; internal resistance to the project could not be understated.Specifically, two key directors at Lifeson (Dennis and Steve) fought tooth and nail to killthe project. The new system threatened their very existence at Lifeson. Manyopponents were sacred cows under the status quo, rich with institutional knowledge onhow the company's proprietary systems worked. In their eyes, the new systemthreatened their livelihoods.

At key meetings, Dennis and Steve would routinely misrepresent the functionality of theERP. For example, Dennis once claimed the new ERP could not update multiple

salaries concurrently, unlike his system. Never mind the fact that he was flat-out wrong;the other executives in the room were hardly ERP super users and could not commenton the veracity of his claim. One entry-level employee did mention that the ERP could,in fact, perform this task quite easily. His protestations, lamentably, fell on deaf ears.

The amount of disinformation surrounding the system was astounding. In a differentmeeting, Steve openly expressed his anger over spending over three million dollars "ona system that can't run a (expletive deleted) report." He actually believed that a systemthat many other large, multinational organizations successfully ran could not providebasic information and that Lifeson's internal systems were vastly superior.

That the implementation was occurring in three regions concurrently -- but not in the US-- posed its own set of problems. Jordan consultants were too geographically dispersedto alter the general direction of the project or any specific decisions, not that they hadthe power to do either. For Jordan, the Lifeson account was a huge win. Given theaforementioned obstinacy of folks like Dennis and Steve, the Jordan PM treaded verycarefully around Lifeson, knowing full well that the company could pull the plug at anypoint and find more obedient consultants at a moment's notice.

When the implementation finally did turn to the U.S., the project had a less-than-stellarreputation internally. Along with budgetary issues, Lifeson decided not to implement theERP's core modules. Rather, in lieu of buying a new training system, executives madethe unwise decision to implement the ERP's training module without having coreemployee information in that very system. This is analogous to having a branch of a treewithout the trunk. The system would store some employee classes and certifications butwould not store essential employee data such as job codes, departments, addresses,salaries, and key employment dates. Thus, simple questions such as, "Have allsalespeople received product training?" could not be answered.

Outcomes and Conclusion

8/7/2019 Lifeson - Failure Case Study

4/4

After spending over $5M, Lifeson eventually scrapped the ERP altogether. Steve andDennis won; broken internal systems and processes remained in place. A few yearslater, Steve and Dennis were shown the door and Lifeson opted to implement acompletely different system. As of this writing, that project is still ongoing.

The Lifeson case study shows that systems initially meant to simplify processing caneasily be corrupted by executives with an agenda and an honest belief that theirbusiness needs are different than those of other organizations. This belief is almostalways unfounded -- but try telling that to a senior director who has never workedanywhere else and is five years removed from his pension. A project of this scopeneeds many things to be successful. First and foremost, however, senior leadershipneeds, in the words of the U.S. Marines, to "lead, follow, or get out of the way."

Lifeson can be rated on the failure scale as an Unmitigated Disaster. Its new systemfailed due to the following factors:

Internal resistance to change Unsustainable setup Excessive integration Unnecessary maintenance of legacy systems Lack of standardization of data Lack of standardization of business practices

Lifeson attempted to integrate new systems into their spaghetti architectures. The vastmajority of the problems associated with the implementation and system failure can betraced directly back to management and setup issues. Executives believed that theirbusiness needs were unique and, as such, required a complicated and costly setup.

This assumption is almost always a big mistake.