Tag Results

September 6, 2006

Recently, a client of mine who is a senior VP of software development told me, “My CFO declared that fully one-third of our work should be in India within the next two years.” For me, it wasn’t that the directive was about outsourcing to India that was shocking. What caught my attention was that the mandate was coming from the head of finance, the CFO. The top bean counter was the one directing this decision, not the head of engineering.

In some corporations, outsourcing can be about gaining access to skilled labor in a global economy, but in many others, it’s still about cost cutting. That’s why decisions on offshoring might come from a CFO. I can understand this reasoning in the midst of a recession but, I thought, the economy’s been growing.

Most of the companies I’m consulting for on large-scale software projects are offshoring in some fashion to take advantage of cheaper labor rates. At the last Cutter Summit conference, about half of the delegates said their projects were about cutting costs, while the other half of the projects represented were about increasing revenue. In some cases, both goals can coexist — when new products that increase revenue are built using lower-cost offshore labor. And yet, I can’t help but think of a scene from the movie “The Right Stuff,” when one of the early astronauts — waiting to be launched into orbit on what was basically a modified missile — bemoaned the fact that they were about to be blasted into space on a machine built by the lowest bidder.

Are companies achieving lower costs on offshore projects? To answer this and several other questions, my colleagues and I at Quantitative Software Management (QSM) examined the time-to-market, effort/cost, and quality profiles of some recent offshore and US-based software projects contained in our industry database. We discovered the following trends associated with offshore projects:

They generally demonstrated higher productivity compared to US projects.

They tended to be staffed with larger teams in response to tight deadlines.

Given these two primary characteristics, they achieved faster schedules.

However, they exhibited nearly 2.8x higher defects.

When factoring in the added time and effort to resolve these higher defects, the cost was nearly the same as US projects, which eroded the advantage of lower labor rates.

The schedule advantage was cut in half due to the extra time needed to resolve the higher defects.

Given these trends, I recommend that US managers and their companies consider the following strategies when electing an offshore option:

Resist the urge to rush the code: On many offshore projects, there’s a high degree of parallelism between the requirements and the build/code/test phase. One metaphor to consider is house building: imagine what would happen if an architectural blueprint were incomplete yet the contractor rushed in to pour cement for the foundation and erect the walls. Many offshore teams try to compress time this way, only to have to rework the code.

Don’t ramp up too fast: The relative availability of lower-cost resources tends to result in offshore staff piling onto the project early, to get a jump on the schedule. Since data shows that defects on software projects tend to rise geometrically with the square of the team size, large-staffed projects experience higher — not lower defects — as a result.

Make sure you have enough testers: Many projects that ramp up too fast show a premature ramp down of staff precisely during the latter one-third of the project, when testing occurs. If you have too few testers (trying to extract 2.8x the defects), many bugs will remain in the code when the system is placed into service, and operations support will struggle with defects in the field.

Negotiate a fair warranty: It seems odd that many offshore contracts that I’ve seen have only a 30-day defect warranty after delivery. Think about this carefully when negotiating warranty terms, since bug fixes starting on day 31 and beyond will be coming out of your pocket. Chances are your offshore projects might have some of the attributes I have described. If they do, your total cost of ownership (TCO) can rise unexpectedly.

Many people think offshoring is here to stay. If it’s going to be successful, you’ll have to be aware of the pitfalls of managing the design and invention of complex systems across multiple time zones with a partner on the other side of the world. It’s not as easy as the accountants think, because when we look at the numbers from a macro-conceptual point of view, it’s not just about cheaper offshore labor rates. If you do it right, you just might achieve your goals, but if you get it wrong, it can actually cost you more than you expected.

September 13, 2005

I just came across an interesting article by Steve Andriole, a professor at Villanova. In it, he talks about an experience where he presented his Top 10 CIO objectives to his then-CEO. The CEO cancelled the meeting, and told him to come back when he narrowed it down to his Top 3. Ten items were too many, he said. As in the movie “Amadeus”, the symphony can have “too many notes” for the Emperor’s ears.

With that, Steve came back with these three priorities: 1) Get the overall technology investment strategy right. 2) Get the infrastructure right, not just in the short-term, but longer-term. 3) Get the people right. Do we have the right people — given the overall technology investment strategy and the infrastructure?

Steve asks, what would your short list look like? I thought about that question for high-pressure technology projects, and I came up with these: 1) Get the deadline right. Is it too short, too long, or just right? 2) Get the scope right. Have the teams taken on too much, too little, or just right? 3) Understand our capacitity/productivity. What is it given the complexity of what we build? Have we planned beyond your capacity?

Truth be told, I confess to knowing that these are loaded questions, primarily because the definition of “right” versus wrong is a matter of perception. Most IT organizations have little data on their deadline performance and productivity, so it stands to reason that their deadlines and scope commitments are largely shaped by (mis)perception. But asking the questions starts a dialog around the risks associated with these commitments.

Thos are mine and Steve’s. If anyone has their versions of a short list, feel free to let us know.