Week 3 Lesson IT SHARED SERVICES IT SHARED SERVICES – OVERVIEW According to Accenture (2005), shared services is the consolidation of support functions from several departments into a standalone organizational entity whose only mission is to provide services as efficiently and effectively as possible. So, what is IT Share services? IT shared service is a strategy in which non-core functions (e.g., tasks, or projects) commonly performed by various units in an organizations are given to a department within an organization to be efficiently executed, providing cost saving, and customer satisfaction value. IT core functions might include network management/maintenance, desktop management, software management, change management, IT capital planning, user training, help desk/incident management, disaster recovery, and a plethora of other services we sometimes take for granted (Roit, 2009). In short a centralized model for IT shared service must have some autonomy to strategize and maximize resources utilization, bringing value to the corporation. A shared service model is always centralized; it runs as an independent business unit with their own budget and bottom-line accountabilities to the parent organization; it has a customer-centric mind-set, and its job is to provide high-quality, cost effective and timely service. A shared service could compete for internal or external services. It is called in-sourcing when services are requested from internal users and out-sourcing when requested from external uses. The goal of this section is to provide the student with insight and understanding on how to successfully establish an IT shared service. IT SHARED SERVICES - PROS AND CONS Some of the Pros and Cons from the parent organization's standpoint are presented in the table below: PROs from an Organization's Standpoint  PROs from an IT Shared Service Unit's Standpoint · Standardization - Uniformity of Services · Service improvements and cost reductions · Functions are focus to the "core competencies" of the shared-service unit · It has the potential to become a profit center (if organizations decides to offer these services externally) · Professionalism - due to customer centric model · Increased efficiencies - due to standardization · Increased control - due to centralization · Decreased personnel requirements - due to centralization of operations · Improved economies of scale - due to concentration of purchasing power, HR, and other specialized functions · Personnel development targeted toward service management  CONs to the Implementation of an IT Shared Service · Becoming a disruption of operations flow. · Instilling an "us vs. them" subculture mentality, deteriorating the provider-customer (i.e., internal user) relationship. · Moving work to a centralized location (creating time, or resources, waste or duplication) · Lengthening the time it takes to deliver a service · Additional cost associated with management bureaucracy and overhead · Extra ...

1. Week 3 Lesson
IT SHARED SERVICES
IT SHARED SERVICES – OVERVIEW
According to Accenture (2005), shared services is the
consolidation of support functions from several departments
into a standalone organizational entity whose only mission is to
provide services as efficiently and effectively as possible.
So, what is IT Share services?
IT shared service is a strategy in which non-core functions (e.g.,
tasks, or projects) commonly performed by various units in an
organizations are given to a department within an organization
to be efficiently executed, providing cost saving, and customer
satisfaction value.
IT core functions might include network
management/maintenance, desktop management, software
management, change management, IT capital planning, user
training, help desk/incident management, disaster recovery, and
a plethora of other services we sometimes take for granted
(Roit, 2009).
In short a centralized model for IT shared service must have
some autonomy to strategize and maximize resources
utilization, bringing value to the corporation. A shared service
model is always centralized; it runs as an independent business
unit with their own budget and bottom-line accountabilities to
the parent organization; it has a customer-centric mind-set, and
its job is to provide high-quality, cost effective and timely
service. A shared service could compete for internal or external
services. It is called in-sourcing when services are requested
from internal users and out-sourcing when requested from
external uses.
The goal of this section is to provide the student with insight
and understanding on how to successfully establish an IT shared
service.
IT SHARED SERVICES - PROS AND CONS

2. Some of the Pros and Cons from the parent organization's
standpoint are presented in the table below:
PROs from an Organization's Standpoint
PROs from an IT Shared Service Unit's Standpoint
· Standardization - Uniformity of Services
· Service improvements and cost reductions
· Functions are focus to the "core competencies" of the shared-
service unit
· It has the potential to become a profit center (if organizations
decides to offer these services externally)
· Professionalism - due to customer centric model
· Increased efficiencies - due to standardization
· Increased control - due to centralization
· Decreased personnel requirements - due to centralization of
operations
· Improved economies of scale - due to concentration of
purchasing power, HR, and other specialized functions
· Personnel development targeted toward service management
CONs to the Implementation of an IT Shared Service
· Becoming a disruption of operations flow.
· Instilling an "us vs. them" subculture mentality, deteriorating
the provider-customer (i.e., internal user) relationship.
· Moving work to a centralized location (creating time, or
resources, waste or duplication)
· Lengthening the time it takes to deliver a service
· Additional cost associated with management bureaucracy and
overhead
· Extraordinary start-up cost (Expensive to initially implement a
newly centralized shared service unit.
· Loss of control from other business unit
If IT shared service is successfully implemented, service
improvements should be realized in processes, quality, time,

3. customer satisfaction, and cost savings.
IT SHARED SERVICES – ORGANIZATIONAL SUCCESS
FACTORS
In order to define success, one should first understand the goals
and objectives of the initiative and how these align to the
organization's strategy. For an IT shared service endeavor to be
successful, its technical function must be thoughtfully
integrated and aligned to the organization's business aspect
A needed service with not incremental intrinsic value beyond
costs savings should be outsource, while services that provide
an edge to the organization's business should be considered as
candidates for shared service. For example, a company wanting
to retain critical knowledge and skills, as well as control, within
the organization will opt for creating a shared service unit
rather than outsourcing the services, or projects.
AN INTEGRADED MODEL OF IT SHARED SERVICES.
Our textbook presents in figure 7.1 an IT Shared Service
Conceptual Model, where a common business function/service,
such as "e-forms," is leveraged by multiple business units or
departments. The model suggests that IT shared services is best
viewed as an "interconnected layers of [business] services" that
are built on top of operational processes, and common IT
infrastructure, each providing unique services to support the end
user; this conceptual model is presented in the block schematic
below.
In short the End User Layer depends on the Operational Support
Layer, and the IT Infrastructure Support Layer and effective
coordination is critical for the successful implementation of
shared services. The model also suggests that if one of the
components in the supporting layers fails, then the IT shared
service would have failed.RECOMMENDED STRATEGIES
FOR THE CREATION OF AN IT SHARED SERVICES
ORGANIZATION
1. Create a transparent process for goal alignment. Right at the

4. outset of the shared services, articulation of explicit goals that
are aligned to the organization's strategies and are accepted by
both the business and IT units are critical to move forward.
"Without goal clarity, transparency, and alignment the shared
service organization will champion one set of goals over
another (i.e., IT goals over business' goals, or vice versa),
creating animosity between the parent organization and the
shared service provider"
2. Develop a comprehensive investment model. The investment
for the establishment of an IT shared service is substantial and
requires sophistication, understanding, and commitment from
the business.
IT shared service common cost includes a start up cost and
ongoing operational cost. In order to measure the cost savings
and benefits that an IT shared service has brought to the
company, it will be critical to establish baselines for the
existing services. Its effective implementation depends on the
size of the organization and its successful implementation might
take a year for small companies with two locations, and up to 5
years for major international organizations with dozens of
locations.
According to Bergeron(2003) "Shared services model is a viable
option when the savings from reduction in staffing are greater
than the overhead of creating a management structure to run the
shared business unit"
3. Redraft the relationship. To guarantee that the client's
satisfaction remains being a primary goal for an IT shared
service unit, customer-centric training should be provided to all
IT shared service personnel particularly during the early the
early stages of its implementation. This need to be conveyed to
the parent organization and all management levels to gain
support and commitment with this endeavor.
4. Make people an integral part of the process. The
implementation of any shared service organizational unit or
department will require many changes across the business, such
as centralization of services and personnel, technology redesign,

5. displacement of personnel, sourcing redesign, changes in
process, new measuring metrics and key performance indicators
(KPIs), training, and perhaps more importantly a cultural
change.
A transformation of this magnitude will have a resistance-
pushback from personnel at all levels; and to implement it
successfully, it will require an organizational change
management approach to ensure the new changes are
understood, embraced, and finally adopted.A MANAGEMENT
FRAMEWORK FOR IT SOURCING
In the last few years the list of functions for which IT is
accountable has grown enormously and could include:
Operations management, systems development, network
management, business transformation, regulatory compliance,
enterprise and security architecture management, information
and content management, mobile and social computing, business
intelligence and analysis, risk management, innovation, demand
management (Smith and McKeen, 2012)
The increasing demand in responsibilities will require
understanding of the various IT functions stage of development
and maturity to determine which activities/functions can be
performed in-house, or outsourced.
MATURITY MODEL FOR IT FUNCTIONS
There is a general agreement that the maturity model for IT
functions has five evolutionary stages: unique, common,
standardized, commoditized, and utility.
The evolutionary logic is straightforward and it's presented
next:
· Successful, unique functions are copied by other organizations
and become common IT functions.
· Common IT functions soon become standardized.
· A "must have" Standardized IT function is a Commodity
· Commodity functions evolve to the Utility IT function stage
when delivered by a centralized/consolidated source.

6. IT FUNCTIONS' MATURITY MODEL: STAGES OF
DEVELOPMENT
1. Unique. An unique IT function provides strategic, and/or
proprietary, advantages and benefits to the organization; hence,
it is commonly performed in house but it could also be
outsource to companies with the expertise not available in
house, for example: business analysis, application Integration,
or knowledge-enabling business process. Examples: Business
analysis, System Analysis, Strategy and Planning, among others
2. Common. A common IT function provides common services
across the organization, and doesn't have any competitive
advantage, for example: printing operations, financial systems
(e.g. payroll systems), and HR
3. Standardized. A standardized IT function provide common
task/activities bud adheres to a set of standards develop and
govern by external agencies. In general an IT shared service
provider seek opportunities to promote and standardize common
functions to streamline company operations. Examples:
billing/payment functions, check processing, facilities
management, disaster recovery planning, and data center
operations.
4. Commoditized. A commodity function is one that is too risky
not to have, and the cost burden of maintaining its availability
falls to a secondary plane. There may be many providers of
these type of functions. Examples: network service providers,
application service providers,(ASPs), universal power supply
(UPS), etc.
5. Utility. A utility function is a commodity deliver by a
centralized and consolidated supplier. "Private" utility providers
compete in the open market, while "public" utility providers are
likely to be single suppliers overseen by regulatory agencies.
Examples: Internet Service Providers (ISPs), and
Telecommunication Service Providers (e.g., cloud services, and
bandwidth on demand)
It is important to note that an IT function maturity stage will
vary from company to company,depending on the company's

7. strengths and capabilities; hence, some IT function
independently of their stage might be insource or outsource.
IT SOURCING OPTIONS: THEORY VERSUS PRACTICE
As discussed in our textbook, IT functions can be classified as:
1. In-house. Permanent IT staff provide the IT function
2. Insource. Internal IT personnel are brought into the
departmental unit to support the permanent IT staff to provide
the IT function
3. Outsource. IT functions are provided by an external
organization
4. Partnership. It is formed by a private agreement between the
partners to complement their IT functions services via a joint
venture or the creation of a new company.
So the question is: How IT sourcing options are determined?
The answer is not straightforward and basically determination
of the IT sourcing option resides on following decision criteria:
flexibility, control, knowledge enhancement, and business
exigency.THE REAL DECISION CRITERIA FOR IT
SOURCING
The IT sourcing decision criteria follows two different
approaches:
· A "normal" approach, in which the IT sourcing option (i.e., in-
house, insource, outsource, or partnership) is decided based on
its flexibility, control, and knowledge enhancement.
Flexibility:
The IT sourcing "flexibility" criterion has two dimensions:
· - Response time (i.e., how quickly IT function can be
delivered), and
· - Capability (i.e., the range of IT functionality)
Control:
The IT sourcing "control" criterion has also two dimensions:
· - Delivery (i.e., ensuring that the delivery IT function
complies with requirements), and
· - Security (i.e., protecting intellectual assets)

8. Knowledge Enhancement:
The IT sourcing "knowledge development" criterion comprises:
· - Knowledge development
· - Knowledge retention
An "actual" approach, in which the IT sourcing option is
decided based on the "Business Exigency"
Business Exigency : In an urgent situation, the fastest
sourcing option will take precedence. Any of the four sourcing
options (i.e., in-house, insource, outsource, or partnership) can
be selected; however, partnership is the less likely source to be
selected if not prior business arrangement exist.
DECISION FRAMEWORK FOR SOURCING IT FUNCTIONS
"The days of IT being good at all things have long
gone....Today you have to pick your spots.... You have to decide
where you need to excel to achieve competitive
differentiation....Being OK at most things is a recipe to failure
sooner or late" (as cited in Mckeen and Smith, 2015, p. 111).
The following decision strategies for sourcing and delivering IT
functions are presented next.
1. Identify Your Core IT Functions: Identification of core
functions is the first step for the decision framework for
sourcing options. Ideally core functions are kept within the
organization and would use the in-house sourcing option.
2. Create a "Function Sourcing" Profile: Start by listing all the
IT functions and determine if it is (1) a core function, or (2) a
future core function. Next, provide the preferred sourcing
option for the identified IT functions. As discussed before in-
house sourcing option is the preferred sourcing method for core
IT functions, leaving by default the other three sourcing options
to those non-core IT functions.
3. Evolve Full Time IT Personnel: This strategy is based on the
premise that full time IT personnel is a resource which
represents a major investment for the company, and therefore its
utilization should be maximized or at least optimized. As such,
the preferred sourcing approach is "insourcing." Another
method used to develop internal IT personnel is based on

9. "Strategic hiring".
4. Encourage Exploration of the Whole Range of Sourcing
Options: This strategy is self-explanatory; companies could
choose to explore any of the sourcing option. There is no
prescribed guide to determining which sourcing option to use. It
is noted that companies choosing to operate within their comfort
zone will select in-house sourcing option as their preferred
option.
5. Combine Sourcing Options Strategically: This strategy
requires to focus on the sourcing of specific IT functions. More
and more this strategic approach is becoming more popular
since it provides flexibility to address a project's requirement,
resulting in a "realizable benefits" such as speed to market.
A MANAGEMENT FRAMEWORK FOR SUCCESSFUL
SOURCING
Key Factors Essential to Effective Management of Sourcing
Options
Develop a Sourcing Strategy:
Key steps include:
· Use a decision framework.
· Determine what are the organization’s “core” and “non-core”
functions
· Determine “what to”, “where to”, “how to”, “to whom to”
source
Develop a Risk Mitigation Strategy: Start by planning the
(outsource) work, developing a work breakdown structure
(WBS), and creating a network diagram that can provide the
inter-relation among activities and a delivery schedule. Next,
apply a Risk Management Process as the one suggested by the
Project Management Institute (PMI) or any other management
process used by the organization.
Key processes suggested in a risk management plan (RMP)
include:
· Identify all the activities, roles, responsibilities, and
expectations

10. · Assess the risk by determining the probability of occurrence
of the risk and impact to the project if it were to occur. Next
determine the risk exposure and prioritize the risks
· Plan Risk Responses, mainly by creating a mitigation plan and
a back-up or contingency plan if the risk actually happens.
Pulling activities back in-house is an exit strategy that should
be considered as a back-up plan.
· Implement Risk Responses by ensuring the risk response plans
are being executed.
· Monitor Risk by incorporating an audit trail into the contract
to ensure self-correction and protect both parties (i.e., the buyer
and the seller)
Develop a Governance Strategy: Layers of governance are
critically important for successful sourcing relationships,
particularly for offshore sourcing.
· Structure and outsourcing relationship to ensure risk is shared
by seller and the buyer, so that both are incented to make it
work
Understand the Cost Structures: It is imperative to understand
the cost of doing an activity internally (i.e., in-house or
insource) vs. the cost when outsourcing it.
· Understand the true cost of outsourcing by adding other costs
such as "relationship management", and "contract management"
for an effective comparison in costs.
It is clear that if the activity is more costly to do it in-house,
then outsourcing should be considered.
Wrapping Things Up
The process of developing an IT shared services requires a clear
understanding of the pros, cons, organizational success factors,
and strategies for the successful creation of an IT shared
services organization. In particular IT management must know
the various sourcing options to their disposal and have a robust
criteria to aid them in the decision making process.
Furthermore, they should have a strategy in place to effectively
manage the sourcing options.References
McKeen, J., & Smith, H. (2015). IT Strategy: Issues and

11. Practices (3rd edition). Upper Saddle River, NJ: Pearson
Prentice Hall
O'Brien, J. A., & Marakas, G. (2005). Introduction to
Information Systems (11th ed.). New York, NY: McGraw-Hill.
Case Study Title
DateCourseInstructor
Introduction
An introduction is used to let the reader know:
· The main entity or entities involved
· The major question or issue being analyzed

12. Introductions for case studies in this course should be one
paragraph in length.
Background
This is a brief overview of the main problems or questions
involved. Historical information can be used as long as it has a
direct bearing on the items being analyzed. Provide enough
description that a reader that is unfamiliar with the case will
understand the context of your analysis. For this course,
background information should be two to three paragraphs in
length, maximum.Discussion
The discussion includes an analysis of each problem or
question. The analysis can include:
· The problem or question and its impact on the main entities
involved.
· How the problem or question is linked to the topics we have
discussed or read to this point.
· How the problem or question is linked to best practices in
industry.
· A solution or multiple solutions and an evaluation of those
solutions.
In this course the case studies will have at least one major
problem or question. There may be secondary problems or
questions but there will be, at most, one or two secondary
issues. Use as much space as necessary to provide a rational
analysis but if there are more than four or five paragraphs for a
given question the analysis needs to be reviewed and made more
concise.
Conclusion
Summarize your solutions and describe how those solutions
improve the current situation or resolve the problems in the
case. The conclusion should be one to two paragraphs.

13. References
All references must be properly cited and referenced using APA
format. Refer to the syllabus for tutorials and resources on
using APA format.
PAGE 2
Mini Case Building Shared Services at RR Communications4
4 Smith, H. A., and J. D. McKeen. “Shared Services at RR
Communications.” #1-L07-1-002, Queen’s School of Business,
September 2007. Reproduced by permission of Queen’s
University, School of Business, Kingston, Ontario, Canada.
Vince Patton had been waiting years for this day. He pulled the
papers together in front of him and scanned the small
conference room. “You’re fired,” he said to the four divisional
CIOs sitting at the table. They looked nervously at him,
grinning weakly. Vince wasn’t known to make practical jokes,
but this had been a pretty good meeting, at least relative to
some they’d had over the past five years. “You’re kidding,” said
Matt Dawes, one of the more outspoken members of the
divisional CIO team. “Nope,” said Vince. “I’ve got the boss’s
OK on this. We don’t need any of you anymore. I’m creating
one enterprise IT organization, and there’s no room for any of
you. The HR people are waiting outside.” With that, he picked
up his papers and headed to the door, leaving the four of them
in shock.
“That felt good,” he admitted as he strode back to his office. A
big man, not known to tolerate fools gladly (or corporate
politics), he was not a cruel one. But those guys had been thorns
in his side ever since he had taken the new executive VP of IT
job at the faltering RR Communications five years ago. The
company’s stock had been in the dumpster, and with the
dramatically increased competition in the telecommunications
industry as a result of deregulation, his friends and family had
all thought he was nuts. But Ross Roman, RR’s eccentric but
brilliant founder, had made him an offer he couldn’t refuse.
“We need you to transform IT so that we can introduce new

14. products more quickly,” he’d said. “You’ll have my full backing
for whatever you want to do.”
Typically for an entrepreneur, Roman had sketched the vision
swiftly, leaving someone else to actually implement it. “We’ve
got to have a more flexible and responsive IT organization.
Every time I want to do something, they tell me ‘the systems
won’t allow it.’ I’m tired of having customers complaining
about getting multiple bills for each of our products. It’s not
acceptable that RR can’t create one simple little bill for each
customer.” Roman punctuated his remarks by stabbing with his
finger at a file full of letters to the president, which he insisted
on reading personally each week. “You’ve got a reputation as a
‘can do’ kind of guy; I checked. Don’t bother me with details;
just get the job done.”
Vince knew he was a good, proactive IT leader, but he hadn’t
been prepared for the mess he inherited—or the politics. There
was no central IT, just separate divisional units for the four key
lines of business—Internet, mobile, landline, and cable TV
service—each doing its own thing. Every business unit had
bought its own hardware and software, so introducing the
common systems that would be needed to accomplish Roman’s
vision would be hugely difficult—that is, assuming they wanted
them, which they didn’t. There were multiple sales systems,
databases, and customer service centers, all of which led to
customer and business frustration. The company was in trouble
not only with its customers but also with the
telecommunications regulators and with its software vendors,
who each wanted information about the company’s activities,
which they were legally entitled to have but which the company
couldn’t provide.
Where should he start to untangle this mess? Clearly, it wasn’t
going to be possible to provide bundled billing, responsiveness,
unified customer care, and rapid time to market all at once, let
alone keep up with the new products and services that were
flooding into the telecommunications arena. And he hadn’t
exactly been welcomed with open arms by the divisional CIOs

15. (DIOs), who were suspicious of him in the extreme. “Getting IT
to operate as a single enterprise unit, regardless of the product
involved, is going to be tough,” he admitted to himself. “This
corporate culture is not going to take easily to centralized
direction.”
And so it was. The DIOs had fought him tooth and nail,
resisting any form of integration of their systems. So had the
business unit leaders, themselves presidents, who were
rewarded on the basis of the performance of their divisions and,
therefore, didn’t give a hoot about “the enterprise” or about
anything other than their quarterly results. To them, centralized
IT meant increased bureaucracy and much less freedom to pick
up the phone and call their buddy Matt or Larry or Helen, or
Dave and get that person to drop everything to deal with their
latest money-making initiative. The fact that it cost the
enterprise more and more every time they did this didn’t
concern them—they didn’t care that costs racked up: testing to
make sure changes didn’t affect anything else that was
operational; creation of duplicate data and files, which often
perpetuated bad data; and loss of integrated information with
which to run the enterprise. And the fact that the company
needed an army of “data cleansers” to prepare the reports
needed for the government to meet its regulatory and Sarbanes–
Oxley requirements wasn’t their concern. Everyone believed his
or her needs were unique.
Unfortunately, although he had Roman’s backing in theory, in
practice Vince’s position was a bit unusual because he himself
didn’t have an enterprise IT organization as yet and the DIOs’
first allegiance was clearly to their division presidents, despite
having a “dotted line” reporting relationship to Vince. The
result was that he had to choose his battles very, very carefully
in order to lay the foundation for the future. First up was
redesigning the company’s internal computer infrastructure to
use one set of standard technologies. Simplification and
standardization involved a radical reduction of the number of
suppliers and centralized procurement. The politics were fierce

16. and painful with the various suppliers the company was using,
simultaneously courting the DIOs and business unit leaders
while trying to sell Vince on the merits of their brand of
technology for the whole company. Matt Dawes had done
everything he could to undermine this vision, making sure that
the users caused the maximum fuss right up to Roman’s office.
Finally, they’d had a showdown with Roman. “As far as I’m
concerned, moving to standardized hardware and software is
nondiscussable,” Vince stated bluntly. “We can’t even begin to
tackle the issues facing this company without it. And
furthermore, we are in serious noncompliance with our software
licensing agreements. We can’t even tell how many users we
have!” This was a potentially serious legal issue that had to be
dealt with. “I promised our suppliers that we would get this
problem under control within eighteen months, and they’ve
agreed to give us time to improve. We won’t have this
opportunity again.”
Roman nodded, effectively shutting down the argument. “I don’t
really understand how more standardization is going to improve
our business flexibility,” he’d growled, “but if you say so, let’s
do it!” From that point on, Vince had moved steadily to
consolidate his position, centralizing the purchasing budget;
creating an enterprise architecture; establishing a standardized
desktop and infrastructure; and putting tools, metrics, and
policies in place to manage them and ensure the plan was
respected by the divisions.
Dawes and Larry Hughes, another DIO, had tried to sabotage
him on this matter yet again by adopting another manufacturer’s
customer relationship management (CRM) system (and yet
another database), hoping that it could be up and running before
Vince noticed. But Vince had moved swiftly to pull the plug on
that one by refusing the project access to company hardware and
giving the divisional structure yet another black mark.
That episode had highlighted the need for a steering committee,
one with teeth to make sure that no other rogue projects got
implemented with “back door funding.” But the company’s

17. entrepreneurial culture wasn’t ready for it, so again
foundational work had to be done. “I’d have had a riot on my
hands if I’d tried to do this in my first few years here,” Vince
reflected as he walked back to his office, stopping to chat with
some of the other executives on his way. Vince now knew
everyone and was widely respected at this level because he
understood their concerns and interests. Mainly, these were
financial—delivering more IT for less cost. But as Vince moved
around the organization, he stressed that IT decisions were first
and foremost business decisions. He spoke to his colleagues in
business terms. “The company wants one consistent brand for
its organization so it can cross-sell services. So why do we need
different customer service organizations or back-end systems?”
he would ask them. One by one he had brought the “C”-level
executives around to at least thinking about the need for an
enterprise IT organization.
Vince had also taken advantage of his weekly meetings with
Roman to demonstrate the critical linkage between IT and
Roman’s vision for the enterprise. Vince’s motto was “IT must
be very visible in this organization.” When he felt the political
climate was right, he called all the “Cs” to a meeting. With
Roman in the room for psychological support, he made his
pitch. “We need to make all major IT decisions together as a
business,” he said. “If we met monthly, we could determine
what projects we need to launch in order to support the business
and then allocate resources and budgets accordingly.”
Phil Cooper, president of Internet Services, spoke up. “But what
about our specific projects? Won’t they get lost when they’re all
mixed up with everyone else’s? How do we get funding for what
we need to do?”
Vince had a ready answer. “With a steering committee, we will
do what’s best for the organization as a whole, not for one
division at the expense of the others. The first thing we’re going
to do is undertake a visioning exercise for what you all want our
business to look like in three years, and then we’ll build the
systems and IT infrastructure to support that vision.”

18. Talking the language of business had been the right approach
because no one wanted to get bogged down in techno-jargon.
And this meeting had effectively turned the tide from a
divisional focus to an enterprise one—at least as far as
establishing a steering committee went. Slowly, Vince had built
up his enterprise IT organization, putting those senior IT
managers reporting to him into each of the business divisions.
“Your job is to participate in all business decisions, not just IT
ones,” he stated. “There is nothing that happens in this company
that doesn’t affect IT.” He and his staff had also “walked the
talk” over the past two years, working with the business to
identify opportunities for short-term improvements that really
mattered a lot to the divisions. These types of quick wins
demonstrated that he and his organization really cared about the
business and made IT’s value much more visible. He also
stressed accountability. “Centralized units are always seen to be
overhead by the business,” he explained to his staff. “That’s
why we must be accountable for everything we spend and our
costs must be transparent. We also need to give the business
some choices in what they spend. Although I won’t compromise
on legal, safety, or health issues, we need to let them know
where they can save money if they want. For example, even
though they can’t choose not to back up their files, they can
choose the amount of time it will take them to recover them.”
But the problem of the DIOs had remained. Used to being kings
of their own kingdoms, everything they did appeared to be in
direct opposition to Vince’s vision. And it was apparent that
Roman was preaching “one company” but IT itself was not
unified. Things had come to a head last year when Vince had
started looking at outsourcing. Again the DIOs had resisted,
seeing the move as one designed to take yet more power away
from them. Vince had offered Helen a position as sourcing
director, but she’d turned it down, seeing it as a demotion rather
than a lateral move. The more the DIOs stonewalled Vince, the
more determined he became to deal with them once and for all.
“They’re undermining my credibility with the business and with

19. our suppliers,” Vince had complained to himself. “There’s still
so much more to do, and this divisional structure isn’t working
for us.” That’s when he’d realized he had to act or RR wouldn’t
be able to move ahead on its next project: a single customer
service center shared by the four divisions instead of the
multiple divisional and regional ones they had now.
So Vince had called a meeting, ostensibly to sort out what
would be outsourced and what wouldn’t. Then he’d dropped the
bombshell. “They’ll get a good package,” he reassured himself.
“And they’ll be happier somewhere else than always fighting
with me.” The new IT organizational charts, creating a central
IT function, had been drawn up, and the memo appointing his
management team had been signed. Vince sighed. That had been
a piece of cake compared to what he was going to be facing
now. Was he ready for the next round in the “IT wars”? He was
going to have to go head to head with the business, and it
wouldn’t be pretty. Roman had supported him in getting the IT
house in order, but would he be there for the next step?
Vince looked gloomily at the reports the DIOs had prepared for
their final meeting. They documented a complete data mess—
even within the divisions. The next goal was to implement the
single customer service center for all divisions, so a customer
could call one place and get service for all RR products. This
would be a major step forward in enabling the company to
implement new products and services. If he could pull it off, all
of the company’s support systems would, for the first time, talk
to each other and share data. “We can’t have shared services
without common data, and we can’t have good business
intelligence either,” he muttered. Everything he needed to do
next relied on this, but the business had seen it differently when
he’d last tried to broach the subject with them. “These are our
data, and these are our customers,” they’d said. “Don’t mess
with them.” And he hadn’t . . . . but that was then. Now it was
essential to get their information in order. But what would he
have to do to convince them and to make it happen?