20140409175526health_care_information_systems_2e_ch14__1_ 20140409175438health_care_information_systems_2e_ch15
C H A P T E R
14
MANAGEMENT’S ROLE IN
MAJOR IT INITIATIVES
LEARNING OBJECTIVES
■ To be able to understand the different types of organizational change associate
d
with IT initiative
s.
■ To be able to discuss the strategies for effecting organizational change.
■ To review the structures and processes used to manage IT projects.
■ To review the factors that contribute to IT project failures.
387
388 Management’s Role in Major IT Initiative
s
Health care organizations routinely undertake projects or initiatives designed to
improve the performance of the organization or advance its strategies through the use of
new or existing information technologies. Many of these projects involve the implemen-
tation of a major application system, and often these projects are labeled “IT projects.”
Examples of such projects include implementing computerized provider order entry,
streamlining the front-end processes of registration and scheduling, and enhancing th
e
discharge process.
This chapter discusses the role of management in these IT projects. The strategy
may have been defined and the IT agenda may have been aligned; now it is time
to execute the plan. What role should management play during the execution of IT
initiatives? What structures, processes, and roles should be in place to make sure tha
t
the initiatives are well managed?
This chapter covers three major topics:
■ Managing organizational change due to IT initiatives
■ Managing IT projects
■ Understanding factors that contribute to IT initiative failures
MANAGING CHANGE DUE TO IT
A majority of IT initiatives involve or require organizational change — change in pro-
cesses or organizational structure or change in the form of expansion or contraction of
roles or services. IT-enabled change and IT-driven change have several possible origins:
■ The new IT system has capabilities different from those of the previous sys-
tem and hence the workflow that surrounds the system has to change and the
tasks that staff perform have to change. For example, if a new electronic medical
record system automatically generates letters for patients with normal test results,
then the individuals who used to generate these letters will no longer have to do
this task.
■ The discussion surrounding the desired capabilities of a new application can lead to
a reassessment of current processes, workflow, and distribution of tasks across staff
and a decision to make changes in processes that extend well beyond the computer
system. For example, the analysis surrounding a new patient accounting system
might highlight problems that occur during registration and scheduling (such as
failure to check insurance coverage during appointment check-in) that hinder the
optimal performance of patient accounting. In this way a new system becomes a
catalyst for a comprehensive set of changes.
■ The health care organization’s strategy may call for significant changes in the
way the organization operates and delivers care. For example, the organizatio
n
may decide to move aggressively to protocol-driven care. This transformation has
extensive ramifications for processes, roles, and workflow and for the design of
applications. New IT systems will be critical contributors to the changes needed,
but they are not the epicenter of the change discussion.
Managing Change Due to IT 389
Change management is an essential skill for the leaders of health care organiza-
tions. Although the need for this skill is not confined to situations that involve the
implementation of major applications, change management is a facet of virtually all
implementations of such applications.
Types of Organizational Change
Keen (1997) identified four categories of organizational change:
■ Incremental
■ Step-shift
■ Radical
■ Fundamental
Incremental Change Incremental change occurs through a series (at times contin-
uous) of small to medium-sized changes to processes, tasks, and roles. Each change
carries relatively low risk, can be completed quickly, and is often accomplished with-
out the need for substantial analysis or leadership intervention. At times, organizations
establish an overall emphasis on continuous change and create groups to help depart-
ments make changes and measure change impact. Techniques such as LEAN and Six
Sigma emphasize continuous, incremental change. Continuous, incremental change can
be seen as plodding and lacking bold vision. However, this perception misses the power
of such change over the course of time and the occurrence of such change across many
facets of the organization. One should remember that the Grand Canyon was formed
from continuous, incremental erosion.
The implementation of an application can involve change that is incremental. This
is particularly true when the application is an upgrade of an existing application and
has new reports and features that require modest alterations to existing workflow.
One outcome of continuous change may be the recognition that current application
systems are progressively becoming a poor fit with the evolving organization. After
several years of dealing with a growing gap between the capabilities of an application
and the direction of an evolving organization, the organization may decide to purchase
a new application; one that is a better fi
t.
Step-Shift Change In step-shift change the leadership is committed to making sig-
nificant changes but is not changing the basic direction of the organization or how
it generates value. Examples of such change include a focused effort to significantly
reduce the cost of care or improve patient safety, the addition of a nonacute business
line in an organization that has previously focused on acute care, and a major effort
to improve the patient service experience in the outpatient clinics. Step-shift change
involves an intense focus on a critical aspect of the organization and, for the areas
within that focus, major changes in processes, roles, and tasks. Step-shift change is
often driven by a strategic realization that the basis of competition has evolved to the
point that in the absence of such change, the organization’s success is in some degree
of peril.
390 Management’s Role in Major IT Initiatives
This type of change invariably leads to the implementation of major new applica-
tions. An emphasis on patient safety may lead to the implementation of computerized
provider order entry, and an effort to improve the patient experience in outpatient ca
re
may result in the implementation of a new registration and scheduling application.
At times the leadership responsible for implementing a new application will realize
that this implementation creates the opportunity to effect step-shift change, asking, for
example, Why don’t we take advantage of this new outpatient system to make significant
improvements in the service experience?
Radical Change Radical change leaves the organization and its core assumptions
intact but significantly alters the way the organization carries out its business. The
creation of an integrated delivery system from a collection of previously independent
organizations is an example of radical change. The movement from fee-for-service
reimbursement to full capitation (that is, fixed fee per patient per year) is radical change.
Radical change always requires some changes, at times extensive changes, in the IT
application portfolio. Because the way work is done has changed significantly across
many facets of the organization, applications that fit the way work was previously done
may no longer be helpful.
In health care it is rare that IT will cause or lead to a decision to undergo radical
organizational change. The Internet frenzy that occurred in the early part of this century
led many health care organizations to wonder whether the Internet would cause radical
change. For example, if patients could look up medical information on the Internet
would this significantly reduce their need for physicians? This radical change did not
occur, although use of the Internet has led to incremental change and some step-shift
change.
Fundamental Change With fundamental change the leadership is committed to cre-
ating what will in effect be a new organization that is in a different business from
the one the current organization engages in. This fundamental change has occurred for
some companies. For example, the now deservedly maligned Enron changed its core
business from acquiring and managing natural gas pipelines to managing a complex
web of businesses that included a global broadband network and the trading of paper
products. A health care example would be an acute care provider that closes all its beds
and becomes a diagnostic imaging center. Fundamental change is risky, and the failure
rate is very high.
Clearly, in these cases the entire IT application suite may need to be jettisoned and
replaced with new applications that support the new business.
Effecting Organizational Change
The management strategies required to manage change depend on the type of change.
As one moves from incremental to fundamental change, the magnitude and risk of the
change increases enormously, as does the uncertainty about the form and success of the
outcome.
Managing Change Due to IT 391
In this section we will present some normative approaches to managing a blend of
step-shift and radical change. Fundamental change is rare in health care. Incremental
change carries less risk and hence requires less management. Note, however, that a
program of continuous incremental change is in effect a form of step-shift change.
Managing change of this magnitude (step-shift to radical) is deceptively simple and
quite hard at the same time. It is the same duality encountered in raising children. At one
level it is easy; all you have to do is feed, teach, protect, and love them. At another level,
especially during the teenage years, it can be an exceptionally complicated, exasperating,
and scary experience.
Managing change has several necessary aspects (Keen, 1997):
■ Leadership
■ Language and vision
■ Connection and trust
■ Incentives
■ Planning, implementing, and iterating
Leadership Change must be led. Leadership, often in the form of a committee of
leaders, will be necessary to
■ Define the nature of the change.
■ Communicate the rationale for and approach to the change.
■ Identify, procure, and deploy necessary resources.
■ Resolve issues, and alter direction as needed.
■ Monitor the progress of the change initiative.
This leadership committee needs to be chaired by an appropriate senior leader. If
the change affects the entire organization, the CEO should chair the committee. If the
change is focused on a specific area, the most senior leader who oversees that area
should chair the committee.
Language and Vision The staff who are experiencing the change must understand
the nature of the change. They must know what the world will look like (to the degree
that this is clear) when the change has been completed, how their roles and work life
will be different, and why making this change is important. The absence of this vision
or a failure to communicate the importance of the vision elevates the risk that staff will
resist the change and through subtle and not-so-subtle means cause the change to grind
to a halt. Change is hard for people. They must understand the nature of the change
and why they should go through with what they will experience as a difficult transition.
Leaders might describe the vision, the desired outcome of efforts to improve the
outpatient service experience, in this way:
■ Patients should be able to get an appointment for a time that is most convenient
for them.
392 Management’s Role in Major IT Initiatives
■ Patients should not have to wait longer than ten minutes in the reception area before
a provider can see them.
■ We should communicate clearly with patients about their disease and the treatment
that we will provide.
■ We should seek to eliminate administrative and insurance busywork from the pro-
fessional lives of our providers.
These examples illustrate a thoughtful use of language. They first and foremost
focus on patients. But the organization also wants to improve the lives of its providers.
The examples use the word should rather than the word must because it is thought that
staff won’t believe the organization can pull off 100 percent achievement of these goals
and leaders do not want to establish goals seen as unrealistic. The examples also use the
word we rather than the word you. We means that this vision will be achieved throug
h
a team effort, rather than implying that those hearing this message have to bear this
challenge without leadership’s help.
Connection and Trust Achieving connection means that leadership takes every
opportunity to present the vision throughout the organization. Leaders may use depart-
ment head meetings, medical staff forums, one-on-one conversations in the hallway,
internal publications, and e-mail to communicate the vision and to keep communicating
the vision. Even when they start to feel ill because they have communicated the vision
one thousand times, they have to communicate it another one thousand times. A lot of
this communication has to be done in person, where others can see the leaders, rather
than hiding behind an e-mail. The communication must invite feedback, criticism, and
challenges.
The members of the organization must trust the integrity, intelligence, compassion,
and skill of the leadership. Trust is earned or lost by everything that leaders do or don’t
do. The members must also trust that leaders have thoughtfully come to the conclusion
that the difficult change has excellent reasons behind it and represents the best option for
the organization. Organizational members are willing to rise to a challenge, often to
heroic levels, if they trust their leaders. Trust requires that leaders act in the best interests
of the staff and the organization and that leaders listen and respond to the organization’s
concerns.
Incentives Organizational members must be motivated to support significant change.
At times, excitement with the vision will be sufficient incentive. Alternatively, fear of
what will happen if the organization fails to move toward the vision may serve as an
incentive. Although important, neither fear nor rapture is necessarily sufficient.
If organizational members will lose their jobs or have their roles changed signif-
icantly, education that prepares them for new roles and or new jobs must be offered.
Bonuses may be offered to key individuals, awarded according to the success of the
change and each person’s contribution to the change. At times, frankly, support is
obtained through old-fashioned horse-trading — if the other person will support the
change, you will deliver something that is of interest to him or her (space, extra staff,
a promotion). Incentives may also take the form of awards — for example, plaques
Managing IT Projects 393
and dinners for two — to staff who go above and beyond the call of duty during the
change effort.
Planning, Implementing, and Iterating Change must be planned. These plans
describe the tasks and task sequences necessary to effect the change. Tasks can range
from redesigning forms to managing the staged implementation of application systems
to retraining staff. Tasks must be allotted resources, and staff accountable for task
performance must be designated.
Implementation of the plan is obviously necessary. Because few organizational
changes of any magnitude will be fully understood beforehand, problems will be
encountered during implementation. New forms may fail to capture necessary data.
The estimate of the time needed to register a patient may be wrong and long lines may
form at the registration desk. The planners may have forgotten to identify how certain
information would flow from one department to another.
These problems are in addition to the problems that occur, for example, when
task timetables slip and dependent tasks fall idle or are in trouble. The implementation
of the application has been delayed and will not be ready when the staff move to
the new building — what do we do? Iteration and adjustment will be necessary as the
organization handles problems created when tasks encounter trouble, and learns about
glitches with the new processes and workflows.
MANAGING IT PROJECTS
Within the overall change agenda, projects will be formed, managed, and completed.
In large change initiatives, the IT project may be one of several projects. For several
step-shift changes, the change management agenda may be composed almost entirely
of the implementation of an application system.
Change management places an emphasis on many of the “softer,” although still
critical, aspects of management and leadership: communicating vision, establishing trust,
and developing incentives. Project management is a “harder” aspect of management.
Project management centers on a set of management disciplines and practices that when
executed well, increase the likelihood that a project will deliver the desired results.
Project management has several objectives:
■ Clearly define the scope and goals of the project.
■ Identify accountability for the successful completion of the project and associated
project tasks.
■ Define the processes for making project-related decisions.
■ Identify the project’s tasks and task sequence and interdependencies.
■ Determine the resource and time requirements of the project.
■ Ensure appropriate communication with relevant stakeholders about project status
and issues.
Different projects require different management strategies. Projects that are pilots or
experiments require less formal oversight (and are not helped by large amounts of formal
394 Management’s Role in Major IT Initiatives
oversight) than large, multiyear, multimillion-dollar undertakings. Projects carried out
by two or more organizations working together will have decision-making structures
different from those found in projects done by several departments in one organization.
In this chapter we discuss a normative approach to managing relatively large
projects within one organization. (Much of the following discussion is adapted from
Spurr, 2003.) This approach is put in place once the need for the project has been estab-
lished (through the IT strategy, for example), the project objectives have been defined,
the budget has been approved, and the major stakeholders have been identified.
Project Roles
Four roles are important in the management of large projects:
■ Business sponsor
■ Business owner
■ Project manager
■ IT manager
Business Sponsor The business sponsor is the individual who holds overall account-
ability for the project. The sponsor should represent the area of the organization that is
the major recipient of the performance improvement that the project intends to deliver.
For example, a project that involves implementing a new claims processing system may
have the chief financial officer as the business sponsor. A project to improve nursing
workflow may ask the chief nursing officer to serve as business sponsor. A project that
affects a large portion of the organization may have the chief executive officer as the
business sponsor.
The sponsor’s management or executive level should be appropriate to the magni-
tude of the decisions and the support that the project will require. The more significant
the undertaking, the higher the organizational level of the sponsor.
The business sponsor has several duties; he or she
■ Secures funding and needed business resources: for example, the commitment of
people’s time to work on the project.
■ Has final decision-making and sign-off accountability for project scope, resources,
and approaches to resolving project problems.
■ Identifies and supports the business owner(s) (discussed in the next section).
■ Promotes the project internally and externally, and obtains the buy-in from business
constituents.
■ Chairs the project steering committee and is responsible for steering committee
participation during the life of the project
■ Helps define deliverables, objectives, scope, and success criteria with identified
business owners and the project manager.
■ Helps remove business obstacles to meeting the project timeline and producing
deliverables, as appropriate.
Managing IT Projects 395
Business Owner A business owner generally has day-to-day responsibility for run-
ning a function or a department: for example, a business owner might be the director
of the clinical laboratories. A project may need the involvement of several business
owners. For example, the success of a new patient accounting system may depend on
processes that occur during registration and scheduling (and hence the director of outpa-
tient clinics and the director of the admitting department will both be business owners)
and may also depend on adequate physician documentation of the care provided (and
hence the administrator of the medical group will be another business owner).
Business owners often work on the project team. Among their several responsibil-
ities they
■ Represent their department or function at steering committee and project team
meetings.
■ Secure and coordinate necessary business and departmental resources.
■ Remove business obstacles to meeting the project timeline and producing deliver-
ables, as appropriate.
■ Work jointly with the project manager on several tasks (as described in the next
section).
Project Manager The project manager does just that — manages the project. He or
she is the person who provides the day-to-day direction setting, conflict resolution, and
communication needed by the project team. The project manager may be an IT staffer
or a person in the business, or function, benefiting from the project. Among their several
responsibilities, project managers
■ Identify and obtain needed resources.
■ Deliver the project on time, on budget, and according to specification.
■ Communicate progress to sponsors, stakeholders, and team members.
■ Ensure that diligent risk monitoring is in place and appropriate risk mitigation plans
have been developed.
■ Identify and manage the resolution of issues and problems.
■ Maintain the project plan.
■ Manage project scope.
The project manager works closely with the business owners and business sponsor
in performing these tasks. Together they set meeting agendas, manage the meetings,
track project progress, communicate project status, escalate issues as appropriate, and
resolve deviations and issues related to the project plan.
IT Manager The IT manager is the senior IT person assigned to the project. He or
she may be the boss of the project manager. In performing his or her responsibilities,
the IT manager
■ Represents the IT department.
■ Has final IT decision-making authority and sign-off accountability.
396 Management’s Role in Major IT Initiatives
■ Helps remove IT obstacles to meeting project timelines and producing deliverables.
■ Promotes the project internally and externally, and obtains buy-in from IT con-
stituents.
Project Committees
These four roles may employ two or three major committees to provide project guidance
and management: a project steering committee, a project team, and a project review
committee.
Project Steering Committee The project steering committee provides overall guid-
ance and management oversight of the project. The steering committee has the authority
to resolve changes in scope that affect the budget, milestones, and deliverables. This
committee is expected to resolve issues and address risks that cannot be handled by the
project team. It also manages communications with the leadership of the organization
and the project team. The project steering committee may be the same committee that
leads the overall change process or a subcommittee of that group.
The business sponsor should chair this committee. Its members should be repre-
sentatives of the major areas of the organization that will be affected by the project and
whose efforts are necessary if the project is to succeed. Returning to an earlier example,
a steering committee overseeing the implementation of a new patient accounting system
might include the director of outpatient clinics, the director of the admitting department,
and the medical group administrator as members. The senior IT manager should also
be on this committee. Depending on the size and importance of the project, this person
could be the CIO. It is rare for the chair of the steering committee to be an IT person
although having an IT person as a cochair is not uncommon.
Project Team The project team may not be called a committee, but it will meet
regularly and it does have responsibilities. The project manager chairs the project team.
This team
■ Manages the performance of the project work.
■ Resolves day-to-day project issues.
■ Manages and allocates resources as necessary to do the work.
■ Works with the steering committee and business owners, as necessary, to resolve
problems; assess potential changes in scope, timeline, or budget; and communica
te
the status of the project.
Project team members may be business owners, business owners’ staff, IT man-
agers, or IT managers’ staff.
Project Review Committee If the organization has a relatively large number of
simultaneously active IT projects (say, fifty or so), a project review committee can be
helpful. The project review committee focuses on a subset of all IT projects, those
deemed to be the most important to the organization or the riskiest, or both. The review
Managing IT Projects 397
committee checks the status of each project in this subset to determine if the project
is proceeding well or likely to be heading into trouble. If trouble is on the horizon,
the committee discusses ways to reduce the threats to the project. The committee also
looks for opportunities to leverage the work from one project across other projects and
checks for areas where redundant work or work at cross-purposes may be occurring.
For example, two projects may need large numbers of workstations deployed during
the same interval of time. The IT group that deploys workstations cannot handle this
volume. The project review committee would discuss ways to resolve this problem.
The review committee serves as a second pair of eyes on critical projects and has
the ability to move resources between projects. For example, if Project A is experiencing
instability with its core infrastructure, the review committee can pull network engineers
and database server team members from Project B to help out on Project A. The review
committee is often chaired by a senior IT person and is composed largely of IT project
managers.
Key Project Elements
Over the course of decades and millions of projects, a set of management disciplines
and processes has been developed to help ensure that projects succeed. This collected
set of practices is referred to as project management. One will see these disciplines
and processes in action in any well-run project. Excellent project management does
not ensure project success. However, without such project management the risks of
failure skyrocket, particularly for large projects. The elements of project management
(above and beyond the roles just described) are reviewed in the following sections.
These elements are created or established after the project proposal has been approved.
Project Charter The project charter is a document that describes the purpose, scope,
objectives, costs, and schedule for the project. This document also discusses the roles
and responsibilities of the individuals and functions that must contribute to the project.
The project charter serves three basic objectives:
■ It ensures that planning assumptions or potentially ambiguous objectives are dis-
cussed and resolved (this occurs during development of the charter).
■ It prevents participants from developing different understandings of the project
intent, timeline, or cost.
■ It enables the project leadership to communicate as necessary with the organization
about the project.
The project charter sets out these project elements:
■ Project overview and objectives
■ Application features and capabilities (vision of the solution)
■ Project scope and limitations
■ Metrics for determining project success
■ Budget and overall timetable
398 Management’s Role in Major IT Initiatives
■ Project organization
■ Project management strategies
Appendix B contains an example of a project charter.
Project Plan The project charter provides an overview of the project. The project
plan provides the details of the tasks, phases, and resources needed, by task and phase
and timeline. The project plan is the tool used by the project team during the day-to-day
management of the project. The project plan has several components:
■ Project phases and tasks. A phase may have multiple tasks. For example, there may
be a phase called “conduct analysis,” and it may involve such tasks as “review
admitting department forms,” “document the admitting workflow,” and “document
the discharge workflow.”
■ The sequence of phases and tasks.
■ Interdependencies between phases and tasks.
■ The duration of phases and tasks.
■ Staff resources needed, by phase and task.
Several software tools are available that assist project managers in developing
project plans. These tools enable the project manager to develop the plan (as described
earlier), prepare plan charts and resource use by phase and task, and model the impact
on the plan if timelines change or resource availability alters.
Figure 14.1 is an example of a project timeline with project phases. Table 14.1
illustrates an analysis of project resources (staff) that shows project team members’
time commitment by activity.
Project Plan and Charter Considerations Developing project plans and charters
requires skill and experience. Managers are often in forums (such as project steering
committee meetings) where they are asked to review, critique, and approve a project
plan. What should they look for in these plans?
To a large degree, the reputations of project managers precede them. If project man-
agers have proven themselves over the course of many projects, then their plans are
likely to be generally sound. If project managers are novices or have an uneven track
record, their plans may require greater scrutiny. Regardless of track record, there are sev-
eral cues that a project plan is as solid as one can make it at the inception of the project:
■ The project charter is clear and explicit. Fuzzy objectives and vague understandings
of resource needs indicate that the plan needs further discussion and development.
■ The leaders of the departments and functions that will be affected by the plan or
that need to devote resources to the plan have reviewed the charter and plan, their
concerns have been heard and addressed, and they have publicly committed to
performing the work needed in the plan.
■ The project timelines have been reviewed by multiple parties for reasonableness,
and these timelines have taken into consideration factors that will affect the
plan — for example, key staff going on vacation or organizational energies being
FI
G
U
R
E
1
4
.1
.
P
ro
je
ct
T
im
e
li
n
e
w
it
h
P
ro
je
ct
P
h
a
se
s
P
A
C
E
P
h
a
s
e
I
II
C
ri
ti
c
a
l
P
a
th
M
il
e
s
to
n
e
s
a
n
d
T
im
e
li
n
e
6-Oct
13-Oct
20-Oct
27-Oct
3-Nov
10-Nov
17-Nov
24-Nov
1-Dec
8-Dec
15-Dec
22-Dec
29-Dec
5-Jan
12-Jan
19-Jan
26-Jan
2-Feb
9-Feb
16-Feb
23-Feb
1-Mar
8-Mar
15-Mar
22-Mar
29-Mar
5-Apr
12-Apr
19-Apr
26-Apr
3-May
10-May
17-May
24-May
31-May
7-Jun
14-Jun
21-Jun
28-Jun
5-Jul
12-Jul
19-Jul
26-Jul
2-Aug
9-Aug
16-Aug
23-Aug
30-Aug
6-Sep
13-Sep
20-Sep
27-Sep
4-Oct
11-Oct
18-Oct
25-Oct
D
e
s
ig
n
p
h
a
s
e
A
ct
u
a
l
B
u
il
d
&
m
o
d
v
a
li
d
a
ti
o
n
U
n
it
t
e
s
t
P
ro
d
u
c
t
te
s
t
I
n
te
g
ra
te
d
t
e
s
t
S
tr
e
s
s
&
v
o
lu
m
e
t
e
s
t
P
ro
d
u
c
ti
o
n
8
.3
1
L
it
e
P
l
a
n
T
e
s
t/
tr
a
in
G
o
l
i
v
e
O
p
e
ra
ti
o
n
a
l
re
a
d
in
e
s
s
P
ra
c
ti
c
e
r
e
a
d
in
e
s
s
C
S
S
r
e
a
d
in
e
s
s
P
a
ti
e
n
t
a
c
c
o
u
n
ts
r
e
a
d
in
e
s
s
I
n
fr
a
s
tr
u
c
tu
re
T
ra
in
in
g
L
o
g
is
ti
c
s
C
u
rr
ic
u
lu
m
d
e
v
e
lo
p
m
e
n
t
E
x
e
c
u
ti
o
n
M
P
I
c
o
n
v
e
rs
io
n
D
e
s
ig
n
/c
o
d
e
T
e
s
t
E
x
e
c
u
ti
o
n
C
u
to
v
e
r
to
g
o
l
iv
e
G
O
L
IV
E
L
e
g
e
n
d
B
la
ck
li
n
e
s
=
P
la
n
n
e
d
t
a
sk
t
im
e
G
ra
y
lin
e
s
=
A
ct
u
a
l t
im
e
W
h
ite
li
n
e
s
=
E
st
im
a
te
d
a
ct
u
a
l t
im
e
t
o
c
o
m
p
le
te
O
c
to
b
e
r
J
u
n
e
J
u
ly
S
e
p
te
m
b
e
r
O
c
to
b
e
r
M
a
y
A
u
g
u
s
t
D
e
c
e
m
b
e
r
N
o
v
e
m
b
e
r
A
p
ri
l
F
e
b
ru
a
ry
J
a
n
u
a
ry
M
a
rc
h
Today
O
c
to
b
e
r
1
s
t
g
o
l
iv
e
3
1
W
e
e
ks
t
o
G
o
L
iv
e
O
u
ts
ta
n
d
i
n
g
M
o
d
s
R
e
s
id
e
n
t
P
C
P
G
e
n
e
ri
c
A
R
P
S
R
u
le
s
E
D
I
B
a
tc
h
R
e
je
c
ti
o
n
D
a
ta
b
a
s
e
O
u
ts
ta
n
d
in
g
I
n
te
rf
a
c
e
s
P
ro
v
id
e
r
M
a
s
te
r
U
p
d
a
te
s
I
n
b
o
u
n
d
M
P
I
C
o
n
v
e
rs
io
n
:
S
ta
g
e
s
2
a
n
d
3
V
e
n
d
o
r
In
te
rf
a
c
e
(
H
o
s
p
it
a
l
s
p
e
c
)
O
u
ts
ta
n
d
in
g
R
e
p
o
rt
s
Today
–
S
p
li
t
A
c
c
o
u
n
t
–
L
in
k
in
g
L
o
g
ic
–
M
P
I
C
o
re
A
d
d
‘l
F
ie
ld
s
–
M
P
I
U
p
d
a
te
s
f
ro
m
P
A
C
o
re
U
n
it
T
e
st
a
n
d
a
ll
m
o
d
s
d
e
liv
e
re
d
t
h
r
o
u
g
h
t
h
e
e
n
d
o
f
F
e
b
‘0
4
n
e
e
d
t
o
b
e
d
e
b
u
g
g
e
d
b
y
0
4
/0
2
/0
4
in
p
re
p
a
ra
tio
n
fo
r
P
ro
d
u
ct
T
e
st
o
n
0
4
/0
5
/0
4
.
D
e
p
e
n
d
e
n
c
ie
s
:
=
=
>
M
G
H
c
o
m
p
le
te
s
u
n
it
te
st
=
=
>
V
e
n
d
o
r
tu
rn
s
a
ro
u
n
d
b
u
g
s
q
u
ic
kl
y
=
=
>
M
G
H
t
u
rn
s
a
ro
u
n
d
d
e
b
u
g
g
e
d
c
o
d
e
q
u
ic
kl
y
=
=
>
V
e
n
d
o
r
n
e
e
d
s
to
f
ix
t
h
e
b
u
g
s
th
e
f
ir
st
t
im
e
A
ll
m
o
d
s
d
e
liv
e
re
d
in
M
a
rc
h
‘0
4
n
e
e
d
t
o
b
e
d
e
b
u
g
g
e
d
b
y
0
4
/3
0
/0
4
in
o
rd
e
r
to
c
o
m
p
le
te
P
ro
d
u
ct
T
e
st
b
y
0
5
/3
1
/0
4
.
D
e
p
e
n
d
e
n
c
ie
s
:
=
=
>
M
o
d
s
m
u
st
b
e
d
e
liv
e
re
d
o
n
t
im
e
a
n
d
r
e
la
tiv
e
ly
c
le
a
n
o
f
b
u
g
s
=
=
>
V
e
n
d
o
r
m
u
st
t
u
rn
a
ro
u
n
d
b
u
g
s
q
u
ic
kl
y
a
n
d
f
ix
t
h
e
b
u
g
s
th
e
fir
st
t
im
e
=
=
>
M
G
H
m
u
st
t
u
rn
a
ro
u
n
d
t
h
e
b
u
g
f
ix
e
s
q
u
ic
kl
y.
P
ro
d
u
ct
T
e
st
f
o
r
n
o
n
-S
p
lit
a
n
d
n
o
n
-L
in
ke
d
S
ce
n
a
ri
o
s.
D
e
p
e
n
d
e
n
c
ie
s
:
=
=
>
D
e
ve
lo
p
a
n
d
s
ig
n
o
ff
o
f
T
e
st
C
o
n
d
iti
o
n
s
=
=
>
D
e
ve
lo
p
a
n
d
s
ig
n
o
ff
o
f
T
e
st
S
cr
ip
ts
=
=
>
P
re
p
f
o
r
P
ro
d
u
ct
T
e
st
P
ro
d
u
ct
T
e
st
f
o
r
S
p
lit
A
cc
o
u
n
t
a
n
d
L
in
ki
n
g
S
ce
n
a
ri
o
s.
D
e
p
e
n
d
e
n
c
ie
s
:
=
=
>
S
p
lit
A
cc
o
u
n
t
a
n
d
L
in
ki
n
g
m
u
st
b
e
u
n
it
te
st
e
d
.
=
=
>
A
ll
o
th
e
r
o
u
ts
ta
n
d
in
g
m
o
d
s
m
u
st
b
e
p
ro
g
ra
m
m
e
d
a
n
d
t
e
st
e
d
.
S
ta
rt
I
n
te
g
ra
ti
o
n
T
e
s
t.
D
e
p
e
n
d
e
n
c
ie
s
:
=
=
>
A
ll
m
o
d
s
co
d
e
d
a
n
d
u
n
it
te
st
e
d
.
=
=
>
A
ll
in
te
rf
a
ce
s
a
re
u
n
it
te
st
e
d
.
=
=
>
P
ro
d
u
ct
T
e
st
C
o
m
p
le
te
.
400 Management’s Role in Major IT Initiatives
TABLE 14.1. Project Resource Analysis
Analysis Project Activity Start Activity Finish Activity % Allocated*
Susan Smith
DFCI – CRIS –> Cancer
Registry Data Load
Application design 11/3/2008 11/10/2008 18.95%
DFCI – CRIS –> Cancer
Registry Data Load
Application testing 11/3/2008 12/12/2008 25.38%
DFCI – CRIS –> Cancer
Registry Data Load
Data mapping specification 11/3/2008 11/19/2008 17.25%
DFCI – CRIS –> Cancer
Registry Data Load
Functional analysis 11/3/2008 11/14/2008 35.00%
DFCI – CRIS Minor
Enhancements
CRIS breast minor
enhancements analysis
11/3/2008 11/2/2009 4.75%
DFCI – CRIS Minor
Enhancements
CRIS breast minor
enhancements testing
11/3/2008 11/2/2009 4.75%
DFCI CRIS/STIP GI
Development and
Implementation
GI CRA form
design/analysis
11/3/2008 1/29/2009 5.38%
DFCI CRIS/STIP GI
Development and
Implementation
GI follow-up form
design/analysis
11/3/2008 2/6/2009 5.75%
DFCI Renal STIP/CRIS Renal CRIS analysis 11/3/2008 2/5/2009
Administration 11/3/2008 9/30/2009 12.63%
Support work 11/3/2008 9/30/2009 55.50%
James Jones
BICS Modernization Background research 11/3/2008 10/28/2009 19.50%
BICS Modernization Develop overall project
plan
11/3/2008 12/13/2009 8.50%
BICS Modernization E-mail coding 11/3/2008 1/15/2009 10.00%
Gartner TCO Analysis Collect data and Input into
template —Rd 1
11/3/2008 11/11/2008 8.55%
LDRPS Implementation Plan building pilot group 11/3/2008 12/1/2008 11.00%
PHS Document
Management
VDRNETS security testing 11/3/2008 11/11/2008
Administration 11/3/2008 9/30/2009 19.50%
Support work 11/3/2008 9/30/2009 24.40%
∗Percentage of employee’s time devoted to a project during the interval bounded by the ‘‘start activity’’ date
and the ‘‘finish activity’’ date.
Understanding IT Initiative Failures 401
diverted to develop the annual budget — and any uncertainties that might exist for
particular phases or tasks — for example, if it is not fully clear how a specific task
will be performed, that task timeline should have some “slack” built into it.
■ The resources needed have been committed. The budget has been approved. Staff
needed by the plan can be named, and their managers have taken steps to free up
the staff time needed by the plan.
■ The accountabilities for the plan and for each plan phase and task are explicit.
■ Project risks have been comprehensively assessed, and thoughtful approaches to
addressing each risk developed. Some examples of project risks are unproven
information technology, a deterioration in the organization’s financial condition,
and turnover of project staff.
■ A reasonable amount of contingency planning has addressed inevitable problems
and current uncertainties. In general, projects should add 10 percent to the timeline
and 10 percent to the budget to reflect the time and dollar cost of inevitable prob-
lems. For very complex projects, it is not unusual to see 20 to 25 percent of the
budget and the duration of some tasks labeled “unknown” or “unclear.”
Project Status Report The project status report documents and communicates the
current condition of the project. This report is generally prepared monthly and dis-
tributed to project participants and stakeholders. The status report often provides matter
for discussion at steering committee meetings. It typically covers recent accomplish-
ments and decisions, work in progress, upcoming milestones, and issues that require
resolution (see the example in Exhibit 14.1). It may use a green (task or phase pro-
ceeding well), yellow (task or phase may be facing a timeline or other problem), and
red (task or phase is in trouble and requires attention) color scheme when graphically
depicting the status of a project. When a plethora of tasks and phases are tagged with
red, then the project is experiencing significant difficulty. Conversely, a sea of green
indicates that the project is going well.
The preparation, distribution, and discussion of the project status report are part of
the overall project communication plan. Other important communications might include
quarterly project presentations at meetings of the organization’s department heads, arti-
cles about the project in the organization’s internal newsletter, and presentations at
specific leadership forums: for example, at a medical staff forum or at a meeting of the
board or of the executive committee.
UNDERSTANDING IT INITIATIVE FAILURES
The failure rate of IT initiatives is surprisingly high. Project failure occurs when a
project is significantly over budget, takes much longer than the estimated timeline,
or has to be terminated because so many problems have occurred that proceeding
402 Management’s Role in Major IT Initiatives
EXHIBIT 14.1. Sample Project Status Report
Electronic Medication Administration Record (e-MAR) – Status Report
Reporting Period: July 2008
Business Sponsor: Sally Salisbury, RN, Vice President Patient Care Services
Business Owners: Amy Leron RN, Director of Nursing Quality and Practice; William Farnsworth RPh, Director of
Pharmacy
Information Systems Sponsors: Cindy Mason RNC, Corporate Director of Clinical Systems Management; Sue
Kimit, CIO-BWH
PROJECT SCHEDULE
Activity Planned Revised Actual
Delivery
Functional specification requirements completed • 01/08 • 07/08 • 07/08
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Technical Specifications completed • 02/08 • 11/28/08
Wireless Infrastructure in place for pilot pods • 02/08 • 9/15/08
Wireless Infrastructure in place for training room (Ledge Site) • 02/08 • 07/08 • 07/08
Wireless Infrastructure in place for pharmacy • 02/08 • 05/08 • 06/08
Wireless Infrastructure in place for all adult inpatient pods • 03/08 • 09/26/08
Bar Code development – Medications • 06/08 • 08/29/08
Bar Code development – Patient ID band Implementation • 05/08 • 08/15/08
Bar Code development – Clinical Staff Implementation (employee ID) • 05/08 • 08/15/08
Bar Code Imager Selection • 02/08 • 04/08 • 04/08
Adult Pharmacy development • 06/08 • 08/08
Adult Pharmacy application pilot • 08/05 • 08/25
Code Freeze (pilot) • 04/08 • 09/15/08
Integrated Testing (pilot) • 04/08 • 9/15/08 – 10/25/08
PILOT
Hardware Purchase (notebook, imager) • 06/08 • 07/08 • 07/08
Create Image/Test Fujitsu Lifebook • 06/08 • 07/08 • 07/08
Hiring/Training Support Staff • 07/08 • 09/26/08
Hardware Deployment • 08/08 • 10/27/08
Training – Planning complete • 06/08 • 07/08 • 07/08
Training – Development complete • 07/08 • 10/01/08
Training- Conduct Classes • 08/08 • 10/14 – 10/25
Implementation • 06/08 • 10/27
Evaluation of pilot • 07/08 • 12/08
ROLLOUT
Rollout Implementation Plan • 09/08 • 08/29/08
Hiring Support Staff • 12/08 • 01/ 04
Training Support Staff • 01/09 • 01/ 04
Hardware Deployment • 07/08 • 2/09 – 5/09
Training – Planning • 08/08 • 12/09
Training- Development • 09/08 • 01/ 04
Training- Conduct Classes • 09/08 • 02/01/09 – 05/08/09
Implementation Begin • 10/08 • 02/16/09
Implementation End • 04/09 • 05/21/09
ACCOMPLISHMENTS
• The functional requirements for the pilot have been agreed upon and finalized
DECISIONS
• The pilot date was revised to 10/27 – 11/21. The additional time is needed to complete the application
development for upcoming changes to OE, such as the new KCL scales and PCA templates
• The format for the Medical Record Copy of the eMAR was approved by Health Information Systems
WORK IN PROGRESS
• Completing the bar coded Employee ID badge. This should be ready for testing during the second week
in August
• Completing the bar coded patient ID band, which can be finalized when the font software arrives
Understanding IT Initiative Failures 403
EXHIBIT 14.1. (Continued)
• Programming for recently finalized eMAR specifications – scales, tapers, various templates, downtime
procedures, reports, etc.
• Programming for BICS changes necessary for eMAR
• Anne Bane is working with several cart vendors to secure carts for the pilot
• Wiring/cabling for the wireless network on the inpatient pods begins 8/4 and continues through 9/26
• Planning for integration testing
• Unit testing
ISSUES
• Accessing BICS from the web pod monitor is inconsistent and slow. The platform architecture specialists
are investigating a solution, and it’s being tested now
• The font software for patient ID bands has been delayed. Joanne Johnson is working to expedite this so
that final development can occur
Upcoming Activities
• ID badge replacement scheduled for RNs and pharmacists 8/14 – 8/22
• The pharmacy will conduct a pilot of its new web system beginning on 8/25
is no longer judged to be viable. Cook (2007) finds that 35 percent of IT projects
were successful whereas 19 percent failed. The remaining 46 percent delivered a useful
product but suffered from budget overruns, prolonged timetables, and application feature
shortfalls.
Cash, McFarlan, and McKenney (1992) note that two major categories of risk
confront significant IT investments: strategy failures and implementation failures. The
project failure rates suggest that management should be more worried about IT imple-
mentation than IT strategy. IT strategy is sexier and more visionary than implementation.
However, a very large number of strategies and visions go nowhere or are diminished
because the organization is unable to implement them.
Why is this failure rate so high? What happens?
In the sections that follow, we will examine several classes of barriers that hinder
large IT projects.
Lack of Clarity of Purpose
Any project or initiative is destined for trouble if its objectives and purpose are unclear.
Sometimes the purpose of a project is only partially clear. For example, an organization
may have decided that it should implement an electronic health record in an effort
to “improve the quality and efficiency of care.” However, it is not really clear to the
leadership and staff how the EHR will be used to improve care. Will problems associated
with finding a patient’s record be solved? Will the record be used to gather data about
care quality? Will the record be used to support outpatient medication ordering and
reduce medication error rates?
All these questions can be answered yes, but if the organization never gets beyond
the slogan of “improve the quality and efficiency of care.” the scope of the project will
404 Management’s Role in Major IT Initiatives
be murky. The definition of care improvement is left up to the project participant to
interpret. And the scope and timetable of the project cannot possibly be precise because
project objectives are too fuzzy.
Lack of Belief in the Project
At times the objectives are very clear, but the members of the organization are not
convinced that the project is worth doing at all. Because the project will change the work
life of many members and require that they participate in design and implementation,
they need to be sufficiently convinced that the project will improve their lives or is
necessary if the organization is to thrive. They will legitimately ask, What’s in it for
me? Unconvinced of the need for the project, they will resist it. A resistant organization
will likely doom any project. Projects that are viewed as illegitimate by a large portion
of the people in an organization rarely succeed.
Insufficient Leadership Support
The organization’s leaders may be committed to the undertaking yet not demonstrate
that commitment. For example, leaders may not devote sufficient time to the project or
may decide to send subordinates to meetings. This broadcasts a signal to the organization
that the leaders have other, “more important” things to do. Tough project decisions may
get made in a way that shows the leaders are not as serious as their rhetoric, because
when push came to shove, they caved in.
Members of the leadership team may have voted yes to proceed with a project,
but their votes may not have included their reservations about the utility of the project
or the way it was put together. Once problems are encountered in the project (and
all projects encounter problems), this qualified leadership support evaporates, and the
silent reservations become public statements such as, “I knew that this would never
work.”
Organizational Inertia
Even when the organization is willing to engage in a project, inertia can hinder it.
People are busy. They are stressed. They have jobs to do. Some of the changes are
threatening. Staff may believe these changes leave them less skilled or less instrumental
or with reduced power. Or they may not have a good understanding of their work life
after the change, and they may imagine that an uncertain outcome cannot be a good
outcome.
Projects add work on top of the workload of often already overburdened people.
Projects add stress for often already stressed people. As a result, despite the valiant
efforts of leadership and the expenditure of significant resources, a project may slowly
grind to a halt because too many members find ways to avoid or not deal with the
efforts and changes the initiative requires. Bringing significant change to a large portion
of the organization is very hard because, if nothing else, there is so much inertia
to overcome.
Understanding IT Initiative Failures 405
Organizational Baggage
Organizations have baggage. Baggage comes in many forms. Some organizations have
no history of competence in making significant organizational change. They have never
learned how to mobilize the organization’s members. They do not know how to handle
conflict. They are unsure how to assemble and leverage multidisciplinary teams. They
have never mastered staying the course over years during the execution of complex
agendas. These organizations are “incompetent,” and this incompetence extends well
beyond IT, although it clearly includes IT initiatives.
An organization may have tried initiatives “like this” before and failed. The pro-
ponents of the initiative may have failed at other initiatives. Organizations have very
long memories, and their members may be thinking something like, “The same clowns
who brought us that last fiasco are back with an even better idea.” The odor from prior
failures significantly taints the credibility of newly proposed initiatives and helps to
ensure that organizational acceptance will be weak.
Lack of an Appropriate Reward System
Aspects of organizational policies, incentives, and practices can hinder a project. The
organization’s incentive system may not be structured to reward multidisciplinary
behavior: for example, physicians may be rewarded for research prowess or clinical
excellence but not for sitting on committees to design new clinical processes. An inte-
grated delivery system may have encouraged its member hospitals to be self-sufficient.
As a result, management practices that involve working across hospitals never
matured, and the organization does not know how (even if it is willing) to work across
hospitals.
Lack of Candor
Organizations can create environments that do not encourage healthy debate. Such
environments can result when leadership is intolerant of being challenged or has an
inflated sense of its worth and does not believe that it needs team effort to get things
done. The lack of a climate that encourages conflict and can manage conflict means
that initiative problems will not get resolved. Moreover, organizational members, not
having had their voices heard, will tolerate the initiative only out of the hope that they
will outlast the initiative and the leadership.
Sometimes the project team is uncomfortable delivering bad news. Project teams
will screw up and make mistakes. Sometimes they really screw up and make really
big mistakes. Because they may be embarrassed, or worried that they will get beaten
up, they hide the mistakes from the leadership and attempt to fix the problems without
“anyone having to know.” This attempt to hide bad news is a recipe for disaster. It
is unrealistic to expect problems to go unnoticed; invariably the leadership team finds
out about the problem and its trust in the project team erodes. At times leadership has
to look in the mirror to see if its own intolerance for bad news in effect created the
problem.
406 Management’s Role in Major IT Initiatives
Project Complexity
Project complexity is determined by many factors:
■ The number of people whose work will be changed by the project and the depth
of those changes
■ The number of organizational processes that will be changed and the depth of those
changes
■ The number of processes linking the organization and other organizations that will
be changed and the depth of those changes
■ The interval over which all this change will occur: for example, will it occur quickly
or gradually?
If the change is significant in scale, scope, and depth, then it becomes very difficult
(often impossible) for the people managing the project to truly understand what the
project needs to do. The design will be imperfect. The process changes will not integrate
well. And many curves will be thrown the project’s way as the implementation unfolds
and people realize their mistakes and understand what they failed to understand initially.
Sometimes complex projects disappear in an organizational mushroom cloud. The
complexity overwhelms the organization and causes the project to crash suddenly. More
common is the “death by ants” — no single bite (or project problem) will kill the project,
but a thousand will. The organization is overwhelmed by the thousand small problems
and inefficiencies and terminates the undertaking.
Managers should remember that complexity is relative. Organizations generally
have developed a competency to manage projects up to a certain level and type of
complexity. Projects that require competency beyond that level are inherently risky. A
project that is risky for one organization may not be risky for another. For example, an
organization that typically manages projects that cost $2 million, take ten person-years
of effort, and affect 300 people will struggle with a project that costs $20 million and
takes one hundred person-years of effort (Cash et al., 1992).
Failure to Respect Uncertainty
Significant organizational change brings a great deal of uncertainty with it. The lead-
ership may be correct in its understanding of where the organization needs to go and
the scope of the changes needed. However, it is highly unlikely that anyone really
understands the full impact of the change and how new processes, tasks, and roles will
really work. At best, leadership has a good approximation of the new organization. The
belief that a particular outcome is certain can be a problem in itself.
Agility and the ability to detect when a change is not working and to alter its
direction are very important. Detection requires that the organization listens to the
feedback of those who are waist deep in the change, and is able to discern the difference
between the organizational noise that comes with any change and the organizational
noise that reflects real problems. Altering direction requires that the leadership not cling
to ideas that cannot work and also be willing to admit to the organization that it was
wrong about some aspects of the change.
Understanding IT Initiative Failures 407
Initiative Undernourishment
There may be a temptation, particularly as the leadership tries to accomplish as much as
it can with a constrained budget, to tell a project team, “I know you asked for ten people,
but we’re going to push you to do it with five.” The leadership may believe that such
bravado will make the team work extra hard and, through heroic efforts, complete the
project in a grand fashion. However, bravado may turn out to be bellicose stupidity. This
approach may doom a project, despite the valiant efforts of the team to do the impossible.
Another form of undernourishment involves placing staff other than the best staff
on the initiative. If the initiative is very important, then it merits using the best staff
possible and freeing up their time so they can focus on the initiative. An organization’s
best staff are always in demand, and there can be a temptation to say that it would be
too difficult to pull them away from other pressing issues. They are needed elsewhere
and this decision is difficult. However, if the initiative is critical to the organization,
then those other demands are less important and can be given to someone else. Critical
organizational initiatives should not be staffed with the junior varsity.
Failure to Anticipate Short-Term Disruptions
Any major change will lead to short-term problems and disruptions in operations. Even
though current processes can be made better, they are working and staff know how to
make them work. When processes are changed, there is a shakeout period as staff adjust
and learn how to make the new processes work well. At times, adjusting to the new
application system is the core of the disruption. A shakeout can go on for months and
degrade organizational performance. Service will deteriorate. Days in accounts receiv-
able will climb. Balls will be dropped in many areas. The organization can misinterpret
these problems as a sign that the initiative is failing.
Listening closely to the issues and suggestions of the front line is essential during
this time. These staff need to know that their problems are being heard and that their
ideas for fixing these problems are being acted upon. People often know exactly what
needs to be done to remove system disruptions. Listening to and acting on their advice
also improves their buy-in to the change.
While working hard to minimize the duration and depth of disruption, the organi-
zation also needs to be tolerant during this period and to appreciate the low-grade form
of hell that staff are enduring. It is critical that this period be kept as short and as pain
free as possible. If the disruption lasts too long, staff may conclude that the change is
not working and abandon their support.
Invisible Progress
Sometimes initiatives are launched with great fanfare. Speeches are made outlining the
rationale for the initiative. Teams are formed. Budgets are established. The organization
is ready to move. Then nothing seems to be happening.
Large, complex initiatives often involve large amounts of preparatory analysis and
work. These initiatives may also involve implementing a significant IT foundation of
408 Management’s Role in Major IT Initiatives
new networks and databases. And even though the project teams are busy, the rest of
the organization sees no progress and comes to believe that the initiative is being held
hostage. Action-oriented managers want to know what happened to the action.
Change initiatives and IT projects need to communicate their progress regularly,
even when that progress is largely unseen by the organization. In a similar fashion
the progress made in digging a new tunnel might be invisible to the motorist until the
tunnel is open, but the tunnel diggers can report regularly on the work that is being
done underground.
If possible, the project should seek to produce a series of short-term deliverables,
even if they are small. For example, while the IT team is performing foundational
work, the organization might go ahead and make some process changes without
waiting for the implementation of the application. Deliverables demonstrate that
progress is being made and help to sustain organizational commitment to the initiative.
Organizational commitment is like a slowly leaking balloon; it must be constantly
reinflated.
Lack of Technology Stability and Maturity
Information technology may be obviously immature. New technologies are being intro-
duced all the time, and it takes time for them to work through their kinks and achieve
an acceptable level of stability, supportability, and maturity. Some forms of Web 2.0
are current examples of information technologies that are in their youth.
Organizations can become involved in projects that require immature technology
to play a critical role. This clearly elevates the risk of the project. The technol-
ogy will suffer from performance problems, and the organization’s IT staff and the
technology supplier may have a limited ability to identify and resolve technology prob-
lems. Organizational members, tired of the instability, become tired of the project and
it fails.
In general it is not common, nor should it be often necessary, for a project to
hinge on the adequate performance of new technology. A thoughtful assessment that
a new technology has potentially extraordinary promise and that the organization can
achieve differential value by being an early adopter should precede any such decision.
Even in these cases, pilot projects that provide experience with the new technology
while limiting the scope of its implementation (which minimizes potential damage) are
highly recommended.
The organization should remember that technology maturity is also relative. Even
if the rest of the world has used a technology, if it is new to your vendor and new to
your IT staff, then it should be considered immature. Your vendor and staff will need
to learn, often the hard way, how to manage and support this technology.
Projects can also get into trouble when the amount of technology change is exten-
sive. For example, the organization may be attempting to implement, over a short
period of time, applications from several different vendors that involve different operat-
ing systems, network requirements, security models, and database management systems.
This broad scope can overwhelm the IT department’s ability to respond to technology
misbehavior.
Understanding IT Initiative Failures 409
CRITICAL SUCCESS FACTORS
Jay Toole outlines several critical success factors for successful clinical information
system (CIS) implementation and transformation of clinical processes.
■ Set realistic and clear expectations for the outcomes that will result from
implementing the CIS.
■ Recognize that implementing a CIS and transforming care processes is an
operational initiative and not an IT initiative.
■ Operational executives must take ownership of the implementation and
related transformation and must be held accountable for its success.
■ Clinicians must actively participate in the CIS design and implementation.
■ A liaison person knowledgeable in both IT and medical issues should be
designated to keep the physicians engaged in the implementation process.
■ A strong project manager with CIS implementation experience needs to be
dedicated to the initiative. [He or she] must have dedicated staff resources
with the right mix of clinical, operational and technical expertise.
■ A well-defined implementation plan and the ability to monitor and track
results against the plan is crucial.
■ Incentives must be aligned and these incentives should reward all participants
for successful implementation and achievement of predefined outcomes.
Source: Toole, 2003, p. 157.
PERSPECTIVE
How to Avoid These Mistakes
Major IT projects fail in many ways. However, a large number of these failures involve
management action or inaction. Few management teams and senior leaders start IT
projects hoping that failure is the outcome. Summarizing our discussion in this chapter
produces a set of recommendations that can help organizations reduce the risk of failure:
■ Ensure that the objectives of the IT initiative are clear.
■ Communicate the objectives and the initiative, and test the degree to which orga-
nizational members have bought into them.
■ Publicly demonstrate conviction by “being there” and showing resolve during tough
decisions.
■ Respect organizational inertia, and keep hammering away at it.
410 Management’s Role in Major IT Initiatives
■ Distance the project from any organizational baggage, perhaps through a thoughtful
choice of project sponsors and managers.
■ Change the reward system if necessary to create incentives for participants to work
toward project success.
■ Accept and welcome the debate that surrounds projects, invite bad news, and do
not hang those who make mistakes.
■ Address complexity by breaking the project into manageable pieces, and test for
evidence that the project might be at risk from trying to do too much all at once.
■ Realize that there is much you do not know about how to change the organization or
the form of new processes; be prepared to change direction and listen and respond
to those who are on the front line.
■ Supply resources for the project appropriately, and assign the project to your best
team.
■ Try to limit the duration and depth of the short-term operational disruption, but
accept that it will occur.
■ Ensure and communicate regular, visible progress.
■ Be wary of new technology and projects that involve a broad scope of information
technology change.
These steps, along with solid project management, can dramatically reduce the risk
that an IT project will fail. However, these steps are not foolproof. Major IT projects,
particularly those accompanied by major organizational change, will always have a
nontrivial level of risk.
There will also be times when a review of the failure factors indicates that a project
is too risky. The organization may not be ready; there may be too much baggage, too
much inertia to overcome; the best team may not be available; the organization may
not be good at handling conflict; or the project may require too much new information
technology. Projects with considerable risk should not be undertaken until progress has
been made in addressing the failure factors. Management of IT project risk is a critical
contributor to IT success.
IT PROJECT IMPLEMENTATION CHECKLIST
Andrew McAfee has developed a short checklist for managers who are overseeing
the implementation of IT projects. This checklist covers critical project management
actions necessary to avoid disaster:
■ Treat the implementation as a business change effort and not as a technology
installation. Project leadership should come from the business side, and the
business sponsor should be given the authority to make project decisions and
be held accountable for project outcomes.
PERSPECTIVE
Understanding IT Initiative Failures 411
■ Devote the necessary resources to the project. This means putting your best
people on the project and avoiding cutting corners on budgets and the use of
outside expertise.
■ Make sure that goals, scope, and expectations are clear from the outset.
Projects get in trouble when they are overhyped, scope is allowed to expand
without discipline, and goals are fuzzy.
■ Track the project’s progress, results, and scope. Sound project management —
for example, status reports, milestones, methodical reviews of proposals to
change scope, and budget tracking — must be in place.
■ Test the new system every way that you can before you go live. Testing and
retesting helps minimize unpleasant surprises, technology problems, and poor
fit with workflow.
■ Secure top management commitment. The leadership must believe in the
project — its goals, scope, and the project team. Leadership must also soberly
understand the magnitude and difficulty of the undertaking.
Source: Adapted from McAfee, 2003, p. 85.
SUMMARY
The leadership of health care organiza-
tions plays an essential role in managing
the change that invariably accompanies the
implementation of an IT application. This
role is particularly important in step-shift,
radical, and fundamental change. The lead-
ership must lead, establish a vision, com-
municate, manage trust, plan the change,
implement the change, and iterate as the
organization experiences the change.
The hard science of implementation
requires the creation of roles such as the
business sponsor and project managers
and committees such as the project steer-
ing committee and project teams. Solid
project management techniques must be
in place: for example, project charters and
project plans must be created, and project
communication must be carried out.
There are many ways that a project
failure can occur; unclear objectives,
embryonic information technology, or
neglecting to anticipate short-term oper-
ational disruptions may lead to failure,
for example. It is the responsibility of
the organization’s leadership to minimize
the occurrence and severity of factors that
threaten to undermine the change.
KEY TERMS
IT initiative failures
Managing IT projects
Organizational change
Project charter
Project committees
Project plan
Project roles
Project status report
412 Management’s Role in Major IT Initiatives
LEARNING ACTIVITIES
1. Attend a project team meeting for each of two different projects. Describe the
project and the challenges facing the project teams. Comment on the differences
between the teams and the projects.
2. Interview the business sponsor of a major project. Describe the role of this business
sponsor. Discuss the scope of the project and its objectives. Describe the change
strategy for the project.
3. Interview a project manager. Describe the factors and skills that he or she asso-
ciates with successful projects.
C H A P T E R
15
ASSESSING AND ACHIEVING
VALUE IN HEALTH CARE
INFORMATION SYSTEM
S
LEARNING OBJECTIVES
■ To be able to discuss the nature of IT-enabled value.
■ To review the components of the IT project proposal.
■ To be able to understand steps to improve IT project value realization.
■ To be able to discuss why IT investments can fail to deliver returns.
■ To review factors that challenge the realization of IT value.
413
414 Assessing and Achieving Value in Health Care Information Systems
Virtually all the discussion in this book has focused on the knowledge and manage
–
ment processes necessary to achieve one fundamental objective: organizational invest-
ments in IT resulting in a desired value. That value might be the furtherance of
organizational strategies, improvement in the performance of core processes, or the
enhancement of decision making. Achieving value requires the alignment of IT with
overall strategies, thoughtful governance, solid information system selection and imple-
mentation approaches, and effective organizational change.
Failure to achieve desired value can result in significant problems for the organiza-
tion. Money is wasted. Execution of strategies is hamstrung. Organizational processes
can be damaged.
This chapter carries the IT value discussion further. Specifically, it covers the
following topics:
■ The definition of IT-enabled value
■ The IT project proposal
■ Steps to improve value realization
■ Why IT investments may fail to deliver returns
■ Analyses of the IT value challenge
DEFINITION OF IT-ENABLED VALUE
We can make several observations about IT-enabled value:
■ IT value can be both tangible and intangible.
■ IT value can be significant.
■ IT value can be diverse across IT proposals.
■ A single IT investment can have a diverse value proposition.
■ Different IT investments have different objectives and hence different value propo-
sitions and value assessment techniques.
These observations will be discussed in more detail in the following sections.
Both Tangible and Intangible
Tangible value can be measured whereas intangible value is very difficult, perhaps prac-
tically impossible, to measure.
Some tangible value can be measured in terms of dollars:
■ Increases in revenue.
■ Reductions in labor costs: for example, through staff layoffs, overtime reductions,
or shifting work to less expensive staff.
■ Reductions in supplies needed: for example, paper.
■ Reductions in maintenance costs for computer systems.
Definition of IT-Enabled Value 415
■ Reductions in use of patient care services: for example, fewer lab tests are performed
or care is conducted in less expensive settings.
Some tangible value can be measured in terms of process improvements:
■ Fewer errors
■ Faster turnaround times for test results
■ Reductions in elapsed time to get an appointment
■ A quicker admissions process
■ Improvement in access to data
Some tangible value can be measured in terms of strategically important operational
and market outcomes:
■ Growth in market share
■ Reduction in turnover
■ Increase in brand awareness
■ Increase in patient and provider satisfaction
■ Improvement in reliability of computer systems
In contrast, intangible value can be very difficult to measure. The organization is
trying to measure such things as
■ Improving in decision making
■ Improving in communication
■ Improving in compliance
■ Improving in collaboration
■ Increasing in agility
■ Becoming more state of the art
■ Improving in organizational competencies — for example, becoming better at man-
aging chronic disease
■ Becoming more customer friendly
Significant
Glaser, DeBor, and Stuntz (2003) describe the return achieved by replacing the man-
ual approach to determining patient eligibility for coverage with an electronic data
interchange (EDI) based approach. One hospital estimated that for an initial invest-
ment of $250,000 in eligibility interface development and rollout effort, plus an annual
maintenance fee of $72,000, it could achieve ongoing annual savings of approximately
$485,000. This return on its EDI investment was achieved within one year of operation.
Wang et al. (2003) performed an analysis of the costs and benefits of the electronic
medical record (EMR) system in primary care. This sophisticated analysis explored
416 Assessing and Achieving Value in Health Care Information Systems
the return over a range of EMR capabilities (from basic to advanced), practice sizes
(small to large), and reimbursement structures (from entirely fee-for-service to extensive
risk-sharing arrangements). On average the net estimated benefit was $86,000 per
provider over five years.
Bates et al. (1998) found that a 55 percent reduction in serious medication errors
resulted from implementing inpatient provider order entry at the Brigham and Women’s
Hospital. This computerized order entry system highlighted, at the time of ordering,
possible drug allergies, drug-drug interactions, and drug–lab result problems.
Bu et al. (2007) estimated that the implementation of a range of telehealth tech-
nologies nationwide would save $14.5 billion in diabetes-related costs over ten years.
Diverse Across Proposals
Consider three proposals (real ones from a large integrated delivery system) that might
be in front of organizational leadership for review and approval: a disaster notifica-
tion system, a document imaging system, and an e-procurement system. Each offers a
different type of value to the organization.
The disaster notification system would enable the organization to page critical
personnel, inform them that a disaster — for example, a train wreck or biotoxin
outbreak — had taken place, and tell them the extent of the disaster and the steps they
would need to take to help the organization respond to the disaster. The system would
cost $520,000. The value would be “better preparedness for a disaster.”
The document imaging system would be used to electronically store and retrieve
scanned images of paper documents, such as payment reconciliations, received from
insurance companies. The system would cost $2.8 million, but would save the organi-
zation $1.8 million per year ($9 million over the life of the system) due to reductions
in the labor required to look for paper documents and in the insurance claim write-offs
that occur because a document cannot be located.
The e-procurement system would enable users to order supplies, ensure that the
ordering person had the authority to purchase supplies, transmit the order to the sup-
plier, and track the receipt of the supplies. Data from this system could be used to
support the standardization of supplies: that is, to reduce the number of different sup-
plies used. Such standardization might save $500,000 to $3 million per year. The actual
savings would depend on physician willingness to standardize. The system would cost
$2.5 million.
These proposals reflect a diversity of value, ranging from “better disaster response”
to a clear financial return (document imaging) to a return with such a wide potential
range (e-procurement) that it could be a great investment (if you really could save
$3 million a year) or a terrible investment (if you could save only $500,000 a year).
Diverse in a Single Investment
Picture archiving and communication systems (PACS) are used to store radiology (and
other) images, support interpretation of images, and distribute the information to the
physician providing direct patient care. A PACS can
Definition of IT-Enabled Value 417
■ Reduce costs for radiology film and the need for film librarians.
■ Improve service to the physician delivering care, through improved access to
images.
■ Improve productivity for the radiologists and for the physicians delivering care
(both groups reduce the time they spend looking for images).
■ Generate revenue, if the organization uses the PACS to offer radiology services to
physician groups in the community.
This one investment has a diverse value proposition; it has the potential to deliver
cost reduction, productivity gains, service improvements, and revenue gains.
Different for Different Objectives
The Committee to Study the Impact of Information Technology on the Performance of
Service Activities (1994), organized by the National Research Council, has identified
six categories of IT investments, reflecting different objectives. The techniques used to
assess IT investment value should vary by the type of objective that the IT investment
intends to support. One technique does not fit all IT investments.
FOUR TYPES OF IT INVESTMENT
Jeanne Ross and Cynthia Beath studied the IT investment approaches of thirty
companies from a wide range of industries. They identified four classes of invest-
ment:
■ Transformation. These IT investments had an impact that would affect the
entire organization or a large number of business units. The intent of
the investment was to effect a significant improvement in overall performance
or change the nature of the organization.
■ Renewal. Renewal investments were intended to upgrade core IT infrastruc-
ture and applications or reduce the costs or improve the quality of IT services.
Examples of these investments include application replacements, upgrades of
the network, or expansion of data storage.
■ Process improvement. These IT investments sought to improve the operations
of a specific business entity — for example, to reduce costs and improve service.
■ Experiments. Experiments were designed to evaluate new information tech-
nologies and test new types of applications. Given the results of the experi-
ments, the organization would decide whether broad adoption was desirable.
(Continued )
PERSPECTIVE
418 Assessing and Achieving Value in Health Care Information Systems
PERSPECTIVE (Continued )
Different organizations will allocate their IT budgets differently across these
classes. An office products company had an investment mix of experiments
(15 percent), process improvement (40 percent), renewal (25 percent), and trans-
formation (20 percent). An insurance firm had an investment mix of experiments
(3 percent), process improvement (25 percent), renewal (18 percent), and transfor-
mation (53 percent).
The investment allocation is often an after-the-fact consideration — the alloca-
tion is not planned, it just ‘‘happens.’’ However, ideally, the organization decides
its desired allocation structure and does so before the budget discussions. An
organization with an ambitious and perhaps radical strategy may allocate a very
large portion of its IT investment to the transformation class whereas an orga-
nization with a conservative, stay-the-course strategy may have a large process
improvement portion to its IT investments.
Source: Ross & Beath, 2002, p. 54.
Infrastructure IT investments may be for infrastructure that enables other invest-
ments or applications to be implemented and deliver desired capabilities. Examples of
infrastructure are data communication networks, workstations, and clinical data repos-
itories. A delivery system–wide network enables a large organization to implement
applications to consolidate clinical laboratories, implement organization-wide collabo-
ration tools, and share patient health data between providers.
It is difficult to quantitatively assess the impact or value of infrastructure invest-
ments because
■ They enable applications. Without those applications, infrastructure has no value.
Hence infrastructure value is indirect and depends on application value.
■ The allocation of infrastructure value across applications is complex. When millions
of dollars are invested in a data communication network, it may be difficult or
impossible to determine how much of that investment should be allocated to the
ability to create delivery system–wide EMRs.
■ A good IT infrastructure is often determined by its agility, its potency, and its
ability to facilitate integration of applications. It is very difficult to assign return
on investment numbers or any meaningful numerical value to most of these char-
acteristics. What, for instance, is the value of being agile enough to speed up the
time it takes to develop and enhance applications?
Information system infrastructure is as hard to evaluate as other organizational
infrastructure, such as having talented, educated staff. As with other infrastructure:
■ Evaluation is often instinctive and experientially based.
■ In general, underinvesting can severely limit the organization.
Definition of IT-Enabled Value 419
■ Investment decisions involve choosing between alternatives that are assessed based
on their ability to achieve agreed-upon goals. For example, if an organization wishes
to improve security, it might ask whether it should invest in network monitoring
tools or enhanced virus protection. Which of these investments would enable it to
make the most progress toward its goal?
Mandated Information system investment may be necessary because of mandated
initiatives. Mandated initiatives might involve reporting quality data to accrediting orga-
nizations, making required changes in billing formats, or improving disaster notification
systems. Assessing these initiatives is generally approached by identifying the least
expensive and the quickest to implement alternative that will achieve the needed level
of compliance.
Cost Reduction Information system investments directed to cost reduction are gener-
ally highly amenable to return on investment (ROI) and other quantifiable dollar-impact
analyses. The ability to conduct a quantifiable ROI analysis is rarely the question. The
ability of management to effect the predicted cost reduction or cost avoidance is often
a far more germane question.
Specific New Products and Services IT can be critical to the development of new
products and services. At times the information system delivers the new service, and at
other times it is itself the product. Examples of information system–based new services
include bank cash-management programs and programs that award airline mileage for
credit card purchases. A new service offered by some health care providers is a per-
sonal health record that enables a patient to communicate with his or her physician
and to access care guidelines and consumer-oriented medical textbooks. The value of
some of these new products and services can be quantifiably assessed in terms of a
monetary return. These assessments include analyses of potential new revenue, either
directly from the service or from service-induced use of other products and services.
A return-on-investment analysis will need to be supplemented by techniques such as
sensitivity analyses of consumer response. Despite these analyses the value of this IT
investment usually has a speculative component. This component involves consumer
utilization, competitor response, and impact on related businesses.
Quality Improvement Information system investments are often directed to improv-
ing the quality of service or medical care. These investments may be intended to reduce
waiting times, improve the ability of physicians to locate information, improve treat-
ment outcomes, or reduce errors in treatment. Evaluation of these initiatives, although
quantifiable, is generally done in terms of service parameters that are known or believed
to be important determinants of organizational success. These parameters might be mea-
sures of aspects of organizational processes that customers encounter and then use to
judge the organization: for example, waiting times in the physician’s office. A quantifi-
able dollar outcome for the service of care quality improvement can be very difficult
to predict. Service quality is often necessary to protect current business and the effect
of a failure to continuously improve service or medical care can be difficult to project.
420 Assessing and Achieving Value in Health Care Information Systems
Major Strategic Initiative Strategic initiatives in information technology are intended
to significantly change the competitive position of the organization or redefine the
core nature of the enterprise. In health care it is rare that information systems are
the centerpiece of a redefinition of the organization. However, other industries have
attempted IT-centric transformations. Amazon.com is an effort to transform retailing.
Schwab.com is an undertaking intended to redefine the brokerage industry through
the use of the Internet. There can be an ROI core or component to analyses of such
initiatives, because they often involve major reshaping or reengineering of fundamental
organizational processes. However, assessing the ROIs of these initiatives and their
related information systems with a high degree of accuracy can be very difficult. Several
factors contribute to this difficulty:
■ These major strategic initiatives usually recast the organization’s markets and its
roles. The outcome of the recasting, although visionary, can be difficult to see with
clarity and certainty.
■ The recasting is evolutionary; the organization learns and alters itself as it pro-
gresses, over what are often lengthy periods of time. It is difficult to be prescriptive
about this evolutionary process. Most integrated delivery systems (IDS) are con-
fronting this phenomenon.
■ Market and competitor responses can be difficult to predict.
IT value is diverse and complex. This diversity indicates the power of IT and the
diversity of its use. Nonetheless, the complexity of the value proposition means that it
is difficult to make choices between IT investments and also difficult to assess whether
the investment ultimately chosen delivered the desired value or not.
THE IT PROJECT PROPOSAL
The IT project proposal is a cornerstone in examining value. Clearly, ensuring that
all proposals are well crafted does not ensure value. To achieve value, alignment with
organizational strategies must occur, factors for sustained IT excellence must be man-
aged, budget processes for making choices between investments must exist, and projects
must be well managed. However, the proposal (as discussed in Chapter Thirteen) does
describe the intended outcome of the IT investment. The proposal requests money and
an organizational commitment to devote management attention and staff effort to imple-
menting an information system. The proposal describes why this investment of time,
effort, and money is worth it — that is, the proposal describes the value that will result.
In Chapter Thirteen we also discussed budget meetings and management forums
that might review IT proposals and determine whether a proposal should be accepted.
In this section we discuss the value portion of the proposal and some common problems
encountered with it.
Sources of Value Information
As project proponents develop their case for an IT investment they may be unsure of
the full gamut of potential value or of the degree to which a desired value can be
The IT Project Proposal 42
1
truly realized. The organization may not have had experience with the proposed appli-
cation and may have insufficient analyst resources to perform its own assessment. It
may not be able to answer such questions as, What types of gains have organiza-
tions seen as a result of implementing an electronic health record (EHR) system? To
what degree will IT be a major contributor to our efforts to streamline operating room
throughput?
Information about potential value can be obtained from several sources (discussed
in Appendix A). Conferences often feature presentations that describe the efforts of
specific individuals or organizations in accomplishing initiatives of interest to many
others. Industry publications may offer relevant articles and analyses. Several industry
research organizations — for example, Gartner and Forrester — can offer advice. Consul-
tants can be retained who have worked with clients who are facing or have addressed
similar questions. Vendors of applications can describe the outcomes experienced by
their customers. And colleagues can be contacted to determine the experiences of their
organizations.
Garnering an understanding of the results of others is useful but insufficient. It is
worth knowing that Organization Y adopted computerized provider order entry (CPOE)
and reduced unnecessary testing by X percent. However, one must also understand the
CPOE features that were critical in achieving that result and the management steps
taken and the process changes made in concert with the CPOE implementation.
Formal Financial Analysis
Most proposals should be subjected to formal financial analyses regardless of their value
proposition. Several types of financial measures are used by organizations. An orga-
nization’s finance department will work with leadership to determine which measures
will be used and how these measures will be compiled.
Two common financial measures are net present value and internal rate of return:
■ Net present value is calculated by subtracting the initial investment from the future
cash flows that result from the investment. The cash can be generated by new
revenue or cost savings. The future cash is discounted, or reduced, by a standard
rate to reflect the fact that a dollar earned one or more years from now is worth less
than a dollar one has today (the rate depends on the time period considered). If the
cash generated exceeds the initial investment by a certain amount or percentage,
the organization may conclude that the IT investment is a good one.
■ Internal rate of return (IRR) is the discount rate at which the present value of an
investment’s future cash flow equals the cost of the investment. Another way to
look at this is to ask, Given the amount of the investment and its promised cash,
what rate of return am I getting on my investment? On the one hand a return
of 1 percent is not a good return (just as one would not think that a 1 percent
return on one’s savings was good). On the other hand a 30 percent return is very
good.
Table 15.1 shows the typical form of a financial analysis for an IT application.
T
A
B
LE
1
5
.1
.
F
in
a
n
ci
a
l
A
n
a
ly
si
s
o
f
a
P
a
ti
e
n
t
A
c
c
o
u
n
ti
n
g
D
o
cu
m
e
n
t
Im
a
g
in
g
S
y
st
e
m
C
u
rr
en
t
Y
ea
r
Y
ea
r
1
Y
ea
r
2
Y
ea
r
3
Y
ea
r
4
Y
ea
r
5
Y
ea
r
6
Y
ea
r
7
C
O
S
T
S
O
n
e
-t
im
e
c
a
p
it
a
l
e
x
p
e
n
s
e
$1
,4
97
,4
66
$1
,3
02
,5
34
S
y
s
te
m
o
p
e
r
a
ti
o
n
s
S
ys
te
m
m
ai
n
te
n
an
ce
–
2
8
8,
0
0
0
$2
88
,0
00
$2
88
,0
00
$2
88
,0
00
$2
88
,0
00
$2
88
,0
00
$2
88
,0
00
S
ys
te
m
m
ai
n
te
n
an
ce
(P
H
S
)
–
15
2,
25
6
15
2,
25
6
15
2,
25
6
15
2,
25
6
15
2,
25
6
15
2,
25
6
15
2,
25
6
T
O
T
A
L
C
O
S
T
S
1,
49
7,
46
6
1,
74
2,
79
0
44
0,
25
6
44
0,
25
6
44
0,
25
6
44
0,
25
6
44
0,
25
6
44
0,
25
6
B
E
N
E
F
IT
S
R
e
v
e
n
u
e
g
a
in
s
R
eb
ill
in
g
of
s
m
al
l s
ec
on
d
ar
y
b
al
an
ce
s
–
6
5
1,
00
0
86
8,
00
0
86
8,
00
0
86
8,
00
0
86
8,
00
0
86
8,
00
0
86
8,
00
0
M
ed
ic
ai
d
b
ill
in
g
d
oc
u
m
en
ta
ti
on
–
22
5,
00
0
30
0,
00
0
30
0,
00
0
30
0,
00
0
30
0,
00
0
30
0,
00
0
30
0,
00
0
D
is
al
lo
w
ed
M
ed
ic
ar
e
b
ad
d
eb
t
au
d
it
–
–
–
–
10
0,
00
0
10
0,
00
0
10
0,
00
0
10
0,
00
0
S
ta
ff
s
a
v
in
g
s
P
ro
je
ct
ed
s
ta
ff
s
av
in
gs
–
36
,5
08
13
6,
04
0
15
6,
50
4
16
9,
06
5
16
9,
06
5
16
9,
06
5
17
1,
09
6
O
p
e
r
a
ti
n
g
s
a
v
in
g
s
P
ro
je
ct
ed
o
p
er
at
in
g
sa
vi
n
gs
–
64
,3
82
77
,0
15
21
8,
23
1
22
2,
55
0
22
6,
43
6
22
6,
54
3
22
9,
93
5
T
O
T
A
L
B
E
N
E
F
IT
S
–
97
6,
89
1
1,
38
1,
05
5
1,
54
2,
73
5
1,
65
9,
61
5
1,
66
3,
50
2
1,
66
3,
60
8
1,
66
9,
03
1
C
A
S
H
F
L
O
W
(1
,4
97
,4
66
)
(7
65
,8
99
)
94
0,
79
9
1,
10
2,
47
9
1,
21
9,
35
9
1,
22
3,
24
6
1,
22
3,
35
2
1,
22
8,
77
5
C
U
M
U
L
A
T
IV
E
C
A
S
H
F
L
O
W
(1
,4
97
,4
66
)
(2
,2
63
,3
65
)
(1
,3
22
,5
66
)
(2
20
,0
87
)
99
9,
27
2
2,
22
2,
51
7
3,
44
5,
86
9
4,
67
4,
64
4
N
P
V
(
1
2
%
d
is
c
o
u
n
t
)
1,
99
8,
06
8
IR
R
33
%
The IT Project Proposal 423
Comparing Different Types of Value
Given the diversity of value, it is very challenging to compare IT proposals that
have different value propositions. How does one compare a proposal that promises
to increase revenue and improve collaboration to one that offers improved compliance,
faster turnaround times, and reduced supply costs?
At the end of the day, judgment is used to choose one proposal over another.
Health care executives review the various proposals and associated value statements and
make choices based on their sense of organizational priorities, available monies, and
the likelihood that the proposed value will be seen. These judgments can be aided by
developing a scoring approach that allows leaders to apply a common metric across
proposals. For example, the organization might decide to score each proposal according
to how much value it promises to deliver in each of the following areas:
■ Revenue impact
■ Cost reduction
■ Patient or customer satisfaction
■ Quality of work life
■ Quality of care
■ Regulatory compliance
■ Potential learning value
In this approach, each of these areas in each proposal is assigned a score, ranging
from 5 (significant contribution to the area) to 1 (minimal or no contribution). The
scores are then totaled for each proposal, and in theory, one picks those proposals with
the highest aggregate scores. In practice, IT investment decisions are rarely that purely
algorithmic. However, such scoring can be very helpful in sorting through complex and
diverse value propositions:
■ Scoring forces the leadership team to discuss why different members of the team
assigned different scores — why, for example, did one person assign a score of 2 for
the revenue impact of a particular proposal and another person assign a 4? These
discussions can clarify people’s understandings of proposal objectives and help the
team arrive at a consensus on each project.
■ Scoring means that the leadership team will have to defend any decision not to
fund a project with a high score or to fund one with a low score. In the latter case,
team members will have to discuss why they are all in favor of a project when it
has such a low score.
The organization can decide which proposal areas to score and which not to score.
Some organizations give different areas different weights: for example, reducing costs
might be considered twice as important as improving organizational learning. The result-
ing scores are not binding, but they can be helpful in arriving at a decision about which
projects will be approved and what value is being sought. (A form of this scoring
process was displayed earlier in Figure 12.1).
424 Assessing and Achieving Value in Health Care Information Systems
Tactics for Reducing the Budget
Proposals for IT initiatives may originate from a wide variety of sources in an organi-
zation. The IT group will submit proposals as will department directors and physicians.
Many of these proposals will not be directly related to an overall strategy but may nev-
ertheless be “good ideas” that if implemented would lead to improved organizational
performance. So it is common for an organization to have more proposals than it can
fund. For example, during the IT budget discussion the leadership team may decide that
although it is looking at $2.2 million in requests, the organization can afford to spend
only $1.7 million, so $500,000 worth of requests must be denied. Table 15.2 presents
a sample list of requests.
TABLE 15.2. Requests for New Information System Projects
Community General Hospital
Project Name Operating Cost
TOTAL $2,222,704
Clinical portfolio development 38,716
Enterprise monitoring 70,133
HIPAA security initiative 36,950
Accounting of disclosure — HIPAA 35,126
Ambulatory Center patient tracking 62,841
Bar-coding infrastructure 64,670
Capacity management 155,922
Chart tracking 34,876
Clinical data repository — patient care
information system (PCIS) retirement
139,902
CRP research facility 7,026
Emergency Department data warehouse 261,584
Emergency Department order entry 182,412
Medication administration system 315,323
Order communications 377,228
Transfusion services replacement system 89,772
Wireless infrastructure 44,886
Next generation order entry 3,403
Graduate medical education duty hours 163,763
The IT Project Proposal 425
Reducing the budget in situations like this requires a value discussion. The lead-
ership is declaring some initiatives to have more value than others. Scoring initiatives
according to criteria is one approach to addressing this challenge.
In addition to such scoring, other assessment tactics can be employed, prior to the
scoring, to assist leaders in making reduction decisions.
■ Some requests are mandatory. They may be mandatory because of a regulation
requirement (such as the HIPAA Security Rule) or because a current system is so
obsolete that it is in danger of crashing — permanently — and it must be replaced
soon. These requests must be funded.
■ Some projects can be delayed. They are worthwhile, but a decision on them can
be put off until next year. The requester will get by in the meantime.
■ Key groups within IT, such as the staff who manage clinical information systems,
may already have so much on their plate that they cannot possibly take on another
project. Although the organization wants to do the project, it would be ill advised
to do so now, and so the project can be deferred to next year.
■ The user department proposing the application may not have strong management
or may be experiencing some upheaval; hence implementing a new system at this
time would be risky. The project could be denied or delayed until the management
issues have been resolved.
■ The value proposition or the resource estimates, or both, are shaky. The leadership
team does not trust the proposal, so it could be denied or sent back for further
analysis. Further analysis means that the proposal will be examined again next
year.
■ Less expensive ways may exist of addressing the problems cited in the proposal,
such as a less expensive application or a non-IT approach. The proposal could be
sent back for further analysis.
■ The proposal is valuable, and the leadership team would like to move it forward.
However, the team may reduce the budget, enabling progress to occur but at a
slower pace. This delays realizing the value but ensures that resources are devoted
to making progress.
These tactics are routinely employed during budget discussions aimed at trying to
get as much value as possible given finite resources.
Common Proposal Problems
During the review of IT investment proposals, organizational leadership might encounter
several problems related to the estimates of value and the estimates of the resources
needed to obtain the value. If undetected, these problems might lead to a significant over-
statement of potential return. An overstatement, obviously, may result in significant
organizational unhappiness when the value that people thought they would see never
materializes and never could have materialized.
Fractions of Effort Proposal analyses might indicate that the new IT initiative will
save fractions of staff time, for example, that each nurse will spend fifteen minutes
426 Assessing and Achieving Value in Health Care Information Systems
less per shift on clerical tasks. To suggest a total value, the proposal might multiply as
follows (this example is highly simplified): 200 nurses × 15 minutes saved per 8-hour
shift × 250 shifts worked per year = 12,500 hours saved. The math might be correct,
and the conclusion that 12,500 hours will become available for doing other work such
as direct patient care might also be correct. But the analysis will be incorrect if it
then concludes that the organization would thus “save” the salary dollars of six nurses
(assuming 2,000 hours worked per year per nurse).
Saving fractions of staff effort does not always lead to salary savings, even when
there are large numbers of staff, because there may be no practical way to realize
the savings — to, for example, lay off six nurses. If, for example, there are six nurses
working each eight-hour shift in a particular nursing unit, the fifteen minutes saved per
nurse would lead to a total savings of 1.5 hours per shift. But if one were then to lay off
one nurse on a shift, it would reduce the nursing capacity on that shift by eight hours,
damaging the unit’s ability to deliver care. Saving fractions of staff effort does not lead
to salary savings when staff are geographically highly fragmented or when they work
in small units or teams. It leads to possible salary savings only when staff work in very
large groups and some work of the reduced staff can be redistributed to others.
Reliance on Complex Behavior Proposals may project with great certainty that
people will use systems in specific ways. For example, several organizations expect
that consumers will use Internet-based quality report cards to choose their physicians
and hospitals. However, few consumers actually rely on such sites. Organizations may
expect that nurses will readily adopt systems that help them discharge patients faster.
However, nurses often delay entering discharge transactions so that they can grab a
moment of peace in an otherwise overwhelmingly busy day.
System use is often not what was anticipated. This is particularly true when the
organization has no experience with the relevant class of users or with the introduction
of IT into certain types of tasks. The original value projection can be thrown off by
the complex behaviors of system users. People do not always behave as we expect or
want them to. If user behavior is uncertain, the organization would be wise to pilot an
application and learn from this demonstration.
Unwarranted Optimism Project proponents are often guilty of optimism that reflects
a departure from reality. Proponents may be guilty of any of four mistakes:
■ They assume that nothing will go wrong with the project.
■ They assume that they are in full control of all variables that might affect the
project — even, for example, quality of vendor products and organizational politics.
■ They believe that they know exactly what changes in work processes will be needed
and what system features must be present, when what they really have, at best, are
close approximations of what must happen.
■ They believe that everyone can give full time to the project and forget that people
get sick or have babies and that distracting problems unrelated to the project will
occur, such as a sudden deterioration in the organization’s fiscal performance, and
demand attention.
The IT Project Proposal 427
Decisions based on such optimism eventually result in overruns in project budgets
and timetables and compromises in system goals. Overruns and compromises change
the value proposition.
Shaky Extrapolations Projects often achieve gains in the first year of their imple-
mentation, and proponents are quick to project that such gains will continue during the
remaining life of the project. For example, an organization may see 10 percent of its
physicians move from using dictation when developing a progress note to using struc-
tured, computer-based templates. The organization may then erroneously extrapolate
that each year will see an additional 10 percent shift. In fact the first year might be
the only year in which such a gain will occur. The organization has merely convinced the
more computer facile physicians to change, and the rest of the physicians have no
interest in ever changing.
Phantom Square Feet Project proposals often state that the movement to digital
records removes or reduces the need for space to house paper records. At the least,
they say, the paper records could be moved off site. This in turn can lead to the
claim that the money once spent on that storage space — for example, $40 per square
foot — can be considered a fiscal return. In fact, such space “savings” occur only when
the building of new space (for any purpose) does not occur because the organization
used the freed-up records space instead. Space, like labor, represents a savings only
when reducing the need for it truly does prevent further expenditure on space. If the
organization uses the freed-up space but never had any intention of spending money to
build more space, then any apparent savings are phantom savings.
Underestimating the Effort Project proposals might count the IT staff effort in the
estimates of project costs but not count the time that users and managers will have to
devote to the project. A patient care system proposal, for instance, may not include
the time that will be spent by dozens of nurses working on system design, developing
workflow changes, and attending training. These efforts are real costs. They often lead
to the need to hire temporary nurses to provide coverage on the inpatient care units,
or they might lead to a reduced patient census because there are fewer nursing hours
available for patient care. Such miscounting of effort understates the cost of the project.
Fairy-Tale Savings IT project proposals may note that the project can reduce the
expenses of a department or function, including costs for staff, supplies, and effort
devoted to correcting mistakes that occur with paper-based processes. Department man-
agers will swear in project approval forums that such savings are real. However, when
asked if they will reduce their budgets to reflect the savings that will occur, these same
managers may become significantly less convinced that the savings will result. They
may comment that the freed-up staff effort or supplies budgets can be redeployed to
other tasks or expenses. The managers may be right that the expenses should be rede-
ployed, and all managers are nervous when asked to reduce their budgets and still do
the same amount of work. However, the savings expected have now disappeared.
428 Assessing and Achieving Value in Health Care Information Systems
Failure to Account for Postimplementation Costs After a system goes live the
costs of the system do not go away. System maintenance contracts are necessary.
Hardware upgrades will be required. Staff may be needed to provide enhancements to
the application. These support costs may not be as large as the costs of implementation.
But they are costs that will be incurred every year, and over the course of several years
they can add up to some big numbers. Proposals often fail to adequately account for
support costs.
STEPS TO IMPROVE VALUE REALIZATION
Achieving value from IT investments requires management effort. There is no computer
genie that descends on the organization once the system is live and waves its wand
and — shazzam! — value has occurred. Achieving value is hard work but doable work.
Management can take several steps to realize value (Dragoon, 2003; Glaser, 2003a,
2003b). These steps are discussed in the sections that follow.
Make Sure the Homework Was Done
IT investment decisions are often based on proposals that are not resting on solid
ground. The proposer has not done the necessary homework, and this elevates the risk
of a suboptimal return.
Clearly, the track record of the investment proposer will have a significant influence
on the investment decision and on leaders’ thinking about whether or not the investment
will deliver value. However, regardless of the proposer’s track record, an IT proposal
should enable the leadership team to respond with a strong yes to each of the following
questions:
■ Is it clear how the plan advances the organization’s strategy?
■ Is it clear how care will improve, costs will be reduced, or service will be improved?
Are the measures of current performance and expected improvement well researched
and realistic? Have the related changes in operations, workflow, and organizational
processes been defined?
■ Are the senior leaders whose areas are the focus of the IT plan clearly supportive?
Could they give the presentation?
■ Are the resource requirements well understood and convincingly presented? Have
these requirements been compared to those experienced by other organizations
undertaking similar initiatives?
■ Have the investment risks been identified, and is there an approach to addressing
these risks?
■ Do we have the right people assigned to the project, have we freed up their time,
and are they well organized?
Answering with a no, a maybe, or an equivocal yes to any of these questions should
lead one to believe that the discussion is perhaps focusing on an expense rather than
an investment.
Steps to Improve Value Realization 429
Require Formal Project Proposals
It is a fact of organizational life that projects are approved as a result of hallway
conversations or discussions on the golf course. Organizational life is a political life.
While recognizing that reality, the organization should require that every IT project
be written up in the format of a proposal and that each proposal should be reviewed
and subjected to scrutiny before the organization will commit to supporting it. How-
ever, an organization may also decide that small projects — for example, those that
involve less than $25,000 in costs and less than 120 person-hours — can be handled more
informally.
Increase Accountability for Investment Results
Few meaningful organizational initiatives are accomplished without establishing
appropriate accountability for results. Accountability for IT investment results can be
improved by taking three major steps.
First, the business owner of the IT investment should defend the investment: for
example, the director of clinical laboratories should defend the request for a new lab-
oratory system and the director of nursing should defend the need for a new nursing
system. The IT staff will need to work with the business owner to define IT costs,
establish likely implementation time frames, and sort through application alternatives.
The IT staff should never defend an application investment.
Second, as was discussed in Chapter Fourteen, project sponsors and business owners
must be defined, and they must understand the accountability that they now have for
the successful completion of the project.
Third, the presentation of these projects should occur in a forum that routinely
reviews such requests. Seeing many proposals, and their results, over the course of
time will enable the forum participants to develop a seasoned understanding of good
versus not-so-good proposals. Forum members are also able to compare and contrast
proposals as they decide which ones should be approved. A manager might wonder
(and it’s a good question), “If I approve this proposal, does that mean that we won’t
have resources for another project that I might like even better?” Examining as many
proposals together as possible enables the organization to take a portfolio view of its
potential investments.
Figure 15.1 displays an example of a project investment portfolio represented graph-
ically. The size of each bubble reflects the magnitude of a particular IT investment. The
axes are labeled “reward” (the size of the expected value) and “risk” (the relative risk
that the project will not deliver the value). Other axes may be used. One commonly used
set of axes consists of “support of operations” and “support of strategic initiatives.”
Diagrams such as this serve several functions:
■ They summarize IT activity on one piece of paper, allowing leaders to consider a
new request in the context of prior commitments.
■ They help to ensure a balanced portfolio, promptly revealing imbalances such as a
clustering of projects in the high-risk quadrant.
430 Assessing and Achieving Value in Health Care Information Systems
FIGURE 15.1. IT Investment Portfolio
Clinical Labs
Pharmacy
Optical Storage
Care Protocols
Discharge
Summaries
CPOE
Home Care
New Storage Technology
PDAs
Risk
R
ew
ar
d
Source: Adapted from Arlotto & Oakes, 2003.
■ They help to ensure that the approved projects cover an appropriate spectrum
of organizational needs — for example, that projects are directed to revenue cycle
improvement, to operational improvement, and to patient safety.
Conduct Postimplementation Audits
Rarely do organizations revisit their IT investments to determine if the promised value
was actually achieved. They tend to believe that once the implementation is over and
the change settles in, value will have been automatically achieved. This is unlikely.
Postimplementation audits can be conducted to identify value achievement progress
and the steps still needed to achieve maximum gain. An organization might decide
to audit two to four systems each year, selecting systems that have been live for at
least six months. During the course of the audit meeting, these five questions can
be asked:
1. What goals were expected at the time the project investment was approved?
2. How close have we come to achieving those original goals?
3. What do we need to do to close the goal gap?
4. How much have we invested in system implementation, and how does that com-
pare to our original budget?
Steps to Improve Value Realization 431
5. If we had to implement this system again, what would we do differently?
Postimplementation audits assist value achievement by
■ Signaling leadership interest in ensuring the delivery of results
■ Identifying steps that still need to be taken to ensure value
■ Supporting organizational learning about IT value realization
■ Reinforcing accountability for results
Celebrate Value Achievement
Business value should be celebrated. Organizations usually hold parties shortly after
applications go live. These parties are appropriate; a lot of people worked very hard
to get the system up and running and used. However, up and running and used does
not mean that value has been delivered. In addition to go-live parties, organizations
should consider business value parties; celebrations conducted once the value has been
achieved: for example, a party that celebrates the achievement of service improvement
goals. Go-live parties alone risk sending the inappropriate signal that implementation
is the end point of the IT initiative. Value delivery is the end point.
Leverage Organizational Governance
The creation of an IT committee of the board of directors can enhance organiza-
tional efforts to achieve value from IT investments. At times the leadership team of an
organization is uncomfortable with some or all of the IT conversation. Team members
may not understand why infrastructure is so expensive or why large implementations
can take so long and cost so much. They may feel uncomfortable with the complexity
of determining the likely value to be obtained from IT investments. The creation of
a subcommittee made up of the board members most experienced with such discus-
sions can help to ensure that hard questions are being asked and that the answers are
sound.
Shorten the Deliverables Cycle
When possible, projects should have short deliverable cycles. In other words, rather
than asking the organization to wait twelve or eighteen months to see the first fruits of
its application implementation labors, make an effort to deliver a sequence of smaller
implementations. For example, one might conduct pilots of an application in a sub-
set of the organization, followed by a staged rollout. Or one might plan for serial
implementation of the first 25 percent of the application features.
Pilots, staged rollouts, and serial implementations are not always doable. Where
they are possible, however, they enable the organization to achieve some value earlier
rather than later, support organizational learning about which system capabilities are
really important and which were only thought to be important, facilitate the development
of reengineered operational processes, and create the appearance (whose importance is
not to be underestimated) of more value delivery.
432 Assessing and Achieving Value in Health Care Information Systems
Benchmark Value
Organizations should benchmark their performance in achieving value against the per-
formance of their peers. These benchmarks might focus on process performance: for
example, days in accounts receivables or average time to get an appointment. An impor-
tant aspect of value benchmarking is the identification of the critical IT application
capabilities and related operational changes that enabled the achievement of superior
results. This understanding of how other organizations achieved superior IT-enabled
performance can guide an organization’s efforts to continuously achieve as much value
as possible from its IT investments.
Communicate Value
Once a year the information technology department should develop a communication
plan for the twelve months ahead. This plan should indicate which presentations will
be made in which forums and how often IT-centric columns will appear in organi-
zational newsletters. The plan should list three or so major themes — for example,
specific regional integration strategies or efforts to improve IT service — that will be the
focus of these communications. Communication plans try to remedy the fact that even
when value is being delivered, most people in the organization may not be fully aware
of it.
WHY IT FAILS TO DELIVER RETURNS
It is not uncommon to hear leaders of health care organizations complain about the
lack of value obtained from IT investments. These leaders may see IT as a necessary
expense that must be tightly controlled rather than as an investment that can be a true
enabler. New health care managers often walk into organizations where the leadership
mind-set features this set of conclusions:
The magnitude of the organization’s IT operating and capital budgets is large. IT
operating costs may consume 3 percent of the total operating budget, and IT capital
may claim 15 to 30 percent of all capital. Although 3 percent may appear small, it
can be the difference between a negative operating margin and a positive margin. A 15
to 30 percent IT consumption of capital invariably means that funding for biomedical
equipment (which can mean new revenue) and buildings (which can help the organiza-
tion appear patient and staff friendly and can support the growth of clinical services) is
diminished. IT can be seen as taking money away from “worthwhile initiatives.”
The projected growth in IT budgets exceeds the growth in other budget categories.
Provider organizations may permit overall operating budgets to increase at a rate close to
the inflation rate (recently 3 to 4 percent). However, expenditures on IT often experience
growth rates of 10 to 15 percent. At some point an organization will note that the IT
budget growth rate may single-handedly lead to insolvency.
Regardless of the amount spent, some members of the leadership team feel that not
enough is being spent. Worthwhile proposals go unfunded every year. Infrastructure
Why IT Fails to Deliver Returns 433
replacement and upgrades seem never ending: “I thought we upgraded our network two
years ago. Are you back already?”
It is difficult to evaluate IT capital requests. At times this difficulty is a reflection of
a poorly written or fatuous proposal. However, it can be genuinely difficult to compare
a proposal directed at improving service to one directed at improving care quality to
one directed at increasing revenue to one needed to achieve some level of regulatory
compliance.
When asked to “list three instances over the last five years where IT investments
have resulted in clear and unarguable returns to the organization,” leaders may return
blank stares. However, the conversation may be difficult to stop when they are asked
to “list three major IT investment disappointments that have occurred over the last five
years.”
If the value from information technology can be significant, why does one hear
these management concerns? There are several reasons why IT investments become
simply IT expenses. The organization
■ Fails to clearly link IT investments and organizational strategy.
■ Asks the wrong question.
■ Conducts the wrong analysis.
■ Does not state its investment goals.
■ Does not manage outcomes.
■ Leaps to an inappropriate solution.
■ Mangles the project management.
■ Fails to learn from studies of IT effectiveness.
Failing to Clearly Link IT Investments and Organizational Strategy
The linkage between IT investments and the organization’s strategy was discussed in
Chapter Twelve. When strategies and investments are not aligned, the IT department,
even if it is executing well, may be working on the wrong things or trying to support
a flawed overall organizational strategy.
Linkage failures can occur because
■ The organizational strategy is no more than a slogan or a buzzword with the depth
of a bumper sticker, making any investment toward achieving it ill considered.
■ The IT department thinks it understands the strategy but it does not, resulting in
implementation of the IT version of the strategy rather than the organization’s
version.
■ The strategists (for a variety of reasons) will not engage in the IT discussion, forcing
IT leaders to be mind readers.
■ The linkage is superficial: for example, “Patient care systems can reduce nursing
labor costs but we haven’t thought through how that will happen.”
434 Assessing and Achieving Value in Health Care Information Systems
■ The IT strategy conversation is separated from the organizational strategy con-
versation, perhaps as a result of the creation of an information systems steering
committee, reducing the likelihood of alignment.
■ The organizational strategy evolves faster than IT can respond.
Asking the Wrong Question
Rarely should one ask the question, What is the ROI of a computer system? This makes
as much sense as asking, What is the ROI of a chain saw? If one wants to make a
dress, a chain saw is a waste of money. If one wants to cut down some trees, one can
begin to think about the return on a chain saw investment. One will want to compare
that investment to other investments, such as an investment in an ax. One will also
want to consider the user. If the chain saw is to be used by a ten-year-old child, the
investment might be ill advised. If the chain saw is to be used by a skilled lumberjack,
the investment might be worth it.
An organization can determine the ROI of an investment in a tool only if it knows
the task to be performed and the skill level of the participants who are to perform the
task. Moreover, a positive ROI is not an inherent property of an IT investment. The
organization has to manage a return into existence.
Hence, instead of asking, What is the ROI of a computer system? organizational
leaders should ask questions such as these:
■ What are the steps and investments, including IT steps and investments, that we
need to take or make in order to achieve our goals?
■ Which business manager owns the achievement of these goals? Does this person
have our confidence?
■ Do the cost, risk, and time frame associated with implementing this set of invest-
ments, including the IT investment, seem appropriate given our goals?
■ Have we assessed the trade-offs and opportunity costs?
■ Are we comfortable with our ability to execute?
Conducting the Wrong Analysis
There are times when determining ROI is the appropriate investment analysis technique.
If a set of investments is intended to reduce clerical staff, an ROI can be calculated.
However, there are times when an ROI calculation is clearly inappropriate. What is the
ROI of software that supports collaboration? One could calculate the ROI, but it is hard
to imagine an organization basing its investment decision on that analysis. Would an
ROI analysis have captured the strategic value of the Amazon.com system or the value
of automated teller machines? Few strategic IT investments have impacts that are fully
captured by an ROI analysis. Moreover, strategic impact is rarely fully understood until
years after implementation. Whatever ROI analysis might have been done would have
invariably been wrong.
Why IT Fails to Deliver Returns 435
As was discussed earlier, the objective of the IT investment points to the appro-
priate approach to the analysis of its return. Sometimes organizations apply financial
techniques such as internal rate of return in a manner that is overzealous and ignores
other analysis approaches. This misapplication of technique can clearly lead to highly
worthwhile initiatives being deemed unworthy of funding.
Not Stating Investment Goals
Statements about the positive contributions the investment will make to organizational
performance often accompany IT proposals. Statements about specific numerical goals
for this improvement are less common. If the investment is intended to reduce medical
errors, will it reduce errors by 50 percent or 80 percent or some other number? If it
is intended to reduce claim denials, will it reduce them to 5 percent or 2 percent, and
how much revenue will be realized as a result of this reduction?
Failure to be numerically explicit about goals can create three fundamental value
problems.
■ The organization may not know how well it performs now. If the current error rate
or denial rate is not known, it is hard to believe that the leadership has studied
the problem well enough to be fairly sure that an IT investment will achieve the
desired gains. The IT proposal sounds more like a guess about what is needed.
■ The organization may never know whether it got the desired value or not. If the
proposal does not state a goal, the organization will never know whether the 20
percent reduction in errors it has achieved is as far as it can go or whether it is only
halfway to its desired goal. It does not know whether it should continue to work
on the error problem or whether it should move on to the next performance issue.
■ It will be difficult to hold someone accountable for performance improvement when
the organization is unable to track how well he or she is doing.
Not Managing Outcomes
Related to the failure to state goals is the failure to manage outcomes into existence.
Once the project is approved and the system is up, management goes off to the next
challenge, seemingly unaware that the work of value realization has just begun.
Figure 15.2 depicts a reduction in days in accounts receivable (AR) at a Partners
HealthCare physician practice. During the interval depicted, a new practice manage-
ment system was implemented. The practice did not see a precipitous decline in days
in AR (a sign of improved revenue performance) in the time immediately following
the implementation in the second quarter of 1997. The practice did see a progressive
improvement in days in AR because someone was managing that improvement.
If the gain in revenue performance had been an “automatic” result of the information
system implementation, the practice would have seen a sharp drop in days in AR. Instead
it saw a gradual improvement over time. This gradual change reflects that
■ The gain occurred through day in, day out changes in operational processes, fine-
tuning of system capabilities, and follow-ups in staff training.
436 Assessing and Achieving Value in Health Care Information Systems
FIGURE 15.2. Days in Accounts Receivable Before and After
Implementation of Practice Management System
100.0
90.0
80.0
70.0
60.0
50.0
40.0
30.0
20.0
Qtr 3-96 Qtr 4-96 Qtr 1-97 Qtr 2-97 Qtr 3-97 Qtr 4-97 Qtr 1-98 Qtr 2-98 Qtr 3-98 Qtr 4-98
10.0
–
Days in A/R
■ A person had to be in charge of obtaining this improvement. Someone had to
identify and make operational changes, manage changes in system capabilities, and
ensure that needed training occurred.
Leaping to an Inappropriate Solution
At times the IT discussion of a new application succumbs to advanced states of technical
arousal. Project participants become overwhelmed by the prospect of using sexy new
technology and state-of-the-art gizmos and lose their senses and understanding of why
they are having this discussion in the first place. Sexiness and state-of-the-art-ness
become the criteria for making system decisions.
In addition the comparison of two alternative vendor products can turn into a fea-
tures war. The discussion may focus on the number of features as a way of distinguishing
products and fail to ask whether this numerical difference has any real impact on the
value that is desired.
Both sexiness and features have their place in the system selection decision. How-
ever, they are secondary to the discussion that centers on the capabilities needed to effect
specific performance goals. Sexiness and features may be irrelevant to the performance
improvement discussion.
Mangling the Project Management
One guaranteed way to reduce value is to mangle the management of the implementation
project. Implementation failures or significant budget and timetable overruns or really
unhappy users, any of these can dilute value.
Analyses of the IT Value Challenge 437
Among the many factors that can lead to mangled project management are these:
■ The project’s scope is poorly defined.
■ The accountability is unclear.
■ The project participants are marginally skilled.
■ The magnitude of the task is underestimated.
■ Users feel like victims rather than participants.
■ All the world has a vote and can vote at any time.
Many of these factors were discussed in Chapters Seven and Fourteen.
Failing to Learn from Studies of IT Effectiveness
Organizations may fail to invest in the IT abilities discussed in Chapter Thirteen, such
as good relationships between the IT function and the rest of the organization and a
well-architected infrastructure. This investment failure increases the likelihood that the
percentage of projects that fail to deliver value will be higher than it should be.
ANALYSES OF THE IT VALUE CHALLENGE
The IT investment and value challenge plagues all industries. It is not a problem peculiar
to health care. The challenge has been with us for forty years, ever since organizations
began to spend money on big mainframes. This challenge is complex and persistent,
and we should not believe we can fully solve it. We should believe we can be better at
dealing with it. This section highlights the conclusions of several studies and articles
that have examined this challenge.
Factors That Hinder Value Return
The Committee to Study the Impact of Information Technology on the Performance of
Service Activities (1994) found these major contributors to failures to achieve a solid
return on IT investments:
■ The organization’s overall strategy is wrong, or its assessment of its competitive
environment is inadequate.
■ The strategy is fine, but the necessary IT applications and infrastructure are not
defined appropriately. The information system, if it is solving a problem, is solving
the wrong problem.
■ The organization fails to identify and draw together well all the investments and
initiatives necessary to carry out its plans. The IT investment then falters because
other changes, such as reorganization or reengineering, fail to occur.
■ The organization fails to execute the IT plan well. Poor planning or less than stellar
management can diminish the return from any investment.
438 Assessing and Achieving Value in Health Care Information Systems
Value may also be diluted by factors outside the organization’s control. Weill and
Broadbent (1998) noted that the more strategic the IT investment, the more its value
can be diluted. An IT investment directed to increasing market share may have its
value diluted by non-IT decisions and events — for example, pricing decisions, com-
petitors’ actions, and customers’ reactions. IT investments that are less strategic but
have business value — for example, improving nursing productivity — may be diluted
by outside factors — for example, shortages of nursing staff. And the value of an IT
investment directed toward improving infrastructure characteristics may be diluted by
outside factors — for example, unanticipated technology immaturity or business diffi-
culties confronting a vendor.
The Investment-Performance Relationship
A study by Strassmann (1990) examined the relationship between IT expenditures and
organizational effectiveness. Data from an Information Week survey of the top 100
users of information technology were used to correlate IT expenditures per employee
with profits per employee. Strassmann concluded that there is no obvious direct
relationship between expenditure and organizational performance. This finding has
been observed in several other studies (for example, Keen, 1997). It leads to several
conclusions:
■ Spending more on IT is no guarantee that the organization will be better off. There
has never been a direct correlation between spending and outcomes. Paying more
for care does not give one correspondingly better care. Clearly, one can spend so
little that nothing effective can be done. And one can spend so much that waste is
guaranteed. But moving IT expenditures from 2 percent of the operating budget to
3 percent of the operating budget does not inherently lead to a 50 percent increase
in desirable outcomes.
■ Information technology is a tool, and its utility as a tool is largely determined by
the tool user and his or her task. Spending a large amount of money on a chain
saw for someone who doesn’t know how to use one is a waste. Spending more
money on tools for the casual saw user who trims an apple tree every now and
then is also a waste. However, skilled loggers might say that if a chain saw blade
were longer and the saw’s engine more powerful, they would be able to cut 10
percent more trees in a given period of time. The investment needed to enhance
the loggers’ saws might lead to superior performance. Organizational effectiveness
in applying IT has an enormous effect on the likelihood of a useful outcome from
increased IT investment.
■ Factors other than the appropriateness of the tool to the task also influence the
relationship between IT investment and organizational performance. These factors
include the nature of the work (for example, IT is likely to have a greater impact on
bank performance than on consulting firm performance), the basis of competition
in an industry (for example, cost per unit of manufactured output versus prowess in
marketing), and an organization’s relative competitive position in the market.
Analyses of the IT Value Challenge 439
The Value of the Overall Investment
Many analyses and academic studies have been directed to answering this broad ques-
tion, How can an organization assess the value of its overall investments in IT?
Assessing the value of the aggregate IT investment is different from assessing the value
of a single initiative or other specific investment. And it is also different from assessing
the caliber of the IT department. Developing a definitive, accurate, and well-accepted
way to answer this question has so far eluded all industries and may continue to be
elusive. Nonetheless there are some basic questions that can be asked in pursuit of
answering the larger question. Interpreting the answers to these basic questions is a
subjective exercise, making it difficult to derive numerical scores. Bresnahan (1998)
suggests five questions:
1. How does IT influence the customer experience?
2. Do patients and physicians, for example, find that organizational processes are
more efficient, less error prone, and more convenient?
3. Does IT enable or retard growth? Can the IT organization support effectively the
demands of a merger? Can IT support the creation of clinical product lines — for
example, cardiology — across the IDS?
4. Does IT favorably affect productivity?
5. Does IT advance organizational innovation and learning?
IT as a Commodity
Carr (2003) has equated IT with commodities — soybeans, for example. Carr’s argu-
ment is that core information technologies, such as fast, inexpensive processors and
storage, are readily available to all organizations and hence cannot provide a competi-
tive advantage. Organizations can no more achieve value from IT than an automobile
manufacturer can achieve value by buying better steel than a competitor does or a gro-
cer can achieve value by stocking better sugar than a competitor does. In this view, IT,
steel, and sugar are all commodities.
Responding to Carr’s argument, Brown and Hagel (2003) make three observations
about IT value:
1. “Extracting value from IT requires innovation in business practices.” If an organiza-
tion merely computerizes existing processes without rectifying (or at times eliminating)
process problems, it may have merely made process problems occur faster. In addition
those processes are now more expensive because there is a computer system to support.
Providing appointment scheduling systems may not make waiting times any shorter or
enhance patients’ ability to get an appointment when they need one.
All IT initiatives should be accompanied by efforts to materially improve the pro-
cesses that the system is designed to support. IT often enables the organization to think
differently about a process or expand its options for improving a process. If the process
thinking is narrow or unimaginative, the value that could have been achieved will have
been lost, with the organization settling for an expensive way to achieve minimal gain.
440 Assessing and Achieving Value in Health Care Information Systems
For example, if Amazon.com had thought that the Internet enabled it to simply replace
the catalogue and telephone as a way of ordering something, it would have missed
ideas such as presenting products to the customer based on data about prior orders or
enabling customers to leave their own ratings of books and music.
2. “IT’s economic impact comes from incremental innovations rather than from ‘big
bang’ initiatives.” Organizations will often introduce very large computer systems and
process change “all at once.” Two examples of such big bangs are the replacement
of all systems related to the revenue cycle and the introduction of a new patient care
system over the course of a few weeks.
Big bang implementations are very tricky and highly risky. They may be haunted
by series of technical problems. Moreover, these systems introduce an enormous num-
ber of process changes affecting many people. It is exceptionally difficult to understand
the ramifications of such change during the analysis and design stages that precede
implementation. A full understanding is impossible. As a result, the implementing orga-
nization risks material damage. This damage destroys value. It may set the organization
back, and even if the organization grinds its way through the disruption, the resulting
trauma may make the organization unwilling to engage in future ambitious IT initiatives.
In contrast, IT implementations (and related process changes) that are more incre-
mental and iterative reduce the risk of organizational damage and permit the organization
to learn. The organization has time to understand the value impact of phase n and then
can alter its course before it embarks upon phase n + 1. Moreover, incremental change
leads the organization’s members to understand that change, and realizing value, are a
never ending aspect of organizational life rather than something to be endured every
couple of years.
3. “The strategic impact of IT investments comes from the cumulative effect of sus-
tained initiatives to innovate business practices in the near term.” If economic value
is derived from a series of thoughtful, incremental steps, then the aggregate effect of
those steps should be a competitive advantage. Most of the time, organizations that
wind up dominating an industry do so through incremental movement over the course
of several years (Collins, 2001). This observation is consistent with our view in Chapter
Twelve. Persistent innovation by a talented team, over the course of years, will result
in significant strategic gains. The organization has learned how to improve itself, year
in and year out. Strategic value is a marathon. It is a long race that is run and won one
mile at a time.
SUMMARY
IT value is complex, multifaceted, and
diverse across and within proposed ini-
tiatives. The techniques used to analyze
value must vary with the nature of the
value.
The project proposal is the core
means for assessing the potential value
of a potential IT initiative. IT propos-
als have a commonly accepted struc-
ture. And approaches exist for com-
paring proposals with different types
of value propositions. Project propos-
als often present problems in the way
they estimate value — for example, they
Analyses of the IT Value Challenge 441
may unrealistically combine fractions of
effort saved, fail to appreciate the com-
plex behavior of system users, or under-
estimate the full costs of the project.
Many factors can dilute the value
realized from an IT investment. Poor
linkage between the IT agenda and the
organizational strategy, the failure to set
goals, and the failure to manage the real-
ization of value all contribute to dilution.
There are steps that can be taken
to improve the achievement of IT value.
Leadership can ensure that project pro-
ponents have done their homework, that
accountability for results has been estab-
lished, that formal proposals are used,
and that postimplementation audits are
conducted. Even though there are many
approaches and factors that can enhance
the realization of IT-enabled value, the
challenges of achieving this value will
remain a management issue for the fore-
seeable future.
Health care organization leaders often
feel ill equipped to address the IT
investment and value challenge. How-
ever, no new management techniques are
required to evaluate IT plans, propos-
als, and progress. Leadership teams are
often asked to make decisions that involve
strategic hunches (such as a belief that
developing a continuum of care would
be of value) about areas where they may
have limited domain knowledge (new sur-
gical modalities) and where the value is
fuzzy (improved morale). Organizational
leaders should treat IT investments just
as they would treat other types of invest-
ments; if they don’t understand, believe,
or trust the proposal, or its proponent,
they shouldn’t approve it.
KEY TERMS
Failure to deliver returns
IT project proposals
IT value
Value realization
LEARNING ACTIVITIES
1. Interview the CIO of a local health care provider or payer. Discuss how his or
her organization assesses the value of IT investments and ensures that the value
is delivered.
2. Select two articles from a health care IT trade journal that describe the value an
organization received from its IT investments. Critique and compare the articles.
3. Select two examples of intangible value. Propose one or more approaches that an
organization might use to measure each of those values.
4. Prepare a defense of the value of a significant investment in an electronic medical
record system.
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
