Why Lessons Don't Stick
Welcome to the Quality During Design podcast. When we're in work, we are faced with challenges having to do with the project. Those challenges can be fun. The not fun challenges are having to rediscover the same problems over and over again. This could be a lesson learned from another project that just never translated to what we were working on.
It could also be just the frustration of the same problem happening over and again with how we do our work.
It's frustrating that the lessons that we learn never seem to stick or we have trouble carrying them forward. And it's a problem. It's a loss. It's not a failure because anybody's careless. It's a failure because the system that we're working in was built to react, not to prevent.
Reactive Systems Hide Data
Within reactive organizations, the intent is usually protection. We're protecting people. There're liability concerns, we're protecting the company.
When there's an issue that pops up or a problem, the first reaction is to fix it. Stop the bleeding, fix the problem, redirect, make sure that things are protected. But then we don't take the next step. You can think of it as continuous improvement, root cause analysis, however you want to think of it.
Yes, there are projects that are started as continuous improvement in order to fix some systemic issues, but oftentimes they don't do enough, or they don't go far enough, and it's difficult to combat some of these reactive systems that we've intentionally built, that are keeping us stuck. This sort of failure information- failure about our products, about our quality management system, about a manufacturing process- this is good information for us to know because we want to learn from our failures.
We don't want to repeat them in the future. But the data gets hidden. It gets compartmentalized into a project. This is why you might have been working on a problem for a project for a couple months, only to later find out that Mike two cubicles down had a similar problem three years earlier and knew the root cause, and it was something that really could have saved you and your project two months.
When reactive organizations are protective in nature, that dictates what gets documented in our lessons learned. And our organizations don't become safer or more streamlined or smarter. They just become quieter because people don't talk about it. And quiet systems don't learn and improve.
Make the System Visible
The work to fix this is not fixing people but making the system visible and then designing something better deliberately, iteratively, and with the humility to adjust when it breaks.
Three Shifts to Learn
So, what does intentional front-end investment actually look like? There are three shifts I see in high performing organizations.
One is that they ensure failure mechanisms go somewhere useful. They're shared with other projects, other divisions, with the field technicians. There is communication along the whole product development cycle, including when it's in the field from concept through retirement or disposal.
And those communications are encouraged by intentionally setting up communication lines and ways to share that information, ways to access that information when you need it.
A second shift is from "who caused it?" Assigning blame to "what did we miss upstream and how do we prevent it in the next FMEA?", For example.
This is more related to the root cause of the problem, the root cause of why we're not capturing these failure mechanisms, why we're not communicating it across the organization. What is the root cause of the system? The failure of our system that's not allowing us to learn from our failures and mistakes.
And then the third shift is treating lessons learned as strategic inputs, not compliance Artifacts filed away after a project closes.
Decision Focused Lessons
There was a time I was consulting on a new product development project. I was acting quality engineer, and we developed supplier quality plans for some critical components.
I did a lessons learned on that project and communicated it with the team, and then a director said, "what are we doing to seed this within the rest of the organization?"
That was the perfect question to ask because now we have lessons learned, which included some things that didn't work out well and things that did work out well. How are we going to incorporate this into the rest of the organization?
And part of that, is understanding who is responsible for making sure that it happens? The overall question to keep asking when we're intentionally designing our systems is, "how does this help people make decisions in their work?" If we can't answer that, the structure probably isn't earning its place.
It isn't providing the value or doing the things we need it to do. "How does this help people make decisions in their work?"
Avoid Over Constraint and Next Steps
Before you go building a system for everything, there's a version of this that goes wrong in the other direction. If you find yourself unable to move because of too much paperwork, too many [00:07:00] checklists too many approval hurdles to get through, and generally it's just too hard. Then the pendulum has swung from accidentally undefined to accidentally over constrained.
Both are system design problems.
Intentional systems are agile.
We should be able to change them when we need to.
We know that whatever system we're developing isn't perfect and we expect changes, so we allow those changes to happen, and we build in a way to be able to make those changes
is the mark of a mature quality culture is one, where learning compounds instead of resets.
If you want to know where your system is leaking, start with a strategic quality integration checklist. You can find it through my newsletter. And if you want to talk through what this looks like in your organization specifically, visit QualityDuringDesign.com/talk.
We'll talk for 20 minutes. I won't pitch anything, but you'll get clarity on your next best move. This has been a production of Deeney Enterprises. Thanks for listening.
