So you have a technology strategy, right? A real, honest to goodness one built up in the IT group?
I can hear the screams now: “that’s not a technology strategy, it won’t be aligned with the business”.
My field work suggests something quite different. What passes for technology strategy in this era of aligning with the business and then documenting the strategy is nothing more or less than a list of projects that have passed through the funding sieve.
There is almost never any long range purpose, and certainly no sense of strategy that pervades it.
One of the perfidious effects of chasing the breeze that is “alignment” rather than bringing expertise into the business strategy process.
Just exactly who else was supposed to ask and answer the question “what future conditions must we as an enterprise be prepared to face that technology can bring about?”, if it wasn’t a group of technology professionals.
Was the business expected to sort out just exactly how your competitive position could be undercut by the early stage work being observed elsewhere in the world, and to commission all the moves necessary not just to meet that, but to do it with attention to the SG&A tied up in IT and the liabilities inherent in the portfolio that exists?
To figure out the many steps that connect now to then?
To determine which moves had value in and of themselves for the enterprise, versus which ones led nowhere useful if that future didn’t come to pass?
I know that doesn’t sound much like the IT work that people have been doing, but I do keep saying IT is now more about information (“big I, little t”) and less about technology (“little i, big T”).
It’s a paradox: you actually have to do more about technology futures — at the strategic level — to get a project portfolio that creates an information ecology in your enterprise.
One objection I hear is: “Wouldn’t a business that could do that level of thinking really not need me in IT at all? After all, with that level of insight into the technology question set, everything else could be commissioned from various service providers. No internal people needed.”
Not true. In fact, to drive a comprehensively outsourced environment you’d better have the ability to strategise back in your own organisation.
So let’s get over this view that the technology strategy derives from the business strategy.
In one sense, of course, it needs to. There’s no point in designing a future that no one else will sign up to.
Really, the processes of business strategy — and the business is seldom unified on what is strategic, division by division — and the process of technology strategy play into and off of each other.
In other words, this is an on-going dialogue. That’s why it can’t be outside your organisation.
To play, you need to have things to say.
Hence the starting point for the discussion must be a technology strategy to be presented as what’s called a “straw man argument” to kick the discussion off.
An example may help here.
I worked with an organisation that’s in the broader public sector, and the government side is trying to wrestle its finances to the ground. So a shift to “exit” could come about, and this organisation would suddenly have to work in a competitive setting, plus earn its cost of capital. If you were forming the technology strategy for this company, a key element would need to be a roadmap to a lower SG&A point (this firm would probably dip before stabilising and clawing its way back), and a much more flexible product line (their offerings are deeply equivalent to their systems).
However, this would all be worth doing whether anything changed or not — it should add up to a more flexible and lower-cost base — but as it’s a multi-year, multi-aspect change that’s required it qualifies as strategic, not tactical.
In turn, rather than looking at portfolio renovation in isolation — which would lead to a suite of package choices or “-as a service” provisioning decisions — a restructuring of the technological base (infrastructure, tools, middleware, etc.) may well lead to different decisions.
So “straw man” scenarios, with potential decision trees and rough costings/timeframes (rounded millions and years will do adequately) and a description of the future state in business terms give the rest of the enterprise something to sink its teeth into in forming corporate strategy.
Indeed, since every other operating unit has things in their scenarios and plans, the business can use these thoughts to focus their own change initiatives. The dialogue commences, with the enterprise the winner.
How different this is from waiting to be told what projects the business has decided on, and then scheduling the work up to the spending limit!
Why would you put, for instance, service-oriented architecture (SOA) on the agenda as a formative element of your technology strategy?
Well, not because it’s trendy, or even “essential”. Nor might you call it that (in public). But you would talk about the importance of building componentry up rather than imposing massive system blocks down, for the options it, done properly, would open up.
Why would you put portfolio renovation on the agenda? To remove roadblocks to that architected future.
Why would you box off certain key areas for bespoke (custom code) potential, and fix others as package realms?
To work to a cost profile, and a timing profile, and hence an SG&A profile, that moves in the right direction.
Indeed, you may have a strategic plan that says “first do this, it lasts five years, then we’ll have these other elements in play to do that, which takes us here.”
All of these are decisions I see organisations taking, yet few of them have either laid out the big picture, nor taken it to the business.
They are trying to do the right things in the margins, at the edges, and on the backs of the project schedule.
If you don’t have a technology strategy, you are creating a corporate risk.
As most organisations also don’t have a proper governance process (such as a Governance Board), this risk goes largely unnoticed.
But, governance process or not, the responsibility still exists. Best to get going.