4 Outsourcing Mistakes Companies Still Make

Control freaks, blame games, and other misguided attempts at building a better business through IT outsourcing.

There's still no script for the Great American IT outsourcing project. But today's most common outsourcing pitfalls have less to do with technology and everything to do with relationships and communication. Or lack thereof.

"Both companies have to rise to the occasion to make it work," says Romi Mahajan, president of marketing consulting firm, the KKM Group, which outsources some of its IT operations.

Nevertheless, communication breakdowns and finger pointing frequently derail even the best-laid outsourcing plans. Here are four missteps to avoid.

1. You play the blame gameWhether onshoring in Kansas City or offshoring in India, outsourcing is a relationship. If communication is poor or scarce and blame is passed around, you won't form a lasting business relationship.

Mahajan notes that complex projects, such as a CRM implementation, can run into big trouble over a minor technical glitch or a miscommunication between people.

"The customer blames the offshore company for overpromising, and a routine issue then becomes a mountain of a problem," he says. "I see this kind of 'us versus them' thinking a lot. It delays projects for months."

2. You focus on pay rates over resultsCompanies outsourcing IT resources often fixate on getting the lowest hourly rate without seeing the big picture, says Forrester principal analyst Liz Herbert. They should always ask: What is the overall pyramid -- are we getting low rates but a huge team?

Outsourcer A, for example, could have rates of $100 per hour, but staff the project with lots and lots of junior, offshore talent with limited experience. Outsourcer B could have rates of $200 per hour, and staff the project with one-third the number of workers as Outsourcer A but use more experienced people.

3. You're a control freakCompanies should be careful not to micromanage. The whole point of choosing an outsourcer is for IT skills and expertise, but too many companies squash efficiencies by over-dictating how a project should run, says Herbert.

For instance, a company contracts with an outsourcer for SAP support on systems used to run a manufacturing plant. The real goal of the project is to improve plant output. However, if the company micromanages the specific technologies and SLAs, it'll lose out on the outsourcer bringing in its own ideas to help reach the real business goal: plant production.

Outsourcing pricing models commonly use the concept of full-time equivalents (FTEs), which measures how many full-time workers are needed to perform tasks. But Herbert says Forrester research shows that if a company moves from an FTE-based approach to one where the outsourcer manages the resources according to what it thinks is best throughout the project, the client can save 20% to 30% in most cases.

"The client rarely has the right expertise to know exactly what mix and how many FTEs they need -- and, of course, this changes over time."

And having SLAs that are not aligned with business goals can lead to troubling scenarios where the outsourcer is technically achieving all the SLAs but the client is not getting business results. "It's a case of 'all the SLAs are green' but our business goal is red," says Herbert.

4. You think you can outsource your whole brainHowever, there's a danger in straying too far from the control freak. Mahajan says too many companies think their job is done just because they've signed an outsourcing contract -- they assume the outsourcer is a mind reader and give it too much leeway.

"It's almost impossible to convey 100% the desired outcome of an IT outsourcing project," says Mahajan. "Only the company knows exactly what it wants to achieve. Don't think the outsourcer will do all the thinking for you."

Business goals can be moving targets, and if companies don't keep explaining those goals throughout the process, the relationship will sour fast.

The mistake of "outsourcing your brain" can signal poor planning as well as leadership problems within the company, says Michele Chubirka, senior security architect at Packet Pushers, a popular podcast for networking pros.

"If you're not dealing with your own conflicts between IT and the business, outsourcing will not fix them," Chubirka says. "An outsourcer should always provide expertise that you don't have in-house -- period."

(Chubirka will also be on the Interop New York panel with Mahajan.)

Indian outsourcer Advaiya (where Mahajan serves as an advisor) dealt with such a conundrum when it developed an entire technical framework for several hundreds of thousands of dollars for a well-known tech vendor. The vendor decided it didn't want to use the framework but didn't communicate that to Advaiya.

"We did all this work and the vendor didn't want to pay at the end, but they didn't update our team along the way," Mahajan says. "We were working in a vacuum."

In its ninth year, Interop New York (Sept. 29 to Oct. 3) is the premier event for the Northeast IT market. Strongly represented vertical industries include financial services, government, and education. Join more than 5,000 attendees to learn about IT leadership, cloud, collaboration, infrastructure, mobility, risk management and security, and SDN, as well as explore 125 exhibitors' offerings. Register with Discount Code MPIWK to save $200 off Total Access & Conference Passes.

Shane O'Neill is Managing Editor for InformationWeek. Prior to joining InformationWeek, he served in various roles at CIO.com, most notably as assistant managing editor and senior writer covering Microsoft. He has also been an editor and writer at eWeek and TechTarget. ... View Full Bio

That's a pretty blanket statement on "coders". There are quite a few of us out here who do the whole package. And funny thing, we tend not to outsource. It's only when you get a bunch of "architects" who can't produce a working product that a company starts looking outside itself. I'm assuming you work for a big company, where teams are so big no one can take a project from the user's mouth to have working code that does what it supposed to.

That is certainly no knock on you, not my intention here to insult you. I'm sure you are correct in all you said. But when you go from a complex communication path internally (architects to coders) it makes it pretty easy for mgmt to move the coding outside. And then you have added a bunch of coders who care about THEIR company and job, not yours. So the CYA factor during communication goes way up, that is your increase in lead time.

The core premise of Agile methodology is flat structure. If the guy getting requirements from users is same guy writing code, you can iterate to what users want pretty quickly. When dealing with large internal teams using waterfall, or outsourcers, what you talk about is a fact of life.

Again, not trying to insult you, but outsourcing probably works best when people like you don't exist. Let the outsourcer handle it (design thru code) and hold them responsible for working systems. If you have the expertise to define the application that thoroughly like you do, just write the code internally so you are in control. And accountable.

Ms. Laurianne, when we deliver documents which EXPLICITLY define data/database design standards & expectations from the request for quote to final acceptance -- the entire lifecycle of the project -- & have built a validation tool to ensure those standards are met, the problem then lies COMPLETELY with the outsource vendor. In effect, the vendor is telling US what standards s/he is going to comply with & which we may not-so-politely stuff in our ears -- regardless, the vendor expects to be paid for an unfinished, non-compliant deliverable. We refuse to accept the product, the vendor begins whining, & the real fun begins.

My point: In the couple of years my company has been outsourcing application development projects, it has been the outsource vendor as the source of 90% of insufficient communication, conflict, & tension. The implementation time required to get the outsource project functional has increased from 6 to 10 hours to 2 to 6 weeks -- a good bit of the added time showing the vendor where IF our standards had been complied with in the first place, the issues encountered would never occurred. The vendors know LONG before implementation -- because we provide the findings reports from our validation tool -- their deliverable is out of compliance; there's no last minute 'gotcha!'.

They don't want to comply with data/database design standards because the coding tools they use are constructed for optimized CODE. From that code, a database is, basically, reverse-engineered. They're coders -- that's what they do & they're good at it. I remember back in the Dark Ages when coders did everything from gather the requirements to write the programs to design the databases to implement the whole kit-&-kaboodle. I remember because I was one.

Coders are a lot like race horses: They're blindered so they can only see what's directly ahead of them. That's what makes a good coder. See problem, fix problem, next problem.

Architects have to see the entire race track -- taking the analogy further. As a matter of fact, we also have to see the stands, offices, parking lots, etc. We HAVE to keep a handle on how the "everything" fits together. Design standards enable us to do that more effectively & efficiently.

The other 10% of all project issues usually belongs to users changing their minds after development has begun. But that is an entirely different herd of ponies.

I agree. If a company isn't clear with the outsource companies about its own goals and objectives they won't able to solve their problem. I noticed that too that relying on a single factor(cost) it narrow the view by not taking into account the other factor which can impact while working with an outsource company as you have point it out.

"If you're not dealing with your own conflicts between IT and the business, outsourcing will not fix them." This is an important point that Michelle raises. If anything, the tensions can get worse when business expectations are not met and IT shifts the blame to the outsourcer.

Shane, In terms of item #2, cost vs. quality. Is the answer to price per job vs. per hour? Say, $5,000 for [complete job] with additions only if the customer expands the scope. That way if the outsourcer takes longer than it estimated, that doesn't hit IT's budget.

Sounds like there are some strange ideas floating around that you are trying to resist. Stand your ground, because you are 100% right!

Standards and sensible design are super important for the database. If the database is screwy, anything built on it will be screwy too. IMO, database design is the place where you get the best and brightest you have and let them do it right, not something to be sent out of the shop to the lowest bidder.

. . . we've been accused both repeatedly & vehemently. Not in relation to managing the project, but in data & database design standards we REQUIRE for these deliverables.

Amazing that coders have no issues -- either verbally or in practice -- incorporating CODING standards into the final deliverable, but data/database design standards are just too onerous & time-wasting. Definitions!? We don't need to stinkin' definitions documented for the project.

Whether the disconnect results from a communication problem, a philosophical difference in design/construction methodologies, or a money-manhour issue for the outsource developer, getting the job "done" includes documentation & compliance with pre-determined company standards. Otherwise, you shouldn't be paid . . . period.