UOP Strategic Plan Paper

Strategic Plan

Prior to beginning work on this assignment, read Chapters 12 through  14 from the Wager, Lee, & Glaser (2017) text, read the articles by  Kahn (2015) and by Laihonen (2015), and watch the video Dave deBronkart: Meet E-Patient Dave

Links to an external site. (2011).

You will select a Strategic Organizational Goal from the following  list that you will use to develop a strategic plan for your proposed  health information system:

Research and education

Patient Care: Quality improvement

Patient Care: Sharing data across the system

Patient Care: Non-acute services

Financial stability

Before beginning to develop your strategic goal, it is important to  understand your objectives. In other words, as you choose your Strategic  Goal, keep in mind the overall impact you want this goal to have on  your department or the organization as a whole. As an example, if you  chose Patient Care: Sharing Data Across the System, you can start by  thinking about the expeditiousness of information from the pharmacy back  to the care team, and how such interface may impact patient outcome. A  good acronym to use to sort through your thought process is PICOT  (Population/Problem, Intervention, Comparison, Outcome, and Time); the  PICOT approach is spelled out below:

Population/Patient problem – Who is it that you are trying to provide service for?

Intervention – What is it you are trying to do? Or, what are you fixing?

Comparison – Is there a possible alternative to this system? Or, why did I choose this system?

Outcome – What is the goal here?

Time – How long will this plan take to be implemented?

The plan for your chosen Strategic Organizational Goal should

Outline one problem an organization faces related to your selected Strategic Organizational Goal.

Chapter 12
IT Alignment and Strategic Planning
Learning Objectives
To be able to understand the importance of an IT strategic plan.
To review the components of the IT strategic plan.
To be able to understand the processes for developing an IT strategy.
To be able to discuss the challenges of developing an IT strategy.
To describe the Gartner Hype Cycle recognizing the wide range of emerging technologies at
various stages of maturity.
Information technology (IT) investments serve to advance organizational performance. These
investments should enable the organization to reduce costs, improve service, enhance the
quality of care, and, in general, achieve its strategic objectives. The goal of IT alignment and
strategic planning is to ensure a strong and clear relationship between IT investment decisions
and the health care organization’s overall strategies, goals, and objectives. For example, an
organization’s decision to invest in a new claims adjudication system should be the clear result
of a goal of improving the effectiveness of its claims processing process. An organization’s
decision to implement a care coordination application should be a consequence of its
population health management strategy.
Developing a sound alignment can be very important for one simple reason—if you define the
IT agenda incorrectly or even partially correctly, you run the risk that significant organizational
resources will be misdirected; the resources will not be put to furthering strategically important
areas. This risk has nothing to do with how well you execute the IT direction you choose. Being
on time, on budget, and on specification is of little value to the organization if it is doing the
wrong thing!
IT Planning Objectives
The IT strategic planning process has several objectives:
To ensure that information technology plans and activities align with the plans and activities
of the organization; in other words, the IT needs of each aspect of organizational strategy are
clear, and the portfolio of IT plans and activities can be mapped to organizational strategies and
operational needs
To ensure that the alignment is comprehensive; in other words, each aspect of strategy has
been addressed from an IT perspective that recognizes not all aspects of strategy have an IT
component, and not all components will be funded
To identify non-IT organizational initiatives needed to ensure maximum leverage of the IT
initiative (for example, process reengineering)
To ensure that the organization has not missed a strategic IT opportunity, such as those that
might result from new technologies
To develop a tactical plan that details approved project descriptions, timetables, budgets,
staffing plans, and plan risk factors
To create a communication tool that can inform the organization of the IT initiatives that will
and will not be undertaken
To establish a political process that helps ensure the plan results have sufficient
organizational support
At the end of the alignment and strategic-planning process, an organization should have an
outline that at a high level resembles Table 12.1. With this outline, leadership can see the IT
investments needed to advance each of the organization’s strategies. For example, the goal of
improving the quality of patient care may lead the organization to invest in databases to
measure and report quality, predictive algorithms to identify patients at risk of readmission,
and the EHR.
Table 12.1 IT initiatives linked to organizational goals
Goal IT Initiatives
Research and education
Research patient data registry
Genetics and genomics platform
Grants management
Patient care: quality improvement Quality measurement databases
Order entry
Electronic health record
Patient care: sharing data across the system
Enterprise master person index
Clinical data repository
Common infrastructure
Patient care: non-acute services
Nursing documentation
Transition of care
Financial stability
Revenue system enhancements
Payroll-personnel system
Cost accounting
Overview of Strategy
Strategy is the determination of the basic long-term goals and objectives of an organization, the
adoption of the course of action, and the allocation of resources necessary to carry out those
actions (Chandler, 1962). Strategy seeks to answer questions such as, where does this
organization need to go, and how will it get there? Where should the organization focus its
management attention and expenditures?
The development of an organization’s strategy has two major components: formulation and
implementation (Henderson & Venkatraman, 1993).
Formulation
Formulation involves making decisions about the mission and goals of the organization and the
activities and initiatives it will undertake to achieve them. Formulation could involve
determining the following:
Our mission is to provide high-quality medical care.
We have a goal of reducing the cost of care while at least preserving the quality of that care.
One of our greatest leverage points lies in reducing inappropriate and unnecessary care.
To achieve this goal, we will emphasize reducing the number of inappropriate radiology
procedures.
We will carry out initiatives that enable us to intervene at the time of procedure ordering if
we need to suggest a more cost-effective modality.
We can imagine other goals directed toward achieving this mission. For each goal, we can
envision multiple leverage points, and for each leverage point, we may see multiple initiatives.
The result is an inverted tree that cascades from our mission to a series of initiatives.
Formulation involves understanding competing ideas and choosing between them. In our
example, we could have arrived at a different set of goals and initiatives.
We could have decided to improve quality with less emphasis on care costs. We could have
decided to focus on reducing the cost per procedure. We could have decided to produce
retrospective reports of radiology use by provider and used this feedback to lead to ordering
behavior change rather than intervening at the time of ordering.
In IT, we also have a need for formulation. In keeping with an IT mission to use the technology
to support improvement of the quality of care, we may have a goal to integrate our clinical
application systems. To achieve this goal, we may decide to follow any of the following
initiatives:
Provide a common way to access all systems (single sign-on).
Interface existing heterogeneous systems.
Require that all applications use a common database.
Implement a common suite of clinical applications from one vendor.
Implementation
Implementation involves making decisions about how we structure ourselves, acquire skills,
establish organizational capabilities, and alter organizational processes to achieve the goals and
carry out the activities we have defined during formulation of our strategy. For example, if we
have decided to reduce care costs by reducing inappropriate procedure use, we may need to
implement one or more of the following:
An organizational unit of providers with health services research training to analyze care
practices and identify deficiencies
A steering committee of clinical leadership to guide these efforts and provide political
support
A provider order entry system to provide real-time feedback on order appropriateness
Data warehouse technologies to support analyses of utilization
Using our clinical applications integration example, we may come to one of the following
determinations:
We need to acquire interface engine technology, adopt HL7 standards, and form an
information systems department that manages the technology and interfaces applications.
We need to engage external consulting assistance for the selection of a clinical application
suite and hire a group to implement the suite.
The implementation component of strategy development is not the development of project
plans and budgets. Rather, it is the identification of the capabilities, capacities, and
competencies the organization will need if it is to carry out the results of the formulation
component of strategy.
Vectors for Arriving at IT Strategy
The IT strategy is developed using some combination of four IT strategy vectors:
Organizational strategies
Continuous improvement of core processes and information management
Examination of the role of new information technologies
Assessment of strategic trajectories
By a vector we mean the choice of perspectives and approaches through which an organization
determines its IT investment decisions. For example, the first vector (derived from organization
strategies) involves answering a question such as, “Given our strategy of improving patient
safety, what IT applications will we need?” However, the third vector (determined by examining
the role of new information technologies) involves answering a question such as, “There is a
great deal of discussion about cloud-based applications. Does this approach to delivering
applications provide us with ways to be more effective at addressing some of our organization
challenges?” Figure 12.1 illustrates the convergence Overview of Strategy
Strategy is the determination of the basic long-term goals and objectives of an organization, the
adoption of the course of action, and the allocation of resources necessary to carry out those
actions (Chandler, 1962). Strategy seeks to answer questions such as, where does this
organization need to go, and how will it get there? Where should the organization focus its
management attention and expenditures?
The development of an organization’s strategy has two major components: formulation and
implementation (Henderson & Venkatraman, 1993).
Formulation
Formulation involves making decisions about the mission and goals of the organization and the
activities and initiatives it will undertake to achieve them. Formulation could involve
determining the following:
Our mission is to provide high-quality medical care.
We have a goal of reducing the cost of care while at least preserving the quality of that care.
One of our greatest leverage points lies in reducing inappropriate and unnecessary care.
To achieve this goal, we will emphasize reducing the number of inappropriate radiology
procedures.
We will carry out initiatives that enable us to intervene at the time of procedure ordering if
we need to suggest a more cost-effective modality.
We can imagine other goals directed toward achieving this mission. For each goal, we can
envision multiple leverage points, and for each leverage point, we may see multiple initiatives.
The result is an inverted tree that cascades from our mission to a series of initiatives.
Formulation involves understanding competing ideas and choosing between them. In our
example, we could have arrived at a different set of goals and initiatives.
We could have decided to improve quality with less emphasis on care costs. We could have
decided to focus on reducing the cost per procedure. We could have decided to produce
retrospective reports of radiology use by provider and used this feedback to lead to ordering
behavior change rather than intervening at the time of ordering.
In IT, we also have a need for formulation. In keeping with an IT mission to use the technology
to support improvement of the quality of care, we may have a goal to integrate our clinical
application systems. To achieve this goal, we may decide to follow any of the following
initiatives:
Provide a common way to access all systems (single sign-on).
Interface existing heterogeneous systems.
Require that all applications use a common database.
Implement a common suite of clinical applications from one vendor.
Implementation
Implementation involves making decisions about how we structure ourselves, acquire skills,
establish organizational capabilities, and alter organizational processes to achieve the goals and
carry out the activities we have defined during formulation of our strategy. For example, if we
have decided to reduce care costs by reducing inappropriate procedure use, we may need to
implement one or more of the following:
An organizational unit of providers with health services research training to analyze care
practices and identify deficiencies
A steering committee of clinical leadership to guide these efforts and provide political
support
A provider order entry system to provide real-time feedback on order appropriateness
Data warehouse technologies to support analyses of utilization
Using our clinical applications integration example, we may come to one of the following
determinations:
We need to acquire interface engine technology, adopt HL7 standards, and form an
information systems department that manages the technology and interfaces applications.
We need to engage external consulting assistance for the selection of a clinical application
suite and hire a group to implement the suite.
The implementation component of strategy development is not the development of project
plans and budgets. Rather, it is the identification of the capabilities, capacities, and
competencies the organization will need if it is to carry out the results of the formulation
component of strategy.
Vectors for Arriving at IT Strategy
The IT strategy is developed using some combination of four IT strategy vectors:
Organizational strategies
Continuous improvement of core processes and information management
Examination of the role of new information technologies
Assessment of strategic trajectories
By a vector we mean the choice of perspectives and approaches through which an organization
determines its IT investment decisions. For example, the first vector (derived from organization
strategies) involves answering a question such as, “Given our strategy of improving patient
safety, what IT applications will we need?” However, the third vector (determined by examining
the role of new information technologies) involves answering a question such as, “There is a
great deal of discussion about cloud-based applications. Does this approach to delivering
applications provide us with ways to be more effective at addressing some of our organization
challenges?” Figure 12.1 illustrates the convergence of these vectors into a series of iterative
leadership discussions and debates. These debates lead to an IT agenda.
Figure depicting the overview of IT strategy development, where the convergence of four
vectors (derived from organizational strategies, improvement of core process and information
needs, new information technologies, strategic trajectory) into a series of iterative leadership
discussions and debates.
T Strategies Derived from Organizational Strategies
The first vector involves deriving the IT agenda directly from the organization’s goals and plans.
For example, an organization may decide it intends to become the low-cost provider of care. It
may decide to achieve this goal through implementation of disease management programs, the
reengineering of inpatient care, and the reduction of unit costs for certain tests and procedures
it believes are inordinately expensive.
The IT strategy development then centers on answering questions such as, “How do we apply IT
to support disease management?” The answers might involve web-based publication of disease
management protocols for use by providers, business intelligence technology to assess the
conformance of care practice to the protocols, provider documentation systems based on
disease guidelines, and CPOE systems that employ the disease guidelines to influence ordering
decisions. An organization may choose all or some of these responses and develop various
sequences of implementation. Nonetheless, it has developed an answer to the question of how
to apply IT in support of disease management.
Most of the time the linkage between organizational strategy and IT strategy involves
developing the IT ramifications of organizational initiatives, such as adding or changing services
and products, growing market share, improving service, streamlining processes, or reducing
costs. At times, however, an organization may decide it needs to change or add to its core
characteristics or culture. The organization may decide it needs its staff members to be more
care-quality or service-delivery or bottom-line oriented. It may decide it needs to decentralize
or recentralize decision making. It may decide to improve its ability to manage knowledge, or it
may not. These characteristics (and there are many others) can point to initiatives for IT.
In cases in which characteristics are to be changed, IT strategies must be developed to answer
questions such as, “What is our basic IT approach to supporting a decentralized decisionmaking structure?” The organization might answer this question by permitting decentralized
choices of applications as long as those applications meet certain standards. (For example, they
may run on a common infrastructure or support common data standards.) It might answer the
question of how IT supports an emphasis on knowledge management by developing an intranet
service that provides access to preferred treatment guidelines.
IT Strategies to Continuously Improve Core Processes and Information Management
All organizations have a small number of core processes and information management tasks
that are essential for the effective and efficient functioningof the organization. For a hospital
these processes might include ensuring patient access to care, ordering tests and procedures,
and managing the revenue cycle. For a restaurant these processes might include menu design,
food preparation, and dining room service. For a health plan, information management needs
might point to a requirement to understand the costs of care or the degree to which care
practices vary by physician.
Using the vector of continuous improvement of core processes and information management
to determine IT strategies involves defining the organization’s core processes and information
management needs. The organization measures the performance of core processes and uses
the resulting data to develop plans to improve its performance. The organization defines core
information needs, identifies the gap between the current status and its needs, and develops
plans to close those gaps. These plans will often point to an IT agenda. This vector may be a
result of a strategy discussion, although this is not always the case. An organization may make
ongoing efforts to improve processes regardless of the specifics of its strategic plan. For
example, every year it may establish initiatives designed to reduce costs or improve services.
The organization has decided that, regardless of a specific strategy, it will not thrive if core
processes and information management are something other than excellent.
Table 12.2 illustrates a process orientation. It provides an organization with data on the
magnitude of some problems that plague the delivery of outpatient care. These problems afflict
the processes of referral, results management, and test ordering. The organization may decide
to make IT investments in an effort to reduce or eliminate these problems. For example,
strengthening the decision support for e-prescribing could reduce the prevalence of adverse
drug events (ADEs). Abnormal test results could be highlighted in the EHR to help ensure
patient follow-up.
T Strategies That Rely on New IT Capabilities
The third vector involves considering how new IT capabilities may enable a new IT agenda or
significantly alter the current agenda. For example, telemedicine capabilities may enable the
organization to consider a strategy of extending the reach of its specialists across its catchment
area to improve its population health efforts. Data-mining algorithm advances might enable an
organization to assess different treatment approaches to determine which approaches lead to
the best outcomes.
In this vector, the organization examines new applications and new base technologies and tries
to answer the question, “Does this application or technology enable us to advance our
strategies or improve our core processes in new ways?” For example, advances in sensors and
mobile applications might lead the organization to think of new approaches to providing
feedback to the chronically ill patient. Holding new technologies up to the spotlight of
organizational interest can lead to decisions to invest in a new technology.
An extreme form of this mechanism occurs when a new technology or application suggests that
fundamental strategies (or even the organization’s existence) may be called into question or
may need to undergo significant transformation. In general these strategies lead to a decision
to adopt a new business model. A business model is the combination of an organization’s
decisions about what it will do, how it will do it, and why “the what and how” are of such value
that customers will pay them.
For example, Uber’s business model is that it will get you from point A to point B (the what) but
it will do so in a way that involves “renting” capacity from drivers already on the road and
making the process of ordering a ride and paying for a ride very easy (the how). The what for
Uber is no different than that for a traditional taxi company but the how is very different.
Uber’s superior business model was made possible by new information technologies—the web,
mobile devices, and advanced analytics.
IT Strategies Based on Assessment of Strategic Trajectories
Organization and IT strategies invariably have a fixed time horizon and fixed scope. These
strategies might cover a period of time two to three years into the future. They outline a
bounded set of initiatives to be undertaken in that time period. Assessment of strategic
trajectories asks the questions, What do we think we will be doing after that time horizon and
scope? Do we think we will be doing very different kinds of things, or will we be carrying out
initiatives similar to the ones we are pursuing now?
For example, we might be planning to implement a broad portfolio of health care information
technology. The organization believes that through medical advances and preventive care the
number of patients older than one hundred will increase dramatically. The strategic trajectory
discussion asks, “Does this increase in longevity have significant implications for the types of
health care that we deliver and hence on the types of information technology that we
implement?”
Or we might be in the process of using IT to support joint clinical programs with other hospitals
in the area. These efforts would be greatly helped by the availability of broad interoperability.
However, such pervasive interoperability has proved elusive and may be elusive for a decade.
How would pervasive interoperability affect our IT strategy?
The strategic trajectory discussion can be highly speculative. It might be so forward looking and
speculative that the organization decides not to act today on its discussion. Yet it can also point
to initiatives to be undertaken within the next year to better understand this possible future
and to prepare the organization’s information systems for it. For example, if we believe our
information systems will eventually need to store large amounts of genetic information, it
would be worth understanding whether the new population health systems we will be selecting
soon will be capable of storing and analyzing these data.
The IT Assest
The discussion of vectors and alignment up to this point has focused generally on the
development of an application agenda as the outcome. In other words, the completion of the IT
strategy discussion is an inventory of systems, such as the EHR system, customer relationship
management system, and an enterprise data warehouse, that are needed to further overall
organizational strategies. However, the application inventory is a component of the larger idea
of the IT asset. These areas are discussed in the following sections.
The IT asset is composed of those IT resources that the organization has or can obtain and that
are applied to further the goals, plans, and initiatives of the organization. The IT strategy
discussion identifies specific changes or enhancements to the composition of the asset—for
example, the implementation of a new application—and general properties of the asset that
must exist—for example, high reliability of the infrastructure. The IT asset has four
components: applications, infrastructure, data, and IT staff members.
Applications
Applications are the systems that users interact with: for example, scheduling, billing, and EHR
systems. In addition to developing an inventory of applications, the organization may need to
develop strategies regarding properties of the overall portfolio of applications.
For example, if the organization is an integrated delivery system, decisions will need to be made
about the degree to which applications should be the same across the organization. E-mail
systems ought to be the same, but is there a strategic reason to have the same pharmacy
system across all hospitals? Should an organization buy or build its applications? Building
applications is risky and often requires skills that most health care organizations do not possess.
However, internally developed applications can be less expensive and can be tailored to an
organization’s needs.
Strategic thinking may center on the form and rigor of the justification process for new
applications. Formal return on investment analyses may be emphasized so that all application
decisions will emphasize cost reduction or revenue gain. Or the organization may decide to
have a decision process that takes a more holistic approach to acquisition decisions, so that
factors such as improving quality of care must also be considered.
In general, strategy discussions surrounding the application asset as a whole focus on, in
addition to the application inventory, a few key areas:
Sourcing. What are the sources for our applications? And what criteria determine the source
to be used for an application? Should we get all applications from the same vendor or will we
use a small number of approved vendors?
Application uniformity. For large organizations with many subsidiaries or locations, to what
degree should our applications be the same at all locations? If some have to be the same but
some can be different, how do we decide where we allow autonomy? This discussion often
involves a trade-off between local autonomy and the central desire for efficiency and
consistency.
Application acquisition. What processes and steps should we use when we acquire
applications? Should we subject all acquisitions to rigorous analyses? Should we use a request
for proposal for all application acquisitions? This discussion is generally an assessment of the
extent to which the IT acquisition process should follow the degree of rigor applied to non-IT
acquisitions (of diagnostic equipment, for example).
Infrastructure
Infrastructure needs may arise from the strategic-planning process. An organization desiring to
extend its IT systems to community physicians will need to ensure that it can deliver low-cost
and secure network connections. Organizations placing significant emphasis on clinical
information systems must ensure very high reliability of their infrastructure; computerized
provider order entry systems cannot go down.
In addition to initiatives designed to add specific components to the infrastructure—for
example, new software to monitor network utilization—architecture strategies will focus on the
addition or enhancement of broad infrastructure capabilities and characteristics.
Capabilities are defined by completing this sentence: “We want our applications to be able to
…” Organizations might complete that sentence with phrases such as “be accessed from home,”
“have logic that guides clinical decision making,” or “share a pool of consistently defined data.”
Characteristics refer to broad properties of the infrastructure, such as reliability, security,
agility, supportability, integratability, and potency. An organization may be heading into the
implementation of mission-critical systems and hence must ensure very high degrees of
reliability in its applications and infrastructure. The organization may be concerned about the
threats posed by ransomware and denial of service attacks and decide to strengthen the
security of its infrastructure. The asset plans in these cases involve discussions and analyses
that are intended to answer the question, What steps do we need to take to significantly
improve the reliability of our systems or improve security?
Data
Data and information were discussed in Chapter Two. Strategies concerning data may center on
the degree of data standardization across the organization, accountability for data quality and
stewardship, data sources, and determination of database management and analyses
technologies.
Data strategy conversations may originate with questions such as, We need to better
understand the costs of our care. How do we improve the linkage between our clinical data and
our financial data? Or, we have to develop a much quicker response to outbreaks of epidemics.
How do we link into the city’s emergency rooms and quickly get data on chief complaints?
In general, strategies surrounding data focus on acquiring new types of data, defining the
meaning of data, determining the organizational function responsible for maintaining that
meaning, integrating existing sets of data, and obtaining technologies used to manage, analyze,
and report data.
IT Staff Members
IT staff members are the analysts, programmers, and computer operators who, day in and day
out, manage and advance information systems in an organization. IT staff members were
discussed in Chapter Eight. IT strategy discussions may highlight the need to add IT staff
members with specific skills, such as mobile application developers and population health
implementation staff members. Organizations may decide that they need to explore
outsourcing the IT function in an effort to improve IT performance or obtain difficult-to-find
skills. The service orientation of the IT group may need to be improved.
In general, the IT staff member strategies focus on the acquisition of new skills, the organization
of the IT staff, the sourcing of the IT staff, and the characteristics of the IT department—is it, for
example, innovative, service oriented, and efficient?
A Normative Approach to Developing Alignment and IT Strategy
You may now be asking yourself, how do I bring all of this together? In other words, is there a
suggested approach an organization can take to develop its IT strategy that takes into account
these various vectors? And by the way, what does an IT strategic plan look like?
Across health care organizations the approaches taken to developing, documenting, and
managing an IT strategy are quite varied. Some organizations have well-developed, formal
approaches that rely on the deliberations of multiple committees and leadership retreats.
Other organizations have remarkably informal processes. A small number of medical staff
members and administrative leaders meet in informal conversations to define the
organization’s IT strategy. In some cases the strategy is developed during a specific time in the
year, often preceding development of the annual budget. In other organizations, IT strategic
planning goes on all the time and permeates a wide range of formal and informal discussions.
There is no single right way to develop an IT strategy and to ensure alignment. However, the
process of developing IT strategy should be similar in approach and nature to the process used
for overall strategic planning. If the organization’s core approach to strategy development is
informal, its approach to IT strategy development should also be informal.
Recognizing this variability, a normative approach to the development of IT strategy can be
described.
Strategy Discussion Linkage
Organizational strategy is generally discussed in senior leadership meetings. These meetings
may focus specifically on strategy, or strategy may be a regular agenda item. These meetings
may be supplemented with retreats centered on strategy development and with task forces
and committees that are asked to develop recommendations for specific aspects of the
strategy. (For example, a committee of clinical leadership members might be asked to develop
recommendations for improving patient safety.) These discussions will examine the
organization’s external environment—such as changes in reimbursement and competitive
position—and internal environment—such as operational efficiency, financial health, and
clinical strengths. This examination invariably results in the identification of gaps between the
organization’s desired position and role and its current status. This examination usually includes
a review of the status and capabilities of the organization’s IT capabilities and application
portfolio.
Regardless of their form, the organization’s CIO should be present at such meetings or kept
informed of the discussion and its conclusions. If task forces and committees supplement
strategy development, an IT manager should be asked to be a member. The CIO (or the IT
member of a task force) should be expected to develop an assessment of the IT ramifications of
strategic options and to identify areas where IT can enable new approaches to carrying out the
strategy.
The CIO will not be the only member of the leadership team who will perform this role. Chief
financial officers (CFOs), for example, will frequently identify the IT ramifications of plans to
improve the revenue cycle. However, the CIO should be held accountable for ensuring the
linkage does occur.
As strategy discussions proceed, the CIO must be able to summarize and critique the IT agenda
that should be put in place to carry out the various aspects of the strategy. Exhibit 12.1 displays
an IT agenda that might emerge. Exhibit 12.2 displays a health plan IT agenda that could result
from a strategy designed to improve patient access to health information and self-service
administrative tasks for a health plan.
IT Liaisons
All major departments and functions (for example, finance, nursing, and medical staff
administration) should have a senior IT staff person who serves as the function’s point of
contact. Because these functions examine ways to address their needs (for example, lower their
costs and improve their services), the IT staff person can work with them to identify IT activities
necessary to carry out their endeavors. This identification often emerges with
recommendations to implement new applications that advance the performance of a function,
such as a medication administration record application to improve the nursing workflow.
Exhibit 12.3 provides an example of output from a nursing leadership discussion on improving
patient safety through the use of a nursing documentation system.
New Technology Review
The CIO should be asked to discuss, as part of the strategy discussion or in a periodic
presentation in senior leadership forums, new technologies and their possible contributions to
the goals and plans of the organization. These presentations may lead to suggestions that the
organization form a task force to closely examine a new technology. For example, a
multidisciplinary task force could be formed to examine the ability of telehealth to support the
organization’s strategies. Table 12.3 provides an overview of different types of telehealth and
an overall assessment of strategic importance.
The organization should expect the process of synthesis will require debate and discussion; for
example, trade-offs will need to be reviewed, priorities set, and the organization’s willingness
to implement embryonic technologies determined. This synthesis and prioritization process can
occur during the course of leadership meetings, through the work of a committee charged to
develop an initial set of recommendations, and during discussions internal to the IT
management team.
An example of an approach to prioritizing recommendations is to give each member of the
committee $100 to be distributed across the recommendations. The amount a member gives to
each recommendation reflects his or her sense of its importance. For example, a member could
give one recommendation $90 and another $10 or give five recommendations $20 each. In the
former case, the committee member believes that only two recommendations are important
and that the first recommendation is nine times more important than the second. In the latter
case, the member believes that five recommendations are of equal importance. The distributed
dollars are summed across the members, with a ranking of recommendations emerging.
The leadership should not feel compelled to accept the ranking as a definitive output. Rather,
the process of scoring will reveal that members of the leadership team will rate
recommendations differently. For example, some members will rate a project as having a high
contribution to patient quality and others will view that contribution as low. The discussion that
investigates these discrepancies can help the team understand the recommendation more fully
and lead to a consensus that strengthens political support for the recommendation. Moreover,
if the leadership team decides to approve a recommendation with a low score, it should ask
itself why it views the recommendation as more important than the score would suggest.
For an example of the scoring of proposed IT initiatives, see Figure 12.2. It lists categories of
organizational goals (for example, enhance patient care), along with goals within the categories.
The leadership of the organization, through a series of meetings and presentations, has scored
the contribution of the IT initiative to the strategic goals of the organization. The contribution
to each goal may be critical (must do), high, moderate, or none. These scores are based on data
but nonetheless are fundamentally judgment calls. The scoring and prioritization will result in a
set of initiatives deemed to be the most important. The IT staff members will then construct
preliminary budgets, staff needs, and timelines for these projects.
Figure 12.3 provides an overview of the timeline for these initiatives and the cost of each.
Management will discuss various timeline scenarios, consider project interdependence, and
ensure that the IT department and the IT department and the organization are not
overwhelmed by too many initiatives to complete all at once. The organization will use the
budget estimates to determine how much IT it can afford. Often there is not enough money to
pay for all the desired IT initiatives, and some initiatives with high and moderate scores will be
deferred or eliminated as projects. The final plan, including timelines and budgets, will become
the basis for assessing progress throughout the year.
T plan timetable and budget
Note: Annual recurring is the ongoing operating cost of the system
On the right of the figure, the approximate project timeline can be seen. The numbers below
the timeline (0.5 and 1) indicate the number of IT staff members needed to implement the
project.
Overall, a core role of the organization’s CIO is to work with the rest of the leadership team to
develop the process that leads to alignment and strategic linkage.
Once all is said and done, the alignment process should produce these results:
An inventory of the IT initiatives that will be undertaken (These initiatives may include new
applications and projects designed to improve the IT asset.)
A diagram or chart that illustrates the linkage between the initiatives and the organization’s
strategy and goals
An overview of the timeline and the major interdependencies between initiatives
A high-level analysis of the budget needed to carry out these initiatives
An assessment of any material risks to carrying out the IT agenda and a review of the
strategies needed to reduce those risks
It is important to recognize the amount and level of discussion, compromise, and negotiation
that go into the strategic alignment process. Producing these results without going through the
preceding thoughtful process will be of little real benefit.
IT Strategy and Alignment Challenges
Creating IT strategy and alignment is a complicated and critical organizational process. The
following sections present a series of observations about that process.
Planning Methodologies
Formal processes and methodologies that help organizations develop IT plans, whether based
on derived linkage or the examination of more fundamental characteristics of organizations,
can be very helpful. If well executed, they can do all of the following:
Lead to the identification of a portfolio of IT applications and initiatives that are well linked to
the organization’s strategy.
Identify alternatives and approaches that might not have been understood without the
process.
Contribute to a more thorough analysis of the major aspects of the plan.
Enhance and ensure necessary leadership participation and support.
Help the organization be more decisive.
Ensure the allocation of resources among competing alternatives is rational and politically
defensible.
Enhance communication of the developed plan.
In addition to formal IT strategic planning methodologies, organizations will often use strategy
frameworks that help them frame issues and opportunities. For example, Porter’s Competitive
Forces Model (Porter, 1980) identifies strategic options such as competing on cost,
differentiating based on quality, and attempting to raise barriers to the entry of other
competitors. By using this model, the organization will make choices about its overall
competitive position.
Models such as these help the leadership engage in a broader and more conceptual approach
to strategy development.
Persistence of the Alignment Problem
Despite the apparent simplicity of the normative process we have described and the many
examinations of the topic by academics and consultants, achieving IT alignment has been a top
concern of senior organizational leadership for several decades. For example, a survey of CIOs
from across multiple industries found improving IT alignment with business objectives to be the
number one IT top management priority in 2007 (Alter, 2007). A survey of CIOs in 2015
(Information Management, 2016) found alignment to be, once again, the top concern. There
are several reasons for the persistent difficulty of achieving alignment (Bensaou & Earl, 1998):
Business strategies are often not clear or are volatile.
IT opportunities are poorly understood and new technologies emerge constantly.
The organization is unable to resolve the different priorities of different parts of the
organization.
Weill and Broadbent (1998) note that effective IT alignment requires organizational leadership
to clearly understand and strategically and tactically integrate (1) the organization’s strategic
context (its strategies and market position), (2) the organization’s environment, (3) the IT
strategy, and (4) the IT portfolio (for example, the current applications, technologies, and staff
skills). Understanding and integrating these four continuously evolving and complex areas is
exceptionally difficult.
Persistence of the Alignment Problem
Despite the apparent simplicity of the normative process we have described and the many
examinations of the topic by academics and consultants, achieving IT alignment has been a top
concern of senior organizational leadership for several decades. For example, a survey of CIOs
from across multiple industries found improving IT alignment with business objectives to be the
number one IT top management priority in 2007 (Alter, 2007). A survey of CIOs in 2015
(Information Management, 2016) found alignment to be, once again, the top concern. There
are several reasons for the persistent difficulty of achieving alignment (Bensaou & Earl, 1998):
Business strategies are often not clear or are volatile.
IT opportunities are poorly understood and new technologies emerge constantly.
The organization is unable to resolve the different priorities of different parts of the
organization.
Weill and Broadbent (1998) note that effective IT alignment requires organizational leadership
to clearly understand and strategically and tactically integrate (1) the organization’s strategic
context (its strategies and market position), (2) the organization’s environment, (3) the IT
strategy, and (4) the IT portfolio (for example, the current applications, technologies, and staff
skills). Understanding and integrating these four continuously evolving and complex areas is
exceptionally difficult.
At least two more reasons can be added to this listing of factors that make alignment difficult.
First, the organization may find it has not achieved the gains apparently achieved by others it
has heard or read about, nor have the vendors’ promises of the technologies materialized.
Second, the value of IT, particularly infrastructure, is often difficult to quantify, and the value
proposition is fuzzy and uncertain; for example, what is the value of improved security of
applications?
In both these cases the organization is unsure whether the IT investment will lead to the
desired strategic gain or value. This is not strictly an alignment problem. However, alignment
does assume the organization believes it has a reasonable ability to achieve desired IT gains.
The Limitations of Alignment
Although alignment is important, it will not guarantee effective application of IT. Planning
methodologies and effective use of vectors cannot, by themselves, overcome weaknesses in
other factors that can significantly diminish the likelihood that IT investments will lead to
improved organization performance. These weaknesses include poor relationships between IT
staff members and the rest of the organization, incompetent leadership, weak financial
conditions, and ill-conceived IT governance mechanisms. IT strategy also cannot overcome
unclear overall strategies and cannot necessarily compensate for material competitive
weaknesses.
If one has mediocre painting skills, a class on painting technique will make one a better painter
but will not turn one into Picasso. Similarly, superb alignment techniques will not turn an
organization limited in its ability to implement IT effectively into one brilliant at IT use. Perhaps
this reason, more than any other, is why the alignment issue persists as a top-ranked IT issue.
Organizations are searching for IT excellence in the wrong place; it cannot be delivered purely
by alignment prowess.
Alignment at Maturity
Organizations that have a history of IT excellence appear to evolve to a state in which their
alignment process has become deeply intertwined with the normal management strategy and
operations discussions. A study by Earl (1993) of organizations in the United Kingdom with a
history of IT excellence found that their IT planning processes had several characteristics.
IT Planning Was Not a Separate Process
IT planning and the strategic discussion of IT occurred as an integral part of the organization’s
strategic planning processes and management discussions.
In these organizations, management did not think of separating out an IT discussion during the
course of strategy development any more than it would run separate finance or human
resource planning processes. IT planning was an unseverable, intertwined component of the
usual management conversation. This would suggest not having a separate IT steering
committee.
IT Planning Had Neither a Beginning nor an End
In many organizations, IT planning processes start in a particular month every year and are
completed within a more or less set period. In the studied organizations, the IT planning and
strategy conversation went on all the time. This does not mean that an organization doesn’t
have to have a temporally demarked, annual budget process. Rather, it means that IT planning
is a continuous process that reflects the continuous change in the environment.
IT Planning Involved Shared Decision Making and Shared Learning
IT leadership informed organizational leadership of the potential contribution of new
technologies and the constraints of current technologies. Organizational leadership ensured
that IT leadership understood the business plans, strategies, and their constraints. The IT
budget and annual tactical plan resulted from shared analyses of IT opportunities and a set of IT
priorities.
The IT Plan Emphasized Themes
A provider organization may have themes of improving care quality, reducing costs, and
improving patient service. During the course of any given year, IT will have initiatives that are
intended to advance the organization along these themes. The mixture of initiatives will change
from year to year, but the themes endure for many years. Because themes endure year after
year, organizations develop competence in these themes. They become, for example,
progressively better at managing costs and improving patient service. This growing prowess
extends into IT. Organizations become more skilled at understanding which IT opportunities
hold the most promise and at managing implementation of these applications. And the IT staff
members become more skilled at knowing how to apply IT to support such themes as
improving care quality and at helping leadership assess the value of new technologies and
applications.
Chapter 13
IT Governance and Management
Learning Objectives
To be able to understand the scope and importance of IT governance.
To review the IT roles and responsibilities of users, the IT department, and senior
management.
To be able to discuss the components of an IT budget and the processes for developing the
budget.
To review the factors that enable sustained excellence in the application of IT.
To understand how IT can contribute to an organization’s IT competitiveness.
In this chapter we discuss an eclectic but important set of information technology (IT)
management processes, structures, and issues. Developing, managing, and evolving IT
management mechanisms is often a central topic for organizational leadership. In this chapter
we will cover the following areas:
IT governance. IT governance is composed of the processes, reporting relationships, roles,
and committees that an organization develops to make decisions about IT resources and
activities and to manage the execution of those decisions. These decisions involve issues such
as setting priorities, determining budgets, defining project management approaches, and
addressing IT problems.
IT budget. Developing the IT budget is a complex exercise. Organizations always have more IT
proposals than can be funded. Some proposals are strategically important and others involve
routine maintenance of existing infrastructure, making proposal comparison difficult. Although
complex and difficult, the effective development of the IT budget is a critical management
responsibility.
Management role in major IT initiatives. Senior management has an extremely important role
in ensuring that major IT initiatives succeed and result in desired organizational performance
gains. In other chapters of this book, management process for system selection,
implementation, and value realization were discussed. In this section we discuss risk factors
facing major initiatives and steps management can take to mitigate those risks.
IT effectiveness. Over the years several organizations have demonstrated exceptional
effectiveness in applying IT: American Express, Bank of America, Uber, Amazon, Schwab, and
American Airlines. This chapter discusses what the management of these organizations did that
led to such effectiveness. It also examines the attributes of IT-savvy senior leadership.
IT to improve an organization’s competitive position. IT is often used as a means to improve
an organization’s ability to compete. In this section we will discuss lessons learned from other
industries from their efforts to use IT as a competitive asset.
IT Governance
IT governance refers to the principles, processes, and organizational structures that govern the
IT resources (Drazen & Straisor, 1995). When solid governance exists, the organization is able to
give a coherent answer to the following questions:
Which committees and processes are used to define the IT strategy?
Who sets priorities for IT, and how are those priorities set?
Who is responsible for implementing information system plans, and what principles will guide
the implementation process?
How are IT responsibilities distributed between IT and the rest of the organization and
between centralized and decentralized (local) IT groups in an integrated delivery system?
How are IT budgets developed?
At its core, governance involves the following functions:
Determining the distribution of the responsibility for making decisions, the scope of the
decisions that can be made by different organizational functions, and the processes to be used
for making decisions
Defining the roles that various organizational members and committees fulfill for IT—for
example, which committee should monitor progress in an EHR implementation and what is the
role of a department head during the implementation of a new system for his or her
department?
Developing IT-centric organizational processes for making decisions in key areas such as
these:
img IT strategy development
img IT prioritization and budgeting
img IT project management
img IT architecture and infrastructure management
Defining policies and procedures that govern the use of IT—for example, if a user wants to
buy a new network for use in his or her department, what policies and procedures govern that
decision?
Developing and maintaining an effective and efficient IT governance structure is a complex
exercise. Moreover, governance is never static. Continuous refinements may be needed as the
organization discovers imperfections in roles, responsibilities, and processes.
Governance Characteristics
Well-developed governance mechanisms have several characteristics.
They are perceived as objective and fair. No organizational decision-making mechanisms are
free from politics, and some decisions will be made as part of side deals. It is exceptionally rare
for all managers of an organization to agree with any particular decision. Nonetheless,
organizational participants should generally view governance as fair, objective, well-reasoned,
and having integrity. The ability of governance to govern is highly dependent on the willingness
of organizational participants to be governed.
They are efficient and timely. Governance mechanisms should arrive at decisions quickly, and
governance processes should be efficient, removing as much bureaucracy as possible.
They make authority clear. Committees and individuals who have decision authority should
have a clear understanding of the scope of their authority. Individuals who have IT roles should
understand those roles. The organization’s management must have a consistent understanding
of its approach to IT governance. There always will be occasions when decision rights are
murky, roles are confusing, or processes are unnecessarily complex, but these occasions should
be few.
They can change as the organization, its environment, and its understanding of technology
changes. For example, efforts to implement regional interoperability between EHRs will require
new governance mechanisms that bring representatives from the partnering organizations
together to deal with inter-organizational IT issues such as the allowable uses of shared data.
Governance mechanisms evolve as IT technology and the organization’s use of that technology
evolve.
IT, User, and Senior Management Responsibilities
Effective application of IT involves the thoughtful distribution of IT responsibilities among the IT
department, users of applications and IT services, and senior management. In general, these
responsibilities address decision-making rights and roles. Although different organizations will
arrive at different distributions of these responsibilities, and an organization’s distribution may
change over time, there is a fairly normative distribution (Applegate, Austin, & McFarlan, 2007).
IT Department Responsibilities
The IT department should be responsible for the following:
Developing and managing the long-term architectural plan and ensuring that IT projects
conform to that plan.
Developing a process to establish, maintain, and evolve IT standards in several areas:
img Telecommunications protocols and platforms
img Client devices, such as workstations and mobile devices, and client software
configurations
img Server technologies, middleware, and database management systems
img Programming languages
img IT documentation procedures, formats, and revision policies
img Data definitions (this responsibility is generally shared with the organization function,
such as finance and health information management, that manages the integrity and meaning
of the data)
img IT disaster and recovery plans
img IT security policies and incident response procedures
Developing procedures that enable the assessment of sourcing options for new initiatives,
such as building versus buying new applications or leveraging existing vendor partner offerings
versus utilizing a new vendor when making an application purchase
Maintaining an inventory of installed and planned systems and services and developing plans
for the maintenance of systems or the planned obsolescence of applications and platforms
Managing the professional growth and development of the IT staff [members]
Establishing communication mechanisms that help the organization understand the IT
agenda, challenges, and services and new opportunities to apply IT
Maintaining effective relationships with preferred IT suppliers of products and services
(Applegate, Austin, & McFarlan, 2007, p. 429)1
The scope and depth of these responsibilities may vary. Some of the responsibilities of the IT
group may be delegated to others. For example, some non-IT departments may be permitted to
have their own IT staff members and manage their own systems. This should be done only with
the approval of senior management. And the IT department should be asked to provide
oversight of the departmental IT group to ensure that professional standards are maintained
and that no activities that comprise the organization’s systems are undertaken. For example,
the IT department can ensure that virus control procedures and software are effectively
applied.
In general, the IT department is responsible for making sure that individual and organizational
information systems are reliable, secure, efficient, current, and supportable. IT is also usually
responsible for managing the relationship with suppliers of IT products and services and
ensuring that the processes that lead to new IT purchases are rigorous.
User Responsibilities
IT users (primarily middle managers and supervisors) have several IT-related user
responsibilities:
Understanding the scope and quality of IT activities that are supporting their area or function
Ensuring that the goals of IT initiatives reflect an accurate assessment of the function’s needs
and challenges and that the estimates of the function’s resources (personnel time, funds, and
management attention) needed by IT initiatives—to support the implementation of a new
system, for example—are realistic
Developing and reviewing specifications for IT projects and ensuring that ongoing feedback is
provided to the IT organization on implementation issues, application enhancements, and IT
support, ensuring, for example, that the new application has the functionality needed by the
user department
Ensuring that the applications used by a department are functioning properly, such as by
periodically testing the accuracy of system-generated reports and checking that passwords are
deleted when staff [members] leave the organization
Participating in developing and maintaining the IT agenda and priorities (Applegate, Austin, &
McFarlan, 2007, p. 431)2
These responsibilities constitute a minimal set. In Chapters Six and Seven, we discussed an
additional, and more significant, set of responsibilities during the selection and implementation
of new applications.
Senior Management Responsibilities
The primary IT senior management responsibilities are as follows:
Ensuring that the organization has a comprehensive, thoughtful, and flexible IT strategy
Ensuring an appropriate balance between the perspectives and agendas of the IT
organization and the users—for example, the IT organization may want a new application that
has the most advanced technology, [and] the user department wants the application that has
been used in the industry for a long time
Establishing standard processes for budgeting, acquiring, implementing, and supporting IT
applications and infrastructure
Ensuring that IT purchases and supplier relationships conform to organizational policies and
practices—for example, contracts with IT vendors need to use standard organizational contract
language
Developing, modifying, and enforcing the responsibilities and roles of the IT organization and
users
Ensuring that the IT applications and activities conform to all relevant regulations and
required management controls and risk mitigation processes and procedures
Encouraging the thoughtful review of new IT opportunities and appropriate IT
experimentation (Applegate, Austin, & McFarlan, 2007, p. 432)3
Although organizations will vary in the ways they distribute decision-making responsibility and
roles and the ways in which they implement them, problems may arise when the distribution
between groups is markedly skewed (Applegate, Austin, & McFarlan, 2007).
Too much user responsibility can lead to a series of uncoordinated and undermanaged user
investments in information technology. This can result in these problems:
An inability to achieve integration between highly heterogeneous systems
Insufficient attention to infrastructure, resulting in application instability
High IT costs because of insufficient economies of scale, significant levels of redundant
activity, and the cost of supporting a high number of heterogeneous systems
A lack of, or uneven, rigor applied to the assessment of the value of IT initiatives—for
example, insufficient homework may be done and an application selected that has serious
functional limitations
Too much IT responsibility can lead to these problems:
Too much emphasis on technology, to the detriment of the fit of an application with the user
function’s need: for example, when a promising application does not completely satisfy the IT
department’s technical standards, IT will not allow its acquisition
Senior Leadership Organizational Forum
Most health care organizations have a committee called something similar to the executive
committee. Composed of the senior leadership of the organization, this committee is the forum
in which strategy discussions occur and major decisions regarding operations, budgets, and
initiatives are made. It is highly desirable to have the CIO be a member of this committee.
Major IT decisions should be made at the meetings of this committee. These decisions will
cover a gamut of topics, such as approving the outcome of a major system selection process,
defining changes in direction that may be needed during the course of significant
implementations, setting IT budget targets, and ratifying the IT component of the strategicplanning efforts.
This role does not preclude the executive committee from assigning IT-related tasks or
discussions to other committees. For example, a medical staff leadership committee may be
asked to develop policies regarding physician documentation of the problem list. A committee
of department heads may be asked to select a new application to support registration and
scheduling. A committee of human resource staff members may be charged with developing
policies regarding organizational staff member use of social media sites.
The executive committee, major departments and functions, and several high-level committees
will regularly be confronted with IT topics and issues that do not arise from the organization’s IT
plan and agenda. For example, a board member may ask if the organization should outsource
its IT function. Several influential physicians may suggest that the organization assess a new
information technology that seems to be getting a lot of hype. The CEO may ask how the
organization should (or whether it should) respond to an external event: for example, a new
Institute of Medicine report. The organization may need to address new regulations: for
example, rules being issued by CMS.
Some organizations create an IT steering committee and charge this committee with addressing
all IT issues and decisions. The use of such committees is uneven in health care organizations.
Approximately half have such a committee.
IT Liaison Relationships
All major functions and departments of the organization—for example, finance, human
resources, member services, medical staff affairs, and nursing—should have an IT liaison. The IT
liaison is responsible for the following:
Developing effective working relationships with the leadership of each major function
Ensuring that the IT issues and needs of these functions are understood and communicated
to the IT department and the executive committee
Working with function leadership to ensure appropriate IT representation on function task
forces and committees that are addressing initiatives that will require IT support
Ensuring that the organization’s IT strategy, plans and policies, and procedures are discussed
with function leadership
The IT liaison role is an invaluable one. It ensures that the IT department and the IT strategy
receive needed feedback and that function leaders understand the directions and challenges of
the IT agenda. It also promotes an effective collaboration between IT and the other functions
and departments.
Variations
The specific governance structures just described are typical in medium-sized and large
provider or payer organizations. In other types of health care settings, these structures will be
different.
A medium-sized physician group might not have a separate board. The physicians and the
practice manager might make up the board and the senior leadership forum. The group might
not need a CIO. Instead the practice administrator might manage contracts and relationships
with companies that provide practice management systems and support workstations and
printers. The practice administrator also might perform all user liaison functions.
Perspective
Improving Coordination and Working Relationships
Carol Brown and Vallabh Sambamurthy have identified five mechanisms used by IT
asic Budget Categories
To facilitate the development of the IT budget, the organization should develop some basic
categories that organize the budget discussion.
Capital and Operating
The first category distinguishes between capital and operating budgets. Financial management
courses are the best place to learn about these two categories. In brief, however, capital
budgets are the funds associated with purchasing and deploying an asset. Common capital
items in IT budgets are hardware and applications. Operating budgets are the funds associated
with using and maintaining the asset. Common operating items in IT budgets are hardware
maintenance contracts and the salaries of IT analysts. In an analogous fashion, the purchase of
a car is a capital expense. Gasoline and tune-ups are operating expenses. Both capital and
operating budgets are prepared for IT initiatives.
Support, Ongoing, and New IT
Support refers to those IT costs (staff members, hardware, and software licenses) necessary to
support and maintain the applications and infrastructure that are in place now. Software
maintenance contracts ensure that applications receive appropriate upgrades and bug fixes.
Staff members are needed to run the computer room and perform minor enhancements. Disk
drives may need to be replaced. Failure to fund support activities can make it much more
difficult to ensure the reliability of systems or to evolve applications to accommodate ongoing
needs—for example, adding a new test to the dictionary for a laboratory system or introducing
a new plan type into the patient accounting system.
Ongoing projects are those application implementations begun in a prior year and still under
way. The implementation of a patient accounting system or a care coordination application can
take several years. Hence a capital and operating budget is needed for several years to continue
the implementation.
New projects are just that—there is a proposal for a new application or infrastructure
application. The IT strategy may call for new systems to support nursing. Concerns over
network security may lead to requests for new software to deter the efforts of hackers.
Improve Current Operations or Strategic Plan
Proposals may be directed to improving current operations, perhaps by responding to new
regulations or streamlining the workflow in a department. Proposals may also be explicitly
linked to an aspect of the health care organization’s strategic plan—they might call for
applications to support a strategic emphasis on disease management, for example.
Budget Targets
During the budget process, organizations define targets for the budget overall and for its
components. For example, the organization might state that it would like to keep the overall
growth in its operating budget to 2 percent but is willing to allow 5 percent growth in the IT
operating budget. The organization might also direct that within that overall 5 percent growth,
the budget for support should not grow by more than 3 percent, but the budget for new
projects and ongoing projects combined can grow by 11 percent. Table 13.1 illustrates the
application of overall and selective operating budget targets.
Table 13.1 Target increases in an IT operating budget
Support Operations Strategic Initiatives Overall Target
Ongoing and new
9%
15% 11%
Support
3%
3%
3%
OVERALL TARGET
4%
7%
5%
Similarly, targets can be set for the capital budget. For example, perhaps it will be decided that
the capital budget for support should remain flat but that given the decision to invest in an EHR
system, the overall capital budget will increase to accommodate the capital required by the EHR
investment.
IT Budget Development
In addition to formulating the categories just described, organizational leadership will need to
develop the process through which the IT budget is discussed, prioritized, and approved. In
other words, it must answer the governance question, what processes will we use to decide
which projects will be approved subject to our targets? An example of a budget process is
outlined in this section and illustrated in Figure 13.1.
Figure 13.1 IT budget decision-making process
This process example has five components.
First, the IT department submits an operating budget to support the applications and
infrastructure that will be in place as of the beginning of the fiscal year (the support budget).
This budget might be targeted to a 3 percent increase over the support budget for the prior
fiscal year. The 3 percent increase reflects inflation, salary increases, a recognition that new
systems were implemented during the fiscal year and will require support, and an
acknowledgment that infrastructure (workstations, remote locations, and storage)
consumption will increase. A figure for capital to support applications and infrastructure is also
submitted, and it might be targeted to be the same as that budgeted in the prior fiscal year. If
the support operating and capital budgets achieve their targets, there is minimal management
discussion of those budgets.
Second, IT leadership reviews the strategic IT initiatives (new and ongoing) with the senior
leadership of the organization. This review may occur in a forum such as the executive
committee. This committee, mindful of its targets, determines which strategic initiatives will be
funded. If the budget being sought to support strategic IT initiatives is large or a major increase
over the previous year, there may be discussions about the budget with the board.
Third, the organization must decide which new and ongoing initiatives that improve current
operations—for example, a new clinical laboratory or contract management system—will be
funded. These discussions must occur in the forum where the overall operations budget is
discussed, generally organizational meetings that routinely discuss operations and that include
among their members the managers of major departments and functions. Budget requests for
new IT applications are reviewed in the same conversation that discusses budget requests for
new clinical services or improvement of the organization’s physical plant.
Fourth, the IT strategy budget discussion and the IT operations budget discussion follow a set of
ground rules:
The IT budget is discussed in the same conversations that discuss non-IT budget requests.
This will result in trade-offs between IT expenditures and other expenditures. This integration
forces the organization to examine where it believes its monies are best spent, asking, for
example, Should we invest in this IT proposal or should we invest in hiring staff members to
expand a clinical service? Following this process also means that IT requests and other budget
requests are treated no differently.
The level of analytical rigor required of the IT projects is the same as that required of any
other requested budget item.
When appropriate, a sponsor—for example, a clinical vice president or a CFO—defends the IT
requests that support his or her department in front of his or her colleagues. The IT staff
members or CIO should be asked to defend infrastructure investments—for example, major
changes to the network—but should not be asked to defend applications.
The ground rule that sponsors should present their own IT requests deserves a bit more
discussion, because the issue of who defends the request has several important ramifications,
particularly for initiatives designed to improve current operations. Having this ground rule has
the following results:
It forces assessment of trade-offs between IT and non-IT investments. The sponsor will
determine whether to present the IT proposal or some other, perhaps non-IT, proposal.
Sponsors are choosing which investments are the most important to them.
It forces accountability for investment results. The sponsor and his or her colleagues know
that if the IT proposal is approved, there will be less money available for other initiatives. The
defender also knows that the value being promised must be delivered or his or her credibility in
next year’s budget discussion will be diminished.
It improves management comfort when dealing with IT proposals. Managers can be more
comfortable with the IT proposal if one of their operations colleagues is defending it. The
defender also learns how to be comfortable when presenting IT proposals.
It gets IT out of the role of defending other people’s operation improvement initiatives.
However, the IT function must still support the budget requests of others by providing data on
the costs and capabilities of the proposed applications and the time frames and resources
required to implement them. If the IT function believes that the proposed initiative lacks merit
or is too risky, IT staff members need to ensure that this opinion is heard during the budget
approval process.
In the fifth and final step of the process, the operations and strategic budget recommendations
are reviewed and discussed at an executive committee meeting. The executive committee can
accept the recommendations, request further refinement (perhaps cuts) of the budget, or
determine that a discussion of the budget is required at an upcoming board meeting.
Management Role in Major IT Initiatives
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 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 implementation 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.
It is rare that leaders plan to fail. And yet they often do things or don’t do things that increase
the likelihood that a major initiative will fail. At times they don’t appreciate the myriad ways
that projects can go south and hence they fail to take steps to mitigate those risk factors. In the
sections that follow we discuss factors that imperil implementations, factors that can be
managed.
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 EHR in an effort to “improve the quality and
efficiency of care.” However, it is not really clear to the leadership and staff members 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 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
members may believe these changes leave them less skilled 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.
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 proponents 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 integrated 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 be admonished, 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.
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 in 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
“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 three hundred people
will struggle with a project that costs $20 million and takes one hundred person-years of effort
(Cash, McFarlan, & McKenney, 1992).
Failure to Respect Uncertainty
Significant organizational change brings a great deal of uncertainty with it. The leadership 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.
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 members other than the best people on the initiative. If the initiative is
very important, then it merits using the best people possible and freeing up their time so they
can focus on the initiative. An organization’s best staff members 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 members know how to make
them work. When processes are changed, there is a shakeout period as staff members 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 receivable 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 members need to know that their problems are being heard and that their ideas for
fixing these problems are being acted on. 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.
Although working hard to minimize the duration and depth of disruption, the organization also
needs to be tolerant during this period and to appreciate the low-grade form of hell that staff
members 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 members may conclude that the change is not working and
abandon their support.
Lack of Technology Stability and Maturity
Information technology may be obviously immature. New technologies are being introduced 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 social networking 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 technology will suffer from
performance problems, and the organization’s IT staff members and the technology supplier
may have a limited ability to identify and resolve technology problems. Organizational
members, tired of the instability, become tired of the project and it fails.
In general, it is not common, nor should it often be 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.
Projects can also get into trouble when the amount of technology change is extensive. For
example, the organization may be attempting to implement, over a short period of time,
applications from several different vendors that involve different operating systems, network
requirements, security models, and database management systems. This broad scope can
overwhelm the IT department’s ability to respond to technology misbehavior.
How to Avoid These Mistakes
Major IT projects fail in many ways. However, a large number of these failures can be mitigated
by management attention to risk factors. Few management teams and senior leaders start IT
projects hoping that failure is the outcome. Summarizing our discussion in this section produces
a set of recommendations that can help organizations reduce the risk of IT initiative failure:
Ensure that the objectives of the IT initiative are clear.
Communicate the objectives and the initiative, and test the degree to which organizational
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.
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
The Technology and the Technical Infrastructure Both Enable and Hinder
New technologies can provide new opportunities for organizations to embark on major
transformations of their activities. We have seen this in retail and music distribution. This
implies that the health care CIO must have not only superior business and clinical
understanding but also superior understanding of the technology. This does not imply that CIOs
must be able to rewrite operating systems as well as the best system programmers, but it does
mean that they must have superior understanding of the maturity, capabilities, and possible
evolution of various information technologies. Several innovations have occurred because an IT
group was able to identify and adopt an emerging technology that could make a significant
contribution to addressing a current organizational challenge. The studies also stress the
importance of well-developed technical architecture. Great architecture matters. Possessing
state-of-the-art technology can be far less important than having a well-architected
infrastructure.
The Organization Must Encourage Innovation
The organization’s (and the IT department’s) culture and leadership must encourage innovation
and experimentation. This encouragement needs to be practical and goal directed: a real
business problem, crisis, or opportunity must exist, and the project must have budgets, political
protection, and deliverables.
True Innovation Takes Time
Creating visionary applications, making major organizational changes, or establishing an
exceptional IT asset takes time and a lot of work. In the organizations studied it often took five
to seven years for the innovation to fully mature and for the organization to recast itself.
Innovation will proceed through phases that are as normative as the passage from being a child
to being an adult. Innovation, similar to the maturation of a human being, will see some
variations in timing, depth, and success in moving through phases.
Evaluation of IT Opportunities Must Be Thoughtful
Visionary and even more pedestrian IT innovations should be analyzed and studied thoroughly.
Nonetheless, organizations engaged in launching a major IT initiative should also understand
that a large amount of vision, management instinct, and “feel” often guides the decision to
initiate investment and continue investment. For example, what is the strategic and clinical
value of an integrated EHR across the continuum? The organization that has had more
experiences with IT, and more successful experiences, will be more effective in the evaluation
(and execution) of IT initiatives.
Processes, Data, and Business Model Change Form the Basis of an IT Innovation
All the strategic initiatives studied were launched from management’s fundamental
understanding of current organizational limitations. Strategic initiatives should focus on the
core elements to be discussed following in this chapter as the basis for achieving an IT-based
advantage: significant leveraging of processes, expanding and capitalizing on the ability to
gather critical data, and enabling new business models. Often an organization can pursue all
three simultaneously.
Alignment Must Be Mature and Strong
The alignment between the IT activities and the business challenges or opportunities must be
strong. It should also be mature in the sense that it depends on close working relationships
rather than methodologies.
The IT Asset Is Critical
Strong IT staff members, well-crafted architecture, and a superb CIO are critical contributors to
success. There is substantial overlap between the factors identified in these studies and the
components of the IT asset.
An overall critical factor in organizations being effective in using IT is the skills and orientation
of senior leadership. Earl and Feeney (2000) assessed the characteristics and behaviors of
senior leaders (in this case CEOs) who were actively engaged and successful in the strategic use
of IT. These leaders were convinced that IT could and would change the organization. They
placed the IT discussion high on the strategic agenda. They looked to IT to identify
opportunities to make significant improvements in organizational performance, rather than
viewing the IT agenda as secondary to strategy development. They devoted personal time to
understanding how their industry and their organization would evolve as IT evolved. And they
encouraged other members of the leadership team to do the same.
Perspective
Principles for Higher Performance
Earl and Feeney (2000) observed five management behaviors in these leaders:
They studied, rather than avoided, IT. They devoted time to learning about new technologies
and, through discussion and introspection, developed an understanding of the ways in which
new technologies might alter organizational strategies and operations.
They incorporated IT into their vision of the future of the organization and discussed the role
of IT when communicating that vision.
They actively engaged in IT architecture discussions and high-level decisions. They took time
to evaluate major new IT proposals and their implications. They were visibly supportive of
architecture standards. They established funds for the exploration of promising new
technologies.
They made sure that IT was closely linked to core management processes:
img They integrated the IT d…