Page 265 -

In fact, that very management overhead at the vendor can be a major source of problems
on your project. For example, an in-house development team in an organization can stan-
dardize on a single language and platform; a vendor, on the other hand, must be ready to
take on a broad range of technologies for many different clients, most of which will not
have any application whatsoever to your project. To accomplish this, the vendor has an
incentive to keep all of the programmers on the team cross-trained in multiple technolo-
gies. One way to do this is to make sure that each programmer is only assigned to any one
project for a short period of time, in order to expose him to many technologies. This
means that long-term engagements can be difficult to set up: many of the people on your
project will see that by staying on your team for a long time, they are falling behind on the
technologies that allow them to advance within the vendor’s organization. This does not
necessarily work against you, but it certainly does not work to your advantage.

Similarly, most good outsourcing vendors will put effort into cross-training other people
in their organization on best practices learned from each client. While this can be good
(because it can potentially help them address your needs better), it also means that some
of your project team members will be allocated in part to helping other project teams
internally at the vendor.
In other words, there are many ways that your needs and the needs of the vendor are not
perfectly aligned. This makes sense—you have two different organizations, with different
businesses and goals. But this difference introduces distance between the client and the
vendor, which can lead to some specific ways that many outsourced projects fail.
The most common response to this—and the most serious mistake that a project manager
can make when working with an outsourced project—is to assume that it’s the vendor’s
responsibility to fix every problem that comes up in a way that will guarantee that the soft-
ware gets built properly. There is very seductive logic here: “I’m paying the bills, and the
vendor will lose my business if they don’t get this right, so they have to take care of every-
thing!” This attitude fails every time. The vendor does not have enough information to build
the software properly, and a hands-off project manager who leaves everything to the vendor
will find that the software that is delivered does not meet the needs of his organization.
Constantly Communicate Project Goals

The people working on your project have different goals than you do. Many of them may
see the tasks that you give them as simply an opportunity to expand their knowledge.
Others are completely devoted to the work that you have given them, but they don’t nec-
essarily see the context in which you have asked for it; all that they know about the
project is what you have told them, and they don’t (or can’t) have an intuitive under-
standing of your organization’s needs because they don’t work there.
What this amounts to is the fact that you are the only person working with the project
team who has your organization’s needs and goals in mind. As a result, outsourcing teams
are much more susceptible to the “Do what I mean, not what I say!” problem. An in-
house project team almost always has a grasp on what it is that the organization does;
people get an enormous amount of context just from working at an organization. Team

MANAGING AN OUTSOURCED PROJECT 257