How to have a successful journey

photo-winding-roadMike Rother, in his excellent book ‘Toyota Kata’, explains that ‘command and control’ organisations see the ‘implementing’ word as a very positive one but that their obsession with it actually impedes their progress and the development of their people.

To explain what is meant by an implementation versus a problem solving mode:

Implementation mode (‘Go fast to go slow’)

This mode can be characterised as:

  • The need for a clear and (usually overly) simple ‘solution’ up front arrived at by some expert(s) a la “we have the answer!”;

(where this answer is normally derived from copying what others have already done);

  • A detailed plan (the more lines on the Gantt chart, the better!) that sets out exactly what needs doing, when, and by whom to implement the answer;
  • A target date (along with some incentives), established to motivate (!) people to put on their ‘implementation’ blinkers…nothing must get in the way;
  • A finish line mentality – “we got it in!…now let’s move on to something else.”

…in reality:

  • The above requires the organisation to assume everything is ‘steady state’ (which includes ignoring the effects of the rest of the system on the component(s) in focus);
  • However, there is continual change both inside and outside the environment (which may or may not be noticed…and which is unlikely to be understood);
  • It is impossible for us to predict what will actually eventuate;
  • We spend vast sums of money trying to shoe horn our answer into this changing reality, often years after it was conceived;
  • There has been very little meaningful learning and development going on!

“Humans have a tendency to want certainty, and even to artificially create it, based on beliefs, when there is none. This is a point where we often get into trouble. If we believe the way ahead is set and clear, then we tend to blindly carry out a preconceived implementation plan rather than being sensitive to, learning from, and dealing adequately with what arises along the way. As a result, we do not reach the desired destination at all, despite our best intentions.” [Rother]

Problem solving mode (‘Go slow to go fast’):

There are three things we need to know with certainty (none of which is to know the answer up front!). These are:

  • Where we are (current condition);
  • Where we want to be (target condition); and
  • A method by which to manoeuvre through the unclear territory in-between

Some key points to make:

‘Where we are’ means that we really understand our current condition, which includes why we are like this (i.e. the system conditions and management behaviours that make it so).

‘Where we want to be’ doesn’t mean “we want to have implemented x”. That’s just the implementation mode by another name. It means clearly stating a target condition (our challenge towards purpose): how should the process operate i.e. can we describe this in terms of relevance to the customer and the process performers. This description can’t know how it is to be achieved….this will unfold via…

…the ‘method’ (experimentation), which IS clear. The experiments themselves will not become clear until we progress step-by-step through the obstacles within the unclear territory.

“True certainty and confidence does not lie in pre-conceived implementation steps or solutions, which may or may not work as intended, but in understanding the logic and method for how to proceed through unclear territory.” [Rother]

So what’s the point?

Too many ‘projects’ are merely the implementation of a new technology or ideology (that someone has been convinced they need) with:

  • a reverse-engineered ‘business case’ that attempts to justify what should be achieved from ‘putting it in’; and
  • a grand plan with supposedly certain time, scope and cost.

Such projects regularly fail, sometimes spectacularly and even if they ‘complete’ (whatever definition they use for this word), there has been little value added or learning achieved….in fact they often (usually) destroy value and repeat the same errors and pitfalls as the last project and the one before that.

Instead, we should adopt a mindset of:

  • being really clear on what we are trying to achieve (in respect of customer purpose); and then (and only then)
  • work our way towards this ideal through a series of steps:
    • learning as we go; and
    • deciding the next step (the how) as we learn, adapt and ‘see’

Okay, so I’ve ‘scratched the surface’ of the idea that a brilliant implementation plan is not the answer. For those that would like an excellent analogy to think about this, here’s a useful (and short) post: The difference between launching a rocket and driving a car.

We should know ‘before we leave the house’ what our intended destination is, why and how we would know how we are going towards it…and we should steer our way there (unconstrained) as we meet the unknown obstacles on the way.

There would be little point in claiming ‘completion’ because we had spent our quota of time, distance or cost if we hadn’t actually arrived!

…but why?

downloadProject Steering Group Meeting starts:

Project Manager: “We’ve had a major setback and we can’t ‘go live’ next week as per the original target date set. We’ve worked some long hours to think about this and what we need to do and have re-planned. We have worked out that, if we work really smart and hard and everything goes to plan, we believe we could be back on track in 8 weeks time.”

Big tough Leader: “I want it in 4 weeks.”

Project Manager: “I know it’s disappointing and you would like it as quickly as possible. That’s why when we did the re-planning we cut out all the fat AND used really stretching estimates…and it is this that gives us the 8 weeks….it could easily have come out at 12 weeks or more.”

Big tough Leader: You’ve got 4 weeks.”

Project Manager: “I’ve spoken with everyone. We got together as a team to work out what is possible. They all rolled their sleeves up, did some good honest talking and they tell me that they will move heaven and earth to hit 8 weeks.”

Big tough Leader: “Look at my fingers [holds up four fingers]. I’m not going to discuss it anymore.”

…and so the meeting ends, with the Big Tough Leader walking off pleased with him/herself and the Project Manager having the unenviable task of trying to explain to the troops and keep them motivated…all of which will take further time (which could have been spent delivering value).

It’s at this point that I would want to press the ‘stop’ button in the conversation, wind back and at the point that the Big Tough Leader says “you’ve got 4 weeks”, I would want the Project manager to say “…but why?”

Now, there appear to be two logical answers to this question:

  1. The leader knows something that the Project Manager doesn’t, like there’s an important constraint that means that 8 weeks is no good….in which case the Project Manager (and the team) needs to know the full facts and can enter a proper dialogue about the options available…with some likely innovative ideas coming out; or
  2. The leader is attempting to ‘manage by fear’ and thinks that their clever ‘stretch-target’ will motivate (!) the workers. Further, it shows that the leader doesn’t trust his/her people and thinks they are lazy, that they are holding effort back and need a carrot/ stick management approach.

So, what actually happens when unrealistic target dates are set?

  • disbelief by those who actually know the reality of the situation…de-motivation…and therefore a major disconnect between worker and leader…leading to an understandable lack of respect in the leader;
  • de-scoping of value from the work so as to hit an arbitrary target date (“we delivered something!”), as opposed to achieving a target condition;
  • the customer (the people receiving the outcomes) never believing the dates that you give them along the lines of ‘the boy that cries wolf’ fable. This is because big tough target dates are published (“because, then, that’ll make ’em work harder!“) and then have to be continually re-published as reality bites and dates are re-set;
  • much effort is wasted ‘analysing’ variances between what was dictated vs. what eventuated…none of which comes as much of a surprise to the workers who knew anyway;
  • much wasted effort is spent after ‘go-live’ coping with the semi-complete outcome and the customer fallout.

Okay, so you hit a published target deadline…big deal!

What matters is what was actually achieved in respect of the purpose of the value stream being affected. Is the value stream more or less capable in the eyes of the customer?

Now, obviously any roll out needs to know a date to be able to plan its implementation, BUT we should be trying to delay the setting of this date as long as possible in the work so that we have the most certainty as to what it will actually be – a ‘just in time’ mentality rather than a ‘hook to hang people on’.

Let’s try to move:

  • away from thinking setting target dates as a management tool is a good thing;
  • to thinking that setting target conditions* is the right thing to do, and then providing an environment in which everyone works to achieve this as effectively as possible.

* A reminder: a target condition is a description of the desired future state (how a process should operate, the intended normal pattern of operation). It is NOT a numerical activity target or deadline.

“First determine where you want to go, then consider how to get there within financial and other constraints.” (Mike Rother)

Do you use target dates as a ‘management by fear’ tool to ‘make people comply’?!