A Common Language for the Business and IT

Visibility into IT processes and services is a must, says Kilcourse. "The biggest part of that is getting agreement on what will be measured, and then measuring it," he says. He urges IT managers to develop a common language that both IT and the business can use to communicate about both a problem's business description and its technical description. "[That language] needs to map its processes and their output (always, digital assets) to the business, and not leave it to the business to figure it out. Inevitably, that leads to development methodologies and portfolio management techniques."

Sponsoring business leaders lose the thread of IT driven change initiatives pretty early in the process, Kilcourse says, usually between requirements definition and system specification phases. That happens when they can't understand the correlations between the requirements and the use cases that define how the requirement will be met.

The fault here may not be all on the business side, though. IT might think it got the use cases right, only to discover-usually much later-that the scope is wrong. "This, more than any other reason that I can think of, is why projects fail," says Kilcourse.

Part of a CIO's job, says Kilcourse, is to create and maintain the "bubble" wherein software engineers can stay focused and do what they're paid to do. But that is very hard to do in an "open" environment where there is free interplay between IT'ers and their business cohorts. Creating that bubble really boils down to getting the "contract" right at the outset: what will be built, what it will do, what it won't do, and (most important) how it will set a foundation for future value generation, says Kilcourse.

That means you need to put extra emphasis on finding out what users and the business executives truly want and to communicate it effectively. "User requirements, no matter what the development style, must be rigorously developed, detailed and documented," says Frank J. Fanzilli Jr., the former managing director and Global CIO of Credit Suisse First Boston, from which he retired in 2002 after 18 years of service. Rigorous change control processes need to be mutually agreed upon and adhered to, he says.

Kilcourse agrees. "The most important thing to get down is the process, and then the rules and data that the process need. As they say, 'A picture is worth a thousand words,' and there are good tools today that define or describe business processes-often in easy to understand graphic form. Having business operatives and IT'ers working on these together is crucial."

Even a great staff who understands the business functions they support very well is, at the end of the day, just IT folks with a somewhat idealized view of reality, he points out. "Any coder will tell you that it's the exception logic that complicates a program-and the same is true for business processes. So you need the operations professionals to help define what is and what will be. Then IT can start talking about the digital assets needed to get the agreed-upon process to flow."

To get others to buy into your solution, you need to understand them-and there is no substitute for getting to know your users as well as you can, adds Fanzilli. "Developers are very cognizant of the impact that user involvement has on them. Requirements definition, change control, education and the like have a significant impact upon their lives, and they know that by experience. He says, "One problem is that they may not see it as their role to help manage those processes."