Inframe-Outframe

I. Fundament & Systematik

Das teuerste Risiko eines jeden Projekts ist das sogenannte Scope Creep, das schleichende und unkontrollierte Wachsen des Projektumfangs. Inframe-Outframe zieht sofort eine unüberwindbare visuelle Mauer um Ihr Vorhaben. Die Methode schützt das Budget und die Ressourcenstruktur, indem sie das bewusste 'Nein' methodisch genauso hart dokumentiert wie das 'Ja'.

Steckbrief & Key Facts

Kategorie

Projektmanagement & Requirements Engineering

Schweregrad | Komplexität

Niedrig (Kognitiv extrem simpel, erfordert jedoch eine hohe Moderationshärte und Konfliktfähigkeit bei Stakeholder-Diskussionen)

Investition | Ressourcen

Sehr gering (Ein großes Whiteboard und ausreichend Moderationskarten genügen vollständig)

Empfohlene Gruppengröße

3 bis 8 Personen (Entscheidungsträger und Fachexperten)

Zeitaufwand

60 bis 120 Minuten (Je nach Projektkomplexität)

Einsatzbereiche

Projekt-Scoping, Systemabgrenzung, Sprint-Planning, Lastenheft-Erstellung

Brancheneinsatz

Branchenübergreifend etabliert, kritischer Standard in der IT-Entwicklung, dem Anlagenbau und der Medizintechnik.

Inhalt

I. Fundament und Systematik
II. Methodik und Anwendung
III. Evaluation und Risikomanagement
IV. Praxis und Mehrwert
V. Verzeichnisse und Anhang

🎯 Ziele und Grundidee

Im Systems Engineering und im klassischen Projektmanagement scheitern Budgets selten an der initialen technischen Herausforderung, sondern fast immer an schwammigen Systemgrenzen. Wenn ein Team einen neuen Elektromotor entwickelt, muss absolut unmissverständlich geklärt sein, ob das Motorsteuergerät, der Kabelbaum oder die übergeordnete Kühlschnittstelle Teil des konkreten Entwicklungsauftrags sind. Die Inframe-Outframe-Methode erzwingt diese Klärung durch eine unerbittliche visuelle Binärlogik. Ein physischer Rahmen wird aufgemalt. Alles innerhalb des Rahmens (Inframe) erhält Budget, Ressourcen und Management-Aufmerksamkeit. Alles außerhalb des Rahmens (Outframe) wird zwar dokumentiert, aber als reine Schnittstelle oder externe Abhängigkeit deklariert, für die das Kernteam keinerlei inhaltliche Entwicklungsverantwortung trägt.

Die Methode zwingt Stakeholder, ihre oft versteckten Erwartungshaltungen in der allerersten Projektphase, dem Scoping, offen auf den Tisch zu legen. Die größte methodische Kraft entfaltet sich interessanterweise nicht bei den offensichtlichen Inframe-Elementen, sondern bei den Outframe-Elementen. Das aktive Niederschreiben und Abzeichnen von Dingen, die das System explizit NICHT leisten wird, schützt das Entwicklungsteam vor späteren Forderungen und Reklamationen. Es bildet das vertragliche und kognitive Fundament für jede funktionierende Systemarchitektur und verhindert das Verwässern des Kern-Geschäftsmodells.

II. Methodik und Anwendung

Methode im Detail

🔍

📌 Grundregeln und Anwendungsprämissen

Absolute Binärlogik

Es gibt kein methodisches Vielleicht oder Später. Ein Element ist zwingend drinnen oder draußen. Klärt sich der Status im Workshop nicht, wandert es auf eine temporäre Klärungsliste mit einem harten Entscheidungsdatum.

Das aktive Nein

Der Outframe ist keine Resterampe, sondern eine aktiv zu pflegende Liste von Ausschlüssen, die den Stakeholdern explizit zur Unterschrift vorgelegt wird.

Schnittstellen-Definition

Elemente, die physisch oder informatorisch die Grenze zwischen Inframe und Outframe kreuzen, müssen sofort als kritische Interfaces für das Risikomanagement markiert werden.

🧰 Erforderliches Kompetenzlevel und Ausstattung

Eine extreme Konfliktbereitschaft des Projektleiters, um den Wunsch der Geschäftsführung nach Alleskönner-Systemen frühzeitig, hart und datenbasiert abzuwehren.

Ein tiefes Systemverständnis der technischen Experten, um zu erkennen, wenn ein zugesagtes Inframe-Bauteil unweigerlich ein unerkanntes, teures Outframe-Bauteil bedingt. Ausrüstung Ein großes Whiteboard oder eine Metaplanwand, auf der ein dicker, physischer Rahmen gezeichnet wird, sowie farbige Moderationskarten für die Anforderungen.

🧱 Detaillierte Aufschlüsselung der Kernkomponenten

Der Projektleiter (Moderator)

Fokus auf Abgrenzung. Denkweise ist budgetär und ressourcenschonend.
Ziel ist die maximale Verteidigung der Systemgrenze gegen ausufernde Kundenwünsche.
Typische Fragestellung: Haben wir das Budget und die Fachkompetenz, um diesen Punkt wirklich noch in den Rahmen zu ziehen?

Die Stakeholder (Kunden / Management)

Fokus auf Funktionsumfang. Denkweise ist fordernd und erweiternd.
Ziel ist es, alle geschäftsrelevanten Bedürfnisse in das Projekt zu integrieren.
Typische Fragestellung: Wenn wir das weglassen, erfüllt das System dann überhaupt noch seinen versprochenen Marktzweck?

Das System-Interface (Der Rahmen selbst)

Fokus auf Interaktion. Denkweise ist verbindend.
Ziel ist die exakte Definition der Übergabepunkte zwischen unserem Projekt und der restlichen Unternehmenswelt.
Typische Fragestellung: Wenn dieses Modul outframe ist, wer baut es dann in welcher Abteilung und wann wird es präzise an unser System übergeben?

🌐 Online-Durchführbarkeit

Die Methode prädestiniert sich geradezu für den Einsatz von Cloud-basierten Whiteboards. Da das Verschieben von digitalen Post-its zwischen verschiedenen Zonen (Inframe, Outframe, Klärungsbedarf) die Kernmechanik darstellt, können global verteilte Teams diesen Prozess asynchron oder synchron perfekt digital abbilden. Moderne digitale Tools bieten zudem den extremen Vorteil, dass die binären Zuweisungen im Nachgang mit einem Klick in die Projektmanagement-Software exportiert und so direkt in Lastenhefte oder Backlogs umgewandelt werden können.

Anwendung

🔨

Vorbereitung des visuellen Systemkontextes

Der Moderator zeichnet auf einem großen Whiteboard einen deutlichen, dicken Rahmen, der fast die gesamte Fläche einnimmt. Der Bereich innerhalb des Rahmens wird in fetten Buchstaben als Inframe (In-Scope) markiert, der Bereich außerhalb als Outframe (Out-of-Scope). In einer unteren Ecke wird eine kleine, temporäre Parkplatz-Zone für ungeklärte Elemente eingezeichnet. Das Ziel des Workshops, zum Beispiel die Systemdefinition der neuen Anlage X, wird klar lesbar als Überschrift notiert.

Unstrukturiertes Anforderungssammeln (Brainstorming)

Die interdisziplinäre Gruppe (Entwickler, Produktmanager, Kundenvertreter) erhält farbige Moderationskarten. Zunächst werfen alle Teilnehmer sämtliche Bauteile, Anforderungen, Prozesse, Software-Module und Dienstleistungen, die sie im Kontext des Projekts sehen, ungefiltert auf die Karten. Eine Funktion pro Karte. Diese Phase dauert etwa 15 Minuten und produziert einen unsortierten Berg an potenziellen Systemelementen.

Die harte Inframe-Zuordnung

Der Moderator nimmt die erste Karte auf. Das Team diskutiert kurz und knapp, ob das Element zweifelsfrei zum Kernauftrag des Projekts gehört und durch das vorliegende Budget gedeckt ist. Ist die Antwort ein klares Ja, wird die Karte physisch innerhalb des gezeichneten Rahmens platziert. Dies geschieht nacheinander für alle offensichtlichen Kernelemente des Systems.

Die bewusste Outframe-Zuweisung

Nun wird es strategisch. Der Moderator fokussiert sich auf Anforderungen, die angrenzend, historisch mitgewachsen oder reines Wunschdenken (Nice-to-have) sind. Ist ein Element nicht strikt notwendig für den Kernnutzen oder schlichtweg zu teuer, wird es ganz bewusst außerhalb des Rahmens platziert. Dieser Vorgang ist enorm wichtig: Die Karte wird nicht weggeworfen, sondern aktiv in den Outframe geklebt, um das explizite Nicht-Erbringen dieser Leistung visuell zu manifestieren.

Identifikation der Grenzgänger (Klärungsfälle)

Es entstehen unweigerlich massive Diskussionen über bestimmte Elemente. Wenn der Kunde behauptet, Modul Y sei zwingend erforderlich, das Entwicklungsteam aber das Budget dafür verneint, droht der Workshop zu eskalieren. Der Moderator legt solche strittigen Karten auf den vorbereiteten Parkplatz. Diese Elemente erhalten einen dedizierten Klärungsauftrag mit Verantwortlichkeit und Frist, da sie im Workshop selbst nicht binär gelöst werden können.

Schnittstellen-Analyse an der Rahmengrenze

Dies ist der anspruchsvollste technische Akt. Das Team betrachtet die Rahmengrenze. Wenn ein Inframe-Modul zwingend Daten oder physische Energie von einem Outframe-Modul benötigt, wird die Karte exakt auf die gezeichnete Rahmenlinie geklebt. Sie wird als Schnittstelle (Interface) definiert. Für jedes Element auf der Linie muss sofort dokumentiert werden: Welche externe Partei liefert diesen Input, in welchem Format und zu welchem exakten Termin?

Das formale Baseline-Freeze

Sobald alle Karten (abgesehen von den definierten Klärungsfällen) zugeordnet sind, wird der Zustand des Boards eingefroren. Der Moderator fotografiert das Ergebnis hochauflösend. Dies ist ein kritischer vertraglicher Akt. Die anwesenden Stakeholder müssen diesem physischen Bild zustimmen. Ab diesem Moment gilt: Jede zukünftige Karte, die in den Inframe wandern soll, löst automatisch einen kostenpflichtigen Change Request (Änderungsantrag) aus.

Überführung in das Backlog und Dokumentation

Die visuellen Daten werden formalisiert. Die Inframe-Elemente werden 1:1 in das Lastenheft oder den Sprint-Backlog kopiert. Die Outframe-Elemente wandern in ein dediziertes Kapitel des Pflichtenhefts mit dem Titel Explizit ausgeschlossene Leistungen. Die Schnittstellen auf der Rahmenlinie werden direkt in das Projekt-Risikoregister (Risk Log) überführt, da externe Abhängigkeiten das größte Ausfallrisiko darstellen.

Ergebnis

📦

Dokumentatorisches Ergebnis

Ein auditfähiges Scope Statement (Lastenheft-Fundament), das nicht nur die Anforderungen präzise auflistet, sondern durch das Anti-Pflichtenheft rechtlich absichert, was nicht geliefert wird.

Unternehmensergebnis

Der drastische Schutz von internen Projektbudgets und Personalressourcen, da jede spätere Ausweitung des Rahmens sofort als kostenpflichtiger Change Request transparent wird.

Teamergebnis

Massive Erhöhung der psychologischen Sicherheit bei den Entwicklern, da sie genau wissen, wo ihre fachliche Verantwortung beginnt und vor allem, wo sie rechtssicher endet.

Alternativen

🧩

III. Evaluation und Risikomanagement

Tipps

💡

Aus der Praxis für die Praxis

Wertvolle Expertenhinweise helfen dir dabei, typische Stolpersteine zu umgehen, die Effizienz bei der Umsetzung drastisch zu steigern und das volle Potenzial der Methode direkt im operativen Alltag auszuschöpfen

Tipp 1: Nutzen Sie die Macht des physischen Rahmens psychologisch voll aus. Wenn ein Stakeholder eine neue Anforderung äußert, zwingen Sie ihn, selbst nach vorne zu gehen und die Karte in den Rahmen zu kleben. Die physische Hürde der Verortung reduziert absurde Forderungen oft dramatisch.

Tipp 2: Verwenden Sie eine spezielle, stark leuchtende Signalfarbe für die Schnittstellen-Karten auf der Rahmenlinie. Diese Karten sind die Achillesferse Ihres Projekts, denn dort müssen Sie sich auf externe Lieferanten oder andere Abteilungen verlassen, über die Sie keine hierarchische Kontrolle haben.

Tipp 3: Der Outframe ist kein Mülleimer. Wenn Stakeholder Ideen äußern, die für Version 1.0 zu teuer sind, benennen Sie eine Zone im Outframe als Roadmap für Version 2.0. Das dämpft den Schmerz der Ablehnung beim Kunden, ohne Ihr aktuelles Projektbudget zu belasten.

Fallstricke

⚡

Wo Licht ist, ist auch Schatten

In der Praxis führen typische Fehler oft dazu, dass die Anwendung der Methode ihr volles Potenzial verfehlt.
∝ Die Parkplatz-Falle. Schwache Moderatoren kleben aus Angst vor Konflikten mit dem Management alle unangenehmen Anforderungen auf den Parkplatz. Wenn am Ende des Workshops mehr Karten im Klärungsbedarf liegen als im Inframe, ist das Scoping völlig gescheitert.
∝ Angst vor dem klaren Nein. Das Team dokumentiert nur den Inframe und lässt den Outframe einfach leer, in der falschen Annahme, was nicht aufgeschrieben ist, müsse man auch nicht liefern. Vor Gericht oder im Lenkungsausschuss gewinnt jedoch bei Grauzonen meist der zahlende Kunde.
∝ Die Das ist doch logisch-Annahme. Ingenieure verzichten darauf, Selbstverständlichkeiten (wie etwa eine standardisierte Stromversorgung) auf Inframe-Karten zu schreiben. Wenn das Budget später gekürzt wird, fehlt genau für diese undokumentierten Basiskomponenten das Geld.
∝ Ignorieren der Schnittstellen. Das Team definiert zwar Inframe und Outframe sauber, vergisst aber festzulegen, wie die Daten physikalisch von draußen nach drinnen kommen. Ohne spezifizierte Interfaces auf der Rahmenlinie ist das System beim Integrationstest tot

Stärken und Grenzen

⚖️

Jede Methode hat ihren optimalen Einsatzbereich

Die Anwendung bietet enorme strategische Vorteile, stößt bei unvollständiger Ausführung jedoch an klare Grenzen.

Wann bringt die Methode besonderen Nutzen?

+ Verhindert toxisches Scope Creep extrem frühzeitig, indem es eine visuelle, kaum zu überwindende Barriere für Zusatzanforderungen ohne Zusatzbudget aufbaut.
+ Schafft extreme inhaltliche Klarheit in interdisziplinären Teams, da Fachbegriffe in harte, binäre Entscheidungen übersetzt werden müssen.
+ Sichert die psychologische Gesundheit des Kernteams, da der Arbeitsumfang messbar, realistisch und durch das Management abgegrenzt wird.
+ Dient als unerschütterliche Grundlage für kommerzielle Verträge und schützt Dienstleister vor ruinösen Nachforderungen von Kunden

Was sind die Grenzen der Methode?

∼ Die Methode ist starr. In extrem agilen Forschungsprojekten mit enorm hoher technologischer Unsicherheit lässt sich am Tag 1 schlichtweg noch kein harter Inframe für Tag 100 definieren.
∼ Setzt ein klares, gemeinsames Zielbild aller Beteiligten voraus. Wenn die Geschäftsführung selbst nicht weiß, was sie verkaufen will, scheitert der Workshop an grundlegenden Definitionskämpfen.
∼ Verliert ihre gesamte Wirkungskraft, wenn der Projektleiter nicht die organisatorische Rückendeckung (Empowerment) besitzt, um Stakeholdern tatsächlich ein hartes Nein entgegenzusetzen

Erfolgsmetriken (KPIs)

📐

Scope Creep Ratio

Messung der prozentualen Zunahme von neuen Inframe-Anforderungen nach dem offiziellen Baseline-Freeze. Ein Wert nahe Null spricht für eine perfekte initiale Inframe-Outframe-Sitzung.

Interface Resolution Time

Die gemessene Zeitspanne in Tagen, die das Team benötigt, um alle identifizierten Grenzgänger (Karten auf der Rahmenlinie) vertraglich und technisch mit externen Parteien final zu klären.

IV. Praxis und Mehrwert

⚙️ Praxisrelevanz in unserem professionellen Ingenieursumfeld

Wir wenden diese Methode fast täglich an, um komplexe Herausforderungen zu strukturieren und messbare Resultate für unsere Kunden zu erzielen. Die folgenden drei Praxisfälle veranschaulichen, wie sich dieser Ansatz erfolgreich realisieren lässt:

Qualitätsmanagement

Im strategischen Qualitätsmanagement wird die Methode zwingend bei der Festlegung des sogenannten Geltungsbereichs (Scope of the QMS) nach ISO 9001 eingesetzt. Auditoren fordern eine messerscharfe Trennung, welche Standorte, Dienstleistungen und ausgegliederten Prozesse im Audit-Rahmen liegen und welche bewusst outframe sind.

Systems Engineering

Im Systems Engineering bildet die Methode den exakten Startpunkt der Systemarchitektur (System Boundary Definition). Bevor auch nur eine einzige Zeile Code geschrieben wird, klärt das SE-Team, welche Hardware-Komponenten zur Eigenentwicklung gehören (Inframe) und was als COTS-Produkt (Commercial Off-The-Shelf) lediglich über eine API angebunden wird (Outframe).

Risikomanagement

Im Risikomanagement dient die Schnittstellen-Betrachtung der Rahmenlinie als primärer Identifikator für Lieferanten- und Projektrisiken. Jedes Outframe-Element, das für die Inframe-Funktion zwingend notwendig ist, wird sofort als kritisches Risiko eingestuft, dessen Eintreffwahrscheinlichkeit durch vertragliche SLAs minimiert werden muss.

🏢 Fallbeispiele aus der Praxis

Theorie wird erst durch messbaren Nutzen im Feld zur Validität: Die folgenden anonymisierten Praxisfälle aus unserer QM- und Systems-Engineering-Beratung dokumentieren den konkreten Methodeneinsatz, die durchgeführten Ursachenanalysen und die quantifizierbaren Projekterfolge unter realen Industriebedingungen.

Fallbeispiel 1: Automotive - Elektromobilität Software-Architektur

Problem: Bei der Entwicklung einer neuen Batteriemanagement-Software (BMS) wurden die Anforderungen wöchentlich größer, da das Team ungeplant auch Lade-Algorithmen schreiben sollte.
Methodeneinsatz: Der Chef-Architekt berief einen Inframe-Outframe-Workshop ein.
Ergebnis: Zell-Balancing und Temperaturüberwachung wurden fest als Inframe definiert. Die Lade-Algorithmen wurden hart in den Outframe verschoben und als reine Schnittstelle definiert, die vom Zulieferer der Ladesäulen kommen muss. Das Projekt hielt das Budget.

Fallbeispiel 2: Anlagenbau - Lieferung einer Verpackungslinie

Problem: Ein Maschinenbauer stritt mit dem Endkunden über die Zuständigkeit für das Fundament und die Druckluftversorgung der neuen Anlage.
Methodeneinsatz: Im Kick-off-Meeting wurde ein physischer Rahmen gezeichnet.
Ergebnis: Die Förderbänder und die Robotersteuerung landeten im Inframe. Betonfundament und Hallen-Druckluft wanderten in den Outframe und wurden vertraglich als bauseitige Voraussetzung des Kunden definiert. Der Maschinenbauer sparte sich massive, ungeplante Baukosten.

Fallbeispiel 3: Medizintechnik - App-Entwicklung für Diagnostik

Problem: Das Marketing-Team forderte unentwegt neue Cloud-Anbindungen für eine sterile Diagnostik-App, was die FDA-Zulassung massiv gefährdete.
Methodeneinsatz: Das Regulatory-Affairs-Team moderierte eine harte IOF-Runde.
Ergebnis: Alle Cloud- und Social-Sharing-Features wurden radikal in den Outframe verbannt. Der Inframe beschränkte sich ausschließlich auf die sterile Offline-Diagnostik. Die FDA-Zulassung wurde durch diesen radikal reduzierten Projektumfang sechs Monate früher erreicht.

💬 Expertenzitate

Einschlägige Fachzitate zur wissenschaftlichen und normativen Einordnung der Methode.

♦ Project Management Institute (2021): 'Das Versäumnis, den Projektumfang präzise abzugrenzen und das Ungeplante auszuschließen, ist die häufigste Einzelursache für das Scheitern komplexer Projekte.'

♦ William Edwards Deming (1982): 'Ohne definierte Grenzen gibt es kein System. Ohne System gibt es keine Prozesskontrolle.'

V. Verzeichnisse & Anhang

📇 Glossar

IOF = Inframe-Outframe | PMI = Project Management Institute | INCOSE = International Council on Systems Engineering | COTS = Commercial Off-The-Shelf | SLA = Service Level Agreement | MVP = Minimum Viable Product | BMS = Batteriemanagementsystem

📰 Blogbeiträge zu Inframe-Outframe

Vertiefe dein Wissen: Hier findest du aktuelle Fachartikel, fundierte Hintergrundberichte und weiterführende Analysen aus unserem Redaktionsnetzwerk, die sich praxisnah mit der Anwendung und den Feinheiten dieser Methode auseinandersetzen.

🎬 Videobeitrag zu Inframe-Outframe

Wenn komplexe Vorhaben finanziell aus dem Ruder laufen, liegt es selten an der fehlenden Kompetenz der Ingenieure, sondern an unklaren Grenzen. Das Projekt leidet unter schleichendem Wachstum, dem sogenannten Scope Creep. Die Inframe-Outframe-Methode zieht hier sofort eine radikale, visuelle Notbremse. Das interdisziplinäre Team versammelt sich vor einem Whiteboard, auf dem ein großer Rahmen gezeichnet ist. Jede Anforderung, jedes Bauteil und jede Dienstleistung wird diskutiert und einer extrem harten Binärlogik unterworfen. Ist es zwingend Teil unseres Budgets, wandert es in den Rahmen, den Inframe. Gehört es nicht zu unserem direkten Auftrag, wird es nach außen, in den Outframe verbannt. Diese Methode schützt das Kernteam vor nachträglichen Kundenwünschen, weil das aktive, dokumentierte Nein hier genauso wichtig ist wie das Ja. Besondere Aufmerksamkeit erhalten die Elemente genau auf der Rahmenlinie. Sie definieren die kritischen Schnittstellen, bei denen das Projekt auf externe Lieferungen angewiesen ist. Am Ende entsteht ein auditfähiges, rechtssicheres Scope Statement, das das Budget verteidigt und dem Team absolute psychologische und technische Klarheit verschafft.

🎙️ Audiotranskript zu Inframe-Outframe

Willkommen zur kompakten Methoden-Übersicht. Ihr Projekt leidet unter endlosen Feature-Wünschen und das Budget implodiert? Dann brauchen Sie die Inframe-Outframe-Methode. Sie ist das radikalste Werkzeug zur Systemabgrenzung. Vergessen Sie schwammige Lastenhefte. Sie zeichnen einen dicken Rahmen an die Wand. Alles innerhalb des Rahmens wird gebaut und bekommt Budget. Alles außerhalb des Rahmens wird vom Team vertraglich und technisch zu einhundert Prozent ignoriert. Diese binäre Logik zwingt Manager und Kunden, frühzeitig Farbe zu bekennen. Der wichtigste Akt der Methode ist das bewusste Dokumentieren des Outframes, also der Dinge, die Sie explizit nicht liefern werden. Das schützt Sie vor ruinösen Nachforderungen. Kritische Übergabepunkte landen direkt auf der Grenzlinie und fließen in Ihr Risikomanagement ein. Inframe-Outframe verhindert das schleichende Projektwachstum und liefert Ihnen ein wasserdichtes Fundament für Verträge und Systemarchitekturen.