When was the last time you saw something that wasn’t as it should be and just fixed it? Maybe your fix worked, or maybe it didn’t and you thought, ‘well at least I tried’. This sort of thing happens all the time and I guess it always will. In many cases it is not wrong, especially when the consequences of an ineffective fix are not important. However when the consequences are more significant, e.g. when they’d create a non-compliant situation or increase the time and cost of the process, then we really should be more careful before following through with initial assumptions. Another aspect of unsuccessful fixes is the time, energy and cost which is consumed for ultimately little or no benefit. So many process fixes are made based on an assumption that we know what is wrong … and as you probably know, when we ‘assume’ it makes an ‘ass’ out of ‘u’ and ‘me’.
A dictionary definition of ‘assume’ is, “suppose to be the case, without proof”, which is the real reason why acting on well-intentioned assumptions can lead to problems. We want the opposite of ‘assume’ which would include ‘to know’ or ‘to prove’ so that we can be confident we’ll avoid undesirable outcomes while making a change quickly. Mentioning the word ‘hypothesis’ can strike fear into people, bringing back unpleasant memories from school maths classes, but it really shouldn’t as its just “a proposed explanation made on the basis of limited evidence as a starting point for further investigation”. We should follow our initial assumptions with testing to prove or disprove them before taking action. Hypothesis thinking in process and product improvement projects can be critical in bagging the early gains and getting those improvements sooner, to deliver value to customers more rapidly and to prove to the nay-sayers that a structured approach to problem solving does not have to take too much time.
My experience with improvement teams is that they will discuss solutions throughout the project but all too often the project leader will park the discussion as ‘we are not ready for that yet, we’ll pick it up after we understand the root causes’. This prescriptive, sequential approach to problem solving is proven and understandable but not necessarily best for the team who want to see progress – and also the customers who may already be looking for an alternative provider. To make the improvements sooner and be confident about making the right changes rapidly, we should adopt the hypothesis thinking approach.
The improvement team should always be considering the end goal for the customer, so with this in mind and with each new piece of information about the current state, the team must decide if the new information is likely to help achieve the goals or not; if not then move on, if yes then think how that hypothesis can be rapidly and thoroughly tested. The team must consider the risks versus rewards and whether more data will be required for the test to be conclusive – after all, you really don’t want to put the customer or current process at risk. If it helps, break the subject into smaller parts, test them individually and then in combinations to understand if anything changes. In reality there is likely to be more failed tests than accepted, so this process of elimination will reveal where the solution lies. Hypothesis thinking and assumption busting is a robust (and safe) way for the team to learn what is really happening.
Hypothesis thinking will certainly require some evidence: observations of people / process behaviours in different locations; sufficient reliable data to be visualised and analysed; identification of excessive work in progress as seen in the workplace or from a value stream map; the list goes on. If you have adequate data then statistical hypothesis testing may be appropriate to validate differences between groups (or not), or where there is causation regression testing may help quantify that relationship. In many cases however, the data is inadequate, so the team should test their hypothesis / proposed explanation objectively using their knowledge and available information in order to become confident that the fix will deliver the desired results.
Right first time should be the goal of anyone making process changes, but to get that point many hypotheses will have been tested and rejected and only a few accepted.
