SCHEITERN VON IT-PROJEKTEN – TYPISCHE PROJEKTSÜNDEN

  |   Allgemein   |   No comment

Viele IT-Projekte sind schon vor Beginn durch unpassende vertragliche Rahmenbedingungen zum Scheitern verurteilt. So sind bei Projekten, bei denen der Kunde noch eine hohe Unsicherheit hinsichtlich seiner Anforderungen aufweist, Festpreis-Regelungen ein riskantes Unterfangen. Bei Projekten mit hohem technischem Innovationsgrad sind Festpreis-Vereinbarungen gar ein Garaus. Böse Überraschungen gibt’s meistens kurz vor Projektende.

 

Das „korrekte“ Inhaltsverzeichnis einer Leistungsbeschreibung sollte folgende Bereiche abbilden: (Den Systemzweck, zu unterstützende Geschäftsprozesse, Anwendungsfälle, was macht das System also für die „Außenwelt“.) Darüber hinaus ein fachliches Datenmodell, welche Daten und Relationen werden im System verarbeitet? Funktionen, also welche Verarbeitungsschritte werden auf den Daten ausgeführt, z.B. Scouring, Statistik, Verschlüsselung etc. Darüber hinaus Benutzerschnittstellen: Wie interagiert das System mit Menschen? Welche Daten werden dargestellt/eingegeben/geändert? Oftmals fehlt im Inhaltsverzeichnis eine Beschreibung der Systemschnittstellen: Wie interagiert das System mit anderen Systemen? Welche Daten werden ausgetauscht? Darüber hinaus müssen frühzeitig nicht funktionale Aspekte geklärt werden, z.B. ein (eventueller aus datenschutzrechtlichen Gründen unzulässiger) Backup in die Cloud, Sicherheitsmaßnahmen, Antwortzeiten, und Benutzerrechte.

 

Nichts dem Zufall überlassen 

 

Gestaltungsentscheidungen in einem IT-Projekt sollten nicht dem Anbieter überlassen werden. Die Gestaltung der zukünftigen Prozesse darf nicht dem Zufall überlassen werden, insbesondere müssen Grenzen zu den umgebenen Systemen klar beschrieben werden.

 

Als typische Projektsünden, die zum Scheitern von IT-Projekten führen, haben sich herausgestellt:

 

1. unklare Vertragstypologie (Dienstvertrag, Werkvertrag?);
2. eine fehlende Projektstruktur;
3. ein fehlendes unvollständiges Pflichtenheft;
4. die Übernahme der Verantwortung für das Pflichtenheft durch den Auftragnehmer und nicht durch den Auftraggeber;
5. unrichtiges Pflichtenheft/Prüfungspflicht des Auftragnehmers;
6. fehlende Abnahmekriterien;
7. fehlende Mitwirkung der Parteien;
8. ein fehlendes Änderungsmanagement und
9. eine fehlende bzw. unzureichende Dokumentation.

 

Positiv gewandt kann man diese Projektsünden wie folgt beschreiben:

 

Den Vertragstyp klar ansteuern! Das Projekt strukturieren! Eine möglichst vollständige Anforderung/Spezifikation verfassen, die IT-Leistungen prüfbar für Anwälte/Juristen beschreibt. Eine klare Verantwortung der fachlichen Anforderungen und ein klares Änderungsmanagement in den Vertrag aufnehmen, Anforderungen regelmäßig überprüfen; Abnahme- und Testkriterien bestimmen; sauber dokumentieren und klare Schnittstellen formulieren.

 

Ein typisches phasenweises Vorgehen zweiteilt ein Projekt in „Planung“ und „Realisierung“ in der Planungsphase stellt sich ein lineares Phasenschema wie folgt dar: Idee, Gründung des Projekts, Vorstudie, Grobkonzept, Machbarkeitsstudie, Ist-Analyse, Schwachstellen-Analyse, Überprüfung der Machbarkeit, fachliche Grobkonzeption, technische Grobkonzeption und fachliche Feinspezifikationen.

 

Auf diesen Phasen fußt die technische Feinspezifikation und die sich hieran anschließende Realisierungsphase mit Programmierung der Quellcodes, Einzeltests, Integrationstests, Dokumentation, Implementierung im System und Tests auf Testsystemen des Auftraggebers, der zwingend einem Test auf dem Produktivsystem vorgeschaltet ist.

 

Erst nach diesem langen Weg ist eine Abnahme-/Abschlussprüfung möglich.

 

Kostenexplosion 

 

Wer solche typischen Projektsünden umschifft, kann einer Kostenexplosion des Projekts entgehen, das Projekt noch rechtzeitig auffangen und die angepeilten Ziele verwirklichen und nicht kostenintensiv kontinuierlich verringern.

 

Während des Projekts selber wiederum ist von beiden Seiten, also von Seiten des Auftraggebers als auch von Seiten des Auftragnehmers, im Rahmen des Projektmanagements streng darauf zu achten, dass der tatsächliche Vertrag auch „gelebt“ wird und dieser nicht im „doing“ schlicht ignoriert wird. Vor Gericht ist das „ unbemerkte Weggehen“ vom Vertrag im Projektverlauf oft schwierig darlegbar. Ein Gericht lässt sich nur schwerlich davon überzeugen, dass man etwas ganz Anderes gewollt habe, als tatsächlich vereinbart und/oder gelebt worden ist.

 

Zum Schutz beider Vertragspartner kann daher nur empfohlen werden, im Rahmen der Vertragsverhandlungen offen über das Projektvorgehen zu sprechen und einem gemeinsamen Konsens zu erzielen, der im Vertrag und dessen Anlagen festgeschrieben wird.

 

Bezahlung splitten

 

Kostenexplosionen lassen sich auch dadurch vermeiden, dass man die Vergütung des Auftragnehmers „splittet“, etwa wie folgt: Eine Art periodische Vergütung zur Deckung eines bestimmten Minimums an Aufwand für eine bestimmte Zeit vereinbaren; einen weiteren, zusätzlichen Teil-Betrag bzw. weitere zusätzliche Zahlung vereinbaren für die Erreichung jeweiliger Planziele und schließlich einen weiteren Betrag vereinbaren, der nur dann bezahlt wird und fällig wird, wenn eine Abnahme/Gesamt-/Endabnahme erfolgreich stattgefunden hat.

 

Diese Hinweise berücksichtigt, lassen sich Projektlaufzeiten erheblich verkürzen, die Gefahr ausufernder Änderungen verringern, den Kunden stark einbinden und die Verantwortung teilen. Der IT-Prozess wird spiralisiert, Funktionen priorisiert, ein klarer Projektplan tritt in den Vordergrund. Gerade die Beschleunigung bei der Beantwortung des Änderungsaufwandes führt oftmals dazu, dass der Auftragnehmer in ein nahezu unübersehbares Risiko kommt, was die Durchführbarkeit von Änderungen bzw. deren Ausführbarkeit betrifft. Deshalb kann es Sinn machen, ein Projekt in kleine, handhabbare, zeitlich überschaubare und fachlich tragfähige Einheiten zu zerlegen.

 

Änderungswünsche der Auftraggeber sollten auf die Zeit nach Fertigstellung eines jeweiligen Abschnitts verlegt werden und vor den Beginn mit dem nächsten Abschnitt die Entscheidung darüber herbeigeführt werden, ob diese Änderung auch tatsächlich ausgeführt werden soll oder nicht. Dieses Vorgehen bietet letztlich die Chance für den Auftragnehmer, Zusatzwünsche sich extra honorieren zu lassen.

 

 

<< Alle Beiträge

 

 

Keine Kommentare

Kommentar schreiben