KonMari Method applied to Organisational Design

Tidy Clothes Hangers

Can we apply the KonMari to Organisational Design?

The KonMari method describes how to tidy your house and how to keep it tidy. It is a set of rules that you can absorb in order to keep a less cluttered house. Having read through the concepts and the rules, I noticed some similarities to the domain of Organisational Design. So let’s work through some of the main rules.

1. Tidy all at once

The premise of this is the concept that tidying an untidy house a bit at a time doesn’t work. Now before I hear you say Continuous Improvement, we have to remember that at first with KonMari, the house is already untidy. And so it is with our organisation. We’re performing Organisational Design because the  organisation is an unfit state; it’s untidy.

So let’s allocate enough time, effort and people to redesign the organisation to get it into a fit shape. We need to accept the fact that it will take time and can’t be done piecemeal.

2. Visualize your destination.

This is the vision that sets the direction for your organisational design. Think of the vision that fits with MSP (Managing Successful Programmes) or the visions provided by your CEO or MD.

Define what you want your organisation to look like in the future, what it does, how it does it. That’s the direction you want to travel in and then that can act as constraints and drivers later on.

Create the design principles in order to identify what criteria you’re going to use to make decision about the future.

3. Identify why you want to live the way you envision

I think this is potentially the wrong way around. In my eyes, the ‘why’ should come before the ‘what’ of the vision in Step 2.

Using KonMari, you’d go through the exercise asking yourself why you need the items that are in your vision. This is a questioning of self, to understand how important an item is for you.

For us, this is the questioning we should ask about the vision. It’s time to reflect on the vision and evaluate it from a different perspective. As opposed to the vision that you’ve developed over time, question “if we achieve this vision, will it be good enough?”, “will it do what we set out to do?”, “are we aiming far enough?”

It’s also the questioning we should be asking ourselves when looking at the design principles. Are they fit for purpose? Are they good enough?

4. Determine if each item “sparks joy”

When you consider the items to keep or reject, KonMari suggests an emotional angle over whether it sparks joy. This enables you to reduce the items beyond just whether it’s functional or not, or whether you may use it in the future.

So we should look at each business capability in your organisation. Does its current implementation, e.g. which team makes it happen, work for you? Does it feel right? This isn’t about the logical response, but the emotional one.

5. Tidy by category, not location.

Remember this. It’s probably the most important one.

The KonMari suggestion is to bring all items of a certain category (e.g. sweaters) into a single place and work through them one-by-one. Rather than sorting through a chest of drawers, drawer-by-drawer.

Consider all the teams that deliver each Business Capability. Is that the way that you want to deliver that capability in future? How does it fit in with your vision? Is there a different way for you to provide that Business Capability, e.g. merging teams, outsourcing, joint venture, etc?

6. Tidy in the right order.

The KonMari method describes this order:

  1. Clothes
  2. Books
  3. Papers
  4. Komono (miscellaneous.)

But also to create subcategories within the categories.

It’s a more complex situation for organisational design. We could find equivalent capabilities for clothes, books, etc, but the reality is that each organisation is different. They may have similar capabilities, but it’s likely that any two organisations will have different implementations of each capability or have capabilities at different stages of maturity.

So we need to create a plan that makes sense for each organisation. Start with the fundamentals of what needs changing first in order to create space (or capacity) elsewhere. For instance, if an intake team within value chain can’t change it’s filtering for whether customers, prospects, etc are passed further down the chain. Then it probably makes sense to focus on the receiving teams first, to then free up people assist with the intake team. It’s similar to clearing out a large enough area to act as swing space, so you can then make bigger changes more efficiently with the space you’ve just cleared.

7. Discard before you place things back

Set honest expectations early. If jobs will be at risk, complete the consultation and follow-up actions before you move people into the new team structure. There is always pain, but better to start a new organisation design with team members who are committed rather than retaining those who know that they are leaving.


I hadn’t intended this as a serious article, but I the more I wrote, the more I realised that there may be some useful perspectives to gain from the exercise.

Can we perform organisational design using just the KonMari method? From what I’ve found of the method so far, no we can’t.

Can we benefit from considering the KonMari method when performing organisational design? Yes, most likely we can.

Partnership Map

Partnership Map 0_02

I’ve developed a Partnership Map, designed to help us think about which companies we partner with and why.

With my clients, I’ve often found workshop attendees confused (at least initially) by the term partnership. If you use other well-known tools such as the Business Model Canvas, maybe you’ve encountered similar issues.

We all use the term partnership, but rarely question what we actually mean by it. I usually revert to asking what the partnership entails. If it’s one company paying another for services, is that really partnership?


There are two parts to the target

  1. The Map itself: designed so you can print it large and place your partnering companies on the map
  2. A table of the definition of the tiers. I’ll admit this is a very rough draft, but I thought it better to get it out in the world and improve with collaboration, rather than it just being the product of one person.

How to use it

  1. Work through each of your partnerships and place them according to their sector and tier.
  2. Once all partnerships are on the map, step back to look at them
  3. Evaluate whether that partnership should exist, moved tiers or become a supplier-client relationship. Think of partnerships moving from outside to inside or vice versa, or partnerships being consolidated across sectors.
  4. If a particular partnership is giving cause for concern, then consider using the Partnership Canvas for more in-depth analysis.


This is a first draft; it’s my first attempt at putting down my thoughts into a picture.

There are a few tasks before I’d consider it a first release:

  • The alignment of the words to the circle isn’t spot-on. I’ll wait to see if the quadrants and sectors change first, before making it neater.
  • The definitions of the tiers and the actions need more thought
  • Validate the quadrants – I’m not comfortable with the name Business Capability; it’s a working title
  • Validate the sectors – Do these need to change, add sectors, merge sectors?



I’m happy to collaborate on it, so get in touch at @alanward and let’s talk.

The Content

Partnership Map 0_02
Partnership Map 0_02


Partnership Map Definition 0_02
Partnership Map Definition 0_02

Rodents Don’t Scuba Dive – Innovation In The Real World

Diving in Black and White
Diving in Black and White

I’ve always liked the concept about innovation being the introduction of something that’s already done in one industry sector into another sector where it’s not (yet) done.

Incomplete Definition

Unfortunately, it doesn’t stand-up as a complete definition of innovation. For instance, it falls short by not recognising innovation from within. By that, I’m not referring to new types of products (e.g. the internal combustion engine) since those would be better classed as inventions. Many new products are existing concepts with new features, so would be better described as improvements. But taking a product and using it for a different purpose, e.g. using an internal combustion engine to power a unicycle could be an innovation.

What I like about the simple concept is that it immediately makes people think about what they Continue reading “Rodents Don’t Scuba Dive – Innovation In The Real World”

Use Case Diagrams for Documenting Scope

Use Cases

I embraced UML as a communication tool some years ago and have found it successful in being able to convey messages in a simple manner. I don’t use every type of diagram – some are too strange for the average business user. I do use Use Case diagrams. These are great and, with a small amount of education, are suitable for use with business users.

Use Case Diagrams for Scope

As a communication tool, Use Case diagrams are great at showing who does what at a very high level. They’re good at showing system solution scope, types of actors and ownership of integration points. In one diagram, I can show the scope of the system in a way that users will understand. Now that’s a powerful tool.

Depth of the Scoping Use Case

Ideally I like to have short Use Cases, perhaps 2 or 3 sentences at the highest level. Used like this, they don’t conform to the more common view of Use Cases, but they do give a good, brief overview of what happens in the solution. More detail is required in later stages, but you can’t beat a concise description to get the ball rolling.

Why use Use Case Diagrams for Change Management?

There’s a system involved. By system, I don’t necessarily mean an IT software application. There are people, teams, dependencies on other organisations, dependency on phone network being available and so on. Often the people in the change team, including the users themselves are not aware of all the interactions that they have with these external organisations (including teams in the same organisation). This is where a simple Use Case comes in. It can show, at a single glance, the main interactions between the team in question and their environment. I use them to gain a joint understanding of what the team does now, or what they’re trying to change to.

Multi-level Use Cases

Originally the concept was that a system had 10-20 Use Cases. If you had vastly more than that, then you were doing it wrong, it you had less than 5, you probably weren’t analysing far enough. Time’s moved on and real-world, practical experience has been added to this. What analysts and software methodologists/project methodologists came to realise was that the power of Use Cases was that they were readable and understandable by users but that to capture sufficient detail, they were becoming unwieldy and cumbersome. Alistair Cockburn has been influential in his work promoting Use Cases at different levels, some will be user and high-level, some more detailed. It does raise the risk of implementing a more traditional waterfall approach where one analysis has to follow on from another.

Use Case Diagrams for Developers

I know that there’s a strong argument for not using Use Case diagrams at all. This comes from developers and I can understand their perspective. That’s fine by me, I expect developers to know what works for them better than I do. In their case, the text of Use Cases counts for more. That doesn’t prevent analysts from using the tool.