When designing an operating model or business architecture, the team are often confronted with the issue of needing to clarify the strategy. For example, how many new service areas is the company planning to develop or how important are back office synergies versus local flexibility and initiative or is product innovation more important than tailored solutions or vice versa?

Why are these kinds of issues not made clear in the strategy? The strategy usually focuses on ambition “we will grow by developing new service areas” or “we will improve margins by exploiting back office synergies” or “we will be market-led”. Strategic plans often fail to explicitly address the dilemmas that are so important to operating model design – “is close to the market more important than technical innovation?” – because leaders are focused on defining a path forward rather than a blueprint for implementation. As those who work on the blueprint get closer to those who develop strategy, there is more potential for these issues to be addressed in the strategic plan. But, currently, in most companies, the enterprise architects or business designers do not usually have much dialogue with the strategic planners while the strategy is being developed.

The best way of solving the problem of unclear strategy is to use scales, laying out the choices that need to be clarified so that the extreme positions are at either end of the scale. So one scale might be market-led versus technology-led. Another scale might be one new service versus six new services. Another scale might be total back office unification versus only unify the low hanging fruit or only unify those activities that do not reduce local flexibility. These scales can then be presented to the strategists or top team for debate. The current strategy can be positioned on these scales where it is clear, helping to expose where more clarity is needed. Also, by laying out the scale, this tool helps strategists realise that they need to explain why a particular choice has been made. It is these reasons why, that are often most helpful to those designing the operating model. (see previous blog on developing good design principles).