« Back to the top page
IDG News Service

IBM: Fixed prices for IT projects are unethical

Rafael Ruffolo, ComputerWorld Canada04.18.2008
Tags
Comments 0
Like the story? Get Alerts of big news events. Enter your email address

If your IT projects are consistently late and over budget, chances are you haven't implemented Agile software development practices.

Speaking at this week's ProjectWorld/Business Analyst World in Toronto, Scott Ambler, practice leader of Agile development at IBM Corp., told a crowd of IT professionals to throw away most of their traditional software development theories and take a new approach in their future projects.

In most development projects, Ambler said, business analysts write out a detailed requirements specification document and send it over to the software developers to carry out the design. By developing the plans upfront, he said, the people making the requirements document end up guessing the type of things the company may need down the road and more often than not, the IT projects end up in failure.

"Writing a detailed requirement spec up front is a worst practice, despite being considered a best practice for the longest time," he said. "When you do this, you are building to specs as opposed to building to what people actually need."

Ambler also said that because many IT projects carve their requirements in stone before any actual tests or coding has been done, their budgets are often underestimated and unrealistic.

"Fixed prices for IT projects are unethical," he said. "We can't estimate up front and the only way to enforce the costs is through change management, which is also unethical. Change management is really about change prevention."

To combat these ineffective IT projects, Ambler recommended organizations consider the Agile approach -- which he defined as an incremental process that is performed in a highly collaborative manner to meet the changing needs of the stakeholders.

"The traditional way of writing a bunch of documentation and flipping it over to the next group doesn't work," he said. "We prefer executive documentation, which requires that we write the code first. It's far more disciplined and every two weeks or so we have working and visual software to show to our stakeholders."

Besides increased teamwork between multiple business groups, some of the key criteria to an agile system, according to Ambler, include continuous testing that drives development, daily work with the stakeholders, and producing working software on a regular basis. Many IT organizations, he said, too often lose sight of their true goals. "You have to know your audience," Ambler said. "Treat your stakeholders like adults and keep them involved in the process. Any dollar spent on documentation is a dollar not spent on working software."

Cem Kaner, author of Lessons Learned in Software Testing and Testing Computer Software, agreed, saying Agile development can reduce the cost of late changes and make it easier for IT organizations to respond as the stakeholders' needs continually evolve.

"The most important thing the executive can do is keep asking the critical question, 'How does this practice (paired programming, test-first programming, whatever the group is proposing this week) make us more able to be more responsive later,'" Kaner, who is professor of software engineering at the Florida Institute of Technology, added. If those implementing the process can't answer this question convincingly, Kaner said, it's a big red flag.

For Ambler, his process simply treats IT project requirements like a prioritized stack.

"We go to the top of the stack in two-week iterations and start working on it from there," he said. "You begin with the good stuff and eventually work your way to the stuff you rarely need. We have a higher success rate because at the end of the iteration, we have potentially shippable software."

The smarter executives, Ambler said, will often want to wrap up the project once they see all the useful features fully integrated. This means IT projects are finished sooner and you can gain increased confidence and funding from the stakeholders for future tasks.

"Because you are creating workable software, they can continue to fund the project until they see something they want to


Post new comment

The content of this field is kept private and will not be shown publicly.
Respectful debate is welcome, but comments that are defamatory, indecent, abusive, or in violation of any law will be removed.