IT-Projekte & technische Due Diligence
IT-Projekte dokumentieren Entscheidungen verteilt: im Backlog, in Chat- oder Meetingprotokollen, Pull Requests, Architekturentscheidungen, Freigaben und Quellcode. Eine sachverständige Rekonstruktion bewertet nicht, welche Darstellung „am glaubwürdigsten klingt“, sondern ordnet die verfügbaren technischen und dokumentarischen Spuren zeitlich und inhaltlich.
Kurzantwort
Aus heterogenen Projektquellen wird eine nachvollziehbare Chronologie aufgebaut. Behauptete Entscheidungen werden mit zeitnahen Artefakten, Änderungen im Repository und resultierenden Systemständen abgeglichen. Widersprüche und Dokumentationslücken bleiben als eigene Befunde sichtbar.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Projektquellen nach Evidenzart unterscheiden
Tickets, E-Mails, Meetingnotizen, Chatverläufe, Wiki-Seiten und Repository-Daten erfüllen unterschiedliche Zwecke und besitzen unterschiedliche Metadaten. Eine technische Rekonstruktion behandelt sie deshalb nicht als austauschbare Belege.
Zeitnahe technische Artefakte wie Commits oder Pipeline-Läufe können Änderungen präzise datieren, erklären aber nicht immer ihren fachlichen Grund. Umgekehrt kann ein Protokoll einen Entscheidungsgrund enthalten, ohne nachzuweisen, dass die Entscheidung anschließend umgesetzt wurde.
2. Chronologie mit belastbaren Zeitankern aufbauen
Zunächst werden Ereignisse mit stabilen technischen Ankern erfasst: Commit-Zeitpunkte, Tag-Erstellung, Ticket-Historien, Release-IDs oder signierte Artefakte. Danach werden weniger präzise Quellen in diese Chronologie eingeordnet.
Zeitstempel sind dabei nicht unfehlbar. Importierte Systeme, Zeitzonen, manuell veränderbare Felder oder neu geschriebene Git-Historien können Unsicherheit erzeugen. Ein einzelner Zeitstempel sollte deshalb nicht überinterpretiert werden, wenn andere Evidenz widerspricht.
3. Entscheidungsbehauptung und technische Umsetzung verknüpfen
Eine dokumentierte Entscheidung wird darauf geprüft, ob sie im nachfolgenden Systemstand Spuren hinterlassen hat. Bei einer Datenbankmigration können das Schemaänderungen, Migrationsskripte oder geänderte Deployments sein; bei einer Architekturentscheidung neue Schnittstellen oder Abhängigkeiten.
Fehlt eine solche Korrelation, kann die Entscheidung dennoch stattgefunden haben, ihre Umsetzung ist aber technisch nicht belegt. Diese Unterscheidung ist für spätere Verantwortungs- oder Ursachenfragen wesentlich.
4. Widersprüche nicht durch Erzählung glätten
Projektunterlagen sind häufig widersprüchlich. Ein Ticket kann „erledigt“ melden, während der relevante Commit später zurückgesetzt wurde. Ein Protokoll kann eine Freigabe nennen, obwohl der produktive Release erst Wochen danach entstand.
Die Aufgabe der Rekonstruktion ist nicht, eine harmonische Geschichte zu erzeugen. Abweichende Quellen werden benannt, auf ihre technische Aussagekraft geprüft und soweit möglich durch unabhängige Evidenz gegengeprüft.
5. Dokumentationslücken als Befund einordnen
Nicht vorhandene ADRs, fehlende Protokolle oder gelöschte Tickets sind nicht automatisch Beweis für fehlerhaftes Projektmanagement. Sie begrenzen aber die Nachvollziehbarkeit einer behaupteten Entscheidung.
Der Bericht unterscheidet daher zwischen „nicht dokumentiert“, „nicht auffindbar“, „technisch nicht rekonstruierbar“ und „durch andere Evidenz indirekt gestützt“. Diese Kategorien vermeiden unzulässige Schlussfolgerungen aus bloßem Fehlen.
6. Rekonstruktion auf den Prüfauftrag begrenzen
Eine vollständige Unternehmens- oder Projektgeschichte ist selten erforderlich. Die Chronologie wird auf die technischen Entscheidungen beschränkt, die für die konkrete Fragestellung relevant sind. Dadurch bleiben Aufwand und Aussagekraft kontrollierbar.
Neue Unterlagen können die Chronologie verändern. Deshalb werden verwendete Exportstände und Stichtage dokumentiert; spätere Funde bilden einen nachvollziehbaren Revisionsanlass.
Für die Quellenkritik ist auch relevant, wann eine Dokumentation erstellt wurde. Eine zeitnahe Ticketnotiz besitzt einen anderen Erkenntniswert als eine Monate später verfasste Zusammenfassung. Spätere Dokumente können wertvolle Einordnung liefern, dürfen aber nicht unbemerkt als zeitgleicher Primärnachweis behandelt werden.
Wenn mehrere Systeme dieselbe Entscheidung unterschiedlich abbilden, kann eine Ereignismatrix helfen: Zeitpunkt, Quelle, behauptetes Ereignis, technische Folge und Grad der Bestätigung werden getrennt geführt. Dadurch wird sichtbar, welche Teile der Chronologie gesichert, plausibel oder offen sind.
Besonders bei parallelen Teams kann derselbe Sachverhalt in mehreren Ticket- oder Repository-Systemen erscheinen. Doppelte oder gespiegelt importierte Einträge werden deshalb nicht als unabhängige Bestätigung gezählt. Eine belastbare Korrelation berücksichtigt Quelle, technische Abhängigkeit und mögliche gemeinsame Herkunft der Informationen.
Was bedeutet es, wenn eine Entscheidung nicht dokumentiert ist?
Zunächst nur, dass in der untersuchten Grundlage kein hinreichender direkter Nachweis gefunden wurde.
Eine Umsetzung kann über technische Spuren trotzdem rekonstruierbar sein, beispielsweise durch Commits, Konfigurationsänderungen oder Deployments.
Aus dem Fehlen eines Dokuments allein sollte keine weitergehende Verantwortungs- oder Rechtsaussage abgeleitet werden.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Sind die verwendeten Projektquellen mit Exportstand oder Stichtag dokumentiert?
- Sind technische und kommunikative Quellen hinsichtlich ihrer Aussagekraft getrennt?
- Sind wichtige Ereignisse auf mehrere unabhängige Zeitanker geprüft?
- Lassen sich behauptete Entscheidungen mit nachfolgenden technischen Änderungen korrelieren?
- Werden widersprüchliche Quellen ausdrücklich dargestellt?
- Sind Dokumentationslücken als Unsicherheit und nicht als Beweis formuliert?
- Ist die Chronologie auf die konkrete technische Fragestellung begrenzt?
Konstruiertes Beispiel
In einem Meetingprotokoll wird beschlossen, eine externe API nicht mehr zu verwenden. Zwei Wochen später zeigen Commits eine neue interne Schnittstelle, im Produktivsystem bleiben jedoch Aufrufe an die alte API sichtbar. Die Rekonstruktion trennt Entscheidung, Implementierungsänderung und tatsächlichen Betriebszustand.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Technische Primärquelle Git-Dokumentation zu git-log für die Untersuchung von Commit-Historien. Quelle öffnen.
- Technische Primärquelle Git-Revisionssyntax zur eindeutigen Referenzierung von Entwicklungsständen. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- IT-Projektverlauf rekonstruieren
- Change Requests und Änderungsstände rekonstruieren
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich IT-Projekte & technische Due Diligence
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
IT-Projektgutachten