Page 274 -

access to the entire organization: they can talk to managers, stakeholders, users, etc. This
is not the case on outsourced projects, where the vendor must route all communication
through the project manager. This introduces many potential pitfalls into your project.
The most costly problems involve the project scope and software requirements. If you do
not describe the project adequately, you will end up with software that does not meet the
needs of your organization. An in-house project team has many more opportunities to
catch these problems.

This requires that you pay a lot of attention to your project team members, possibly more
than you would to an in-house team. This is paradoxical, as most project managers are
more likely to spend time with an in-house team than they would with a team at a ven-
dor. It’s not only your job to communicate your company’s needs to the team, it’s also
your job to understand the needs of each team member. For example, if your team mem-
ber needs clarification—and it is essentially impossible to run a project where a team
member does not need clarification!—you are that person’s only resource for gathering
the information. If you do not provide a communications path from the team to your
organization, they will simply make assumptions about any missing or unclear require-
ments. This will almost certainly lead to a misunderstanding. Sometimes those might be
small problems that are easily corrected once the build is delivered. But small problems
can snowball into big ones, and that could lead to software that does not do what you
expect it to.

One of the hardest parts of working with your project team is correcting problems. Keep-
ing a team motivated when they are not performing as well as you would like them to is
difficult enough when they are in-house (see Chapter 10). It is even more difficult to han-
dle this situation in an outsourced environment. Not only is the team in another organiza-
tion, where you don’t have the same access to them, but they also do not have the same
goals as you do.

Expecting your project team to give you credibility in reviewing their work is like expecting
your car mechanics to listen to your criticisms of how they fix your car. Most of the clients
that your team has dealt with in the past have probably been relatively hands-off. The cli-
ents have been mostly ignorant of how software is built at their organization, so it’s likely

that some of your team members have never even been addressed directly by a project man-
ager at a client. Now they’re faced with a project manager who is taking the time to evaluate
their work in detail. This new attention may not necessarily be welcome at first, especially
since you will almost certainly ask them to make changes to how they work.
You need to be aware of the fact that when you are saying something negative, you need
to present it with a lot of objective supporting evidence. Over time, you will gain credibil-
ity with them. But, at least initially, you will have to prove that you know what you are
talking about. You will not be recognized as an authority just because you are paying the
bills. This is a reasonable attitude for the team members to take, since it’s true of most of
their clients. You have to give them good reason to understand that you are different.

266 CHAPTER ELEVEN