Es finden sich mannigfaltige Statistiken über Erfolg / Misserfolg von IT Projekten, manche Autoren beziffern den Anteil von gescheiterten IT Projekten auf bis zu 50%. Tatsächlich gilt: Vergleicht man etwa große Bauvorhaben mit großen IT-Projekten, so laufen IT-Projekte etwa doppelt (sic!) so schnell aus dem Ruder – so eine Studie von McKinsey („Schwarze Schwäne in IT-Projekten“). Das betrifft entweder das Budget oder aber den Zeitrahmen. Angesichts dieses Risikos lohnt es sich also, dem Management von Softwareprojekten etwas mehr Aufmerksamkeit zu schenken.

Dieser Artikel gibt zunächst einen Überblick zu den wichtigsten Erfolgsfaktoren sowie Handlungsprinzipien, ohne die jeweiligen Punkte zu vertiefen. Eine ausführliche Auseinandersetzung erfolgt in je eigenen Artikeln, die Sie auch auf dieser Wissensplattform finden.

[1] Klare Entscheidung für Individualsoftware versus Standardsoftware

Erfolgreiche Unternehmen wie Amazon, Zalando oder aber der mittelständische Logistiker IN tIME Express Logistik bilden ihre effizienten Geschäftsprozesse natürlich mit einer eigens entwickelten Software ab. Dies verschafft Ihnen einen entscheidenden Wettbewerbsvorteil, denn die Software bildet eigens für ein spezifisches Geschäftsmodell optimierte Prozesse ab – das leistet eine Standardsoftware in der Regel nicht. Das sollte aber Unternehmen nicht zur leichtsinnigen Annahme verleiten, eine handgestrickte Software für alle Unternehmensbereiche sei der Weisheit letzter Schluss.

Zwar gilt, dass Entwickler immer mehr mit Bausteinen bzw. vorgefertigten modularen Komponenten arbeiten und damit Individualsoftware schneller und kostengünstiger erstellt werden kann (vergleiche dazu auch den Artikel: „Individualsoftware, Standardsoftware oder Low-Code-Plattform?“). Dennoch sollte die Nutzung einer Standardsoftware stets Vorrang haben, eine Individualentwicklung erst dann verfolgt werden, wenn die Standardsoftware die Anforderungen nicht oder nur mit unverhältnismäßig hohem Customizing erfüllen kann. Die Individualprogrammierung erscheint bisweilen als der bequemere Weg, da man stets davon ausgeht, dass sich so 100% der Anforderungen erfüllen lassen; wie im Folgenden deutlich wird, erfordert die Auftragsentwicklung jedoch ein erhebliches Maß an zeitlichem und monetärem Investment, das vielfach unterschätzt wird.

Darum ist die dringende Empfehlung, ausreichend Zeit für ein Marktscreening verfügbarer Standortsoftware zu verwenden, vielversprechende Softwareanbieter für Workshops einzuladen und auf dieser breiten Informationsbasis die Entscheidung pro / contra Individualsoftware zu treffen.

[2] Erstellung eines (groben) Lastenheftes

Nichts gefährdet den Projekterfolg mehr als schreibfaule Auftraggeber, die halbgare Ideen und Das-habe-ich-mal-gesehen kommunizieren und anschließend erwarten, dass Softwareingenieure aus diesen Ideenskizzen die vollautomatisierte IT Lösung entwickeln.
Damit wir uns nicht missverstehen: Natürlich, vorbei ist die Zeit, wo eine detaillierte Anforderungsspezifikation an einen Softwareentwickler übergeben wird, der Entwickler geht in Klausur und übergibt schließlich die Software nach Abschluss von Entwicklung/Testing an den Endkunden. Zwar laufen vereinzelte Projekte noch nach dieser Logik ab, mehrheitlich jedoch werden agile Projektmanagementmethoden angewandt. Am Ende einer Iteration steht ein Produktinkrement, zu dem von Endkunden/Endnutzern Feedback in den Entwicklungsprozess einfließt. Dieser iterative Ansatz erlaubt die schnelle Korrektur von Fehlern, die Re-Priorisierung von Anforderungen und vermeidet so komplette Fehlentwicklungen.

Keineswegs aber darf die weite Verbreitung von agilen Projektmanagementmethoden zu der irrigen Annahme verleiten, ein Lastenheft sei nicht erforderlich. Mag man auch nach Auswahl eines Entwicklungspartner übereinkommen, eine agile Projektmanagementmethode anzuwenden, so bleibt ein (grobes) Lastenheft entscheidend, damit sich Softwarehäuser über technische Anforderungen, Ressourcenbedarf und Herausforderungen ein unmissverständliches Bild machen können. Ein gut strukturiertes Lastenheft erfüllt mehrere Zwecke: Erstens ist ein solches Dokument der effizienteste Weg, mehrere Anbieter zu informieren und in einen Auswahlprozess einzubeziehen. Zweitens zwingt es den Auftraggeber, eine unternehmensintern abgestimmte Vision für eine Software herbeizuführen; ein gut strukturiertes Lastenheft macht Inkonsistenzen sichtbar und zwingt zur Klärung. Drittens kennen auch agile Projektmanagementmethoden wie SCRUM Elemente wie eine Releaseplanung, etwa für das unverzichtbare Zeit- und Budgetmanagement.

Ein grobes Lastenheft bleibt also unabdingbar. Je spezifischer (und ungewöhnlicher) Ihre Unternehmensprozesse, desto ausführlicher muss das Dokument ausfallen (zu Tipps für die Erstellung eines guten Lastenheftes vergleiche folgenden Artikel: “Erfolgreiche Softwareprojekte: Tipps für ein gutes Lastenheft“). Grundsätzlich gilt, dass das Dokument möglichst schlank sein sollte und damit genügend Freiraum für Lösungsvarianten lassen. Mengenrüste müssen aber darin zwingend benannt werden (für eine adäquate Softwarearchitektur und Technologiewahl), ebenso die Entwicklungsdynamik in der Firma: Welche Schnittstellen oder Skalierungen sind möglicherweise binnen eines 10-Jahres-Horizonts erforderlich?

Bisweilen verschiebt ein Auftraggeber die Erstellung des Lastenheft in die Sphäre des Auftragnehmers, beispielsweise bei zeitlichen Engpässen oder fehlender fachlicher Qualifikation. Die Zielsetzung einer solchen Übung sind hierbei einerseits eine Analyse der inhaltlichen Problemstellung, andererseits eine Machbarkeitsanalyse (technische Machbarkeit oder/und Wirtschaftlichkeitsberechnung). Ich persönlich empfehle Unternehmen mittelständischer Größe unbedingt, digitale Kernkompetenz wie die systematische Erarbeitung eines Lastenheftes nicht an Berater weg zu delegieren. Es handelt sich nicht um unterstützende Prozess wie Buchhaltung oder Gebäudeinstandhaltung, sondern in der Regel um das Geschäftsmodell an sich (sonst ließe sich das mit einer Standardsoftware abbilden, wie etwa die Buchhaltung). Sollten solche Kompetenzen noch nicht vorhanden sein, müssen diese zwingen, d entwickelt werden (ggf. unter Hinzuziehung eines Coaches, der aber – anders als der Berater – nicht selbst moderiert, sondern nur als Zuflüsterer agiert).

[3] Vertragsgestaltung: Faire Verteilung der Risiken

Bei vorliegender Feinspezifikation und geringen technischen Risiken ist ein Vertrag vergleichsweise einfach: Hier können sich beide Seiten auf einen Fixpreis einigen, der Vergleich verschiedener Anbieter fällt leicht. Die Zahlung sollte nach Meilensteinen erfolgen, dem sollte ein Zeitplan zugrunde liegen. So lässt sich für den Auftraggeber schnell erkennen, wie sich das Projekt entwickelt. Wichtig: Mit Abnahme der Produktinkremente am Ende jeden Meilensteins muss der Auftraggeber ausreichend Ressourcen für das Testing bereithalten, sonst bleibt diese Regelung Makulator.

Schwerer wird die Vertragsgestaltung offensichtlich, wenn keine Feinspezifikation vorliegt, sondern nur grobe Anforderungen, die im Verlaufe eines Projektes weiterentwickelt werden. Einerseits wird sich kein Anbieter auf ein Fixpreisangebot einlassen, andererseits sollte kein Auftraggeber einen Blankoscheck unterzeichnen. Es gibt verschiedene Komponenten, um mit dieser Herausforderung umzugehen. Erstens sollte ein Anbieter auf Basis der groben Anforderungen eine Aufwandsschätzung bereitstellen, hierbei insbesondere (zeitliche) Risiken benennen. Zweitens muss der Vertrag eine klare Regelung dazu treffen, wie zu Beginn jeder Iteration im agilen Entwicklungsprozess Anforderungen definiert und Aufwandsschätzungen bereitgestellt werden. Die Releaseplanung (zur Kontrolle von Budget- und Termintreue des Gesamtprojektes) muss nach jedem Meilenstein zwingend aktualisiert werden. Im Projektverlauf ist die klare Priorisierung durch den Projektmanager seitens des Auftraggebers entscheidend, um Overengineerung und Budgettreue zu erreichen. Drittens müssen Stundennachweise inklusive Tätigkeitsbeschreibungen mindestens monatlich, wenn nicht gar wöchentlich eingefordert werden.

Eines ist besonders wichtig, damit die Verhandlungsposition des Auftraggebers nach Projektstart nicht zu schwach wird. Denn ist ein Entwicklungsprojekt erst einmal gestartet, steigen die Wechselkosten für den Anbieter massiv an, die Wechselbereitschaft sinkt. Projektentwickler wissen das. Dem kann der Auftraggeber mit folgenden Maßnahmen effektiv begegnen: Code und Architektur sind von Anfang an in genau definiertem Umfang zu dokumentieren (optimalerweise in Englisch), der Source Code wird mit Abschluss jedes Meilensteins an den Auftraggeber übergeben. Mit diesen Maßnahmen stellt der Auftraggeber sicher, dass seine Wechselbereitschaft glaubhaft bleibt, sollten Kosten ausufern oder die Qualitätsanforderungen verfehlt werden.

Für eine Vertiefung von vertragsrechtlichen Überlegungen bei Softwareentwicklungsprojekten nachfolgender Buchtipp: Management von Softwaredienstleistern – Buchrezension zu „Agile Verträge“ von Fritz-Ulli Pieper und Stefan Rook

Im Glossar können Sie sich auch einen schnellen Überblick zu einigen vertraglichen Gestaltungsvarianten verschaffen: Agiler Festpreis, Festpreis pro Sprint, Garantierter Maximalpreis, Garantierter Minimalumfang, Money for Nothing, Change for Free, Proviant & Prämie.

[4] Einfordern der Entwicklerprofile

Lassen Sie sich als Auftraggeber vor Vertragsschluss das nominierte Entwicklerteam vorstellen, und zwar in Form von 2-bis-3-seitigen Entwicklerprofilen. In der Regel lässt sich schnell erkennen, ob die Entwickler im relevanten fachlichen Umfeld und mit der Zieltechnologie ausreichend Erfahrung mitbringen. In langlaufenden Projekten spricht nichts dagegen, auch Entwickler ohne Erfahrung in einem fachlichen Bereich mitspielen zu lassen, diese Information ist allerdings von Wert für die Preisverhandlungen.

[5] Eine Projektorganisation für schnelle Entscheidungen und für die rechtzeitige Bereitstellung von Informationen

Damit erforderliche Entscheidungen unter Berücksichtigung aller relevanten Informationen schnell getroffen werden können, bedarf es einer klug aufgesetzten Projektorganisation. Häufig werden die Vertreter jener Funktionsbereiche in eine Steuerungsgruppe entsandt, die von einem Softwareprojekte profitieren und an der Entscheidungsfindung beteiligt sein sollten. Der Projektsponsor (häufig: der Geschäftsführer / Vorstand) erhält im regelmäßigem Rhythmus Statusmeldungen und kann kurzfristig zur Entscheidungsfindung/Eskalation hinzugezogen werden.
Die Aufgabe des Projektmanagers besteht darin, diese Steuerungsgruppe am Leben zu erhalten, die Informationsversorgung sicherzustellen, Diskussionen zu moderieren und Entscheidungen zu dokumentieren. Wenn das Softwareentwicklungsprojekt mit der agilen Projektmanagementmethode SCRUM arbeitet, empfiehlt es sich, die Vertreter der verschiedenen Funktionsbereiche an den sogenannten Sprint-Reviews zu beteiligen, wo Produktinkremente bewertet und die nächsten Anforderungen definiert/priorisiert werden. Eine solche Beteiligung ist schon alleine deshalb wichtig, um sicherzustellen, dass sich die Vertreter eingebunden fühlen und die fertiggestellte Software in Ihrem Bereich zügig ausrollen.

[6] Technologische Entscheidungen selbst treffen

In vielen mittelständischen Firmen, wo IT (vermeintlich) noch keine strategische Relevanz hat, sind IT Abteilungen (sofern existent) personell sehr schlank aufgestellt. Bisweilen besteht eine solche IT Abteilung ausschließlich aus IT Administratoren; bei Anfragen zur Bewertung von Technology Stacks für Softwareapplikationen wird abgewunken. In solchen Situationen ist es verlockend dem naheliegenden Impuls nachzugeben, solche technologische Entscheidungen an den „Spezialisten“ abzugeben und sich auf die rein fachlichen Anforderungen zu fokussieren. Das ist jedoch falsch.

Zwar kann man davon ausgehen, dass ein Softwarehaus heutzutage keine Projekte mehr in Delphi (veraltet) oder VB (geeignet für Kleinprojekte) entwickeln wird; man muss andererseits damit rechnen, dass ein Softwarehaus standardmäßig auf jene Technologien / Bibliotheken / Frameworks zurückgreift, mit denen dortige Entwickler vertraut sind. Die Verfügbarkeit an Technologien ist geradezu explodiert, Webprojekte lassen sich in Java, PHP, C#, etc. entwickeln, Datenbanken reichen von Oracle, MS SQL Server, mySQL bis hin zu Dutzenden von NoSQL Datenbanken. Jede Technologie weist Stärken und Schwächen auf, hier sind Abwägungen zu treffen (Trade-Off Entscheidungen), die nicht allein von einem externen Softwareentwickler getroffen werden können oder sollten.

Externe Softwareentwickler sowie der Projektmanager des Auftraggebers sollten darum für jede Technologieentscheidung die relevanten Entscheidungskriterien herausarbeiten (niedrige Entwicklungskosten, einfache Wartung, Skalierbarkeit, …), diese gewichten und anschließend die in Frage kommenden Technologien bewerten. Es ist ein no-brainer, dass diese Entscheidungen gut dokumentiert sein müssen.

Einen Überblick zu den gängigsten Technologien und einigen Hinweisen, in welchen typischen Anwendungsbereichen diese eingesetzt werden, findet sich in diesem Artikel: Executive Summary: Die wichtigsten Programmiersprachen, Frameworks. Falls der IT Dienstleister Free Open Source Software (FOSS) einsetzen möchte, dann ist ein grundsätzliches Verständnis der damit verbundenen Anforderungen hilfreich: Open Source Software: Crash Kurs zum richtigen Umgang mit Compliance Anforderungen

[7] Frühzeitige Prototypen

Bereits im Zusammenhang mit der Vertragsgestaltung wurde darauf hingewiesen, dass ich eine meilensteinorientierte Entwicklung dringend empfehle. Die Ergebnisse jeden Meilensteins müssen Softwareprodukte sein, die vollständig lauffähig sind (wenn auch im Funktionsumfang noch eingeschränkt).

Diese Empfehlung hat eine so hohe Relevanz, dass ich ihr einen eigenen Punkt gewidmet habe. Gerade die agilen Projektmanagementmethoden zeichnen sich dadurch aus, dass Entwicklungsergebnisse frühzeitig verfügbar sind und damit Fehlentwicklungen sofort gegengesteuert werden kann bzw. Nachbesserungen unmittelbar im nächsten Entwicklungszyklus erfolgen können. Auch hier nochmal der allfällige Hinweis: Der Auftraggeber muss sicherstellen, dass ausreichend (zeitliche) Ressourcen vorhanden sind, um diese Prototypen im Verlauf eines Projektes ausreichend zu testen und hierzu Feedback zu erarbeiten/dokumentieren.

[8] Dokumentation von Entscheidungen, Feedback und Ähnlichem

Auch dieser Punkt ein no-brainer, aber häufig vernachlässigt: Die Dokumentation von Entscheidungen, Feedback zu Testzyklen oder Ähnlichem schafft vollständige Transparenz. Nur so lassen sich ggf. Inkonsistenzen bei den Anforderungen erkennen, wird die Stellungnahme von Beteiligten in der Projektsteuerungsgruppe möglich und – worst case – damit besteht auch eine Grundlage zur Auseinandersetzung mit dem externen Softwareentwickler bei Verfehlung von Anforderungen.

Wichtig im Zusammenhang mit Dokumentation: In der heutigen Multi-Channel-Kommunikation finden sich vielfach Doku-Schnipsel auf diversen Kanälen: Email, aufgezeichneter VideoCall mit ScreenRecording, WhatsApp oder Team-Chat. Praktisch verwertbar wird eine Dokumentation, wenn diese in einheitlichem Format in einem konsolidierten Dokument (oder wenigstens: Ordner) stattfindet. Erst dann lässt sich von verwertbarer Dokumentation sprechen. Ein gemeinsamer Datenraum (z.B. auf NETFILES oder ähnliche sichere Plattformen, NICHT: DropBox) ist hierfür in der Regel Voraussetzung.

[9] Auf Überraschungen vorbereitet sein

Je innovativer Ihre Softwareapplikation ist, desto mehr Überraschungen werden Sie erleben. Darauf sollten Sie sich als Projektmanager einstellen. Bringen Sie eine gute Portion Gelassenheit mit, dazu Lust an Herausforderungen.

Author

Der Autor ist Manager in der Softwareindustrie mit internationaler Expertise: Prokurist bei einem der großen Beratungshäuser - Verantwortung für den Aufbau eines IT Entwicklungszentrums am Offshore-Standort Bangalore - Director M&A bei einem Softwarehaus in Berlin.