Supplier relationships

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

I enjoyed reading an article by Marcia Blenko, a Bain & Co advisor, about operating model work for charities –  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

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

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

Doing “genuine” work and being “genuine”

I have always been a bit suspicious of terms like “authentic” leadership or “genuine” leadership.  So I was interested to read Travis Bradberry’s “12 habits of genuine people” in Forbes.

I had two reactions.  First, there is some good stuff here: some of which I do and some of which I do not do.  So some personal lessons for me.  Second, surely a “genuine” person would not need to package their thoughts into 12 habits.  The person would more likely list a handful!  So here goes.

  1. Genuine people don’t worry if some people don’t like them.  They know that some will and some will not. They don’t try to please, to win favor.  They are pleasant because they like to get the best from people.  They are willing to take unpopular positions, if they believe them to be right.  Depending on their personality, they may show off or show some ego: but not just to get attention.  They use it to help them get their message across.
  2. Genuine people are open minded.  They are always willing to consider and debate the views of others.  They do not sway in the wind.  Their own views are well anchored and open for others to challenge and debate.
  3. Genuine people are generous and respectful.  They share openly, confident that the interaction will bring benefits for both.  They don’t have favorites.  They interact based on the potential gain for both parties, neither wasting other people’s time nor squandering their own time.
  4. Genuine people are thick skinned and trust worthy.  They do not easily take offense.  They focus on the content, while recognizing the distortion that may have come from emotion. They know who they are, which makes it easier for others to trust them.  They don’t hide their weaknesses. They keep their promises.
  5. Genuine people are loving humans.  They stand by family.  They help those suffering.  They execute tough love.  They can be distressed.  They can be joyous.  They like to fool around and laugh.
Posted in Uncategorized | Tagged , , | Leave a comment

A Critique of Deloitte’s Thoughts on Operating Models

I have just read one of the better articles on operating models.  It is from Deloitte, and it appears to describe their approach.  I recommend it to you because it is relatively easy to understand (if you skip over the jargony, fluffy bits), and because, in my view, it has some important flaws.

Let me explain.  First the article suggests that the journey from strategy to success involves – strategy, business model, capabilities, operating model, people/process/technology – see exhibit (if it is a bit blurred, please go to the original in the article)

This use of language relegates the word strategy to what others typically call vision or mission; and the phrase business model takes up the space that others typically call strategy.  There is also an interesting step – “capabilities” – between business model and operating model, which I want to say more about.  Lastly, people, process and technology is seen as separate from operating model.  Whereas most of us think of people, process and technology as the heart of operating model.  The point I am trying to make here is that you need to be thoughtful about consultant frameworks: challenge them; make sure you understand them; look for gaps, overlaps, language differences, etc.

The flow of questions behind the framework seem logical and sensible.  But, how can you answer the question “who has ownership and decision rights?” without having first defined an organisation chart?  How can you decide which capabilities to buy in before you have defined the operating model?

Moving on to the capabilities box.  The authors are clearly influenced by the Enterprise and Business Architecture view of operating models, which places the concept of capability in centre stage, along with the concept of a capability map.  They provide a very accessible exhibit explaining Deloitte’s version of these two concepts (I suggest you go to the original in their article).


My concern here is that capabilities are being defined away from their operating model context.  Lets take “consumer marketing” (top of fourth column), which is presented here as a capability within the function Marketing.  First, this display, encourages the idea that there will be a function “marketing” rather than some other configuration.  Second, having only one capability titled “consumer marketing” encourages the idea that this is only one capability.  In my experience, consumer marketing for ice cream is a very different capability from consumer marketing for spaghetti, which is different from consumer marketing for knitwear.  By this I mean that, if you took someone who is a good consumer marketeer in one of these sectors and moved him or her to one of the other sectors, he or she would on average fail to perform well, without learning new skills.

It is for this reason that the Operating Model Canvas focuses on value chain maps rather than capability maps.  I believe that you first need to understand the different customer segments you want to serve and the value propositions you believe will succeed in these segments (this is what I call strategy).  Then you need to define the work processes (value chains or capability chains) needed for each of your value propositions.  This gives you an understanding of the work (capability) in its context (value chain).  So if you want to sell ice cream, spaghetti and knitwear, you will have three value chains and are likely to have a work step in each of these value chains called “marketing”. You can then consider whether some of the capabilities in different value chains (e.g. consumer marketing across these three different products) are similar or not.  Configuration (value chain), I believe, comes before capability analysis, not afterwards.

So, my flow from strategy to success might be something like this: mission/vision/values; strategy (what, to whom, how will we get advantage); high-level operating model (value chain first, then organisation model, then other elements including location and sourcing); then high-level financial model to make sure the high-level operating model is viable; then more detailed operating models for those critical capabilities that are to be delivered in house.

This flow differs from the Deloitte’s flow in a few ways:

  • There is no business model step separate from strategy or operating model. If you use the business model canvas, then strategy deals with the right-hand side (value propositions, target customers, channels and customer relationships) and operating model deals with the left-hand side (activities, resources, partners).
  • There is no “capabilities” step separate from the operating model work. The two are intertwined, and much of the capabilities work is done at a lower level of detail
  • There is a recognition that operating model work needs to be done at multiple levels: high level for the whole organisation, medium level for each function in the organisation, low level for each department or capability in each function.
  • There is a financial model step – as in the business model canvas – which needs to be done when strategy is being developed, then repeated for the high-level operating model, and so on.

I may seem rather critical of Deloitte’s article. But, actually, I rather like its clarity and willingness to convert ideas into visuals.  I particularly like some of the material in the section “Where does work get done?”, which is not about location, rather it is about outsourcing and building capabilities.

Thank you Kwan, Schroeck and Kawamura.  It would be great to meet up and debate these issues.

Posted in Capabilities, OM frameworks | Tagged , , , , , , | 5 Comments

The role of operations in strategy

I recently enjoyed an article by Kevin Laczkowski and colleagues at McKinsey titled “Seeing your way to better strategy”.  It argued for four lenses to help you “see your way” forward – Financial, Market, Competitor and Operating Model. The thought behind these lenses is that, by doing some focused thinking around each lens, you will develop better strategy.

I recently enjoyed an article by Kevin Laczkowski and colleagues at McKinsey titled “Seeing your way to better strategy“. It argued for four lenses to help you “see your way” forward – Financial, Market, Competitor and Operating Model. The thought behind these lenses is that, by doing some focused thinking around each lens, you will develop better strategy.

While this is not the first of these kinds of articles (see David Collis’s “Can you say what your strategy is?”), it is the first one to include “operating model” as one of the perspectives.  Unfortunately, in the article, the operating model perspective is allocated little more than a paragraph, and, in my opinion, says little of note.  So, I thought I would improve on it. 

First let me summarize the other three lenses.  The financial lens is about using financial analysis to understand if the strategy is ambitious enough: will it justify the current share price, will it deliver top quintile performance compared to peers, will it outperform the do-nothing-new option? Can we afford it?

The market lens is about granular analysis of where growth and profits are now and will be in the future: which segments, which countries, which channels, which adjacencies?  Is the strategy exploiting these trends with an appropriate balance between reliable profits and more risky opportunities?

The competitor lens is about advantage. What gives advantage in each market and how well placed is our company? Will the strategy deliver improvements in our advantage? How much change will be needed for us to gain sustainable advantage in each of the markets we are targeting?

The operating model lens is about implementation.  Has the organization committed sufficient resources and capabilities given the strategy’s challenges?  And also, is the organization designed in a way that will accommodate the new activities or new capabilities required by the strategy?

So, let me explore this lens in a little more depth.  For most companies, the current operating model acts as a constraint on strategy.  New opportunities typically require new capabilities, which in turn depend on a new operating model.  It is only once the new capabilities have been developed – the operating model has been transformed – is it possible to use the new capabilities to exploit the new opportunities. Often, the transformation is not achieved or not even planned and the operating model fails to deliver the new strategy.

The operating model lens encourages strategists to think about the transformation that may be required, whether it is realistic and, if so, whether sufficient planning and resources have been or will be allocated. 

How does a strategist make this assessment?  First, the strategist needs to understand the current operating model and the value propositions it is capable of delivering.  The Operating Model Canvas is an excellent tool for doing this (see

The strategist can lay out, on one page, the current value propositions and the processes, people, information systems, locations, suppliers, management meetings and scorecards that enable the organisation to deliver these value propositions.  If the strategy involves either delivering some new value propositions or delivering similar propositions to new market segments (as most strategies do), the strategist can assess how much transformation is needed: whether new processes, people, information systems, locations, supplier relationships, management meetings or scorecards will be needed and how much the existing ones will have to change. 

Using the Operating Model Canvas, the strategist can assess the size of the transformation required and the likelihood that the needed changes will be made successfully. If the likelihood of successful transformation is low, a wise strategist will want to reconsider the strategy or ensure that the leadership team have the commitment and the resources that will improve the odds.

The Operating Model Canvas is a high-level tool.  In places where more detail is required, the Canvas is supported by further tooling:

The operating model lens is asking whether the organization has or is likely to be able to put in place the people, structure, information capabilities, supplier relationships and management systems that will enable it to successfully implement the strategy?  In my experience, successful strategies are not primarily about finding exciting new business opportunities.  Successful strategies are about matching opportunities with capabilities, and ensuring that the result leads to an advantage over competitors.  This means understanding the current operating model well, understanding what changes are realistic and understanding the competitor benchmark that must be exceeded. 

Posted in Uncategorized | 1 Comment

Comparing McKinsey’s procurement framework with the Operating Model Canvas

I have been reading a McKinsey article on procurement, titled “A next generation operating model for source-to-pay”, authored by Samir Khushalani and Edward Woodcock

At the centre of the article is a “honeycomb” framework (see exhibit). 

So I thought I would try to link this framework with the Operating Model Canvas (see exhibit).

The value capture and value sustainment parts of the McKinsey framework seem to address the Processes or Value Delivery Chain middle arrow of the Canvas:  

  • Translate business strategy into procurement strategy working with colleagues from outside the function to ensure alignment
  • Manage categories both by managing the suppliers and by influencing colleagues
  • Contract with suppliers based on the category strategy, McKinsey’s “Source to Contract” step
  • Place and expedite purchase orders with suppliers and receive and qualify goods (or enable colleagues to do so). This is McKinsey’s “Procure to Invoice” step
  • Process and pay invoices, McKinsey’s “Invoice to Pay” step
  • Manage supplier relationships

Because the function is Procurement, the Supplier box in the Canvas becomes incorporated into the value chain: much of the value chain is about choosing suppliers, developing contracts with suppliers and managing relationships. 

The McKinsey honeycomb’s outer ring broadly aligns with the other elements of the Operating Model Canvas:

  • The Suppliers box in the Canvas has already been covered in the value chain
  • The Organisation box is covered by “Organisation” and “Capabilities and Culture”
  • The Information box is covered by “Data & Analytics” and, to some degree, “Digital”
  • The Management System box is covered by “Governance”

This leaves three issues for discussion.  The “Processes” element of the McKinsey framework is one of these. The article explains “In a next-generation operating model, processes are not only harmonized across business units and geographical regions but also employ category-specific solutions that streamline approval processes for the user journeys associated with a particular channel and category.”  In other words, McKinsey’s “Processes” element appears to be about “value chain mapping” drawing value chains for each category. This tool helps organization designers decide what parts of the value chain should report to categories, and hence potentially be different for different categories, and what parts should report to central functions within Procurement. For example, the first step – “procurement strategy” – could report centrally and the last step – “manage supplier relationships” – could report to the category managers. “Invoice to Pay” would typically report centrally, but there might be category specific elements in the process.  “Manage categories” would report to the category manager, and might be very different for different categories. 

The second issue concerns the Locations box in the Canvas.  It does not seem to be represented in the McKinsey framework.  This is surprising.  Location of staff is an important issue in designing the operating model of the procurement function. It is important to decide which staff should be located near suppliers, which staff located near other internal functions and which staff need to be collocated to smooth collaboration within the function.

The third issue concerns “Digital” in the McKinsey framework.  As the article states, “Advanced procurement organizations are increasingly making use of automation technologies to eliminate unnecessary manual work from transactional processes. Digital approaches can also enhance user experiences by making access to procurement services easier and more intuitive.” Does the Operating Model Canvas need another box for Digital?

My answer is no, for the same reason that the Operating Model Canvas did not include a box for technology.   The middle arrow in the Canvas is about the work steps and the machinery and technology needed to execute these work steps.  The Information box is about the information systems needed to support these work steps (and the management system).  Digitization is muddying this distinction. Digitization means that a number of work steps will be done by computers. The temptation is then to see these steps as being part of the Information box rather than the middle arrow. The same confusion is happening inside organizations wrestling with whether digitization should be led by the IT function or by a separate team.  What is important is that all operating model designers recognize that there are two very different tasks – digitizing the work steps and providing information systems.  Because some of the skills sets are similar and the need for collaboration between the two tasks is high, many have chosen to have both tasks led by the IT function.

So where have we got to?  First, McKinsey’s honeycomb framework is very similar to the Operating Model Canvas, although it may overlook the locations issue. 

Second, while the article claims to describe “A next generation operating model” for Procurement, in fact it just raises some issues that operating model designers should consider when designing future operating models.  It provides a value chain and makes some interesting observations about what activities in the value chain will need to change in the future and how priorities might be redistributed.  It emphasizes the influence digital will have on these value chains and suggests that “category specific” value chains may also be part of the future.

But the article does not provide an organization structure or suggest what sort of information support is needed or how to resolve the locations issues or how to define those suppliers that need to be managed through collaborative agreements or what type of management calendar or scorecard is suitable for running the next generation procurement function.  If McKinsey was using the Operating Model Canvas as its framework for operating model work, all of the above questions would have been top of mind and the authors might have more fully delivered on the article’s promise.

Third, the honeycomb framework attempts to address the issue of value creation, distinguising between “enabling”, “capturing” and “sustaining”. I have been wrestling with how to link value to operating models for my course Designing Operating Models. It is easy when working on an operating model for a business because revenues can be offset against costs, and , as with lean analysis, “waste” or “lack of value” is any cost that does not deliver more than its weight in “value”. However, retaining a focus on “value” when doing an operating model for a function like Procurement is harder. McKinsey’s ideas have got me thinking … which will hopefully lead to a future blog.

Posted in Operating Model Canvas, Procurement operating model | Tagged , | 2 Comments

How to identify use-cases for new technology

James McGovern asked an interesting question on LinkedIn: “What Methodology Should BA Use to Determine Applicable Blockchain Use Cases For Their Organization?”  In this sentence, BA means Business Architecture rather than British Airways!  It got me thinking – what methodology should operating model analysts use to determine what technology is used to execute any work in the organization.

My first reaction was that this is not a question that is addressed in operating model work.  When doing an operating model design for a restaurant, we do not decide what type of cooker is used by the chef or what type of lighting is used in the restaurant entrance.  These are level three or four decisions (level 1 being design principles and level 2 being a high-level operating model design).  But, I then began to think some more.

Operating model work involves deciding what sort of people you need to do the work, what sort of information support the work needs, where the work will be done, what external suppliers or partners are needed and how the work will be governed.  The answers to all of these questions depend at least in part on the technology that is used.  If an accounting ledger is kept in a large book with each entry hand written, you need different people, different IT support, different suppliers and different governance processes than if the ledger is held on a blockchain. In other words, once you have defined the work that needs to be done – the value chain needed to deliver a particular value proposition – you also need to decide, in broad terms, the technology that will be used to do the work in order to be able to address all the other operating model questions.

You may not need to decide what type of cooker the chef uses, but, if the cooking only involves microwave ovens, you will need a different kind of chef and different suppliers, than if the cooking involves Cordon Blue cuisine.  To give one more example, if you are designing an organization to make holes, you need to know whether the technology you will use is picks and shovels, a mechanical digger, a drill or dynamite before you can design an operating model.

This raises the question of whether this “high-level” technology choice should be part of strategy or part of operating model design.  Should the operating model designer say, “I know you want to make a hole, but until you tell me what technology you want to use, I can’t design an operating model for you”; or should the designer say “I know you want to make a hole, tell me a bit more about the type of hole you want and I will tell you what technology is most suitable and give you an operating model design as well”.  Personally, I think the latter is more practical, if only because, in operating model work, it is hard enough getting the client to give a clear articulation of the strategy, let alone getting clarity about technologies. 

Putting my academic hat on, though, I think the answer to the riddle is dependent on whether the technology choice is a source of advantage/excellence or not.  If it is, then it should be defined in the strategy.  If not, it can be left to the operating model designer.

So we come back to James’s question “what methodology should operating model designers use to choose technologies for doing the work?”  The answer, as with most operating model design, is to ask those who know.  Find an expert at “making holes of this kind” and ask him or her what is the best technology, what kind of people are needed to use this technology, etc.  When a new technology comes along, like blockchain, ask someone who understands the technology to explain what the technology is good at doing, and then consider each “work step” to assess whether the technology is likely to significantly improve the cost or quality or speed or … of the work step.

Posted in Technology and operating models, Uncategorized | Tagged , , , | Leave a comment

Comparing Agile and Cross-functional Teams

I was reading a McKinsey interview with the head of the Rijksmuseum on the subject of Agile. For some time now, since a conference I ran in July on Agile and New Forms of Organisation, I have been trying to get clear in my mind what the difference is between “agile organisation” and “cross-functional teams”. This interview helped me clarify a couple of points. Cross-functional teams have been a feature of organisation since the 1960s, when Boeing first developed a new aeroplane using a multi-functional approach.  This successful experience was documented by Jay Galbraith, who called it a “matrix structure”.  It was one of the first documented uses of matrix organisation ideas: in Boeing’s case a function/project matrix. So what is new/different about Agile compared to cross-functional teams?   Here is my list
  1. Agile team members are allocated to the agile team full time.  Many cross-functional project teams are part time.  Of course, many, like the Boeing example, are also full time (at least for a number of years).  Just to confuse us all, some people call teams with part-time members “agile” teams.
  2. Agile requires a fully defined mission for the team.  It also gives freedom for the team to “self-manage” in delivering the mission.  Project teams will typically have objectives, but often not as much care is taken in defining the mission of the team, and less commitment is given to ensuring the team has freedom to work in whatever way they like.
  3. Agile typically requires co-location of the team.  Cross-functional, project-team members often remain located in their function but come together for joint activities.  Co-location is believed to be an important part of agile because it produces better communication (essential to self-management), more commitment and more speed.
  4. Agile typically involves using many of the methods of ‘scrum’, like backlogs, sprints, stand up meetings, visible progress displays, etc.  Project teams, at least historically, involved few standard ways of working, and project management typically uses a “waterfall” approach.
  5. An agile team needs a “product owner”, the person in the team who prioritizes the backlog and does other “team-leader like” roles.  A cross-functional project team has a team leader, whose role is typically broader and less well defined.
  6. An agile team is expected to produce intermediate outputs and trial these outputs with the beneficiary/customer it is serving.  The concept of “minimum viable product”, from Lean Start Up thinking is important here.  Agile teams are expected to generate trial outputs quickly and expose them for comment and reaction.  Project teams, more typically work in a “waterfall” approach, only exposing their output towards the end of their work.
  7. An agile team is a permanent part of the organization.  Whereas a cross-functional project team is typically expected to have a limited life, often months not years.  However, many people use “agile” to refer to temporary teams, and because organizations change fairly frequently few agile teams stay the same for more than a year or two.
  8. Organisations with many agile teams (such as Spotify), typically call these teams “squads” and group them into “tribes” to help manage coordination between “squads”.  The functions are called “chapters”.  Organisations with many project teams may have a “project office” to coordinate “multiple workstreams”, as, for example, in post-merger integration projects.
In summary, some cross-functional project teams (those with long time horizons, well defined missions, clear team member roles, scrum working practices, sensitivity to their customers, etc) are very similar to agile teams.  But the typical cross-functional project team has important differences from the strictly applied agile team. This raises the question of what is the same between agile teams and cross-functional project teams.
  1. Both types of team have members drawn from different functional disciplines, and the functional disciplines are still responsible for the capabilities of their people.  This is the matrix element.
  2. Both types of team have defined objectives and are expected to deliver within set time frames.
Both are ways of breaking down the functional silos that stultify organisations.  But “agile” is also associated with speed, customer-orientation and higher levels of motivation and engagement.
Posted in Agile and operating models | Tagged , , , , | 1 Comment