I spent a fascinating morning yesterday with the head of transformation design in a UK government department. Like most government departments, the transformation is about cutting costs while improving outcomes. The lever for achieving this is technology – in particular, digital technology.
The transformation program has been funded and has been underway for a year or more. The problem we were discussing had two parts to it. First, how can the leaders be sure that the transformation projects that are underway will deliver the strategic intent (cut costs and improve outcomes)? Second, since some projects are over spending, how can the leaders decide which projects to cut out or cut back?
Step one in dealing with these questions, of course, is to get really crisp about the strategic intent. I thought that the department had done a good job – here I am simplifying a little to maintain confidentiality – but there appeared to be good clarity about the objectives of cutting costs and improving outcomes. The department had also done a segmentation of types of citizens that it was interacting with, and it had sub-divided the overall transformation program into sub-programs and then into projects. So what was the issue? The sub-programs were not aligned either with the strategic intent (e.g. sub-programs for cutting costs and sub-programs for improving outcomes) nor with the types of citizens (e.g. sub-programs for citizen group X aimed at both cutting costs and improving outcomes and sub-programs for citizen group Y, etc). Also, the sub-programs and projects had not been prioritized in terms of their expected impact on the strategic intent.
The head of transformation design asked for advice on whether a different transformational methodology would give more accurate strategic alignment. One approach that had be suggested to him was to use “capabilities” as the connecting tissue between strategic intent and projects. By listing the capabilities needed to deliver the strategic intents (level 0), then listing the capability components for each capability (level 1) and then the requirements for each capability component (level 2), etc, it should be possible to connect projects to intent. I felt uncomfortable with this approach, because I could not see an easy way of breaking “cut costs” or “improve outcomes” down into a MECE (mutually exclusive and collectively exhaustive) list of capabilities … and, even if this were possible, developing MECE lists at level 1 and level 2 would be difficult … and, even if this were possible, connecting level 2 lists to projects would probably also be difficult.
So I suggested another way of linking strategic intent to projects: chunk up the department into smaller pieces each of which should be trying to “cut costs” and “improve outcomes”. Here the value chain map tool is powerful. So my suggestion was to start with the citizen segmentation (again I have simplified a little to protect confidentiality) and to develop value chains for each segment and for each product or service provided to each segment. Then lay out a simple value chain for each of these segment/service combinations (probably around 100 in total). Then apply the intent – “cut costs” and “improve outcomes” – to each of these 100 value chains.
This will provide a MECE list of the changes needed. This list of needed changes could then be set against the list of transformation projects to see if the projects cover all the needed changes. If not, the intent will not be delivered.
By rank ordering the 100 segment/service combinations based on their strategic importance, and then ranking the needed changes by likely impact on “cutting costs” or “improving outcomes”, it would be possible to rank order the projects by their likely impact on the strategic intent. This will then make it possible to decide which projects to drop or cut back.
The conversation reinforced a concern I have with the capability mapping approach to operating model design (see previous blogs). The head of transformation design also explained that the differing languages of design and Portfollio management sometimes clashed. Whereas my experience is that leaders readily connect with the value chain language and visual representations used to support it.
Of course, in some ways, it is just a different use of words. What I call a value chain could also be called a capability chain or a process chain. But, in other ways, there is a huge difference. The value chain mapping approach encourages you to chunk the organization up into “segments” each of which is aiming to deliver value to a target customer or beneficiary. So your focus is on what the organization is trying to do for its stakeholders and to a presumption of decentralized units each targeted at a different segment. The capability mapping approach encourages you to chunk the organization up into capabilities. The focus switches to being more internal, and to a presumption of centralized functions in charge of these capabilities. These are very different ways of thinking about organizations. The former is more likely to help you connect with strategic intent.