Like several key CIOZone.com contributors, I used to work at
Baseline Magazine, where the centerfold feature was typically an
in-depth case study on information system implementations - and, often,
on system failures. Simon's book features some case studies, too, one
of which he has allowed me to share as an excerpt below. As a
journalist, my preference is to name names because that's part of how I
establish the credibility of the story I'm telling. Simon's case
studies are fictionalized - the names of companies and individuals have
been changed to protect the innocent and the guilty. On the other hand,
his are based on experience, and he assured me that the fictional
failures closely mirror actual projects he was involved in and his
thoughts about what went wrong and why.
"When I started in this field, I kept walking into projects that
were a mess. I thought for a while I was the unluckiest person in the
world," Simon said. Gradually, he realized that his experiences with
poor project management were all too common.
This title turns out to have been published on a print-on-demand
basis, rather than by a big publisher. This is an increasingly common
way for a new author to get into print and is perfectly respectable,
particularly for the author willing to hustle to do his own promotion.
Simon has yet to establish himself as an industry pundit, but he is
working on it. He speaks from his experience, but his experience is
mostly with implementing mid-market enterprise systems from Lawson
Systems, with a particular focus on human resources and payroll
aspects.
All that said, I found it to be a good read and as insightful as any
I have read about enterprise software project management and the
obstacles to success. When I spoke with him about the book, he made a
reasonable case for why experience with one software package versus
another was less important than the planning and the quality of the
management that go into an enterprise implementation.
"In my experience, the system itself is rarely the cause of the
problems in these projects, which tend to stem from people issues,"
Simon said. "I can count on one hand the number of times there has been
a true application failure, where the application didn't work the way
it was supposed to work."
Simon does a good job of working methodically through the problems
that can be introduced in the initial planning, at the system selection
stage, during implementation, and after a system goes into production.
To some extent, it's a consultant's viewpoint on the problem, with some
pointers on when you really ought to listen to your consultant
(because, if not, why did you bother to hire them). But he also goes
through decisions that should not be left to the consultant (for
example, entrusting system selection decisions to the consultant
without understanding the consultant's biases or alliances with
specific vendors).
The fictionalized case study in the excerpt below is from Chapter
11, Setup Issues. There are actually two case studies in this chapter.
The first, which is referenced briefly in this excerpt, is on "Portnoy
Healthcare," which decides on an excessively complicated setup and then
keeps piling on changes until the project collapses.
The point of the chapter is that the right system configuration is
extremely important to the success of an enterprise software
implementation. While the best of these systems can be customized to
support a variety of business processes through configuration (rather
than altering any of the core software), some configurations work
better than others.
This is one of the places where Simon thinks it is important for the
customer to listen to the consultant, and for the consultant to seek
out the correct configuration through an intelligent dialog with the
customer about the enterprise's true needs.
In the "Lifeson" case study outlined below, the client insists on a
configuration that will replicate the functionality of the legacy
system the new software is being brought in to replace, effectively
crippling the project. The villains in this story are a couple of
internal IT managers who make themselves into obstacles to the success
of the project.
Excerpt taken from "Why New Systems Fail"
Lifeson Case Study: Replicating the Old in the New
The following case study shows what happens when an organization
rips out the guts of a new system to have it mimic its predecessor. It
proves that nothing good can come from such an endeavor.
Background
With over 50,000 employees across the globe, Lifeson is a large manufacturer that lacked a central repository of information on its employees.
Simple questions such as "How many employees work here?" took weeks to
answer. By the time that the number was calculated, it was doubtless
incorrect. Also, relatively straightforward administrative processes,
such as awarding employee bonuses and stock options, took nearly six
months, thus crippling any attempt by the HR department to function as
a truly strategic partner. How could it? It was too tied up in basic
administration and did not 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 its internal 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
contained bonuses and stock options. Foreign Service National and
employee payroll data were stored in two totally disconnected systems.
- Many individual employees kept separate spreadsheets and
stand-alone databases containing information on employee skills,
training courses, and the like.
- Within the main legacy system, end-users processed three out of
every five HR and 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 so many different systems, most report requests were routed
to IT. Also, as one would expect, end-users often would have to submit
report requests multiple times because the reports contained data that
did not match their initial requests. Even when the IT folks got it
right, the data were at best inconsistent and, at worst, incomplete and
inaccurate.
In the late-1990s, Lifeson finally decided to implement a Tier 1
ERP, using a phased approach. 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: Jordan Consultants.
Implementation Issues
The implementation started internationally. Lifeson wanted to
activate domestic sites after other parts of the globe were already
live. In retrospect, this approach allowed many of Lifeson's key
domestic players - against the project from the get-go - to delay
making important decisions and face the reality of the new system. Many
of them hoped that the project would never gain any traction
internationally and the project would just go away.
A Campaign of Misinformation Leads to Successful Internal Sabotage
Through a campaign of misinformation, opponents of the new system
were able, at least partially, to sabotage the project from the start.
Rather than change business processes and retire systems that had well
outlived their usefulness, Lifeson management had Jordan consultants
dramatically customize the ERP, making it basically another system in
the company's labyrinth. In other words, Jordan inserted additional
code, screens, and batch jobs specifically to retrieve data from - and
send data to - Lifeson's existing array of systems. The ERP would house
certain data but would 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 to guarantee a
positive ROI!
Aside from failing to deal with obstinate managers, Lifeson's top
brass made a number of other critical errors in the planning phase of
the project. Lifeson failed to create a central authority or committee
within the company with the requisite "teeth" for holding the regions
accountable to some type of data standard. For the most part, each
region of the globe marched to the beat of its own drummer. This gave
additional ammunition to those vehemently opposed to the new system. As
they saw it, if things were already spiraling out of control
internationally, why should Lifeson extend the project to the US?
To say that everyone was "on board" with the new system at Lifeson
could not be further from the truth. A few heavy hitters saw the ERP as
a means to "blow up" the eye chart of internal systems that had evolved
over the years. These people were 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
kill the project. The new system threatened their very existence at
Lifeson. Many opponents were sacred cows under the status quo, rich
with institutional knowledge on how the company's proprietary systems
worked. In their eyes, the new system threatened their livelihoods.
At key meetings, Dennis and Steve would routinely misrepresent the
functionality of the ERP. 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 comment on 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 different meeting, Steve openly expressed his anger over spending
over three million dollars "on a system that can't run a (expletive
deleted) report." He actually believed that a system that many other
large, multinational organizations successfully ran could not provide
basic 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 dispersed to alter the general direction of the
project or any specific decisions, not that they had the power to do
either. For Jordan, the Lifeson account was a huge win. Given the
aforementioned obstinacy of folks like Dennis and Steve, the Jordan PM
treaded very carefully around Lifeson, knowing full well that the
company could pull the plug at any point and find more obedient
consultants at a moment's notice.
When the implementation finally did turn to the US, the project had
a less-than-stellar reputation internally. Along with budgetary issues,
Lifeson decided not to implement the ERP's core modules. Rather, in
lieu of buying a new training system, executives made the unwise
decision to implement the ERP's training module without having core employee information in that very system. This
is analogous to having a branch of a tree without the trunk. The system
would store some employee classes and certifications but would not
store essential employee data such as job codes, departments,
addresses, salaries, and key employment dates. Thus, a simple questions
such as, "Have all salespeople received product training?" could not be
answered.
Outcomes
After spending over $5M, Lifeson eventually scrapped the ERP
altogether. Steve and Dennis won; broken internal systems and processes
remained in place. A few years later, Steve and Dennis were shown the
door and Lifeson opted to implement a completely different system. As
of this writing, that project is still ongoing.
Much like the Portnoy case study, Lifeson shows that systems
initially meant to simplify processing can easily be corrupted by
executives with an agenda and an honest belief that their business
needs are different than those of other organizations. This belief is
almost always unfounded but try telling that to a senior director who
has never worked anywhere else and is five years removed from his
pension. A project of this scope needs many things to be successful.
First and foremost, however, senior leadership needs, in the words of
the US Marines, to "lead, follow, or get out of the way."
Excerpt taken from "Why New Systems Fail"
By Phil Simon, copyright 2009. All rights reserved. Reprinted with permission.Paperback: 264 pages
Publisher: AuthorHouse; 1st edition (February 4, 2009)
Language: English
ISBN-10: 1438944241
ISBN-13: 978-1438944241
