Outsourcing: Preparing the natives to welcome the new allies

One of the most resounding mantras in business today is to do more with less, especially in IT. You won't find "slow periods" here. Gone are the days of large internal IT groups, awaiting new projects or experimenting to develop the next killer application.

More and more, companies look to external consultants for small- and large-scale IT application design and development projects. Progressively smaller staffs must manage more business-critical technology initiatives -- which leads companies to look outside for additional support.

Many companies find a money-saving solution in outsourcing noncore business projects, particularly business enablement projects. It's a cost-effective way to remain competitive and complete critical projects -- including custom applications, data warehousing, third-party integration and marketing initiatives such as Web-site redesigns.

"Going outside" isn't always smooth sailing, though. While external resources meet these needs, it can be expensive and cost-prohibitive. Far too many companies simply turn to external consultants without properly involving key internal personnel or identifying explicit project objectives and goals. What happens as a result? Not surprisingly, many of these initiatives don't meet expectations -- or simply fail. Whether you're redesigning part of your Web site, integrating mission-critical data or constructing a complete business-to-business IT infrastructure, here are some simple steps to ensure that your next external development project will run smoothly and garner internal acceptance.

Define the Scope

There's no point in rubbing the lamp if you don't know what to ask the genie. What do you need? What do you want? Whether you're integrating legacy systems or simply reporting mission-critical data, figure out what you need and want before you hire someone to complete the task. The leading cause of failed projects, large or small, is the double whammy of loosely defined requirements and poor planning. It might seem ridiculous to think that a company would hire a consultant to do a job before even realizing what the job is; however, this happens far too often. Understanding what you want will help you define your expectations, control negotiation and articulate the project plan.

You should spend time before engaging a partner to accomplish a few tasks:

  • Clearly identify your project objectives
  • Define the measurements of success
  • Recognize critical success factors
  • Distinguish between internal problems and process pain points
  • State an achievable goal.

By documenting these criteria before starting the project, your team members will feel more in control. They'll find themselves with a list of quantifiable measurements to ensure that the project remains on track. This list of factors will influence the direction of project, help guide decisions and define how the team will measure success. A little planning up front will provide your team with a road map for success throughout the project life cycle.

The internal team should be prepared to educate the external development staff. It's easy to call the shots on a high level: "This is what we want; build it!" But can your internal team define what "it" is? The requirements should focus on the "what" and "why" of your company's problem statements.

  • What business issues should the application address?
  • What will this application do?
  • Why do you need it to do that?
  • What efficiencies will it provide?

An excellent rule of thumb is if you can't explain what you want and why you need it to someone that doesn't work in your industry, then you probably have more work to do. So, how do you go about defining clear goals, needs and priorities? Try working with an outside vendor who can drive you to consensus with a brief, targeted workshop.

A good facilitator will make you think about the current process and challenge your preconceived ideas regarding a solution. Plan to pay 10% to 20% of the proposed budget for this outside opinion -- you'll reap immediate benefits in your organization and continue to see the return on investment throughout the project.

After you've figured out what you want, you need to figure out how long it will take to accomplish. Dovetailing project requirements with a realistic estimate of the project duration will help manage internal expectations. Understandably, your company will want this process to be completed as quickly as possible -- which might translate into a less-than-realistic time frame. Simply wanting or demanding something to move quickly doesn't mean it will. Your team should take a realistic look at the time required to complete the project. It's not uncommon for internal teams to underestimate the project durations by as much as 300%.

One helpful way to develop a realistic estimate entails listing desired features and assigning a time frame to each feature. Add these together, and you should get a close approximation of the expected timeline. Don't consider this rough estimate a final timeline, or even a high-level project plan, but use this as a basis for negotiation when you select a vendor.

Don't forget assimilation time, a frequently overlooked element in the budget. The vendor will require time to get up to speed on your process, your business and quality assurance practices. Make sure to include estimates for meeting times and the number of internal resources necessary at each step in the development process. If Susan is the primary contact at your company, be sure her schedule allows her to be available for the external team.

Organize the Internal Team

Now that you know what you want, make sure you get the right people involved. This is a delicate process. Who should be included, and at what stage of the process? Who is extraneous to the project or may slow down the process? There will be times when you'll need answers to questions or assistance with deliverables. Getting the right people allocated in the beginning will benefit the project down the road.

You can't go at it alone: To complement your external consultants, you need an internal team and support from key stakeholders. The internal team serves several purposes. It answers questions, clarifies requirements and assists the consultants.

In most cases, the internal team will have a list of features and deliverables, milestones in the success of the project, along with information about how they're personally involved. Get buy-in from the key stakeholders to ensure they allocate the proper resources and time to the project.

Remind internal resources that the time required to support the project may affect their daily responsibilities -- so they should fully understand the level of effort required of them. State these expectations clearly, early and often so staffers can delegate noncritical internal tasks to others.

Pitfalls abound -- project timelines can be compromised quickly if internal team members fail to deliver critical path items to the outsourced team.

Roles and Responsibilities

There's no secret recipe here. All projects comprise resources that fall into a few categories:

  • Project champions or sponsor
  • Primary contact
  • Decision makers
  • Supporting cast
  • Success blockers

Recognize where each team member fits into your project. The difference between success and failure on a project is figuring out who the players are and knowing how to best use them.

Project champions are typically managerial employees who understand the project's value. They'll help at the beginning to get the right people on board and will help both external and internal teams understand the scope. Keep them abreast of the operation so if a problem does arise, they're fully aware of background information and can help resolve it. They own the success and failure of the project -- so they will help focus the direction and scope of the project.

The primary contact can either make or break a project. It's his responsibility to ensure that the external development team has access to the internal members of the team as needed. The primary contact should have a technical background and in-depth knowledge of the problems and proposed solution. He should have the support of the decision-makers to get the job done by the best and most efficient way they know how.

Decision-makers are typically at the executive level and are rarely involved with day-to-day tasks. Not all decision-makers are at the managerial level; in fact, you should have a resource with decision-making authority working with the primary contact. If this isn't feasible, the primary contact should be authorized to make day-to-day decisions in order to keep the project on track.

The supporting cast handles the day-to-day project resources. This includes internal team members who are passionate about the project and want it to succeed. They will team with the primary contact to assist the consultants in meeting deliverables.

While you may not task someone to this role, don't forget about the success blockers -- the negative "can't do that" folks who show up on every project. It's important to recognize these people right away; limit their involvement, although not altogether. The success blockers often have valuable insight into the risks of a project. After all, you don't want a team full of the "everything is possible" types.

Set Expectations

All parties should clearly communicate their expectations to ensure a successful project. While members of your internal team might be on the same page about the application, is your external development team? Make sure you translate these expectations to them.

Consultants will often deliver based on their expectations or assumptions, which is you should make sure your expectations are clear by documenting the needs and scope of the project. If you expect a loaded Mercedes, you don't want to receive a loaded BMW. Although both are luxury cars, many consumers prefer one to the other for a variety of reasons.

Setting expectations doesn't have to be a difficult. Follow these guidelines, and you'll communicate your needs while gaining buy-in from your internal stakeholders. To start with, be sure the entire team is there when the requirements are translated to the vendor -- you want to ensure all parties hear the same story.

In addition to the face-to-face meeting, provide the requirements and specifications in writing. This document will serve as the basis for quoting and budgeting as well as the blueprint for development. Encourage the vendor to ask questions in order to clear up any misunderstandings early on.

Manage Change

So the train is leaving the station, we're all on board ... but what happens when we change our minds? It's unrealistic to think all projects will be perfectly defined, scoped or budgeted right from the start. Every project undergoes changes, and you'll need to address these changes upfront and quickly -- with all members involved. Sounds easy, right?

A great way to minimize the impact of change on a project is to establish a change-control team. This team will clearly communicate the risks associated with a change and drive the necessary decisions and the action plan. The goal of your change management team will be keeping business expectations and objectives as the primary goals of each initiative.

It's possible to effectively outsource your project and position it on a course for success. Spend patience and time internally to make it that much easier. While these factors don't necessarily guarantee success, you'll be on the right track.

Remember your tool kit -- open communication, a well-defined scope and setting clear expectations -- and you'll improve the odds that all internal and external parties will understand what drives the initiatives and the success criteria for completion.

Copyright © 2005 IDG Communications, Inc.

Shop Tech Products at Amazon