Outsourcing: How to Create a Transformation Roadmap

If you don't know where you want to go, as the Cheshire cat once advised Alice in Wonderland, any road will take you there. But if you have specific and significant goals for your outsourcing engagement, you need a map to make sure you arrive at the intended destination.

Most information technology leaders enter into outsourcing relationships with a reasonable understanding of where they'd like their IT services provider to take them—some point in the future where the state of IT has been improved by saving money, increasing efficiency, or implementing new enterprise systems.

But do they have a clear idea of how they'll actually get there? Not so much.

The problem with that strategy is that it's akin to heading off on a road trip to a great new destination without a map or directions, says Shawn Fields, a managing consultant with outsourcing advisory firm Alsbridge. And it will likely leave you feeling the same way—lost and frustrated.

Outsourcing clients need to specify not only where they are going —We want a cost reduction of 20 percent over five years, for example—but also how they're going to get there. One way to do that is to create a transformation roadmap: a definitive plan specifying how the vendor will provide those contractually obligated improvements.

"It's easy for a provider to say that they're going to reduce contract spend 20 percent over five years, but where the rubber meets the road is when the client asks, 'How?'" says Fields. "That extra due diligence—the 'how'—provides the mechanism for the client to verify that the committed cost improvements are or are not achievable."

A transformation roadmap should consist of a set of projects prioritized by their importance as well as the timing of their implementation, Fields advises.

Each transitional project in the overall transformation should include a specific set of information. For example, if the overall transformation roadmap calls for overhauling an organization's help desk, one transitional project might be changing the password-reset process, which would look something like this:

Description/Objective

A brief description of the project (The introduction of automated password-reset tool)

Scope

Intended scope of the project (An IT Help Desk)

Investment

A non-binding estimate of what the anticipated investment will be and who is responsible for making the investment (Projected implementation cost of password-reset system is $300,000. Cost will be shared by client and provider.)

Benefit/Savings

Anticipated benefit of implementing project—typically expressed in terms of ROI or productivity (Implementation of the password-reset tool will reduce password calls to the Help Desk by 50 percent annually. At 50,000 password-reset calls annually and $20 per call, anticipated annual cost savings is $625,000. ROI achieved in approximately six months.)

User Impact

Anticipated impact to the end-user community (Average hold times at Help Desk today are 45 seconds. Users will benefit by being able to reset their passwords at their convenience with no hold time, with a corresponding increase in customer satisfaction.)

Dependencies

Any dependencies that might affect the project (In order for the client to achieve a higher ROI, the client must accept the provider's existing password platform. The client's corporate security must also approve the vendor's password reset platform, policy and procedures.)

Timeframe/Approach

Projected implementation timeframe and any specifics related to project approach (The project will take 90 days and will start in the first quarter of 2010. Standard provider project methodology will be followed.)

Then, each project can be categorized into one of three project types:

Category A: Client/provider has sufficient information to start the project, create the project plan, define investment requirements and estimate savings.

Category B: Client and provider believe the project could have a positive effect but lack sufficient information to create project plan, investment requirements or savings estimate.

Category C: The idea, vision or innovation are anticipated to be beneficial but will need to be jointly evaluated in the long term.

While some projects, particularly those that fall into the last category, may not be completely defined, the information included as part of the transformation roadmap should be descriptive enough to allow client and provider team members to effectively evaluate and prioritize them on business needs and the available budget dollars.

The first year of a transformation roadmap may even be incorporated into the initial contract, says Fields, along with language that commits both parties to an annual review of the roadmap and funding mechanisms for revising it. If not enough information is available to include a first year plan in the signed papers, outsourcing customers should include language that stipulates a methodology for and obligation to create a transformation roadmap in the first year of the deal.

"The roadmap is mutually beneficial," says Fields. "It takes the vague notion of continual improvement and puts it into concrete terms. Additionally, it helps set expectations on both sides for what changes are coming and when they're expected to occur."

The only danger is getting too deep into the details in the early stages of every project.

"If that happens, both the client and the vendor waste valuable time arguing about the people, processes and tools of each and every project rather than the benefit of that project to the overall company business strategy," Fields says. " Both parties have to learn to walk the fine line between too much detail on each project and too little—with the right amount being just enough information for each party to make a strategic decision based on the merits of the individual project, and its ultimate benefit to the business."

Insider Resume Makeover: How (and When) to Break the Rules
Join the discussion
Be the first to comment on this article. Our Commenting Policies