11 Steps to Successful Outsourcing: A Contrarian's View

By Johanna Rothman

Computerworld |

During the past few years, we've been bombarded with news of outsourced call centers, help desks, testing, development, projects and entire IT infrastructures. It sure looks as if outsourcing is the way to go.

Before you jump on the outsourcing bandwagon, ask yourself this question: What's the value of the knowledge your staffers learn in the work you're planning to outsource? That's the value you give up when you outsource.

We have a history of looking for ways to bring down the cost of development. In the '70s, we moved to chief architect teams or other hierarchical teams a la Fred Brooks' Mythical Man-Month. In the '80s, we had structured analysis and design, followed by numerous computer-aided software engineering tools. In the '90s, we had object-oriented programming (with inheritance, wouldn't we get reuse for free?), components and more reuse. And let's not forget the mother of all productivity enhancers -- process. All of these techniques can lower the cost of product development.

But what's happened? Every project seems to require more developers, more testers, more project managers, more requirements analysts, more process people and more managers. And with all those extra people, we still haven't figured out how to complete enough projects on time and within budget.

There are reasons for needing more people, but in my experience, there are four big reasons for requiring more people for every project: poor management, technical debt, architectures that can no longer be extended and more complex systems.


	Johanna Rothman consults on managing high-tech product development, focusing on project management, risk management and people management. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.

Poor Management

I bet you know managers who regularly assign more than one No. 1 priority and more than one project to their staffs, expecting that somehow one brain can work on more than one problem at a time. We have more than our fair share of managers who arbitrarily cut schedules, refocus the project in the middle of the project and ignore obstacles. Poor managers dramatically increase the cost of development.

Technical Debt

If you've cut corners on previous releases in the past, you've incurred technical debt. Technical debt is work you owe the product. If you didn't completely design it or test it, you owe the product the work you haven't done yet. You pay interest on technical debt, the same as on money debt. The longer you wait to properly design, code or test the product, the more it costs -- in time and/or money -- to release the next time. Technical debt requires more people per project to overcome, even for similar amounts of work.

Nonextensible architectures

Even if you have no technical debt in a product, at some point, every architecture meets the end of its extensibility. When the additional requirements outstrip the ability of the architecture to add those requirements, you're stuck with a nonextensible architecture. No matter how you try to shoehorn in more features, the features don't easily fit. If you try to shoehorn more features into the system, the system becomes more complex. The more complex the system, the more time people need to learn their parts of the system and the more people are needed to reduce overall project time -- which increases the communication complexity of the project.

More complex systems

We developed the easy systems long ago. Systems today are more complex than the most complex systems of even just 10 years ago. The more complex a system, the longer it takes to complete the work for a given release. When you use agile techniques or incremental life cycles, you can reduce the time per iteration, but you still require more time to complete what the stakeholders see as the entire system.

Software project costs are primarily labor

No matter which of these problems you have, the bulk of a software project's cost is labor. The more problems you have, the higher your labor costs. From a senior executive's view, it makes sense to cut salaries through outsourcing. Instead of paying a U.S. developer a $100,000 salary (loaded labor including overhead), you can pay a Canadian developer the equivalent of $50,000 or an Indian developer $15,000 or even less. Huge difference.

Some executives believe that even if you need four times as many people, you can still do the job cheaper and faster (because of the round-the-clock project team) than you can if you keep the work in the U.S.

In my experience, every outsourced project has taken longer and costs more than the original estimates. Remember, you're training these external people on your product domain.

If you must ...

But if you think offshore outsourcing may work for you, then make sure you remember these points.

Train the outsourcing staff. The outsourcing staff needs to know how the product works, both from the internals and from the perspective of knowing the problems the customer wants to solve.
Qualify the vendor. Does the vendor have domain knowledge? Is it financially viable? Are there contractual safeguards in place to keep control over the intellectual property you give it?
Assign one of your best project managers as your internal project manager. Just because there's a project manager at the outsourcer doesn't mean you don't need someone in your office making sure all the appropriate handoffs are happening.
Plan for your in-house staff to shift their work hours. If you don't shift enough people to work earlier or later in the day, then someone across the world who has a problem won't have someone to talk to. Too often, when an engineer at least eight time zones away needs information, no one is in the office and no one can be reached. Instead of round-the-clock work, the work is stopped until the engineer can determine the answer.
Document the requirements. If your native technical staff can't read your mind about what you want in the product, how can geographically distant, non-native English speakers understand your requirements?
Develop an appropriate change process. Especially if you have development occurring in multiple sites around the world, you need a clear change process to make sure only the changes you want are allowed.
Select outsource projects with nonvolatile requirements. If your requirements change frequently and you need to check out the evolving product with the user, development across the world makes it that much harder.
Plan for each project to take longer and cost more, especially at the beginning of an outsourcing relationship. My rule of thumb is to increase the estimated time by 30% for the first project. Then monitor the project to see if you need to increase that estimate.
Insist that the outsourcing company keep the same team for your project's duration. Otherwise, the time you spent training their people is wasted and you'll have to start the training process again.
Make sure you have the tools, information systems and processes in placeto support the outsourced teams. They'll need access to the source code, defect tracking system, database or other platform applications, builds, etc. -- the same project tools that the internal teams need.
Verify that the people who said they'd be working on the project are the ones actually working on the project. U.S. firms have been using the bait-and-switch approach to contracting for years. Senior staff sell the project and then proceed to the next potential sucker -- er, client -- while new college grads and other underexperienced staff work on your project. Well, guess what? The non-U.S. outsourcing firms have learned the same technique. If you don't verify who's working on your project, your project could be the learning ground for their staff to build their resumes.

If you don't already create project environments like this, do you know what you'll have to change to manage a successful outsourcing relationship?

But ...

Outsourcing works because the work is now being completed under contract. If you treated your development staff as if they were under contract and avoided the poor management practices mentioned above, you might be able to keep the work in-house.

Managers can't easily change the focus of the outsourcer's technical staff or change the technical staff's processes and practices. So if the outsourcing vendor has a working process for product development, you will receive the benefit of that process.

And ...

Any software project worth doing is worth funding appropriately, whether you fund it for internal or external development. Remember, the cost of outsourcing is higher than the actual project cost. Some of the intangible costs are increased training, giving away your product domain expertise and lowered morale.

Of course ...

If you choose commodity projects, projects where the technical staff doesn't have to learn a lot upfront about the project and the product, outsourcing can work for you. But if you're thinking of outsourcing all your technology, you're not making technology a differentiator in your business. I honestly don't see how a company that uses technology as a key piece of its business can stay competitive and outsource all its technology initiatives. Of course, if you have terrible management, outsourcing your management makes sense!

If you have some legacy-product projects, or if the projects you need completed aren't core to your business, then it won't matter if you outsource them. Whatever your in-house staff could learn from the projects isn't enough to matter to your future success.

Finally...

Remember, every time you outsource a project, you're giving away part of your assets to the outsourcer, the intellectual capital that your technical staff learns every time they complete a project. Eventually, these outsourcers will know your business better than you do. And when that happens, the company's management and then the company won't be needed anymore. The outsourcers will take over your industry.

If you need to bring down the cost of your projects, certainly consider outsourcing. Just remember that it's not a free lunch, and you will have significant start-up time, training investment and probably some delays on your initial projects while the outsourcers learn your business. And make sure to outsource commodity work, not work that advances the state of your business.

Offshore Buyer's Guide

Stories in this report:

Outsourcing

It’s time to break the ChatGPT habit