IT-Projektgutachten & Projektrekonstruktion

Technische Rekonstruktion und Bewertung von IT-Projekten

Bei strittigen, verzögerten oder schwer nachvollziehbaren IT-Projekten ist zunächst festzustellen, welcher technische und dokumentierte Projektstand zu welchem Zeitpunkt tatsächlich vorlag. Ein IT-Projektgutachten kann Anforderungen, Tickets, Spezifikationen, Repository- und Versionshistorien, Builds, Releases, Testnachweise, technische Entscheidungen, Kommunikations- und Änderungsstände sowie erkennbare Abhängigkeiten zusammenführen. Ziel ist keine nachträgliche Projektsteuerung, sondern eine nachvollziehbare technische Rekonstruktion von Befunden, Abweichungen, Risiken, Alternativerklärungen und Aussagegrenzen.

Typische Fragestellungen

Welcher technische Projektstand lag zu einem bestimmten Zeitpunkt tatsächlich vor?
Welche Anforderungen, Änderungen und Akzeptanzkriterien waren dokumentiert und welche davon technisch umgesetzt?
Welche Repository-, Commit-, Branch-, Build-, Release- oder Deploymentstände lassen sich belastbar zuordnen?
Welche Architektur- oder Technologieentscheidungen sind dokumentiert und welche technischen Folgen sind erkennbar?
Wo bestehen Widersprüche zwischen Tickets, Spezifikationen, Kommunikation, Quellcode, Tests und ausgeliefertem Systemstand?
Welche technischen Risiken, Abhängigkeiten, offenen Punkte oder technischen Schulden sind im Prüfzeitraum belegbar?
Welche Alternativerklärungen kommen für Verzögerungen, Ausfälle oder Qualitätsprobleme in Betracht?
Welche Aussagen lassen sich aus der vorhandenen Evidenz gerade nicht belastbar ableiten?

Methodischer Ansatz

Die Untersuchung trennt Fragestellung, Untersuchungszeitraum, Soll-Grundlagen, technische Artefakte, Befund, Interpretation und fachliche Bewertung. Zeitstempel, Tickets, Dokumente, Repositories, Commits, Tags, Builds, Test- und Deploymentnachweise werden soweit erforderlich zu einer prüfbaren Chronologie zusammengeführt. Abweichungen werden nicht allein zeitlich korreliert, sondern gegen plausible Gegenhypothesen und alternative Ursachen geprüft. Aussagen werden auf den belegten System- und Projektstand begrenzt.

Der Schwerpunkt liegt auf Nachvollziehbarkeit: Planung, Implementierung, Test- und Abnahmephasen werden systematisch geprüft, um technische Abweichungen, Risiken sowie dokumentierte Rollen und Zuständigkeiten nachvollziehbar einzuordnen.

Prüflogik für die Projektrekonstruktion

Der iterative Problemlösungszyklus nach Nicolai Andler – Diagnose, Zielformulierung, Analyse und Entscheidungsfindung – bildet den übergeordneten Rahmen. Im Projektgutachten wird er auf historische und technische Evidenz übertragen. Neue Nachweise können dazu führen, dass Zeitraum, Soll-Grundlage, Hypothesen oder bereits gebildete Einordnungen erneut geprüft werden müssen.

1 Diagnose & Scope Projektfrage, Zeitraum, Beteiligungs- und Systemgrenzen sowie verfügbare Quellen bestimmen.

2 Soll & Kriterien Anforderungen, Akzeptanzkriterien, Definition of Done und maßgebliche Vergleichsstände rekonstruieren.

3 Rekonstruktion Tickets, Kommunikation, Git, Builds, Releases, Tests und Deployments zeitlich verbinden und Gegenhypothesen prüfen.

4 Synthese Befunde, Abweichungen, technische Risiken, Unsicherheiten und nicht belegbare Schlussfolgerungen ausweisen.

Chronologische Nähe ist noch keine technische Kausalität; Ursachen werden nur soweit eingeordnet, wie unabhängige Nachweise die Zuordnung tragen.

Mehrere Zeitachsen getrennt halten

Projektquellen besitzen unterschiedliche Zeitbezüge. Ticket-Zeit, Commit-Zeit, Build-Zeit, Release-Zeit, Deployment-Zeit und der tatsächlich beobachtete Laufzeitzustand können voneinander abweichen. Eine belastbare Rekonstruktion dokumentiert diese Ebenen getrennt und verbindet sie nur dort, wo die Zuordnung technisch oder dokumentarisch belegt ist. Fehlende Zwischenstände oder widersprüchliche Zeitstempel werden als Unsicherheit ausgewiesen.

Weiterführendes Wissen: Der Beitrag IT-Projektverlauf rekonstruieren: Tickets, Git-Historie, E-Mails und Protokolle erläutert, wie unterschiedliche technische und organisatorische Quellen zu einer nachvollziehbaren Projektchronologie zusammengeführt werden können.

Bewertungsschwerpunkte

Anforderungen, Spezifikationen, Akzeptanzkriterien und technischer Soll-Ist-Vergleich
Projektchronologie aus Tickets, Protokollen, Kommunikation und technischen Artefakten
Repository-, Commit-, Branch-, Tag-, Build-, Release- und Deploymenthistorien
Architektur, Schnittstellen, Datenflüsse und technische Integrationsentscheidungen
Test-, Qualitäts- und Abnahmenachweise sowie deren technische Aussagekraft
Change Requests, Scope-Änderungen und deren technische Auswirkungen
Abhängigkeiten, technische Schulden, Wartbarkeit und erkennbare Betriebsrisiken
Projektübergaben, Anbieterwechsel und technische Übernahmefähigkeit

Erweiterte technische Prüfmodule

Lieferstand: Ist nur Quellcode vorhanden oder auch ein reproduzierbarer Build-, Test- und Deploymentstand?
Entscheidungshistorie: Welche technischen Entscheidungen, Annahmen und verworfenen Alternativen sind dokumentiert?
Projektübergabe: Sind Repositories, Buildprozesse, Konfiguration, Dokumentation und Abhängigkeiten technisch übergabefähig?
Projektkrise: Welche technischen Faktoren erklären fehlgeschlagene Releases, Integrationsprobleme oder wiederkehrende Störungen?
Provenienz: Welche Herkunfts- und Entwicklungsspuren lassen sich für Softwareartefakte technisch nachvollziehen?
Definition of Done: Welche dokumentierten Kriterien bestanden und welche Nachweise belegen deren Erfüllung oder Nichterfüllung?

Ein technischer Befund beantwortet nicht automatisch rechtliche Fragen zu Vertragsauslegung, Pflichtverletzung, Verschulden oder Schadenshöhe. Solche Entscheidungen bleiben den dafür zuständigen Personen und Stellen vorbehalten.

Einsatzbereiche

Typische Einsatzfelder sind technische Projektstreitigkeiten, Projektabbrüche, Übergaben und Anbieterwechsel, die Rekonstruktion historischer Lieferstände, die technische Einordnung von Änderungsanforderungen sowie die Vorbereitung von Audits oder fachlich geprägten Entscheidungsprozessen. Der Untersuchungsumfang wird dabei auf technisch prüfbare Fragen begrenzt und ausdrücklich von rechtlicher, steuerlicher oder betriebswirtschaftlicher Beratung getrennt.

Fallstudie: Methodischer Ablauf eines IT-Projektgutachtens

Analyse, Bewertung und Nachvollziehbarkeit komplexer IT-Projekte in Anlehnung an Nicolai Andlers Problemlösungsphasen

Konstruiertes Prüfszenario: Diese Darstellung beschreibt kein reales Mandat und keine tatsächliche gerichtliche Beauftragung; sie enthält keine realen Ergebnisse.

1. Diagnose – Projektlage und Ursachenanalyse

Ausgangspunkt ist die Untersuchung der Projektlage: Zeitpläne, Pflichtenhefte, Änderungsprotokolle, Kommunikationsverläufe und technische Umsetzungsstände werden analysiert. Ziel ist es, Verzögerungen, Fehlentwicklungen oder Missverständnisse im Projektverlauf nachzuvollziehen und die zugrunde liegenden Ursachen transparent zu machen. Dabei wird klar zwischen technischen, organisatorischen und kommunikativen Faktoren unterschieden.

2. Zielformulierung – Bewertungsrahmen und Prüfkriterien festlegen

Nach der Diagnosephase werden die konkreten Untersuchungsziele festgelegt: Soll geprüft werden, ob dokumentierte technische Anforderungen und Leistungsmerkmale umgesetzt wurden? Ob die Projektorganisation angemessen war? Oder ob technische Entscheidungen nachvollziehbar begründet wurden? Diese Zieldefinition ist entscheidend, um die Bewertung sachlich, nachvollziehbar und für eine mögliche fachliche Prüfung durch Dritte strukturiert aufzubauen.

3. Analyse – Technische und organisatorische Bewertung

In dieser Phase werden Projektdokumente, Code-Stände und Kommunikationsprotokolle ausgewertet. Es erfolgt eine Bewertung der Architekturentscheidungen, Testabdeckung, Änderungsprozesse und Entscheidungsstrukturen. Ergänzend werden organisatorische Aspekte – etwa Rollenverteilung, Eskalationswege und Kommunikationskultur – auf ihre Wirksamkeit und Angemessenheit geprüft. Ziel ist eine interdisziplinäre, evidenzbasierte Analyse der Projektrealität.

4. Sachverständige Synthese – Befunde und Handlungsempfehlungen

Die gesammelten Befunde werden in einem strukturierten Gutachtenbericht zusammengeführt. Er enthält:

eine sachlich begründete Bewertung der Projektleistung,
die Identifikation wesentlicher Abweichungen zwischen Soll und Ist,
eine Ursachenanalyse technischer und organisatorischer Mängel,
und konkrete Empfehlungen zur Behebung oder Prävention zukünftiger Risiken.

Das Ergebnis bildet eine neutrale technische Entscheidungs- und Beurteilungsgrundlage für Auftraggeber, Projektverantwortliche und – bei entsprechender Beauftragung – auch für gerichtliche Fragestellungen.

Methodische Anregung:
Nicolai Andler: Tools für Projektmanagement, Workshops und Consulting – Kompendium der wichtigsten Techniken und Methoden, 6. überarbeitete und erweiterte Auflage, Publicis, Erlangen, 2015, ISBN 978-3-89578-453-8. Die sachverständige Synthese und die Beispiele sind eigene fachliche Adaptionen. Quellen und Methodik.

Beispiel für ein Gutachtenangebot

Ein typisches Angebot für ein IT-Projektgutachten kann folgende Leistungen enthalten:

Analyse der Projektdokumentation (Pflichtenhefte, Änderungs- und Kommunikationsprotokolle)
Technische Bewertung der Umsetzung und Softwarearchitektur
Technische Analyse der Projektorganisation sowie dokumentierter Rollen und Zuständigkeiten
Bericht mit Befunden, Bewertung und Handlungsempfehlungen

Der Leistungsumfang richtet sich nach Projektgröße, Komplexität und Dokumentationsstand. Nach Sichtung der Unterlagen erhalten Sie ein individuelles, unverbindliches Angebot.

Orientierung nach Untersuchungstiefe:

Klar abgegrenzte technische Prüfung oder Stellungnahme: ca. 1.500 € bis 4.500 € netto
Umfangreichere technische Begutachtung: ca. 4.500 € bis 10.000 € netto
Komplexes IT-Gutachten mit umfangreicher technischer Untersuchung: ca. 10.000 € bis 20.000 € netto oder darüber

Maßgeblich sind insbesondere die konkrete Fragestellung, Projekt- und Systemgröße, Anzahl und Zustand der zu untersuchenden Artefakte, Qualität der verfügbaren Unterlagen sowie die erforderliche Untersuchungstiefe und Berichtsdokumentation.

Nach einer ersten Sichtung der Fragestellung und der verfügbaren Unterlagen kann ein individuelles und unverbindliches Angebot erstellt werden. Je nach Untersuchungsgegenstand kann insbesondere ein Festpreis oder eine andere geeignete Vergütungsstruktur vereinbart werden.

Hinweis: Die genannten Größenordnungen dienen ausschließlich der ersten Orientierung und stellen kein verbindliches Angebot dar. Der konkrete Aufwand kann im Einzelfall auch außerhalb dieser Bereiche liegen.

Kontakt zum IT-Sachverständigen Mathias Ellmann

Benötigen Sie ein unabhängiges IT-Projektgutachten zur objektiven Bewertung technischer und organisatorischer Zusammenhänge in Ihrem Projekt?

Kontakt aufnehmen

Häufige Fragen zu IT-Projektgutachten

Was ist ein IT-Projektgutachten?

Ein IT-Projektgutachten analysiert den Verlauf, die Organisation und die technische Umsetzung eines IT-Projekts, um Ursachen für Verzögerungen, Mängel oder Konflikte objektiv zu identifizieren.

Wann ist ein IT-Projektgutachten erforderlich?

Bei Projektabbrüchen, Streitigkeiten oder Qualitätsproblemen ermöglicht das Gutachten eine fachlich fundierte Bewertung der technischen und organisatorischen Zusammenhänge.

Welche Unterlagen werden benötigt?

Benötigt werden Projektpläne, Pflichten- und Lastenhefte, Code-Stände, Kommunikations- und Änderungsprotokolle, um den Projektverlauf vollständig nachvollziehen zu können.

Wofür kann das Gutachten eingesetzt werden?

Das Gutachten dokumentiert technische Befunde und kann der fachlichen Klärung sowie der Vorbereitung außergerichtlicher oder gerichtlicher Fragestellungen dienen. Ob und in welcher Form es in einem konkreten Verfahren berücksichtigt werden kann, ist eine rechtliche Frage und wird hier nicht bewertet.

IT-Projektgutachten & technische Projektrekonstruktion