25 Apr The business case for software applications
Madison, Wis. – David Cagigal knows the missing link in many software evaluations, and it’s a link that manifests itself after the implementation.
Cagigal, chief information technology officer for Alliant Energy Corp., said technologists who miscalculate return on investment often neglect to factor in the ongoing support costs, which will exceed the implementation cost over the life of the application.
It’s easy to pinpoint the pre-implementation cost factors, which include hardware and software purchases and consulting services, but to gain a true sense of the bottom-line value, those ongoing support costs must be baked into the model. The scale of interest is in the long term, so Cagigal requires technologists to calculate the return on investment value to be delivered and quantify the benefits in hard-dollar savings.
No exceptions.
“Typically, they are implemented by a project manager that might be here today and gone tomorrow,” Cagigal said, “and often they focus only on the implementation. They forget the ongoing costs, and they easily transcend the implementation costs.”
Writing the business case
That’s not to say that technology projects don’t pay for themselves over time, even with ongoing costs computed in the business case.
Alliant has technology plans for each of its business units that explain the current state and the desired future state of the affected technology application.
When the time comes to craft the 2008 budget, his department will build the business case, in laymen’s terms, for 20 to 30 applications. The organizational sponsors of a given application, who must make the business case before a governance council, are expected to know both its benefits and boundaries.
In addition to including all the relevant cost factors, they must make sure the technology is architecturally congruent with Alliant Energy’s technology environment. Alliant relies on several key vendors, including Hewlett-Packard desktops and servers, Cisco routers, and Oracle databases. To be architecturally congruent, it must be positioned to evaluate a software bundle that matches its own architecture.
The other side of that coin is skill sets, Cagigal indicated. Since the company has committed to products that require certain skill sets, it can save a good deal of money by making sure it doesn’t have to hire externally to find those skills.
One of the roles of the governance council is to make sure technology sponsors have thought internal resource availability through. Failure to provision internal resources would mean hiring a consultant at three to four times the cost of internal staff, Cagigal said.
Estimating risk
The next page in Alliant’s playbook is measuring project and organizational risk. On one hand, this ensures that cost estimates are grounded in reality and that projects aren’t sunk by poor estimating, and on the other hand it is used to estimate the degree of change management that will have to occur.
The dilemma of enterprise resource planning, for example, is that technologists tend to underestimate the cultural change involved. If an organization does not have a credible project manager with the appropriate tools and processes to follow, Cagigal said it would be difficult to understand the entire risk definition of a project.
The importance of change management has been illustrated in recent transitions to Outlook for e-mail service and to Voice over Internet Protocol for voice services. Both are key parts of Alliant’s culture, and both required the requisit employee training to make for a smooth cultural transition.
The ideal quality assurance scenario is for the users, themselves, to define the requirements and write the test scripts with corresponding requirements.
At Alliant, information technology implementations also are expected to come with a fiscal safety valve – an exit strategy and a “gated’ process that advances from milestone to milestone. The gated process not only establishes a sense of orderly advancement, it also establishes junctures at which a project can be shut down, and losses can be cut, if it becomes clear that a technology simply will not work.
Making tracks
The last piece to evaluating the business case is to track the benefits of a discretionary IT implementation. For a two-year discretionary project, or a project that is not mandated or part of the company’s regulatory compliance, those “deliverables” will be evaluated in years three, four, and five.
Cagigal said the company has established a “pretty well buttoned up” process template that minimizes errors and risk, and always delivers value – perhaps not always in the anticipated timeframe.
“The payback in some cases might take longer than expected,” he said, “but eventually they offset the cost.”
Related stories
• Fusion 2007: In “e-legalities,” CIOs and lawyers combine to provide business value
• Fusion 2007: CEOs say bar is raised for CIOs
• What do CIOs want? Fusion2007 speakers weigh in
• CEOs and CIOs must be ‘joined at the hip’
• Byron Glick: CIO Leadership Series: David Cagigal, Alliant Energy