Most problems don't come from the parts of a design that have been working for ten years. They come from what changed.
What it is
DRBFM stands for Design Review Based on Failure Mode. It was developed at Toyota by Tatsuhiko Yoshimura. His approach is often summarized in three words: good design, good discussion, good dissection.
- Start from a design that's proven.
- Change as little as possible.
- When you do change something, look hard at that change: what it touches, what could go wrong, and how you'll know.
The heart of it is a question asked about every change: "What else does this affect?"
Why people skipped it
It's another review meeting, and changes happen all the time. Teams save it for big changes and let small ones through. Then a small change breaks something nobody connected to it.
How a bot does it
Bots are good at this because they're good at comparing two versions and tracing connections.
- Give it before and after. The old version and the new one: drawing, spec, skill file, process.
- Have it list every difference. Including the small ones people didn't mention.
- For each difference, ask what it touches. Other parts, steps, documents, people, bots.
- For each touch, ask what could go wrong. And how you'd notice.
- A person reviews the list. Especially the "touches" nobody expected.
The bot brief
Run a DRBFM on this change.
Before: [file]. After: [file]. Other related documents: [list].
1. List every difference between before and after, including small ones.
2. For each difference, list everything it could affect: other parts, process
steps, documents, people, other bots, customers. Cite where you found the link.
3. For each effect, describe how it could fail, how bad that would be
(High/Medium/Low), and how we would detect it.
4. Recommend an action or a check for each High.
5. List any difference you couldn't trace to an effect — say so, don't guess.
Format as a table: Change | Affects | Possible failure | Severity | Detection | Action.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example
A bot's report skill changes from Revision 7 to Revision 8. The owner says, "I just changed where it pulls owners from."
| Change | Affects | Possible failure | Severity | Detection | Action |
|---|---|---|---|---|---|
| Owners now pulled from action log | Weekly report | Blank owners if log entry has none | Medium | Count blanks | Mark "owner needed" |
| Owners now pulled from action log | Monday summary bot (reads this report) | Summary format breaks | High | None today | Test Monday summary before switching on |
| Date format changed (not mentioned) | Monday summary bot | Wrong week picked up | High | None today | Revert or update summary bot |
The third row is the point. Nobody mentioned the date change. The bot found it by comparing the files.
Where bots differ
A bot comparing two files is thorough in a way people rarely are. But it only knows the connections you've written down. If the Monday summary bot isn't listed anywhere as reading this report, the bot can't know it does. This is a good reason to keep a playbook of who reads what. See Your bots need a management system.
What this means for you
- Run a DRBFM on every change to a skill, a process or a design.
- Give the bot both versions, not a description of the change.
- Pay most attention to the effects nobody expected.
- Keep a list of what depends on what.