loumiTECH
DE / EN Kontakt
Project Systems Research

Zwischen Entscheidung
und Wirkung

Forschungsfrage

Projekte verlieren Zeit selten an der Umsetzung.

Zwischen Fachbereich und Technik, Vertrag und Scope, Reporting und Entscheidung, Build und Betrieb – dort entstehen Wartezeiten, Doppelarbeit und Entscheidungen, die zwar getroffen, aber nicht wirksam sind.

loumiTECH untersucht, wie Steuerung, Koordination und Zeitverwendung in komplexen Programmen zusammenhängen — und welche Strukturen Zeit tatsächlich zurückgewinnen. Jeder Beitrag macht kenntlich, was durch Quellen gestützt ist und was eigene Synthese bleibt.

EVIDENZ MODELL BEOBACHTUNG ÜBERARBEITUNG
Forschungsfelder

Drei Felder, eine Frage: Wohin geht die Zeit?

01 / Projektsteuerung & Governance

Wie Entscheidungen, Gremien und Verantwortlichkeiten die Geschwindigkeit eines Programms bestimmen.

Untersucht werden Entscheidungslatenz, Koordinationsaufwand an Schnittstellen und die Frage, warum dokumentierte Beschlüsse die Arbeit oft erst Wochen später erreichen. Grundlage sind veröffentlichte Governance-Studien und anonymisierte Programmbeobachtungen.

Decision Latency · Coordination Surface · Steering Quadrant · Rollenklarheit · Eskalationslogik

Decision Latency lesen
02 / Zeitmanagement in Programmen

Wo in komplexen Programmen Zeit verloren geht — und welche Strukturen sie zurückgewinnen.

Dieses Feld untersucht Zeit als Steuerungsgröße in Programmen. Gemeint sind Wartezeiten zwischen Gremienterminen, der Takt von Reporting und Entscheidung sowie die Reaktionszeit auf Abweichungen. Um den Kalender einzelner Personen geht es dabei nicht. Erste Studien beginnen im November 2026.

Wartezeiten · Gremientaktung · Reconfiguration Latency · Reaktionszeit · Zeitbudgets für Eskalationen

Im Aufbau
03 / Projektsysteme & Reporting

Warum Tools, Prozesse und Berichte mit der Zeit von der realen Arbeit abweichen — und was Reporting entscheidungsfähig macht.

Configuration Drift in Jira und Confluence, Reporting, das beschreibt statt zu führen, und Betriebsfähigkeit, die erst am Go-live betrachtet wird: Dieses Feld untersucht Projektsysteme als Steuerungsinstrumente.

Configuration Drift · Decision-Driven Reporting · Build-to-Run · Datenqualität · Maßnahmenmanagement

Configuration Drift lesen
Methodik

Vier Inhaltstypen, jeder mit offengelegter Erkenntnisgrundlage.

Evidenz-ReviewEin Evidenz-Review wertet veröffentlichte Studien und Fachliteratur zu einer klar abgegrenzten Frage strukturiert aus. Eigene Daten werden nicht erhoben. Jede Aussage ist einer Quelle zugeordnet.

StudienüberblickEin Studienüberblick fasst ausgewählte veröffentlichte Untersuchungen zusammen, ohne dass eine systematische Suche zugrunde liegt. Eigene Daten werden nicht erhoben. Jede Zahl ist einer Quelle zugeordnet.

ArbeitsmodellEin Arbeitsmodell beschreibt einen eigenen Begriff oder ein eigenes Steuerungsmodell, das aus Forschung und Praxis hergeleitet ist. Es ist ausdrücklich als nicht validiert gekennzeichnet und nennt seine Grenzen und offenen Fragen.

BeobachtungEine Beobachtung beschreibt ein anonymisiertes Muster aus der Projektpraxis und ordnet es in die Literatur ein. Sie ist keine Studienaussage. Sie dient als Ausgangspunkt für Hypothesen, die anschließend geprüft werden.

Transparenz. Jeder Beitrag unterscheidet zwischen Aussagen, die durch Quellen gestützt sind, und eigener Synthese. Quellen sind verlinkt, der Einsatz generativer KI ist offengelegt, und Version und Prüfdatum stehen am Ende jedes Beitrags.

Umfang der Forschungsarbeit

7

veröffentlichte Beiträge in Deutsch und Englisch

21

ausgewertete Quellen — Studien, Standards und Fachliteratur

3

Arbeitsmodelle, jeweils mit offenem Validierungsstatus

3

Forschungsfelder — Steuerung, Zeitmanagement, Projektsysteme

Beiträge

Alle Beiträge, chronologisch.

Studienüberblick

Warum große IT-Programme scheitern

BCG, McKinsey/Oxford und Standish finden übereinstimmend hohe Planabweichungen. Wo nach Ursachen gefragt wird, stehen Steuerung und Koordination im Vordergrund und nur selten die Technik.

Lesen
Arbeitsmodell8 Min.

Coordination Surface

Koordinationsaufwand wächst mit der Zahl und Heterogenität der Schnittstellen — nicht mit der Zahl der Arbeitspakete.

Lesen
Arbeitsmodell8 Min.

Decision Latency

Zwischen einem Beschluss und der veränderten Arbeit vergeht messbare Zeit. In Programmen wird diese Zeit selten gesteuert.

Lesen
Arbeitsmodell8 Min.

Configuration Drift

Tools werden einmal konfiguriert, Arbeitsweisen entwickeln sich wöchentlich weiter — ohne Governance driften beide auseinander.

Lesen
Arbeitsmodell9 Min.

Build-to-Run

Betriebsfähigkeit entsteht über die gesamte Delivery, nicht am Go-live — und entscheidet über den realisierten Wert einer Transformation.

Lesen
Beobachtung8 Min.

Decision-Driven Reporting

Reporting wird erst dann wertvoll, wenn es Entscheidungen verändert — nicht, wenn es Vergangenheit beschreibt.

Lesen
Beobachtung7 Min.

Programme verlieren Zeit an Übergängen

Wer Anforderungen, Verträge, Tickets und Forecasts getrennt steuert, verliert Geschwindigkeit, lange bevor das erste Release entsteht.

Lesen
Studienüberblick Überblick über veröffentlichte Studien Arbeitsmodell eigenes Modell, nicht validiert Beobachtung strukturierte Praxisbeobachtung
Modelle

Drei Arbeitsmodelle, offen zur Prüfung.

01Arbeitsmodell · nicht validiert

Modular Project Management Blueprint

Statt eine Universalmethode als Gesamtpaket zu übernehmen: Welche Steuerungsbausteine braucht dieses Projekt, in welcher Ausprägung — und welche lässt es bewusst weg?

  • Governance
  • Reporting
  • Entscheidung
  • Koordination
  • Delivery

Auswahl nach: Projektarchitektur · Veränderungstyp · Abhängigkeiten · Betriebsnähe

02Arbeitsmodell · nicht validiert

Steering Quadrant

Vier Perspektiven, die meist getrennt geführt werden, in einer wöchentlichen Steuerungslogik zusammengeführt — ein Owner pro offenem Punkt, eine explizite Eskalationsstufe.

  • Fachklarheit
  • Operative Transparenz
  • Kommerzielle Steuerung
  • Technische Wirkungsanalyse

Kommerzielle und vertragliche Themen werden als potenzielle Lieferblocker geführt, nicht als separate Workstreams.

Herleitung in „Programme verlieren Zeit an Übergängen“
03Arbeitsmodell · nicht validiert

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

Reporting, das Entscheidungen verändert, baut auf vier Ebenen in fester Reihenfolge auf — ohne belastbare Datengrundlage erzeugt jede weitere Ebene Scheingenauigkeit.

  • Datengrundlage
  • Kennzahlenlogik
  • Automatisierung
  • Maßnahmenverknüpfung

Jede Auffälligkeit ist mit Owner, nächstem Schritt und Termin verbunden.

Herleitung in „Decision-Driven Reporting“

Alle drei Modelle sind eigene Synthesen, inspiriert u. a. von ISO 21502 und PMBOK 7 (Tailoring) — keine empirisch validierten Standardmodelle.

Research-Dialog

Hinweise, Gegenbeispiele oder Daten aus Ihrer Praxis?

Die Arbeitsmodelle werden fortlaufend überprüft. Rückmeldungen zu einzelnen Beiträgen, anonymisierte Fallbeispiele, Hinweise auf weitere Quellen sowie Kooperations- und Presseanfragen sind willkommen.

hello@loumi.tech

Die Nachricht geht direkt an loumiTECH. Eine Rückmeldung erfolgt in der Regel innerhalb weniger Werktage. Hinweise zur Verarbeitung der Daten: Datenschutzerklärung. Alternativ direkt per E-Mail an hello@loumi.tech.