Translate

Friday 10 July 2015

Business as unusual

The great InThinking thought-leader Bill Bellows gave an inspiring talk at the recent Lean Management Journal (LMJ) Annual Conference in Amsterdam (8-9 July 2015). A lot of what is written below draws from his insights1 but I have added some of my own thoughts and references as well.

Business as Usual

Most of us think about day-to-day management in terms of business as usual (BaU): what are the things we need to do to effectively manage the regular activities of our organisations. 
But traditional BaU thinking can and does lead us awry. There are many reasons for this, but three key causes are as follows.

1. We disregard context (seeing in parts).

Here's a typical type of question that the great W. Edwards Deming would ask: "What do you need to clean a room?". Most of us would come up with a good list of stuff such as vacuum cleaners, cleaning cloths, window cleaner, people to do the work, etc.. All good BaU type answers. Deming, however, would challenge this because he'd point out we'd missed a key element: context - i.e. asking "What sort of room?" The list of stuff would be very different for a hospital operating theatre versus a domestic kitchen, etc.. Yet we all do this - we jump to conclusions based upon our beliefs and assumptions.

Another example of this, which I picked up from the great project management thinker, Eddie Obeng, several years ago, is as follows: You show an audience a slide of two horizontal, parallel lines. The top line has arrow heads at each end, the bottom one has reverse arrow heads at each end. The bottom line appears to be very slightly longer than the top one (see example here: page 1). You ask people to vote - (a) top line longer, (b) bottom line longer, (c) both the same. Most, if not all, will vote (c) because there's a well known optical illusion where this is the case. Except in your version, the bottom line actually is longer (and you then demonstrate that - page 2 of example file above).

2. We separate the relationships (treating in parts).

By this I mean that you look at components of things disregarding their relationships. This can lead to creating waste because managing entities separately that then need to be brought into relationship is more liable to this than if you managed the relationship. Here's an example: in 1983 the Ford Motor Company discovered a dramatic difference in warranty claims between automatic transmissions designed by Ford and produced in two locations, one in Batavia, Ohio, the other by Mazda in Japan. The parts concerned were a valve and the casing into which this was inserted. Clearly the valve needed to have a smaller bore than the casing, but not too small. Ford's manufacturing focus was on the valve diameter and the bore diameter, taken separately. Mazda’s focus was to actively manage the gap between the outer diameter of the valves within the transmission and the corresponding diameter of the valve bore. Mazda had worked out what the ideal gap needed to be and measured according to this, ensuring that variation in gap size was kept under control. In other words, Mazda managed the relationship between the parts.

In my own experience, when working for the NHS many years ago, an improvement project in A&E was very successful and resulted in faster throughput of patients needing to be admitted to the hospital. Unfortunately, the availability of beds - which was only just coping under the old regime - came under additional stress and led to queues building up for admission, with patients on gurneys lined up in hospital corridors. Again, a failure to deal with relationships.

3. We manage problems (defining in parts).

When thinking about what we need to do to keep our services running smoothly we often look for problems to solve - troubleshooting at best, fire-fighting at worst. This seems like the right thing to do: after all, if we don't solve the problems they'll get worse!

But actually what we need to do more often is manage what's going right. For example, when you're driving a car you'll keep an eye on the petrol gauge and, usually, won't allow it to run out before you refill. However you also don't go to the petrol station all the time and there is no set point at which we say "this is when we need more petrol" - some days we might fill up when the tank is nearly empty, and others when it is still half full. This is not managing a problem, it's managing something that's OK so that it doesn't become a problem.

Yet in BaU we manage things like fire fighting:
  • the project is late;
  • the customer has complained about this.
and troubleshooting:
  • prevent the risk that this will break;
  • find contingency to manage this going beyond budget.
We all know that we'd rather not have to deal with the first, but surely the troubleshooting is what we do to prevent it happening? The issue is - we're looking at the problem and not the process; it's as if all we're interested in is when the petrol gauge reaches empty.

It's a subtle difference, but it leads to thinking like "you have to fill the tank when it reaches quarter full in order to prevent it running out" instead of "keep an eye on the gauge and make sure there's always enough petrol". There's also a subtle hidden agenda here which is "I don't trust you to work out what needs to be done, so I'm giving you rules to follow" (see section 3 in the business as unusual part of this blog).

Business as Unusual

So if all of the above is BaU, what we need instead is business as UNusual. Though the reality is what we call BaU is actually "unusual" and what I'm now calling business as unusual should really be the usual practice!

Hopefully you'll have realised that the three things above are all related because they all look at things "in parts" - the components of what to do rather than context; the components of what to make instead of their inter-relationships; the components of what might go wrong instead of the flows that keep things going. It's a lack of holistic thinking that permeates the way we do management - even the traditional organisational chart is an example of that!

The organisational chart dates back to the mid 19th century and work that was done by George Whistler and  Herman Haupt, both West Point graduates working for the Pennsylvania Railroad. The normal story2 is that Whistler created the organisation chart following a train crash in 1847, and used his knowledge of military organisation to come up with a chart that basically identified who to blame if and when a problem occurs. The reality is not quite so simpleas Whistler had been developing his organisation plans as early as 1841, and his work was taken up by Haupt in the 1850s. However what is not in question is that one of the purposes of the chart was to show lines of responsibility. The legacy leaves us saddled with organisational silos and managing things in parts rather than as relationships.

So how do we fix it? The answers are at hand, but too few organisations seem interested in them. My own "starter for ten" (well, three actually) is...

1. Organisations as systems.

Viable Systems Model
The most familiar system to us all is our own body. The human body is made of of millions of "parts" that all function together remarkably well, but there is no "organisation chart" of management - the brain is not the CEO! There is no Director of Nerves or Director of Muscles. As the brilliant cybernetician Stafford Beer realised over 50 years ago, if you were to model an organisation on how the human system works you might come up with a more viable scheme than the current one. His Viable Systems Model4 describes how this can be done, but apart from a few honourable exceptions, not many organisations have taken this on board. He even wrote a book explaining how to put his model into action5. Earlier posts in this blog describe VSM in more detail (especially in relation to project management).

VSM helps you to both model how the systems within an organisation actually work together, and identify the gaps that are causing de-stabilisation. For example, in his interesting talk about his research at the LMJ conference mentioned above, Torbjørn Netland looked at success factors for improvement programmes in Volvo6. One of his findings was that lean audits did not contribute towards success, and he acknowledged that this isn't their purpose anyway. That's obvious in the VSM, where audit is part of system 3*.

2. Organisations as members of dynamic systems.

Predator-prey stock and flow model
Beer's VSM recognises that each system interacts with its environment, but what it doesn't really do is show how this interaction is managed over time. VSM puts in place the systems to manage the interactions, but we also need some way of understanding how the interactions work. This is where System Dynamics comes in. This was developed about the same time that Beer was doing his VSM work, by Jay Forrester initially in an industrial context, but later in a much wider organisation and societal context7.

System Dynamics has, perhaps, had a greater success than VSM, and there are many software tools available to help with SD modelling and simulation. It uses a simple set of ideas based on causal loops, stocks and flows, and equations. The (hard) trick is in doing the modelling. Typical models that are used to show how SD works include population dynamics models such as predator-prey (e.g. this online simulation of forest, rabbits and wolves).  An example stock and flow diagram for this type of simulation is shown here (click to expand).

3. Organisations as people.

You often hear phrases like "the greatest asset of an organisation is its people" - but just as often you see organisational behaviour that belies this through the flagrant lack of care for these "assets". One of the founders of lean thinking (though he wouldn't have described it as such) is Genichi Taguchi who developed the Quality Loss Function8. A key part of this is "loss to society". The important thing here is not so much the QLF itself as the recognition that you can't do something without impacting something else, and that "something else" includes people.

The problem is that organisations think of people in boxes: by this I mean that they place them into constrained containers called "jobs" which have job descriptions, person specifications and role titles. Oh, and they also assess how "important" they are by giving a salary. Is it any wonder that you end up with behaviours like "that's not my job, it's Sam's responsibility to do that", or "I'm not going to do this extra piece of work because it's outside my role and you don't pay me to do that"?

Herein lies a dilemma because VSM and System Dynamics don't seem cope with this aspect very well. In VSM a component of system 1 (operations) can't suddenly start doing a system 5 (policy setting) role, and in System Dynamics a wolf won't start to eat grass instead of sheep!

But we're missing the point, because VSM and SD define roles and interactions between them: they are agnostic as to whether Sam is in this role or that, or indeed whether Sam might do both. But our organisational hierarchies aren't agnostic: they fix people into place. And when this rigidity starts to break down, what do we do? We re-organise and restructure!

So what can we do instead? Well, for a start we can borrow from project management (PM). In PM you have teams, and teams are not static or permanent. They are formed to do a task and made up of the right people to do it. When it's done the team disbands. A person can be in more than one team. Teams can be made up of people with different skills, knowledge and experience. Team leaders are not managers in the traditional sense: they are there to help coordinate (they do a Systems 2 role in VSM terms: see my blog series on this topic). Projects have project boards - these too are not permanent and their make-up can change over time. The board's role (system 5) is to set the direction but not to interfere with the work. It's also to provide the resources (system 3). I'm not suggesting we should manage our organisations as if they are projects, but we can borrow from the project model to rethink the organisation structures.

Conclusion

Business as usual is a mixture of seeing things in parts, treating things in parts and defining things in parts - we need a new paradigm, and it's been around for a long time. Bill Bellows calls this Business as Unusual... well let's try to be unusual!


References:
1: A different presentation by Bellows, given to the 7th Annual Southern California Quality Conference, November 8, 2014 covers much the same ground is available online here: http://www.in2in.org/insights/Bellows-ASQ-8November2014BusinessasUnusual-handout.pdf (accessed 10 July 2015)
2: Chandler, A.D. (1977), The Visible Hand (Harvard University Press) and also Scholtes, P. (1998) The Leader's Handbook: Making Things Happen, Getting Things Done (McGraw-Hill Professional)
3: Hoskin, K.W. and Macve, R.H. (2002) PENNSYLVANIA ($)65000? (Accounting, Business & Financial History Conference, Cardiff Business School, 17th-18th September 2002) Available online at: http://www.lse.ac.uk/accounting/pdf/Macveabfhconf02a.pdf (accessed 10 July 2015)
4: Beer, S (1981) Brain of the Firm (John Wiley 2nd Edn) and also Beer, S (1979) The Heart of Enterprise (John Wiley)
5: Beer, S (1985) Diagnosing the System for Organizations (John Wiley)
6: Netland, T.H., Schloetzer, J.D. & Ferdows, K. (2015) 'Implementing corporate lean programs: The effect of management control practices' Journal of Operations Management, Vol. 36, In press. Available online at: http://better-operations.com/wp-content/uploads/2015/05/Netland-Schloetzer-Ferdows-2015-Management-Control-Practices-Lean_JOM_author-version-A4.pdf (accessed 10 July 2015)
7: Forrester, J.W. (1961). Industrial Dynamics (Pegasus Communications) and also Forrester, J.W. (1971) 'Counterintuitive behavior of social systems' in Technology Review 73(3): 52–68
8: Taguchi, G., El Sayed, M. & Hsaing, C. (1989) Quality engineering and production systems (McGraw-Hill)

No comments:

Post a Comment