Necessary but not sufficient: check what else is needed
What else must be in place for this change to help? Use this page to check whether a proposed response is incomplete—and avoid treating one useful action as the whole solution.
Writing a procedure, buying software or delivering training may help. Completing the activity does not establish that the intended result will follow.
Necessary is not the same as enough
- Necessary: a condition that must hold for the stated outcome to occur. Without it, that outcome is not possible.
- Sufficient: a condition, or combination of conditions, that ensures the stated outcome under the stated assumptions.
- Helpful: something that may improve the chance or extent of success, but is not necessarily essential.
Be precise about the outcome and setting. A particular tool or policy is not “necessary” simply because it is familiar; another route may achieve the same result.
Meeting every necessary condition you have listed does not prove sufficiency. The list may be incomplete, the explanation mistaken or important assumptions unmet.
Example: prevent rework from an outdated specification
This is an illustrative example, not a finding about a real business.
Putting the approved specification in a shared folder may help, but does not ensure it is used. Old copies may remain at workstations; staff may lack access; orders may not identify the required version.
A proposed response could combine a clear version reference on each order, reliable access and a way to withdraw or visibly supersede old copies. Check the actual work before deciding which arrangements are needed.
Test whether people can find and use the right version, whether this type of rework falls and whether the arrangement introduces delays. It may address one pathway without explaining every error or late order.
Check the proposed combination
- State the result. What should improve, for whom, by how much and when?
- Explain the connection. Why should this change help? Separate evidence, assumptions and unanswered questions. Use evidence-led investigation where needed.
- Check what else is required. Consider capacity, skills, tools, information, authority, cooperation and feedback—not a mandatory checklist. Explore system conditions.
- Challenge the explanation. What could still prevent the result, even if we make the change? Could a different route work? What might make things worse elsewhere?
- Choose a workable test. Agree responsibilities, sequencing, measures and review. Do not start every suggested action: choose a coherent response that fits available capacity, then learn and adapt.
If two requirements seem incompatible, TRIZ separation may help generate alternatives. Use PICK to compare ideas—not to drop a genuine dependency just because it is difficult.
Optional: where Goldratt and Dettmer fit
Goldratt’s Necessary But Not Sufficient, with Eli Schragenheim and Carol Ptak, explores why technology alone may not deliver the promised benefit. The practical question is what working arrangements and management rules also need to change.
Dettmer’s Logical Thinking Process offers more structured ways to examine proposed cause-and-effect links, prerequisites and action sequences. These tools can help make assumptions visible; they do not prove the explanation or replace testing in the actual setting.
Check the result—not just the completed actions
Measure implementation, the intended outcome and possible harm. Allow a justified period for effects to emerge; keep checking whether the required arrangements remain in place.
A chart or Bootstrap CUSUM analysis can help identify a performance change, not prove sufficiency or its cause. A change point does not guarantee permanent improvement. No detected change does not, by itself, show that a condition is missing: consider effect size, timing, data quality and other explanations.
In safety-critical work, an aggregate incident trend cannot establish why an individual event occurred or prove that a particular package prevents every recurrence. Follow appropriate safety and investigation requirements.
Choose useful measures →What’s your next useful question?
If we make this change, what could still stop the result—and how could we find out?
Return to Right intervention? →Manage competing commitments →