Die Risikoanalyse bzw. -bewertung in Softwareprojekten ist in vielen Unternehmen und Projektteams immer noch ein ungeliebtes Stiefkind. Das liegt zum Teil schlichtweg an der Durchführbarkeit. Im Gegensatz etwa zum Scrum-Framework, in dem es klare Regeln gibt, gibt es hier keine eindeutigen Vorgehensweisen. Denn wie genau bewertet man die Eintrittswahrscheinlichkeit und vor allem den daraus resultierenden Schaden? Den meisten Projektleitern ist aber durchaus bewusst, dass sie sich mit dem Thema vor und in der Tat auch während des Projektverlaufs auseinandersetzen müssen.

Die folgenden sieben Fragen können bei der praktischen Risikoanalyse helfen:

Diese Frage scheint auf den ersten Blick trivial, denn nur qualifiziertes Personal kann Projektpläne erstellen. Leider zeichnet sich in der Praxis oft ein anderes Bild. So werden Zielvorgaben von Bereichsleitern oder Vorständen formuliert. Wichtig hierbei ist es, nicht direkt auf Konfrontation zu gehen, sondern sachlich den Wunsch aufzunehmen und dann mit dem Projektteam zu besprechen. Nach Zerteilung des Projektes sollte der Projektleiter in der Lage sein, eine grobe Zeiteinschätzung zurückzugeben, um so vorzeitig auf eine Gefahr in der Zeitplanung hinzuweisen. Nichts ist schlimmer, als eine genannte Timeline zu akzeptieren und sie dann kurz vor Ablauf der Frist ohne vorherige Warnung zu reißen. Wird von der Führungsebene kein Verschieben des Fertigstellungsdatums gewährt, muss die nachfolgende Frage geklärt werden.

Diese Frage stellt sich nicht nur bei fixen Zielvorgaben, denn die richtige Teamgröße mit der Besetzung aller benötigen Skills ist unumgänglich. Geprüft wird das am besten vor beziehungsweise zu Beginn des Projektes. Gerade bei Softwareprojekten ist ein nachträgliches Einbinden von Entwicklern problematisch. Dem Brooks’schen Gesetz nach kann das im Worst Case den Projekttermin noch weiter nach hinten schieben. „Der Einsatz zusätzlicher Arbeitskräfte bei bereits verzögerten Softwareprojekten verzögert sie nur noch weiter.“ Zudem sollten die Urlaubskalender und somit die verfügbare Zeit aller Kollegen während der Projektlaufzeit erfasst sein.

Ein Bereich, der oftmals unterschätzt wird, ist das Testen und Dokumentieren von Softwareprojekten, was uns zur nächsten Frage bringt:

Frei nach dem Motto „Darum kümmern wir uns später“ kann es vorkommen, dass aufgrund von Zeitdruck Tests und die Dokumentation nach hinten verschoben oder im schlimmsten Fall gar nicht gemacht werden. Warum ist das so? Oft wird das Thema zweitrangig behandelt, weil es nicht direkt in der Wertschöpfungskette enthalten und nicht zwingend notwendig für ein Deployment ist. Kunden sind oftmals nicht bereit, dafür zu zahlen, und Führungskräfte können die Notwendigkeit aus ihrer Sicht schwer abschätzen. Tests und Dokumentation sind aber ein elementarer Bestandteil jedes Softwareprojektes, weil jede länger im Einsatz befindliche Software Bugfixings erhält. Deshalb muss jedes Feature dokumentiert und ausgiebig getestet werden. Jede Zeitspanne, die hier eingespart werden soll, wird in der Zukunft potenziert auf einen zurückfallen. Eine Faustformel besagt: 1/3 Planung und Konzeption, 1/3 Entwicklung und 1/3 Testing und Dokumentation. Mittlerweile gibt es auch Konzepte wie das Continuous Testing, bei denen das Testen mit dem Entwicklungsfortschritt verdrahtet wird.

Wie bei einer erfolgreichen Sportmannschaft muss sich auch ein Projektteam erst zusammenfinden. Hier müssen zum einen die fachlichen Kompetenzen der anderen ergründet werden, aber auch die menschlichen. Besteht das Kernteam schon länger, ist das in der Regel weniger problematisch. Da aber vermehrt technische Teams mit sehr spitzem Wissen für bestimmte Projektziele zusammengesucht werden, kann es vorkommen, dass ein neu formiertes Projektteam gebildet wird. Es benötigt dann, genau wie die Sportmannschaft, eine gewisse Zeit, um produktiv zu werden. Ein Nullsprint zu Beginn des Projekts ist hier keine Seltenheit. Es ist nicht immer sofort klar, wer welche Information wann an wen übergibt. Zudem ist es hilfreich, ein internes Lexikon anzufertigen, in dem auch vermeintlich einfache Begriffe definiert werden, damit jedem im Wording klar ist, wovon das Gegenüber spricht. Womit wir auch direkt zur nächsten Frage kommen:

Hierbei geht es nicht um die Bloßstellung einzelner Personen, sondern darum, dass der Projektleiter auf sachlicher und menschlicher Ebene herausfindet, ob die einzelnen Mitarbeiter fachlich in der Lage sind, das Projekt durchzuführen. Hier muss behutsam den einzelnen Personen auf den Zahn gefühlt werden. In aller Regel werden eingesetzte Technologien vor dem Projektstart mit dem Team zusammen festgelegt. Das kann niemals eine Einzelentscheidung sein. Will das Team mit einer bestimmten Technologie arbeiten, können Teammitglieder sich einarbeiten oder geschult werden. Das kann ein Risiko darstellen, weil nicht klar ist, ob und vor allem in welcher Zeit es funktioniert. Deshalb muss hier mehr Zeit eingeplant werden. Die folgende Frage muss, egal in welcher Technologie das Projekt umgesetzt werden soll, mit geklärt werden:

Neben den fachlichen Skills der einzelnen Mitarbeiter ist es auch wichtig, zu wissen, wie aktuell beziehungsweise neu die verwendete Technologie ist. Ein Softwareprojekt in einer bereits seit Jahrzenten bestehenden Programmiersprache lässt sich einfacher abschätzen als eines in einer, die sich erst seit kurzem auf dem Markt befindet. Hier sind die Informationen, Foren, Libraries, Dokumentation und Co. schlicht und ergreifend nicht in dem gewohnten Maße vorhanden. Das kann in der Entwicklung und Verknüpfung der einzelnen Teilprojekte zum Risikofaktor werden.

Last but not least ist zu prüfen:

Einige denken nun vielleicht: „Wir entwickeln komplett intern, deshalb betrifft uns das nicht.“ Falsch! Third Parties sind nicht nur die offensichtlich externen Dienstleister für ein Projekt, sondern durchaus auch andere Abteilungen innerhalb des Unternehmens. So muss zum Beispiel das Marketing einbezogen werden, wenn es um Styleguides geht, oder die Kern-IT, wenn Anbindungen an Root-Systeme gelegt werden müssen. Darüber hinaus gibt es immer eine höhere Führungsetage, in der weitere Features besprochen werden. Deshalb muss ab einem Tag X immer ein Feature-Freeze gelten. Ab diesem Tag werden keine weiteren Features mehr in das neue Produkt aufgenommen. Deshalb ist zu prüfen, wer alles bei Entscheidungen oder Anbindung des neuen Systems involviert ist. Je mehr Treffer es hier gibt, desto risikoreicher wird es, weil diese Personen in der Regel eine eigene Agenda haben, nach der sie arbeiten und eigene Themen auf dem Tisch liegen haben. Deshalb ist es wichtig, sie frühzeitig mit dem Vorhaben zu kontaktieren und Termine festzulegen, bis wann etwas erledigt/geprüft werden muss. Eine offene und freundliche Kommunikation der eigenen Interessen mit guten Pufferzeiten kann hier Wunder bewirken.

Die Risikoanalyse und Identifikation erfordert also eine Vielzahl an fachlichen, aber auch menschlichen Fähigkeiten. Dazu kommt ein hohes Maß an Organisationsfähigkeit. Die genannten Fragen sind selbstverständlich nicht abschließend, stellen aber eine gute Grundlage dar, um das Thema praktisch anzugehen.