AUCKLAND (03/24/2000) - Measuring contractors' performance by how close they get to a fixed specification is a flawed way of handling software contracts, says Walker Royce, Rational Software Corp.'s general manager worldwide services organization.
Royce, who has managed large software engineering environment projects for the past five years, is the author of "Software Project Management: A Unified Framework."
Most of industry sets a target that is a very fixed specification of what's wanted, he says.
"The contractors are measured by how close they get to the specification, and that puts them into risk management to try to lose only the minimum amount of money.
"It's much more effective to set a vision of approximately what is wanted, and give the developer the freedom to move the vision up and down in collaboration with the customer."
Giving the developer that freedom might produce 90 percent of what is wanted but at 50 percent of the original price, he says. It also encourages innovation by the developer.
"The other way, both good and bad contractors make money."
Royce is also opposed to some of the so-called state-of-the-art quality assurance, which he describes as expensive fads.
"I can't think of a more expensive way to evaluate software than by using humans. Quality assurance is usually formal inspection of software.
"A lot of studies show inspections are only 60 percent efficient. You don't find any of the issues that are killers, such as row-locking or bottlenecks."
The better approach, he says, is demonstration-oriented evaluation, where a version of the project is built that is an immature model of how it will work.
"You take the 20 percent that really counts and build that first. It costs the same as doing it on paper but you avoid the later downstream reworking, which may be 40 percent of the effort."
The customer's domain expertise defines what the important 20 percent is, in collaboration with the developer.
"A lot of this has been practised in an ad hoc way for several years but it's just now turning into systematic processes."
He says that only one out of four software projects is successful, but the three failures are usually unwilling to share data because "it shows how they screwed up".
And the successful projects aren't talked about because businesses regard them as a competitive advantage.
"It's amazing how organizations want to increase productivity but can't measure where they're at now," he says.
"The main metrics today are derived from change of software over its life cycle. But metrics don't tell you what's right or wrong. It still takes common sense and human judgement."