Outsourcing doesn't mean foisting off all the work on the provider. For outsourcing to do you any good, you need a dedicated, resourceful, and carefully defined team in house - one that knows exactly what problem they're trying to handle, and uses the best methods and people to accomplish their goals.

This article is part of the Harris Kern Enterprise Computing Institute Series. Placing special emphasis on a comprehensive approach combining organization, people, process, and technology, Harris Kern's Enterprise Computing Institute is recognized as one of the world's premier sources for CIOs and IT professionals concerned with managing information technology.

From the author of

From the author of

As discussed in our earlier article,
"Keys to Successful Outsourcing,"
many factors come into play when deciding whether to outsource. Before an
organization acquires the services of an outsource provider, however, they must
define their requirements, expectations, and metrics thoroughly through the use
of a multi-tiered team structure that will support all functions. Once these
issues have been addressed and documented, the organization, its IT services
provider, and its support teams can judiciously take on other
factorscustomer satisfaction, measurability, scalability, and so on.

Writing the Job Ticket"The Ask"

One key to a successful development strategy involving Integrated Service
Delivery (ISD) is setting problems, scope, and boundaries, and
defining the expected deliverables through a job ticket. There is no
mystery to the job ticket; simply put, it lists the problem, sets the scope and
boundaries of the job, and defines the expected set of deliverables. The job
ticket helps you to determine the skills mix of the team you'll need to
assemble, and helps to "chart the course" for the team. A
well-crafted, clear, succinct job ticket serves as a charter by which the team
will measure its progress.

Let's explore the components of a job ticket:

Problem Statement

Purpose/Statement of Deliverables

Scope/Boundaries

Team Definitions

Problem Statement

The problem statement is exactly what it suggests. The point is to define the
problem, and yet formulating a problem statement isn't always easy:

You must thoroughly analyze the problem, or you could end up spinning
your wheels, treating what turns out to be only a symptom rather than the real
problem.

Don't get caught in the trap of prematurely deciding the root
cause.

It's important to understand all of the symptoms, which are the
manifestations of the root cause(s).

For example, Figure
1 shows a situation of sagging customer satisfaction, decreasing Level of
Service (LOS), and increasing cost of outsourced services. Given that this graph
is a representation of symptoms experienced from an outsource partnership, there
might be a tendency to have the problem statement read like this:

It may not be immediately obvious, but this statement has a fundamental flaw.
The way it's written implies a root cause; therefore, you may immediately
focus your attention on replacing the existing outsource partner, or on
insourcing. Both options could be very costly mistakes if the root causes
actually lie in poorly defined requirements or a poorly defined portfolio of
services. A more suitable problem statement might read as follows:

The current infrastructure supporting our globally distributed environment
is experiencing trends of sagging service levels and rapidly increasing costs,
both resulting in customer satisfaction woes.

This statement makes no implications as to a root cause, but it clearly
defines the symptoms of the problem, keeping the focus fact-based. You can see
the importance of clearly understanding and defining the problem statement.

Purpose/Statement of Deliverables

The purpose/statement of deliverables should tie directly to and actually be
a function of the problem statement. Stating the desired deliverables not only
conveys the expectations of the management team, including timeframes for
delivery, but serves as a framework for the team. Consider the following
example:

The purpose of the team is to develop and provide alternatives for
delivering an infrastructure that supports a globally distributed environment
and provides a consistent and predictable level of service, increased customer
satisfaction, and predictable and manageable costs. The final deliverable should
be in the form of a proposal detailing each alternative, including relevant
supporting facts, cost model, quality, and delivery metric impacts. The initial
draft is to be delivered six (6) weeks from the start of the project.

As this example shows, the purpose is a direct function of the problem
statement, and the statement of deliverables is defined at a high level.

Scope/Boundaries

Boundaries serve multiple purposes. They provide a definition of scope and
magnitude, and even more importantly they define the limits of the team's
empowerment. The team needs to understand the limits of their ability to effect
change. For example, your company might be under a sole source agreement with a
third-party vendor regarding certain aspects of your data center. This would
clearly be out of scope, and therefore a boundary would be set to protect this
agreement. It's not always enough to define what is in scope;
it's often equally important to define what specifically is not in
scope.

LAN networks within the walls of the data center in which the servers
reside

Client software that supports the server-based application

Servers that reside in the Northeast Region

Production, Test, and Development environments and associated
servers

Out of Scope

The client itself and associated office productivity tools

The WAN outside of the data center

Mainframe servers and associated applications

Application XYZ being supported by Vendor UVW

Team Definitions

To ensure involvement, buy-in, and support across functions in the
organization and across the corporation, it's important that a multi-tier
team structure be put in place prior to the execution of the job ticket.
Appropriate formation of the multi-tiered structure is essential to success.

Core team: This team is composed of the "doers," the
main team chartered to execute the job ticket. The team should be small, with
broad yet diverse expertise. It should include members with the following skill
sets: applications development and management, database administration, system
administration, infrastructure development and management, and facilities
management. These skills represent the essential components for a complete
Integrated Service Delivery model and therefore must be represented to ensure
the appropriate coverage. It has been our experience that flexibility, dynamics,
and velocity are in direct relationship to the size of the team.

Support team: The purpose of this team is really twofold: to
provide guidance and/or a specific expertise to the core team, and to gain the
buy-in of the middle management team through their involvement up front.
Therefore, the team should be made up of those IT managers who will be directly
affected by the core team's output. The thought here is that by putting
them on the team it will force interaction, allowing for their input to be
included, and gaining their buy-in early.

Extended support team (if applicable): The formation of this team
depends on the size and structure of your company. Where it really adds value is
when your IT organization is structured by division with an overlying corporate
IT. If this is the case, this should be a team from outside the direct
divisional IT organization. It's crucial to pull in these people to gain an
expanded perspective as well as for cross-corporate buy-in.

Steering committee/decision team: This is the team of direct
decision-makers who ultimately have authority over whether the proposal
you'll be presenting is approved. This is why gaining their buy-in early in
the project is so important.