Zukunft im Projektmanagement

2 Vertragsgestaltung und Projektmanagement (S. 73-74)

2.1 Ausgangsposition – Projektvertrag, Vertragsschluss, vorvertragliche Bindung und Allgemeine Geschäftsbedingungen

Die Erstellung von Individualsoftware wird in so genannten Projektverträgen geregelt, die juristisch als Werkverträge qualifiziert werden. Bei Werkverträgen schuldet der Unternehmer (hier das Softwarehaus) im Gegensatz zu Dienstverträgen einen Erfolg. Die Problematik der Projektverträge liegt darin, dass zu Beginn eines Projektes in der Regel noch nicht der Leistungsgegenstand (hier die Software) genau beschrieben werden kann und aufgrund dieser Unwägbarkeit auch die Vergütung noch nicht feststeht. Mangels dieser Eckpunkte gilt es, im Projektvertrag die »Spielregeln« zwischen den Vertragspartnern festzulegen und ein Verfahren zu definieren, mit dessen Hilfe diese Eckpunkte festgelegt werden. Der Verweis auf das Gesetzesrecht reicht hier nicht aus, da dieses keine Regelungen für ein solches Verfahren enthält. Wegen der Unsicherheiten ist es unbedingt empfehlenswert, vor Projektbeginn zumindest die ersten Leistungsstufen und die Vergütung zu vereinbaren. Vorverträge (LoI – letter of intent, MoU – memorandum of understanding) sollten unbedingt auch schon vor Aushandeln des endgültigen Vertrages die Punkte Erstleistung (z.B. Grobpflichtenheft), Vergütung und Nutzungsrechte an den Erstleistungen regeln. Softwarehäuser legen dem Kunden oftmals vorformulierte Projektverträge vor.

Bei solchen Allgemeinen Geschäftsbedingungen (AGB) ist darauf zu achten, dass diese der AGB-Kontrolle durch das Gesetz und durch die Gerichte unterliegen, Konsequenz ist, dass, sofern eine Regelung zu sehr zu Lasten des Kunden geht, die Regelung unwirksam ist und das Gesetzesrecht gilt, was im Zweifel den Kunden bevorzugt.

2.2 Wichtige Regelungspunkte

2.2.1 Leistungsbeschreibung

Grundsatz (wenn auch streitig) ist, dass der Kunde die gewünschte Leistung vorgeben muss, was in einem Grobpflichtenheft geschieht. Das Softwarehaus hat jedoch aufgrund des Wissensgefälles eine Beratungs- und Informationspflicht. Richtig wird zudem sein, dass das Softwarehaus die technisch-organisatorischen Informationen des Projektes (z.B. DV-Konzept) beibringen muss. Es ist ratsam, die Erstellung des Pflichtenheftes (und die entsprechende Vergütung) im Vertrag klar einem Vertragspartner zuzuordnen. Im Leistungsabschnitt »Planung« werden die konkreten Eigenschaften des Projektes beschrieben. Die zu erstellende Software und ihre Funktionen können enummerativ aufgezählt, wirtschaftlich-organisatorisch umschrieben oder mit einem Referenzprojekt bezeichnet werden. Zusätzlich empfiehlt sich, abstrakt Leistungsbeschreibungsmethoden zu nutzen, z.B. durch Verweis auf:

• Regeln der Technik;
• Stand der Technik;
• Stand von Wissenschaft und Technik.

Die Regeln der Technik bezeichnen ein niedrigeres Niveau als die Ausführung mittlerer Art und Güte des »Standes der Technik«. Der »Stand von Wissenschaft und Technik« beschreibt das höchste Niveau. Auch Angaben zur Ergonomie und zum Zeitverhalten sind sinnvoll. Im Rahmen des Projektmanagements (siehe unten) wird die Leistungsbeschreibung während des Projektverlaufes fortgeschrieben und konkretisiert.

2.2.2 Leistungsumfang der Software

Bei Überlassung von Standardsoftware muss das Softwarehaus, sofern nicht anders vereinbart, nur das Maschinenprogramm und ein Handbuch (auch online – streitig) dem Kunden überlassen. Streitig ist auch, ob bei der Erstellung von Individualsoftware auch der Quellcode überlassen werden muss. Die Rechtssprechung ist der Ansicht, dass jedenfalls dann nicht der Quellcode überlassen werden muss, wenn die Fehlerbeseitigung und Pflege der Software gewährleistet ist (zur Softwarehinterlegung siehe unten). Empfehlenswert ist jedenfalls, die Überlassung des Quellcodes entweder vorzuschreiben oder auszuschließen. Das Gleiche gilt für die Entwicklungsdokumentation.

2.2.3 Softwarehinterlegung

Software-Hinterlegungsvereinbarungen sind ein Kompromiss zwischen dem Softwarehaus, das eine unbefugte Verwendung seines Know-hows befürchtet, und dem Kunden, der insbesondere dann auf die Quellen und die Entwicklungsdokumentation zurückgreifen möchte, wenn das Softwarehaus entweder nicht mehr leistungsbereit ist oder insolvent wird. In der Hinterlegungsvereinbarung verpflichtet sich ein Treuhänder (Escrow, z.B. Notar oder spezialisiertes Unternehmen) zur Herausgabe an den Kunden in bestimmten Fällen. Üblich ist eine Herausgabe bei Insolvenz des Softwarehauses; im Interesse des Kunden ist auch die Herausgabe bei Leistungsabbruch und Beendigung der Weiterentwicklung durch das Softwarehaus. Risiken von Software-Hinterlegung sind z.B. deren Konkursfestigkeit (kann der Insolvenzverwalter die Hinterlegung wiederrufen?), die ständige Aktualisierbarkeit der Sourcen und die Gefahr des Missbrauchs.