ObeyaJapanese: 大部屋 — "big room"

Obeya (大部屋, 'big room') is a co-located cross-functional programme room — physical, virtual, or hybrid — walled with visual management that displays the entire state of the programme on persistent surfaces. Schedule, open issues, technical risks, prototype photos, A3s under nemawashi, KPI dashboards, supplier status, customer voice, regulatory milestones — all visible simultaneously, all reviewed in a rigorous cadence, all updated by the cross-functional team that meets there. The discipline is not the room itself; the discipline is what happens in the room — daily standups, weekly reviews, visual issue management, and decisions made in front of the data with all the necessary functions present.

The contrast is with the conventional programme structure: functional departments each work in their own area, meet weekly in conference rooms, communicate through slide decks and emails, surface cross-functional issues days or weeks after they emerge, and resolve them through escalation chains. Obeya collapses the communication latency to minutes — the engineer with the problem walks to the supplier-engagement lead at the next desk, the quality lead is in the daily stand-up, the chief engineer reviews the open-issues board every morning. Programmes that took 18 months ship in 9.

Obeya was institutionalised at Toyota in 1993-1997 during the development of the first-generation Prius. Chief engineer Takeshi Uchiyamada had been given a brief that bordered on impossible: develop a hybrid-vehicle platform with twice the fuel economy of conventional cars, productionise it for global launch, and do it in roughly half the time a conventional Toyota platform programme would take — 27 months instead of 60. The conventional matrix-organisation structure could not move that fast.

Uchiyamada's solution was to physically co-locate the entire programme team — vehicle engineering, powertrain, body, electrical, manufacturing engineering, quality, finance, programme management — in one large room walled with the programme state. He met with the team in that room daily. Issues that would have taken weeks to surface through normal channels surfaced in minutes. Cross-functional trade-offs that would have escalated to executive review were made in the room with the chief engineer present. The Prius launched on time and re-defined the hybrid-vehicle category. Obeya became a Toyota standard for major programmes and was documented as a Toyota Production Development System practice by James Morgan and Jeff Liker in 2006.

An obeya's walls are programme-specific but follow a recognisable structure. The Morgan + Liker convention (Toyota Product Development System, 2006) identifies seven canonical zones; mature obeyas adapt the zones to the programme but rarely drop any.

The walls are deliberately not digital screens flipping through dashboards. The whole programme state is visible simultaneously — the engineer looking at an open issue can glance up at the technical state, the schedule, and the relevant A3 without clicking through tabs. Visual simultaneity is the unique cognitive advantage; replacing the walls with a digital dashboard that shows one view at a time defeats the purpose.

Obeya is a cadence discipline as much as a spatial one. Three meetings define the rhythm; attendance is not optional for the core team.

Co-location was non-negotiable in the 1990s Toyota model; distributed teams in the 2020s have forced an evolution. Digital obeya replicates the visual-management discipline using persistent virtual surfaces (Mural, Miro, dedicated platforms) reviewed in synchronous video standups. Hybrid obeya keeps a physical room for the on-site core team while extending the visual surfaces virtually for distributed contributors. Both work — with caveats.

• Persistent surfaces, not slides. The walls (virtual or physical) must be persistently visible between meetings. A digital obeya that exists only during the standup video call is not an obeya — it's a recurring meeting.
• Synchronous standup with cameras on. The cognitive value of the standup depends on simultaneous attention — async substitutes (read-the-update threads) routinely degrade into inattention. Daily synchronous standup is non-negotiable even for distributed teams.
• Reduced cross-functional latency. Digital obeya cannot fully replace the engineer-walks-to-the-supplier-lead's-desk moment. Programmes typically run 15-25% slower in pure-digital mode than in physical mode for this reason — still dramatically faster than non-obeya delivery.
• Onboarding latency. New team members in digital obeyas take longer to absorb the programme state because they cannot stand in the room and look at the walls. Mature digital obeyas invest in structured onboarding walkthroughs (a 1-hour facilitated tour of the virtual walls for each new member).
• Hybrid pitfall: two-tier participation. Hybrid obeyas where the in-room team is the 'real' team and remote contributors are spectators consistently fail. The discipline must explicitly include remote contributors in standup speaking order, decision authority, and wall editing.

• 21 CFR 820.30 / ISO 13485 §7.3 — Design controls. Design-control programmes (Design + Development Planning, Inputs, Outputs, Review, Verification, Validation, Transfer, Changes) are the natural obeya fit — cross-functional, phase-gated, evidence-heavy. Mature MedTech programmes run an obeya per major development programme; the wall zones map directly to the DHF sections.
• 21 CFR 820.30(e) — Design review. Design reviews require independent functional input. An obeya makes this trivial because the independent functions are in the room and have been reviewing the A3s in nemawashi for weeks before the formal review.
• ICH Q8 + Q11 — Pharmaceutical development. New-drug-substance + new-drug-product development programmes benefit equivalently — the QbD design space is constructed cross-functionally and the obeya is the construction site.
• ICH Q9(R1) — Quality risk management. The risk register is an obeya wall zone; risks are reviewed in the daily standup; risk-mitigation actions become open issues with owners + due dates.
• 21 CFR 820.100 / 211.192 — Major CAPA investigations. Major CAPAs (multi-month, cross-functional, regulator-visible) typically benefit from a dedicated obeya for the duration of the investigation. The 5 Whys / fishbone is on the wall; the investigation timeline is on the wall; the effectiveness-verification plan is on the wall.
• ICH Q10 §2.7 / 21 CFR 820.20 — Management review. Standing programme obeyas roll up into the management review automatically — the executive review walks the obeya walls rather than reading prepared slides, sees the real programme state, and makes decisions in front of the data.
• Annex 15 — Qualification and validation. Multi-site validation campaigns (URS, FAT, SAT, IQ, OQ, PQ across multiple equipment trains) are obeya-friendly — the validation schedule, the protocol-execution status, the deviation register, and the QA review queue are wall zones reviewed in daily standup.
• 21 CFR Part 11 + Annex 11 — Electronic records + signatures. Digital obeya platforms must produce Part 11-compliant audit trails on the visual-management surfaces; physical obeyas archive photos of the walls at phase gates as evidence. V5 captures both.

• Attendance rate at daily standup — target >90% for core team. Below 70% signals cadence collapse imminent.
• Time-to-issue-surfacing — average days from issue emergence to obeya visibility. Target <24h. Above one week, the obeya is missing the cross-functional latency advantage.
• Open-issue cycle time — average days from issue raised to issue closed. Target trending down; rising cycle time means issues are accumulating faster than they resolve, programme is at risk.
• Schedule variance — actual milestone delivery vs planned. Healthy obeyas show smaller variance than peer non-obeya programmes — typically 30-50% smaller.
• Decision velocity at monthly steering — decisions made vs deferred. Healthy obeyas show >70% decision rate (decisions made in the meeting); below 40% means nemawashi was not done and steering is degenerating into debate.
• Cross-functional issue ratio — % of open issues that span 2+ functions. Healthy obeyas show 40-60%. Below 20% means functions are siloing their issues and the obeya is not catching cross-function impact.
• Programme delivery time vs benchmark — final calendar months for delivery vs equivalent non-obeya programme. Toyota benchmark is 40-50% reduction; mature Western adoptions typically deliver 25-40% reduction.

1. Building the room without the discipline. Beautiful war room, walls full of artefacts, nobody actually meets there daily. Within 60 days the artefacts age out and the room becomes a storage closet.
2. Skipping the chief engineer. Obeya without a single decision-maker present at standup degenerates into status reporting; conflicts escalate to email rather than resolving in the room. The chief-engineer (or programme manager with decision authority) is non-optional.
3. Slides instead of walls. Replacing persistent visual surfaces with weekly slide updates kills the visual-simultaneity advantage. Slides hide; walls expose.
4. Skipping or shortening the daily standup. The cadence is load-bearing. 15-30 minutes daily is the floor; cutting to 'twice a week' is the beginning of cadence collapse.
5. Two-tier participation in hybrid obeya. In-room team treats remote contributors as spectators; remote contributors disengage; programme effectively becomes single-site again with worse coordination than pure single-site.
6. Confusing obeya with project-management software. Tools like Jira / Asana / Smartsheet are useful inputs but cannot replace the wall — they show one view at a time, do not enforce cross-functional standup attendance, and degenerate into individual task lists.
7. Treating obeya as a deliverable rather than a discipline. 'We have set up an obeya' is not an achievement; running it for 12 months at full cadence with measurable schedule + quality improvement is.

V5 ships obeya as a first-class digital programme room — designed to support physical, hybrid, and fully distributed teams without sacrificing the visual + cadence + decision-authority discipline.

• Programme obeya workspace per major programme (NPI, design-control, validation campaign, major CAPA, multi-site rollout, hoshin tactic). Configurable wall zones aligned to Morgan + Liker convention; templates per programme type (820.30 NPI, Annex 15 validation campaign, multi-site rollout).
• Persistent visual surfaces. Schedule, open issues, risk register, A3 wall, technical state, KPI dashboard and supplier status all visible simultaneously on a single canvas — designed for a 4K wall display in the physical room and for laptop / iPhone access by distributed team members.
• Daily standup workflow. Auto-scheduled with the programme team, structured agenda (issues raised since yesterday → blockers → today's commitments → KPI flags), 30-minute timer, automatic attendance capture, recorded standup notes auto-roll into the open-issues + decision logs.
• Open-issues management. Cross-functional issue tracking with owner + status + due date + escalation level; surfaces in standup automatically; escalates via configurable thresholds; auto-promotes to CAPA when criteria met; auto-creates kaizen experiments when patterns repeat.
• A3 nemawashi integration. A3s under nemawashi posted to the obeya wall for full-team visibility; conversation logs from nemawashi feed the A3 revision history; decision meetings happen in the obeya with all stakeholders present.
• Phase-gate reviews. Design-control phase gates (planning, inputs, outputs, review, verification, validation, transfer) and validation phase gates (URS, FAT, SAT, IQ, OQ, PQ) modelled as wall zones with structured review workflow + Part 11 e-sig at each gate.
• Risk register integration. ICH Q9(R1) risk register lives as a wall zone; risks reviewed in daily standup; mitigation actions become open issues; residual-risk trends populate the KPI dashboard.
• Schedule + KPI auto-population. Programme schedule auto-pulled from work orders + validation protocols + supplier deliveries; KPI dashboard auto-populated from live programme data; no manual slide-deck maintenance.
• Hybrid + distributed support. Synchronous video standup integrated; remote contributors have equal speaking + editing rights; on-site wall display mirrors the digital canvas; new-member onboarding walkthrough as a guided wall tour.
• Photo + recording archive. Physical-wall photos uploadable at phase gates as evidence; digital-canvas snapshots auto-captured at phase gates; full attendance + decision history retained for regulatory inspection.
• Regulated overlay (820.30 / ISO 13485 §7.3 / ICH Q8 + Q11 / Q9(R1) / Q10 §2.7 / 820.20 / 211.192 / 820.100 / Annex 15 / EU MDR Annex II). Design-control DHF / DMR sections, validation VMP + protocols, CAPA investigation files, and management-review records all share the obeya substrate — auditors see one coherent programme delivery system.
• Part 11 + Annex 11 audit trail. Every wall edit, standup attendance, issue update, decision sign-off and phase-gate approval timestamped + attributed + retained.
• Mobile-safe (iPhone ≤390px). Programme team members can join standup, review walls, update issues and approve decisions from the floor or the road — distributed obeya is a first-class mode, not a degraded fallback.