Agile Vertragsstrukturen für den Projekterfolg. 6. c-akademie

Größe: px

Ab Seite anzeigen:

Download "Agile Vertragsstrukturen für den Projekterfolg. 6. c-akademie"

Ernst Maus
vor 8 Jahren
Abrufe

1 Agile Vertragsstrukturen für den Projekterfolg 6. c-akademie

2 Seite 2 Softwareentwicklung 3.0 ist die Synthese der nützlichen Ideen aus den bestehenden Modellen, sowie neuen Aspekten, die sich aus aktuellen und zukünftigen technologischen und soziologischen Entwicklungen ergeben. Man soll das nutzen, was in einer gegebenen Situation Nutzen bringt und nicht unüberlegt den Methoden- Gurus folgen. Stefan Matt, creasoft ag

Aspekten, die sich aus aktuellen und zukünftigen technologischen und soziologischen

3 Seite 3 Erfolg und Misserfolg von Projekten 3 Rechtsordnungen, 1 Problem Klassische Vertragsstruktur Agile Vertragsstruktur Wo liegen die Probleme? Empfehlungen

4 Seite 4 Erfolg und Misserfolg von Projekten Quelle: The Standish Group 2013

5 Seite 5 Erfolg und Misserfolg von Projekten Quelle: The Standish Group 2013

6 Seite 6 Erfolg und Misserfolg von Projekten Quelle: The Standish Group Juni 2015

7 Seite 7 Erfolg und Misserfolg von Projekten The Google Way small teams of five to six people small time frames of five to six months limited and/or discrete function Quelle: The Standish Group 2013

8 Seite 8 Hall of Shame SAS Institute PeopleSoft Microsoft Dynamics Siemens Business Systeme AGFA Healthcare

9 Seite 9 Was sind Erfolgsfaktoren? Point 1: Simple Vision Point 6: Measurements Point 2: Commitment Point 7: Negotiate Point 3: Blink. 1,5 Entscheidungen pro 1000 USD Beraterkosten Point 4: Velocity Point 5: Education Point 8: The Plan Point 9: Kill Switch Point 10: Celebrate Quelle: The Standish Group 2013

10 Seite 10 3 Rechtsordnungen, 1 Problem Keine adäquate gesetzliche Regelung Modell des Austauschvertrages passt weder als Werkvertrag mit Erfolgsverpflichtung (keine Rückmeldung an den Auftraggeber, unbeschränkteherstellungsverpflichtung bis zur Abnahme, Zahlung erst bei Abnahme) noch als Dienstvertrag mit Weisungsabhängigkeit vom Auftraggeber (Projektverantwortung liegt beim Auftraggeber, Vergütung schon für bestes Bemühen fällig) und das Modell des Austauschvertrages selbst ist falsch: im Kern geht es um eine Joint Venture Struktur (analog einer ad hoc Gesellschaft)

noch als Dienstvertrag mit Weisungsabhängigkeit vom Auftraggeber (Projektverantwortung liegt beim Auftraggeber, Vergütung schon für bestes

11 Seite 11 Klassische Vertragsstruktur (I) 1 Definitionen 2 Vertragsgegenstand Der Auftragnehmer erstellt für den Auftraggeber in der Planungsphase das nach seiner Abnahme diesem Vertrag als Anlage 2 beizufügende Pflichtenheft. In der Umsetzungsphase entwickelt und realisiert der Auftragnehmer die Vertragssoftware nach den Vorgaben des Pflichtenheftes 3 Leistungserbringung Der Auftragnehmer erstellt das Pflichtenheft und die Vertragssoftware sorgfältig nach dem jeweils aktuellen allgemein anerkannten Stand der Technik. 4 Mitwirkungspflichten 5 Projektleitung Die Parteien benennen in Anlage 4 je einen Ansprechpartner ( Projektleiter ) und einen Stellvertreter als feste Bezugspersonen für alle das Projekt betreffende Angelegenheiten.

In der Umsetzungsphase entwickelt und realisiert der Auftragnehmer die Vertragssoftware nach den Vorgaben des Pflichtenheftes 3 Leistungserbringung Der Auftragnehmer erstellt das

12 Seite 12 Klassische Vertragsstruktur (II) 6 Informationsrecht und Reporting Der Auftragnehmer wird dem Auftraggeber regelmäßig und mindestens monatlich über den Stand des Projekts, insbesondere die Einhaltung der Anforderungen des Pflichtenhefts und des Zeitplans, Bericht erstatten ( Performance-Reports ). 7 Leistungsänderungen 8 Planungsphase: Erstellung des Pflichtenhefts Der Auftragnehmer erstellt das Pflichtenheft und die Vertragssoftware sorgfältig nach dem jeweils aktuellen allgemein anerkannten Stand der Technik. 9 Abnahme des Pflichtenhefts 10 Umsetzungsphase: Erstellung der Software 11 Abnahme der Software

7 Leistungsänderungen 8 Planungsphase: Erstellung des Pflichtenhefts Der Auftragnehmer erstellt das Pflichtenheft und die Vertragssoftware sorgfältig nach

13 Seite 13 Klassische Vertragsstruktur (III) 12 Vergütung 13 Rechteeinräumung 14 Fehlerklassen und Reaktion 15 Gewährleistung 16 Haftung 17 Eskalationsverfahren 18 Datenschutz und Datensicherheit 19 Geheimhaltung 20 Export- und Importkontrolle 21 Sonstiges

Gewährleistung 16 Haftung 17 Eskalationsverfahren 18

14 Seite 14 Agile Vertragsstruktur (I) 1 Vertragsgegenstand Auftraggeber beauftragt hiermit Auftragnehmer das im Product Backlog beschriebene Projekt nach Maßgabe dieses Vertrages durchzuführen. Die Projektplanung liegt bei Auftragnehmer Ziel des gemeinschaftlichen Projektes ist die betriebsbereite Implementierung von Standardsoftware (einschließlich vereinbarter Schnittstellen) mit abgeschlossener Migration bzw. Datenübernahme von den Altsystemen. Das Projekt umfasst die in der Grobspezifikation gem. Anhang 8.1 Sprintbacklog (Phase I) aufgeführten Funktionsbereiche. Der Zeitplan ist in Anhang 8.2 Projektvertrag Sprintplanung detailliert aufgeführt. 2 Pflichtenheft und Product Backlog 3 Zeitplan

Die Projektplanung liegt bei Auftragnehmer Ziel des gemeinschaftlichen Projektes ist die betriebsbereite Implementierung von Standardsoftware (einschließlich vereinbarter

15 Seite 15 Agile Vertragsstruktur (II) 4 Änderungsverfahren 5 Abnahme 6 Vergütung, Abrechnung Sollten die abgerechneten Leistungen unter 80% des vereinbarten Budgets liegen, erhöht sich die Vergütung in der Weise, dass Auftragnehmer 90% des vertraglich vereinbarten Budgets abrechnen darf. Sollten die abgerechneten Leistungen zwischen 110% und 129% des vereinbarten Budgets liegen, gewährt Auftragnehmer Aufttraggeber auf den über 110 % liegenden Betrag einen Discount in Höhe von 20% auf den überschießenden Betrag. Dies bedeutet, dass Auftragnehmer nur 80% des vertraglich vereinbarten Tagessatzes für die über 110% liegenden Leistungen abrechnen darf.

Sollten die abgerechneten Leistungen zwischen 110% und 129% des vereinbarten Budgets liegen, gewährt Auftragnehmer Aufttraggeber auf den über 110 % liegenden

16 Seite 16 Agile Vertragsstruktur (III) 6 Vergütung, Abrechnung Sollten die abgerechneten Leistungen zwischen 130% und 149% des vereinbarten Budgets erreichen, wird für den über 130% hinausgehenden Aufwand ein um 30% verminderter Tagessatz angewandt. Dies bedeutet, dass Auftragnehmer nur 70% des vertraglich vereinbarten Tagessatzes für die über 130% liegenden Leistungen abrechnen darf. Sollten die abgerechneten Leistungen 150% oder mehr des vereinbarten Budgets erreichen, wird für den über 150% hinausgehenden Aufwand ein um 50% verminderter Tagessatz angewandt. Dies bedeutet, dass Auftragnehmer nur 50% seines vertraglich vereinbarten Tagessatzes für die über 150% liegenden Leistungen abrechnen darf.

Dies bedeutet, dass Auftragnehmer nur 70% des vertraglich vereinbarten Tagessatzes für die über 130% liegenden Leistungen abrechnen darf.

17 Seite 17 Agile Vertragsstruktur (IV) 7 Beendigungsmanagement Am Ende des Projekts liefert der Auftragnehmer dem Auftraggeber den aktuellen Stand der Entwicklungen und Anpassungen in elektronischer Form. Dazu gehören: Eine Liste der Transporte, die für dieses Projekt ins Produktivsystem eingespielt wurden, Eine Kurzanleitung, wie die neuen Funktionen aufgerufen werden können. Am Ende des Projekts findet eine Abnahme mit Last-, Funktions- und Integrationstests statt. Die qualitativen Ausprägungen für den Test werden vorher in einem Testplan festgehalten.

Dazu gehören: Eine Liste der Transporte, die für dieses Projekt ins Produktivsystem eingespielt wurden, Eine Kurzanleitung, wie die neuen

18 Seite 18 Agile Vertragsstruktur (V) 8 Zusammenarbeit Beide Vertragsparteien wollen die Projektmethode Scrum einsetzen, um die erforderliche Flexibilität und um einen optimalen Ausgleich zwischen technischer Machbarkeit und den Wünschen des Auftraggebers zu erreichen sowie zur Risikominimierung, Transparenzsteigerung und zur Verbesserung des Return-on- Invest. Der vorliegende Vertrag berücksichtigt die besonderen Anforderungen hinsichtlich der Agilität und Beauftragungsmodi von Scrum. Das Gelingen des Projekts setzt eine enge Kooperation zwischen Auftraggeber und Auftragnehmer nach den etablierten Verfahrensregeln von Scrum voraus. In diesem Projekt werden folgende Rollen besetzt: Product Owner: wird abweichend von den üblichen Regelungen - von Auftragnehmer gestellt Stakeholder: werden von Auftraggeber gestellt Scrum Master: wird von Auftragnehmer gestellt Team: wird von Auftragnehmer gestellt

Der vorliegende Vertrag berücksichtigt die besonderen Anforderungen hinsichtlich der Agilität und Beauftragungsmodi von Scrum.

19 Seite 19 Agile Vertragsstruktur (VI) 9 Schlussbestimmungen

20 Seite 20 Wo liegen die Probleme? Klassischer Vertrag Komplexität Beschränkte Steuerungsreichweite der Spezifikation Dynamik der Anforderungen Zunehmende Abhängigkeit vom Dienstleister/Auftragnehmer kriechende, herrenlose Projekte

21 Seite 21 Wo liegen die Probleme? Product Backlog? Definition of Done? Pricing? fixed price per iteration? fixed price per user story fixed price for an agreed number of user stories? Haftung?

22 Empfehlungen Betrachten Sie den Software Erstellungsvertrag als Kooperationsverhältnis über einen Economic Lifecycle Die Qualität der Steuerung- und Kontrollsysteme im Vertrag entscheidet über Erfolg oder Misserfolg des Projekts! Vertrauen Sie nicht auf Vertragsmuster. Juristen arbeiten strukturell immer im Rückspiegel, zukunftsorientierte Lösungen sucht man deshalb in Vertragsmustern häufig vergeblich. Finden Sie Lösungen für Optimierungsverpflichtung Sicherung unternehmerischer Freiheit des Auftraggebers Proaktive Kommunikation

23 Seite 23 Werner Bachmann Rechtsanwalt Tel: Fax: Mobil:

24 Seite 24 Backup Priorisierung von Störungen Auswirkung 1 Person 1 Bereich 1 Standort Totalausfall Dringlichkeit Kritisch FK2 FK1 FK1 FK1 Hoch FK2 FK2 FK1 FK1 Mittel FK3 FK2 FK2 FK1 Niedrig FK3 FK3 FK2 FK2

25 Seite 25 Backup Reporting FK1 FK2 FK3 Mindestens jede Stunde, jeweils um 00. Der Takt ist zu erhöhen, je näher man an einen produktionswichtigen Zeitpunkt kommt (alle 15 Minuten, jeweils um 00, 15, 30 und 45) alle 2 Stunden zur vollen Uhrzeit (gerade Stunden) innerhalb der Servicezeit erste Statusmeldung bis zum nächsten Arbeitstag 14 Uhr

26 Seite 26 Backup Anforderung an Statusmeldungen Aktueller Status Darstellung der Ergebnisse der durchgeführten ersten Fehleranalyse Darstellung der Auswirkungen auf andere Funktionalitäten (Kritikalität) Vorschlag einer Vorgehensweise, um den Fehler zu umgehen Veranlassen der mit Auftraggeber abgestimmten notwendigen Maßnahmen zur Implementierung der vorläufigen Lösung sowie Veranlassen der notwendigen Maßnahmen zur endgültigen Behebung des Fehlers inkl. Zeitplan ggf. Anforderung von Mitwirkungspflichten mit klaren Arbeitsanweisungen Wann gibt es die nächste Statusmeldung? (z. B. Die nächste Statusmeldung kommt um 17:30., bzw. Es erfolgt keine weitere Statusmeldung )

Ähnliche Dokumente

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was