Ich arbeite seit fast 20 Jahren in der Softwareentwicklung und den überwiegenden Teil habe ich die Rolle des Projektleiters ausgeführt. Zuletzt hat mich ein CTO eines IT-Dienstleisters gefragt: „sag doch mal, was ist deine Definition von guten Softwareprojekten, auf was muss ich achten, damit ich das Projektvorhaben nicht gleich nach 3 Monaten wieder einstellen muss“.
Ich habe ihm in einer eMail kurz knapp meine Gedanken formuliert und dass zum Anlass genommen mit diesem Blog das Thema etwas ausführlicher zu beschreiben.
Alle die in IT-Organisationen arbeiten oder mit IT-Abteilung aus einer Businessbeziehung heraus zusammenarbeiten, wissen, es gibt gute und es gibt schlechte IT Projekte.
Je nachdem wen wir in der Organisation fragen, hat das Management eine andere Wahrnehmung als vielleicht die Betriebsführung, oder die Entwickler, die Tester und am wichtigsten: Unsere Kunden. Wir alle haben keine Lust auf schlechte Projekte – weder als Projektbetroffene noch als Projektbeteiligte und schon gar nicht unsere Kunden, die am Ende unsere Produkte nutzen.
Was ist die Ursache dessen und wie können wir sicherstellen, dass wir ein gutes IT-Projekt haben?
Auf Basis derer habe ich mit dem Fokus auf den Projekt-Erfolg eine Klassifizierung erstellt, die die für mich wichtigsten Erfolgs-Faktoren sind.
Zu Beginn eines Projektes ist es wichtig, festzulegen, welche Rolle wofür verantwortlich ist.
Es muss klar sein, wer sind die Ansprechpartner und wer stimmt sich frühzeitig aus dem Projektteam mit diesem Ansprechpartner ab, wer ist innerhalb des Projektteams für welche Aufgaben verantwortlich.
Um die Verantwortlichkeiten zu dokumentieren, ist eine erprobte und gängige Praxis die Erstellung einer RACI Matrix, die ich gerne noch um ein S&O (support & ommited) erweitere.
Hierbei wird je Stakeholder und Projekt-Rolle festgelegt, wer ist für einzelne Aufgaben „Responable“, wer „Accountable“, wer „supportet“ den Responsable bei der Umsetzung der Aufgabe. Wer ist als „Consultant“ einzubinden, wer muss „Informed“ werden und wichtig, wer ist „Omitted“, also explizit von einer Aufgabe ausgeschlossen.
Diese RASCIO Matrix sollte zu Beginn des Projektes nach innen und außen kommuniziert und kontinuierlich aktualisiert werden. Sie dient allen betroffenen und beteiligten Projektmitgliedern als Orientierung. In einem Projekt kann es anstrengend sein ständig die Frage zu klären, wer für was verantwortlich ist.
Hierdurch entsteht erstmal ein Aufwand, um diese Verantwortungen festzulegen.
Dieser Aufwand lohnt sich und macht sich in jedem Projekt bezahlt, da für alle Stakeholder Klarheit herrscht, weniger Konflikte entstehen und dadurch deutlich weniger Eskalations-Kommunikationen notwendig werden.
In vielen Projekten habe ich festgestellt, dass es innerhalb einer Organisation, in welchem Bereich auch immer, für einige Aufgaben expliziten Ansprechpartner gibt oder die aus Projektsicht klaren Verantwortlichkeiten sogar gänzlich fehlen.
Das ist ein fundamentales Risiko, was entsprechend durch das Projekt mitigiert werden muss. Hier ist es ratsam, nicht Dinge zu fordern, die für eine Organisation in der Umsetzung unmöglich sind, sondern aus dem Projekt heraus Lösungen zu identifizieren und bei der Umsetzung zu unterstützen.
Zusätzlich zu den Verantwortlichkeiten sollte auch der Entwicklungsprozess des Projektes an das Umfeld angepasst werden.
IT-Projekte finden selten auf der „grünen Wiese“ statt, sondern stehen immer im Kontext mit anderen IT-Entwicklungen z.B. weiterer Projekte die z.B. in großen Transformationen andere IT-Komponenten entwickeln.
In kleinen IT-Transformationen gibt es z.B. Umsysteme die Schnittstellen bereitstellen oder Schnittstellen nutzen, bzw. Daten benötigen oder bereitstellen.
Diese anderen IT-Projekte oder IT-Verfahren haben eigenständige etablierte Release-Zyklen und deployen Ihre Artefakte vielleicht quartalsweise, andere monatlich, wiederum andere wöchentlich.
Es muss also abgestimmt werden, in welchem Deployment-Intervall wer von wem die Schnittstellen und Daten bekommt, sodass z.B. ein gesamthafter Integrationstest stattfinden kann und somit unnötige Wartezeiten vermieden werden.
Unabhängig davon, für welche Art des Projektmanagements sich das Projekt entscheidet, ob agil, hybrid oder Wasserfall, ist die Qualität der zu Grunde liegende IT-Anforderung essenziell für den späteren Erfolg.
Es muss für alle betroffenen und beteiligten Stakeholder im Projektumfeld klar sein, was umgesetzt werden muss, wo die Prioritäten liegen und das möglichst interpretationsfrei.
Wenn alle Stakeholder also nahezu das gleiche Verständnis haben, was das Projekt umsetzen soll, entstehen weniger Missverständnisse, weniger Konflikte.
Das größte Risiko für ein IT-Projekt sind aus meiner Sicht unzufriedene Stakeholder und damit frustrierte Projektmitarbeiter. Klar definierte Anforderungen unterstützen die Projektmitglieder im Erwartungsmanagement ggü. den Stakeholdern, was die Kommunikation des Projektes erleichtert.
Um zu verstehen, was eine IT-Anforderung ist, anbei ein kurzer Exkurs in die unterschiedlichen Arten von IT-Anforderungen:
Alle genannten Anforderungsarten benötigen eine gewisse Qualität eine Eindeutigkeit, damit sie für alle verständlich und planbar werden. Hierzu gibt es unterschiedliche Ansätze, wie eine einheitliche Qualität oder auch ein Reifegrad „Ready to Plan“ oder „Definition of Ready“ erzeugt werden können.
Anforderungen sollten in jedem Falle einer festen Struktur folgen, z.B. unter der Verwendung von Satzschablonen:
Durch die Verwendung von Satzschablonen, werden Anforderungen einheitlich strukturiert. Es wird Kompaktheit erzwungen, Lücken aufgedeckt und Anforderungen dahingehend optimiert, um genau zu beschreiben, was der Kunde wirklich braucht.
Eine zusätzlich gute Methode zur Qualitätssicherung sind die I.N.V.E.S.T. Kriterien.
Eine User Story, welche im agilen Vorgehen eine runtergebrochene Anforderung entspricht. Hier wird ähnlich einer Checkliste überprüft ob eine User Story:
Wenn alle relevanten Anforderungen durch das Projekt zum jeweiligen Zeitpunkt bzw. Entwicklungsintervall erfasst wurden und inhaltlich abgestimmt und qualitätsgesichert sind, müssen die Anforderungen priorisiert werden.
Es kann nicht sein das aus Sicht der fordernden Bereiche alle Anforderungen die gleiche Priorität haben. Diese Diskussion ist mühsam, da anfordernde Bereiche immer das Maximum umsetzen wollen, was aber in den seltensten Fällen in das initial geplante Budget und in den Zeitrahmen passt. Wenn also bei der Projektinitialisierung nicht alle Anforderungen bewertet wurden, muss im Rahmen eines Change Request Prozess die Anforderungen so gegenseitig priorisieren werden, sodass das Projektbudget eingehalten wird oder zusätzliches Budget notwendig wird.
Für ein IT-Projekt ist es wichtig das ausreichend fachliche und technische Kompetenzen zur Verfügung stehen.
Insbesondere das fachliche Domain Wissen, also wie funktioniert der End-to-End-Businessprozess und welche Geschäftsprozesse gibt es? Wer ist daran wie beteiligt?
Wo gab es in der Vergangenheit Probleme, bzw. auf was muss das IT-Projekt besonders achten?
Dieses Wissen, was in jedem Unternehmen unique vorhanden ist oder sein sollte, kann nicht außerhalb des Unternehmens eingekauft werden, da es ja unternehmensspezifisch ist.
Dieses Wissen ist besonders wichtig für die Anpassung oder den Neubau eines IT-Systems.
Diese Experten sind absolut notwendig und müssen einem IT-Projekt im Idealfall zu 100% zur Verfügung stehen, damit das Projekt effizient alle notwendigen funktionalen Anforderungen identifizieren kann.
Anders sieht es bei der technischen Kompetenz aus, welche ebenfalls für den Erfolg eines IT-Projekts wichtig ist. Steht diese technische Kompetenz nicht zur Verfügung, kann das Projekt im Zweifel die notwendigen Kompetenzen auch extern einkaufen.
Selten stehen weder fachliche oder technische Kompetenzen zur Verfügung, sondern es handelt sich um einen Konflikt in der Priorisierung. Die fachlichen und technischen Experten sind vielleicht gleichzeitig in vielen unterschiedlichen Projekt gleichzeitig geplant oder müssen im Daily-Business den Produktionsprozess unterstützen. Die Folge dessen ist, dass dem IT-Projekt diese Experten nur zu 10-20% zur Verfügung stehen. Auch das ist ein massives Risiko und muss mitigiert werden. Auch in diesem Fall muss das Projekt sinnvolle Vorschläge unterbreiten, wie diese Experten so eingesetzt bzw. unterstützt werden, dass das Projekt die notwendige Unterstützung bekommt. Aus meiner Erfahrung heraus, sind das die schwierigsten Risiken, für die es meist keine sinnvolle Mitigation gibt. Aus diesen Risiken folgt oft die Konsequenz, dass das Projekt mehr kostet oder länger oder dauert, was bedacht und akzeptiert werden muss.
Hier ist der Projektleiter und der Product-Owner eines Projektes besonders gefragt, denn im Umfeld eines IT-Projektes redet man gerne über Aufgaben, die irgendwann in der Zukunft erledigt werden müssen, aber nicht jetzt. Also reden wir irgendwann darüber aber eben nicht jetzt.
Von Beginn an ist es notwendig, dass sich das Projekt auf das konzentriert, was für das Projekt zum Zeitpunkt den größten Nutzen für die Organisation oder für den Kunden den größten Wert darstellt.
Ich habe Eingangs über das Thema Anforderungsmanagement gesprochen. Einerseits wollen wir zu Beginn des Projektes wissen, welche und wie viele Anforderungen das Projekt umsetzen muss, damit wir grob einschätzen können wie teuer und wie lange ein Projekt braucht. Auf der anderen Seite macht es zu Beginn eines Projektes keinen Sinn, alle Anforderungen so weit zu detaillieren, dass sie durch ein Entwicklungsteam umgesetzt werden können, wenn diese erst in einem Jahr wichtig werden. Das heißt, ein Projekt konzentriert sich nur auf die Anforderungen im Backlog, die zum jeweiligen Zeitpunkt den größten Nutzen, bzw. den größten Wert haben.
Nach meiner Erfahrung sind aus Sicht einer Organisation Projekte immer unbequem, da diese die existierende Prozesslandschaft verändern. Alle Prozessbeteiligten haben sich über Jahre an den Prozess gewöhnt. Mit Veränderungen tun wir uns alle immer schwer, also muss diese Veränderung moderiert werden. Dazu gibt es unterschiedliche Formate und auch Stakeholdergruppen die wir informieren müssen.
Unabhängig der Vorgehensweise ist es wichtig, dass diese Abstimmungsrunden nicht ausufern und sich die Projektmitglieder in Details verlieren. Egal ob Daily oder Jour-Fixe, die Termine müssen time-boxed stattfinden und jemand muss in die Moderations-Rolle schlüpfen, um der Diskussion Einhalt zu bieten, falls notwendig. Wichtig ist hierbei nicht, time-boxing des time-boxing willen zu praktizieren, sondern, wenn dringende kritische Themen diskutiert werden, zu prüfen, ob der Termin überzogen wird und ob wirklich alle Teilnehmer für die Diskussion notwendig sind. Ggf ist es sinnvoll, einen gesonderten Termin zu organisieren.
Weiterhin sollten man nicht vergessen, immer wieder nach Feedback zu fragen und selbst auch bereit sein, Feedback zu geben. Natürlich immer konstruktiv, denn nur durch Feedback wissen wir, ob wir noch richtig unterwegs sind oder ob es ggf. an unserem Verhalten oder den Arbeitsprozessen Optimierungsbedarf gibt. Die agilen Teams nutzen das SCRUM-Event Retrospektive. Klassische Vorgehensweisen „Lesson Learned“ Veranstaltungen. Leider finden diese in vielen klassischen Projekten erst am Ende des Projektes statt und nicht regelmäßig während der Projektlaufzeit.
Für mich eines der größten Erfolgsgaranten eines IT-Projektes ist, wie ein Projekt kommuniziert. Wenn Projekte beginnen innerhalb des Projektteams gut zu kommunizieren, dann wird es auch außen gut kommunizieren, da jeder Projektmitarbeiter gleichzeitig auch als Multiplikator in die Organisation fungiert.
Kommunikation im Projekt ist ein großes, umfangreiches Arbeitspaket, welches in der Aufwandsbetrachtung des Projektes nicht unterschätz werden soll. Gerade in Projekten, in denen sehr viele Stakeholder mitwirken, ist übergreifende Projektkommunikation inkl. Vorbereitung und Nachbereitung, kapazitär betrachtet, mindestens ein Vollzeitjob.
Ich habe in den vergangenen Jahren immer wieder erlebt, das IT-Projekte gegenüber dem Management kommunizieren, dass sie keine Risiken haben. Bei diesen Projekten werde ich misstrauisch, denn jedes Projekt dieser Welt hat Risiken. Es ist unbequem, dem Management in einem Lenkungskreis „Rede und Antwort“ zu stehen und zu erklären, warum wir denn schon wieder Risiken identifiziert haben. Man neigt in Managementrunden dazu, Risiken kleinzureden und der Projektleiter, der die Risiken mit seinem Projektteam identifiziert hat, bekommt schnell den Stempel, im Panik-Modus zu sein. Ich kann dazu nur raten, wenn es sich wirklich um echte Projektrisiken handelt, in der Sache hart zu bleiben.
Jedoch ist es wichtig, darauf zu achten, dass wir auch nur echte Risiken identifizieren und nicht jedes kleine Problem kommunizieren, nach der Methode „melden macht frei“.
Alle Störeinflüsse die den Erfolg des Projektes in Time, Quality & Budget gefährden, sind per se Risiken. Das Mitarbeiter krank werden können ist aber kein Risiko, da wir keinen Einfluss darauf haben, ob dieses allgemeine Risiko eintritt und welche Auswirkung daraus resultieren.
Wir haben aber die Möglichkeit, ein Risiko zu identifizieren das z.B. Key-Player ausfallen und Mitigationsmaßnahmen identifiziert und umgesetzt werden, sodass z.B. sich entweder die Prioritäten anderer Key-Player im Falle des Ausfalls ändern und diese dem Projekt unmittelbar zur Verfügung stehen oder Key-Player frühzeitig personell so gecovert werden, dass andere kurzfristig übernehmen können.
Bei der Definition, was eigentlich ein echtes Risiko ist, scheiden sich oft die Geister. Ich rate dazu, ein Risiko nachfolgender Schablone zu formulieren.
Mit Hilfe dieser Klassifizierung kann man relativ einfach die Eintrittswahrscheinlichkeit und die Auswirkung des Risikos (hoch, mittel, gering) einstufen. Alle Risiken, die dann die Kombination aus Eintrittswahrscheinlichkeit = hoch und Auswirkung = hoch haben, gelten als Top-Risiken des Projektes.
Wenn, wie in diesem Beispiel das Management nicht bereit ist, den KeyPlayer zu repriorisieren, interne Businessanalysten zu priorisieren und oder das Budget für die zwei externen Business Analysten zu bewilligen, muss sowohl das Projekt, als auch das Management das Risiko akzeptieren. Dies führt dann aber zu einer Neuplanung des Projektes
Proaktives professionelles Projektmanagement ist eine der Kernaufgaben eines Projektleiters. Er muss über die gesamte Projektlaufzeit Risiken frühzeitig antizipieren und entsprechend kommunizieren und Mitigationsmaßnahmen planen und umsetzen.