Software Development, December 1997
Managing Outsourced
Projects
Buy, build, or outsource? It’s the
1990s twist on a classic question. You may not find it in a
hardcover dictionary yet, but outsourcing is part of the
everyday vocabulary of developers around the world. Often it
is intoned to make it sound like a blessing or an epithet,
and it can be either or both.
Outsourcing is looked upon with fond
hope by development managers squeezed between shrinking staff
and mushrooming expectations. It is eyed warily by in- house
developers worried about job security. And, of course, it is
the mother lode paying the salaries of the outsourcing
industry.
Managing and outsourcing are not usually
used in the same sentence, except by the managers at those
contract development firms to which software projects are
outsourced. Managers at other companies, the buyers and
potential buyers of outsourced development, are more likely
to think that you outsource software development in part to
avoid managing it yourself. Once a project is outsourced,
managing it is someone else’s problem. After all,
that’s what you are paying them for, isn’t it?
Steve McConnell thinks otherwise. His
message is simple: outsourced projects require the buyer to
practice good management. You need to manage an outsourced
project at least as well as you manage your in-house
development projects, but there are some added complications.
Fortunately, Steve has already choreographed the basic steps
for you. If you follow them carefully, you and your new
outsourcing partner should be able to finish the dance with
smiles on your faces.
-- Larry Constantine
Some of the greatest software project risks
are associated with projects outsourced to internal or
external vendors. How can you manage outsourced projects
without losing control?
Consider the sad but true case of
Giga-Corp. Its customers were clamoring for the second
version of its popular software product, but it didn’t
have sufficient technical staff to work on the upgrade, and
the manager in charge of the project was already overwhelmed.
Giga-Corp decided to outsource.
It created a 50-page requirements
specification and sent a request for proposal to a dozen
vendors. The request for proposal didn’t include a
budget, but did indicate a strong preference for a fixed
price bid with delivery within five months. After holding a
meeting to answer vendors’ questions, Giga-Corp received
a handful of bids, all for time and materials, ranging from
$300,000 to $1,200,000. The high bid came from Fledgling,
Inc., a startup founded by a former Giga-Corp programmer who
had worked on the first version of the software. Giga-Corp
threw it out, along with the low bid, on the assumption that
those were outliers and probably the result of
misunderstanding the project’s technical requirements.
It selected middle-of-the-pack Mega-Staff and then negotiated
the estimate down to $350,000.
Heading South
The first indisputable hint of trouble came
when Mega-Staff’s head recruiter phoned Fledgling,
Inc.’s president on a Thursday afternoon, sounding
desperate. "We need three C++ programmers by
Monday," he said. "Giga-Corp accepted our bid, but
their senior engineer said our Visual Basic approach
wasn’t technically feasible and we don’t have
enough C++ programmers to support the project."
Fledgling, Inc.’s president said he couldn’t find
three C++ programmers on such short notice, and wished
Mega-Staff’s recruiter good luck.
Somehow, when Monday rolled around,
Mega-Staff showed up at Giga-Corp headquarters with three new
C++ programmers. The Mega-Staff team was enthusiastic and
appeared to make good progress at first, but by the
five-month mark, the team was nowhere close to completion.
Mega-Staff promised delivery within eight months, which was
acceptable to Giga-Corp because that coincided with the
beginning of its next sales year. Eight months into the
project the end was still far from reach, and Giga-Corp
demanded cost concessions for late delivery.
Fourteen months into the project, after
more schedule slips and many painful meetings with Giga-Corp,
Mega-Staff delivered about 25% of the planned functionality
at a cost of approximately $1,500,000. Considering the
functionality underrun, Mega-Staff had essentially overrun
its proposed cost by 1,400% and its proposed schedule by
1,000%.
Battening Down the Hatches
With software outsourcing on the rise, the
Giga-Corp and Mega-Staff disaster is being replayed by
software outsourcing buyers and vendors throughout the world.
These problems could have been avoided if the participants
had understood the basics of the software outsourcing life
cycle.
Effective outsourcing consists of six
steps: specifying the requirements in detail, making an
explicit decision to outsource, obtaining resources,
selecting a vendor, writing the contract, and building an
in-house management team that will monitor the project to
completion. Super large projects—DoD style— will
need more steps, but most business software projects will
benefit from learning the specifics of these basic steps.
Step One: Specify
Requirements in Detail
Because the requirements document often
becomes part of the legal contract between the buyer and
vendor, outsourced projects need high-quality requirements.
If requirements aren’t clearly specified in the
beginning, the project can become a battleground on which all
possible ramifications of the buyer’s and seller’s
different interests are contested. As the case study
illustrates, this is a battle that both parties will lose.
If the organization doing the buying
doesn’t have the in-house resources to create detailed
requirements, it should use a two-phase acquisition. During
the first phase, the buyer outsources development of the
requirements. During the second phase, the buyer puts those
requirements out for bid and then outsources the development
of the software. In general, if an organization doesn’t
have the technical or managerial resources in-house to
perform the necessary tasks for effective outsourcing, it
should have a disinterested third party perform them.
Detailed requirements also form the basis
of the buyer’s effort and schedule estimates. A buyer
who doesn’t create detailed estimates or have them
prepared by a disinterested third party won’t know
whether a $300,000 or a $1,200,000 bid is more realistic.
Step Two: Make an Explicit
Decision to Outsource
The decision to outsource invariably
involves weighing both costs and benefits. Because
outsourcing will increase a project’s risk, you should
make the decision explicitly, with full awareness of
potential problems. Don’t choose to outsource because it
seems to be the easiest option—it rarely seems easy by
the time the project is complete.
Step Three: Obtain
Resources
The buyer must acquire sufficient resources
to complete the project. These resources include budgets for
the proposal phase, vendor payment, and management of the
project on the buyer’s side.
Step Four: Select a Vendor
to Develop the System
Choose a software outsourcing vendor
carefully. The vendor selection process usually entails
creating an request for proposal, distributing it to
potential vendors, and requesting that they submit proposals.
The request for proposal should contain at least the
following materials:
Software requirements specification.
These are the detailed requirements that were developed in
the first step to effective outsourcing.
Statement of work. The statement of
work is a document containing the management requirements for
the project. It specifies your demands regarding managing
changes to requirements, what kinds of tools and development
environments will be used, technical methods and
methodologies, software documentation, engineering data
(design notes, diagrams, scaffolding code, build scripts, and
so on), backup procedures, source code control, quality
assurance procedures, and the project’s management
organization—especially the interaction between your
organization and the vendor.
Documentation list. The request for
proposal should specify the documents you want to have
developed in conjunction with the software. You should
include design documents, source code documentation,
operating manuals, status reports, and any other documents
you want developed.
Cost and schedule estimates. Include
the cost and schedule estimates you prepared during
requirements development. Giga-Corp didn’t know how much
its project should cost or how long it should take, which led
it to hire a vendor incapable of performing the work. If you
don’t publish your cost and schedule estimates in the
request for proposal, the proposal process degenerates into a
game in which each vendor tries to guess your budget.
The divergence among vendor estimates to
Giga-Corp suggests that either the technical requirements
were not developed well enough or that some or all of the
vendors were poor estimators. The fact that the highest bid
was submitted by the company most familiar with the software
was a clear warning. If Giga-Corp didn’t want to choose
the highest bidder, it would have been wise to switch to a
two- phase acquisition approach, using one of the vendors to
develop the requirements more fully, creating new cost and
schedule estimates, and then putting the project out to bid
again.
Evaluation criteria. Tell the
vendors what criteria you will use to evaluate their
proposals. Typical criteria include project management
capability, general technical capability, technical design
approach, technical methodologies, technical documentation,
engineering data management, requirements management
approach, configuration management approach, and quality
assurance approach.
Competent vendors will explain in their
proposals how they plan to meet each of the evaluation
criteria. By publishing evaluation criteria, you make it
easier for yourself to make side-by-side comparisons among
proposals, and you significantly improve the quality of
information that vendors provide.
Proposal preparation guidelines.
Describe how you want the proposals to be organized and
formatted. Include descriptions and page limits for each
section, margin sizes, contents of running headers and
footers, and font size. This might seem overly picky, but
specifying a standard proposal format makes the job of
proposal evaluation easier. Be sure to create a sample
proposal so that you know the page count limits are
reasonable. On larger projects, buyers distribute their
proposal guidelines for review by vendors before they
distribute the official request for proposal. This gives
vendors a chance to comment on the page count, evaluation
criteria, and other issues and generally helps to improve the
quality of information the buyer ultimately obtains through
the proposal process.
Picking the Winner
If you did your homework when you created
the request for proposal, proposal evaluation will be nearly
painless. Create a decision matrix based on the evaluation
criteria described in your request for proposal, and score
each proposal accordingly. Be prepared to follow up with
questions to cover missing or insufficient proposal
responses.
You might eliminate some vendors because of
low scores overall or in specific categories. For example,
you might eliminate any vendor that scores less than 10 out
of 15 points in project management capability. If Mega-Staff
scored only seven points in project management capability, it
would have been eliminated. By publishing explicit evaluation
criteria and scoring proposals based on them, Giga-Corp could
have known that Mega-Staff was critically weak in project
management. Thus, Mega-Staff’s eventual project overrun
would have been predictable—and avoidable—at
proposal time.
As the Giga-Corp case illustrates, the
lowest bid and the final project price are often not related.
The goal of awarding a contract is not to choose the lowest
bid but to choose the vendor that will provide the best
value—do the best job for the least money as judged by
systematic evaluations of the proposals. You can also use the
evaluation criteria for negotiating changes to the winning
vendor’s proposal. For instance, Giga-Corp could have
negotiated changes to requirements management and quality
assurance approaches if those were the weak points in the
winning bid.
Step Five: Write the
Contract
Your warm feelings about your choice of
vendor will quickly evaporate if the project begins to
unravel. Be sure your contract spells out the details of
management requirements, technical requirements, warranties,
patents and other intellectual property issues, contract
termination, payment, and any other important issues.
Don’t try to draw up the contract yourself. You can lose
in court if your contract doesn’t mean what you think it
means, so spend the money to have it reviewed by legal
counsel before you sign it.
Step Six: In-house
Management and Monitoring
The magnitude of Mega-Staff’s overrun
suggests that Giga-Corp essentially didn’t monitor or
control the project after the contract was awarded.
Giga-Corp’s managers might have voluntarily accepted a
100% or 200% cost overrun, but they would have to be trying
to put themselves out of business to knowingly accept an
overrun of 1,400%.
The most common mistake I see in managing
outsourced software development is that no one on the buyer
side manages the outsourced development project at all. While
outsourcing can indeed reduce the amount of management
needed, it increases the degree of management sophistication
needed. The problems involved with managing a project across
the hall are magnified when you have to manage a project
across town or across the globe.
Because you can’t monitor progress on
an outsourced project just by walking around and talking to
project team members, project tracking indicators must be
more formal. In your request for proposal, you should specify
what management controls you want the vendor to provide so
you can track the project’s progress. Such controls
might include:
- Weekly status reports
- Weekly updates to the list of
technical risks
- Weekly defect statistics
- Weekly statistics on the amount of
code added, modified, and deleted
- Weekly reports on the number of
modules planned, number coded, and number that have
passed their code reviews
- Any of many other indicators of
project health.
On small projects, someone from the
buyer’s side must be put in charge of monitoring the
vendor’s progress and sounding an alarm when problems
arise. On large projects, several people from the
buyer’s side might be needed.
Smooth Sailing
These steps might seem like a lot of work
for an outsourced project. As the case study illustrates,
however, the price of not doing your homework can be budget
and schedule overruns of 1,000% or more. The time you spend
laying the groundwork for a successful project and then
steering the project to the desired conclusion is time well
spent. Just ask any project manager who has been drawn by the
siren’s song of easy software to the rocky shores of
unreliable vendors, cost and schedule overruns, functionality
underruns, and failed projects.
About the Author
Steve McConnell is the author of Code
Complete (Microsoft Press, 1993); Rapid Development (Microsoft
Press, 1996); and numerous technical articles. He works as
chief software engineer at Construx Software Builders. His
newest book is Software Project Survival Guide (Microsoft
Press, 1997). You can reach him at stevemcc@construx.com or
through Software Development magazine.
Larry Constantine is the Management
Forum editor. You can reach him at
LConstantine@compuserve.com or through Software
Development magazine.
