Wie schon in dem Beitrag „Warum scheitern IT-Projekte“ geschrieben, ist das größte Problem von IT Projekten das falsche bewerten von Risiken oder gar das Ignorieren dieser.Für jedes IT-Projekt (Das gilt übrigens auch für nicht IT-Projekte) sollte vor dem Beginn sich jeder hinsetzen und sich mögliche Risiken überlegen, welche das Projekt zum Scheitern bringen oder behindern könnten. Ich möchte euch mit diesem Beitrag einen Leitfaden mitgeben, welche Risiken bei quasi jedem IT-Projekt vorhanden sind und wobei es in der IT zu falschen Bewertungen kommt.
Identifikation von Risiken
Beginnen wir zunächst mit der Identifikation von Risiken. Folgende Projekt-Bereiche sollten dabei jedes Mal durchdacht und näher betrachtet werden:
Projektleiter
Die Projektleiter bei Auftraggeber und Auftragnehmer sind häufig Schlüsselpositionen für ein Projekt. Sollten diese Personen für ein Projekt Wegbrechen oder vielleicht nicht die notwendige Motivation mitbringen kann das enorme Auswirkungen auf die zeitliche Schiene eines Projektes haben. Denn die Kommunikation wird beeinträchtigt, sollte der Projektleiter zum Beispiel nur einmal die Woche auf Fragen antworten. Versucht deswegen, dass die Projektleiter immer nur mit einem Projekt primär beschäftigt sind und dafür die Verantwortung tragen. Das nimmt auch die offene Frage nach Priorisierung der Projekte für den Projektleiter weg.
Mitarbeiter
Ein großer Risiko-Faktor sind die Mitarbeiter innerhalb von IT-Projekten. Die Mitarbeiter sind die eingesetzte Ressource für ein IT-Projekt. Wenn diese nicht richtig funktioniert oder gar nicht zur Verfügung steht, kommt das Projekt gar keinen Schritt vorwärts. Gründe dafür können sein: Krankheit, fehlende Motivation, Kündigung neue Mitarbeiter (zusätzliche Einarbeitungszeit), fehlendes fachliches Know how (Dadurch entstehende Fehler in der Umsetzung) u.v.m. Versucht also eure Mitarbeiter-Ressource immer optimal zu pflegen und auch vorzubereiten. Denn, wenn dieses Rädchen gut geölt funktioniert müsst ihr euch auf jeden fall viel weniger Sorgen um die Umsetzung eines Projektes machen.
Budget
Auch in Bezug auf Budgets bestehen Risiken. Gerade in Konzernen kommt es durch sogenannte „Sparrunde“ immer wieder zu erheblichen Probleme bei Projekten. Ressourcen müssen umgeplant werden, gesteckte Ziele müssen neu formuliert werden und gerade in der Software-Entwicklung treibt dies den Planungs- und Steuerungsaufwand enorm in die Höhe. Häufig habe ich sogar die Erfahrung gemacht, dass ein Projekt durch die mehrfache Neu-Planung und Steuerung am Ende mehr Budget gekostet hat, als wenn man es einfach bei der ursprünglichen Planung belassen hätte. Tipp also an alle Budget-Verantwortlichen: Sich vorher Gedanken machen, ob eine Sparrunde, wirklich den gewünschten Erfolg bringt.
Zeit
Besonders bei der Zeit bestehen extreme Risiken. Ich finde es immer wieder erschreckend, wie knapp IT-Projekte berechnet werden, was die Zeit angeht. Häufig höre ich den Satz: „Das schaffen wir schon“ …… Wenn dieser Satz fällt, wurde das Projekt nur im „Best Case“ betrachtet. Ich gebe euch die klare Empfehlung bei der Zeitplanung immer nach dem Worst Case Szenario zu rechnen und dieses auch zu kommunizieren. Das man pünktlich abliefert, muss man erwarten können als Auftraggeber und für den Auftragnehmer ist es besser „früher“ fertig zu sein, als nachher zu sagen: Es verzögert sich. Kommuniziert von Anfang an realistische Zeitpläne. Auch muss hier nochmal eine Sache erwähnen: Den Zeitplan gibt immer der Auftragnehmer vor, denn nur dieser kann einschätzen wie lange er für die Anforderungen mit den zur Verfügung stehenden Ressourcen benötigt. Zeitpläne, welche durch den Auftraggeber vorgegeben und im schlimmsten Fall auch kommuniziert worden ist eines der schlimmsten Fehler für IT-Projekte!
Faktor X
Der Faktor X ist das größte Risiko. Denn diesen kann man nicht vorhersehen oder gar vorab minimieren. Denn eines muss jedem beim Risikomanagement bewusst sein: Ein Risiko, welches vorher nicht erkannt wurde, hat meistens die größten Auswirkungen. Es sind Dinge, die man für unvorstellbar hält und doch denkt man sich im Nachhinein: Darauf hätte ich vorher kommen müssen. Am besten kann der Faktor X nur durch Erfahrung minimiert werden. Basierend auf vergangene Projekte in denen Dinge passiert sind, die man vorher nicht bedacht hat. Nur das lässt den Faktor X minimieren. Ich kann an dieser Stelle nur jedem empfehlen, bei der Planung für den Faktor X ein wenig Puffer überall einzurechnen: Ein wenig mehr Budget, etwas mehr Zeit je Task einrechnen und auch immer damit rechnen, dass bei jedem Teilnehmer eines Projektes mal etwas unvorhergesehenes passiert. Wenn ihr das macht, habt ihr wenigstens die Chance auf den Faktor X zu reagieren. Wenn alles immer auf Kante geplant ist, wird es euch irgendwann aus der Bahn werfen und dein Projekt wird niemals sein Ziel erreichen.
Bewertung von Risiken
Gehen wir nun auf die Bewertung selbst ein. Wie bewerte ich ein Risiko, nachdem ich es identifiziert habe?
Die Bewertung eines Risikos sollte immer der Verantwortliche vornehmen. Meistens sollte dieser sich die Eintrittswahrscheinlichkeit von seinen Programmierern abholen. Tipp an die Programmierer: Seid ehrlich! Nur mit größtmöglicher Transparenz kann etwas anständig bewertet werden. Und es nicht schlimm, wenn ihr Gefahren / Risiken erkennt. Denn erst, wenn ihr diese offene kommuniziert kann darauf reagiert werden und niemand verliert sein Gesicht.
Andersherum gilt natürlich an die Projektleiter der Appell: Nehmt die Aussagen eurer Programmierer ernst. Fragt vor allem alle beteiligten und nicht nur die zwei „erfahrensten“, erstaunlich oft habe ich es erlebt, dass die „neuen“ im Projekt die Risiken am besten sehen. Vermutlich liegt dies an dem frischen und objektiven Blick auf das Projekt.
Welche Einteilung oder Skala ihr bei der Bewertung von Risiken verwendet obliegt euch. Ich versuche es hierbei meistens „einfach“ und dafür klar zu halten: Schwer (rot), mittel (orange), leicht (gelb).
Wenn ein Risiko mit „rot“ bewertet wird, versuche ich alles mögliche um das Risiko verschwinden zu lassen. Zudem kommuniziere ich an alle Teilnehmer so häufig wie möglich, dass das Risiko weiterhin besteht. Ein Beispiel dafür ist zum Beispiel eine fehlende Zulieferung oder Freigabe von zum Beispiel dem Datenschutz. Ohne diese Dinge kann ein Projekt einfach komplett scheitern und ist somit als „rot“ gekennzeichnet.
Ein mittleres Risiko ist für mich meistens beim Ausfall von Mitarbeitern zu finden. Diese Ausfälle können mit Überstunden oder weiteren Programmierern intern abgefangen werden ohne das viel passiert. Dennoch muss einem immer bewusst sein, wenn Ressourcen ausfallen kann auch dies das Projekt scheitern lassen. Meistens in Bezug auf den Zeitplan. Deswegen mein Tipp an dieser Stelle: Wenn ein Mitarbeiter von euch krank ist und zum Beispiel eine Woche ausfällt, dann erzählt eurem Auftraggeber davon. Dann ist er nicht überrascht, wenn ihr irgendwann anruft und Bescheid geben müsst, dass der Zeitplan nicht mehr zu halten ist aufgrund von Krankheitsausfällen, denn dafür kann niemand etwas!
Risiken mit der Bewertung „gelb“ sind die häufigsten. Denn alles möglich beinhaltet ein kleines Risiko: Eine API funktioniert nicht wie gewünscht, der Code hat Bugs, irgendein Gerät funktioniert nicht wie erwartet usw. Diese Dinge sind meistens sehr einfach zu lösen durch „einfache Funktionstests“ vor Projekt oder Aufgabenstart. Dennoch dürfen diese Dinge nicht ignoriert werden und gehören vielmehr zu Fleißaufgaben, welche aber gemacht werden müssen.