Jede Veränderung, die mit einem Softwareprojekt durchgeführt wird, birgt auch immer gewisse Risiken, die bekannt, bewusst und aktiv betrachtet und nachverfolgt werden müssen. Risiken können kleine Informationen bis grosse Auswirkungen sein.
Risiken können in Gruppen aufgeteilt werden, weil sie unterschiedlich betrachtet und bearbeitet werden müssen. Sie können mit einem Status wie im Bild farblich hervorgehoben werden. Heute gehe ich auf die technischen Risiken ein.
Ziele / Scope
Beschreibung: Ziele und Scope aus technischer Sicht haben Auswirkungen auf die Lösung und somit das Ergebnis des Projekts.
Vorgehen: Ständiges prüfen der Ziele und des Scopes aus technischer Sicht und bei Abweichungen frühzeitig erkennen, um Gegenmassnahmen starten zu können.
Richtige Teilnehmende
Beschreibung: In jedem Projekt benötigt es unterschiedliche Wissensträger, die auch zu unterschiedlicher Zeit unterschiedlich stark benötigt werden (Siehe hierzu das Kapitel Teilnehmende). Wissensträger können aus allen Ebenen sein. Hier die technischen Teilnehmenden. Aus technischer Sicht werden die richtigen Teilnehmenden benötigt, um zu der richtigen Zeit im Projekt die notwendigen Lösungsansätze technisch zu formulieren, oder gemeinsam eine Vorgehensweise und Lösung zu erarbeiten und später werden die richtigen technischen Teilnehmenden für die Umsetzung benötigt. Es ist fast nie eine Lineare Planung im Projekt pro Rolle und Wissensträger
Vorgehen: In der Planung und später im Projekt muss immer wieder überprüft werden, ob die richtigen Wissensträger zur richtigen Zeit im Projekt sind und bei erkannten Missständen sollte sofort reagiert werden. Ist jemand zu viel im Projekt und bietet keinen Mehrwert (auch nicht zur Wissenserweiterung für später), sollte die Person aus dem Projekt – wenn auch temporär -herausgenommen werden. Wenn es Wissensträger benötigt, die aktuell nicht im Projekt sind, müssen sie schnellstmöglich versucht werden dem Projekt zu ergänzen.
Systembereitschaft / Systemarchitektur
Beschreibung: Das System selbst sollte ab der Zeit der Übersetzung in Soll-Prozesse bekannt oder sogar schon bereitstehen und über das gesamte weitere Projekt verfügbar sein. Weiter muss die Arbeitsweise am System allen bewusst sein. Hierzu sollte es Umsetzungs- und/oder Entwicklungs-Regeln geben und die Systemarchitektur und der Transport von Anpassungen und Daten zwischen Systemen (Entwicklung zu Test zu Produktiv etc.) muss allen bewusst sein.
Vorgehen: Periodisches Prüfen der Systembereitschaft, Einhaltung der Umsetzungs-Regeln, Systemarchitektur und dem Transport zwischen den Systemen. Auffälligkeiten frühzeitig versuchen zu erkennen, um Gegenmassnahmen starten zu können.
Komplexität
Beschreibung: Technische Komplexität kann zu grossen Zusatzkosten oder Projektverzug führen, daher ist es wichtig, neben der fachlichen Komplexität auch die technische aktiv nachzuverfolgen. Es können reine Nutzungs-komplexitäten entstehen, aber auch sehr viel Logik im Hintergrund, die dann zu einer längeren Wartezeit führt, oder später nicht mehr nachvollziehbar und sehr Aufwändig in der Administration macht.
Vorgehen: Gibt es komplexe fachliche Anforderungen müssen diese technisch geprüft werden und der Aufwand gegen den Nutzen verglichen werden. Hier baucht es Zeitnahe Entscheidungen, da selbst die Planung von komplexen Themen negative Auswirkungen auf die Zeit und Budget-Situation haben kann.