Category: Mental Models

A principle of lean thinking is to remove waste – anything that stops us from producing our product or service for a paying customer.

This is called muda in Japan and seven ways to create waste are especially important to manufacturing organisations.

They can also be used to think about knowledge work and if we are doing it effectively or not.

Take transport for example. Are we moving work between locations unnecessarily?

This can be as simple as splitting a process up between teams, so that one team focuses on just one part and the other team on another.

This is a good way of creating silos – where people focus on their bit and forget the overall system and waiting customer.

Having a small group of multi-skilled individuals close together that can handle the entire process from starting the project to delivering to the customer reduces this type of transport and waste.

What might inventory look like in knowledge work?

Could it be the collection of reports, analyses, studies, comments, meeting notes and so on that accompany the simplest of projects or decisions?

Is all that really necessary?

A lean organisation can design and test a product with a customer and iterate to a finished version in the time it takes for another to come up with specifications.

Motion simply adds heat to a process. The best knowledge work gets done when people sit down and work on a single task for a stretch of time.

Flapping between projects, having to check in all the time with managers and getting interrupted break the flow of work, raise stress levels and increase the total time needed to do the job.

Then there is the time we spend waiting. Meetings are places where we wait – where interminable discussions happen to decide what to do.

We spend so much time in meetings that there is little time left over to do any of the work or actions that come out of them.

Or, we often do too much – over-processing the work we need to do.

Modern computer systems are so powerful that we can do almost anything on them – which means we spend ages selecting fonts and sizes and colours and logos and header placement instead of creating content or analysis.

User interfaces that try and make things simple don’t help.

A quote from an old newsgroup says that graphical user interfaces (GUIs) make simple things simple and complex things impossible.

Closely related to over-processing is overproduction.

There is little point creating work-in-progress that has to go through a bottleneck.

It makes more sense to work to the capacity of the bottleneck and spend the rest of the time working on a different project or improving the performance of the bottleneck.

And finally, there are defects.

Defects in knowledge work often result from not understanding the end result well enough and rushing to create something too quickly.

Information degrades quickly it is passed along links in the chain of communication.

For example a customer speaks to a sales person who speaks to an operational manager who asks an analyst to do some work who then creates something.

It is almost a certainty that the something that is created is not what the customer had in mind.

The problem is that knowledge work is not as visible as manufacturing – we don’t see piles of inventory piling up.

We may only see a cluttered desk and be aware of late projects.

We’ll also see the effect of waste in rising stress levels among colleagues.

And all that’s just a waste.

What do we do when we have a situation – perhaps something has gone wrong?

We probably rely on experience – either fix things ourselves or get an expert in to solve the problem.

Most solvable problems like this tend to be hard problems, in the sense that they have clean edges.

For example, the tap is broken, a flood has disrupted shipments and we need an alternative or the printer is jammed and we have to get this proposal to the couriers in the next fifty minutes.

Many other problems are less well defined – how do we reduce our environmental impact while still growing the business, how can we develop people’s skills, what information systems do we need to invest in or what changes do we need to make now to stay relevant?

As a species, we have been phenomenally successful at solving hard problems.

For example, many of us live safer, longer and healthier lives as a result of the medical and technological breakthroughs of the last couple of centuries.

This success has been accompanied by an unexpected problem.

Many people are concerned about the growth in population as we head towards 8 billion people.

They point out that it’s unsustainable and we’ll run out of food to feed everyone and really it would be much better if everyone in all these developing countries stopped making so many babies.

But is the cause of population growth really more babies?

It’s not, really… it’s not that we breed like rabbits – it’s just that we’ve stopped dying like flies.

The real solution to population growth might be somewhere else.

It turns out that richer people have fewer children.

So, if we want to manage population, a better way might be to help everyone get richer – so instead of aid should we focus on trade?

We normally think that charities or the UN handle big problems like that but maybe it’s business that will solve it in the end.

The thing is that we don’t know. And with many real-world problems we don’t know what solution is going to work – or for that matter what the real problem is.

That’s where a learning cycle comes in.

Hard problem solvers like to say give me your requirements, I’ll build a system and you’ll be happy.

That works sometimes – but all too often it doesn’t.

That’s because most real-world problems are context specific – they depend on the ideas and assumptions of the people involved as well as the situation and environment.

So, instead of solving a problem we may need to work our way to a solution.

In a learning cycle, we have a theory about what might work and that leads to ideas we can put into practice.

We can learn from the results and that leads to modifying our theory and ideas.

It’s not rocket science – but it’s easy to fall into the trap of thinking a new system or platform will solve our problems.

Real-world problems, however, are usually solved after going round the learning cycle loop several times.

Reference: Information, Systems and Information Systems – Peter Checkland and Sue Holwell

There are two traps we often fall into when developing something new:

1. We try too hard to plan ahead and come up with everything we will possibly need before starting any work.
2. We spend a lot of time making one part better and faster when it doesn’t help to make the overall performance better.

In software development the classic problem is one of requirements and specifications.

We usually don’t know what we need to do the first time we approach a problem.

It’s the process of engaging with and solving the problem usually helps clarify thinking – and when we have finished with our first solution we now know what we really need to do to solve the problem.

The idea of right first time simply doesn’t work when we don’t know what the right way is yet.

A better approach is to prototype our way to the right solution.

We ought to start small and simple – designing something we and others can understand.

Whether it’s a business process or a software program, once we can show others a working prototype we will be able to see reactions, get feedback and other useful information which can help us refine our ideas.

It’s also important we don’t get too fancy or try to locally optimise things.

Something very clever right now may be hard to understand in three year’s time by someone else, who might decide to throw out all our work and start again instead.

Local optimisation is the idea that we work very hard on speeding up one part of the process but miss the real bottlenecks in the system.

The overall time any system takes to work will be controlled by its slowest component. Making any other part work faster will not reduce the overall time.

For example, it doesn’t matter how fast we get ready in the mornings if the real bottleneck is how long it takes the bus to get to our stop.

We could be 20 minutes early – but it’s the bus time that will decide whether we are late or on time to work.

Our natural tendency, very often, is to try and do more – plan more, think more and have more.

In reality that leads to bloat – creating large unwieldy systems no one loves.

We would be better off following a few simple rules:

1. Prototype then polish. Get it working first, then try and make it better.
2. Doing nothing can be very constructive. Words that aren’t there can’t be read wrong. Code that isn’t written can’t fail.

If we must do something – then we should concentrate our time on the things that deliver exponential results, not incremental improvements.

Why is it that many systems – software applications, company policies, operational processes – are hard to use?

Take websites for example. How many company websites are structured in an easy to use, logical manner?

If we ask any company’s marketing team, they will probably say that their website is structured, laid out and easy to follow.

For them, that is.

This is an example of a principle called Conways’s law, which says that Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

In other words, the way in which we structure ourselves influences the systems we create.

For example, if we have two factories, one making bread and the other making jam, we are likely to advertise ourselves as having two product lines, the bread line and the jam line.

We’re unlikely to combine them and pitch ourselves to customers as the jam sandwich line – even though they might actually be looking for a sandwich rather than a collection of components.

This is a natural way for an organisation to behave – after all the way they look at themselves seems natural and normal – so why not show themselves to the world in that way?

Except to a user with little experience, it’s hard to work out what companies do, so they will pick the one that makes it easiest for them to understand.

The problem gets worse as we try and create bigger and bigger systems.

For example, a large software application that tries to do everything will find itself bogged down as it grows, constrained by previous decisions and choices about architecture and design.

One solution to this problem is to limit the size of teams – use multi-skilled individuals in small teams that have end-to-end responsibility for a product.

This is the principle behind work cells in lean manufacturing.

These teams tend to produce work that has clean edges and plays nicely with other teams.

Small teams are also fast – they can get together, come up with a plan, develop a product, test it and get feedback, and iterate and improve in the time it takes for a large organisation to do the paperwork needed to get permission to start.

Although, the size of teams is not a solution by itself – it simply produces systems that may be smaller, simpler and work more independently, and so be easier to scale.

The point is that our default approach when trying to design anything is to focus on what we think a user needs.

But, that thinking focuses on us – not on the user – who might actually approach the situation from a completely different point of view.

Perhaps that’s why some of the most useful tools have been developed by people who made them for their own use – they knew exactly what they wanted from the start.