5.CARPET YANKING: Pay Attention to the People on the Front Line

Most developers aren't asking you to know all the details of a given project. Some believe if a CIO is worrying about specific line items in a software requirements spec, she's micromanaging, and she isn't paying attention to the right tasks. But the developers do want the CIO to pay attention to what they're doing, what they're telling you, and — perhaps most importantly — what isn't being said.

Get out of the office. Talk to people. Manage by walking around. Find out whether the software requirements are being instantiated in the real world. Steurs wants his CIO to ask questions and listen carefully. "The CIO has to realize that if there is no bad news, there is something very wrong. Smiling people nodding 'Yes' in meetings is not a sign of great intelligence at work," Steurs says.

But don't pretend to listen if you aren't going to take action. "Don't ignore our feedback if you ask for it. That's not empowering. It's pretending to include us before yanking the carpet out from under our feet," Richardson says.

Your testing organization is also an early-warning system. According to Pensyl, development staff may propagate positive reports during R&D, but if the test group is vocal at this point in the project, complaining of incomplete, missing and ambiguous requirements, you should take it as a clue that the team is working with a poor foundation. "Project truths transition from being based upon factual evidence at the beginning of the project, to truths and decisions being based upon perceptions and reaction as the project progresses," Pensyl says. "The only untruth at the beginning of the project is and was the marketing promise date. All else at the beginning was truth based upon fact at that point. A promise date should never be issued without proper estimating. All project teams should be given equal credibility for their estimates."

If you want the software requirements process to improve, says Pulley, attach a reward to doing so. He suggests that CIOs find a way to tie a very large bonus percentage to the quality of the delivered application, six months after the release. "People are dollar motivated," he points out. "If you incent people to deliver by a given date, with few penalties for quality, then the application shall be delivered by that date. Make the pool substantially large. Place a small percentage of the bonus pool on the delivery date. Allow product support to draw from the bonus pool. If the project meets the date, but delivers a poor quality product, then the bonus pool will disappear. If, on the other hand, the application date slips, but the resulting delivery is rock solid and requires only a small amount of support beyond training, then the bonus pool should reward greatly."

Perhaps you can't achieve telepathy with your development staff. That may be beyond our current level of technology. But if you put these five techniques into practice, your developers may be fooled into believing that you can, indeed, read their minds.