Controlling von IT-Projekten

(1)

In Kooperation mit

Münchner Fachanwaltstag IT-Recht

Controlling von IT-Projekten

Rechtliche Schnittstellen in der

Vertragsgestaltung und Projektbegleitung

(2)

Der Alltag

Die Begriﬀe „IT-‐

Projekt“ und

„scheitern“ liefern bei google in 0,22 sec 165000

Einträge

(3)

Das Problem im Jahr 2000

Controlling von IT-Projekten

Fachgruppe IT-‐Projekmanagement der GesellschaR für InformaTk:

Nach Aussagen der Standish Group, die dazu mehr als 13.000 Projekte ausgewertet hat, hat sich die durchschniZliche Erfolgsquote von IT-‐

Projekten in den letzten zehn Jahren mehr als verdoppelt auf miZlerweile durchschniZlich 34

%. Je nach ProjekZyp erreichten 30 bis 40 % der Forschungs-‐, Entwicklungs-‐, SW-‐Einführungs, OrganisaTons-‐ und ProzessopTmierungsprojekte alle ihre Ergebnis-‐, Kosten-‐ und Terminziele vollständig.

(4)

wurde in den letzten 10 Jahren nicht gelöst

(5)

•  Die Beratungsfirma IAG Consulting hat festgestellt, dass trotz aller Warnungen und technischen Hilfen immer noch 68 Prozent aller IT- Projekte als gescheitert betrachtet werden müssen. Diese beachtliche Anzahl hat aber ganz verschiedene Ursachen. Und so ist auch die Lösung dieses Problems so diffizil wie das Problem selbst.

•  Wie es bei IAG hieß, ist der Erfolg auch in laufenden IT-Projekten meist

"unwahrscheinlich". In den meisten Fällen wurden die konkreten Bedürfnisse und Anforderungen nicht präzise untersucht, die das IT- Projekt erforderlich machten.

Das Problem ist stabil

(6)

Ein Projekt ist gescheitert, wenn für einen seiner Hauptaspekte (Leistung, Zeit, Geld) die Soll-Vorgabe vom Ist-Wert nicht erreicht wird, d.h. es wird nicht mit dem vorgesehenen Funktionsumfang, nicht innerhalb der geplanten Zeit und/oder nicht im Rahmen des genehmigten Budgets abgeschlossen.

Definitionsversuch

(7)

Die Ursachen

(8)

•  Mangelnde Geschäftsanalyse führt zu dreimal mehr Misserfolg im Projekt wie zu Erfolgen. Finanzielle Sorgen wie gesprengte Budgets, Underperformer und plötzliche Mehrkosten und Verschuldungen der Firmen führen am häufigsten dazu, dass das IT-Projekt stecken bleibt.

Meistens begannen diese Projekte schon mit kleinen Fehlern, die später unüberwindlich wurden.

•  Etwa 41 Prozent der eingesetzten Menschen, Software, intern und extern eingekauften Prozesstechniken werden von schlechten

Anforderungsbestimmungen aufgebraucht.

•  Etwa 60 Prozent an Zeit und Budgetanteilen werden für mangelnde Anforderungspraxis verbraucht.

Die Ursachen

(9)

•  Fehlende Klarheit und Anschaulichkeit der Anforderungen, fehlende

Beispiele, Missverständnisse zwischen Auftraggeber und Auftragnehmer (Visualisierung)

•  Fehlerhafte Angebotskalkulation aufgrund fehlerhafter

Anforderungsdefinition: Viele Auftraggeber sind weder bereit noch fähig, eine genaue Angebotsspezifikation etwa in Form eines abnahmefähigen Lastenheftes mit vollständigen Mengengerüsten vorzulegen.

•  Fehlende Leistungsbeschreibung mit Meilensteinplanung

•  Fehlendes Projektmanagementsystem mit integrierten Anforderungen

•  Ad-Hoc-Modifikationen ohne zusätzliche Ressourcen

•  Fehlende Ressourcen bei beiden Vertragsparteien

•  „Veralterung des Projektes“ durch Verzug oder zu spätes Beginnen nach Anforderungsdefinition: Kann der Zeitrahmen nicht eingehalten werden, wird spätestens ab 2 Jahren Laufzeit jedes IT-Projekt von der Technologieentwicklung überrollt.

Im Detail 1

(10)

•  Mangelnde Akzeptanz im Unternehmen und an den Schnittstellen – Schlüsselpersonen stehen dem Projekt kritisch gegenüber

•  Unzureichende Definition von Mitwirkungspflichten – unzureichende Mitwirkung

•  Austausch von Key-Personen (z.B. Projektleiter)

•  Schlechtes Monitoring / Schlechtes Reporting

•  Zu wenig Zeit und Personal für Qualitätssicherung

•  Unzureichende Testdefinition / schlechte Testdurchführung: im Zuge der unzureichenden Qualitätskontrolle treten häufig Fehler auf, die dann erst im Nachgang – und mit deutlich höheren Kosten – beseitigt werden können. Der damit verbundene Aufwand liegt nach Einschätzung von Steria Mummert um das Fünffache höher als für frühzeitige Test- und Korrekturläufe in den Projekten.

Im Detail 2

(11)

Ergebnis dieser Probleme

Werden diese immer wieder auRretenden Probleme nicht bei der Vertragsgestaltung berücksichTgt, vorhergesehen und

Regelungen im Vertrag zu ihrer Vermeidung sowie zur Lösung bei ihrem AuRreten

eingearbeitet, ist die Wahrscheinlichkeit des Scheiterns des Projektes hoch.

(12)

•  Vertragsgestaltung kann jeder Rechtsanwalt, aber ..

•  Der Spezialist weiß um diese kritischen Erfolgsfaktoren eines Projektes und berücksichtigt sie bei der Vertragsgestaltung.

•  Er sieht Mechanismen vor, die diese Probleme vermeiden, erkennbar oder bei Auftreten kontrollierbar machen.

•  Er sichert seinen Mandanten dagegen ab, dass ihn die Folgen dieser Probleme treffen.

•  Er trägt zu einer Dokumentation des Projektes bei, die bei einem Rechtsstreit die Beweislage für den Mandanten verbessert.

•  Er begleitet ein Projekt, indem er regelmäßig den Fortschritt des

Projektes abfragt, Änderungen vertraglich einordnet und nachvollzieht und nach Möglichkeit in kritischen Phasen auf eine sachgerechte

Entscheidung und Dokumentation hinwirkt.

Auswirkungen auf die Arbeit des IT-Fachanwalts

(13)

•  Sicherer Umgang mit spezifischen Begriffen

•  Kenntnis von Methoden, Normen und Vorgehensweisen (z.B. DIN-

Normen zum Projektmanagement, Dokumentation von Quellcodes, ITIL- Prozesse, Open-Source-Lizenzbedingungen, EVB-IT ...

•  Kenntnis / Umgang von Standardtools wie Projektmanagementsoftware, SAP-BluePrint ..

•  Sicherstellung einer regelmäßigen Information in einem Projekt / Sondenfunktion in der Korrespondenz der Projektleiter

•  Unterstützung des LA im Projekt und in die Abnahme der Lösung

•  Er liefert über die rein rechtliche Thematik hinaus einen

Das bringt er als Spezialist ins Projekt ein

(14)

Commitment des Teams und Erwartungshaltung

(15)

•  Projektdefinition

•  Voruntersuchung / Anforderungsanalyse

•  Erstellung Lastenheft

•  ggf. Ausschreibung der Leistungen / Bewertung der Angebote

•  Erarbeitung Pflichtenheft / Abnahme

•  Projekteinrichtung / Projektstruktur / Projektgremien

•  Definition Gesamtprojekt / Teilprojekte

•  Kickoff / Teambuilding

•  Entwicklungsphase / Piloterstellung

•  Testdefinition / Testfallbildung

•  Definition Rollout-Konzept

•  Schulung Keyuser

Projektphasen I

Das ideale IT-Projekt - Wunschvorstellung

(16)

•  Migrationsleistungen für Testdaten, ggf. Anonymisierung / Pseudonymisierung vorhandener Echtdaten

•  Testabläufe gemäß Testdefinitionen

•  Flächenschulungen

•  Migration Echtdaten

•  Definition und Vorbereitung Abnahmeumgebung

•  Technische „Abnahme“ und Produktionsfreigabe

•  Rollout in Produktivbetrieb

•  Begleiteter Produktivbetrieb

•  Rechtliche Abnahme

•  Support- und Maintenancephase

Projektphasen II

(17)

I. Vertragliche Grundlagen II. Projektdurchführung

III. Leistungssicherung IV. Vergütung

V. Vertragsdurchführung

VI. Allgemeine Bestimmungen

Umsetzung im Vertrag - Regelungsinhalte

Gestaltung von IT-Projektverträgen

(18)

•  Projektvorhaben – Projektziele

•  Bisheriger Projektverlauf

•  Geplanter Projektverlauf

•  Finanzieller, technischer und

organisatorischer Rahmen des Projektes

•  Qualitätskriterien

I. Vertragliche Grundlagen

(19)

Projektdefinition

•  Was sind die Ziele des Projektes

•  was gilt es zu erreichen (Ergebnisse)

•  wie ist der Zeitrahmen

•  in welchem Budget und

•  mit welchem technischen und organisatorischen Rahmen sind die Ziele umzusetzen

•  Wie werden diese Ziele im Projekt sichergestellt

(20)

Anforderungsdefinition

•  Analyse der Ist-‐SituaTon im Unternehmen

•  DokumentaTon der Deﬁzite der Ist-‐SituaTon

•  DeﬁniTon der Soll-‐SituaTon, der damit verbundenen

Vorteile in RelaTon zu den dokumenTerten Deﬁziten

•  DeﬁniTon der daraus resulTerenden

Anforderungen an die neue Lösung

(21)

Anforderungsbewertung

•  Welche Anforderungen tragen mit welchem Faktor dazu bei, dass die deﬁnierten Ziele (Soll) erreicht werden

•  Welche Anforderungen sind zur

Zielerreichung zwingend erforderlich

•  Welche Anforderungen sind notwendig, um das Team für das Projekt zu

moTvieren

•  Welche Anforderungen verbessern ineﬃziente Abläufe

•  Welche Anforderungen können „auch“ in diesem Projekt umgesetzt werden

•  Welche Anforderungen kosten

Ressourcen ohne deutlichen Mehrwert

(22)

Angebotsbewertung

•  Vor Angebotseingang Verfahren deﬁnieren, wie die Bewertung der eingehenden Angebote erfolgt.

•  Bemessungsfaktoren für die Angebote festlegen, z.B. für die Bereiche

•  Vorhandener Standard

•  Anteil Individualisierung

•  Kosten

•  Festpreisvereinbarung

•  Tme&material-‐Anteil

•  Vorhandene SchniZstellen

•  Referenzlösungen

•  Releasefähigkeit

•  Kompetenz des Teams

•  Langjährige Pﬂegezusage Im Zweifelsfall externe

(23)

•  Entwicklungsleistungen

–  Basissystem –  Module

–  Pilot

–  Schnittstellen

•  Projektmanagement

–  Methodik

–  Projektphasen - Meilensteine –  PMS

–  Steuerung

•  Projektcontrolling

–  Termine –  Ressourcen –  Leistungen –  Kosten

II. Projektdurchführung (1)

(24)

Projektplanung

•  Ist eine besTmmte Methodik und eine besTmmte Qualität des PM vereinbart

•  z.B. DIN 69900-‐1 bis -‐5, siehe auch Deutsche GesellschaR für

Projektmanagement, www.gpm-‐infocenter.de

•  Gibt es einen strukturierten Projektplan

•  Wird ein PMS in „Echtzeit“ eingesetzt, auf das auch der Kunde Zugriﬀ hat und in dem die Tasklisten, Ressourcen und ggf.

Anforderungen abgebildet sind.

•  Gibt es eine dem Projekt angemessene

ProjektorganisaTon, Teilprojekte, deﬁnierte Projektphasen mit deﬁnierten Soll-‐

Ergebnissen

(25)

Zeitliches Projektmanagement

•  Gibt es einen Projektzeitplan mit deﬁnierten Meilensteinen und ggf.

Fixterminen

•  Ist die Zeitplanung realisTsch,

berücksichTgt übliche Ferienzeiten,

durchschniZliche Krankheitszeiten und die erforderlichen Ressourcen auf Kundenseite (Mitwirkungspﬂichten)

•  Sind ausreichend Puﬀer für zu erwartende Verzögerungen vorgesehen

•  Sind Puﬀer für erwartete Changes und den Prozess zur AbsTmmung der Changes und deren Genehmigung vorgesehen

•  Sind die Zeiten für interne Tests und deren IteraTon eingeplant

•  Sind Zeiten für die Planung und

Durchführung der Abnahme eingeplant

(26)

Reporting

•  Ist ein ReporTng vertraglich geregelt und sind die

MindesTnhalte des ReporTng deﬁniert

•  Gibt es bei Vertragsschluss Musterreports als Grundlage

•  Ist deﬁniert, wer an wen wann was reportet

•  Behinhalten Reports

•  FunkTonen

•  Zeit

•  Kosten

•  Ressourcen

•  Wer monitored die Reports (4-‐

Augen-‐Prinzip)

KommunikaTon der

Projektleitung „sondieren“

(27)

•  Change-Request Verfahren

•  Installationen

•  Migrationen

•  Dokumentationen

•  Schulungen

•  Mitwirkungspflichten

II. Projektdurchführung (2)

(28)

Changes

•  Ist im Vertrag ein Change-‐Request Verfahren vereinbart

•  Wer darf Changes verlangen AG und/oder AN

•  Wie ist auf einen Change-‐Antrag zu reagieren

•  Prüfungsphase – Dauer -‐ Kosten

•  Angebot

•  Darstellung Projektauswirkungen

•  BeauRragung

Manchmal ist es besser, keine Changes zuzulassen und

Änderungen nach Abschluss des Projektes umzusetzen

(29)

Prioritäten bei Changes

•  Einordnung in Prioklassen zur Steuerung, was im Projekt und was außerhalb umgesetzt werden muss

•  Müssen im Zweifelsfall im Lenkungsausschuss entschieden werden, da ggf. Vertragsänderung.

(30)

Bewertung von Change-Requests

•  Wie wirken sich die Changes auf das Projekt aus

•  Inhalt des Projekts

•  Zeithorizont und Meilensteine

•  Kosten

•  bereits entwickelten FunkTonen

•  Test-‐ und Abnahmeverfahren

•  Ressourcen

•  Wie werden die Changes priorisiert

•  Unverzichtbar und dringend

•  WichTg und sinnvoll

•  Hilfreich und unterstützend

•  NeZ und nice to have

•  Ich häZe nie gedacht, dass das jemand

(31)

Dokumentation

•  Gibt es eine StandarddokumentaTon

•  Welche Qualität hat diese

•  DIN 661239 für Programmdoku

•  DIN 66231 für Entwicklungsdoku

•  EDV-‐Gerichtstag Saarbrücken

•  Wer dokumenTert die Changes

•  Wer schreibt Helptext in der Online-‐Hilfe

•  Gibt es dafür ein RedakTonssystem

•  Ist die Online-‐Hilfe strukturiert ausdruckbar

•  Ist eine Online-‐Doku update-‐und releasefest

•  Bekommt der Kunde die Doku in

bearbbeitbarer Form und kann er eigene ModiﬁkaTonen einarbeiten -‐>

RechtesituaTon an der Doku

(32)

•  Qualitätssicherung

•  Testverfahren

•  Abnahmeverfahren

•  Rechteeinräumung an Entwicklungsleistungen und Know- how

•  Quellcoderegelungen

•  Gewährleistung / Haftung / Schutzrechte

•  Geheimhaltung

•  Support und Pflege

–  Leistungen –  SLA

–  Kosten

III. Leistungssicherung

(33)

Qualitätsmanagement

•  Enthält der Vertrag Regelungen zu Qualitätsanforderungen,

•  z.B. ZerTﬁzierungen des Anbieters DIN 9001-‐2000 oder

•  der zu liefernden Lösungen – GOBS, IDW-‐PS880

•  Werden Qualitätsdokumente oﬀen gelegt

•  Können die Qualitätsvereinbarungen audiTert werden

•  Wird darüber im Projekt regelmäßig reportet

(34)

Testmanagement

•  Für Test ist bei SoRwareentwicklung in etwa so viel Zeit vorzusehen wie für die Entwicklung selbst! Ist das im Projektplan so berücksichTgt?

•  Enthält der Vertrag konkrete Regelungen für die Durchführung von Tests und die anwendbaren Testverfahren

•  Testobjekte

•  Testverfahren und DokumentaTon

•  Wasserfallmodell / V-‐Modell u.ä.

•  Werden besTmmte Normen vereinbart (z.B.

Test von SoRware nach DIN/ISO 9126 oder Testkonzept nach IEEE 829 (1)

(35)

•  Leistungen vor Vertragsschluss

•  Lizenzen

•  Projektvergütung

–  Fixpreis

–  Variable Kosten –  Changes

•  Rechnungstellung und Zahlung

–  Abschlagszahlungen

–  Zahlung nach Meilensteinen

•  Absicherung von Rückforderungen

–  Erfüllungsbürgschaften

–  Gewährleistungseinbehalte

IV. Vergütung

(36)

•  Gremien im Projekt

•  Eskalationsszenarien –  TPL -> PL -> LA

–  Sachverständigenverfahren –  Mediationsverfahren

•  Kündigungen im Projekt und Folgen

–  Sonderkündigungsrechte bei „Sollbruchstellen“

–  Definierte außerordentliche Kündigungen in Krisensituationen

V. Vertragsdurchführung

(37)

Gremien und wichtige Entscheidungen

•  Ausgestaltung und Dimensionierung in Abhängigkeit von Projektgröße

•  Steering-‐CommiZee

•  Lenkungsausschuss (oder mehrere)

•  Projektleitung und Projektkoordinator

•  Teilprojektleiter

•  Spezialgremien wie

•  Fachausschüsse

•  Change-‐Request-‐Board

•  Abnahmeboard

(38)

Technische Freigabe und Abnahme

•  Lieferanten drängen in der Regel auf Abnahme

•  Testumgebungen sind häuﬁg nicht geeignet, den Echtbetrieb ausreichend zu simulieren

•  Manche FunkTonen und Performance lassen sich erst im ProdukTvbetrieb überprüfen

•  Die Freigabe zum oder die Übernahme in den ProdukTvbetrieb sollten daher nicht als Abnahme gelten

•  Abnahme in 2 Phasen

•  Technische Freigabe zum ProdukTvbetrieb nach „Testabnahme“

•  Rechtliche Abnahme nach ausreichender Prüfungsphase in Echtumgebung

•  ACHTUNG: Vertragsstrafenvorbehalt beachten

(39)

Go-Live

•  Kein Go-‐Live ohne Fallback-‐Szenario (wenn technisch möglich)

•  Kann ein Parallelbetrieb organisiert werden

•  Go-‐Live mit gestaﬀelter

Einführungsunterstützung durch den Anbieter

•  Stresstest im Go-‐Live planen

•  Nach Go-‐Live erneute Abnahmeüberprüfung in Echtbetrieb

(40)

Nach dem Go-Live: Maintenance

•  Mindestpﬂegezusage schon im Projektvertrag vereinbaren

•  Update-‐ und Releasefähigkeit von Anpassungen und SchniZstellen geregelt?

•  SLAs

•  Quality of Services, Kompetenz von Hotline, Sprache, Ticketsystem mit Zugriﬀ durch AuRraggeber

•  Natürlich auch DatenschutzproblemaTk bei Zugriﬀ 24*7 around the world klären

(41)

Unsere Aufgabe: Vertragsgestaltung und Controlling

Gestaltung und Controlling von IT-Projekten durch den IT-Fachanwalt / Spezialisten

(42)

FÜR RÜCKFRAGEN

www.goerg.de www.czarnetzki.eu

(43)

Das Ende des Projekts ist der Anfang des Nächsten Einen habe ich noch!

Controlling von IT-Projekten

Münchner Fachanwaltstag IT-Recht