What is the role of a capability map?

Posted on February 4, 2014 by Andrew Campbell

I have been thinking about capability maps. One of the participants on my course Designing Operating Models http://www.ashridge.org.uk/dom had a consultant do a big capability map as the first step in designing a TOM. I think it is also one of the first steps in Enterprise Architecture – but I am less familiar with this process.

She explained that she was overwhelmed by this capability map, as were her executive colleagues. It did not seem to provide any leverage for creative thinking, and it did not help with the communication of either the current state or the “to be”. This made sense to me, because I have often looked at capability maps and wondered if this is a good way into the problem.

So I have been thinking about what I do.

I like to start with a visualisation of the current state. I like to put the key stakeholders on this visualisation. So, for a retail business, we laid out the link between customers and suppliers. We started with customers, then put marketing next, then the service engineers who visited customers, then the three retail channels, then logistics, then commercial, then suppliers. Support activities like Finance and HR were positioned alongside this flow. Sometimes the visualisation is a flow chart like this. But other times the visualisation is an organisation chart as a model or maybe a map of locations or … The key is to identify some of the major activity chunks and how they relate to each other.

This visualisation then makes it easy to conceive of alternatives – to do “what ifs”. One can move the chunks about on the page and think about different relationships and even different chunks. I don’t particularly think of the chunks as capabilities, although they could be converted into capabilities.

I then like to choose a few (one or two or three) chunks to focus on. I choose ones that I think are interesting because they affect other chunks or because they are likely to change a lot or because they are being affected by technology or because they link to a critical stakeholder. So in the retail company we focused on Commercial because it links to suppliers, is a major power base and drives what goes on the shelves in the stores or on the website.

I then go through the visualisation process again at this lower level of detail, often going right down to the lowest level of detail to understand the processes used by the buyers or how the buyers control shelf-space allocation or.. Here I might lay out some detailed process and wonder how it could be done ten times as fast and at a tenth of the cost. I might also wonder what would happen if the incentive structure is changed for these people or if the department is staffed by different kinds of people. I do thought experiments at the lowest level of detail using my PILOS model – process, information, location/property, organisation/people and suppliers – and tools like IDEA or ASIAA or SPACI. This detailed work usually generates some insights that are relevant to the design challenge at the highest level. The insights often come from a better understanding of how this chunk links to other chunks or how this chunk could transform its work.

I like to have agreed some high level design principles to help me as I am wallowing in the details. But, some thought experiments will not be driven by design principles. The process is more creative than that. Also, the details often suggest additional design principles that are relevant at a higher level.

Exploring the detail in a couple of areas gives energy for creative work on the “to be” visualisation. Often this involves changes in power structures and some tough political fights. These cannot be won with a capability map. You need clever ways of representing the “to be” and clever arguments about why it will be much better for the business.

Once I have a “to be” agreed, then I clarify what falls within each of the chunks, how they relate to each other and what capabilities are needed within each chunk. This is where the capability maps start to be useful. But sometimes I go straight to the elements of my PILOS model – processes, information, location/property, organisation/people and suppliers. Of course a capability is just processes, information, people, property and suppliers – so one is doing the same work, but it is often easier to go straight to PILOS. Of course the process, etc exists to achieve something, so it is critical to think of the design principles for the process particularly those that come from the stakeholders of the process. Defining it as a capability can be helpful, but is not always the most helpful thing to do at this stage.

Ultimately one moves down to detailed process mapping, job descriptions, data capture rules, decision authorities and such like. At this point is it sometimes quite helpful to have a capability descriptor to help guide some of these low level choices. But good design principles are just as useful.

So what is the role of a capability map? Varied and not always useful. What do you think?

Since writing this blog I have been exposed to a few more capability maps.  My thought is that the main benefit is that they help with issues of ‘standardisation’ across organisational units and ‘integration’ between different processes.   The people who have developed the maps – the enterprise or business architect – has enough knowledge to be able to point out opportunities for standardisation and areas where integration issues may have been overlooked.  It is a bit like the Knowledge for a London cab driver.  It save the client having to figure out the best route.

I can see why capability maps are useful to business improvement experts.  They can identify “maturity” (or skill) levels and pinpoint important capabilities that need attention.   I can also see why capability maps are a useful aid for resource allocation.  It is possible locate improvement projects by capability to see if the company has a balanced approach.

But I do not really understand the attraction of capability maps for enterprise architects.  It seems to me that these are artifacts that should be produced after the design work has been done rather than as part of the design process.  So course, if you are making small adjustments from an “as is” to “to be”, then a capability map may be a good way of representing this.  But I do not see it as a primary tool in the process of design.

 

Posted in Capabilities, Design steps, Design tools | Tagged , , , | 6 Comments

Design process

Posted on January 26, 2014 by Andrew Campbell

I am in the middle of designing a course on Operating Model Design for a client. So I have been observing my behaviour. I understand what the client wants, but there are lots of ways of achieving the end result. How have I been doing the design work.

Some of the design principles or constraints are things like – 2 days, 19 people, 4 internal projects to be discussed hence lots of break-out sessions, no overnight work because participants will be going home, etc.

Rather than go at the problem top down – strategy, design principles, options, evaluation – I have found that I have gone about it top-down and bottom-up. So, yes I have spent time getting clear about the strategy: what this event is expected to achieve for each of the stakeholders. But I have also been focusing on the core sessions that I think will prove critical – the break out sessions. By laying out all the possible break-out sessions, I concluded that, the first design choice would be to decide which of ten possible break-out sessions to run. Having chosen 5-7 sessions, I then worked out the optimum amount of time for each session. This required defining what the break-out task should be, how much time would be needed in plenary and how much input would be needed to brief the session. This process helped me realise that we only had time for six break-out sessions.

With this back bone of break out sessions, I then began to design other sessions around them. Obviously the introductory sessions at the start, but also linking sessions, change of pace sessions and sessions involving switches of media.

The bottom-up design was then challenged against the top down objectives and against my knowledge of what makes for a good event. The final step will be to have the design challenged by the client.

If I had had access to participants, I would, of course have called three or four in order to understand their expectations and needs. These have been relayed to me by the client, so I am working with second hand data – always dangerous when doing design work.

Conclusion: Design involves top-down and bottom-up approaches. It is often necessary to design the details of critical components before finalising the overall design. Judging which details need to be designed early is the key.

Post script: I once worked on designing a matrix structure. I knew that the structure would only work well if there was a good process for linking product developers with markets. But, I failed to insist that this process was designed before the matrix structure was finalised. As a result, the new matrix structure was implemented without the critical linking process. Performance dropped, the company was acquired and most of the top managers were asked to leave. A pretty bad outcome for a design process mistake.

Posted in Design tools | Leave a comment

Understanding design principles

Posted on January 26, 2014 by Andrew Campbell

I had always thought of design principles as objectives that help the designer choose between options. But, as I worked, I realised that design principles only provide guidance towards an acceptable solution space. Within that space there are still many choices to be made for which one needs additional decision criteria.

But design principles have another use. They help during implementation of the design. Not only do they help the different parties understand the higher level objectives, but they also help when those implementing the design come across something that has not been anticipated. They continue to give guidance towards an appropriate solution space.

The problem though is how to develop design principles. Of course this can be done informally by talking to people. But, is there a methodology that is a little more rigorous? My own method is to start with the stakeholders of the “thing” that is being designed – customers, suppliers, employees, shareholders, etc. What is each of these stakeholders expecting from his or her relationship with this “thing”? What should they expect? What is the strategy? The “promise” to each stakeholder is a required output of the design .. and can be turned into a design principle. If the design is good, it will deliver to all stakeholders beyond their expectations.

Posted in Design principles, Design tools | Tagged , , | Leave a comment

Object oriented design

Posted on January 25, 2014 by Andrew Campbell

I am probably the only person on the planet who had not heard of object oriented design. But, today I did learn a bit about it. Forgive me if I have the wrong end of the stick!

So, the idea is that you create a “black box” or a “mock up” in your design. You may not understand what goes on inside the “object” but you do understand how it needs to link with other “objects”: the inputs and outputs. If you are designing a house, a window space might be an “object”. You know the size and what is needed around it, but you may not have decided what materials it is made out of, whether it is double glazed, how it opens, etc. But you know enough about the “object” to continue with your design work. In this way, you do not have to design every detail – you can even leave the final design of the window to someone else – maybe the interior decorator.

The reason I particularly like this thought is that it allows you to mix top-down design with bottom-up design. For example, top-down design is when the architect takes the brief from the client and draws up the outline of the house and the floor plan and the windows and … Bottom-up design might start with some detailed design of the windows, and then, taking inspiration from the window design, adding walls and roof to match.

Maybe I did not fully understand the conversation I had – but I still like the idea of mixing top-down design with bottom-up design. I must learn more about “object oriented” design.

Posted in Design steps, Design tools | Tagged , | Leave a comment

Eight questions to ask your team

Posted on January 24, 2014 by Andrew Campbell

I got an email recently from an organisation in South Africa called Leadership Works. It was about eight questions you can address with your team that will help you have a storming 2014. Here are the eight questions.

1. Why do we exist? What is our main purpose that explains why we call ourselves a team and makes it clear to us and everyone else what we are trying to achieve together?
2. Our advice to ourselves? What are the main lessons we learnt from our successes and mistakes in 2013 and what practical advice do we give ourselves to take into the new-year?
3. What reputation do we have? What are we known for now and what do we want to be famous for by 31 December 2014?
4. What is most important right now? What is the single most important priority that will define success for us in the next 6-9 months and which we must combine all our resources to achieve? State this priority clearly and simply and say how it will be achieved.
5. Are our roles clear and relationships intact? Is it crystal clear who must do what and do we trust and respect each other to get it done?
6. How will we know we are winning? What must we measure and how will this be displayed so everyone can be sure at all times how we are doing?
7. How will we behave? What few behavioural values do we commit to that will guide and bind us tightly together in the next 12 months?
8. What must we stop doing? What projects, priorities, behaviours or beliefs should we say goodbye to – they no longer serve us and detract our attention from what is most important.

Your answers to these questions clarify what you are trying to achieve and why. You can even write up the answers and stick them on your wall or in the coffee area. Leadership Works calls this a Team Performance Charter. Is it part of an operating model? Certainly it will help with the execution of the model.

Posted in Design tools | Leave a comment

Do those involved in business design need an MBA?

Posted on January 20, 2014 by Andrew Campbell

There is an interesting debate about the right training and background for a strategist or someone who does business design or operating model design. First, do they need an MBA or is it more important to have experience of the business, intimate knowledge of the operations and experience of the sector? The second issue is whether an MBA gives participants a broad understanding of different business functions and business models. My own view is that an MBA helps, but if the person does not also have deep business knowledge, he or she cannot do good design work. See http://www.ashridge.org.uk/dom for a course that is designed to give those with deep experience the design skills needed to do good business design.

Posted in Design tools | Leave a comment

Why knowledge of Lean methodologies is not enough

Posted on December 13, 2013 by Andrew Campbell

Lean has been a wonderful influence on organisations all over the world. Since Edwards Deming first extoled its virtues in Japan in 1950, organisations have been finding ways to do more and better with less. Pareto Charts, Spaghetti Diagrams, Process Maps, Root Cause Analyses and associated tools are powerful ways to reduce waste, raise standards, improve quality and cut process time.
Managers who have had Kaizen training and know how to use these tools to help their organisations are both fortunate and valuable.

However, organisations do not survive through Kaizen alone. In fact, Deming’s original suggestion that a focus on quality would ensure an organisation’s survival (see UK Excellence article by John Morgan the August issue) was claiming too much for his new discipline. Certainly Lean methods are a huge contributing factor, but there are other, possibly more important, forces at work in a competitive economy.

Probably more critical to organisation success is strategy and the way the organisation’s operating model is designed to align with the strategy. Lean can help ensure that the operating model is executed efficiently and under a philosophy of continuous improvement. If the operating model is not well aligned to customer needs, Lean will help nudge it towards better alignment. But the tools of Lean are not the best tools for ensuring that the strategy and the operating model are appropriate and are aligned. It is for this reason, that Malcolm Baldridge Award winners can be underperforming organisations. It is for this reason that Lean experts can find themselves improving the deck chair delivery process as the Titanic hits the iceberg.

Hence managers with Kaizen training should also be ambitious to understand operating models and how they link with strategy. With this knowledge they can make sure the operating model in their organisation is aligned to strategy and they can use their knowledge of operations to help develop better strategies.

A strategy is best articulated by thinking about the relationship between an organisation and its stakeholders. Strategy defines on which stakeholders the organisation will focus, what value the organisation will deliver to each stakeholder and what the organisation expects to get in return from each stakeholder. For example a restaurant has lunch-time customers, evening meal customers, chefs, waiters, other employees, suppliers of foods, suppliers of IT and financial payment systems, a landlord, bankers and investors. While the restaurant must have a good value proposition for its customers because without customers it has no revenues, the restaurant must also have good value propositions that attract employees, suppliers and investors. Without employees or suppliers or money, the restaurant cannot provide meals.

Each value proposition is a two-way contract. The restaurant promises customers good food and good service in return for prompt payment. But there are many strategic choices here. Some restaurants focus on rich customers with plenty of time for their meal. Others focus on customers in a hurry. Some restaurants ask for payment in advance for a buffet offering. Others have no fixed prices, allowing customers to pay what they think is appropriate. Others allow good customers to pay at the end of the month. Others have loyalty cards.

To employees the restaurant promises training, pay and perks in exchange for hard work and commitment to the organisation. Again, there are many strategic choices: how many hours of work to offer employees; whether to aim for higher-cost, long-term employees or lower-cost, short-term employees; whether to aim for older or younger employees; whether to pay at the end of each day or week or month.

The value propositions for suppliers and investors and any other important stakeholders involve similar strategic choices. So strategy is about making all these strategic choices. Once made, these choices provide the framework for the organisation’s operating model.

The operating model defines the organisational elements needed to deliver the strategy. There are four parts of an operating model – 4 Ps
– Processes and activities
– Patents and technologies
– Properties and assets
– People and organisation

Each of these elements needs to be designed to support the strategy. If the strategy involves focusing on younger, cheaper, untrained waiters who are only likely to stay for six months, the organisation is likely to need a unit that does recruitment and basic training. If the strategy involves providing faster service than competitors, then the property, technologies, processes and people will need to facilitate speed. If the strategy is to serve rich people in a luxurious ambience, then the property will be in an expensive part of town, the chef will need to have a Michelin star and the waiters will need to be experienced with this type of customer.

Clearly it is important for Lean experts to understand the strategic choices that have been made. This makes sure that they choose the right performance measures against which to assess quality. It also makes sure they avoid changes in the name of productivity that might undermine the strategy.

But there is a more important reason for Lean experts to understand the link between strategy and operating models. Their knowledge of processes and operations can be a vital input to the strategic choices that are made. If the Lean expert knows that it is possible to significantly reduce the time it takes from order to plate-on-table, the strategy could be changed to focus on speed of service. If the Lean expert knows that experienced staff make many fewer errors in recording customer orders, the strategy could be changed to create a value proposition that is more attractive for experienced staff. If the Lean expert knows that quality issues with fresh vegetables are the main cause of stress in the kitchen and customer complaints, it may be better to change the strategy to focus on a less demanding menu and less demanding customers, comfortable with frozen vegetables .

Lean experts have a huge contribution to make to the success of their organisation. But, to be able to bring the full benefit of their knowledge to the aid of their organisation, they need training in the link between strategy and operating models.

Andrew Campbell is a Director of Ashridge Business School and leads a two day course titled Designing Operating Models www.ashridge.org.uk/dom that focuses on the links between strategy and operations.

Posted in Lean, Op Excellence and Op Model | Tagged , , | Leave a comment