Editor's Note: Poor Quality Invites LawsuitsEditor's Note: Poor Quality Invites Lawsuits

For the past few years, IT investments have followed a path similar to the many diet crazes: Trim down, get lean, ingest the good stuff, stop consuming the less-healthy, nonstrategic stuff. Develop an exercise plan and deploy quickly. The risky, longer-term megaprojects are still out there, but all this healthier living--plus new licensing models, more thoughtful service-level agreements, software-as-a-service models, and other strategies--have lessened the hazards of IT investments. But it's doubtful that lawyers specializing in IT-related litigation are going to be out of business any time soon. There are still plenty of unpublicized failed IT projects that find their way into court or into the hands of a mediator. Figuring out who's to blame is a tricky job.

There are many reasons that projects fail: poor management, unrealistic expectations, complex customization, market changes, etc. But what I hear most from readers is that poor-quality software is to blame. During a meeting with Borland a few months ago, I was intrigued by the company's idea that software development needs to be transformed into a managed business process, much like manufacturing, procurement, or other key business functions. Approaching development as a life-cycle process, the company contends, will mean higher quality output.

Michael Silverman, an IT litigator quoted in our cover story (p. 28), laments that too often software companies pressed to meet a deadline say, "Let's just get the software done and out to users and see how well it works. It doesn't need to be perfect."

But there's something to be gained from development done right. Software engineered using a rich set of processes and quality standards is ideal. But offering a product up to the user community for testing, refinement, even extensive additional development is also a good thing. Advancements in communications and collaboration can make the process of development more creative and innovative. It's something the open-source community knows well. So maybe the answer is higher quality and higher levels of collaboration--but long before a company is several years and many millions into a deployment!

Stephanie Stahl
Editor-In-Chief
[email protected]

To discuss this column with other readers, please visit Stephanie Stahl's forum on the Listening Post.

To find out more about Stephanie, please visit her page.