Page 272 -

that’s the “regular way” that clients interact with your particular vendor. The benefit of
doing things the “regular way” does not outweigh the increased chance of miscommuni-
cation, scope problems, and requirements problems. Provided you take responsibility for
your part of the end deliverable, you should be able to work with the team in the way you
are most comfortable.

In addition to escalation, there are other procedures at the vendor that might not suit your
method of working. Their system for performance reviews might reward your team mem-
bers for things that are important to the vendor’s organization but are not necessarily
important to your project. For example, they might be rewarded for years of service at the
vendor. It looks great from the vendor’s perspective to have a team of “seasoned profes-
sionals” (who may have been around for a long time, but may not necessarily be stellar
performers). If a vendor can quickly assemble a team of people with many years of experi-
ence, they can use this as a sales tool to get more lucrative contracts. Therefore, when they
are recruiting potential employees, some vendors might offer a compensation package
that rewards years of experience over knowledge. What’s more, some vendors work very
hard to prevent attrition because it looks worse for clients, and so will work very hard to
keep from losing employees who have seniority—even if these employees are not all that
great at their jobs.

It’s not just hiring and firing practices that might not suit your project. There may also be
trouble with the specific ways that vendors reward employees. It is common for vendors
to reward employees for seniority with things like increased responsibility and access to
new technology. This can be bad for your project: it is very unlikely that you will need to
change your team members’ responsibilities or switch technologies over the course of
your project, which means that you are cutting your team off from what they traditionally
expect as a reward for seniority. In other words, if you are developing a piece of software
in Visual Basic, the chances are that you will not change to Java over the course of your
project. If people on your team feel that they are falling behind in their technical skills,
they will look to switch to another project at the vendor.

Look around your own organization: you can probably think of one or two people who
have been there a long time, yet are not great employees! There’s no reason to think that

this isn’t also true at the vendor. The bottom line is that a team member with years of
experience in IT or seniority at a vendor is not necessarily competent. This means that the
less you rely on the vendor’s management to assign responsibilities to and reward your
team members, the more control you have over your project. The best way to handle this
is to set up your own system of rewards. For example, you can offer a bonus based on
actual performance rather than seniority. To do this, you need to have a good handle on
how well each person does her job—which, once again, means that you need to commu-
nicate with them. This works especially well if you personally assign tasks to the team
members, rather than relying on the vendor’s management to do that for you. This will
require that you do your own project planning (see Chapter 2), and that you find ways of
objectively measuring the performance of the people on your team.

264 CHAPTER ELEVEN