Software-Projekte zum Erfolg führen

Agile Methoden haben sich in der Praxis durch­gesetzt. Projektleiter, Entwickler und Fachvertreter sehen bei Software-Projekten große Vorteile im iterativen Vorgehen. Statt wie beim Wasserfallprojekt die Ergebnisse im Voraus zu planen, nähert sich das Team dem Ziel etappenweise an. Eigenverantwortliches Vorgehen mit Methoden wie „Fail fast“ und das gemeinsame Lernen aus Fehlern stehen im Vordergrund. Finanzabteilung und Geschäftsleitung aber sehen Kostensicherheit und Termintreue durch agile Methoden gefährdet.

Tatsächlich bietet die klassische Wasserfallmethode rein rechtlich mehr Sicherheit. Das juristische Instrumentarium ist auf solche klassischen Projekte ausgerichtet. Beratungsleistungen werden in einem Lastenheft festgehalten, das zum Gegenstand eines Werkvertrags gemacht werden kann. Leistungsbeschreibung, Termine und Kosten scheinen zunächst unter Kontrolle. Später verändert sich die Situation. Software-Entwicklung, egal ob Individual-Entwicklung oder Produkteinführung, ist wissensbasiert und daher stark abhängig von funktionierender Kommunikation im Team. Schon einfache Missverständnisse können große Auswirkungen haben.

Der Konflikt über Missverständnisse im Lastenheft ist daher vorprogrammiert und eine Serie von Change Requests die logische Folge. Das verursacht beträchtliche Mehrkosten. Es ist deshalb zu überlegen, ob zu Projektbeginn gar keine werkvertrag­liche Leistung vereinbart werden sollte. Stattdessen könnte in ein kollaborativ-generatives Team investiert werden, das mit höherer Wahrscheinlichkeit ein funktionierendes Software-System liefert.

In Software-Projekten trifft Technik auf Geschäfts- und Organisationsentwicklung. Ein Software-Projekt steht immer an der Schnittstelle zwischen Altem und Neuem. Es hat zwar
eine starke technologische Komponente, ist aber auch Geschäfts- und Organisationsentwicklungs­projekt. Dem wird zu wenig Bedeutung zugemessen. Projekte scheitern nicht an der Technik, sondern aufgrund von Missverständnissen im sozialen Feld der beteiligten Organisationen.

So möchte etwa der Einkauf Software beziehen wie Ziegelsteine, weil dies rechtlich sicher ist. Was beim Erwerb physischer Güter gut funktioniert, geht aber nicht mit Software. Diese ist beliebig oft und ohne Qualitätsverlust kopierbar, leicht formbar, unsichtbar und vor allem komplex. Sie bildet zudem die Prozesse des Unternehmens ab und ist deshalb immer auch individuell, selbst wenn Standard-Software eingesetzt wird. Software-Projekte haben kein Enddatum. Ständig muss die Software an neue Gegebenheiten in ihrem Umfeld an­gepasst werden, umso mehr, je strate­gischer die eingesetzte Software für die Organisation ist. Die Entwicklung endet erst, wenn die Software ab­geschaltet wird. Sie begleitet das Software-Produkt also über seinen gesamten Lebenszyklus.

Organisationen, die Software-Projekte als Veränderungsprojekte verstehen, haben größere Chancen auf eine erfolgreiche Realisierung. Das hat Auswirkungen auf den Einkauf externer Leistungen. Echte Veränderung muss man selber bewirken, man kann sie nicht delegieren. Veränderung wirkt immer und wird unterschiedlich stark gesteuert. Wie können Organisationen Veränderung bewirken?

Rationale Strategie: Sie setzt auf Denken, sachliche Argumente, Logik. Zentral ist der Experte. Er analysiert das Pro­blem, erarbeitet Lösungsvorschläge und geht davon aus, dass andere ebenso sachbezogen und logisch denken wie er. Der Auftraggeber unterstellt dem Experten einen Wissensvorsprung und erwartet von ihm eine Lösung. Rationale Strategien liefern oft schlüssige Konzepte, doch ist es für Betroffene oft schwer, die vom Experten erarbeiteten Lösungen nachzuvollziehen. Sie werden als fremd empfunden und nicht akzeptiert. Auch wird kein eigenes Know-how erarbeitet. Experten können zu 100 Prozent richtigliegen und trotzdem kann das Projekt im Misserfolg enden. Der Skeptiker Michael Shermer hat dazu einmal gesagt: Je schlauer du bist, desto besser bist du im Rationalisieren einer schlechten Idee.

Entwicklungsstrategie: Hier bleibt die Verantwortung für die Veränderung bei der Organisation. Der beratende Experte liefert keine fertigen Lösungen, sondern gestaltet den Veränderungsprozess zum Wohl der beteiligten Organisationen. Der Ansatz geht davon aus, dass die Lösungsfähigkeit in der Organisation bereits vorhanden ist oder entwickelt werden kann. Die alten Lieferanten sind die neuen Partner.

Technische Expertise wird durch Methoden der Facili­tation integriert. Ein psychologisch sicherer Raum wird geöffnet, der Höchstleistung zulässt. Die Entwicklungsstrategie stärkt die Innovationsfähigkeit der Organisation, die Mitglieder erlernen Methoden sowie Strategien auch für künftige Entwicklungsprozesse. Das setzt einen hohen Zeitaufwand voraus. Sind Mitglieder der Organisation selber nicht bereit, Verantwortung zu übernehmen, kann keine Wirkung erzielt werden.

Für klassische Software-Projekte gibt es ein erprobtes vertragliches Instrumentarium. Früh werden Berater mit einer Bestandsaufnahme und mit der Erarbeitung eines Lastenhefts beauftragt. Dafür werden Verträge auf der Basis des Auftragsrechts ab­geschlossen. Geschuldet ist eine sorgfältige Beratung, aber kein Resultat, doch Pauschalpreise können vereinbart werden. Anschließend sucht eine Ausschreibung einen Anbieter, der bereit ist, das Projekt gemäß des Lastenhefts zu realisieren. Ein Werkvertrag fixiert Leistungsgegenstand, Termine und Kosten. Kommt es zu Änderungen des Leistungsgegenstands im Projektverlauf (was bei Software immer der Fall ist), müssen diese in Vertragsnachträgen (Change Requests) abgebildet werden. Für die Betriebsphase werden separate Wartungsverträge abgeschlossen.

Für Applikationsprojekte ist dieses vertragliche Instrumentarium jedoch nur beschränkt brauchbar. Denn das Werkvertragsrecht mit seiner auf messbare Ergebnisse ausgerichteten Resultatverantwortung polarisiert die Interessen. Es versteht Kundinnen und Kunden als bloße Leistungsempfänger statt als wesent­liche Faktoren für den Erfolg. Zudem bekommt der Kunde die falsche Sicherheit, man könne Projekterfolg einkaufen. Das Auftragsrecht bietet daher eine geeignete Grundlage, um Dienstleister mit Steuerungs- oder Moderationsaufgaben in Entwicklungsprojekten zu beauftragen, auch mit Pauschalpreisen für Leistungspakete. Doch kennt das Auftragsrecht keine Gewährleistung und deshalb auch keine Verpflichtung, für Mängel einzustehen.

Bei Projekten mit Ergebnisverantwortung sind zwei Themen auseinanderzuhalten: die Vereinbarung von verbindlichen Zusagen bezüglich Zielsetzung (Scope), Terminen und Kosten einerseits und das Einstehen für Mängel nach Projektabschluss andererseits. Wir erkennen an, dass Anbieter für die Qualität ihres Codes einstehen müssen. Das spricht für das Werkvertragsrecht. Hingegen kann durchaus darauf verzichtet werden, den Scope, die Kosten sowie die Termine zu Projektbeginn abschließend zu fixieren. Werkvertragliche Leistungen können auch nach Aufwand (Time & Material) abgerechnet werden. Damit trägt der Kunde mehr Risiken oder positiv formuliert: mehr Verantwortung. Anstatt das Erreichen des Projekterfolgs an den Anbieter zu delegieren, tragen Auftraggeber jede wichtige Entscheidung mit, weil die finanziellen Konsequenzen letztlich sie und nicht den Anbieter treffen. Eine gewisse Kostensicherheit lässt sich auch bei Time-&-Material-Verträgen erreichen, indem vom Anbieter eine Kostenschätzung verlangt wird. Wird die ohne Zutun des Kunden unverhältnis­mäßig überschritten, kann er vom Auftrag zurücktreten. Das Risiko eines Abbruchs wirkt disziplinierend, lässt aber dennoch eine flexible Projektgestaltung zu.

Ein ähnlicher Ansatz ist der Einkauf technologischer Leistungen im „Rent a Factory“-Modell. Dabei werden neben personellen Ressourcen in Form ganzer Teams auch Tools und Methoden eingekauft. Im Unterschied zu einem herkömmlichen Werkvertrag wird aber ebenfalls kein Scope garantiert, sondern nur die Qualität der im Auftrag des Kunden (auf Zuruf) ausgeführten Entwicklungsleistung. Im Zusammenhang mit agilen Projekten werden Risk-Sharing-Modelle diskutiert, mit denen der Anbieter das Projektrisiko mittragen soll. Solche Ansätze haben sich in der Praxis jedoch (noch) nicht durchgesetzt.

Sowohl Kunden als auch Anbieter fahren deshalb heute noch besser damit, auf erprobte Vertragskonzepte wie den Werkvertrag mit Vergütung nach Aufwand abzustellen. Dass Parteien sich zwecks Realisierung eines gemeinsamen Projekts zu einer einfachen Gesellschaft zusammenschließen, dürfte hingegen nur ausnahmsweise gerechtfertigt sein, etwa wenn über das Projekt hi­naus eine weitere Zusammenarbeit ins Auge gefasst wird. Auch kennt das Recht der einfachen Gesellschaft einige Regeln, die im Zusammenhang mit Software-Projekten unerwünscht sind. Hierzu zählt beispielsweise der Erwerb gemeinsamer Rechte am Arbeitsergebnis sowie das gemeinsame Tragen des Projektrisikos.

Über Software-Projekte entwickeln Unternehmen gleichzeitig ihre betriebliche Organisation. Beziehen Sie als Führungskraft die Belegschaft deswegen so oft wie möglich in die Planung und Umsetzung ein, um gemeinsam zu lernen. Vertrauen Sie Ihrem Team und drücken Sie dies auch aus. Nehmen Sie Ergebnisse des Teams ernst. Vermitteln Sie Sicherheit. Es muss klar sein, dass niemand mit seinem Arbeitsplatz spielt. Schaffen Sie einen sicheren Raum, aber vergewissern Sie sich auch, dass das Team bereit ist, Verantwortung zu übernehmen. Sehen Sie Ihre Lieferanten als Partner und vertrauen Sie Ihren eigenen Fähigkeiten im Projekt. Eine eigenverantwortliche Kooperation und weniger Risikoabsicherung führen zu besseren Ergebnissen als harte Verträge. Die Zeit für die Erstellung komplexer Lastenhefte, die jeden Eventualfall abdecken wollen und dies doch nie erreichen, sparen Sie sich lieber.