Research / Frameworks

Practitioner Frameworks.

Steuerungsmodelle, die aus wiederkehrenden Mustern in komplexen IT-Programmen entstanden sind — gedacht für die direkte Anwendung, nicht für die Theorie.

Kennzeichnung: Eigenes anwendungsorientiertes Modell, entwickelt aus Literaturauswertung, Projekterfahrung und strukturierter Synthese.
Featured Framework

Modular Project Management Blueprint.

Ein modulares Modell zur Auswahl von Governance-, Reporting-, Entscheidungs-, Koordinations- und Delivery-Bausteinen anhand von Projektarchitektur, Veränderungstyp, Abhängigkeiten und Betriebsnähe.

Steuerungsbausteine — je Projekt ausgewählt, nicht als Gesamtpaket Modul antippen › Governance Gremien · Rollen Reporting Status · Trends Entscheidung Decisions · Latenz Koordination Schnittstellen Delivery Milestones · QA Ausgewählt nach vier Dimensionen PROJEKTARCHITEKTUR VERÄNDERUNGSTYP ABHÄNGIGKEITEN BETRIEBSNÄHE

Fünf Bausteinfamilien, vier Auswahldimensionen: Der Blueprint beschreibt, welche Steuerungsbausteine ein konkretes Projekt braucht — und welche es bewusst weglassen sollte.

Die Grundidee des Blueprints ist eine Absage an die Universalmethode. Projekte scheitern selten daran, dass die falsche Methode gewählt wurde — sie scheitern daran, dass eine Methode als Gesamtpaket übernommen wird, obwohl das konkrete Projekt nur einen Teil davon braucht und an anderer Stelle Bausteine fehlen, die keine Standardmethode vorsieht. Der Blueprint ersetzt die Frage „Welches Framework führen wir ein?" durch die Frage „Welche Steuerungsbausteine benötigt dieses Projekt, in welcher Ausprägung, und welche lassen wir bewusst weg?".

Dafür unterscheidet das Modell fünf Bausteinfamilien. Governance umfasst Gremien, Rollen, Entscheidungsrechte und Eskalationswege — die formale Struktur, in der gesteuert wird. Reporting umfasst Status-, Trend- und Ausnahmeberichte, die auf Entscheidungen zielen statt auf Vollständigkeit. Entscheidung umfasst Decision Log, Entscheidungsreife und die Latenz zwischen Beschluss und Wirkung — der Baustein, der bestimmt, ob Governance führt oder nur dokumentiert. Koordination umfasst Schnittstellen, Abhängigkeiten und die Taktung zwischen Workstreams, Lieferanten und Fachbereichen — die Coordination Surface des Projekts. Delivery umfasst Meilensteine, Testing, Releases und Betriebsnähe — der Baustein, an dem sich die Wirkung aller anderen messen lassen muss.

Welche Bausteine ein Projekt in welcher Ausprägung braucht, bestimmen vier Auswahldimensionen. Die Projektarchitektur beschreibt, wie viele Workstreams, Lieferanten und Systeme beteiligt sind und wie sie geschnitten wurden. Der Veränderungstyp unterscheidet, ob ein Projekt Neues aufbaut, Bestehendes ablöst oder Laufendes stabilisiert — jede Variante verlangt andere Steuerungsbausteine. Die Abhängigkeiten erfassen, wie stark Entscheidungen in einem Bereich Wirkungen in anderen erzeugen. Die Betriebsnähe schließlich beschreibt, wie dicht das Projekt am produktiven Betrieb arbeitet — je näher, desto strenger müssen Release-, Test- und Eskalationsbausteine ausgeprägt sein.

In der Anwendung folgt der Blueprint drei Schritten: In der Diagnose werden die vier Dimensionen für das konkrete Projekt eingeschätzt. In der Auswahl wird daraus die Zusammenstellung der Bausteine begründet — einschließlich der bewussten Entscheidung gegen Bausteine, die nur Aufwand erzeugen würden. In der Aktivierung werden die gewählten Bausteine in Gremien, Tools, Reports und Routinen übersetzt. Eine wichtige Grenze gehört dazu: Der Blueprint ist ein Modell aus Praxis-Synthese und Literaturauswertung, kein empirisch validiertes Instrument. Er strukturiert Entscheidungen über Projektsteuerung — er ersetzt nicht die Prüfung im konkreten Kontext.

Framework 02

loumiTECH Steering Quadrant.

Vier Perspektiven — in einer Steuerungslogik konsolidiert KLARHEIT · GRUNDLAGE STEUERUNG · WIRKUNG FACHLICH · OPERATIV KOMMERZIELL · TECHNISCH Fachklarheit FUNCTIONAL CLARITY Anforderungen verständlich, priorisiert, entscheidungsreif. Operative Transparenz OPERATIONAL TRANSPARENCY Fortschritt, Risiken und Abhängigkeiten in einer Sicht. Kommerzielle Steuerung COMMERCIAL STEERING Budget, Forecast und Verträge mit dem Lieferstatus verknüpft. Technische Wirkungsanalyse TECHNICAL IMPACT ANALYSIS Migration, Schnittstellen und Releasefähigkeit je Runde bewertet. Konsolidiert in einer wöchentlichen Steuerungslogik — je offener Punkt ein Owner, eine Eskalationsstufe.

Der Steering Quadrant verbindet vier Perspektiven, die in den meisten Organisationen getrennt geführt werden: Fachklarheit (Anforderungen sind verständlich, priorisiert und entscheidungsreif), Operative Transparenz (Fortschritt, Risiken, Tickets und Abhängigkeiten in einer konsolidierten, entscheidungsorientierten Sicht), Kommerzielle Steuerung (Budget, Forecast, Vertragsstatus und Lieferantenbeiträge direkt mit dem Lieferstatus verknüpft) und Technische Wirkungsanalyse (Migration, Schnittstellen, Datenqualität und Releasefähigkeit in jeder Steuerungsrunde bewertet).

Die vier Perspektiven sind einzeln nicht neu. Der Kern des Modells liegt in der Konsequenz der Zusammenführung: Alle vier werden in einer wöchentlichen Steuerungslogik konsolidiert, jeder offene Punkt erhält genau einen Owner, und für jeden Punkt existiert eine explizite Eskalationsstufe. Damit werden vertragliche und kommerzielle Themen auf derselben Ebene geführt wie technische und fachliche — als potenzielle Lieferblocker, nicht als separate Workstreams.

Das Modell ist im Insight-Artikel zur IT-Programmsteuerung ausführlich hergeleitet und eingeordnet: IT-Programmsteuerung: Warum komplexe Projekte an den Übergängen scheitern.

Framework 03

Vier-Ebenen-Modell für Decision-Driven Reporting.

Vier aufeinander aufbauende Ebenen Maßnahmenverknüpfung ACTIONABLE INSIGHTS Automatisierung AUTOMATION Kennzahlenlogik METRICS & LOGIC Datengrundlage DATA FOUNDATION AUFBAUENDE EBENEN → STEUERUNGSWIRKUNG

Reporting, das Entscheidungen verändert, baut auf vier aufeinander aufbauenden Ebenen auf: Datengrundlage (konsolidierte, bereinigte, eindeutig referenzierbare Quellen — jede Kennzahl ist auf eine definierte Berechnungslogik rückführbar), Kennzahlenlogik (KPIs werden von der Entscheidung her gedacht, nicht von der Datenverfügbarkeit; was keine Steuerungsfrage beantwortet, gehört nicht in den Report), Automatisierung (regelmäßige, strukturierte Aktualisierung ohne manuelle Brüche, mit automatischer Markierung von Trends und Schwellwertüberschreitungen) und Maßnahmenverknüpfung (jede Auffälligkeit ist mit Owner, nächstem Schritt und Termin verbunden).

Die Reihenfolge der Ebenen ist Teil des Modells: Ohne belastbare Datengrundlage erzeugt jede weitere Ebene Scheingenauigkeit; ohne Maßnahmenverknüpfung bleibt auch das beste Dashboard Information statt Steuerung. Erst wenn alle vier Ebenen ineinandergreifen, wird Reporting von einer rückblickenden Tätigkeit zu einem aktiven Steuerungsprozess.

Herleitung, Anwendungsbeispiele und Grenzen des Modells finden sich im zugehörigen Insight-Artikel: Decision-Driven Reporting: Warum Reporting erst dann wertvoll wird, wenn es Entscheidungen verändert.

Literaturbezug

Die drei Frameworks sind eigene Synthesen von loumiTECH, nicht empirisch validierte Standardmodelle. Sie sind jedoch von etablierter Fachliteratur inspiriert — die zentralen Bezugsquellen sind hier je Modell ausgewiesen.

Modular Project Management Blueprint — kontextabhängige Auswahl von Steuerungsbausteinen (Tailoring)

  1. ISO 21502:2020: Project, Programme and Portfolio Management — Guidance on Project Management.
  2. Project Management Institute (2021): PMBOK® Guide. 7. Auflage — Konzepte Tailoring und Progressive Elaboration.
  3. Snowden, D. J.; Boone, M. E. (2007): A Leader's Framework for Decision Making. Harvard Business Review, 85(11) — Cynefin Framework.
  4. Shenhar, A. J.; Dvir, D. (2007): Reinventing Project Management: The Diamond Approach. Harvard Business School Press.
  5. Boehm, B.; Turner, R. (2004): Balancing Agility and Discipline. Addison-Wesley.

Steering Quadrant — Zusammenführung getrennter Perspektiven, Koordination und Abhängigkeiten

  1. Cataldo, M.; Herbsleb, J. D.; Carley, K. M. (2008): Socio-technical Congruence. DOI: 10.1145/1414004.1414008.
  2. MacCormack, A.; Rusnak, J.; Baldwin, C. Y. (2012): Exploring the Duality between Product and Organizational Architectures (Mirroring Hypothesis). Research Policy, 41(8).
  3. Herbsleb, J. D.; Mockus, A. (2003): An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE TSE, 29(6).

Vier-Ebenen-Modell für Decision-Driven Reporting — Entscheidungsarchitektur und Governance

  1. Turner, J. R. (2020): Investigating How Governmentality and Governance Influence Decision Making on Projects. Project Leadership and Society, 1, 100003.
  2. Sirisomboonsuk, P.; Gu, V. C.; Cao, R. Q.; Burns, J. R. (2018): Relationships between Project Governance and IT Governance and Their Impact on Project Performance. IJPM. DOI: 10.1016/j.ijproman.2017.10.003.
  3. Tubre, T. C.; Collins, J. M. (2000): A Meta-Analysis of the Relationships between Role Ambiguity, Role Conflict, and Job Performance. Journal of Management, 26.
Method & Transparency Note Content type: Practitioner Framework

Die hier vorgestellten Frameworks sind von loumiTECH entwickelte Synthesen aus Literaturauswertung, Projekterfahrung und eigener Analyse. Sie sind literaturinspiriert, aber keine wissenschaftlich validierten Standardmodelle. Zugrunde liegende empirische Untersuchungen wurden nicht von loumiTECH durchgeführt.

Generative KI wurde unterstützend für Rechercheplanung, Strukturierung und sprachliche Überarbeitung eingesetzt. KI-Ausgaben wurden nicht als eigenständige Quelle verwendet. Modellbildung, Prüfung der Quellen, Interpretation und finale Fassung wurden durch Shirin Meggendorfer verantwortet.

Version
1.0
Published
16. Juli 2026
Last reviewed
16. Juli 2026
Framework status
Working model / not independently validated
Start with the Context

Welche Bausteine braucht Ihr Programm?

Projekt besprechen Zurück zur Research-Übersicht