Gartner analysts are urging application development managers to look at the existing application portfolio and decide what to do with it. It's common for companies to find that they no longer need 12-18% of their applications. Yet, managers and developers need to move forward using older code "without acting like 'old is bad,'" Hoyle said.

That does not mean that your manager will return from Phoenix with a documentation gleam in her eye — at least, not if she listened to the entire presentation. To make a reuse culture work in your organization, said Veccio and Hoyle, involves a lot of work, including (among several other items) metadata mangement, standards and principles, quality assurance, and performance incentives. Veccio said, "Reliablity, responsiveness, and ROI are the Three Rs of service oriented development architecture (SODA). They're based on the coneptt of reuse, which reduces programming effort and cycle time, and reduces inserted defects."

But the biggest problem with code re-use is the human resources element, they caution. Hoyle pointed out that programmers are likely to say, "I can write you some of that. Reuse is for sissies. I'm a better programmer than they are."

The renewed emphasis on process control includes various forms of project management, because it's impossible to judge progress without some kind of measurements. Whatever your project size, Hoyle said, you need a solid basis for understanding the requirements and the expected benefits. Hardly anybody, he commented, does benefits realization; every manager is advised to go back to the business unit 6-12 months after project completion to find out if they got the benefits they expected — and to learn from the answer.

Another quality issue raised is Gartner's emphasis on "just enough." In his Process session, Hoyle said, you need "just enough process to enable good enough results." Managers shouldn't get themselves into a state of analysis paralysis in the effort to produce perfect results.

Another management function that Hoyle suggested is to kill development projects early, "and often," he said, "if your failure rate is high." You can improve productivity by 20%, Hoyle advised, "by killing projects when you should: which is early in the lifecycle." For example, a project that has had three baseline adjustments because of scope creep is already in trouble. Most projects do have scope creep — 1% per month is typical — but three or more adjustments due to changing requirements means that the project is already out of control.