These articles are aimed at senior management funding Software Developer or IT Professionals attempting to show the ROI benefits of what can sometimes seem counterintuitive.
This ever growing library is provided free of charge and can be found here.
In this article, part of my series explaining better ROI from software development, I’d like to look at the why building it right is important. Possibly more important than building the right thing.
Avoiding the alignment trap in IT
Avoiding the alignment trap in IT is an article published by Bain & Company back in 2007. The article was based on deep analysis of overall effect on the business based on firstly how aligned IT was to the business and secondly how effective IT was. The original article can be found here.
I first became aware of this piece of research through the “Why Building the Right Thing Means Building the Thing Right” presentation by Liz Keogh (presentation can be found here).
During the presentation, Liz goes through why it is not only important to build the right thing – it is important to make sure that it is built right. She references the Alignment Trap survey to demonstrate this.
Business Alignment vs IT Effectiveness
In the Alignment Trap, the below quadrant was used to demonstrate the results of a survey they had conducted – a survey which showed some surprising results.
The survey summarised results into one of four quadrants – the bottom left, where the organisations IT was less aligned & less efficient, through to the top right where it was both highly aligned and efficient.
What is probably hugely surprising to most (and it was to the survey analysts) was that having a highly aligned IT wasn't a good thing. If anything of the all the quadrants, it had the highest IT cost and lowest company growth rate.
The Alignment Trap
Most people could reasonably expect that if its IT is aligned to company (or department, dependant on size) then this is a good thing.
The “Alignment Trap” as coined in the article was an illustration that this really wasn't the case if IT wasn't also highly effective.
And this holds true to my own personal perspective.
I've worked with many companies over the years where their IT effort has been highly aligned, integrated with the local business unit. The owner of business unit believes they are getting the best IT they can because they can control exactly what is required for their unit.
And at the unit level that maybe fine.
When however you expand further afield and look at the wider organisation you find that that narrow focus makes it very difficult to operate effectively.
If you are trying do to anything that crosses those Business Unit boundaries then suddenly you have a complete clash of technologies, principals, terminology – all of which are expensive problems to overcome.
Town planning
I like to equate this sort of thing to town planning.
If each neighbourhood has sole responsible for its own planning then they will build based on their own wants. Each neighbourhood will have its own priorities.
Each will have need for water & sanitation facilities – so they build their own rather than gain the efficiencies of shared resources.
Each will zone its area based its own wants. Your residential estate may back onto your neighbour’s toxic waste dump.
Each could build very effective and good roads within their neighbourhood – but what happens when that road crosses into another neighbourhood? You need to be looking at engaging with your neighbour and convincing them that their side of the road is at least as important as you have it. Otherwise you may find your 6 lane super-highway suddenly becomes a dirt track once you cross the border.
Hopefully you start to get the idea.
Not just at the business unit level
While the survey and my examples above talk about different business units, I believe the effectiveness can be just as important locally.
That effectiveness is also just as important in the local team. And when I say effectiveness – are they using IT best practice?
More practical examples
One example I can think about is where one company have a very aligned development team. They had created a solution for the company and it worked really really well for their major client.
When however they landed a second client their solution simply hadn't been built to support it – so with tight timescales – what other option did they have than to “copy and paste” their existing solution?
Because their solutions wasn't effective, they has to spend a lot more IT money to expand it – plus they would really struggle have grown the business at any speed.
Does this seem familiar with that top left quadrant?
Taking a second example, a complex website had been developed very closely between the MD and a developer. The website was very closely aligned to what the MD wanted – which was great. It wasn't built using best IT practices leaving the software in a very complex state. That state was so complex that every change made to it became increasing more difficult (and expensive) to change and test.
Thus the alignment trap.
How to escape the trap
Returning to the original article, it was interesting to see that the advice on escaping the alignment trap was to drop back into the maintenance zone first. Then move into the well-oiled IT. And finally re-align with the business to move into that IT-Enabled Growth quadrant.
That isn't going to be a quick exercise.
It will likely take time and investment.
In most organisations we are talking years rather than months.
Looking at the rewards (reduction in IT spend/ increase in annual growth) – this to be a good business case to investigate it.
Summary on ROI
The graph summaries it well:
- If you’re in the Alignment-Trap quadrant then you’ll be incurring additional IT cost and suffering from reduced growth
- If you’re in the Well-oiled IT quadrant then you’ll be spending less on IT and getting better growth
- If you’re in the IT-enabled growth quadrant then for the sacrifice you are making on IT cost savings, the growth is considerably more