02, Risiko-Controlling

Risiko-Controlling: Risiken in Software-Projekten in den Griff bekommen (Teil 1)


Softwareprojekte sind für Unternehmen zumeist mit einem nicht unerheblichen Einsatz von Ressourcen verbunden; ferner erfordern sie aufgrund ihrer einmaligen und komplexen Aufgabenstellung im Regelfall den Umgang mit Risiken. Umso wichtiger ist es daher, derartige Risiken im Rahmen eines Risiko-Controllings rechtzeitig zu erkennen und zu bewältigen, um dadurch nicht eine eigentlich erfolgreiche Unternehmensentwicklung in Mitleidenschaft zu ziehen.

Warum Risikomanagement im Software Life Cycle?

Risiko-Controlling als führungsunterstützende Instanz kann die zur Steuerung bzw. Beeinflussung von Risiken nötige Informationsbasis liefern. Risikomanagement gehört in immer mehr Unternehmen aufgrund zunehmender Markt- und Wettbewerbsdynamiken sowie dem „Domino-Effekt” – ein ausgelöstes und nicht richtig bekämpftes Risiko löst weitere Risikoeffekte aus – mittlerweile mit zum Planungsalltag. Das Management von Risiken als solches besteht ganz allgemein aus der Identifikation, Analyse und Bekämpfung von Risiken – Letzteres natürlich unter Planung entsprechender Maßnahmen und Überprüfung von deren Auswirkungen.

Der fachtypische Software-Lebenszyklus (Software Life Cycle) beginnt mit der Entstehung eines softwaretechnisch zu lösenden Problems. Die nachfolgenden Teilschritte Analyse, Entwurf bzw. Softwareentwicklung i.e.S. sind abgeschlossen mit der eigentlichen Implementierung in die bereits vorhandenen Systeme. Auf umfangreiche Tests und die Einführung folgt der produktive Einsatz der Software, kombiniert mit Pflege-, Wartungs- und Erweiterungsarbeiten – also dem Beheben von Fehlern, dem Anpassen der Softwareumgebung an veränderte Bedingungen oder der Erweiterung um neue Funktionen. Am Ende des Lebenszyklus steht schließlich die Ersetzung der Software durch ein Nachfolgeprodukt.

 

 
Ein solcher Software Life Cycle ist auf allen Entwicklungsstufen gefährdet durch spezifische Softwarerisiken unterschiedlicher Art, Ausprägung sowie Auswirkung auf das Unternehmensgeschehen:

  1. Direkte Projektrisiken mit negativen Konsequenzen für den Projektzeitplan, die weitere Vorgehensweise sowie die Projektressourcen (u.a. Fluktuation projektbeteiligter Mitarbeiter).
    ——
  2. Direkte/indirekte Produktrisiken mit Auswirkungen auf die Softwarequalität der Neuentwicklungen sowie deren Leistungsfähigkeit (zum Beispiel unbefriedigende Performance).
    ——
  3. Wirtschaftliche Risiken mit unerwünschten Folgen für das eigene Unternehmen oder – sofern Auftragsentwicklung, z.B. Softwarehaus – den eigentlichen Auftraggeber (u.a. fehlende Unterstützung wichtiger Unternehmensprozesse).

 
Einzelne Risikoelemente dieser drei Risikokategorien können beispielsweise sein:

  • Von Anfang an unrealistische Zeit- und Kostenplanungen sowie grundsätzlich stark begrenzte finanzielle Mittel, d.h. wenig Spielraum für Anpassungen bzw. Veränderungen.
    ——
  • Hohe Fluktuation des projektbeteiligten Personals und für das spezifische Projekt ungenügend vorhandenes Mitarbeiter-Knowhow.
    ——
  • „Overengineering” bei vergleichsweise eher weniger wichtigen Softwarefunktionalitäten, im Umkehrschluss zu wenig Ressourcen für wirklich bedeutende Funktionen.
    ——
  • „Setzen auf das falsche Pferd”: Implementierung komplett unbenötigter Eigenschaften sowie keine Entwicklung einer auf die Anforderungen der Endanwender ausgerichteten Benutzeroberfläche.
    ——
  • Extern zugekaufte Teilleistungen passen und harmonieren nicht im Betrachtungswinkel der gesamten Softwareumgebung.
    ——
  • Im Zeitverlauf über die Entwicklungsphasen wird keine klare Linie verfolgt, sondern es gibt ständig neue und wechselnde Wünsche nach Funktionen; die an die Software gestellten Anforderungen werden kontinuierlich verändert: Das fertige Software-Resultat ist „weder Fisch noch Fleisch”.
    ——
  • Im Produktiveinsatz stellt sich schnell heraus, dass mit wachsendem Nutzerstamm Einbrüche hinsichtlich der Echtzeitleistung bzw. Performance einhergehen: Es können in der Folge nicht alle Funktionen effektiv und effizient genutzt werden, die Nutzenvorteile sind eingeschränkt.

 
Ableitend von diesen Risikoelementen muss es daher das Grundanliegen des Risikomanagements in Softwareprojekten sein, Risikofaktoren bzw. mit hohem Risiko behaftete Bereiche bei der Softwareentwicklung rechtzeitig zu bestimmen – bevor sie zur Gefahr für einen erfolgreichen Softwareeinsatz mutieren oder Hauptquelle für zeit- und kostenintensive Überarbeitungen sind. Je nach Anwendungsfall werden entsprechende Maßnahmen zur Risikoabsicherung, dem Ausbau von Ressourcen oder der direkten Änderung des Softwareprototypes erforderlich.

 

Grundvoraussetzungen für erfolgreiches Risikomanagement

 
a) Kontinuierliche Anwendung
Eine lediglich einmalige Identifikation von Projektrisiken am Projektanfang und dann darauf aufbauende Risikobekämpfung sind sicherlich nicht ausreichend. Gerade zu Beginn der meisten (Software-)Projekte wird es noch nicht möglich sein, sämtliche potentiellen Risiken zu benennen und konkret einzuschätzen. Stattdessen ergeben sich erst im weiteren Projektverlauf bislang noch nicht „auf dem Schirm gehabte” Risikofaktoren, andere bereits bekannte verändern sich wiederum.

Deshalb ist es im Sinne eines optimalen Risiko-Controllings notwendig, die einzelnen Prozessphasen (Identifikation, Analyse, Gegenmaßnahmen, Monitoring der Risikoelemente) kontinuierlich zu durchlaufen – und dabei die Erkenntnisse aus vorherigen Durchläufen stetig auf noch vorhandene Richtigkeit bzw. Plausibilität zu prüfen sowie nötigenfalls Korrekturmaßnahmen vorzunehmen.

Sofern in zumindest monatlichen Abständen das (erfolgreiche) Vorankommen bei der Risikoeindämmung kontrolliert und bereits bekannte genauso wie neu identifizierte Risiken gleichermaßen weiter analysiert werden, sollte man sich bei der Betrachtung zudem nicht nur auf das eine Software-Projekt beschränken. Denn nicht selten handelt es sich bei den erkannten Risikoelementen um projektübergreifende Faktoren, welche sich ebenso auf andere Projektentwicklungen negativ auswirken können.

 
b) Offene Kommunikationskultur
Für die letztgenannte Analyse hinsichtlich der gegebenenfalls projektübergreifenden Gestalt der Risiken, dürfen diese zudem nicht ausschließlich in einem kleinen Team oder einem singulären Projekt diskutiert werden. Stattdessen ist eine im Unternehmen gelebte, offene Kommunikationskultur anzustreben, d.h. Diskussionen im Rahmen des Risikomanagementprozesses für eine Projektmaßnahme sind auszuweiten auch auf vorgesetzte und benachbarte Funktionen bzw. Bereiche. Es versteht sich in diesem Zusammenhang desweiteren von selbst, dass sich unternehmensintern Niemand vor beruflichen Konsequenzen oder Ähnlichem zu fürchten braucht, sofern er erkannte Risiken an die dafür zuständigen Stellen meldet.

 
c) Vollständige Integration
Während der gesamten Laufzeit des Softwareprojektes muss Risikomanagement zu guter Letzt als vollwertiger Bestandteil der Entwicklungsprozesse implementiert sein – auf sämtlichen zeitlichen wie sachlichen Ebenen. Um das Ziel einer vollständigen Integration zu erreichen, ist es daher nicht minder wichtig, das direkt im Softwareprojekt involvierte Team im Rahmen der Risikoanalyse und -überwachung umfassend „mit ins Boot zu holen”. Dies beinhaltet ebenso eine klare Festlegung der Verantwortlichkeiten und der Kompetenzspielräume aller Beteiligten.

 
Sind die Grundvoraussetzungen für erfolgreiches Risikomanagement geschaffen, kann der vierstufige Risikomanagementprozess (Risiken identifizieren, analysieren, mit Gegenmaßnahmen bekämpfen, überwachen) in Gang gesetzt werden.

 
Fortsetzung:
Risiko-Controlling: Risiken in Softwareprojekten in den Griff bekommen (Teil 2)
In Teil 2 zum Risiko-Controlling in Softwareprojekten werden insbesondere die einzelnen Phasen eines solchen Risikomanagementprozesses, sowie das damit verbundene, eigentliche Risiko-Controlling bzw. -Monitoring behandelt.

Top