This CIO (we'll call him Mike) needs to figure out what IT processes and practices he should have in place to generate tangible value for his business. He'd also like to avoid the fate of his predecessor, who never did get it right.
Mike asked me a very simple question about a fairly complex process. How do CIOs decide, from the multitude of IT projects, which to undertake? And once we've selected them, how do we prioritize these projects to line up the ones with the highest value first?
For the past decade, I've held several turnaround CIO roles, and I've found the quickest way to success is to bridge that chasm between IT and the business functions. Making sure that IT resources are spent on the high-value, high-impact projects does that. But to really deliver the best business value, we can't take that first step alone. We need to form a steering committee, a group of business leaders who will help us determine which initiatives are most closely aligned with their needs. The steering committee members must be real decision makers, not people who will need to "get back to you" after checking with someone else. Just as it takes a village to raise a child, it takes a steering committee to keep IT from straying.
Once the committee is in place, we have to develop decision and/or measurement criteria to use in evaluating and prioritizing IT initiatives. These criteria should consider both strategic and tactical business requirements. For example, business strategists may need to understand customer buying patterns before implementing a loyalty or rewards program, while a more tactical system might help reduce the head count in accounting.
I judge these initiatives based on their contributions in the following five areas:
- Providing direct payback.
- Enabling strategic alignment.
- Improving business practices.
- Simplifying architecture.
- Reducing risks.
As we build the cost/benefit model here, keep in mind that the sponsoring business function must be responsible for delivering the benefits while we (IT) own the costs.
I learned this the hard way, early in my career. We had implemented an inventory management system that was expected to improve inventory turns by 50%. After we took the system live, inventory turns did not budge. Six months later, the CEO beat me up about my new system (this is when I learned that underperforming systems belong to IT). In fact, the system was working as designed, but the vice president of manufacturing hadn't implemented any of the process changes required to achieve the inventory benefits. Ever since, I ask the business function to sign up for the benefits.
Sometimes, though, it's hard to calculate exact benefits or costs. So for projects with more nebulous benefits, I recommend breaking the project into phases that let you test the costs and benefits before committing to the entire project.
Mike called me after his first committee meeting. Four of his five projects were approved, and the CFO volunteered to work with Mike on refining the decision criteria. As the meeting closed, the CEO told Mike that the company had needed something like this for a long time. Considering the history of IT turmoil at this place, this new CIO chalked up a well-earned victory.
Niel Nickolaisen is CIO and vice president of strategic planning at Headwaters Inc. in South Jordan, Utah. To comment on this story, email email@example.com.
This was first published in August 2005