Page 283 -

will welcome this collaboration. It means that you are sharing responsibility for the quality
of the code. You are recognizing the challenges that the team developing the product will
face, and you are helping them solve those problems. And it means, ultimately, that there
will be no surprises: you won’t end up with interminable QA cycles. In other words, both
the project manager and the vendor should see this as a win-win situation.

Take Responsibility for Quality
You are responsible for the quality of your products, even when you contract the work
out. It’s easy to forget this. If you are paying a vendor to build a project, it somehow
makes it easy to consider quality just another deliverable. It’s not—it’s a responsibility.

Many times, outside providers will offer “testing” of their products as part of the develop-
ment estimate. It’s not uncommon for this testing to be done not by an independent test-
ing team but by the programmers who wrote it, or by junior members of the programming
team with little or no test experience. When this is the case, they generally do not have
much test documentation. Do not let this happen to your project. Demand resources allo-
cated exclusively to test activities. Expect to review and inspect all test documentation. Be
sure that your test activities are defined in your vision and scope document and, if possi-
ble, discussed in your contract.

Just as you would have members of your test team involved in all document inspections
in your own organization, schedule your designated test team outside to review all docu-
ments and schedule their time researching and writing test plans as well. If you use spe-
cific metrics to measure product quality, expect your test team off-site to provide the same
data and meet the same standards. Collaborate with them as you would your own team—
spot-check the test plans, and test the results to be sure that the testing is being done as
you would expect. Defect tracking should be done within your own organization. Test
results should be monitored, and redundant tests should be done within your organization
to be sure that bugs aren’t slipping through.

Don’t make decisions that undercut your QA team. When the project has reached its test-
ing phase, there are many points when the project manager has to decide between doing
things in less time and doing them thoroughly. As the end date looms closer and closer, it

becomes less and less appealing to choose the “thorough” option.
For example, say you have a project 25% through its regression test cycle after a minor bug
fix. Everyone expected the test to go well, but instead, a major defect was found. The lead
tester at the vendor asks whether they should cut a new build now or if they should finish
the regression test. It’s possible that there are no more major bugs lurking within the code,
and you could potentially cut out 75% of the time it takes to regress the software. Do you do
it? If you are taking responsibility for the quality of the product, the answer is “absolutely
not”: you know that chances you will find another defect when you cut the next build are
greater if you haven’t completed the current regression test. But it’s difficult to make this
decision with looming deadlines, clients putting pressure on you, and, most importantly, a
compliant vendor willing to cut out work in order to meet your deadline.

MANAGING AN OUTSOURCED PROJECT 275