Häufig ist es mir in Großunternehmen bereits passiert, dass man als externer in ein Projekt kommt, das kurz vor dem Scheitern steht. Das Projekt läuft bereits lange, der Fortschritt ist im einstelligen Prozentbereich und das Geld ist zu 80% weg. Irgendwas ist schief gegangen und irgendwie muss das Projekt nun doch noch gerettet werden. Aber zum Anfang.
Szenario
Ein Projekt zur Einführung von Produkt X in einem großen Finanzkonzern läuft nun bereits seit einem Jahr. Das Projektkoordinationsteam ist intern besetzt, lediglich die verlängerte Werkbank und die Projektleiterin sind Externe. Die Projektleiterin soll natürlich dieses Projekt als Profi auf Kurs halten und ist entsprechend für Zeit, Budget und Qualität verantwortlich. Sie wurde als externer Beraterin ausgewählt, da sie sich mit Produkt X bereits auskennt und eine ältere Version des Produktes bei einem anderen Kunden eingeführt hat. Die Firma für die Umsetzung ist ebenfalls ein Profi auf diesem Gebiet, wird aber aus den Entscheidungen herausgehalten, da es hier um interne Anforderungen geht.
Nun, ein Jahr nach Projektstart, ist die Luft raus. Das Team ist längst nicht mehr auf das eigentliche Projekt fokussiert, sondern Tausend interne Meetings und andere Linientätigkeiten haben den Fokus zerstreut. Und obwohl die Kollegen laut Projektberichten etwa 20 Stunden pro Woche für das Projekt investiert haben, ist der Fortschritt lächerlich gering. Das Konzeptpapier hat einen Fertigstellungsgrad von etwa 40%. Überall fehlt es an Entscheidungen, die irgendjemand treffen muss. Und außerdem gibt es irgendwie niemanden, der so richtig für ein Thema zuständig ist. Da gibt es dieses Infrastruktur-Kapitel, doch die Verantwortliche kann ja gar nicht weiter machen. Es fehlen Zulieferungen von 4 verschiedenen Abteilungen. Diese hat er natürlich angeschrieben, aber es kommt einfach nichts dabei rum.
Ich denke, dies beschreibt eine Situation, die viele Projektmitarbeiter:innen kennen. Hier handelt es sich nicht um ein konkretes Projekt, auf das ich anspiele, sondern ehr um ein prototypisches Szenario, welches ich häufig erlebt habe. Auch die männliche und weibliche Beschreibung wurde zufällig gewählt und dient lediglich der Storyline. Doch was ist eigentlich passiert?
Der Projektverlauf
Das Projekt hat „eigentlich“ ja gut gestartet. Das Team war motiviert und freudig über die neue Aufgabe. Jedes Mitglied hat die Möglichkeiten in seiner Abteilung gesehen und das Prestige, was mit dem erfolgreichen Projektabschluss einher geht. Die Projektleiterin beginnt mit den üblichen Projektinitialisierungsthemen und findet sich langsam in die interne Organisation ihres Teams ein. Erste Aufgaben werden im Projekttool, sagen wir Jira, definiert und den entsprechenden Projektmitgliedern zugewiesen.
Die Mitglieder haben zwar von ihrem jeweiligen Themenbereich eine konkrete Vorstellung – z.B. Infrastruktur, Marketing, interne Kommunikation – aber sie kennen die Technologie noch nicht. So finden erste Sondierungsmeetings mit der „verlängerten Werkbank“ statt und es werden Youtube-Videos konsultiert. Maßstab ist dabei das Vertraute, dass die Kolleg:innen bereits kennen, angereichert um die Werbeversprechen, die von den Berater:innen und Videos kommen. Die Projektleiterin ist zu diesem Zeitpunkt noch damit beschäftigt einen ersten Projektplan zu entwickeln, die JIRA-Tasks aufzubauen und das Team in Meetings kennenzulernen. So vergeht der erste Monat ohne sichtbares Ergebnis, aber mit jeder Menge Ideen und dem Gefühl hier einen großen Fortschritt zu erzielen.
In der nächsten Etappe werden die Ideen vorgestellt. Doch schnell wird klar, die die unterschiedlichen Themenbereiche nicht miteinander zusammenpassen. Die Idee der internen Kommunikation geht der IT zu weit, die bei dieser Gelegenheit gleich in vorauseilendem Gehorsam den Datenschutz und Betriebsrat ins Gespräch bringt, ohne, dass dieser überhaupt schon von diesem Projekt weiß. Hier muss zunächst einmal eine Anfrage gestellt werden. Das Marketing muss außerdem noch den Styleguide vorlegen. Doch damit dies funktioniert, benötigen die erst einmal eine Aufstellung welche Elemente überhaupt benötigt werden, und so weiter. Das Gefühl des Anfangs verpufft langsam und die Projektteilnehmer ziehen sich in ihre Silos zurück. Natürlich ist jeder bereit seinen Teil zu liefern, wenn denn die anderen zunächst einmal XY bereitstellen. Die Projektleiterin notiert nun die einzelnen Pakete, welche von den Fachabteilungen identifiziert wird. Die Ideen werden im Jira erfasst, jedoch ohne konkret ausdefiniert zu werden. Keiner der fachlichen Spezialisten will zu sehr ins Detail gehen, aus Angst, hier etwas aufzuschreiben, dass sich später als Fehler herausstellt. Schließlich gibt es dafür noch gar nicht genug Fachwissen in der Technologie. Stattdessen werden Anforderungen an andere Abteilungen genannt, auf die man wartet. Diese jedoch finden nur selten Einzug in das jeweilige Jira-Ticket. Schließlich will man an dieser Stelle kein Fingerpointing betreiben. So vergeht der zweite Monat. Es werden viele Metainformationen zum Projekt generiert, doch wenig, was wirklich auf den Fortschritt einzahlt. Das Projekt verliert an Schwung.
Die nächste Etappe steigert dieses Gefühl noch. Immer mehr Meetings zwischen den einzelnen Projekteilnehmer:innen, sowie zwischen dem Projekt und anderen Stellen fressen die Motivation auf. Das Projekt fühlt sich immer mehr nach Grabenkrieg an. Jedes Detail muss erst diskutiert werden. Die Projektleiterin merkt, dass sich der Fortschritt verzögert und meldet dies ordnungsgemäß im Steering Meeting an. Um das Projekt zu beschleunigen und die Teilprojekte zu entlasten werden weitere Spezialisten hinzugezogen. Die Infrastruktur wird nun nicht nur durch den Spezialisten der alten Lösung betreut, sondern auch noch durch eine Expertin für ein verwandtes Thema. Wenn man schon die neue Lösung einführt, könnte man ja diesen Nebenkriegsschauplatz auch gleich mit erledigen und dadurch Synergieeffekte nutzen, so die Überlegung. Die beiden Spezialist:innen sind sich einig, das Konzept kann nur sinnvoll fertiggestellt werden, wenn die verlängerte Werkbank einen echten externen Spezialisten stellt, der Antworten auf die Detailfragen kennt. Dies wird genehmigt und künftig kümmert sich also der externe Spezialist darum, wie das mit der Authentifizierung auf dem iPad des Vorstands sinnvoll abgebildet werden kann. Auch die anderen Teilprojekte gewinnen so immer mehr an Komplexität. Es entstehen Dokumente und Lösungen für einzelne Aspekte. Die Projektleiterin gewinnt den Eindruck, dass das Projekt an Fahrt aufnimmt. Doch die eigentliche Kernaufgabe gerät aus dem Fokus und die Details zahlen nur wenig darauf ein. So vergehen die nächsten Monate und das Budget wird immer weiter aufgebraucht. Da aber der Fortschritt in den Detailfragen sichtbar ist und auch in den Steering Meetings berichtet wird, fällt dies zunächst keinem auf. Es ist zwar spürbar, dass das ganze Projekt nicht so einfach ist, wie ursprünglich erwartet, aber das war ja ohnehin irgendwie klar. Die Statusampeln bleiben auf Grün.
Schließlich nähert sich das Projekt früher oder später einem wichtigen Meilenstein, der am Anfang gesetzt wurde und bei dem nun ein konkretes Ergebnis erwartet wird. Beispielsweise das fertige Konzept. Erst jetzt wird wirklich deutlich, dass der Projektfortschritt schon vor einiger Zeit ins Stocken geraten ist. Es gibt wenige oder keine Tickets im Jira mehr, die auf das eigentliche Ziel einzahlen. Stattdessen ist die Issue-Liste immer weiter gewachsen und die Themen wurden behoben. Irgendjemand stellt die Frage, was eigentlich mit dem Styleguide passiert ist, der am Anfang angefragt wurde. Diese Aufgabe wurde nirgendwo wirklich dokumentiert, sondern ist im „Arbeitsgedächtnis“ zwischen der internen Kommunikation und Marketing abgelegt. Es muss auf jeden Fall hier noch etwas passieren, aber niemand löst den Zirkelschluss zwischen fehlendem Guide und fehlenden Modulen auf, die jeweils auf den anderen referenzieren. Stattdessen haben sich die Beteiligten auf andere Aufgaben gestürzt. Und die waren ja auch wichtig und schließlich wurden sie auch in den Projektmeetings regelmäßig besprochen und von der Projektleitung und sogar dem Steering abgenickt. Nur leider haben diese nicht in relevantem Maß auf den Fortschritt eingezahlt, sondern sich in Details verloren. Ein Bild, das sich so oder ähnlich auch in den anderen Bereichen abzeichnet. Der Fachbereich Infrastruktur wartet noch immer auf ein Feedback vom Datenschutz, was sie ja schon vor Wochen angefragt hatten. Doch diese wissen von nichts. Eine Dokumentation dieses Vorfalls existiert nicht so richtig. Nur eine E-Mail, in der vage nach dem Stand gefragt wird, doch hier war der Datenschutz ja nur auf CC. Die Situation ist verfahren, das Projekt steckt fest. Die Stimmung ist auf dem Nullpunkt.
An dieser Stelle verlieren sich die Gemeinsamkeiten der Projekte. Das Projekt steht auf Eskalation, das Budget ist bereits empfindlich belastet und der Fortschritt steht hierzu in keiner Relation. Einige Projekte versuchen nun die Timeline anzupassen, um über den Faktor Zeit den Rückstand wieder gutzumachen. Externe werden freigestellt und das interne Budget wird großzügig ignoriert. Doch es wird keine grundsätzliche Reorganisation des Projektes vorgenommen. Stattdessen werden die aufgefallen Probleme einfach auf den Workload mit draufgepackt und das Mikromanagement geht weiter. Die Timeline wird immer wieder angepasst und nach der dritten Anpassung wird die Projektleiterin ausgewechselt, um das Problem in den Griff zu bekommen, doch das Projekt ähnelt bereits dem Berliner Flughafen. Andere Projekte ignorieren das Budget komplett und schicken einfach mehr Personen in das Projekt, um durch schiere Arbeitskraft den Projektfortschritt aufzuholen. Das Ergebnis ist häufig noch katastrophaler, denn das Budget verbrennt nun mit atemberaubender Geschwindigkeit und die vielen neuen Meinungen führen nur zu noch mehr Schuldzuweisungen und zu neuen Baustellen. Das Projekt versinkt in Anarchie und kann oft nur durch einen kompletten Abbruch beendet werden. Eine dritte Gruppe versucht den Qualitätsaspekt zu kürzen. Das Problemkind Vorstand wird komplett aus den Anforderungen herausgestrichen und auch das begleitende Schulungskonzept und die Change Management Strategie fallen dem Rotstift zum Opfer. Das Projekt wird in einer sehr reduzierten Version abgeschlossen und das Ergebnis wird nie wirklich eingesetzt oder – was sogar schlimmer ist – sorgt langfristig für massiven Unmut bei allen Beteiligten, die auf die Lösung angewiesen sind.
Doch wie kann man ein Projekt noch retten, wenn man an einem wichtigen Meilenstein feststellt, dass das Projekt komplett aus dem Ruder gelaufen ist? Wenn man merkt, dass man mit 80% des Budgets nur 20% des Ergebnisses fertiggestellt hat? Schauen wir uns dazu zunächst die Kardinalfehler an, die in diesem Beispielprojekt passiert sind.
Problemanalyse und Maßnahmen
Natürlich ist es immer leicht im Nachhinein ein Projekt zu analysieren. Da einige oder alle dieser Probleme aber tatsächlich in fast jedem Projekt, das später eskaliert ist, gemacht wurden, möchte ich darauf eingehen und Schlüsse für die Zukunft ziehen.
Projektmanagement
Die Projektleitung extern zu besetzen halte ich tatsächlich sogar für eine gute Idee. So ist sichergestellt, dass das Projekt nicht durch interne Strukturen und Seilschaften beeinflusst wird. Eine externe Projektleiterin ist nur dem Projekt verantwortlich und muss sich nicht in der Linienorganisation verantworten. Allerdings muss man sich bewusst sein, dass sie auch die Linienorganisation der Projektbeteiligten nicht kennt und darauf keine Rücksicht nimmt. Auch sind ihr dadurch die Fähigkeiten und Erfahrungen der Beteiligten unklar. Hier ist besonders am Anfang eine helfende Hand wichtig. Dies kann einer der Projektbeteiligten sein oder eine Projektassistenz. Diese Stelle muss weder ein Vollzeit noch langfristig sein. Es geht ehr um ein Coaching, wie man es auch für neue festangestellte Mitarbeiter:innen machen würde. So kann die Projektleiterin die weiteren Aufgaben und die Verfügbarkeit der Beteiligten besser planen. Wichtiger ist aber, dass sie dadurch auch Probleme effizient lösen kann. Ein Projektmitglied soll an einem bestimmten Linien-Meeting teilnehmen? Hier kann ggf. ein Gespräch am Kaffeeautomaten helfen die Prioritäten zu klären und unnötige Meetings von den Beteiligten fernhalten.
Hier kommen wir auch direkt zur definierten Verfügbarkeit. Fokus ist eines der wichtigsten Themen in jedem Projekt. Nur wenn eine Mitarbeiter:in sich eine längere Zeitspanne am Stück auf eine Aufgabe konzentrieren kann, wird sie wirklich effizient arbeiten. Hier ist es wichtig alle Störungen fernzuhalten. Sei es ein Anruf, eine E-Mail oder ein Meeting. All das zerstört die Konzentration und sorgt so für unnötige Projektverzögerung. Ist ein Projektmitglied nur für z.B. 50% für ein Projekt verfügbar, so sollte die Projektleitung dafür sorgen, dass diese Verfügbarkeit möglichst in ganzen Blöcken verfügbar ist und in dieser Zeit jede Störung vermieden wird. Dabei sind Blöcke von 2 Stunden als untere Grenze empfehlenswert. Planbare Unterbrechungen sollten ebenso möglichst am Stück stattfinden, um so die Ablenkung möglichst gering zu halten. Häufig ist es auch so, dass Menschen zu einer bestimmten Zeit besser im konzentrierten arbeiten sind. Z.B. am frühen Morgen oder späten Nachmittag. Sofern die Projektmitglieder eine solche Präferenz haben, sollte die Projektleiterin versuchen diese Phasen mit der Projektarbeit zu füllen.
Um das Thema Projektleitung noch einmal zusammenzufassen: Es ist die wichtigste Aufgabe der Projektleitung die Arbeitsfähigkeit des Teams zu gewährleisten. Dafür sollten vor allem Ablenkungen und Störungen von außerhalb des Projektteams dringend vermieden werden. Hier sollte sich die Projektleitung darum bemühen ein allgemeines Verständnis für diese Situation im Umfeld der Projektmitglieder zu schaffen. Diese Fokussierung in der eigentlichen Arbeitszeit kann einen enormen Boost erzeugen. Auch sind es solche Phasen hoher Konzentration, in denen kritische Fragen wie die Abhängigkeitsschleife zwischen den Abteilungen aufgelöst werden können. Dies funktioniert nicht bei einem schnellen Kaffee zwischen zwei Meetings.
Tools und Methoden
Kommen wir zum Thema Planung und Tools. Auch hier ist der erste Ansatz, Jira dafür zu verwenden, genau richtig. Natürlich könnte es auch Azure DevOps oder HP ALM sein. Die Methodik ist entscheidend. Denn sie bietet erheblich mehr Möglichkeiten als das berühmte Gantt-Chart in Project. Außerdem kann aus einer gut gepflegten Liste ebenfalls ein entsprechendes Reporting erzeugt werden, was dazu noch aktuell ist und mehr Details zu den einzelnen Aufgaben bietet. Das Problem liegt hier darin, diese Liste aktuell und aussagekräftig zu halten.
Gerade am Anfang eines Projektes werden die befüllten Listen oft sehr idealistisch betrachtet. Die Arbeitspakete, die zunächst als grobe Vision hinterlegt werden, werden dabei nicht weiter ausspezifiziert. Schließlich weiß man ja was gemeint ist. Auch eine Definition of Done für die Arbeitspakete findet nicht statt. Genauso wenig wie ein herunterbrechen auf einzelne Aufgaben oder das Erfassen von Impediments und Abhängigkeiten. Man hat es ja im Kopf und alle Projektmitglieder ziehen an einem Strang. Das Problem bei dieser Herangehensweise wird beim Beschreiben bereits deutlich. Es ist für Außenstehende und das Projekt Steering nicht erkennbar wo das Projekt eigentlich steht und welche Aufgaben aktuell wirklich in Bearbeitung sind. Ohne das Herunterbrechen auf die Tasks ist auch nicht klar, welche Themen am Anfang wirklich definiert und priorisiert wurden und wobei es sich um Nebenschauplätze handelt. Das Projektmanagement muss nun regelmäßig den „gefühlten Fortschritt“ in den Projektmeetings kommunizieren, anstatt einfach eine Liste zu nehmen mit den Themen die wirklich erledigt wurden und den Aufwänden die wirklich dahinter stehen.
Bricht man Arbeitspakete auf konkrete Aufgaben herunter und beziffert diese, kann man den Aufwand für das Projekt recht früh abschätzen. Diese Aufgabe hat eine Komplexität von 3, die andere von 5, und so weiter. In Summe kommt das Projekt auf z.B. 500 Komplexitätspunkte. Wobei ein Komplexitätspunkt nicht zwangsläufig eine Stunde oder ein Tag ist. Es sagt lediglich aus, dass eine Aufgabe mit 6 Punkten etwa doppelt so schwer ist wie eine Aufgabe mit 3 Punkten, und so weiter. Man kann diese Komplexität auch mit Stunden angeben, doch meiner Erfahrung nach verbringt man dann schnell mehr Zeit damit die Zahlen zu korrigieren, als sich auf eine Aufgabe zu konzentrieren. Das eine Aufgabe im Budget bleibt, sollte nicht das Problem des Projektmitglieds ein. Hier greift das Projektmanagement bei Bedarf steuernd ein.
Hat man alle Aufgaben sauber dokumentiert und mit einer Definition of Done versehen, reduziert das die implizite Komplexität einer Aufgabe erheblich. Eine Definition of Done sagt dabei aus, welche Schritte erledigt sein müssen, damit diese Aufgabe als fertig bezeichnet werden kann. Ist das Login für den Vorstand mit dem iPad möglich, muss sich der betreffende bei dieser Aufgabe keine Gedanken um den Datenschutz machen. Er ist fertig damit. Das Thema Datenschutz kann dann eine eigene Aufgabe sein, bei der er dann seinen ganzen Fokus auf eben dieses Thema richtet. Der Mitarbeiter hat nicht das Gefühl von 10 Aufgaben gleichzeitig beansprucht und förmlich zerrissen zu werden. Auch ist die Gefahr eines Fehlers reduziert, denn was „Done“ ist, steht ja in der Aufgabe. Wird dann eine neue Abhängigkeit entdeckt, wird eben eine neue Aufgabe erzeugt. Oder, wenn der Mitarbeiter noch nicht fertig ist, die bestehende Aufgabe wird um genau diesen einen Punkt ergänzt. Wobei man hier auf die Zuständigkeiten achten muss. Kann der Kollege überhaupt den Punkt Datenschutz bearbeiten? Oder wäre das die Aufgabe der Datenschutzbeauftragen? In diesem Fall sollte eine eigene Aufgabe für sie hinterlegt werden, die zu der Aufgabe des Kollegen in Relation gesetzt wird. So wissen beide, dass sie sich miteinander austauschen müssen, um das Problem zu lösen.
Gibt es hierbei unklare Zuständigkeiten ist es wieder die Projektleiterin, welche diese klären muss. Und hier kommen wir ggf. zu dem Coach, welcher der Projektleiterin zur Seite gestellt wurde. Er weiß, wen sie fragen muss, um die notwendigen Zuständigkeiten herauszufinden.
All diese Gedanken sind dem Scrum entlehnt, benötigen jedoch nicht zwangsweise die Methodik der Sprints und Retros – auch wenn ich diese für sinnvoll halte. Sie sorgen dafür, dass die Komplexität jeder Aufgabe möglichst gering gehalten wird und die Projektmitglieder somit nicht in das Gefühl der Überforderung hineinrutschen.
Weiterhin hilft eine sauber gepflegt Liste sich zu visualisieren wie aufwändig eine Aufgabe ist und ob sie überhaupt auf das Gesamtergebnis einzahlt. Hat man eine Aufgabe regelmäßig vor sich, bespricht sie, und sieht auch die anderen Aufgaben, die noch auf der Liste stehen, kann man hier schnell eine Priorisierung der Aufgaben vornehmen. Entweder durch den verantwortlichen Fachbereich oder durch die Projektleitung. Das Geschriebene bleibt im Gedächtnis.
Meetings und Organisation
Häufig habe ich den Eindruck, dass mit der Länge des Projektes auch die Anzahl und Länge der Meetings zunimmt. Gleichzeitig nimmt der eigentliche Informationsgehalt immer weiter ab. Ist am Anfang eines Projektes das eigentlich Kickoff-Meeting häufig innerhalb von einer bis zwei Stunden abgehandelt und behandelt alle wesentlichen Aspekte für den Projektstart gibt es in der Mitte eines Projektes häufig schon Projekt-Weeklies, die einen halben Tag dauern und die eine Art Rechtfertigungscharakter haben. Hier versuchen sich die Projektbeteiligten „freizusprechen“ oder ihre Arbeit zu rechtfertigen. Je weiter das Projekt Richtung Eskalation geht, desto mehr nimmt dieser Rechtfertigungscharakter zu, desto mehr werden Schuldzuweisungen geäußert und alte Dokumente, E-Mail und Notizen sollen den einen oder anderen Aspekt scheinbar beweisen. Die eigentliche Frage des Projektfortschritts geht dabei immer weiter verloren. Es wird nicht mehr geklärt, welche Hindernisse für den nächsten Projektfortschritt beseitigt werden müssen, sondern es wird diskutiert, wer für diese oder jene Verzögerung verantwortlich ist.
Die Praxis, die sich für mich hier bewährt hat, ist wieder dem Scrum entnommen. So wird in regelmäßigen Abständen zwischen einer und vier Wochen der aktuelle Projektfortschritt besprochen. Im Wasserfall-Modell könnte man hier von einer Projektphase sprechen, im agilen Umfeld sprechen wir von einem Sprint. Wichtig ist, dass am Ende einer solchen Phase ein messbares Ergebnis stehen sollte. Alle Tasks, die wir in dieser Phase umsetzen wollen, sind mit einer Definition of Done versehen und entsprechen den SMART Kriterien. So haben wir in regelmäßigen und kurzen Abständen ein Meeting, welches Arbeitsergebnisse präsentiert und Fehlentwicklungen aufdecket. Zwischen diesen Planung- und Abschlussmeetings findet dann ein tägliches, kurzes Meeting statt. In diesem Daily findet keine Rechtfertigung der Arbeit durch die Projektmitglieder statt, sondern es geht darum Probleme aufzuzeigen. Um es deutlich zu machen, wenn ein Projektmitglied jeden Tag meldet, dass alles OK ist, dann reicht diese Meldung völlig aus. Eine Arbeitskontrolle findet hier nicht statt und ist explizit auch nicht erwünscht. So sollen diese Meetings kurz gehalten werden und der Blick bleibt auf das wesentliche konzentriert.
Meldet ein Projektmitglied ein Problem, so kümmert sich der Projektmanager um eine Lösung. Das kann bedeuten, dass 2 oder mehrere Projektmitglieder unterschiedlicher Fachrichtungen ein kurzes Meeting im Anschluss machen, um eine Frage zu klären. Es kann aber auch bedeuten, dass die Projektleiterin auf den Teamleiter des Projektmitglieds zugeht und ihm erklärt, warum die Arbeit an der Zusatzaufgabe nicht ausgeführt wird, da die Mitarbeiter:in hierfür aktuell keine Kapazität hat. Notfalls trägt die Projektleiterin hier auch den Konflikt mit dem Vorgesetzen aus. Das Ergebnis kann natürlich sein, dass die Projektmitarbeiter:in dennoch die Zusatzaufgabe ausführen muss. Aber in diesem Fall ist es der Projektleiterin bewusst und sie wird diese Störung entsprechend in der Projektplanung berücksichtigen und notfalls auch eine Verzögerung des Projektes im Steering mit dieser Aufgabe argumentieren. So ist eine einfache Planbarkeit gewährleistet und es gibt keine versteckten Verzögerungen im Projekt.
Um es noch einmal zu sagen, jedes Meeting, dass nicht auf den Fortschritt des gesamten Projektes einzahlt, oder das nach Gründen für ein vergangenes Verhalten sucht, sollte vom Projektteam ferngehalten werden. Insbesondere dann, wenn bereits eine größere Eskalation stattgefunden hat, und das Projekt nun reorganisiert wird. Wenn eine solche Fehleranalyse stattfindet, sollte sie am Ende eines Projektes durchgeführt werden und die Ergebnisse sauber dokumentiert mit einem echten Mehrwert versehen in die Lessons Learned übergehen. Findet während dem Projekt eine solche Analyse statt, bspw. um zu entscheiden, ob das Projekt überhaupt weitergeführt wird, liegt es an der Projektleitung dieses Meeting durchzuführen und die Informationen vom Team einzuholen. Die Projektleitung dient hier als Puffer zwischen externen Einflüssen und dem Projektteam, um den Fortschritt des Projektes nicht zu gefährden und die Stimmung innerhalb des Teams nicht ins Negative driften zu lassen. Die Projektleitung holt hier lediglich für dringende, fachliche Fragen gezielt Experten in einen Termin, um die Eskalation möglichst zeitnah zu beenden und den neuen Weg aufzuzeigen.
Fazit
Die beschriebene Geschichte ist wie gesagt nur ein Gedankenspiel und zeigt verschiedene, häufig auftretende Fehler in Projekten an. Die anschließend Maßnahmen sind dazu geeignet ein Projekt in jeder Phase seines Fortschrittes in eine positive Richtung zu lenken. Sei es nun von Anfang an, um direkt die Leistungsfähigkeit des Teams in das Projekt zu stecken, oder zu einem späteren Zeitpunkt, um ein ins Schlingern geratenes Projekt wieder einzufangen. Alle diese Maßnahmen sind an sich einfach auszuführen und reduzieren den organisatorischen Overhead eines Projektes enorm. Hier liegt sowohl die Stärke als auch die Schwierigkeit dieser Maßnahmen. Denn es ist wichtig, dass die ergriffenen Maßnahmen dann stringent eingehalten werden. Lässt man diese Maßnahmen wieder Fallen oder kehrt nach einer erfolgreich beendeten Eskalation zum alten Muster zurück, wird der Erfolg dieser Maßnahmen wieder zunichte gemacht. Schlimmer noch, die an sich erfolgreichen Methoden werden dann mit einem Scheitern in Verbindung gebracht und es herrscht ein Misstrauen gegen diese an sich einfachen Konzepte. Ein konsequentes Weiterführen dieser Methoden führt hingegen dazu, dass die Projektmitglieder ihre Arbeitskraft wirklich auf das Lösen der Projektprobleme richten können und auch komplexe Probleme in einfachere, handhabbare Teile zergliedert werden können. Dies auch bei einem Projekt einzusetzen, dass bereits in Schieflage geraten ist, erfordert einen gewissen Mut und die Bereitschaft auf ein komplett neues System umzustellen. Etwas, dass nicht immer einfach ist, wenn die Projektleitung ihr gutes Standing erst einmal eingebüßt hat. Daher sind diese Maßnahmen in verschiedene Bereiche unterteilt und aufeinander aufbauend, sodass man zunächst eine einzelne Maßnahme probieren kann, um den Erfolg am Gesamtsystem zu messen.
Gerne helfen wir auch bei der Beratung eines Projektes in Schieflage. Gerade in solchen Situationen ist ein externer Ansprechpartner, der das Gesamtbild neutral betrachten kann, von enormer Hilfe.
0 Kommentare