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 fachlichen Risiken ein.
Ziele / Scope
Beschreibung: Ziele und Scope aus fachlicher Sicht ist die Inhaltliche Grundlage für das Projekt und hat Auswirkungen auf alle Bereiche. Angefangen bei den fachlichen Themen selbst. Fachliche Ziele haben aber auch Auswirkungen auf technische und Organisatorische Themen wie Zeit und Teilnehmende und schliesslich auch kommerzielle Auswirkungen
Vorgehen: Ständiges prüfen der Ziele und des Scopes aus fachlicher 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. Wissensträger können aus allen Ebenen sein. Hier die fachlichen Teilnehmenden. Aus fachlicher Sicht werden die richtigen Teilnehmenden benötigt, um zu der richtigen Zeit im Projekt die notwendigen Anforderungen zu formulieren, oder gemeinsam eine Vorgehensweise und Lösung zu erarbeiten, oder zu testen. Es ist fast nie eine Lineare Planung pro Rolle und Wissensträger, wenn Teilnehmende nicht viele Rollen im Projekt ausfüllen können.
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.
Anforderungen sind klar
Beschreibung: In dieser Vorgehensweise werden zuerst die IST-Prozesse aufgenommen, dann die Soll-Prozesse beschrieben, bevor sie in eine Systemumgebung übersetzt und dann im Detail umgesetzt werden können. Jeder Schritt ist ein weiterer Detaillierungsgrad. Es ist oft sehr schwer die genaue Detaillierung in den Ebenen zu finden. Wichtig ist aber, dass sie in den Ebenen klar formuliert und allen bewusst sind.
Vorgehen: Begleitung und ständiges prüfen der Durchgängigkeit der Anforderungen und Detaillierungsgrad in jeder Prozess-Phase.
Komplexität
Beschreibung: Fachliche Komplexität wird oft heruntergespielt. Eine Anforderung, die schwer oder fast gar nicht formuliert werden kann, kann noch schwerer oder fast gar nicht realisiert werden. Und wenn sie realisiert werden kann, dann mit einem oft unverhältnismässigen Aufwand.
Vorgehen: Sind die Anforderungen (egal in welcher Prozess-Phase) schwer oder fast gar nicht formulierbar, sollten sie durch einfachere Prozess Schritte oder Funktionen ersetzt werden. Eine Entscheidung, dass es später noch ausgearbeitet wird, ist oft ein Trugschluss, wenn die Anforderungen nicht klar benannt werden können. Daher sollten solche Anforderungen frühzeitig identifiziert und thematisiert werden.