How much detail do you need

Posted on April 30, 2014 by Andrew Campbell

This is a re-post of a previous blog that I have had to trash because it was attracting a stream of spam.  If you have read it before – my apologies.

In a recent workshop, we were working on operating models for four parts of the business. It was only a two-day workshop so we had to keep our work at quite a high level. This involved drawing pictures of the operating model, and then picking out different aspects, such as organisation structure or information systems or core processes and doing some work on them. We also used some good tools to stimulate creative thinking: to get people to think out of the box.

The workshop generated huge energy and interest partly because participants could see both how siloed the company had become and how complex it was. Big themes like smarter, more connected and simpler were being championed. And there were lots of individuals with new ideas about how to review their own areas of responsibility.

One of the issues that came up was about when to get into the grinding detail of process mapping and data architecture and so on. Should the high-level operating model be agreed before work is attempted on lower levels of detail? This seems like the obvious answer; but my own experience is that it is more complex.

I found that the sessions where we delved down into the detail on a particular process – for example reviewing the process using the IDEA tool (increase, decrease, eliminate, add) or the ASIAA tool (aggregate, standardise, integrate, arbitrage, adapt) – were the ones that generated the most radical new insights. These insights had the potential to change the high-level design. So my conclusion is that you need to work at the problem from both ends. You need to identify some areas of detail to delve into, then step back and look at the big picture, then dive into some more detail, etc.

One way to do this is to have multiple teams working simultaneously – simultaneous design!

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

Maybe there is a role for a capability map

Posted on April 16, 2014 by Andrew Campbell

Last night I was reading Roger Martin’s book “Playing to Win”. It is mainly about P&G. The chapter I focused on was the one where he talks about core capabilities.

He draws on Michael Porter’s article “What is strategy?” and argues that the first step of executing a strategy is to define three to seven core capabilities that the strategy relies on. These are things that the company will do better than competitors which will allow it to achieve the market position and profitability that it wants.

Martin argues that there are usually a cluster of these capabilities that are linked together in an important way that makes them doubly hard to copy.   For P&G the capabilities are things like – being better at understanding the unmet needs of consumers, being good at creating global brands, having more scale benefits, knowing how to work productively with large retailers.

Typically these capabilities are some of the main steps in the value chain – gain consumer insight, develop products, build brands, distribute products, etc.   But he points out that P&G does not need to be world class at all the steps: manufacturing and some other elements of the value chain are less critical to P&G’s strategy.

He then takes these capabilities and creates an “activity system map” or a logic map, showing how the capabilities connect and reinforce each other, but also showing how other supporting capabilities or resources or other elements of the operating model support and connect to the capabilities.   I reproduce his exhibit from the book (hopefully this is not breaking copyright).

Slide1

This seems to be a really good use of capability mapping.   As you may know from my earlier blogs, I have a hard time understanding the business benefit for producing a comprehensive “capability reference model”, but I can see the power of a focused “activity system map” or “capability logic map”.   In fact, a map like this could be a way of visualising the operating model.   I think I might add some stuff to it, like customers, consumers and suppliers – so that the links with stakeholders are clearer.   I might also add some location information – partly because the key to consumer insight is to sit with consumers in India or wherever, but the key to technical innovation is to have some centralised R&D labs.

Maybe I am getting closer to my quest for clarity about the role of capabilities in designing a target operating model (TOM).

Posted in Capabilities, Design steps, Design tools | Tagged , , , , , | 1 Comment

Working with the Client/Sponsor to get a good brief

Posted on April 15, 2014 by Andrew Campbell

Last week I was leading a workshop, mainly for training purposes, but we used a live organisation issue.   A recently appointed manager volunteered his organisation partly because he was planning to make some significant changes, partly because his organisation was hemmed in by a number of tricky constraints and he wanted to get some ideas and partly because his organisation was facing a major change in its environment.

So, after I had introduced to the group the concepts and tools that we were going to use, the manager gave us his brief. He did not have a formal presentation. So he started with some history.   Then he looked ahead at the changes in the environment. Then he started talking about the constraints. Interestingly, in all his opening remarks, he did not clearly define the problem or what he wanted us to do.

In the question session, the group got very excited about the constraints and asked endless questions about contracts of employment and flexibility in these contracts and constraints imposed by other departments and so on. This was familiar ground for them – so they were more comfortable asking questions about these aspects.

I let the discussion continue until the time was almost up, before I intervened with a question about the scope of what he wanted us to do and the deliverables.   I then used this “experience” as a lesson for the group, about the importance of getting the scope and the deliverables defined as early as possible in the briefing process.

It turned out that the scope was sufficiently narrow that many of the questions we had been asking about the constraints proved to be unnecessary: the constraints were not going to be challenged – at least unless we renegotiated the scope of the work.

Afterwards, I was reflecting on why less experienced managers don’t focus on getting clarity on the scope and deliverables. I have noticed this before, both in workshops and in real projects. A manager can leave the CEO’s office having been briefed about something without real clarity on what he or she is supposed to do. I do not have a clear answer to this ….. so please comment if you have an answer.

My supposition is that it is partly, that managers are nervous about asking questions on subjects they do not understand well, in case they expose their lack of understanding. But also, those defining a brief are often reluctant to define the brief too narrowly because they are expecting the person who is helping them to bring some of his or her ideas to the discussion.   Hence, it is not unusual for both “client” and “project leader” to dance around each other.   In my experience this is not productive. The most useful thing the project leader can do early on is to push the client to define what he or she wants.

After we had worked on this problem for a day and had a review with the “client” at the end of the day, the client gave us an even tighter focus for the second day of the workshop.   While our wider focus on the first day, had not been wasted (we had come up with some helpful ideas), it turned out that the problem which he did not have clear in his mind was even more limited than he had been prepared to express up front. He really just wanted help with defining the operating model of one department within his larger organisation. So why didn’t he say this up front? “Well I did not want to constrain your work too much”, was the response.   So clients need a bit of education on how to brief well!

With this tighter focus, we did some high quality work on the second day – and learnt a good deal about operating models and organisation design in the process.

Posted in Getting a brief from the client | Tagged , , , , | Leave a comment

More on business models and operating models

Posted on April 12, 2014 by Andrew Campbell

I recently came across Deloitte’s framework for business models and operating models (see exhibit below).   I was quite taken by the framework and began to think about what it is missing and why or whether my framework is better.   It is always good to keep challenging any framework you use because it can become a toxic influence on your work if it is not appropriate.

The first observation is that Deloitte uses the term business model to cover only the front end target customers, channels and the product and service value propositions; whereas I use the term business model to cover the whole subject.  For me the term business model is the big term – like strategy – everything else is a subset of business model.

However, Deloitte’s approach is similar to the approach in Enterprise Architecture.   The term Business Architecture refers to the front end of Enterprise Architecture.  Other components of Enterprise Architecture are Technology Architecture, Information Architecture and Applications Architecture.  Although the split may be a little different again. I think Business Architecture also includes process architecture so it is not exactly the same definition as Deloitte.

Another difference is that Deloitte does not include people or people policies within its definition of operating model.  Deloitte has a separate concept: People Model.  At one level I like this idea because I think there is often some really interesting opportunities that come from re-thinking the people model.  For example, one IT services company set up its operating model to be attractive to women with children working from home.  The company spotted that there is lots of under-utilised talent in this people pool and designed a good business.  In the same way Eden McCallum developed a different kind of consulting company out of the observation that there are lots of capable people with portfolio careers. Mark Warner has built a business model around gap year students.

At another level, this separation of people model from organisation design feels odd to me.  I do not believe that organisation design should be done without taking account of the available people.  In other words the design will change depending on the people you have, particularly at senior levels.   So people and organisation are hard to think about separately.  Hence, I include both as part of my concept of operating model – although I like to encourage some separate focused thinking about the people dimension.

Deloitte’s framework is also missing some things that surprise me.   It does not include suppliers and business partners – for me a vital ingredient to the operating model.   It does not include intangibles, like brand and IP; which for me are also important.  It does not include location, another significant part of the design challenge in my opinion.  Although, in Deloitte’s framework, location may be a subset of “physical assets”.  Possibly Deloitte also include brand and IP under “physical assets”.

Finally, Deloitte’s framework does not include the financial  model.   This maybe because Deloitte’s, being an accounting firm, ssee the financial aspect of the operating model as an integrated part of all the other choices – and hence all pervasive.  However, in my experience it is helpful to do some design work on the financial model as a separate step.   What are the ratios going to look like?  And, how do the ratios work so that there is a good profit margin and a good return on invested capital?

Slide1

Posted in Business model, Design tools, Enterprise architects and operating models, Strategy | Tagged , , , , , , , , , , | 3 Comments

Some thoughts on the process of design

Posted on April 2, 2014 by Andrew Campbell

I have realised over the years that the flow charts we put together to describe the work steps of a design project, which look very neat, dovetail into each other and make all kinds of rational logic, don’t describe what happens.

So let me have a go at describing what happens.   First, there is a brief from the “client”: the person who wants some change or improvement.   Part of the brief is about what is important, part is about the history and the journey to today, part is about the stakeholders, part is about constraints, and so on.   I have learnt not to try to get all this in one briefing but rather to have a check list of things I need to know, and pick up the missing bits early in the assignment.   So the “briefing” work step often spans the whole of the first week or month of the project.

But, after the first meeting, stuff starts to happen in one’s brain or amongst the team.   A view starts to form about what the problem is and what sort of solution is likely to emerge.   This is dangerous work.  Every work plan will say do the diagnostic before coming up with solutions.  But the human brain does not work like that.  In fact, the brain often does not really understand the problem without thinking about it in terms of a solution.  “Oh, I see what we are talking about.  We are trying to decide whether to create a shared services division or not.”

I like to log these early solution ideas – in part as a guide as I go through the rest of the project.  If I start getting towards the end of the project and I find that I have not re-framed the brief – in other words come up with a very different understanding of the problem or the solution than I had immediately after the briefing – I start to worry.    In my experience the best solutions to complex problems are non-obvious ones: in part because the obvious ones have already been tried or rejected. But I also try keep the rush to solutions at bay by focusing on design principles (see earlier blog on how to create good ones).  In fact, one of the things I like to do following a briefing is to extract from it anything that I think is a design principle.  Part of the on-going briefing is about putting these emerging design principles in front of the stakeholders to get their reactions.

Following the briefing, there is a period of diagnostic or “immersion”.   There are a couple of things going on here.  There is a need to get one’s arms around the context: to know enough about everything to know what is in the box and what is outside it.  Interviews with all sorts of different stakeholders.   Discussions about what goes on in all the different departments and so on.   This phase can be structured around a “databook” or it can be a looser process of following ones nose.   The latter is best for insight generation.  The former is normally more useful for documenting conclusions.   Sometimes, it is possible to do both.  Have part of the team complete a databook and the other part wander around talking to people.

A critical judgement here is about where to get into more detail (see posts on ‘detailed information’ and ‘going to Gemba’).  You never have time to understand all the detail.  But you must understand some of it.  Customer journey maps and getting close to customers normally pays back.   Getting close to critical employees is also often powerful.

Diagnostic work can go on for ever … and cost your client too much.  So how do you keep it under control?  By focusing on design principles.   As you learn more, you add to your list of design principles or you refine the ones you already have.  When you stop making changes to your list of design principles, you have arrived.

This is the signal for some structured thinking about options and solutions.  Of course this thinking has been going on since day 1, whether you like it or not.  But, it is helpful to have some structured time on options, where you deliberately identify some extremes and deliberately flush out some of the options that lie between the extremes.

Evaluation is supposed to come after option generation.   But in practice these two steps are more iterative.   It is hard to think of a solution without evaluating it, and the process of evaluating one solution often leads directly on to another solution.   So, option generation and evaluation often go along in parallel.   The only time I try to deliberately turn off the evaluation filter is when I am generating ideas for extreme solutions – these nearly always fail the filter, but are useful as boundary markers, for stretching creativity and for challenging the status quo.

Of course evaluation, against design principles and against other challenges, such as ease of execution, is supposed to be a separate step in the process: generate options and then do evaluation.  But, in practice it is much more muddled together.   Also, new design principles emerge at this stage.  In fact it is not uncommon for re-framing to happen during option generation or evaluation:  the problem gets seen in a different light, for example it becomes a problem of customer segmentation rather than one of under performance or it becomes an issue of capability rather than clarity of roles.  When this happens it is helpful to stop and go back to the beginning.

Imagine what you would have done if the original brief had been articulated in this new way: what different stakeholders might you have talked to; what different bits of diagnostic might you have done; has Gemba been defined differently?  Where there are differences you may need to redo parts of the briefing or diagnostic steps and reconsider your list of design principles.

The end of the journey is some agreement by those who are involved that the proposed solution is a good one.  This can only be achieved with face to face discussion and a willingness to adjust the solution to accommodate relevant inputs.  I like to start this step as early as possible, often involving people up front as stakeholders, checking with them the wisdom of the design principles, getting from them their solution ideas, working with them to evaluate solutions, and so on.   But this is time consuming and can distract large amounts of people from more useful work – so a balance is needed (but rarely found!).

At the end of the process you should have a pretty well designed operating model.

 

 

 

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

Strategy, change and involvement

Posted on March 31, 2014 by Andrew Campbell

I was reading a post by Amy Gallo of HBR on change and …. it got me thinking.    First, some of the highlights.

– 95% of transformation projects fail (this seems high to me – the McKinsey figure is “over half”)

– don’t separate strategy from action (but lots of the people who are good at action are not good at strategy and vice versa)

– involve lots of people when you are making change (yes but this is expensive and time consuming)

So what do I think about these issues.   First, that, if you want someone to do something creative and non-routine, you need to engage this person in a dialogue that results in them being just as excited about the ambition and just as knowledgeable about the challenge.   Ideally, you want to get them to come up with the idea for change and suggest it to you.  But, often this is not practical – you have already had the idea.  So, in this case, you need to share with them as much of the situation that has caused you to come to a conclusion … and see if they come to the same conclusion.  If they don’t you need to engage in a dialogue and arrive at a jointly agreed way forward.

The process is a bit like briefing a consultant.  You tell the consultant what you are trying to achieve and as much about the situation as possible.  But, you then expect the consultant to do some thinking and data collection of his or her own and come back to you if he or she thinks that your ambition or understanding of the situation is part of the problem rather than the solution.

The bottom line of this way of thinking is “beware being too forceful” – “look for engagement more than loyalty”.  A rule of thumb I use is “strategy – the clever plan bit – should be developed by the person who will lead the action”.  So I often find my self asking – who developed this and who is going to lead the implementation.  If they are different, I start to worry.

But, I also recall a CEO I admire explaining to me that leadership can require the most enormous amount of will power.  The forces of resistance can be so strong and so misguided that you need to “nail your courage to the sticking post” almost every day.  This seems like the opposite of “beware being too forceful”.    I square this circle by arguing that, in this situation, the CEO is “leading the implementation”.   In other words, if you are having to use a lot of will power to get something to happen, then you are leading, you are not letting them lead.

So it is OK to “be forceful” if you are willing to lead.  It is not good to be forceful, if you want the other person to lead.   The danger of leading is that you get followers under you who do what you want rather than leaders who do what is needed to achieve success.

I am not sure what this has to do with operating models!  Maybe it says something about who should design different parts of the operating model.  As work on the model gets into more detail, each sub-leader should design their own part of the operating model.

 

 

 

 

 

Posted in Strategy | Tagged , , , | 1 Comment

Levels of design and dimensions of design

Posted on March 21, 2014 by Andrew Campbell

In the last week I have been wrestling with levels and dimensions – all part of ongoing work on the Operating Model Canvas.   Here is where I have got to.

There seem to be five levels of design

1. Strategic goals/ambitions expressed as design principles (see blog on design principles)

2. One page drawing of the operating model plus an Operating Model Canvas analysis

3. Activities defined in terms of “capabilities” and “sub-capabilities” and high level “process maps”,  distinguishing between “operating” capabilities and “support” capabilities (an outcome of my organisation modelling tool), distinguishing the most important for success from the rest, and showing the links between “capabilities” and “resources” – this is a bit of a mouthful and I need to simplify it  … but this is where I have got to.  “Resources” covers people, locations/buildings, other assets (brand, IP, etc) and data (PLOD!).

Levels 4 and 5 are different depending on the dimension of the design that is being focused on.   So for the Process dimension – level 4 is about detailed process maps using a notation such as BPMN (Business Process Modelling Notation) and detailed decision analysis using an approach such as TDM (The Decision Model).  Level 5 is the development of the information systems needed to support the processes using a tool such as UML (Universal Modelling Language).

For the People dimension, level 4 might be detailed organisation structure charts with numbers and types of people needed for each box in the chart. It might include an analysis of responsibilities using tools such as RAPID or RACI.  Level 5 would then involve detailed job descriptions for each role, draft contracts of employment and such like.

For the Locations/Building dimension, level 4 would be a detailed location chart specifying the size of building required in each location and other infrastructure needs.  Level 5 would be detailed building floor plans, wire routing and so on.

The other dimensions – Other Assets and Data – would have similar levels 4 and 5.

So there are five levels of design and five dimensions of design (Process, People and Organisation, Locations/Buildings, Other Assets and Data).  The design work is the same for levels 1, 2 and 3 for all dimensions.  It only starts to become different at levels 4 and 5.

What do you think?

Posted in Levels of design | Tagged , , , | 8 Comments

Can enterprise architects help lean experts?

Posted on March 19, 2014 by Andrew Campbell

I was reading a blog from BiZZdesign by Marc Lankhorst & Peter Matthijssen, and it got me thinking … clearly a good blog.

The core message in the blog is that lean experts should involve enterprise architects (people who have an overview of the whole operating model … and have probably developed a ten page ‘capability reference model’).

[If you don’t know what a capability reference model is don’t panic: it is just a list of capabilities needed to make the organisation work structured into levels: there might be 10 capabilities at the highest level, 50 or 100 at the next level, and so on.  Some capability maps have five or six levels.   The idea is that an enterprise architect can use this map to identify where capabilities need to connect and link together and where there may be duplication.]

What intrigued me was the idea that the lean expert should involve the enterprise architect in order to make sure that the lean improvements were not sub-optimal: succeeding in one place at a cost to the total organisation.   On the face of it this makes good sense.

But, from a different perspective, it makes less sense.  Surely the lean expert will be using a stakeholder model to understand all the stakeholders that are affected by the process under investigation.  In fact the lean expert will need to talk to these stakeholder to understand them, and maybe even to understand what their stakeholders want from them.  So the lean expert should be well enough connected without “help” from the enterprise architect.    As I understand it, one of the principles of good lean analysis is a focus on the ultimate customer.

So what help can enterprise architects give?  The authors suggest that the enterprise architect can help with SIPOC analysis (supplier, input, process, output, customer).  But, I think this is already a core part of lean analysis.

Offer lean experts previous analysis done by the enterprise architect as input to their work is another suggestion.  I can imagine that this might save some time, but, as the authors point out, the analysis is often out of date and needs to be redone anyway.

Help develop better solutions is a third suggestion.  Here I can imagine that the enterprise architect with a broader view of the whole system will be likely to have some ideas that do not come so easily into the mind of the lean expert.

Share good practices from other parts of the organisation is a fourth suggestion.  I can see the logic here as well.  But for both of these last two points, I can imagine that the lean expert is likely to be working at a level of detail that is much lower than the enterprise architect normally works (say level 5 or 6 of the capability map), hence the enterprise architect may have little to contribute.

So where does this leave me?  It made me wonder about the role of enterprise architects, and also wonder whether the solution might be to educate lean experts in the broader operating model and capability map, so that they are more aware of wider implications and where to look for good practices.  Maybe the enterprise architect is the designer of transformations and the lean expert is the designer of incremental improvements … and they do not need to work together as suggested by the article.  The enterprise architect documents and redesigns the total operating model.   The lean expert promotes continuous improvement in processes within an operating model.

Of course this thinking may be influence by my self interest.  It implies that both need to come on my course Designing Operating Models!

Posted in Enterprise architects and operating models, Lean, Op Excellence and Op Model | Tagged , , , , | 2 Comments

Tips for designing target operating models

Posted on March 17, 2014 by Andrew Campbell

This video describes six tips to help you with designing operating models.   I think you will get more from reading the blogs in this blog than from watching the video,  but if you prefer the human touch, the video will give you more feel for Mark Lancelott and me.   Together we run the two-day Ashridge Business School course Designing Operating Models.

Posted in Design principles, Levels of design, stakeholders | Tagged , , , , , , , , , | Leave a comment

How to get enough information about the detail

Posted on March 17, 2014 by Andrew Campbell

The following is mostly stolen from Don Reinertsen’s article “Going to Gemba”.  But it is worth stealing!  Thank you Don.

In lean methodology, the way to get enough knowledge about details is to “go to gemba”.  This means going to where the action is: seeing it for yourself.  This might be watching operatives on the factory floor or watching customers shopping or watching consumers using your product in the home.

For those unfamiliar with the phrase “go to gemba”, the Japanese word “gemba” refers to the location where an activity takes place, for example, the factory floor. Going to gemba is revered in lean manufacturing. Taiichi Ohno taught observation to new engineers. (Ohno was Toyota’s vice president of manufacturing and the genius behind the Toyota Production System.) He would make an engineer stand in the middle of a chalk circle and tell him to observe and take notes. Later he would return to see if the engineer had observed enough. Ohno believed that observation was the best way to understand what is happening.   So going to gemba is about being there, and about observing rather than interfering.

But observation is not enough in environments where much of the important work is not visible.   Nobel Laureate Daniel Kahneman classifies the tendency to overweight the visible as a cognitive fallacy called, WYSIATI (What you see is all there is.) Kahneman points out that when we observe a situation, we construct a mental model based on its most salient features. Our confidence in this mental model is a function of the coherence of the model rather than the strength of the evidence that it is right. We will weight a small amount of consistent data much more heavily than a much larger amount of data that contains some noise. It almost never occurs to us that the data that we do not see might be important. Simply put, our brains are wired to think that what we observe is all that is going on.

Unfortunately, in many processes the most important information is not observable from your chalk circle.  This is not news to companies where much of the work is a function of talent rather than process. Consider Bill Hewlett and Dave Packard of HP. Like Ohno, they believed it was critical to go to the place where the work was done.  But they used an approach known as management by walking around, (MBWA). It sounds a lot like going to gemba, but it was quite different. In fact, the most important words in MBWA are “managing” and “walking” not standing in a chalk circle. You see, Bill and Dave, who were great design engineers, fully realized that the most important decisions made by design engineers could not be directly observed by merely visiting the workplace. So what did they do? They left the chalk circle. They learned what was going on through active interaction with the engineers.  They asked questions.  They collapsed status differences by chatting, creating low-risk ways for engineers to express concerns and feelings.  They were collecting information, but they were also communicating their goals and values through interaction with the engineers.   They did more than go to gemba.  They shaped while listening.

Of course, as a designer, you are not “managing”.  But you are “shaping”, and you need to “walk”.  As you get into the detail, remember that sometimes you need to stand in your chalk circle and watch; at other times you need to interact, ask open ended questions and chat in a way that will reveal the hidden logic, assumptions, feelings and mental processes; at other times you need to communicate your goals and design principles as part of your shaping work.   Maybe there is a new mnemonic here:  OCQS – observe, chat, question, shape.

Posted in Design steps | Tagged , , , , , , , , | 1 Comment