There is no cut-off point where requirements stop changing, believes developer Stefan Steurs, but many CIOs assume a point exists when everything is perfect and coding may commence. When developers, testers and users get involved in reviews, development, testing, prototyping, piloting and other activities, they feed the discovery process with new elements, some of which can be very disruptive. "This means you need decent change management," Steurs says. "You want to know throughout the development of the product if the change to the requirements is converging or whether it remains disruptive . . . The CIO has to know what is going on, and it's time for the next [management] level down to start being honest instead of saying that the clothes of the emperor are very, very nice."

Developers passionately wish that CIOs and other managers would build change management into the development process and make it safe. Otherwise, you put more than the project at risk. Instead, some managers whitewash the situation or software methodologies. Luiz, who works at the Brazil office of one of the biggest consulting companies in the world, says that his firm uses waterfall techniques but casts it in more modern-sounding terms. "We estimate the size of the system using [function point analysis] at the very beginning of each project and use this estimate to sign the contract. So usually in the first two weeks we know exactly how much this system is going to cost and how long it will take to develop it. Of course, we are wrong most of the time and usually we are on the wrong side of 'wrong', which means we underestimated the complexity of the system, and it's going to cost more and take longer to develop than we initially thought. To protect us, we assume that every requirement change is a potential way to grab more of the customer's money by charging extra and overestimated 'code-monkey hours' for even trivial changes. Sometimes this works, meaning that we could profit a lot and the customer hates us just a little bit after all this. Many more times, the customer just hates us, we hate our jobs, and our bosses hate us for [their] not being able to go to Aspen this year."

You can be part of the problem, too. Geoffrey Slinker, a software developer for more than 20 years, says he is most irked by the tendency for a software feature mentioned or proposed by the CIO, or any CXO, to instantly become a required feature. "The problem doesn't lie in the proposed feature," he says. "Often, the feature is a good idea. The problem lies in the disruption that is caused. The proposed feature becomes a high priority just because a CXO made the proposal . . . Even if the statement is an off-the-cuff comment during a demonstration towards the end of the development cycle, the statement can be interpreted as an action item and cause a chain reaction of meetings, changes and re-prioritizations." Remember that your voice carries, Slinker cautions; don't let your position disrupt the prioritization of software requirements.

Getting the software requirements right is only the first step, though. After the developers and testers have started work, it's the CIO's job to ensure that the project stays on track, and that the result adheres to the original promise. And oh boy, does that open up a whole new set of developer foot-stomping.