Das Projekt geht nicht voran?
Es kann sehr nervenaufreibend sein, wenn man tage- oder wochenlang keinen Fortschritt bei Produktfehlern oder Impediments erzielt.
Dauerhafte Impediments und Fehler können sogar zum Scheitern eines Projektes führen!
Mit diesem 3-stufigen Kochrezept bekommst Du eine Lösungsschablone, um schnell darauf reagieren zu können!
#003
In vielen Projekten habe ich beobachtet, dass man irgendwann in eine Phase kommt, da hat man einen Produktfehler oder ein Impediment und erzielt dadurch tagelang oder wochenlang keinen Fortschritt. Daraufhin werden dann Gegenmaßnahmen getroffen, aber irgendwie greifen diese dann auch nicht so richtig. Oder es wird ein Problem behoben und gleichzeitig ein neues Problem freigelegt. Und so schmilzt der ganze Puffer dahin, falls man den überhaupt geplant hat, oder die Velocity geht voll in die Knie und man fragt sich: „Wann wird diese Ursache endlich behoben sein?“ Und die Kommunikation Richtung Kunden wird ja auch immer schwieriger, weil man jedes Mal hoffnungsvoll von neuen Maßnahmen berichtet, diese dann durchführt und wieder neue Probleme auftreten. Aus diesen Nährstoffen kann dann ziemlich schnell eine echte Projektkrise entstehen, weil Zeit und Geld ausgehen. Und damit es dazu erst gar nicht kommt, verrate ich dir gleich mal mein dreistufiges Kochrezept dazu.
Damit du gleich besser verstehst, warum ich diese Maßnahmen vorschlage, erzähle ich dir mal von meiner Rumänien-China-Story. Ich war mal für den Aufbau eines verteilten Entwicklungsteams verantwortlich.
Ein paar Entwickler davon kamen aus Rumänien und ein paar andere aus China. Mit den Entwicklern aus Rumänien habe ich damals ein Vorstellungsgespräch gemacht. Die habe ich mir auch selbst ausgesucht, ich war mehrfach vor Ort und ich wusste auch, welche Stärken und welche Schwächen die hatten. Das Team aus China wurde mir von einem chinesischen Technologiekonzern gestellt, das heißt, ich kannte die Mitarbeiter nicht. Mir wurde jedoch gesagt, dass sie fit in der Programmiersprache seien, die wir auch einsetzen wollten.
Gut, dann gab es einen Kickoff, bei dem sich alle remote kennengelernt haben. Dann wurde unter anderem das Backlog mit den Stories präsentiert und wie wir uns die Entwicklung nach Kanban vorstellen und auch welche Entwicklungswerkzeuge jedes Team konfigurieren muss, um gemeinsam entwickeln zu können. Danach haben wir dann festgelegt, dass wir uns zweimal wöchentlich zum Statusmeeting zusammentelefonieren. Alles klar. 2 Wochen später, nach dem Kickoff, hat sich dann folgendes Bild ergeben – ich zähle jetzt nur mal 3 Punkte davon auf:
Team Rumänien: Aufbau der Entwicklungswerkzeuge: Alles in der ersten Woche aufgebaut. Check. Fortschritt bei der Entwicklung: Backlog nach Plan abgearbeitet, Stories abgeschlossen. Super, Check. Statusmeetings: Immer anwesend, immer pünktlich und eine sehr gute Sprachqualität. Check.
Team China: Aufbau der Entwicklungswerkzeuge: Deren Quellcode läuft ja immer noch nicht auf Apple Testgeräten. Fortschritt bei der Entwicklung: Noch keine Story abgeschlossen. Mehrere Stories mit niedriger Priorität in Bearbeitung. Statusmeetings: Fast immer anwesend, aber übelst schlechte Sprachqualität. Man konnte fast nichts verstehen.
OK, was haben wir darauf probiert? Das rumänische Entwicklungsteam hat versucht, die Fehler beim chinesischen Team zu finden, also warum der Source Code nicht auf den Apple Geräten lief. Ohne Erfolg. Ich habe das chinesische Team gebeten, wirklich bitte immer am Meeting teilzunehmen und bitte immer über Festnetz zu telefonieren, damit die Sprachqualität besser wird. Die Reaktion darauf war, dass in weniger als 50% aller Fälle die Meetings jetzt gar nicht mehr zustande kamen. Dann wurden Links mit Anleitungen im Internet gesendet, wie man bestimmte Infrastrukturprobleme lösen kann. Die wurden entweder nicht durchgelesen oder komplett nicht verstanden. Fazit von dem Ganzen: Auch noch mal 2 Wochen später kein Fortschritt bei den Ergebnissen. Wir stapften also 4 Wochen lang auf der Stelle und kamen nicht weiter.
Diese Situation war für mich auch neu. Ich hatte schon sehr viele Probleme in den letzten Jahren gelöst, wo andere gesagt haben: „Ach, das geht sowieso nicht“, und ich habe bewiesen, dass es doch einen Weg gab. Aber hier hat sich einfach nichts getan. Das rumänische Team hat dann resignierend nur darum gebeten, alles alleine zu machen, auch um die Wirtschaftlichkeit des ganzen Projektes nicht zu gefährden. Dann habe ich mich gefragt: „Können die nicht oder wollen die vielleicht nicht entwickeln?“ Und aus den Gesprächen habe ich schon gemerkt, dass die grundsätzlich schon entwickeln können. Die hatten die fachlichen Kenntnisse. Ich dachte mir, es gibt irgendwelche Blocker, die ich aktuell nicht sehe und die ich aktuell nicht höre, aber die auf jeden Fall existieren. Und der einzige Weg, das rauszufinden, ist: Ich muss mir vor Ort ein Bild machen. Und dann bin ich zu diesem Unternehmen nach China geflogen, habe den rumänischen Lead-Entwickler mitgenommen und wir haben uns Zeit genommen, uns die gesamte Arbeitsweise einmal anzuschauen. Also von „Wie macht ihr das, wenn ihr uns anruft?“ bis hin zu „Zeigt mir mal eure PCs. Und welche Entwicklungswerkzeuge benutzt ihr?“ und dann sind uns die Augen aufgegangen, als wir Folgendes erlebt haben:
1. Die Entwicklungswerkzeuge konnten nicht vollständig installiert werden, weil auf deren Macs 2 Jahre lang kein Betriebssystem-Update gemacht wurde. Der Grund dazu war, dass das laut Unternehmens-Policy nicht erlaubt war, die Macs an das Internet anzuschließen, auch nicht für Updates. Daraufhin habe ich mit dem Manager gesprochen, die Rechner wurden abgeholt und nach einer Woche waren die Updates drauf.
2. Warum sind die Telefonkonferenzen nur noch in unter 50% aller Fälle zustande gekommen? Naja, wir haben erfahren, dass es nur einen einzigen Meetingraum gibt, in dem das einzige Telefon stand, aus dem man eine deutsche Telefonnummer wählen konnte. Und dieser Meetingraum konnte nicht reserviert werden, also war es Zufall, ob ein anderer gerade den Raum für sich hatte oder unser Team den Raum belegen konnte. Getreu dem Motto: First come, first serve. Wieder mit dem Manager gesprochen und für das Team eine Sonderregel eingeführt. Die konnten den Raum dann buchen.
3. Warum haben die Entwickler die Anleitung im Internet nicht gelesen? Wir haben denen doch die Links zugeschickt. Naja, Entwickler haben keinen Zugriff auf das Internet von da, wo sie entwickeln. Die müssen mit Büchern klarkommen – also kein Stack Overflow. Es gab noch viele andere Impediments und auch Maßnahmen, die wir eingeführt haben, um die Zusammenarbeit zu verbessern. Und ich finde es auch toll, wie schnell wir dort Erfolge hatten. Also jetzt bitte nicht falsch verstehen. Die Arbeit mit Chinesen macht mir persönlich immer unwahrscheinlich viel Spaß. Es ist super pragmatisch, Dinge werden schnell umgesetzt, auch ohne große Diskussionen zu führen über das Thema Vertrag.
Aber ich will jetzt auch gerade gar keinen Podcast über interkulturelle Zusammenarbeit machen. Der Punkt, auf den ich hinaus möchte, ist folgender: Wir wären nie auf die Idee gekommen, dass es nur einen Meetingraum gibt, von dem man deutsche Nummern aus wählen kann, und wir wären nie auf die Idee gekommen, dass die Macs verwenden, bei denen 2 Jahre keine Updates gemacht wurden.
Was in unserer Wirklichkeit nicht denkbar war, war in deren Wirklichkeit Alltag. Und dieses Phänomen kommt in der IT häufiger vor, als wir denken.
Die einen denken sich: „Ist doch klar“, und deshalb wird etwas nicht erwähnt. Und die anderen haben so etwas noch nie erlebt und können deswegen auch nicht die richtigen Fragen stellen, um diese Art von Impediment zu lösen, wenn im Projekt tage- oder wochenlang kein Fortschritt erzielt wird oder wenn mehrere unterschiedliche Lieferanten an einer Entwicklung beteiligt sind und jeder sagt: „Bei mir liegt der Fehler nicht“, „Ja, bei mir liegt der Fehler auch nicht. Ich habe auch alles geprüft.“ Ja, bei mir als Projektleiter wird er wahrscheinlich auch nicht liegen, aber wir müssen es ja trotzdem ausmoderieren und das Thema lösen.
Daher mein Tipp: Sei vor Ort. Sei vor Ort und mache dir erst mal selbst ein Bild von der Lage oder schicke alternativ deinen Scrum-Master mit Experten da hin. Und wenn du vor Ort bist, dann versuche absolut immer, die Ursachen für ein Problem im Projekt herauszufinden, also den Root Cause, bevor du eine Maßnahme beschließt oder auch bevor das Team verschiedene Maßnahmen beschließt. Ansonsten kann es sein, dass du nur versuchst, die Wirkung zu verändern, und die Ursache poppt später wieder auf. Nur Wirkung ändern ist das Gleiche wie Schulden machen. Irgendwann wird es zu viel und du kommst da nicht mehr raus, weil die Zinsen dich auffressen.
Man kann heute alle IT-Projekte fast ausschließlich remote durchführen bis auf einige wenige Meetings, aber wenn es brennt oder irgendwo längere Zeit hakt, dann solltest du oder jemand anderes mit den Experten da hinreisen, wo auch die Musik spielt, und sich Zeit nehmen, die Ursachen zu finden. Das lohnt sich.
OK, ich habe die Geschichte jetzt mal so ausführlich erzählt, weil das für mich damals ein wirklicher Augenöffner war, also eines der größten Learnings im Projektmanagement, was ich aber so nicht gelesen habe bisher. Und jetzt fasse ich mal kurz meine 3-Punkte-Vorgehensweise zusammen.
1. Wenn du im Projekt längere Zeit keinen Fortschritt bei technischen Problemen erzielst oder bei Impediments, dann stelle ein temporäres Expertenteam zusammen und besprich mit denen einen Stichtag, bis wann das Problem behoben sein soll. Die zentrale Frage für die Zusammenstellung des Teams lautet: Wer kann etwas zur Problemlösung beitragen von Kunden- und von Lieferantenseite? Und die bilden dann die Task Force.
2. Bei internationalen Projekten oder verteilten Teams ist diese Task Force dann in der Regel zuerst natürlich auch verteilt. Und wenn das Problem remote nicht bis zum Stichtag gelöst werden kann, dann verlängere nicht die Zeit, weil du hoffst, dass alles gut wird, sondern handle sofort und gehe mit den Experten zur Quelle des Problems. In der Regel ist das ein Lieferant, bei dem man sich vor Ort trifft und dann gemeinsam die Ursachen auch schnell rausfinden kann – wie gesagt, entweder du selbst oder der Scrum-Master, jedenfalls eine Person mit Moderationsfähigkeiten. Wirklich wichtig finde ich, dass die Experten sich auf die technische Problemlösung fokussieren können und jemand anderes die Moderation inklusive Dokumentation übernimmt. Und damit kommen wir auch zum 3. Punkt.
3. Moderation und Dokumentation bedeutet, dass gemeinsame Lösungs-Workshops und Brainstormings gemacht werden und die Ergebnisse davon immer nachgehalten werden. Nur damit ist es dann auch möglich, dass man Schritt für Schritt per Ausschlussverfahren die Ursache herausfindet. Wenn man das nicht dokumentiert, dann kann es passieren, dass man bestimmte Schritte noch mal macht oder schon vergessen hat, was man alles ausprobiert hat.
Wenn dich Insider-Wissen beim Thema agiles Projektmanagement interessiert, dann abonniere jetzt gerne meinen Podcast: Agiles Projektmanagement
