Was ein Meilenstein ist? Entschuldigung, aber das ist eine selten dämliche Frage. Wer etwas von Projektmanagement versteht, weiß selbstverständlich, was ein Meilenstein ist! Dachte ich auch mal…

Die Praxis ist irrer als jedes Lehrbuch

Wenn ich als Projekt-Coach Projektteams begleite, frage ich beim ersten Teammeeting immer: „Ist jedem klar, wie Arbeitspakete definiert und abgenommen werden? Was ein Meilenstein ist?“ Ich traue mich kaum noch, das zu fragen, denn unweigerlich bricht daraufhin der Sturm der Empörung los: „Was glauben Sie denn? Jeder von uns hat drei PM-Trainings und schon mindestens fünf Projekte hinter sich. Wir wissen, wie das läuft!“

Dann bin ich dankbar und froh: Uff, wir müssen nicht bei Adam und Eva anfangen. Das freut uns alle. Wir kommen schneller voran, mein Auftraggeber muss mir weniger Honorar überweisen und ich muss keine Grundsatzreferate halten. Alles prima, legen wir los, vereinbaren wir die erste Teamaufgabe: „Bitte stellen Sie bis zu unserem nächsten Treffen in vier Wochen Ihre Arbeitspakete auf und ordnen Sie sie den sechs Meilensteinen zu, die wir vereinbart haben.“ Alle nicken, keiner hat mehr Fragen, ich setze mich ins Auto und fahre froh von dannen. Wenn ich zurückkomme, trifft mich der Schlag. Re-gel-mäs-sig.

Das darf nicht wahr sein

Von 184 Arbeitspaketen überspringen 97 den jeweils nächsten Meilenstein oder halten sich überhaupt an keinen Meilenstein. Bei überraschend vielen Arbeitspaketen steht unter „Vorgänger-Arbeitspaket“ dieselbe Bezeichnung wie über dem betrachteten Paket (so hat z.B. AP 28 den Vorgänger AP 28). Das sind nur zwei der „Ausrutscher“, die weder nach Lehrbuch noch nach Selbstauskunft der Teammitglieder hätten passieren dürfen. Und doch wimmelt es nur so von ihnen in der Projektplanung.

Man braucht keine große Phantasie, um sich vorzustellen, was bei so einer Planung nachher im Projekt los ist. Man braucht keine Phantasie, weil man lediglich die bislang durchgeführten Projektverläufe betrachten muss: Da wird plötzlich evident, weshalb diese Projekte so unbefriedigend liefen. Wenn nicht mal klar ist, was ein Meilenstein bedeutet… Warum ist das nicht klar?

Was macht ihr da?

Natürlich bemerkt es kein Teammitglied, dass sein Arbeitspaket den betreffenden Meilenstein überschreitet – sonst hätte es den Fehler nicht begangen. Warum wird er begangen? Ich habe den Verdacht, dass einige Arbeitspaketinhaber zwar wissen, wie ein Meilenstein definiert ist, aber nicht seine Bedeutung erkennen – für ihr eigenes Arbeitspaket.

Andere sind schlicht so froh, wenn nach Tagen der Planung und der verzweifelten Suche nach Ressourcen ihr Arbeitspaket endlich steht, dass sie einfach „vergessen“, dessen Dauer auf den nächsten Meilenstein abzustimmen (wir klammern Vorsatz in diesem Rahmen mal aus).

Ähnliches gilt für den Fehler mit dem „Vorgänger-Arbeitspaket“. Das mag ein Flüchtigkeitsfehler sein, mangelndes Verständnis darüber, was mit dieser Angabe bezweckt werden soll, oder schlicht Bequemlichkeit, sich mit den anderen Teammitgliedern abzustimmen und zu klären: „Hey, wer kommt eigentlich vor mir? Von wem übernehme ich?“ Das mögen wirklich Flüchtigkeitsfehler sein. Aber uns allen ist doch wohl klar, dass an dieser Stelle jedes seriöse Projektmanagement zusammenbricht. Ist es das wirklich? Jedem klar?

Das ist alles andere als klar

Wenn das wirklich jedem/r klar wäre, würde ich nicht ständig Dialoge führen wie:

„Kam es in früheren Projekten vor, dass Sie nicht mit Ihrem Arbeitspaket beginnen konnten, weil es zu spät bei Ihnen eintraf?“

„Das kommt ständig vor! Deshalb haben wir Sie ja gerufen!“

„Wenn Sie am Tag 0 Ihr Paket nicht bekommen haben – was machen Sie dann?“

„Mich ärgern! Was sonst!“

„Das ist klar. Wem machen Sie dann Druck?“

„Dem Projektleiter. Aber der ist ja nie erreichbar!“

„Hat der Projektleiter das Paket?“

„Natürlich nicht. Das hat der, der es bearbeitet!“

„Warum fragen Sie dann nicht bei diesem nach, wo das Paket bleibt?“

„Woher soll ich wissen, wer das ist!“

Aha. Aber irgendwie geht das nicht a priori mit der Erkenntnis zusammen, dass man diesen Unbekannten „Vorgänger“ nennt – und nachschlagen könnte. Wenn man ihn bei der Planung identifiziert, benannt und dokumentiert hätte. Dieser Mangel an Erkenntnis reicht sehr viel tiefer als eine falsche Angabe unter „Vorgänger“ im Projektplan.

Das tiefere Verständnis fehlt

Wirklich sämtliche dieser prima facie rätselhaften, furiosen, trivialen und katastrophalen Fehler bei der Projektplanung lassen sich bei tieferer Analyse auf einen erschreckend simplen Befund zurückführen: Wem solche Flüchtigkeitsfehler durchrutschen, der hat noch nicht physisch erfasst, das sich hinter dem irreführenden Abstraktum „Projektmanagement“ im tiefsten Kern ein extrem intensiver, interaktiver, kooperativer und kollegialer Abstimmungsprozess versteckt.

Wenn ich diese Abstimmung versemmle, verhaue ich das Projekt. Wenn ich nicht weiß, wer mein Vorgänger und Nachfolger ist, kann ich mich nicht informell zwischen zwei Sitzungen mit ihm abstimmen – und dann bekommen wir all die schönen Probleme, die wir nur allzu gut kennen. Was taugt ein PM-Training, wenn es nicht einmal diesen banalen Zusammenhang vermitteln kann?

Wer ist schuld?

Natürlich lernt man diesen Zusammenhang in jedem guten Training! Aber wie wir alle wissen: Gelernt heißt nicht gemacht. Und gemacht heißt nicht richtig gemacht. Viele „vergessen“ nach Treu und Glauben tatsächlich die Meilenstein-Abstimmung oder den Eintrag des Vorgängers. Das ist nicht schlimm. Das ist mir in der Eile des Gefechts auch schon passiert. Wirklich schlimm ist: Das merkt keiner!

Da startet ein Projekt munter, obwohl 97 Arbeitspakete länger laufen als ihr Meilenstein und obwohl 28 Vorgänger nicht oder falsch eingetragen sind. Jede Videospiel-Software beschäftigt zig Bug-Tester, bevor sie raus in den Handel geht. Wo sind die Bug-Tester für den Projektplan? „Tja“, antwortete mir eine Geschäftsführerin unlängst darauf: „Dafür müssten wir Leute haben, die wissen, worauf man schauen muss.“ Woher nehmen?

Die Bug-Tester

Tatsächlich engagieren Unternehmen, die die Problematik erkannt haben, inzwischen externe Tester: „Checken Sie unseren Projektplan durch – damit wir nicht erst mittendrin bemerken, wo der Plan Fehler hat.“ Das Witzige daran ist: Das ist gut und nützlich – aber nicht unbedingt nötig. Denn in wirklich jedem Unternehmen treffe ich Teammitglieder, die im Gegensatz zu ihren KollegInnen wissen, was ein Vorgänger und ein Meilenstein ist und auf diese und andere Fehler im Plan frühzeitig hinweisen.

Was kriegen die höheren Orts zu hören? „Nun hören Sie mal auf zu meckern und kommen Sie in die Puschen!“ Oder: „Lassen Sie gut sein. Das regeln wir, wenn es soweit ist.“ Oder: „Muss das jetzt sein? Das hält doch nur auf. Noch eine Woche den kompletten Plan durchchecken? Das können wir uns nicht leisten! Das Projekt muss schleunigst raus! Der Kunde wartet!“

Dass der Kunde ohne diesen Plan-Check vielleicht sehr viel länger als eine Woche auf das Projektergebnis warten muss, weil manche Fehler im Projektplan unentdeckt bleiben, ist dabei vermutlich nur Ihnen und mir klar. Doch darauf möglichst beharrlich, wiederholt und überzeugend hinzuweisen, gehört zu den diplomatischen Pflichten jedes vorausschauenden Projektleiters.