Problem Statement Framing

A well-framed problem statement opens possibilities, while a bad problem statement closes down alternatives and quickly sends you down dead ends of facile thinking.

Consider a few typical problem statements you might hear during a management review:

  1. We have too many deviations
  2. We do not have enough people to process the deviations we get
  3. 45% of deviations are recurring

You hear this sort of framing regularly. Notice that only the third is a problem, the other two are solutions. And in the case of the first statement it can leave to some negative results. The second just has you throw more resources at the problem, which may or may not be a good thing. In both cases we are biasing the problem-solving process just as we begin.

The third problem statement pushes us to think. A measurable fact raises other questions that will help us develop better solutions: why are out deviations recurring? Why are we not solving issues when they first occur? What processes/areas are they recurring in? Are we putting the right amount of effort on important deviations? How can we eliminate these deviations?

If a problem statement has only one solution, reframe it to avoid jumping to conclusions.

By focusing on a problem statement with objective facts (45% of deviations are recurring) we can ask deeper, thoughtful questions which will lead to wisdom, and to better solutions.

To build a good problem statement:

  1. Begin with observable facts, not opinions, judgments, or interpretations.
  2. Describe what is happening by answering questions like “How much/How many/How long/How often.” This creates room for exploration and discovery.
  3. Iterate on the problem statement. As you think more deeply on the situation modify your first version. This is a sign that you understand more about the situation. This is the kind of data that will join with the facts you discover to lead towards sound decisions.

The 5W2H tool is always a good place to start.

5W2HTypical questionsContains
Who?Who are the people directly concerned with the problem? Who does this? Who should be involved but wasn’t? Was someone involved who shouldn’t be?Roles and Departments
What?What happened?Action, steps, description
When?When did the problem occur?Times, dates, place In process
Where?Where did the problem occur?Location
Why is it important?Why did we do this? What are the requirements? What is the expected condition?Justification, reason
How?How did we discover. Where in the process was it?Method, process, procedure
How Many? How Much?How many things are involved? How often did the situation happen? How much did it impact?Number, frequency

Remember this can be iterative as you discover more information and the problem statement at the end might not necessarily be the problem statement at the beginning.

ElementsProblem Statement
Is used to…Understand and target a problem.
Provide a scope.
Evaluate any risks.
Make objective decisions
Answers the following… (5W2H)What? (problem that occurred)
When? (timing of what occurred)
Where? (location of what occurred)
Who? (persons involved/observers)
Why? (why it matters, not why it occurred)
How Much/Many? (volume or count)
How Often? (First/only occurrence or multiple)
Contains…Object (What was affected?) Defect (What went wrong?)
Provides direction for…Escalation(s)  Investigation

How we tell our story

“If it Isn’t Written Down, then it Didn’t Happen” is a guiding principle of the quality profession.

There are four major types of writing in quality: instructional, informational, persuasive and transactional. When evaluated against the three major document types instructional is a functional document, informational is a report and transactional is a record. This is not to say that all transactional business writing should be considered a record, the traditional argument against emails in quality systems for example.

It is important to understand these differences as they require differences in writing style, format and grammar. An SOP (instructional/functional) is very different that an informational/report). When building your writing competencies it is important to remember these are different (with a common foundation).

We utilize reports in our quality systems (and everywhere else) to act, to communicate information, to capture work completed, to record incidents, to finalize projects and recommendations, and to act as an archive. A well written report allows the reader to easily grasp the content and, if applicable, make informed decision. Report writing is a cornerstone of a CAPA system (from incident identification to root cause through CAPA completion and effectiveness review), validation, risk management and so much more.

In short, reports are our stories, they form the narrative. And how we tell that narrative determines how we think of an issue, and how we will continue to thing of it in the future.

We tend to mix and match two modes in our report writing — Story thought and system:

  • Story thought emphasizes subjective human experience, the primacy of individual actors, narrative and social ordering, messiness, edge cases, content, and above all meaning.
  • System thought emphasizes 3rd-person descriptions of phenomena from a neutral perspective, the interchangeability of actors and details, categorical or logical ordering, measurements, flow, form, and above all coherence.

We tend to lean more heavily on system thought in quality,the roots of the discipline and the configuration of our organizations make us predisposed to the system thought mode. This means that over time, best practices accumulate that favor system thought, and many of our our partners (regulatory agencies, standard setting bodies, etc) favor the measurable and the reducible. However, by favoring the system thought mode we are at jeopardy of missing how human beings function in our organizations and how our organizations need to deal with society. And we make mistakes. Me make bad decisions. We fail to deal with the truly complicated problems.

It is time to learn how to utilize story though more in quality.

What is in a title

Recently I’ve seen a few inspection observations that have provided an observation on the title of quality record (e.g. deviation, CAPA, change control).

The title might seem the most basic part of a quality system record – a simple task – but instead it should receive some serious thought. This is any inspector’s first interaction, it serves as a historical flag that generations of readers will use to become familiar. And everyone falls prey to “judging a book by its cover.” This cognitive bias tends to make readers considerably susceptible to allowing the quality systems title to function as the sole factor influencing their decision of whether to read or skip a record. A bad title could shape an inspection or deprive an important historical record from being evaluated in the future. We can do better.

A good quality systems record title:

  • Condenses the record’s content in a few words
  • Differentiates the record from other records of the same subject area

Some general tips:

  1. Keep it simple and brief: The primary function of a title is to provide a precise summary of the record’s content. So keep the title brief and clear. Use active verbs instead of complex noun-based phrases, and avoid unnecessary details. Moreover, a good title for a record is typically around 10 to 12 words long. A lengthy title may seem unfocused and take the readers’ attention away from an important point.
  2. Avoid: Wrong label issued

    Better: Sample ABCD was issued label 1234 instead of label X4572

  3. Use appropriate descriptive words: A record title should contain key words used in the record and should define the nature of the quality systems event. Think about terms people would use to search for your record and include them in your title.
  4. Avoid: No LIMS label for batch ABDC

    Better: Batch ABDC was missing label Y457 as required by procedure LAB-123

  5. Avoid abbreviations and jargon: Known abbreviations can be used in the title. However, other lesser-known or specific abbreviations and jargon that would not be immediately familiar to the readers should be left out.

It sometimes surprises folks how simple things can have ripple effects. But they do, so plan accordingly and ensure your users are trained on writing a good title. Trust me; it will make things easier in the long run.