Have you ever heard it said that “business improvement kills innovation”. I have, numerous times.
Though I never fully understood that because I was of the opposite opinion based on years of experience using improvement methods to actually create innovation.
Then one day, the penny dropped!
I heard it and saw it first hand and began to realise that business improvement can hamper innovation if certain scenarios are allowed to take place.
I came to realise there are points along the improvement journey when the thinking of the people involved could either support of kill innovation. And much of this thinking stems from the conditioning we are exposed to in educational institutions and at work.
First let me define innovation in the context within which I’m speaking here.
I am using the term ‘innovative’ (as in innovative person) to mean:
‘one who explores a myriad of ideas that generates potential solutions both within constraints and outside traditional limitations’
The term to innovate could then be defined as:
‘the act of expanding ones awareness to include ideas that exceed the limitations we are conditioned to think and operate within’.
So what it is that kills innovation?
I would go as far as to say that the number one correction we have to make when mentoring project leaders is the refinement of their problem statement.
While a lack of clarity on the problem can appear in many ways, the one form that kills innovation right at the outset of the project is when you define the problem as a solution.
For example, a statement like “We don’t have a process to manage returns which is resulting in $300k in store holding costs each year” points you towards doing one thing - developing a process to manage returns.
A statement like “Currently 30 percent of returned goods are sitting in the store for a period longer than 3 months which is resulting in $300k in annual holding costs” gives us a chance to do more than just design a process. The observation of the actual problem without saying what to do to fix it opens us to many possibilities.
An interesting pattern of thinking I see with 100 percent of students in my lean training simulation is revealed when I ask them to tell me what the problems are.
I hear responses like ‘the sieve is not big enough’ or ‘a larger ROM pad has to be built’ or
They see the waste but the conscious brain immediately frames the observation in the form of a solution.
Seeing waste (e.g. we spill material as the sieve is shaken) opens you up to many ideas while seeing a solution (e.g. we need a bigger sieve) gives you just one.
There’s a whole bunch of different tools that can be used to study cause and effect; tools such as the Ishikawa Diagram (or fishbone) and the 5 Whys and CE Structure Trees.
Where these go wrong is when a facilitator allows a “single solution cause” to enter and remain in the process.
When someone says ‘lack of training’ or ‘not enough staff’ or ‘the absence of a procedure’ is the cause, they are solution thinking. Each of these is treated by a single solution.
However, when we turn the ‘lack of training’ into the real observation, i.e. ‘everyone does it a different way’, we are at the real cause and now open up to innovation.
Here is a pet one of mine. We teach value add / non value add concepts in lean training in the context of processes and activities.
In order to be determined as value adding work, an action step must meet three criteria - customer cares about it, change takes place to the product or service, and it’s the first time you do that task.
People understand what those criteria are, but when it comes to actually applying those criteria, we see steps being defined as value adding because of a multitude of arguments:
"If we didn’t do it we’d be in trouble" (so admin work gets in)
"We have to get the product to the customer" (so transport gets in)
"The government says we have to do it" (so compliance work gets in)
"If we don’t check it bad product will get through (so quality checks get in)
Finally we end up at a point where most of the work in a process is considered value adding.
Look, the rules of value adding are there to make sure you identify those activities which are truly value adding in terms of the customer requirements and efficiencies.
And the reason we separate these from non value adding is to guide us to where we should give attention (non value adding) in order to make a process lean.
The more ideas that get included in the value adding mix, the less activities we actually challenge the necessity to do.
That’s an innovation killer.
An operator is asked to explain what they do so it can be drawn as a flowchart.
They respond with their experienced interpretation of the series of activities - “well first I receive the order, then I calculate the invoice total, I record the details in the TRS, I then place it in the outbox for processing.”
The question “tell me WHAT you do” gets you information about the flow of work and how it actually happens.
However, the ‘chunked up process’ it produces (i.e. macro process flow) conceals the details that would be provided if you asked “tell me HOW you do that?”
It’s the HOW you do it details that reveals where waste sits.
So how do you calculate the invoice total?
“Well first I identify the batch number, then I take the first 3 digits and compare these to the matrix and identify the base price, I write that on the order, then i locate the second 3 digits and compare these to the second matrix to identify the discount ......” etc etc.
What is not necessarily revealed in the ‘what do you do’ question and answer scenario are all of the duplicated activities and unnecessary writing that actually takes place.
Innovation won’t occur when we accept what the experienced operator says about what they do, and (a) we have not seen the process so don’t know what to ask to dig deeper, and (b) we don’t get to the ‘how do you do it’ question and draw out the waste that actually sits in the process.
Finally, how you facilitate a group can hinder or help with innovation.
Be super careful about how and when you discussion actual project constraints and limitations. Brainstorming and solution generation activities conducted with people with self imposed rules about only throwing out ideas that meet certain criteria or are within constraints (e.g. can’t spend any capital) may result in good ideas not being put forward.
Even if that idea would not have been a workable or permissible idea, the fact the idea was held back means we’ll never know what good ideas it might have prompted.
If you allow any of these scenarios to exist, of course innovation will be hampered.
Be disciplined enough to avoid these, and be aware enough to see them when they do arise - because they will.
George
