Outsourcing Gone Bad - Another Reason to Consider Agile

by Deborah Hartmann Preuss on Jul 05, 2006 |

Lawsuits, recriminations, millions squandered on failed projects--and outsourcing is supposed to be a good thing for businesses?

IntelligentEnterprise.com has run a long InformationWeek article by Paul McDougall entitled: In Depth: When Outsourcing Goes Bad. In it, McDougall reports on the recent InformationWeek Research survey on the subject of IT Outsourcing.

50% of companies rate their outsourcing efforts a success, a third are neutral, and 17% - nearly one in six - call them disasters. For those in the latter category, primary reasons for dissatisfaction include:

poor customer service, vendor responsiveness or flexibility (45%)
hidden vendor costs
insufficient up-front planning by our company

Another InformationWeek article reports the prime motivator for outsourcing is, of course: cutting costs, among others. McDougall's article, however, tells how Sprint, while planning to save $2M by outsourcing to IBM, instead ended up accusing IBM in court of failing to achieve the promised productivity improvements. In another example, Sears Holdings, the corporate parent of retailers Sears and Kmart, and Computer Sciences Corp. are still locked in a legal battle to settle the status of a 10-year, $1.6 billion IT services contract that Sears walked away from in early 2005, after just one year.

For those suddenly interested to hear more about Agile software development, a good place to start is the Articles Library of the Agile Alliance which is organized by topic.

Related Editorial

Agile Executive Primer: Partnering Across the Organization

How do you Develop a Shared Understanding on an Agile project?

Application Performance Management Buyer's Guide

Continuous Delivery: A Maturity Assessment Model

How do you estimate on an Agile project?

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Orthogonal concepts by Michael Burke Posted

Re: Orthogonal concepts by Deborah Hartmann Posted

am I wrong? by Alex Popescu Posted

Re: am I wrong? by Deborah Hartmann Posted

Orthogonal concepts by Michael Burke

I fail to see the connection between failed outsourcing and agile methods. An outsourced development shop can still use an agile or traditional development methodology - doesn't change the fact that they are still outsourced.

"A new study has found that cheeseburgers contain 27% more fat than regular burgers. Perhaps it's time to consider Agile methods.."

am I wrong? by Alex Popescu

Am I wrong if I believe that the percentage of successful outsourced projects is bigger than succesful in-house projects? (cause I think I remember some data saying that only 1 in 6 in-house projects are successful, so according to this data it means 3 times more outsourced projects are successful than in-house) :-).

./alex
--
.w( the_mindstorm )p.

Re: Orthogonal concepts by Deborah Hartmann

I was addressing the practice of cutting or reducing internal development, *replacing* it with outsourcing. In that case, some teams ask for a reprieve (to try Agile methods), in an attempt to give management the productivity increase they seek without resorting to outsourcing.

Apparently, I didn't get that across :-)

You are right in saying that this item doesn't in any way address use of Agile *with* outsourcing.

Re: am I wrong? by Deborah Hartmann

The gist of what you say sounds right (I'll look up the stats for you later, you're referring to the Standish Chaos Report stats, I believe). However, I'm not sure that the two are comparable... I'll get back to you.

Re: am I wrong? by Deborah Hartmann

Here are the original Standish Group 1994 stats (and 2000 stats in brackets): Success rate was only 16% (28%), while challenged projects accounted for 53% (49%), and impaired (canceled) for 31% (23%). For "challenged" projects - projects which were, in fact delivered - on average, only 61% of originally specified features and functions were delivered, and 86% had >20% time overrun. (I don't know the 2000 stat for this)

I'm not sure we can compare these stats against the mentioned outsourcing stats, which don't indicate quality of deliverables or timeliness, only cost savings achieved.

In addition, Standish identified success criteria based on the study. I suspect that the absence of these factors would equally cripple outsourced and insourced projects.

Points / Success Criteria
19 / User Involvement
16 / Executive Management Support
15 / Clear Statement of Requirements
11 / Proper Planning
10 / Realistic Expectations
29 / other factors (see the site)
100 total point

Here are some recent stats: A new Gantthead.com article To Insource or Outsource IT notes:

In almost every conversation I have had with executives as to why they are pursuing outsourcing, the focus has been more on cost savings than on anything else. Unfortunately more times than not the results have been dismal as they fail to appreciate the complexities, intricacies and energies needed to manage the process.

Nonetheless, the same article goes on to say:

In a recent study on outsourcing, IBM claims that companies that engage in IT outsourcing have shown 11.8 percent higher growth in earnings, 9.9 percent lower expenses and 8.6 percent higher return on assets than their competition.

This suggests to me that (if quality doesn't suffer) it pays, but it's messy: worthwhile when the cost-cutting aspect far outweighs other considerations. But one wonders what the personal cost was for those doing the firefighting - which too often comes out of the home-life bottom-line, and doesn't show up in corporate accounting.

I suspect that for some industries it's more suitable, hence more beneficial, than for others.

Re: am I wrong? by Deborah Hartmann

PS: note that, given the dates of the Standish stats, the projects measured used traditional, not Agile development processes. Again, making it harder to apply these figures to our discussion here.