Doyle says, "The business exec is concerned with, 'Will I get the system when I need it, for the price I agreed to, and will it perform as requested (meet expectations)?' Whereas the CIO is also looking across all projects to determine manpower requirements and effective resource allocation."
That makes it even more important to gauge the progress of a project. Unfortunately, says Doyle, most development departments are very weak in collecting and reporting meaningful metrics. Disparate processes and lack of tools can make it very difficult to accurately report a development team's efforts to both IT management and business partners. Most data is collected and reported manually, which is labor intensive, not timely and prone to error, he says. "Often, you had to rely on 'gut' experience and judgment when explaining the 'health' of a project," says Doyle.
Doyle suggests that IT managers explore recently available tools, such as CIO dashboards, which are integrated into the software development process. Doing so, he says, can facilitate the collection and reporting of development activities-and improve communication with the business people.
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.
Sign up for Computerworld eNewsletters.