2.1 Writing the Job TicketThe Ask

2.1 Writing the Job Ticket”"The Ask"

The successful development of an integrated service delivery strategy begins and ends with a well-developed job ticket. There is no mystery to the job ticket, simply put, it is the problem set”it sets the scope and boundaries and defines the expected set of deliverables. The job ticket helps you to determine the skills mix of the team you will need to assemble, as well as, helps you to "chart the course" for the team. A well-crafted, clear, succinct job ticket will serve 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

2.1.1 Problem Statement

This is exactly what it suggests; it simply means to define the problem, and yet formulating a problem statement is not always easy. Don`t be quick to jump the gun with what you think the problem is, or you could be treating what turns out to be only a symptom. Don't get caught in the trap of prematurely deciding the route cause, this too can lead you down a wrong path . It is important, however, to understand all of the symptoms, which are the manifestations of whatever the root causes may be.

For example, inChapter 1, we referred to a graph of sagging customer satisfaction, sagging Level of Service (LOS), and increasing costs with outsourced services:

Given that Figure 2-1 is a representation of symptoms experienced from an outsource partnership, there might be a tendency to have the problem statement read:

Figure 2-1. ISD trends.

Our outsource partner cannot deliver the required customer satisfaction, level of service, and required cost targets necessary to support a globally distributed environment.

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

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. 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.

2.1.2 Purpose/Statement of Deliverables

The purpose/statement of deliverables should tie directly to, and actually be a function of, the problem statement. They not only convey the expectations of the management team, including time frames for delivery, but they also serve as a framework for the team. To illustrate the point it is best to look at the following example:

The purpose of the team is to develop and provide alternatives to 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, and have associated with it the relevant supporting facts, cost model, quality, and delivery metric impacts. The initial draft is to be delivered six weeks from the start of the project.

You can see from this example how the purpose is a direct function of the problem statement, and that the statement of deliverables is defined at a high level.

2.1.3 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 empowerment to affect 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. Given this, it is important to note that it is not always enough to define what is in scope, it is equally important to define what specifically is not in scope

Here is an example of a subset of scope/boundaries:

In Scope

• UNIX-based servers, hardware, software, and associate applications set.

• LAN networks within the walls of the data center on 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.

2.1.4 Team Definitions

In order to ensure the involvement, buy-in, and support across functions in the organization and across the corporation, it is important that a multitier team structure is put in place prior to the execution of the job ticket. The formation of the multitiered structure is essential to success.

1. The Core Team

   These are "the doers," the main team chartered to execute the job ticket. The team should be small, with broad yet diverse expertise. Its makeup should include members with the following skill sets: applications development and management, data base administration, system administration, infrastructure development and management, and facilities management. These skills represent the essential components for a complete ISD 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.

2. 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 upfront. 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.

3. Extended Support Team (if applicable )

   The formation of this team is really dependent on the size and structure of your company. Where it really adds value is when your IT Organization is organized 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 is crucial to pull these people in to ain an expanded perspective, as well as for cross-corporate buy-in.

4. Steering Committee/Decision Team

   This is the team of direct decision makers who ultimately have authority over whether or not the proposal you will be presenting will be approved. This is why gaining their buy-in early on in the project is so important.