Page 282 -

Maintain Control of Design and Programming
The challenge of managing the design and programming of an outsourced project is col-
laborating with your engineering team. Clearly, the programming work is going to be tak-
ing place in the vendor’s organization; the only question is whether the various aspects of
the design take place in your own organization or at the vendor.
There are always design constraints for any piece of software: it may need to work with an
existing enterprise infrastructure; you may have legacy code that must be integrated; you
or others in your organization may have already decided on a language or platform; there
may be user interface or other design standards that are already in place and must be met,
etc. Minimally, you must make sure that these are communicated to the vendor.
The easiest way to maintain control over the design of the software is to design it yourself.
Sometimes it’s easiest to come up with a solution yourself that meets all of your needs,
and to provide that as technical direction to the programming team at the vendor. You can
do this by writing a technical specification or approach document. If you do this, it’s very
important that you put checkpoints in place, in order to make sure that the work is really
being done according to these documents. The vendor team should inspect the document,
and there should be periodic reviews or walkthroughs scheduled throughout the project,
in order to verify that the work is being done according to your design.

One of the most common mistakes that project managers make on outsourced projects is
to blindly trust that the vendor team fully understands and has properly interpreted all of
the design documentation provided. If you do not check in at many points along the way
to make sure that your intentions are being properly interpreted, it’s very likely that you
will end up getting software that technically complies with the specifications but that does
not really meet your needs. This is a very frustrating position for a project manager. How-
ever, by implementing reviews and inspections (see above), you can avoid this problem.
Once you have put in place controls to ensure that the software design meets your organi-
zation’s needs, you then need to ensure that the software is being built well. The tools and
techniques in Chapter 7 are especially helpful here. Require that the team build unit tests
for all code, and that those unit tests are run regularly, with the results of the unit tests

published across the teams. Use an automated project monitoring system to create nightly
builds and run unit tests, and have the results published across teams. Have in-house soft-
ware engineers do spot-check code reviews with vendor team members—preferably using
code samples that were already reviewed by the vendor team. (To some people, it may
seem like a waste of time to review code that has already been reviewed. In fact, it’s espe-
cially helpful, because it allows your team to both verify that the code is being built prop-
erly and to audit the vendor’s code review process.) Use automated code analyzers to
enforce widely accepted coding best practices that may slip through a code review.

Some project managers may be hesitant to get this involved with the way the vendor team
builds the code. It may seem somehow intrusive that you are second-guessing the abilities of
the programmers at the vendor. It’s important not to fall into this trap. Almost every vendor

274 CHAPTER ELEVEN