Some problems are already well known. They have been raised in meetings, assigned to a manager, and answered with new instructions or a new tool. For a while things improve. Then the same delay or error returns, and the team gives it attention again.
Each repetition makes the next proposed fix harder to believe in.
Look at the attempts as well as the problem
A recurring problem deserves an investigation of the condition today and of what came before it. A fix may have addressed the symptom and left a dependency untouched. It may have worked at one level of demand and failed when demand changed. People may also have gone back to the older method for a practical reason that no one wrote down.
Without that history, a business can repeat an earlier approach under a new name and meet the same limits.
Ask what you tried, why it did or did not work, and what the next change has to accomplish.
Design for the conditions that made it return
Those three questions turn an old failure into evidence. They show which conditions the next change must accommodate, and they keep the work tied to what the business needs rather than to the most recent idea.
The aim is a fix that holds up in everyday use. That takes attention to why the problem recurs, as well as to the work of resolving it this time.