« August 2006 | Main | October 2006 »
September 25, 2006
The QSM 2006 SLIM User Conference
Well, its that time of year again; the leaves begin their journey to join their neighbors already on the ground and the QSMA team treks to McLean, Virginia to likewise join our colleagues and friends at the 2006 QSM Users Conference, being held on September 28th at the Tower Club.
This get together offers a stimulating, fast-paced opportunity to hear some real-world “nuts and bolts” of how the SLIM (Software Lifecycle Management) Suite of tools has improved the application development process at some of the most successful, innovative companies in the world. It’s flattering and gratifying to hear how the ideas I have discussed in this blog can help effect genuine change in organizations, and not just from a bottom line perspective. Communications improve, quality goes up, overtime/stress can be lowered and everybody wins! It also gives our users a chance to tell us what changes and/or improvements they would like to see in future releases of SLIM.
I’m going to be speaking about Agile Productivity Metrics and I can’t wait to hear advice and expert opinion from some really bright people on the positive influence the “right” tools and knowledge can have on world-class organizations; I’ll share some of what I pick up when I return!
For more info, please visit here
Posted by Mike at 06:14 PM | Comments (0)
September 24, 2006
Making Tom Friedman Grumpy
Ed Yourdon recently wrote me in response to the most recent post about the world perhaps not being so flat. He says:
"Great blog posting about the un-flat world today; no doubt you've made Tom Friedman grumpy! Since death-march projects are often the cause of litigious IT failures that keep you and me gainfully employed
and if interested, take a look at a couple more recent postings, where I've created some quickie polls to find out why people think death-march projects are initiated in the first place, why anyone in his right mind would volunteer for one, and what "type" of death-march projects (kamikaze, suicide, "ugly," or "mission-impossible") is most common."
Fans of Ed will no doubt find his insights remarkable, as I always do. Ed's blog is also something you don't want to miss. As Tim Lister once told me, "I don't think Ed has ever had an undocumented thought, ever :)" Nice to have the opportuntity - at every turn - to have access to his mind. Thanks Ed!
Posted by Mike at 02:23 PM | Comments (0)
September 06, 2006
The World May Not Be So Flat...
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.
Posted by Mike at 05:09 PM | Comments (0)