Alfred Chandler is famous for writing that “structure follows strategy”, and in many ways, he was right. But often this logic is taken too far, to mean that the org. chart should be the first tool out of the box when a new strategy is defined, and this can make quite a mess. I’ve seen this play out many times, but one particularly difficult experience convinced me that the org. chart is necessary but far from sufficient to enable a new strategy – the whole “operating model” needs to shift, or nobody will be able to get anything done.
Here’s my tale of woe, observed from ringside: A major Bank wanted to advance on the Carnegie Mellon Maturity Index (CMMI, a common framework for comparing the degree to which IT organizations have established repeatable, high quality delivery processes), to both reduce costs and improve delivery quality for the business. To do this, we began by reorganizing IT from business unit aligned delivery “verticals” into a series of functionally aligned “horizontals”, or (so-called) Centers of Excellence. There was nothing all that special about the CoEs – they were made up of the same folks who had managed data, architecture, security, testing etc. in the verticals. Now they each had a mission – to make sure that their function was so excellent that they would ensure the success of the business-led projects they supported, like the one I was responsible for…
At the same time, we began to roll out the company’s first application development methodology, which was totally custom and, in my view, incomplete. For example, it didn’t include the words Vendor or Package anywhere, even though off the shelf software and delivery vendors had become about 70% of the workload, and most of what my program was trying to do. Everything became an exception to the new rules, which meant there were no clear rules, so we were constantly debating and defending every decision.
In the old business aligned structure, each IT group had one customer and controlled most of the resources they needed to deliver on their commitments, and they were pretty good at it. Of course there were redundancies, but it generally delivered what the businesses needed.
Now, every project had to be delivered across a complex matrix of functional Centers lending their staff to the project and withholding their support when they disagreed with the direction of the project.
Chaos ensued, as key decisions got tangled in the matrix – how many testers do we need, 8 or 23? Shall we have account-level data or summary level data? Are our requirements sufficient to proceed from Design into Development. Who even gets to make these decisions – the business unit? the CIO? the Center of (so-called) Excellence??? The functional representatives on our team became trolls at the cross roads, forbidding us to pass until we could satisfy their (undocumented) requirements. OK, I’m a little biased…
Chaos was followed by analysis paralysis, project delays, scope and budget creep, and ultimately about $150 million in IT write-0ffs, as several large programs failed or had to be radically restructured. Before long, the Bank quietly declared a new strategy, and reorganized IT back to the original business aligned structure.
I hope that this example illustrates that it takes a lot more than a new org. chart, aligned with strategy, to make good things happen.
An effective IT Operating Model tells the entire organization how to get all things IT done, in a clear, integrated, business-focused way. It starts with a statement of business objectives and strategy – what are we trying to accomplish and what choices have we made that will lead to success? Then, it’s worth being clear about the IT capabilities that are in and out of scope. What is provided by internal resources? What is outsourced? What is missing?
Once the context and direction are established, the org chart can to be drawn in a way that will make most of the work as easy as possible. As advanced as some matrix organizations have become, people naturally understand and follow the solid lines. But the chart is not enough – the roles and responsibilities need to be spelled out, particularly decision rights for typical scenarios. Does business decide if we do the work off-shore, or does IT? Does IT pick the software package, or the business.
Next, the governance structures that overlay the solid lines need to be laid out – ideally as little governance as possible. Think State vs Federal rights, and define when the central IT organization will pre-empt local decisions for the sake of architecture, security, etc.
Once the solid and dotted line roles are defined you can lay out the key process steps and supporting tools to enable decision-making, so that everybody understands the “game”. Tie it all together with a simple set of reinforcing metrics and incentives – you get not just what you measure, but what you reward.
After reflecting on my painful experience at the Bank, I’ve used this framework to design and implement IT Operating Models for over a dozen corporations in several industries, and while the discussion is often similar, the answer is always unique to the strategic context and direction of the client.
More to come on how to not only design a new IT Operating Model but make it “stick”…
