Describing IT in terms of Business Outcomes
We’ve all seen IT described in terms of business outcomes. Most business cases for investment are crafted this way. There are two challenges inherent in this approach, one obvious, the other subtle.
The obvious trap that almost all IT projects fall into is that business outcomes are described in terms of automating existing business processes: we’ll do the same things but better, faster and cheaper. To do otherwise is to take a leap of faith that IT is capable of transforming the business; creating unimagined business outcomes. Think about Steve Jobs and the iPad. That could never have been defined in terms of ‘business outcomes’ and it wasn’t: it was defined in terms of vision.
If an organisation lived in a bubble, we’d never know what we were missing out on. But organisations are staffed by people who use brilliant IT at home; and who are dismayed at the appalling state of IT at work. They know there’s something wrong but can’t describe what.
The subtle problem with describing IT in terms of business outcomes is that we’re inevitably focusing on outputs unconstrained by reality. Once that business outcome target has been defined, woe betide any realities that dare to intrude on the project that’s supposed to be delivering those outcomes.
It’s like deciding that our aircraft must carry 10,000 passengers… when sadly, the inputs (aircraft grade alloys) aren’t capable of supporting that sort of loading. Realists are required in the aircraft industry; they’re shunned as ‘negaholics’ in the IT industry. We all know IT project managers who told the truth and were promptly dismissed.
I recall all too clearly a major defence project which was to support some awesome training objectives (the country and project shall remain nameless to protect the innocent). The business outcomes were compelling and a business case was signed off to the tune of $100M++. But no-one had considered the spatial data that was required to support the system. The system was designed, tested and accepted based on a training area which had a lot of spatial data. The first real deployment; no spatial data. Cost of the spatial data: $100M++.
Business outcomes met reality. Reality won. It was like designing an aircraft that was too big / heavy to land at any airport.
The IT Priesthood
So that’s why we have another way of describing IT: in architectural terms. We’ve all seen wonderfully complicated architectural diagrams that purport to describe the IT infrastructure to be.
Most of you reading this blog will be in the IT industry and we all nod sagely at these diagrams. We understand what they’re communicating to us, forgetting that we’re the IT priesthood, reciting the sacrament in Latin, content that the congregation will just follow along in a state of religious fervour.
Two problems with that. The first and most corrosive is that the congregation is already worshiping at the altar of Steve Jobs. People working in our organisations have seen a better way. It doesn’t involve architectural diagrams. It involves beautiful, intuitive access to information.
The second problem is that as an IT priesthood, we’ve forgotten who we answer to. It isn’t the IT God… it’s the CFO, CEO and Board. Not only are they becoming fed up with IT promising miracles and delivering the barely adequate, they’re also looking covetously at the better way.
That’s all well and good but we all know that enterprise IT can’t be defined as simply as Steve Jobs would have suggested. It’s presented as one of the reasons why Apple has never conquered the enterprise; their simplicity doesn’t scale. We believe that simplicity can scale.
LINQ; A Better Way
What if we were to describe IT in an intuitive way that encouraged dialogue with the CFO, CEO and Board? What if we could describe planned improvements in a way that had the CFO nodding in violent agreement?
We have created a methodology for describing IT in terms of the flow of information from source to decision support application: the information supply chain. We focus in on that flow, consigning people and systems into their roles of plumbers and plumbing. This is far from dismissive; it recognises the real value of these people and systems in terms of the business outcomes that they’re serving. As such, it is empowering.
It’s also powerfully simple. The role of IT is to enable the efficient and effective flow of information from source to decision maker. nothing more, nothing less.
As we’ve rehearsed this methodology with our customers, we’re seeing entirely new conversations emerge.
The first is during the capture phase. We’re finding that tracing an information flow generates tremendous curiosity. The creators of information want to know who uses their information and how. The application maintainers want to know where their information comes from. Tracing an information flow demands a conversation with another team. We often see that conversation work like this:
“Ah! I didn’t realise you used our data like that; if I change this field, it’s really going to help you… right?”
“Yes! And if you were to provide a web service of that information instead of a file, we’d save a fortune”
“No-one’s ever asked us to that… it makes perfect sense.”
That conversation encourages an incremental improvement; a small cost realising a large benefit. Suddenly the ‘big bang’ approach is no longer as relevant.
That creates a whole different approach to conversations between IT and the business: chances are that the conversation above was between someone in IT and someone in a business unit. Consensus about change started at the bottom and can be relayed up the chain in terms that everyone understands. Even the CFO understands – and is delighted that big savings are going to be achieved for a small capital outlay. Suddenly, the CFO wants to have coffee with the CIO!
People understand and can relate to information supply chains. It’s as revolutionary as the sacrament shifting from Latin to the language of the congregation. Suddenly, we’re seeing participatory IT… IT fusing into the business… IT serving the business.
Once IT can be described in terms that executives can relate to, the communication barrier is broken down and the focus can shift from ‘business outcomes’ to ‘vision’. Suddenly, the better, faster, cheaper is being achieved through continuous and incremental change and energy can go into discussing transformational change.
We call our methodology and emerging tools LINQ; if you’re interested in finding out more about the power of this new approach, please click below.