Process

Deja Vu

giantknave Brain Farts , , ,

How often does your function experience people coming in to ‘map processes’? And when this happens, how often are they referred to a similar exercise, usually performed for a specific project, carried out a year or so ago?

When your function digs out (what they can find of) these earlier process mapping ‘artefacts’ (as they are, in my view, unhelpfully labelled) for the new mappers to look at, how often do they say “excellent, we’ll use these as a starting point” and then adopt a slightly different mapping approach/ method/ tool and do it all over again.

….and the people ‘mapping’ and those ‘being mapped’ experience a certain déjà vu.

deja-vu

Even worse, do the ‘mappers’ take process performers away from the process to do the mapping in workshops?! Do you think this enables them to map reality or a set of opinions? Do you think they end up with a highly crafted and nice looking ‘logical diagram’ or the complex and messy truth?

If processes have been mapped before and this is being done (yet) again, then some hard questions need to be asked.

  • why did they get mapped last time?
  • who (if anyone) agreed/ agrees with what they produced?
  • who used/ uses them to perform the work?
  • what happened to them? (are they likely to be complete, current and meaningful?)
  • …and therefore, why does it need doing all over again?

Projects vs. Processes:

If the purpose of mapping is ‘for a project’ then there is already a problem.

A process exists all the time, no matter what projects are being done on (or, more likely, to) it.

A process should have a purpose and a clear customer. It will have demands that are placed upon it (both value and failure) and a capability for handling that demand (which includes variation). It will have a desired flow (how it should be performed), a current flow (how it is performed) and a set of system conditions (constraints) that make this so.

Whilst a project might affect a process, you shouldn’t need a project to understand a process and you don’t always need a project to improve a process. If you do, then you aren’t properly managing your processes!

Conversely, if you’ve got a project that is going to have a major impact on your processes….you had better be managing your processes well for this project impact to go smoothly. Otherwise you can expect the proverbial car crash.

Purpose

Let’s get to the real point: Every process performer wants to do a good job and, to do this they desperately* want:

  • really good process knowledge that they can easily use to do their job to the current standard;
  • this process knowledge to be able to cope with (absorb) the variety that they experience in customer demands, not force them into an unhelpful straight jacket;
  • to be able to use their actual experiences (as opposed to what is supposed to happen) and make sure that these learnings are captured, understood and properly used so that the process knowledge is continuously improved for them and for the benefit of their colleagues;
  • to know when the standard has changed, why and to what such that they can easily and consistently adopt it…and this means there is NO confusion as to what the new standard is and from when it is to be adopted.

What you will notice from the above is that it is the process performers who most want and need excellent and current process knowledge and, standing back, this is actually rather obvious!

* I use the word ‘desperately’ because this is what I always hear when I talk to the process performers at the Gemba (the place where the work is done). They cry out for the above!

But is this what our usual process ‘mapping’ focus is? I would say not.

Reality:

So what actually happens?

Projects come along, pull process performers into workshops, ask them what they do, document what they say, (sometimes) ask the process performers to ‘sign off’ on these ‘artefacts’ (grrr) who, in turn, typically think “it doesn’t tell the whole picture but, yeah, that’s about right” or “it’s not how I would have explained it, but I can see what you’ve done there”…and then the project goes away allowing the process performers to get back to their reality….until, wham, the project change is sprung on them.

In parallel to this, process performers are getting on with their day jobs and, desperate to make it easy for themselves to know what to do, they create (or augment) the necessary process knowledge to perform the work. They do this in whatever medium they have available to them, in what little spare time they have and then store it wherever is convenient for them. All of which is totally understandable.

Over the top of all this, those who determine the policies to be adhered to when carrying out a process (let’s call them the process owners) issue ‘memos’ (in increasingly modern formats) informing all of what is changing and how it should be done from now on. Similarly, these process owners also issue ‘rebukes’ as to what people are doing wrong (along the lines of “didn’t you read my memo dated xyz!”) and warning them to “do it right from now on!“.

dogs dinnerThe above usually creates what I would refer to as a ‘dog’s dinner’

Here are some thoughts on what’s needed for our processes to continually deliver customer value:

  • Clarity as to what the organisation’s set of value streams (and processes within) are and who is responsible for what;
  • A horizontal focus on these value streams, rather than a vertical silo focus…so that:
    • a process is seen from the customer’s point of view
    • there is meaningful collaboration by process performers across the flow
  • The process performers and process owners jointly owning their own process knowledge….they need to:
    • determine what they need to know and how it is best provided/ presented for their ongoing consumption;
    • like using this process knowledge; and, even better
    • like improving it (meaning this has got to be easy and obvious to do)
  • A focus on the wider subject of process knowledge, not (just) process maps:
    • i.e. any/ all knowledge necessary to perform the work
    • this includes the business rules (policies) to be applied when performing a process, and any necessary supporting materials
  • A true understanding of Service organisations such that the process knowledge helps the performers to absorb the variety within customer demand, not frustrate it
    • we shouldn’t attempt to create a ‘process encyclopaedia’ that clinically answers everything since no such thing can truly be created. Instead, it needs to allow the absorption of variety
  • An experimentation mentality (trial and error) from which to continually improve how process knowledge is created, provided and improved
  • Expert help on what tools are available to enable the above BUT this help is not to ‘do it’ to them or for them….but to advise and support them

Some good tests for process knowledge are:

  1. how comfortable (or conversely, anxious) a new starter is when beginning their work; and
  2. if/ how well a seasoned operator picks up a change in process without reverting to the old way.

And finally….it’s not about tools!

It doesn’t matter how good the ‘process management’ tool is that you have found if you don’t understand and properly live the above. Your investment in such a tool (and the resources to populate it) is likely to become one huge costly, dare I say ‘dog turd’ of a, mistake. You can create amazing (looking) process knowledge in an awesome tool but if no one uses it to perform (and continually improve) their processes then, wow, what a waste!

“A fool with a tool is still a fool” (Grady Booch).

Conversely, we seem to have the idea that there is only one tool ‘out there’ that will work for us. Rubbish. Many tools will help you, though no doubt some will help more than others. The process performers can successfully start with using, say, MS Word if they want…and then continuously improve through their experimentation and learning…where this may take them in many directions as opposed to finding ‘the one tool to rule them all’.

There is no ‘right answer’ when it comes to tools, only a never ending journey to continually improve the efficiency and effectiveness of how process performers know how to carry out their work in the best way currently known for the good of the customer.

Are you currently involved in ‘process mapping’? Is this Déjà vu for you?

Meet the process

giantknave Brain Farts , , ,

IvoryTowerAll rational ‘leaders’ appreciate that, rather than sitting in metaphorical ‘ivory towers’, they need to understand what actually happens in their business.

But how do many leaders go about this? I suggest that the following two techniques are the norm:

1. Hold a regular ‘road show’ in which the leaders present to ‘their people’ and, at the end, hold a Q&A session.

What usually follows are questions from the floor that are:

    • generalist in nature and which can be answered safely, politically with ‘happy talk’…and everyone appears content; or
    • highly specific and which need to be answered ‘off line’ because how could you expect your leader to be able to answer that on his/her feet…and no one is the wiser

Whilst such leaders may be great orators and the people may like what they hear….it becomes somewhat of a show divorced from reality.

2. Perform ‘tours’ of their facilities, usually starting with a (very carefully prepared) workshop presentation by that function’s management team, and then being introduced around the floor by the duty manager…along the lines of “Leader, this is your worker…worker, this is your leader…now have a polite chat as if he/she were the Queen”.

What usually follows is a discussion with a random set of workers who are conveniently at their posts that:

    • is full of pleasantries: “so how are things”…”very good thanks”….”that’s great to hear, keep up the good work”…and everyone is happy; or
    • is used by a ‘plucky worker’ as a golden opportunity to air a particular soap-box issue (which may have little relevance in terms of size and occurrence)…and management MUST now act immediately on that issue because the leader now ‘knows about it’ and has to be seen to be ‘listening to the workers’

How much of reality do the leaders actually get exposed to? How much ‘polishing’ is likely to be performed before a management presentation? How distorted (subdued, careful or biased) is the process performer’s voice likely to be?

…how is this really helping the customer receive a forever improving service?

I suggest that ‘leaders’ (whatever level in an organisation) switch their mentality from ‘meeting the people’ to ‘meeting the process’. This means:

  • listening to, and observing actual customer demand at the point it comes in; and
  • following actual units of demand through the value stream (not just a silo within!) until its successful conclusion.

Now, it should be obvious that to do this the leader has to meet the process performers along the way…but the purpose is totally different. Instead of focusing on a person, there is a joint focus (leader and process performers) on the unit of customer demand and how it is processed through the value stream – with its warts and all. This is likely to garner a level of trust with the process performers as and when they believe the leader is really interested in the process, not in judging them.

Meeting the process is often referred to as ‘Gemba walking’, where Gemba is the Japanese word for ‘the real place’ or place of action/ where the work gets done. A Gemba walk involves walking with a unit of customer demand, from its trigger all the way through to its resolution (to the customer’s satisfaction). In performing this, the leader will see the environment that their management system requires the people to work within and probably a great deal of waste along the way.

To be clear: A Gemba walk isn’t a one off thing…it is a management practice that is regularly performed. This regularity is hugely important:

  • one walk won’t uncover the variety that exists within customer demand, or the subsequent process;
  • establishing the trust of the process performers will come over time (as and when they believe in you); and
  • we want to see the process actually changing for the better as leader, management and process performers continue to make changes to improve their capability of meeting the customer’s true purpose.

The act of actually ‘meeting the process’ will ensure that the leader really gets what’s going on and what’s possible…and can ensure that the appropriate management system is put in place that ensures continual process improvement.

Footnote:

Here’s a link to a post that I subsequently wrote on how to ‘Gemba walk’: Gemba Walking: A ‘How to’ Guide

Bad digger driver or bad process?

giantknave Brain Farts , ,

5tonne_diggerOn Thursday 29th October 2014, a digger cut through a major gas pipe in the centre of Christchurch and a major evacuation ensued.

There was plenty of talk about this in the tea room at my work place the next day, about the major traffic jams and hassle it caused. The usual “I bet the digger driver gets it!” comment was made….and, possibly, he will. But, on reflection, do any of us think that the digger driver did it deliberately? I doubt it.

The Press article reporting the gas leak notes that the Fire Service representative said “a digger driver working in the area caused the widespread disruption”. Whilst maybe taken out of context, as the media delight in doing, it’s pretty emotive to single out the digger driver.

Much better, I would suggest, is that SCIRT (the infrastructure rebuild organisation) claimed responsibility, stated that they will be doing a full investigation and said “it is essential that we work out how this happened so it does not recur in future.” That’s a lot better, looking much wider than the person AND wanting to improve the process.

It is interesting to note that the reader’s comments section below the article is a mixture of blaming the digger driver, blaming SCIRT and conversely, trying to ‘cut them some slack’ by noting that the post-quake Christchurch environment is a somewhat tricky one to be operating within and it would be a miracle if no such defects occurred given the magnitude of the work being undertaken. I am often frustrated at how people jump to blame without being in possession of the facts.

Whilst this example of a defect causing pain for others is pretty major, we could (if we looked with our ‘blaming bad people’ radars turned on) find lots of examples at work in which you and I think badly of a person because of what we perceive they did, or did not do.

But, standing back, how many people turn up at work to deliberately do a poor job…conversely, how many people are doing their best given the environment they work within…and, perhaps most concerning, how many people have effectively turned their brains to their ‘low setting’ because of the system they have to work within?

So, whenever you find yourself blaming a person, try to stand back and think about the environment that they are working within. If you think about it, you are very likely to find many reasons as to why they acted as they did…and the harder you look, the more likely you are to consider the process could be improved.

Finally, if you think the process should be improved but believe it won’t be…I would ask you to reflect on why this is the case…perhaps the constraint is within the design of the ‘management system’ in which the workers have to operate.

As the Toyota saying goes “Be hard on the process, but soft on the operators.”

‘Management by results’…how does that work?!

giantknave Brain Farts , , , ,

cause_effect__1_1_5312The CEO of the company I work for recently shared a tweet with us summing up an insight she gained at a recent engagement she attended, which read as follows:

“Nick Farr-Jones dinner guest at conference key message focus on process not the scoreboard and you will get result.”

I like this tweet – the words, whilst short, are incredibly important for anyone wanting to make improvements. I thought it useful to dig into this a bit.

Dr W. Edwards Deming was very clear on this point! He set out the practise of ‘Management by results’ (e.g. focusing on a scoreboard of outcomes) as one of the diseases of a ‘modern organisation’ and, instead, proposed that we should spend our time and focus on understanding and improving the processes that produce the results i.e. the results are the outcome of something, and you can look at the outcome till you are blue in the face…but this won’t make it change!

“The outcome of management by results is more trouble, not less….Certainly we need good results, but management by results is not the way to get good results….It is important to work on the causes of the results – i.e. on the system. Costs are not causes: costs come from causes.” (Deming, The New Economics)

Professor John Seddon (think ‘Deming on steroids’ for Service organisations 🙂 ) takes this message on further. He notes that the measures used in most organisations are ‘lagging’ or ‘rear-view’ measures – they tell you what you did.

Seddon has a very clear view on measurement but at this time I want to simply put forward his thinking regarding the difference between operational and financial measures. He says that we should use:

  • Operational measures (such as demand for a service, and a processes capability to deliver against its purpose) to manage; and
  • Financial measures (revenues, costs) to keep the score.

We know that one affects the other but we can never know exactly how and it is waste to divert time and effort to try to do so.

Bringing this back to Nick Farr-Jones and Rugby: A rugby coach uses process measures to manage (e.g. passes complete, line-outs won, tackles made…) and the result quite literally as the score!

So Nick Farr-Jones, Deming and Seddon quite clearly agree with each other. If you work on the capability of a system/ value stream/ process to deliver against its purpose (as from the customer’s point of view) then the results will come.

Finally, you may be thinking ‘ah yes, this is where the balanced scorecard comes in’…there’s a post in there! Watch this space.