Connecting...

W1siziisijiwmtcvmdmvmjkvmtqvmtqvmdmvmzmyl1nly3rpb24gagvhzgvyx09qrvjbvelptlmyys5wbmcixsxbinailcj0ahvtyiisijiwmdb4njawiyjdxq

Define the Problem before starting your Improvement Journey

By Paul Swift


I recently came across a client who had been on an improvement journey for a while with some degree of success but with the potential to really make some monumental strides forward. When we discussed the journey so far, one thing became really obvious and I thought it was worth sharing.

You see, this company had set out to ‘make improvements’ to the way they operated, which sounds like a noble aspiration and one that most businesses should indeed be embracing. The problem was, they had never fully defined the problem they were trying to solve. Now you may think that this isn’t such a great issue but imagine if you went to the doctor and told him you didn’t feel well and that was all you told him. How long do you think it would take him to diagnose you correctly? He would end up guessing as to the solution to fix your ailments, without knowing EXACTLY what part of you wasn’t right and the background to this.

It’s exactly the same for improvement initiatives. Define precisely what problem you are trying to solve. It’s like a journey;

Beginning the journey… Define the problem

What is this problem costing us? Are we likely to lose business as a result? Look at all the potential problems and classify or rank in terms of financial impact (increased costs, revenue lost or at risk etc.) Recast this, referencing stakeholders’ requirements – for example, cost reduction, improved customer satisfaction, and market share implications.

  • Looking at the Problem Statement
  • If you’re tackling a problem, what’s wrong?
  • What’s not meeting our customer’s requirements?
  • When and where does the problem occur?
  • How big is it?
  • What’s the impact on the business?

Without the data we need, the issue statement and the description of what’s wrong may be our best guess perception.

Some Questions to Consider About Your Problem Description;

  • Is it based on fact or gut feel?
  • Does it already suggest the root cause?
  • Can the team collect data to verify it?
  • Is the description too narrow or too vague?
  • Is the solution already implied?
  • Would your customers be pleased you’re planning to work on this?

In Summary, the better we can define the problem, the faster we can identify a root cause, which in turn will allow us to generate a solution.

Next time, we’ll look at the flip side of this, the goal statement. Another essential element of the Define stage.


If you enjoy reading my blogs, please take a look at my many other on-line resources,
Facebook, https://www.facebook.com/leansixsigmacert
Follow me on twitter, https://twitter.com/DrLeanSigma

I have also recently launched a new range of #lean Six Sigma on-line training courses which you can read about here,http://www.beyondlean6sigma.com/  

Tags:

Paul Swifti&iImprovement and InnovationLean Six Sigma