Managing Outsourced Projects

 Issue: December 1997

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.

Author: Steve McConnell, Construx Software  |  More articles