The software development department might envision a marvelous solution to the company’s IT or business need, but the technology goal can’t be achieved unless the Big Boss commits to the new strategy. How do you get there-and ensure that the user need really is filled?
The key, say three former CIOs, is accurate business process requirements, a common language for the business and IT to communicate, and executive steering.
“It’s what happens before a project gets to IT that often creates the challenges,” says Brian Kilcourse, former CIO of Longs Drug Stores, and now a managing partner at Retail Systems Research.
While conflicting demands for IT resources and the propensity for a short-term view are significant challenges, he says, the most basic quality issue that IT efforts face is a lack of business involvement.
“Businesses tend to think of IT efforts as separate from their overall strategic agenda, in spite of the fact that to a large extent it is a company’s ability to use its digital assets effectively that distinguish winners from losers,” he says.
Bob Doyle, former CIO of Alliant Foodservice (formerly Kraft Foodservice), agrees.
“My major challenge-the reason I was brought in to five different companies in four distinct industries-was to enable major business change by implementing integrated IT application solutions that fundamentally changed the way the business operated. And do it as quickly as possible,” says Doyle, who now runs a consulting firm.
Management staff usually did not fully understand their role or responsibility in the development process, he says, so they felt no accountability. Plus, says Doyle, who has more than 30 years experience with Fortune 100 and smaller companies, company management had no process to involve, manage and set expectations.
For an IT strategy to succeed-or simply to sell the business on a major development project-you need full executive buy-in and support. Reports Kilcourse, a CIO friend of his said it simply: the most important word a CIO must learn is “No,” and his most important skill is to say it when the business isn’t ready to commit. “Top level guidance and visibility is an absolute must,” Kilcourse adds.
Given the challenge, how does one address it?
Winning the Boss’ Trust
To win over the business side, Doyle suggests three overall solutions:
- Educate at all management levels: explain and engage.
- Establish Executive IT strategy committees to create a formal executive and management reporting and feedback process.
- Win their confidence and trust by demonstrating successful implementations.
A successful CIO of a US 60 billion (62.billion CND) dollar company once told Kilcourse that the perfect IT budget was one that was 100 per cent allocatable to business initiatives. “That might be a little bit of hyperbole,” he says, “But it’s a stretch goal that companies should try to reach.”
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.
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.”
