5 Ways to Send a Custom Software Project Off the Rails

Unless you want to build a software system that quickly becomes a fossil (or a monster), you should avoid doing these five things that usually seem like a good idea at the time.

By David Taber
Mon, May 21, 2012

CIO — The first two articles of this series discussed the relationship between two problematic good ideas—bid-to-win behaviors from vendors and Big Bang release planning from clients. In many a data migration and custom software project, these ideas lead to big overruns in cost and schedule.

This all happens in big cloud projects as well. There are many contributing factors to these bad outcomes—chief among them adversarial incentives, inappropriate metrics and lack of collaborative infrastructure—but those aren't the root cause.

It doesn't matter how well you collaborate and execute if you are working on the wrong thing.

Custom Software Projects Beget Unnecessary Code

When The Standish Group conducted an analysis of big Y2K projects, it evaluated the old COBOL systems that were being converted rather than the success of those conversion projects. The bigger the original project had been, the firm found, the more of its code actually had no current function.

Some of this was correlated with age, of course, as those behemoth systems had evolved over more than 20 years. But that merely underscores the point that larger projects were more likely to be wasteful projects. Imagine maintaining a billing program with 20 million lines of source code when you're not exactly sure what half of it does.

In the group of mainframe projects analyzed, more than 90 percent of the function points in the original programs didn't need to be recreated at all in the replacement system. The key issue here is that, in those programs' pasts, every one of those function points was fought over, budgeted for and sweated over— all for a business purpose that was at best temporary and at worst imaginary.

Borrowing a metaphor from the construction industry again, we have to constantly apply value engineering to avoid overinvestment in custom software. At every turn in the project, we must ask, "Isn't there a simpler way to solve this problem?" This applies the lessons of The Innovator's Dilemma at the microscopic level by relentlessly looking for the "good enough" alternative to something sexy and elegant.

Remember, You Can't Fight City Hall

In an organization of any size, political decision rules the day when there's any amount of stress and controversy. The way to improve the quality of decisions is to make sure that your project doesn't get into trouble in the first place.

The following five "great ideas" can send any custom software project off the rails.

A tight specification makes for a good project. Too often, this means an overly-detailed technical tome that is thin on business context and silent on economic goals. Unless you are lucky, you've specified something that is so hard to build that it'll cost more than it's worth—though you probably won't be able to see that until halfway through the project. The antidote here is a change of mind-set. Focus the business analysts on describing the business goals, and leave the software implementation details to the team.

Continue Reading

Our Commenting Policies