is not damaging the company neither is aligned with the company objectives.
Secondly one needs to consider the context of the research, namely, alignment is being considered in comparison with effectiveness. If your organization is experiencing problems - and the chances are it is simply because 74% of companies do - then it is faced with the question of which to improve first: effectiveness or alignment?
The insight from the research is not that it is not wrong to improve alignment, rather, when effectiveness is poor it can be harmful to focus on alignment first.
This fits with my own experience: when delivery is ineffective it is not possible to have good conversations about what to do. Organizations that cannot deliver spend a lot of their time agonising about their inability to deliver. The narrower the delivery pipe, the hard it is it to decide what to deliver.
The Bain research offers another explanation, and again it is one that fits with the Agile agenda: the loss of effectiveness is in part due to complexity. Keeping IT departments effective means controlling complexity. Improving alignment alone does nothing to improve effectiveness.
Once complexity is managed, once organisation can deliver then it is time to tackle alignment. Its a question of timing.
Do both together
Some respondents asked why an organization couldn't move diagonally, from the maintenance quadrant to the growth quadrant in one bound. As attractive as this idea is there are several reasons to take the longer route.
Tackling effectiveness then alignment allows management and staff to focus on one issue at a time. Rather than spread available time and resources thinly it is better to achieve one thing at a time.
Attempting both changes at once will increase the risk of change as well. Should the team succeed in increasing alignment but fail to bring about the necessary effectiveness improvements the group would move themselves into the alignment trap, the worst place to be. Sequencing the change remove this risk entirely.
My experience suggest one reoccurring causes of the alignment trap is a breakdown of trust. When IT departments fail to deliver on business needs the business responds by demanding the next project is bigger, better and faster than the previous one because they don't trust IT to deliver. At some level the hope is that by asking for a lot more they will get a little bit more.
The IT department responds promising less and erring on the side of caution. Estimates are increased, time and cost budgets padded.
The result is an arms-race and a breakdown in trust. It is no longer possible to have a constructive dialogue between the two groups.
When IT acts to put its own house in order first, adopts Agile and moves itself from the maintenance zone to well-oiled zone it demonstrates it can deliver. As the delivery record improves trust is rebuilt, dialog improves and it is easier to fix alignment.
My method already does this
Another response has been to claim that Agile method X already bridges this divide. The claim may hold for some methods for the most popular Agile methods, XP and Scrum, the claim does not stand up to analysis.
XP is very delivery focused and deals with requirements by an onsite-customer. XP is based on the belief that the customer will know what to do. The method itself says nothing how the customer knows what needs doing or what methods they use. There is no equivalent of TDD for customers.
The XP customer provides both the requirements and is the subject matter expert. There is no