EA strategy maturity (2008)

I was recently asked to review an IT Strategy document and give my views on it. This document did not appear to come from what I would have called an Enterprise Architecture practice but from a typical IT approach to strategising about how to deal with all the technology in the IT department.

Before starting I thought to myself, what standard should I score this against? This then lead me to think about different levels of Maturity of Strategy implementations (in this case an IT strategy), but it could be used for any strategy I suppose.

Basing my thoughts on the CMM definition I came up with this table below in terms of the levels of sustainability, repeatability and continuous optimization of Strategy:

Level

Conscious

Planned

Governed

Quantitative

Continuous

Description

So level 0 is where there is zero concept of any strategy. The organisation just muddles on, project by project, request after request – firefighting.

Level 1 has a cognitive concept that strategy is important and tries to implement it from a mental model, and give direction in conversation to people, but no more. This tends to come from someone leading but is perhaps not general knowledge in the department.

Level 2 is where a plan has been derived and planned, based upon gathering information in some one-off exercise. This is typically put together for the budget in order to justify funding for the next year or three. Thereafter it is cast aside, once the money has been obtained and the projects have been defined.

Level 3 takes this to the next level, because not only is it planned but over time, it is managed and governed, to ensure this strategic plan actually happens. The reason this has been differentiated as a separate item is because in my humble experience, many of the best laid plans fall away after a few months, as people change positions or business changes occur. Eventually the initial strategy is forgotten, and things devolve into firefighting again unless governed against a baseline. Obviously this does not imply that the baseline cannot change, in fact it will change, but if a new baseline is derived then the governance can continue to monitor progress against the new strategic baseline.

Level 4 goes up another notch by measuring the Strategic Architectural goals met against the initial plan versus the actual delivery. Even if Waivers and Dispensations are given, and these are measured, we have an adea of convergence or otherwise towards the strategy. Capturing daily, weekly and monthly Architecture review board activity metrics, and reporting them regularly over time. This also begins to imply that the Strategy is captured and managed as well, because if things change, we need to record the differences from the initial baseline to the new baselines over time of the Architecture.

Level 5 is where the Strategy evolves continuously, due to the above processes of monitoring, persisting the information and governing the change in a managed way on a regular (weekly to monthly) basis. Weekly. Eventually we reach the situation where it would not be necessary to do a one-off Strategy once per annum for the budgets, but to do one and keep continually refining it and governing it. When budgets are submitted, it is a simple matter of printing out a few diagrams and reports from the decision support system that already exist, ordered by highest risk and current business drivers.

All this would require a foundational set of configuration management, change management and iterative planning to keep on top of the “Models” be they visual or otherwise that make up the Strategy.

Based upon this maturity – the document and it’s contents I saw reached somewhere between 2 and 3, but I was not privy to how they would manage or govern it so I could not say for sure, as its not only about the actual document, but also about how we manage the Strategy over time that makes it more mature.