Von saubergehaltenen Höfen

Die Natur verabscheut das Vakuum (Aristoteles)

Ein früherer Kunde meiner Agentur (selber technischer Projektmanager) verwendete erheblichen Aufwand in die Umsetzung folgender PM-Regel:

"Für jede erdenkliche Situation, die im Projekt auftreten könnte, muss es einen Verantwortlichen geben. Dieser muss identifiziert werden bevor die Situation eintritt, und dieser muss sich nachprüfbar dazu committed haben" (so habe ich mir das zumindest zusammengereimt...)

Es gibt dafür zwei Motivationen:

1. Es erleichtert die Arbeit massiv, weil es Reibungsverluste vermeidet. Ein TPM sollte sich möglichst schnell mit seinen Kollegen verständigen, wer welchen Teil im Angebot schreibt/kalkuliert, ob die fachlichen Anforderungen von den Konzeptern vollständig beschrieben werden oder aus der Technik unterstützt werden muss, ob der TPM das Testing organisieren muss oder jemand anderes dies erledigt. Mit dem Kunden ist abzustimmen, in welcher Form die Abnahme durchgeführt werden soll, mit welcher Vosständigkeit bei geliefertem Material man rechnen kann, wer in welcher Reihenfolge Schnittstellenprogrammierung für die Integration zweier Systeme erledigen muss etc.

2. Noch wichtiger: Es hilft im Zweifelsfall dabei, "den eigenen Hof sauber zu halten". Sollte eine unangenehme Situation auftreten, ist man gut beraten eine Mail aus der Tasche ziehen zu können die belegt, dass jemand anderes die Verantwortung hat.

Und weil man hier einwenden könnte dass es eher darauf ankommt, gute Projekte zu machen als seine Zeit mit macchiavellistischem Polit-Kram zu versusen, sei mir zu diesem Thema eine Erklärung gestattet:

• Wenn in einem Projekt etwas richtig schief läuft fragt kein Mensch danach, ob man bisher als TPM einen tollen inhaltlichen Job gemacht hat. Im Extremfall kommt man nicht mehr dazu, weiterhin gute Projekte zu machen: "Der X. als Technischer Projektmanager für so ein wichtiges Ding? Lass mal, das war doch bei Y so ein Debakel, das können wir echt nicht nochmal gebrauchen..."
• Ob man will oder nicht, wenn ein Auftraggeber (Kunde, Chef oder andere Abteilung) einem den schwarzen Peter zuschiebt, muss man sich dazu äußern.
• In der Regel ist die Beweislast umgekehrt, als Projektmitglied muss man nachweisen dass man alles richtig gemacht hat. Das ist im Zweifelsfall ausgesprochen aufwendig. Für die Möglichkeit, eine Mail der Form "sorry, aber hatten wir nicht vereinbart (siehe angehängte Mail), dass Sie sich um die rechtzeitige Buchung des externen Dienstleisters kümmern?" schreiben zu können ist man dann dem Herrn dankbar.

Eskalation

Der Begriff Eskalation hat weiß Gott kein gutes Image: wenn man bei Google danach sucht findet man ihn vor allem im Umfeld von Nah-Ost-Konflikt, Telekom gegen ver.di oder Messerkampftechniken. Im Projektgeschäft ist Eskalation eigentlich nichts Schlimmes, dennoch haftet ihm der Ruch von "Verpetzen" oder "in die Pfanne hauen" an. Laut Wikipedia bedeutet Eskalation "dass bestimmte Entscheidungen kontrolliert eine Ebene "nach oben" (zu den jeweiligen Vorgesetzten) delegiert werden, wenn in einer Konfliktsituation auf der unteren Entscheidungsebene keine Übereinkunft möglich ist."

Projektarbeit basiert - wie im Übrigen jede Art von geschäftlicher Beziehung - darauf, dass Menschen untereinander "Verträge" eingehen, und jeder muss sich darauf verlassen können, dass seine Vertragspartner ihren Teil des Vertrags einhalten. Diese Verträge sind meistens informell und werden als solche gar nicht wahrgenommen:

• Der Kunde verlässt sich darauf, dass die Agentur zum vereinbarten Zeitpunkt eine Website live schaltet.
• Die Agentur erwartet von den Mitarbeitern des Kunden rechtzeitige Materiallieferungen und Freigaben.
• Der Leiter des Entwicklungsteams erwartet von letzterem, dass die Entwicklung der Website pünktlich beendet wird.
• Der Entwickler verlässt sich darauf, dass er rechtzeitig die Layouts und das finale Konzept aus der Kreation erhält.

Wird eine Vereinbarung nicht eingehalten, so führt das unmittelbar dazu, dass jemand anderes seinen Job nicht anständig machen kann. Kreation liefert Layouts zu spät = Web Developer wird ebenfalls nicht pünktlich fertig und würde damit seine Vereinbarung mit seinem Chef nicht einhalten.

Viele Entwickler verstehen nicht, dass die Lösung des Problems außerhalb ihres Einflussbereiches liegt ("ich habe echt zwanzigmal nachgefragt, aber nix ist passiert. Was hätte ich denn machen sollen?"). Tatsächlich ist der einzige gangbare Weg, die Aufgabe nach oben zurück zu delegieren, mit anderen Worten: zu eskalieren.

Also, lieber Web Developer (stellvertretend für alle anderen): demnächst bitte den Teamleiter darauf hinweisen dass Du gar nicht pünktlich fertig werden kannst, weil Du kein Material bekommen hast. Damit wäre der Plumpsack beim Teamleiter. Dieser versucht mit seinen Mitteln eine Lösung: er wird beim Teamleiter der Kreation die Lieferung der Layouts einfordern. Der Kreationsleiter delegiert das entweder eine Hierarchieebene nach unten (etwa wenn der Designer einfach nicht genug Zeit zur Verfügung hatte um seine Aufgabe zu lösen) oder eskaliert selber nach oben (wenn der Kunde Material nicht geliefert hat).

Eskalation ist im richtigen Zusammenhang also nicht nur ok, sondern sogar absolut notwendig.