Calculating the ROI on IT Innovation

Many IT professionals believe innovation in IT pays for itself. But a surprising number of companies I visit aren’t in a position to prove this hypothesis. They typically don’t know what it costs to provide their IT services and can’t quite put a figure on the benefits of IT innovation projects. Without these key data points, they have a hard time quantifying the ROI or payback on any IT project—making it difficult for IT to compete internally with other departments for scarce business funding.

The rest has many considerations for planning our ROI, plus contingencies to muck about with.

For much more detail, see Mindy Cancila’s write-up over at Gartner from earlier this year.

Source: Calculating the ROI on IT Innovation

Working with legacy applications, systems, and portfolios

Elisabeth Greenbaum Kasson asked me recently for advice on working with legacy applications. Check out her piece on it. Here’s the full reply I sent to her in email:


Her topics:
– The steps someone could take to get themselves up to speed on their employer’s legacy software.
– How this knowledge can make them indispensable (I know that term is relative)
– Why this type of expertise is so necessary, especially when it comes to integrating said software with new and/or evolving products.

When it comes to “dealing with legacy,” there aren’t that many good options. We often think of “legacy” as software that must be changed but that we’re afraid to change. If you’re not afraid to change it, you often just think of it as “our software.” Legacy has this connotation of it being risky, scary, or maybe just boring.

If someone wants to go down into the mines of legacy management, the first thing I’d recommend is doing some history work to find out why the legacy system in question was created, what it’s currently used for, and, hopefully, who the current stake-holders/owners are. You’d be surprised – or maybe not! – how often some or all three of those are totally unknown: with unknown stake-holders, I sometimes hear tale stories of IT departments just shutting down systems and waiting to see who calls them.

Understanding the why, what, and who of a legacy system will tell you most of what you need to know when it comes to managing it. Further up the management chain, having a good grasp of and on portfolio management is valuable. Given the why, what, and who, you should be able to prioritize any given “legacy application” relative to another with respect to funding and attention. Is fixing the application that’s used to schedule office party birthday cake orders more important than the application used to re-order plungers for the warehouse bathrooms? You won’t know between cakes or plungers if you don’t do portfolio management.

The other aspect is simply learning the technologies you need – operationally, programming, and sometimes physical management – to keep the thing up and running and to modify it. This might mean learning, for example, about operating systems for mainframes, AS/400, UNIX, older versions of Windows, and sometimes even exotic things like OS/2. There’s dozens of programming languages out there, and you’ll need to learn not only the appropriate “old” language, but how the build, version control, and project management tools around those old stacks function.

For more, I wrote about dealing with legacy in my cloud native journey booklet last year.

Bimodal IT leads to technical debt that must be paid, with interest

Instead, it has created a great divide, said Pucciarelli. “This siloed, divided approach brings frustration, disappointment and failure in multiple ways.” For one thing, it doesn’t support healthy team spirit, he said, and the innovation side tends to operate fast to deliver business solutions without the accountability around reliability, quality and security that is expected from the traditional IT side. “It leads to redundancy and inefficiency.”

Source: Bimodal IT leads to technical debt that must be paid, with interest

Don’t confuse influencers with check-signers

Tracking the exact mechanics of bottoms-up shifts in IT is as hard as tracking “real cloud” spend, if not harder:

I would listen to developers, but more likely an architect or head of development than allow the grass roots to start buying and using anything they wanted. I am not naive enough to believe that developers don’t go out and look at neat new stuff, a developer happy and content to just do maintenance on existing software is a rare commodity indeed. Developers may have introduced some tools such as Git, Github, JIRA and Jenkins but these will at some point still require some level of management buy in and approval , nor do they affect the company wide license expenditure.

There’s a lot on “this is how large organizations actually work,” which is good context for what all this “enterprise nonsense” is all about:

In order for a developer to sign up to a public cloud service any even remotely competent compliance driven department will ensure there is a process for approval for the spend which would include justification. If the initial spend is approved then there is a risk that a developer might be naive in his usage of the cloud environment and start moving data around or investing in massive amounts of computing power. This would normally be caught at a monthly bill cycle by any diligent IT manager/Director. If not then the finance team would certainly pick up on the unusual spend.

In summary: “hi, we’re a ‘large enterprise,’; cloud, we don’t do things like that.”

Don’t confuse influencers with check-signers