The governance of design projects

Posted on November 14, 2022 by Andrew Campbell

I recently had an interesting conversation with Tom Cummins of PA Consulting about design governance.  He is doing some research on different approaches to design governance with the idea of creating a framework for helping organisations choose an appropriate and cost-effective governance approach for each design project. 

I pointed out that the jargon (“governance”, “operating models”, “design principles”, etc) that we use when we are thinking about or researching these issues often gets in the way of clear thinking. 

So first, what do we mean by governance.  We mean who makes the decisions and how we make sure that different decisions makers coordinate so that the whole design is aligned with the purpose, strategy and financial constraints of the organisation. We also mean how we resolve differences of opinion or clashes between different designers or design teams. 

Both Tom and I recognise that design work often goes wrong in organisations because different design teams – for example, the Finance team and the IT team or the North American team and the European team – have different design ideas and fail to coordinate well.  They make their own design decisions judging what the organisation needs from their own perspective.  This can result in hard to resolve conflicts or a design that does not fit well together.

I often find it useful to use a non-business example, but one we are all familiar with, to help me think about these issues.  So lets take the example of designing a house.  Lets assume we have five separate design teams: foundations; structure and room layout; plumbing and heating; electricals, sound system and wifi; and decoration.  We can easily see that, without coordination between these teams, the resulting house is likely to be a bit of a camel.

How is this every day problem solved?  First there are the clients for whom the house is being built.  Whenever there are difficult issues, they can be presented to the clients.  Lets assume the clients are husband and wife, and lets assume they do not always agree: the husband holds the financial controls and the wife has strong views about what she wants (or the other way around). 

In this case, the “design authority” is the husband-and-wife team.  Each of the design teams working for them should be careful about making design decisions without checking back with the “design authority”.   To help them, the husband-and-wife team will typically employ a building architect.   This person takes all of their desires and converts them into a blueprint.  He or she then takes the overall blueprint to each of the design teams and asks them to think about how to design and cost the details in their area of responsibility.  Inevitably issues come up not just about coordination, say between the foundations team and the plumbing team, but also about the practicality of the blueprint (e.g. the plumbing team may ask for a wall to be moved to give space for the boiler).  The architect, who is ideally someone who understands the challenges in each of the specialist areas, (something that the husband-and-wife team typically do not), takes all of the issues raised, tries to develop solutions and thinks through whether any of the solutions will be a problem given the expressed requirements  of the husband and wife.  The architect is a crucial conduit between the design teams and the design authority.

The architect makes it possible for the husband-and-wife team to make design decisions even though they do not fully understand the challenges facing the specialist design teams and even if they do not agree.   If the husband-and-wife team do understand all the challenges, have aligned views about what they want and have time to devote to resolving all the issues, possibly doing some of the detailed design themselves, they do not need an architect.   So, some houses are built without architects.  Also, in some cases, one of the specialist design teams, such as the “structure” team, takes responsibility for coordinating with all the other teams and with the client.  Often the architect does the structure design, hence is one of the specialist teams coordinating all the others.

So now lets apply our jargon to this situation.   The blueprint is a high-level “operating model”.  The detailed designs for plumbing or decoration are “detailed operating models” for these areas.   The governance process consists of the husband-and-wife team, the architect and the design teams in each specialist area along with some rules of engagement.  Example rules of engagement might be “the architect will share progress with the client at least once a week”,  “the specialist design teams will not make any design decisions that conflict with the blueprint without checking with the architect”, “the architect will arrange a meeting between all the design teams to share their design ideas every week”, etc

“Design principles and design guidelines” are mechanisms that any or all of the participants can use to help get alignment, for example between husband and wife or between the husband-and-wife team and the architect.  In fact, the blueprint can be considered to be a set of design guidelines for the specialist design teams (in other words a high-level operating model is a set of design principles for lower-level operating models).

So, what do we learn from this example about design governance.

There are some elements of the situation that we need to understand before we choose our governance mechanisms and processes.

  1. How clear is the “client” about what is wanted and how aligned is the “client” on what is wanted.   Since the client is often the executive team, clarity and alignment are hard to get (in my experience).  If the client is the head of the organisation and he or she is clear and is prepared to impose alignment, the governance is easier.  Design principles, design meetings and blueprints are often used to help get clarity and alignment.
  2. How experienced is the client in understanding design challenges and developing design solutions across different specialisms?   In most cases the client does not have the necessary experience or does not have the time.  Hence a designer/architect is needed who does most of this work for the client.  This person must have deep understanding of all the specialisms, plenty of time to work on the problems that arise and the full confidence of the client.  Very few “transformation leaders” or “project leaders” have these three requirements.
  3. How many specialisms are involved and how often have those involved worked together, before, on this kind of a design project?   The smaller the number and the greater their familiarity with each other, the more informal the governance processes can be.
  4. What time and cost constraints exist that might call for lighter touch, rather than heavier touch, governance.

Design projects in my experience go wrong because the governance is not designed to take account of the situation: the number of different political groups who need to collaborate, how much experience they have had with design work, how often they have worked together on projects like this, the degree of alignment about what is wanted at the level where the different groups have a common boss, the capability of project or transformation leaders, and the time and cost constraints. Leaders too often set up standard governance processes, without thinking through the challenges that the governance should be designed to solve.

Posted in Design governance | Tagged | Leave a comment

Process Maps vs Capability Models

Posted on October 16, 2022 by Andrew Campbell

Hans-Christian Grung-Olsen alerted me to an article in BP Trends by Paul Harmon titled Processes and Capabilities.

So first to summarize Paul Harmon’s excellent article. He points out that a process is a sequence of work steps that produce some valued outcome. He used pizzas as an example. The process – take dough, shape it into a pizza, place on a pizza tray, add tomato, cheese and toppings, cook, take it off the tray and place in a box, give the box to the customer and take the money – involves a series of work steps. The outcome is a pizza in a box in the hands of the customer. The “capability” is the ability to deliver this outcome repeatedly so that a series of customers can leave with pizzas in a box.

A capability is not a process and it is not an outcome. It is the ability to create the outcome – the pizza in a box paid for by the customer. It is not the ability to execute the process because it may be possible to create the outcome with a different process. For example, “buy prepared pizza, cook, place in box, give to customer and take money”. The outcome is the same (well the pizza might not be quite as good), so the capability is the same, even though the process is a bit different. Of course, if we defined the outcome as a “hand-made pizza, prepared in front of the customer, in a box ….” then the first process is probably the only one possible. The more detail that you put into the description of the outcome, the more likely you are to have only one process that will deliver it. So “a hand-made pizza, prepared in front of the customer, with mushrooms and peperoni, cooked for 8 minutes in a wood fired oven, served in a recyleable box, paid for by credit card” is almost a statement of the process. The capability is then the ability to execute this process.

“Capability” has become an attractive term because it is possible to define the outcome you want to be capable of delivering without defining the process steps or the organisation. This makes it easier to identify similar capabilities in different parts of the organisation and to centralize them, reducing duplication; standardize them, building on best practice; and invest in innovation, enabling even better practice. A “capability model” is a tool that helps with this thinking. It involves grouping like capabilities, such as “pizza production management” or “take money management”.  By grouping capabilities, the model makes it easier to identify opportunities to centralize and standardize. The “capability model” is particularly helpful for IT Functions because a single IT application is a capability that may have multiple use cases in different parts of the organisation.

The “capability model” tool has been drilled into many business and enterprise architects and others, and is widely used.  But few are aware of its downsides. The biggest problem comes from taking capabilities away from their process flow context and grouping them by capability type.

Lets take the pizza example. One of the sub-capabilities is “take payment”.  Even at this level of detail, there are different possible processes for the same outcome – payment by cash giving change, payment by credit card with a tap, payment by credit card with a pin, opening an account for credit, etc. If we abstract the “take payment” capability from its process flow context and group it with “take payment” for other lines of business (e.g. coffee or a bag of groceries), we can easily fall into the trap of building a “take payment” capability that is “centralized”, “standardized”, “more efficient” and “lower cost”, but which fails to take into account the particular process flow context of each line of business.  Think about the pizza customer standing at the counter, salivating over the delicious pizza aroma.  He or she will be upset by any payment process that does not allow him or her to gobble the pizza before it starts to cool. So, it is vital for the pizza area to have a process that is local and can cater for those who have cards and those who have cash and maybe even those who have forgotten both, but are willing to deposit their car keys while they eat the pizza and then find a friend to lend them the cash to redeem their keys.

My observation is that the loss of context that can occur when capabilities are grouped in a capability model often leads to over centralization and over standardization … and, hence, a less good architecture or operating model than is needed.

So, what is the solution? My solution is to replace capability modelling or mapping with a tool called “value chain map”. In this tool, every work step is recorded in its process flow along with clarity about who the “customer” is for that process (often an internal customer) and what the “value proposition” is for that customer. So the pizza example would have “member of the public who wants to eat pizza” as the customer and “a hand-made pizza, prepared in front of the customer, with mushrooms and peperoni, cooked for 8 minutes in a wood fired oven, etc” as the value proposition. The work steps in the process would be similar to those already described. I call this combination – process, value proposition and customer – a value chain. Others call it a value stream. In lean 6 sigma, it is just a process. Labels here do not matter much.  What is important is that each process flow is clear.

Other value chains for other value propositions to the same customer or to different customers are laid out alongside this pizza value chain to form a value chain map. For example, there might be a value chain for a mug of barista prepared coffee. There might also be a value chain for a bag of groceries. The work step “take payment” appears in all three value chains … and, when laid out in a value chain map, the three “take payment” work steps can be positioned as a column – one under the other. The rows in the map are the three process flows, one for pizza, one for coffee and one for a bag of groceries. The columns are “capability” columns: a group of work steps that have similar outcomes. The “take payment” capability column could be labelled “take payment management”.  What is important is that each of the three “take payment” capabilities is presented within its process flow and value proposition context, so that the particular customer need and the collaboration with the steps before and after is clear.  

Presenting all the “take payment” steps in a column, raises the same questions as a capability model: should the “take payment” work steps be centralized and standardized or not?  The alternative to centralization is for the barista to take payment for coffee, the pizza chef to take payment for the pizza and the check-out person to take payment for the bag of groceries. If the decision is to have three different payment points for the three different products, it might still be possible to centralize or standardize the technology or processes used. In other words, the value chain map achieves the same grouping as a capability model, and raises the same questions, but in a way that keeps each capability in its process flow context. This helps the architect or designer think about the coordination problems or customer service issues that might arise from centralization or standardization.

The other power of the value chain map is that the default position is not to centralize or standardize.  The logic for this default position is that it is normally easier to deliver the value proposition – “hot pizza in a box” or “barista coffee” – to the total satisfaction of the customer and to make a profit, if all of the activities in the process are designed with the customer in mind and managed by someone who has total responsibility for customer satisfaction and profit.  This person then has the power, for example, to change the “take payment” process, if the local cash machine is not working, and his or her customers still want pizza, but have no immediate way of paying.

Given this default position (build separate capabilities for each work step in each value chain), capabilities should only be standardized or centralized when the gains in terms of cost reduction or increased customer satisfaction are large enough to offset the risks that centralization or standardization will constrain operational flexibility in a way that increases cost or loses customers. 

Assessing the costs and benefits of moving away from the default position is often tricky because on one side it is usually possible to identify tangible cost savings from centralization or standardization, while on the other side the negatives are often risks that are hard to put a figure on (the risks from loss of operational flexibility or reduced cooperation between steps in the value chain).  Tangible savings on one side and difficult to assess risks on the other can bias the cost benefit analysis towards choosing centralization.  By having a default position of not centralizing unless the gain is significant and undisputed, and by keeping each work step in its process flow context, the bias is reduced if not eliminated.  

Without taking this example any further, I hope that you are thinking what I am thinking. If you have one central place for taking payment and one standard process, you may have pizza or coffee customers standing in line behind customers with trollies of groceries, while their pizza or their coffee cools and their frustration mounts. A decentralized and non-standardized approach, possibly one that involves payment in advance while waiting for the pizza to cook or the coffee to brew, might be better. Of course, a decentralized and non-standardized process, does not mean that some of the tools used (the credit card machine or the cash machine) and some of the supporting IT applications (for example the app that transmits the data to the leger) should not be standardized and centralized.  But the default starting position would be not to do this, unless the gain is significant compared to the risks. 

The problem with the capability model tool is that it implies the opposite default position: it implies that the capability should be standardized and centralized unless a powerful argument can be presented to show why it should not be.  Now, in theory, intelligent people using either approach, should come to the same answer. However, in practice, the tool that you use can bias your orientation and the choices you make.

While I have never worked in a pizza parlour, I have experienced the pain of over centralization and over standardization, even in a business school, which is normally a highly decentralized environment.  I was running a portfolio of courses that required marketing.  But “marketing management” had been centralized and standardized, which meant that my courses never got the marketing that they needed – and I know this because previously I had control of my own marketing.

But I can also see the world from the other end of the telescope.  I recognise that, if you work in IT, you will have experienced the pain of too much decentralization, too many applications with similar capabilities and too much cost.  So, it is not surprising that capability models are attractive tools to enterprise architects: these architects are typically looking for opportunities to standardize and reduce duplication.   

My warning against the use of capability models, therefore, is probably aimed more at business architects and operating model professionals than at enterprise architects. 

Posted in Capabilities, Uncategorized, Value chain | Tagged , , , | 2 Comments

Design Principles: how to manage them

Posted on January 1, 2022 by Andrew Campbell

I have already blogged on the topic of design principles: how to get good ones; more about design principles.  But I was stimulated by some questions from Hans-Christian Grung-Olsen.

Before I comment, let me clarify what I mean by “design principles”.   This is a jargon phrase referring to statements (usually single sentences) that a design team creates (or sometimes they are provided by the “client”) that define the most important guiding thoughts for the design work.  Imagine that you are redesigning your kitchen.  What would be the most important guiding statements that you might give to the kitchen designer?  “I want a light, bright kitchen that makes me want to jump out of bed for breakfast”.  “The design must enable us to have six people round the table”.  “The design must have an aisle near the cooker for preparing food and laying out dishes”. “Work surfaces should be xx inches high”.  “There should be two sinks, under the West window”.

As you think about these statements, you can see that some of them are very specific – “xx inches high”, while some are broader, allowing more flexibility for the designer to find a creative solution – “light and bright”.  Some design principles are about big structural choices “an isle near the cooker”, others are about minutiae “at least one power point with a slot I can use to charge my mobile phone”.

One question that Hans-Christian asked is about how to deal with all these different kinds of guiding statements.

Try to keep the number of statements (for each level of design work) to less than 10.  Three is often better than 23.  This is because the human mind finds it hard to be influenced by more than 6 or 7 thoughts at the same time.  Hence, if you want the designer to do good work, don’t given him or her more than six or seven thoughts at a time.  Additional statements can be added as the design work progresses to lower levels of detail. Bring in the statement about electric plugs, when the electrician is making choices about what plugs to place in the wall.  Bring in the statement about the height of work surfaces when the designer is working on the heights of work surfaces.

The first level of design is usually architectural or structural, so your first set of design statements should be aimed at giving architectural guidance.  Here, you can get the designer to help.  “Is this statement useful to you, at this stage of your design work, or is it too much detail or too constraining or too vague?”  Often the designer will respond “It feels too constraining.  Can we take the thought up a level?  You are saying you want an aisle near the cooker, but I am hearing that what you really need is somewhere to prepare food and lay out dishes.  If I come up with a design that fulfils this need, but does not involve an isle, would that be OK?” “You say you want two sinks under the West window.  How important is two sinks? How important is ‘under a window’?  Does it have to be the West window, why?”  So, you or the designer should probe every statement for its relevance to the design work that is being done now, and for the nature of the guidance that is contained in the statement.

When this process still leads to 20 statements, the designer should demand some forced ranking.  “Which are the most important 10?” or “If I have to make compromises, which of these would you be prepared to compromise in order to ensure the others are fully met.”

The designer then goes away and does a first draft or some options.  If the first draft is acceptable, the designer can then start working on the next level of detail: the positioning of lights, the material used for surfaces, the layout of cupboards or the positioning of electrical equipment. 

At this point the designer will want more guidance: statements that define requirements or preferences for this next level of detail.  There are often frustrations as these lower level design requirements become clear.  “I wish you had told me earlier that having the dishwasher near the plate cupboard is important to you. This probably means we should move the table closer to the door, and this means I will need to redesign the shape of the work surface”.  The lower-level requirements can sometimes turn out to influence higher-level design choices, causing some iteration and rework.  But this is a cost worth paying, for the benefit of having a manageable number of statements at the higher level. 

Hans-Christian also asked about design requirements that feel as though they are not specific to the design work that you are doing, but could have an influence.  For example, “I don’t want the kitchen to get too hot in summer” or “We should think about the impact on the environment” or “We might have grandchildren in the future”.  These kinds of statements should not be included in the 5-7 most influential design principles.  But there is no harm in thinking about them once a design has been developed: “are there any adjustments to this design that we might want to make because of our concern for the environment or because our daughter is getting married next year?”

Using design principles in design work is an art not a science.  There are two thoughts that will help you as you develop your approach: first, keep the number down (below 10); second, make sure each design principle is relevant to the level of the design work that is being done next.  And, of course, use some of the techniques described in my earlier blog for ensuring you have good quality statements. 

Posted in Uncategorized | Tagged | 1 Comment

Operating Model work is simple

Posted on November 27, 2021 by Andrew Campbell

Tom Graves from Tetradian has just posted a wonderfully elegant thought on LinkedIn, which I include below. He is a leading thinker in the fields of business and enterprise architecture – fields that overlap a good deal with operating models.

“What is architecture? What do we do in architecture? And how do we do it?

Turns out that it’s essentially the same for every kind of architecture: enterprise-architecture, solutions-architecture, software-architecture, building-architecture, naval-architecture, brand-architecture, whatever.

Right down at the root, in principle, architecture is incredibly simple. It all comes down to just one idea, one aim: that things work better when everything works together, on purpose.”

I love simplicity. But, I don’t think that the sentence in italics is quite complete. Building on Tom’s insight, I have added a thought: Things work better when everything works together for a purpose, on purpose.

“On purpose” means that we have made design choices with the intention of ensuring that “everything works together”. The reason why the sentence also needs the phrase “for a purpose” is because we only need everything to work together if we are trying to get something done efficiently. So the start point of all architecture and all operating model work is clarity about what we are trying to do – the purpose.

In my approach to operating model work this clarity involves defining three things: for whom are you trying to do something (the customer), what is it that you are trying to do for the customer (the product or service) and what activity do you believe you need to do particularly well in order to create value for the customer. These three elements are written in the singular: customer, product and activity. But in most cases operating model design work involves multiple customer types, multiple products or services and multiple special areas of needed competence.

Hold onto the “working together… for a purpose, on purpose” thought, and you will not go far wrong. Start with clarity about who the customers are (not always obvious, especially with internal functional design) and what the organization is trying to do for these customers (often not clearly defined). Then lay out the work steps that need to be done to create the beneficial outcomes for the customers (the value chain or chains). Then identify which work steps it is most important to do brilliantly well. Then design everything towards this end, recognizing that it all needs to “work together”.

Of course, operating model design work is easy to describe, but difficult in practice. As Tom adds:

“What we end up with should be simple – or as simple as possible and practicable, anyway. But we often have to go through a lot of complexity before we arrive at that simplicity. People, processes, politics and petty feuds, technology, temper-tantrums, structure, story, hopes, fears, wishful-thinking, delusions, disasters, doubts, debt-collectors, nightmares of logic and logistics, lost-in-translation tangles, things that just don’t work, things that do work in surprising ways, and maybe a little bit of magic, too: successful architecture covers and copes with all of that, and more.”

If you keep the simplicity of what you are trying to do front of mind, and recognize that you will often be wrestling with dilemmas and constraints and difficult people and seemingly impossible contradictions, you will do great work.

Posted in Uncategorized | Tagged , , , | 1 Comment

How to design for agility

Posted on January 9, 2021 by Andrew Campbell

I was stimulated, by an article in the Journal of Organization Design, about how to do design work recognizing the need for agile evolution, the fact that designers do not always get it right and the fact that people don’t always behave as planned .

Good design does not always lead to a good organization because the designers are “boundedly rational”, and because people have their own wills which can cause them to act in unpredictable ways.  Also, a good operating model for today may become less good tomorrow because the environment changes in ways that require new tasks or require tasks to be executed in new ways.

Agility, as I am using the word in this article, is the ability of organizations to adjust as circumstances change. But it is also the ability to adjust when part of the design that has been developed proves to be ineffective, either because the design is wrong or because people do not follow the design.

So why do people behave in ways that are not intended by the design.

First, they are influenced by the challenges they face, which may not have been anticipated by the designer.

Second, they have their own ideas about what tasks are most important, which may not always be the same as the intentions of the designer

Third, they choose behaviours that they believe are most effective for completing the task, which may not be the same as the behaviours that the designer thought were needed, and

Fourth, they choose behaviours they believe are most beneficial for them personally (personal rewards) and for their team or department and these can be in conflict with the behaviours that are most beneficial for the organization as a whole.

So what does “designing for agility” look like in practice?

We need to start with a definition of “good organization”. Good organization is an organization where “capable people work well together”.  “Capable people” means people with the skills and personality suitable for the task combinations they are allocated.  “Working well together” means that the people interact effectively where their tasks involve working with others in the organization.

Armed with this definition, “designing for agility” means:

  1. having a good understanding of which tasks need to be executed particularly well for the organization to succeed (which behaviours are critical to success) and how the people responsible for these tasks are currently behaving (if an organization already exists).
  2. focusing on achieving a fit between the person and the task, particularly for the most important tasks and most powerful people.  This is about the “capable people” element of good organization. Fit occurs when the person already has the relevant skills, values, behaviours and understanding of priorities needed for the task. In these circumstances the slipage between intended behaviour and actual behaviour is likely to be low, at least where the intended behaviour is appropriate for the job. To go from mistfit to fit The designer will need to adjust the task or the person or both.
  3. focusing on designing solutions to “difficult links”: important interactions between people that are likely to be (or are known to be) suboptimal because of conflicting objectives or competence issues or personality issues or …. This is about the “working well together” element of good organization. Design solutions may involve adjustments to people, to task definition, to interaction protocols, to leadership structures, to incentives, to information systems, to locations or to ….
  4. designing strong performance accountabilities, so that areas of “misfit” or “difficulty” that impact performance are quickly exposed.
  5. “fast redesign”, whenever a “misfit” or “difficulty” emerges. A “misfit” or “difficulty” may emerge because the design was inappropriate, because the people are not behaving as the design intended or because circumstances have changed. Managers should be encouraged to think like the manager of a football club.  If a person is injured – redesign.  If a person is not executing their tasks well – coach or redesign. If we are losing the game – coach the team or redesign. If two people are not working well together – coach them or redesign.  Every manager, therefore, needs the authority to redesign in their own area, as well as some competence at or support in good design.
  6. creating “design authorities” at different levels who can check whether the continuous process of small redesigns is challenging the overall working of the operating model or whether broader operating model changes are needed. The process should not be an approval process, which would slow down the redesigns.  It should be a review or audit process, which raises red flags when a small redesign may have consequences that have been overlooked.
  7. designing a process that enables managers at all levels to signal the existence of and drive the resolution of “organizational tensions”: a “misfit” or “difficulty” that is not part of their authority, but is effecting their ability to execute their task.  This process needs to be like the “tensions” process in holacracy or like the “Andon cord” on a Toyota production line.
  8. putting in place a culture and a reward system that reduces the natural forces of self-interest and department-interest which can distract from “organization-interest”.  Managers also need to be supported with training that will help them evaluate the “organization-interest” when making small redesigns.

Since the enacted or realized or real organization is how people actually behave rather than how the operating model design expects them to behave, all design changes should focus on what actual behaviours are likely to result, given the actual people involved, the current cultural norms that will be difficult to change and the likely pressures on the organization that may affect behaviour. The enacted or realized organization emerges from the combination of the formal design plus the informal behaviours. Design work is mainly about designing the formal organization, but this should always be done with an eye on the likely impact the changes will have on actual behaviour.

Posted in Agile and operating models, Tips for design work | Tagged , , | 6 Comments

Thoughts about HR and Operating Models

Posted on December 3, 2020 by Andrew Campbell

I was stimulated by this “4 stages of HR maturity” graphic, which was shared on a LinkedIn post. I am not sure of the original source.

There were more than 30 comments against the post, all of which were complimentary, saying how useful and helpful they found the graphic. This caused me to have a closer look because I do a bit of operating model work on HR functions and often find that HR strategy is not well defined.

What I want to share here is a critique of some of the content in this graphic, and point out that this kind of “maturity scale”, while seductive, is unhelpful. As my tools, such as the operating model canvas and the value chain map, point out, HR (or any function) needs to define who its customers/beneficiaries are, what value it aims to deliver to these customers/beneficiaries and what work it needs to do to deliver this value. Of course, in some areas an HR function may have an ambition to deliver value, but not yet have the capabilities to fully do so (for example business partnering in many HR functions). The capabilities to deliver this “value proposition” may be “immature”. But, to suggest that there is a maturity scale for the whole of HR is to misunderstand what is going on.

Now to some specifics in the graphic.

First, HR Reputation: HR should aim “to help the organization succeed given the legal context”. Aiming for best practice or external plaudits or just to help the organization be compliant are inappropriate for any HR team. HR exists to help the organization succeed and it should want to have a reputation for achieving this.

Second, HR Customers: HR has many customers and it should be clear about the different customers it has (Board, employees, managers, etc) and the value that it seeks to deliver to each of these customers (reports/advice to the board, services to managers, etc). Phrases like “we are employee champions” or “we are strategists” get in the way. For some customers HR may act as a champion. For other customers, HR may provide strategic support. What is vital is that someone has thought through all of the different customers and their needs, and is clear about what HR is providing to each.

Third, HR Purpose: HR exists to deliver the value (services, etc) that is has been set up to deliver. In some services HR may be delivering basic support. In some it may be delivering innovative solutions. In some it may be impacting external stakeholders. The key is to be clear about the ambition/promise for each service HR is offering. When considering the “service portfolio” some kind of scale, such as implied in the graphic, may be useful. Some HR functions may aim to provide a narrower range of services and others a broader range of services. But the service portfolio that is chosen should depend on the needs of the organization and the capabilities of the HR team. The vast majority of HR functions aim to deliver a broad range of services.

Fourth, HR practices: the scale in the graphic implies that first you need to be able to deliver “essential work” before you can deliver “leading edge” and this before you can deliver “strategy enabling”. This misunderstands the role of HR. As my point under HR Reputation states, HR should aim to deliver “strategy enabling” practices. Delivering essential work is “strategy enabling”. “Leading edge” is not necessarily strategy enabling. First it is impossible to define what is “leading edge”. Second, the pursuit of “best practice” often gets in the way of “helpful practice” because it encourages HR professionals to look at what other companies are doing rather than focusing on what our organization needs.

I could go on. My point is that a graphic like this is seductive, but can lead us away from clear thinking about HR. Tools like the Operating Model Canvas and the Value Chain Map are much more helpful.

Posted in HR, OM frameworks | Tagged , | 2 Comments

Supplier relationships

Posted on June 24, 2020 by Andrew Campbell

An important topic in any operating model design is the design and maintenance of good supplier relationships.  The first step is to decide what should be done in house versus by suppliers.  For this, use the “supplier matrix” tool.  The next step is to design relationships with those suppliers that cannot be treated in a transactional way: these are tasks for which there are not ready alternatives to the supplier or ones that are particularly important to your success.   “Relationships” will include a formal or informal agreement that addresses “the purpose and strategy”, “who does what”, “who owns what” (important for IP or data), “how the performance specifications are defined and monitored”, “incentives and penalties”, and “how the relationship is dissolved”.  The “relationship” may be a formal JV, a contracted alliance or an informal understanding.

I was recently reading a McKinsey article on how to do a “health check” on these “designed” relationships.  The advice was pretty straight forward: clarify the purpose and strategy, collect performance information and then talk to leaders of both organizations. But the article also contained a list of six aspects of good supplier relationships … and it is this list that caused me to write this blog.  I partly agree and partly disagree.

  • Strategy—gaining agreement on the partnership’s objectives
  • Culture and communication—encouraging open and trust-based communication among all parties
  • Operations—establishing a new operating model and performance metrics (for instance, sales or quality-assurance metrics)
  • Governance and decision making—adherence to key decision processes, metrics regarding speed of decision making, stage gates, and time lines
  • Economics—defining how value will be created from the partnership
  • Adaptability—proactively planning how to “tend” the relationship over time, in the wake of industry and organizational shifts

I agree with “Strategy”, “Culture”, “Operations” and “Governance”.  All vital elements worth real attention in the design.  But “Economics” as a separate topic from strategy makes no sense to me.  Strategy should be primarily about the value that the partnership/relationship is trying to jointly create.  To think of strategy as a topic separate from value creation seems to me to misunderstand strategy or value creation.

Then I also felt uncomfortable with the final item “adaptability”.  In my nine tests of good organisation design, the last test is the “flexibility test”: will the organisation find it easy to change/flex/adapt to the changes that may be needed in the next couple of years?  So it is very similar to the McKinsey “adaptability test”: will the relationship easily change/flex/adapt in the wake of industry and organizational shifts.  So I like the point.

But, in my nine tests, I do not have a separate governance test.  I think of governance as covering legal due diligence stuff, like approval of accounts, decision making, especially what happens when people disagree, and appointments of those with “governing responsibilities”.   The ability to adapt to new events/pressures is about decision making and appointments, so it seems to me to be part of governance.  Hence, rather like “Economics”, I think the McKinsey list should either make the “Governance” point more specific or include “Adaptability” within it.

Posted in Supplier Matrix | Tagged , , , | Leave a comment

Five guiding thoughts for good operating model work

Posted on June 15, 2020 by Andrew Campbell

I enjoyed reading an article by Marcia Blenko, a Bain & Co advisor, about operating model work for charities – https://www.bridgespan.org/insights/library/organizational-effectiveness/nonprofit-operating-models.  The article follows the Bain definition of an operating model, which is focused on organisation structure, accountabilities, governance, systems and ways of working.  It does not give as much attention to work processes, location, and supplier relations as the Operating Model Canvas.  Nevertheless, Marcia is an authority in this area and worth listening to.

Her first five guiding thoughts are:

1. Start with strategic clarity

2. Use design parameters (or design principles) to define what matters most

3. Up your game on decision effectiveness

4. Prioritize must deliver capabilities over “good enough” capabilities

5. Look beyond structure

This article is about my reactions to these five.

1. Strategic clarity is a big problem in operating model work, especially in charities.  So I wholeheartedly support Marcia’s focus on this.  The problem for an operating model team, who may not be skilled at strategy work, is to know when there is enough clarity and when there is not.  Few heads of organization are going to admit that there is not enough clarity.  They are more likely to say the opposite.  So I have a template that I get the operating model team to try to complete. If they can complete it, there is enough clarity.  If not, there is a problem.  The template asks the following questions

– what products or services does the organization aim to deliver/offer?

– to whom is the organization aiming to deliver these products or services (often there are multiple customer groups or beneficiary groups)? For charities, one of the “customer groups” may be donors.  So, it is important to understand what the “service” is that is being provided to donors.

– in which locations/geographies is the organization aiming to deliver/offer these products/services?

– through which channels of delivery will the products or services be offered?

– what does the organization aim to have as its sources of excellence or advantage?  These are normally operating capabilities.  But they can be brand or location or a range of things.

– what operating initiatives/transformations are underway or likely to be initiated in the next two years.

2. Design parameters or what I call design principles are also critical to good design work.  They help limit the number of options that need to be considered and focus design attention on the most important aspects.  I agree with everything Marcia says on this topic.  Again, I have a template to help with this work.  It has three columns.  The first is for the design principles (each a sentence that typically starts with “The design must enable ….).   The second column addresses the question “why is this principle important”.  It is useful to keep asking why, until the answer links directly with a high level strategic objective.   The third column provides space for listing implications for the design.  Here the design principle is converted into design ideas.  The value of this column is that it helps make sure the principle really does have design implications.

3. Decision effectiveness is a big focus of Bain & Co’s consulting work.  I agree that it is important, and I recommend using their tool – RAPID.  But, I typically do not give it as much focus as Marcia does because organizations need to be flexible and responsive.  Decision rights at time A may need to change for dealing with things that happen at time B.  As long as roles are clear and people are competent with regard to their role, they can adjust decision making rights to suit the change in situation.   So I mainly use RAPID only where there are “difficult links” that need to be designed at a lower level of detail.

4. Must deliver or critical capabilities are also central to the way I think about operating models.  You should avoid making design compromises with regard to critical capabilities.  But you can make design compromises for “good enough” capabilities.  I use a value chain map to help pin point these critical capabilities and to help me assess whether I am compromising them.

5. Structure is just one design lever.  It is a powerful one.  But we should not think of it as the only one.  In fact, I like to say that all of our design levers, only design the formal organization.  The real organization is the informal organization.  We make changes to the formal design in the hope that it will influence informal behaviours. Unfortunately, it often does not.  Culture eats design for lunch!

The article mentions three more guiding thoughts, which I have not included here because I think they are less significant (and this article is getting too long).  I will let you discover them for yourself.

 

Posted in Decision grids, Design principles, Design tools, Strategy, Tips for design work | Tagged , , , , , , , | 2 Comments

Finance function operating model

Posted on April 1, 2020 by Andrew Campbell

I was recently asked to give some help to a team working on an operating model for their Finance function.  The prime objective was to upgrade the function, so that it added more value and cost significantly less.  The particular discussion was about organization structure: who should report to the CFO, how to free up some of the CFO’s time for interacting with stakeholders and for spending more time on business strategy, and how to resolve the overlaps between “controllership”, “FP&A”, “strategy” and “performance management”.   In this company strategy reported to finance.

My first recommendation was to do a value chain map.  This was not because I expected there to be significant overlaps or common capabilities across value chains, but because the teams did not seem to have made a clear list of the “value propositions” of the Finance function.  You cannot do a value chain map without first defining the value propositions for which you need value chains.

The list of value propositions included things like “Provide a controllership function”, “Provide tax services”, “Provide treasury services”, “Produce management accounts”, “Propose changes to the portfolio of businesses”, “Influence performance outcomes”, “Help set budgets and KPIs”, etc.   We had a list of nearly 15 value propositions.

When we laid out the value chains, we noted that there was very little commonality across value chains.  Yes, a number of value chains involved analysis.  But we concluded that tax analysis is a different capability from internal audit analysis or portfolio analysis.  Also, most value propositions involved some partnering with the business divisions.  But, we concluded that strategy partnering is a very different capability from treasury partnering or risk management partnering.  So we concluded that any organization design for Finance should have a person in charge of each of the value propositions, with all the resources needed to deliver the value proposition.  This meant that cost cutting would have to happen within each value proposition or some value propositions should be dropped.

We then needed to think about how to group the 15 (or so) value proposition owners for the purposes of reporting to the CFO.  Ideally we only wanted 5 or 6 direct reports to the CFO to help free up some of her time.

Some value proposition owners (or departments) needed to report directly: Strategy, Internal Audit and Treasury.  So the question became “how to group the rest” and whether some of the rest could report to Internal Audit or Treasury or Strategy.  This raised some interesting debates about whether M&A Support and/or Performance Management could report to Strategy.  I counselled that I thought that both M&A and Performance Management were incompatible with Strategy because Strategy is about reasoning, creativity and intellectual rigour, whereas M&A is about deal doing and Performance Management is about holding people’s feet to the fire even when it seems unreasonable.  But we observed that many companies do put some of these activities together.

A number of logics for grouping departments were discussed

  1. Operations type activities, like accounting; specialist departments, like tax, treasury and M&A; departments with heavy interaction with business divisions, like FP&A and Strategy
  2. Activities with an “innovation” orientation, like Strategy and Tax; activities with a “customer intimacy” orientation, like FP&A and Risk; activities with an “operational effectiveness” orientation, like Management Accounting or M&A support
  3. Activities that are primarily about setting policy, like Controllership and Risk; activities that are primarily about shared services, like Management Accounting and M&A support; activities that are primarily about “influencing”, like Strategy and Performance Management

To date, no decisions have been made.  But I thought you might find the process of thinking interesting.

Posted in Finance function, functional alignment, Value chain | Tagged , | 16 Comments

The Operating Model Canvas, Kaizen and Agile

Posted on February 22, 2020 by Andrew Campbell

This week I was in Bologna and Vicenza helping launch the Italian edition of Operating Model Canvas.  The translation and funding for the Italian edition was provided by Kaizen Institute: who support companies wanting to improve their operations.  I was giving a presentation on the Canvas and toolkit.  There were also presentations from the Kaizen Institute explaining how they integrated the Canvas with their work on processes and change.  I wanted to share some observations and learnings.

First, the Kaizen approach is built around “value streams”: observe and document each value stream, imagine ways in which the value stream could be improved, try out the good ideas, then operationalize, then monitor and measure improvements.  The value stream focus of Kaizen is similar to the value chain focus of the Canvas.

Second, because the Canvas is looking at more than processes, it has been providing the Kaizen Institute consultants with a “whole system” way of understanding their client organisations and of explaining to their clients why they should be considering more than just process improvement.  Often process improvements are only possible if wider changes are made to the operating model and sometimes the improvements will only be sustained if reinforced by other changes in the operating model.

Third, the Kaizen approach exposed me to two aspects of what I call “management system” that I was previously aware of, but had not fully connected with management system.  The first is Hoshin Kanri, the process for “deploying” strategic ambitions through change projects. Companies, such as Danaher the US conglomerate, are devotes of Hoshin Kanri, using this management system to define “breakthrough” projects, set priorities and drive change. Clearly Hoshin Kanri is a part of “management system”.

The second aspect of the Kaizen approach that is part of management system is the upwards cascade of review meetings that starts with the daily team meeting of operators on the production line, then the daily meeting of shift or line supervisors to connect across teams, then the daily meeting of production managers, then the weekly meeting of functional heads including production and finally the monthly business meeting.  This upwards cascade helps correct issues speedily at the level where they occur, but also ensures that a small issue low down in the organisation that has a big business-wide impact is raised up to the business meeting, and does not rely only on more informal lines of communication.

This recognition that even the lowest level daily stand-up is part of the “management system” made me think about the management system of “agile”: backlogs defined by the team, product owners who prioritize the backlog, kanban boards showing the progress of items that are taken out of the backlog, daily stand up meetings, sprints, etc.  Agile is an operating model: it is an organisation structure (multifunctional teams or “squads” each part of a separate “mother function or chapter” linked together into a “tribe”) where the team members are co-located, typically operating out of one shared space, and everyone is guided by a management system, often called “scrum”.  So we have the work (backlog), the process (sprints), the organisation (squads, tribes, chapters and …), the location (one shared space), the information system (many visible displays) and the management system (backlog, kanban and scrum).  We are only missing the “suppliers” element from the Operating Model Canvas, which, of course, is very specific to the type of work that the agile team is doing.

Posted in Operating Model Canvas | Tagged , , , | 4 Comments