It should go without saying, but it bears repeating: not all changes that are requested are worth doing, and a CIO needs to have a rationale for saying “yes” to this one, and “no” to that one.
For many, the business case has been the tool to at least weed out some of the desires of the business for IT change.
Still, many changes do not require a business case — the effort of mounting one for a change that costs less than a month’s work over three exceeds any benefit the change might bring, 90% of the time — and still others are things that don’t have a convenient user ready to stand up for them, but would really be worthwhile.
Two cases like this have recently come to my attention.
One had to do with a portal solution. The portal software was justified for a new, business partner-facing solution. Now that it was installed, however, the CIO and his team saw value in offering the portal capabilities internally, to allow different users to configure a specialized view of the company and its systems that met their individual needs. It was fortunate it was essentially “free”, because it did not attract much usage.
This pointed out that most people don’t want to configure technology. It would take only 12 minutes or so over four to five sessions to configure the button bars in Microsoft Word or Excel to exactly suit the functions — and only the functions — commonly used by the user. While all the attendant productivity gains was a “given” in terms of results, practically no one did it.
It would pay, therefore, for IT help desk to build several common configurations and set up users’ applications remotely: pick out the one that suits you and we’ll do it. Result: a high response rate, significant reductions in help desk calls, and what a typical user told us was “a good half hour or more back into my day” of time not spent figuring out how to do things.
Creating some standard portals, and treating them as “products”, would stimulate usage. Moreover, finding out which ones are selected and by whom, and going out and doing some fieldwork to find out what works and what doesn’t with them, would allow them to be regenerated periodically.
This shift to a product development framework rather than a project framework for these elements would allow the CIO to demonstrate further benefits from the portal software — and justify continued investment in it (especially since the client-facing solution hadn’t lived up to its promises).
A second situation came up where a company got “serious about portfolio management”.
To start, they assessed every one of their applications: functional fit to the company today, technical quality, availability of required skill sets in their labour market, nature of the code — and were able to come up with a ranking, from “cheap to change” to “expensive to touch”.
A second analysis stack ranked the application set by its range and reach within the business: what was the potential effect if something good was created here.
This gave them a 2×2 matrix that all applications could be dropped into.
Expensive and low effect were frozen (and each would be looked at for elimination opportunities). Expensive and high effect were prime candidates for replacement.
Cheap and low effect were automatically low priority, unless the change was an obvious winner (major increase in effect, or generated a one-time return of note). Cheap to change and high effect were priority items to infill a plan that was fundamentally about eliminating liabilities.
Expressed this way, the business leadership — which had spent years complaining that IT wasn’t responsive to their needs — insisted that the CIO hold off on their initiatives in favour of cleaning up the liabilities. This is what you want portfolio management to accomplish.
Most IT organizations think good client service involves doing as much as possible of what you’re asked for. Greater rewards come from having a framework for decisions, and sticking to it.