HUMAN RESOURCES IN HEALTH CARE2
mz2ood
health_care_information_systems_2e_ch14.pdf
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 associated with IT initiatives.
■ 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 Initiatives
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 the 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 that 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 organization 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 fit.
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 care 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 through 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 communicate 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
In 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
la n
T
e s
t/ tr
a in
G
o l
iv 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
in 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
ro 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.
