Kaum ein IT-Projekt wird so zu Ende geführt, wie es sich die Vertragsparteien am Anfang vorgestellt hatten. „Change Requests“ der Kundschaft im Projektverlauf sind wohl eher die Regel als die Ausnahme. Diese Ergänzungen und Anpassungen benötigen zusätzliche Zeit. Häufig kann dann der ursprüngliche Zeitplan nicht mehr eingehalten werden – vertraglich vereinbarte oder formlos bestimmte Meilensteine werden zu bloßer Makulatur. Das ursprünglich veranschlagte Budget gerät möglicherweise außer Kontrolle. Der hinter dem Projekt stehende Business-Plan – die Erwartung, ab einem bestimmten Zeitpunkt nicht mehr Geld für die Softwareentwicklung auszugeben, sondern mit der entwickelten Software Geld zu verdienen – platzt wie eine Seifenblase. Was tun?
Viele IT-Projekte geraten auf diese Weise in Schieflage. Die Stimmung zwischen den Beteiligten ist im Keller. Am Ende wirft die eine oder die andere Seite hin, kündigt den projektvertrag und beendet die Zusammenarbeit. Dann wird gestritten, wer von wem wieviel Geld bekommt: Der Besteller fordert Vorschusszahlungen zurück. Der Entwickler stellt Rechnungen über Restzahlungen.
Die folgenden sieben Tipps für ein erfolgreiches IT-Projektmanagement sollen dazu beitragen, dass am Ende der Erfolg steht. Mit maßgeschneiderten Regelungen in Ihrem IT-Projektvertrag schaffen Sie Planungs-, Kosten- und Rechtssicherheit und schließen etwaige Compliance-Risiken aus.
Inhalt
Tipp 1: Detaillierte Leistungsbeschreibung (Scope)
Streit zwischen den Vertragspartnern, welche Leistungen bei der Entwicklung der Software tatsächlich geschuldet sind und welche Leistungen vergütungspflichtigen Mehraufwand bedeuten, bringt IT-Projekte wohl am häufigsten zum Scheitern. Deswegen muss der „Scope“ präzise bestimmt werden. Der „Scope“ definiert den gesamten Arbeitsumfang, der erforderlich ist, um das Projekt erfolgreich abzuschließen. Dazu gehören die Ziele, Ergebnisse („Deliverables“), Meilensteine, technische Anforderungen, Aufgaben und Zuständigkeiten der beteiligten Personen auf der einen und der anderen Seite, und schließlich die Grenzen des Projekts.
Bei agiler Sotwareentwicklung ist es grundsätzlich nicht erforderlich, einen konkreten Scope zu definieren. Dennoch ist es auch in agilen Projekten empfehlenswert, den Scope zuvor näher zu bestimmen, zum Beispiel in einem gemeinsamen Workshop der Beteiligten zu Beginn des Projekts.
Je ausführlicher, präziser und detaillierter der Scope definiert ist, je geringer ist das Risiko, dass die Vertragsparteien wegen Mehraufwand und Mängeln in Streit geraten.
Tipp 2: Lastenheft und Pflichtenheft
Je ausführlicher, präziser und detaillierter der Scope definiert ist, je geringer ist das Risiko, dass die Vertragsparteien wegen Mehraufwand und Mängeln in Streit geraten. Das hergebrachte Pflichtenheft und das vorangegangenen Lastenheft des Auftraggebers erweisen sich in vielen Fällen nicht als unnötiger Bürokratismus, sondern als der sichere Weg zum erfolgreichen Projektabschluss.
Tipp 3: Zuständigkeit und Befugnisse beim Auftraggeber
Häufig wird ein IT-Projekt vom operativ verantwortlichen Projektleiter anders gesteuert, als es sich das die wirtschaftlich verantwortlichen Personen – Geschäftsführer, Controller, Einkäufer – ursprünglich vorgestellt haben. Mehraufwand infolge von Change Requests oder unvorhergesehenen Verzögerungen führt dann zu unternehmensinternen Konflikten auf Auftraggeberseite. Häufig ist der Projektleiter nicht befugt, die erforderlichen Zusatzarbeiten zu beauftragen, die zeitlichen oder finanziellen Mehraufwand zur Folge haben.
Deshalb ist es unbedingt empfehlenswert, die Kompetenzen bzw. Bevollmächtigungen ausdrücklich im Vertrag festzulegen: Wer darf was und erstattet wem Bericht?
Tipp 4: Mitwirkungspflichten
In jedem IT-Projekt ist es notwendig, dass der Auftraggeber mitwirkt. Viele IT-Projekte scheitern daran, dass die eine Vertragspartei der anderen vorwirft, sich unkooperativ verhalten zu haben.
Der Umfang der erforderlichen Mitwirkung variiert je nach Projekt. Gerade agile Methoden erfordern in der Regel aber sehr umfangreiche Mitwirkung des Auftraggebers. erforderlich. Soweit Zeitpunkt und Umfang dieser Mitwirkungsleistungen bereits im Vorfeld bekannt sind, sollten sie konkret in den Vertrag mit aufgenommen werden. Dann können Auftraggeber und Auftragnehmer planen. Sonst drohen Unklarheiten Missverständnisse, Verzögerungen und Ärger.
Tipp 5: Dokumentation der Change Requests
In jedem IT-Projekt gibt es Abweichungen vom ursprünglichen Scope. Hier sind es Änderungswünsche des Auftragnehmers, dort sind es falsche Annahmen und Prognosen in der Planungsphase. Gerade in agilen Projekten werden derartige Änderungen häufig ohne Dokumentation umgesetzt. Soweit keine festen Termine und vor allem keine feste Vergütung vereinbart sind, ist dies oft kein Problem. Allerdings wird es in den meisten Fällen verbindliche Absprachen geben, auf die sich die Change Requests dann ganz erheblich auswirken: Der geplante Zeitpunkt der Fertigstellung („go live“) lässt sich nicht mehr halten. Der ursprüngliche Projektetat platzt.
Ohne einen Change-Prozess und die Dokumentation der Auswirkungen läuft der Auftragnehmer Gefahr, die zusätzliche Vergütung für Mehraufwand zu verlieren, wenn der Auftraggeber diese verweigert.
Tipp 6: Jour fixe
„Beim Reden kommen die Leute zusammen.“ Warum immer nur unter Zeitdruck miteinander sprechen, weil es notwendig ist oder weil es gar brennt? Ein Jour fixe, also ein regelmäßiger Besprechungstermin unabhängig von einem konkreten Anlass, bietet den Projektbeteiligten die Möglichkeit, sich in einem informellen Rahmen auszutauschen. Dabei können beispielsweise der Projektstatus abgeglichen, Problemsituationen besprochen und nächste Schritte geplant werden.
Tipp 7: Die Zeit nach dem go live
Nach dem „go live“, also der Inbetriebnahme für den operativen Einsatz, ist das IT-Projekt noch nicht wirklich abgeschlossen. Häufig aber regeln die Parteien des IT-Projektvertrages nicht, wie es nach Fertigstellung und Abnahme weitergehen soll.
Die Auftraggeberseite sollte ein Interesse daran haben, von Anbeginn an Planungssicherheit für den Betrieb des fertigen IT-Projekts zu erlangen. Hosting, Pflege und Wartung, Support, und Service-Level-Agreements spielen während der gesamten Einsatzzeit eine Rolle. Auch an eine Vereinbarung über Software-Escrow, also die Hinterlegung von Software, Quellcode und Dokumentation bei einem unabhängigen Treuhänder, sollte gedacht werden. Das gilt vor allem dann, wenn die Software für den Fortlauf unternehmenswichtiger Geschäfte erforderlich ist und nicht von jetzt auf dann ersetzt werden kann.
Entsprechende Verträge sollten deshalb parallel zum eigentlichen IT-Projektvertrag direkt mit vereinbart werden.
© RA Stefan Loebisch | Kontakt