The Integrated Service Delivery Strategy
- Writing the Job Ticket — "The Ask"
- Forming the Core Team
- Charting the Approach
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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:
){kind=link}
Our outsource partner cannot deliver the required customer satisfaction, level of service, and required cost targets necessary to support a globally distributed environment.
Figure 1 Symptoms of a problem.
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.
Here's an example of a subset of scope/boundaries:
In Scope
UNIX-based servers, hardware, software, and associated applications set
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.