Business-IT Strategies Advisory Service

Executive Update Vol. 12, No. 9

Systems Breakdown
Case Study:
A Square Peg and a Round Hole
by Phil Simon
Every organization uses software applications to
support its business processes. Some organizations buy,
some build, and some rent software as a service (SaaS).
Buying and integrating proprietary applications are
sometimes complicated by M&A activity; acquired or
merged organizations often use different applications
and systems than their new owners. CIOs facing this
type of problem should think long and hard when
considering integrating disparate applications.
New systems fail for many reasons. The following case
study involves a large organization that spent more
than US $3.5 million attempting to implement and integrate disparate applications over the course of several
years. This case study is instructive on a number of
fronts, showing:
„

„

„

An organization believing that its business processes
were unique and thus warranted a special, complicated system setup
An organization not understanding the role of a consultancy and the latter not knowing the definition of
“bad business”
An organization not having the personnel to support
the monster that it chose to create

Note: names of the organizations and individuals are fictitious
and represent a composite of actual situations encountered by
the author.

PROJECT BACKGROUND
LaBrie Healthcare is a large, multisite organization with
a hodgepodge of disparate systems. Over the course of a

CUTTER CONSORTIUM

number of years, LaBrie acquired several individual hospitals without imposing strict standards about systems
and data on these new acquisitions. As a result, each
hospital maintained a great deal of autonomy vis-à-vis
maintaining its own systems. What’s more, some sites
outsourced such functions as payroll, while others ran
these processes internally.
LaBrie aimed for simplicity: it wanted to implement
and integrate an enterprise resource planning (ERP)
system throughout the organization. However, rather
than have the ERP replace the disparate legacy systems,
LaBrie decided to simply add the enterprise system to
the fray. Additional interfaces would be incorporated
into its already complex systems’ framework. In other
words, LaBrie senior management decided to create a
monster. It attempted to stitch together a number of
disparate legacy systems via a third-party ETL (extract,
transform, and load) tool and keep them all in sync.
The overall system, and related ETL tools, would theoretically allow for disparate rules at each hospital, as
shown in Figure 1:
„

Interface 1. Basic employee demographic, payroll,
and benefit data are transmitted via an ETL tool
from different client legacy payroll systems into
an ERP system.

„

Interface 2. Benefit information is transmitted from
the ERP to the third-party benefit application (TPBA).

„

Interface 3. Data is transmitted from TPBA to the
ERP. In theory, this would ensure that the information in both systems is in sync.

„

Interface 4. Benefit elections are returned to the
legacy payroll systems, ensuring that employee
deductions are accurate and employees are covered
under health, dental, and other plans.

In the long term, LaBrie management intended to eliminate its legacy systems. Note that each interface was
actually a set of interfaces. To load employee benefits
from the legacy systems into the ERP, for example, each
of the following types of information needed to be
loaded separately: employee, employee dependent,
employee benefit, and employee dependent benefit.
What’s more, one error would cascade through the 

2

BUSINESS-IT STRATEGIES ADVISORY SERVICE

Legacy Payroll Systems
Interface 1

Interface 4
ERP

Interface 2

Third-Party Benefit
Application

Interface 3

Figure 1 — System architecture of case study.
chain. For example, if the system rejected an employee
due to an invalid Social Security number, then her benefits, dependents, and dependents’ benefits would also
kick out.
LaBrie management wanted to go live in October,
roughly one year after the project commenced. This
would coincide with its annual enrollment.

THE SALES CYCLE
LaBrie executives listened to proposals from different
consultancies, expressing their collective desire for an
exceptional setup due to LaBrie’s “unique business
needs.” LaBrie’s fundamental question to potential
partners was, “Can your firm stitch together these
different systems and make them talk to each other?”
Prospective partners should have responded not in
the affirmative but with two questions of their own:
1. Why does LaBrie need to do this?
2. Does LaBrie have the internal resources and expertise
to support the architecture it wants to create?
The majority of salespeople at large consultancies do
not want to appear difficult and risk losing business. As
a result, LaBrie management faced little resistance during the sales cycle. It found that most consulting firms
neither asked these kinds of questions nor emphasized
their importance.

XYZ CONSULTING
XYZ Consulting ultimately won the LaBrie account,
largely because of its name recognition. During the
sales cycle, XYZ partners strongly emphasized that it
had the talent to build the amalgam of systems that
LaBrie desired. XYZ was an established firm and could
not have claimed ignorance about LaBrie’s forthcoming
challenges. XYZ senior partners simply chose not to
advise LaBrie of the many difficulties that it would
undoubtedly face by undertaking such an endeavor.
If it had, then XYZ certainly would not have won the
business in the first place.
XYZ was a very large consulting organization. Within
it, the ERP group represented a very small percentage
of total company revenue. The salespeople at XYZ saw
a multimillion-dollar carrot and opted to ignore the
risks associated with chasing it. Surely, XYZ had overcome more formidable client challenges than the one
posed by LaBrie.
It is very likely that smaller boutique firms would have
walked away from this deal upon learning about what
LaBrie was determined to build. Smaller firms tend to
be very risk-averse to large IT failures.

PROJECT CHALLENGES
As expected, technical and people issues plagued the
project from the beginning.

The Executive Update is a publication of the Business-IT Strategies Advisory Service. ©2009 by Cutter Consortium. All rights reserved.
Unauthorized reproduction in any form, including photocopying, faxing, image scanning, and downloading electronic copies, is against
the law. Reprints make an excellent training tool. For information about reprints and/or back issues of Cutter Consortium publications,
call +1 781 648 8700 or e-mail service@cutter.com. Print ISSN: 1530-3470 (Executive Report, Executive Summary, and Executive Update); online/
electronic ISSN: 1554-7086.
Vol. 12, No. 9

©2009 Cutter Consortium 

3

EXECUTIVE UPDATE

Technical Issues
To be certain, many implementations face last-minute,
unexpected data issues and crises. A postmortem on
such implementations can typically find a few key
points at which the project derailed. On the other hand,
the LaBrie project had no viable chance of succeeding
from the start; the system architecture virtually ensured
that this project would never hit its financial and calendar objectives. Each application (legacy systems, ERP,
and TPBA) had its own business rules that, out of the
box, did not mesh with other rules in such systems.
All rules had to be created and maintained in external
tables to interact with each other. These tables were
technical in nature and, as such, were not available
to functional users. Any change to the system would
require IT involvement, thus making the system forever
tied to IT for even the most basic of system edits.
Other issues included:
„

„

„

„

„

The ERP did not conduct any transactions; it simply
housed transactions sent over via the first and third
interfaces. In laymen’s terms, the ERP just “got in
the way.”
No one on the project team had ever worked with all
of LaBrie’s systems, much less the ETL tool required
to make these systems talk to each other.
LaBrie’s project manager insisted on constant retesting, which magnified project delays. While the retesting may have been justified, there simply was no time
to run through another battery of tests. The project
manager realized the difficulty and impossibility but
had her marching orders from senior management.
Spiraling project cost was linked to several factors:
z

Delays and integration issues

z

LaBrie’s multiple license and support fees

LaBrie’s system configuration led to nine categories
of potential issues with this setup (three types of
issues in each of three systems, as shown in Table 1).

People Issues
XYZ’s sole functional ERP consultant (James) abruptly
left the organization for personal reasons, leaving an
enormous vacuum. XYZ eventually filled the position
five weeks later. Because James had not completed the
ERP’s setup before leaving, much of the interface development ceased during that period.

www.cutter.com

Table 1 — Types of Potential Issues During Implementation
System

Setup

Data

Interface

Legacy
Systems

x

x

x

ERP

x

x

x

TPBA

x

x

x

Lesson: Before undertaking a massive integration project,
organizations need a profound and complete understanding
of who will be working on a project, including what happens
if key end users and consultants leave. Failure to appreciate
these issues increases project risk exponentially.
On the client side, issues abounded. Because the project
was extremely technical in nature, most of the work
required both of the following:
„

Sign-off of LaBrie’s technical lead

„

Input of client-side functional end users

Quite frankly, end users were out of their element.
While they could appreciate the complexity of the
different applications and interfaces, they did not have
the skills to manage them independently once XYZ’s
consultants were scheduled to leave. This situation
fostered dependence on external consultants, making
LaBrie’s project manager justifiably weary. After all,
how could the project be successful if it basically guaranteed that expensive consultants were required indefinitely? In addition, what would happen if one of the
consultants left? Consultant attrition is not exactly
uncommon, as everyone saw earlier when James left.
On the functional side, LaBrie lacked the necessary
internal resources to address setup issues in the ERP.
Remember that a benefit election from the TPBA had
to pass through the ERP in order to make it all the way
back to each hospital’s individual payroll systems.
A perfect example of LaBrie’s lack of internal expertise occurred when XYZ’s chief functional consultant
(Derek) moved on to another project. Despite his copious documentation and attempts at knowledge transfer
to LaBrie personnel, interfaces failed because end users
could not properly change codes within the ERP. A new
or modified business rule could bring down the whole
house of cards. Derek had to be contacted to fix the
problem remotely. This was particularly scary given
that the ERP passed so few types of data to and from
the other systems via interfaces.

Vol. 12, No. 9 

4

BUSINESS-IT STRATEGIES ADVISORY SERVICE

Beyond the core implementation team, the level of
system expertise at LaBrie’s local hospitals was wholly
deficient. These end users did not understand what
was expected of them or, in fact, the point of the whole
project. Most became frustrated and could not or would
not follow test scripts, causing even more delays.
Lesson: The importance of communication cannot be understated during a project. Cooperation cannot be expected among
different end users when the entire point of the project has not
been communicated. What’s more, for a project of such scope
to have a remote chance of success, end users have to be held
accountable.
Tensions intensified throughout the project between
employees from LaBrie and XYZ. Testing revealed
many errors stemming from the different and overlapping systems. From the perspective of LaBrie end users,
their partner was one of the purported experts in the
field. As an organization, LaBrie was paying millions
of dollars for this project to meet specific deadlines,
which were routinely not being met. XYZ employees
expressed frustration over their management’s blind
acceptance of LaBrie’s complicated setup; the different
systems and interfaces were not meant to work in the
fashion desired by the client.
Additional people issues arose when LaBrie’s local end
users were summoned to corporate headquarters for
integrated testing. LaBrie’s employees resented being
taken away from their day jobs. They believed they had
more pressing issues to address; they saw testing the
new system as merely a distraction from their day jobs.
Finally, more problems stemmed from the presence of
an internal auditor (Terry) throughout the project. He
would trust reports that came only from “the system.”
To the extent LaBrie was implementing multiple systems, there was no one single standard report that could
capture all of the transactions sent up and down the
chain. While Derek created and ran such reports using
Microsoft Access, Terry chose not to trust them because
they had the potential for human error. His questions
about data integrity, however legitimate, served as a
major bottleneck throughout the entire project. Senior
management at LaBrie should have involved Terry
from the beginning, when his concerns could have been
appropriately integrated into the project plan.

Vol. 12, No. 9

OUTCOMES AND ADDITIONAL LESSONS
The project went live well after the initial date and well
past the initial budget of $3.5 million. LaBrie’s project
manager involuntarily left the organization well before
system activation. LaBrie’s executives claimed that they
did not know the extent to which the integration issues
would prove problematic and wanted blood. That may
have been true, but LaBrie was determined to have its
way from the beginning.
XYZ lost the LaBrie account and now has a less-thanstellar reputation in the ERP world. LaBrie brought in
a different consultancy that blew up the old architecture. With management’s blessing, it implemented the
vanilla ERP at each hospital individually, with each
legacy system replaced altogether.
The ERP vendor had already released a relatively mature
— and quite respectable — online benefit enrollment
application. That would have eliminated the need for
LaBrie to continue using both the legacy systems as well
as the TPBA. While this Web application was certainly
not “best of breed,” using it would have simplified the
project tremendously. Lesson: Minimizing the number of
vendors and data, integration, and system issues lessens the
number of issues and maximizes the chance of success on an
IT project.
LaBrie manifests a number of challenges and issues
that are endemic, to some extent, to many new systems
implementations (e.g., knowledge transfer and data
integrity). However, by and large, most of LaBrie’s issues
are atypical: rare is the organization these days that
attempts to integrate a set of completely disparate
systems. Organizations should aim for simplicity, transparency, and integration with respect to their systems.
By insisting on an overly complicated system architecture, LaBrie management essentially guaranteed the failure of a new system from day one. Lesson: Keep it simple.
LaBrie executives demanded a very complicated system
configuration, approved long before the first XYZ consultant ever showed up onsite. Lesson: Allow consultants
to be true partners and recommend intelligent architectures.
Aside from a horribly conceived setup, LaBrie’s disastrous systems failure ultimately resulted from the
inability of its senior management to enforce system
or data standardization across the entire organization.
End users at each hospital were used to having their

©2009 Cutter Consortium 

5

EXECUTIVE UPDATE

own sandboxes; they were not accustomed to working
and playing with other children. In the end, the executives who mandated this setup did not give the project
a remote chance of being successful on any term. Lesson:
Ensure buy-in prior to beginning a massive project.

ABOUT THE AUTHOR
Phil Simon, founder of Phil Simon Systems, is a seasoned
independent systems consultant, a public speaker, contributor
to different media outlets, and author of Why New Systems
Fail. In 2002, after six years of related corporate experience, he
started his company with the intent of optimizing organizations’ use of different technologies. With his extensive knowledge of many applications, Mr. Simon has cultivated more
than 30 clients from a wide variety of industries, including
healthcare, manufacturing, retail, telecommunications, education, and those in the public sector. He has worked with many
organizations that use enterprise systems in varied ways. As
a result, Mr. Simon simultaneously brings both breadth and
depth to the table. He is a graduate of Cornell University
and Carnegie Mellon University. He can be reached at
phil@philsimonsystems.com or via philsimonsystems.com.

www.cutter.com

Vol. 12, No. 9 

Cutter
IT Journal

The Journal of Information Technology Management

Get global perspectives and solutions to some of the most critical
business-technology issues facing organizations today!
Your Front-Row Seat to IT
Management Debate at the
Highest Level!
Every day, your organization is confronted
with the stark reality of having to achieve
more aggressive goals with a shrinking
budget, ever-changing requirements, and
impossible deadlines.
Few of you have the time to develop
well-supported arguments on how to get
your organization to improve its IT operations. It’s a tough trap: you know solutions
are out there, but you’re too busy to identify
them and convince your organization to
implement them.

Advice, Solutions, and Experience
That You Can Rely On
A Cutter IT Journal subscription helps you
break out of the trap. Every month, Cutter
IT Journal features a select guest editor
who articulates the controversial issues,
offers his or her opinion on them, invites
others to introduce opposing viewpoints,
and sparks a lively debate.

Cutter IT Journal provides you the opportunity to experience a variety of perspectives:
viewpoints that will be instrumental in
advancing the cause of better software
development. No matter where you stand
on these issues, the thoughtful discourse
delivered in Cutter IT Journal will certainly
help you clarify your position.
In addition to your monthly journal issue,
you will also receive the weekly Cutter
E-Mail Advisor. Each Advisor brings you
practical advice and thoughtful analysis from
well-known and respected experts in the IT
field. Learn from the experiences of others,
including what you should avoid and what
you should consider implementing.
As a subscriber to Cutter IT Journal, you’ll
stay up to date on important IT issues such
as project management, security, risk management, business intelligence, sourcing,
enterprise architecture, requirements, trends
in technology, and more. Whatever the
topic, you can be sure you’ll receive frank,
unbiased opinions, in the no-holds-barred
manner Cutter IT Journal is known for.

Don’t miss upcoming issues on:
n Sourcing Strategies for Weathering a

Recession
n The Convergence of Information Security

and Privacy
n Cloud Computing
n Semantic Web
n Social Networking

Begin your subscription to Cutter IT Journal
today! Just complete and return the form
below by fax to +1 781 648 8707,
call +1 781 648 8700, or order online in
our secure bookstore at www.cutter.com/
bookstore.html.
For more information on Cutter IT Journal,
please visit www.cutter.com/itjournal.html.

Begin a New Subscription Today!
YES! Please start my new, one-year subscription to Cutter IT Journal and the weekly
Cutter IT E-Mail Advisor for just $485 or US $585 outside North America.
Name

Title

Company

Dept.

Address/PO Box

Mailstop/Suite

City

State/Province

ZIP/Postal Code

Country

Phone
Fax
E-Mail

Fax to +1 781 648 8707, call +1 781 648 8700, or send e-mail to service@cutter.com. Mail to Cutter Consortium, 37 Broadway, Suite 1, Arlington,
MA 02474-5552, USA. Order online at www.cutter.com/bookstore.html.