Your CIO just summoned you to duty by handing off the decision-making power about whether to outsource next year’s big development project to rewrite the internal billing system. That’s quite a daunting task! How can you possibly begin to decide if outsourcing is the right option for your company?
There are a few strategies that you can follow to help you avoid the pitfalls of outsourcing and make informed decisions. Outsourcing is not exclusively a technical issue, but it is a decision that architects or development managers are often best qualified to make because they are in the best position to know what technologies make sense to keep in-house. Deciding what should and should not be outsourced is key to a successful game plan.
Before we get into the strategies and pitfalls, here’s a little bit of background about outsourcing. There are two types: onshore outsourcing is obtaining services outside the company, but within the same country; offshore outsourcing is obtaining services not only outside the company but also outside the country.
More hoopla of course has been raised about offshore outsourcing than onshore. The argument in the United States is that “offshoring” has a negative impact on the economy. Why is the software industry turning to outsourcing—both offshore and onshore? Many believe that the software industry is an immature industry going through growing pains that any mature industry has already experienced. The auto industry, for example, in the 1960s was going through exactly what the software industry is going through in the 2000s: learning how to specialize and fragment to reduce costs, improve quality, and accelerate production.
Such growth happens over time. Herein lies the myth of outsourcing. It is usually viewed and implemented as a short-term money-saving maneuver, when it actually should be part of a long-term strategy—not a quick fix to save a few bucks.
In a recent study on outsourcing in the software industry, some of the findings reinforced that the immediate consequences of outsourcing are of negative influence to the U.S. economy. In the long run, however, we are actually seeing that outsourcing has a positive influence on American businesses, the employment rate, and the economy. The study was conducted by Global Insight on behalf of the Information Technology Association of America (ITAA), a group that consists of 375 corporate members (including Microsoft and IBM). ITAA released a report on the study, which is based on research and forecasts conducted and calculated by Global Insight’s chief economist, Dr. Nariman Behravesh, and his research team (The Impact of Offshore IT Software and Services Outsourcing on the U.S. Economy and the IT Industry; http://www.itaa.org/itserv/docs/execsumm.pdf).
Ultimately, what matters to you is to implement a successful project and contribute to the success of your company. Is outsourcing a wise move for you? It’s definitely not a maneuver that you want to make blindly. Analysis and strategy are involved from the moment you begin to even consider outsourcing until the moment your project is finished and delivered.
If you approach and implement outsourcing incorrectly, the effects are not pretty—not only can you jeopardize your position, but you can put the jobs of your co-workers in peril, as well. Those are extreme consequences. When outsourcing projects fail, however, people within your company end up doing the work that the outsourcer failed to do correctly—or even do at all. Other consequences of a failed outsourcing project include an increase in the cost and production time of your project—exactly what you do not want to accomplish. A failed outsourcing project creates unnecessary havoc and fails to offer any benefits at all to the company. To launch a successful outsourcing project, here are some strategies you might consider:
• Determine the main focus of your company. You can outsource anything that is immaterial to that focal point.
• Analyze, focusing on increases in quality and production.
• Concentrate your efforts and the efforts of your team on the focal point of the company.
• Establish and maintain long-term relationships with vendors that specialize.
• Increase productivity and reduce costs through higher quality.
Let’s take a closer look at each of these areas and the challenges they present.
The very first action you should take is to determine your company’s main focus. What exactly is the core of the business? You can figure that out by answering these questions:
• What is the competitive advantage of the company?
• What is the company really in business for?
• What is the company trying to accomplish?
Determining the focal point is important because you want to focus your energies and those of your team on any projects that are related and contribute in any way to that main focus. The only projects you should even think about outsourcing should have nothing to do with the main focus of the company (And, of course, make sure your perception of company focus is the one senior management has!).
Challenges
There can be a lot of distractions, as well as politics, when it comes to determining a focal point. People will come up with all sorts of reasons why their project should or should not be outsourced. My advice is to look beyond the interests of individual project managers, who typically fall into one of two categories: (1) those who want to hold on to projects; and (2) those who want to get rid of projects. The difficulty is trying to see through what project managers are saying to why they’re saying it.
Some project managers will never let go of projects. Their reasons are typically based on fear. They want to keep the empires they’ve built. Maybe they’re afraid of losing their influence. Some project managers might hold on to protect their employees, whereas others might attempt to protect their own careers.
Then there’s the other side of the coin. Some project managers who know that their projects are in danger might try to get rid of them so they don’t jeopardize their careers. They might also want to get rid of uninteresting projects, projects that are in trouble, projects they don’t know how to solve, and so on. Instead, they would rather make it another person’s problem. Watch out for that. In fact, it’s possible that a project manager wants to outsource a hot project that could potentially be key to the future success of the company—simply because the manager doesn’t know how to do it.
After you figure out what your company is really in business to produce, it’s important to evaluate and analyze the production of any projects you are thinking about outsourcing. To determine whether outsourcing is the most viable option, you need to answer these questions:
• Do I really need to build the part myself?
• Can I get somebody else to build it for me more efficiently?
Challenges
It’s important to take a very critical look at the resources in your company. If you ask engineers whether they can build a certain part, they always answer yes. That’s how we engineers are. A better question is, “Why is the part critical to my business?” In other words, “Do we have enough insight and know-how in-house to do this more effectively than somebody else?”
Let’s say you can find a group within the company to build the part. Next, you find out the cost and the deadline. You discover that this group can build the part efficiently. If that is the case, you need to uncover whether the project is critical to your business right now. If it’s not critical now, there’s got to be a reason why this part is going to be critical for the business later. Otherwise, there’s no reason to do it internally. It may be advantageous to use somebody else’s knowledge to build it rather than using up internal resources.
Of course, if and when you decide to go outside company walls, be careful. Outsourcers are not going to tell you that they are going to do a shoddy job. Do your homework and find out whether they have real knowledge about building the part.
Specializing
With the focal point of your company in mind, you can really begin to concentrate the efforts of your team. You want your team members to focus their time on becoming better in the specialty of the business. Doing so increases the value of your team and their contribution to the primary intellectual property of the business.
Any projects that aren’t key to the focal point of your business can potentially reduce costs and increase production if outsourced. Let those who specialize in that area concentrate their efforts there for you—focus your efforts on the areas in which you specialize. You’ll likely end up with a higher-quality part than you could have produced on your own, in less time. As a result, your team will be freed up to concentrate efforts on increasing the quality and productivity of the work you keep in-house.
Do not be lured by “potential” cost savings, especially if the part you’re talking about is a core competency. Unfortunately, most outsourcing projects occur merely because of the price tag, without further analysis.
Often, managers focus on price when they are not certain how to improve productivity. Do not reach out and take hold of something just because the price is right. The price might be the only thing that’s right.
Challenges
People are afraid of specialization because it narrows skills. It can make you much more valuable, but if your field disappears, then you are useless. Many people sense this subconsciously—especially architects and developers. They are afraid to be locked into a narrow specialization because they know one day it will be difficult to find a job or expand their careers.
This is a tough problem, and there’s no magic bullet. Convincing your team that specialization will be good for their careers won’t be easy. Being part of a successful development team and a successful company is good for everyone, however, and specializing can be a key part to long-term success.
If you determine that outsourcing your project is a wise move and will benefit your company, your next challenge is to establish and maintain good, long-term business relationships. More specifically, once you know the focus of your company and determine exactly what your team should and should not concentrate its efforts on, your next move is to find the right outsourcer, a subcontractor with whom you can cultivate a healthy working alliance that will last. This is critical. Without it, your outsourcing project will not be successful.
Consider these important points during your search:
• Personal relationships. Is it beneficial to have the subcontractor next door so that you can build strong relationships among team members?
• Geographic location. Does it even matter? Is geographic location something you need to think about?
• Culture. If geographic location does not matter, what about culture? Is it important that you stay within the same culture, or can you step outside of the culture?
Of course, one of the most important requirements is quality. If you remember nothing else from this article, remember this: You can greatly improve the quality of your final project when you develop a healthy working relationship with a company that specializes in a part that you need but is inconsequential to the focal point of your company. Because both you and your outsourcing partners are focusing more time on your respective specialties, quality increases.
Then, of course, there’s price—an important decision point, though clearly not the only one. If you make your decision based solely on the price and don’t get the results you want, the minimum price could become the maximum price: if your team (or anyone else in the company) has to rewrite the code after the subcontractor delivers it, you have failed.
Challenges
People are often afraid to set tough guidelines with their outsourcing partner upfront. They fear it’s not nice, or think it is intrusive or aggressive. Such thinking can set partnerships up for failure. Good relations are tough relations. In good relations, everybody gets something out of it. If it’s too biased in one direction, or based on the inability of one side to be asking tough questions about timing, costs, and requirements, the partnership is going to fall apart. For example, if you think you signed a contract that is much to your advantage, you can count on the fact that this relation won’t last very long—when the outsourcing team figures it out, it probably won’t be inclined to go that extra mile for you. A real relation means that both parties are doing something together and everybody benefits.
Now, we finally get to the costs. The first fallacy we have in the software industry is that the only way to reduce production costs is to hire cheaper labor. This thought has short legs. At the moment, we can go round and round the world to obtain cheaper labor. We can go to India, China, soon it will be Africa, and then where will we go?
Nobody knows how long it will take us to go through this cycle. It could be 30 years. Eventually, it will come full circle. In the end, what matters most and what needs to change is an increase in productivity.
One of the main difficulties with increasing productivity is that developers spend most of their time—80 percent of it—looking for and fixing bugs. While this problem is sure not to go away any time soon, everyone can agree that if we can prevent bugs, then we can all increase our productivity, and thus reduce our costs.
Challenges
The belief factor is a big problem when it comes to implementing bug-reducing methodologies. Nobody really believes that productivity will increase until they actually see a reduction in errors. To convince your team that it needs to prevent bugs, rather than fix them later, consider gathering your best developers to implement an agreed-upon methodology. If you can show (or even document) that fewer bugs beforehand means less coding time in the long run (and you have to include all that after-the-build bug fixing in your analysis), you’ll likely see a number of agreeing smiles on your team.
So, now that you’ve had a chance to think through outsourcing a project using the five key strategies, what’s next? Even the best-planned outsourcing project is bound to face challenges. A good game plan can still be thwarted if your outsourcer drops the ball. Make sure to keep the following all-too-common outsourcing pitfalls in mind once you finish your planning and embark upon your outsourcing project.
Outsourcer didn’t work on your code. It is not rare for an outsourced developer to overbook projects, as any contractor would. When outsourced developers do this, they end up scrambling to catch up and ultimately do not deliver code on time. If the reason for not delivering code on time is not overbooking, the situation could be that the outsourcer has remained idle for too long or is working at too slow of a pace.
Outsourcer doesn’t understand what you want. In other words, the outsourced developers do not understand your requirements. They say they do, but they don’t. In the end, they think that they have done a good job for you, but what they have actually done is write something that you do not want.
Outsourcer doesn’t write code that is up to your standards. The repercussions of this problem are that you end up with code that is buggy, inflexible, and does not easily integrate with what you already have.
Each of these problems can trickle down and cause problems back home once your outsourced project is under way—symptoms you’ll need to address quickly if your CIO is to keep his or her cool.
There are many elements to consider and factor into your own scenario when you devise an outsourcing game plan. First, think about the consequences and benefits; think about those areas of code that are key to your organization and those that can easily be handed off. Next, develop strong relationships with your outsourcing partners, and make sure the lines of communication are open between outsourcer and outsourcing—in both directions. Last, take preventive measures to ensure that outsourcing problems cannot even begin to fester. Q
LOVE IT, HATE IT? LET US KNOW
[email protected] or www.acmqueue.com/forums
ADAM KOLAWA, [email protected], is the chairman and CEO of Parasoft, which he cofounded with a group of fellow CalTech graduate students in 1987. He is a well-known writer and speaker on industry issues and in 2001 was awarded the Los Angeles Ernst & Young Entrepreneur of the Year Award in the software category. He holds a Ph.D. in theoretical physics.
© 2004 ACM 1542-7730/04/1100 $5.00
Originally published in Queue vol. 2, no. 8—
Comment on this article in the ACM Digital Library
Martin Kleppmann, Alastair R. Beresford, Boerge Svingen - Online Event Processing
Support for distributed transactions across heterogeneous storage technologies is either nonexistent or suffers from poor operational and performance characteristics. In contrast, OLEP is increasingly used to provide good performance and strong consistency guarantees in such settings. In data systems it is very common for logs to be used as internal implementation details. The OLEP approach is different: it uses event logs, rather than transactions, as the primary application programming model for data management. Traditional databases are still used, but their writes come from a log rather than directly from the application. The use of OLEP is not simply pragmatism on the part of developers, but rather it offers a number of advantages.
Andrew Leung, Andrew Spyker, Tim Bozarth - Titus: Introducing Containers to the Netflix Cloud
We believe our approach has enabled Netflix to quickly adopt and benefit from containers. Though the details may be Netflix-specific, the approach of providing low-friction container adoption by integrating with existing infrastructure and working with the right early adopters can be a successful strategy for any organization looking to adopt containers.
Marius Eriksen - Functional at Scale
Modern server software is demanding to develop and operate: it must be available at all times and in all locations; it must reply within milliseconds to user requests; it must respond quickly to capacity demands; it must process a lot of data and even more traffic; it must adapt quickly to changing product needs; and in many cases it must accommodate a large engineering organization, its many engineers the proverbial cooks in a big, messy kitchen.
Caitie McCaffrey - The Verification of a Distributed System
Leslie Lamport, known for his seminal work in distributed systems, famously said, "A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable." Given this bleak outlook and the large set of possible failures, how do you even begin to verify and validate that the distributed systems you build are doing the right thing?