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.

Das Festpreis-Fiasko

Einmal dem Fehlläuten der Nachtglocke gefolgt - es ist niemals gutzumachen. (Franz Kafka: Ein Landarzt)

Was im Festpreisangebot verbockt wird ist oft im gesamten Projektverlauf nicht mehr zu beheben. Entsprechend gerne sträuben sich Entwickler, eine Aufwandschätzung abzugeben ("es dauert eben so lange wie es dauert"), gerade wenn man noch gar nicht sooo genau weiß was im Projekt überhaupt gemacht werden soll. Der Kunde will es eben besonders früh wissen, und wer will es ihm auch verdenken: Er muss ein Budget organisieren bevor das Projekt begonnen hat. Würden Sie ein Haus bauen (und sich massiv verschulden) ohne zu wissen was es kostet? Eben.

1. Idealerweise macht man eine technische Kalkulation auf Basis eines Fachkonzeptes und einer technischen Analyse. Das hat man beides leider in den seltensten Fällen.

2. Wenn es für die fachlichen Anforderungen nur ein knappes Briefing gibt ("wir würden gerne unsere Website um ein Shopsystem erweitern") greift die Grundregel "Eine Anwendung kann frühestens dann kalkuliert werden wenn man sie sich als Anwender vorstellen kann". Man muss also alle Seiten und alle Prozesse aufführen und grob beschreiben können. Wenn es diese Beschreibungen nicht gibt, muss man sie eben auf Basis eines kurzen Workshops oder Telefonats mit dem Kunden oder alternativ auf Basis von Annahmen selber machen. Diese kommt dann als Leistungsbeschreibung ins Angebot.
Ob die Anforderungen später im Projekt genau so umgesetzt werden ist gar nicht so wichtig, es kommt darauf an, eine Beschreibung zu haben, gegen die man Mehraufwand abgrenzen kann, falls sich die Anforderungen ändern (und das wird in der Konzeptphase mit Sicherheit passieren). Je ungenauer die Beschreibung im Angebot ist, umso wahrscheinlicher ist es, dass der Kunde sich etwas wünscht was aufwendiger ist als ursprünglich kalkuliert.Im Bereich der fachlichen Anforderungen kann man durch etwas Detailarbeit Projektrisiken recht gut in den Griff bekommen. Das gilt für den folgenden Punkt 3. nur eingeschränkt.

3. Wenn die technische Analyse nicht vorliegt, kann man versuchen, zumindest eine knappe Recherche und ein kurzes Prototyping zu machen um einen Überblick über die unklaren Technologien oder Schnittstellen zu bekommen. Für technische Risiken gibt es aber anders als für fachliche Anforderungen keine Möglichkeit, sie durch Abgrenzungen im Angebot abzufedern. Dem Kunden ist ja letztlich egal wie seine Anforderungen durch Technik gelöst werden, es macht deshalb auch keinen Sinn, Annahmen dazu im Angebot zu formulieren, denn wenn diese nicht zutreffen ist das kein vom Kunden geforderter Change sondern ganz schlicht eine falsche Annnahme des Dienstleisters.
Ausnahme: Schnittstelle zu externen- oder Kundensystemen. Hier ist es durchaus üblich etwas zu schreiben wie "Annahme: die Produktdaten werden durch einen SOAP-Webservice vom Kunden zur Verfügung gestellt".

4. Gerne vergessen werden Qualitätssicherung, Deployment ins Livesystem, Dokumentation etc. Auch hier gilt: Abgrenzen, abgrenzen, abgrenzen. Da das etwa bei technischer Doku nicht ganz trivial ist (weil man deren Detailgrad nur schwer definieren kann) muss man sich mit Krücken behelfen, wie etwa: "Erstellung einer technischen Dokumentation, Umfang ca. 20 Seiten". Auch wenn die Seitenzahl hier völlig sinnfrei scheint, so erfüllt sie doch den Zweck zumindest eine grobe Vorstellung der Leistung zu vermitteln.

Folgekosten: Zwei Nachträge

Nachtrag 1:
Die Folgekosten in meinem Post von gestern müssen nicht unbedingt Geld bedeuten - es funktioniert auch mit den beiden anderen Elementen des Magischen PM-Dreiecks, nämlich Qualität und Zeit:

Zeit bedeutet, dass die Auswirkungen der Kundenanforderung auf die Deadline klargemacht werden müssen. Eine kostengünstige Lösung kann möglicherweise mit höherem Risiko behaftet sein und dadurch die Einhaltung der Deadline gefährden.

Qualität bedeutet nicht unbedingt das was die Agentur oder der Entwickler dafür hält. Viele Kunden verstehen darunter "keine Bugs" und generell Einhaltung ihrer Erwartungshaltung. Wie es unter der Haube aussieht ist ihnen oft weniger wichtig. Überzogene Anforderungen führen oft zu höherer Fehlerquote, das ist kein Verschulden der Agentur und sollte dem Kunden auch transparent gemacht werden.

Nachtrag 2:
Wie bei jeder Verhandlungssituation kann auch hier der Schuss nach hinten losgehen: "Das mit den Folgekosten bei Erweiterung meines schwiemeligen Altsystems klingt völlig überzogen. Wenn Sie das nicht in der Hälfte der Zeit schaffen - andere Agenturen schaffen es, ich habe zwei Angebote dazu auf dem Tisch liegen. Machen Sie bitte beim Rausgehen die Tür zu."

Folgekosten

Alles, was wir tun, hat eine Folge. (Johann Peter Eckermann)

Es ist gerade für Softwareentwickler nur unter Schmerzen zu akzeptieren, dass die im Projekt erstellte Website oder Anwendung das Eigentum des Kunden ist, und nicht das der Agentur. Das kann zu Konflikten führen wenn der Kunde etwas fordert, was der Entwickler als Verschlechterung des Produktqualität empfindet, und der erste Impuls ist oft zu sagen: "das machen wir nicht, das ist doch Pfusch? Oder?" Beispiel: Kunde will statt einer state-of-the-Art-Neuentwicklung lieber eine schon bestehende und veraltete Anwendung weiterentwickeln lassen, zu der ganze Horden von Entwicklern Spaghetti-Code beigesteuert haben und deren technische Basis durch und durch Old-School ist. Eine Erweiterung ist nun mal in der Regel günstiger als ein kompletter Neubau.

Antwort: Doch, das machen wir im Zweifelsfall, denn es Sache des Kunden ob er die Qualität seiner Website verschlechtern will. Aber es gibt einen Ausweg.

Grundregel 1: Was man mit dem Kunden ausgemacht hat (etwa im Rahmen eines Angebotes/Vertrages) muss man durchführen. Man verpflichtet sich mit dem Vertrag zur Erbringung einer bestimmten Leistung zu einem bestimmten Preis, und da gibt es auch nichts zu diskutieren.
Grundregel 2: Alles was nicht vereinbart wurde (weil es um einen ganz neuen Aufttrag geht oder weil es ein Change in einem bestehenden Projekt ist) ist grundsätzlich verhandelbar. Dabei bietet man dem Kunden wiederum eine Leistung an, ist aber frei einen Preis zu nennen. Das ist der wichtigste Hebel den man zur Kundenführung im Projekt hat.

Denn das Argument "diese Technologie ist durch und durch Old-School, und außerdem haben ganze Horden von Entwicklern Spaghetti-Code beigesteuert" wird von vielen Kunden nicht akzeptiert. Sie ist ja auch eher ästhetisch motiviert als dass sie berücksichtigt, dass ein Kunde einfach nur ein Projekt mt einem begrenzten Budget durchführen muss.

Man sollte vielmehr dem Kunden die Konsequenzen seiner Absicht verdeutlichen, und zwar auch die zukünftigen:"Natürlich, lieber Kunde, erstellen wir Dir gerne Deine Anwendung auf Basis dieser schwiemeligen Altanwendung. Die Erweiterung kostet [hier moderaten Preis einsetzen]. Allerdings ist der Code sehr schwer zu warten, weil er sehr oft ungesteuert erweitert wurde. Das wird in der Zukunft bedeuten dass wir die monatlichen Kosten für den Betrieb der Anwendung um [weniger moderater Preis] höher ansetzen müssen und außerdem Changes in der Größenordnung von [hier Prozentsatz einsetzen] Prozent aufwendiger werden."

Natürlich müssen die Zahlen und die Behauptung als solche realistisch sein und einer Überprüfung standhalten. Wenn sie das nicht tun sollte man sich ernsthaft fragen ob der Kunde mit seinem Ansatz nicht richtig liegt.

Was Kunden hassen

Das Vertrauen wird kommen, hat jeder nur erst seine Sicherheit (Schiller: "Wallenstein")

Fast genauso sehr wie schlechte Arbeit hassen Kunden Unsicherheit. Klar: ihr Erfolg ist oft aufs engste mit dem Projekterfolg verbunden, da ist man natürlich gerne im Bilde über den aktuellen Stand des Projektes oder über das Ausmaß eines Problems: "Tut mir leid, Frau K., der Produktimport klappt leider immer noch nicht, wir sind dran. Stimmt, wenn es bis übermorgen nicht läuft können wir nicht rechtzeitig live gehen. Was wir dann machen? Äääähhh, gute Frage."

Umso dankbarer sind Kunden wenn man ihrem Sicherheitsbedürfnis Rechnung trägt:

Regelmäßig und unaufgefordert Statusinformationen geben. Auch wenn die Erstellung von Statusberichten zu den verhasstesten Tätigkeiten hochbezahlter Softwaretechniker gehört: die Kunden werden Dich lieben, also erstelle sie ohne dass der Kunde ständig nachfragen muss.
Möglichst immer einen Plan B bereithalten. Sobald man gezwungen ist, Probleme zu melden, sollte man irgendeine Antwort aus der Tasche ziehen können für den Fall dass sich das Problem nicht oder nicht pünktlich lösen lässt (außer man kann glaubhaft versichern dass das Problem auf jeden Fall in einer definierten Zeit lösbar ist).
Prozesssicherheit vermitteln: Wenn ernste Probleme auftreten ist nichts wichtiger, als dem Kunden zu vermitteln, dass man die Situation noch unter Kontrolle hat. Im Klartext: Keine frei erfundenen Versprechungen, sondern eine Schilderung dessen was man bereits getan hat und was man als nächstes zu tun gedenkt um die Situation zu lösen. Das beinhaltet auch den oben genannten Plan B.

Anmerkung 1: Natürlich gehört Fachkenntnis dazu. Sicherheit vermitteln ist ziemlich schwer wenn man eine komplette Gurkentruppe am Start hat die es (d.h. Design, Konzept, Programmierung) einfach nicht kann.
Anmerkung 2: Das gilt alles nicht nur bei Kunden sondern auch bei Chefs und Teamkollegen. Auch die werden gerne mal informiert und bekommen kalte Füße wenn sie befürchten muss dass man auf das Prinzip Hoffnung baut anstatt aktives Risikomanagement zu betreiben.

Über Freiheitsgrade

In einem Projekt vor einigen Jahren musste ich für meine Agentur sehr kurzfristig ein Angebot für eine Website erstellen. Die Geschäftsführung des Kunden hatte uns gegen den Willen des Projektteams ins Boot geholt, und ich wusste, dass der Projektleiter auf Kundenseite alles tun würde um uns draußen zu halten (das Projekt endete übrigens genauso krank wie es begonnen hatte, aber das ist eine andere Geschichte...)

Interessanterweise war der Projektleiter nicht komplett unkooperativ. Er setzte eine verbindliche und recht knappe Timeline zur Abgabe des Angebots, Verzug hätte bedeutet dass das Angebot nicht berücksichtigt würde (denn er selber hatte von seinem Management ebenfalls ein knappes Timing für das Gesamtprojekt bekommen). Im Gegenzug hat er uns mit Material zum Angebot geradezu zugekippt und mehrfach nachgefragt ob er denn auch wirklich alle Unterstützung geleistet hat die wir benötigen - was wir schriftlich bestätigen mussten. Tatsächlich konnten wir in der Zeit die Informationen gar nicht alle bewältigen.

Er hat uns mit dieser Strategie maximal unter Druck gesetzt ohne sich selber angreifbar zu machen. Hätte sich im Nachhinein herausgestellt, dass er blockiert hat, wäre möglicherweise eine zweite Angebotsrunde die Folge gewesen. Man könnte daraus folgendes lernen: Auch in weniger aufgeladenen Situationen sollte man sich als IT-Projektmanager angewöhnen, allen Beteiligten ein Mindestmaß an Freiheitsgraden zu lassen, aber gleichzeitig Termine und Grenzen setzen (das gilt übrigens auch für die Erziehung von Kindern, wenn man der einschlägigen Ratgeberliteratur glauben schenken darf. Meine Kinder können allerdings noch nicht lesen):

Beispiel 1:Man ist im Projekt auf Materiallieferungen oder Freigaben des Kunden angewiesen. Auf jeden Fall im voraus eine Frist setzen, die aber nicht zu knapp halten! Wenn der Kunde sie nicht einhält und darauf hinweist, dass sie lächerlich kurz war, hat man wenig Hebel. Eisernes Beharren auf sinnlosen Timelines steht einem Dienstleister nicht sehr gut zu Gesicht. Wenn der Kunde die Frist nicht einhält, auf jeden Fall reagieren, sonst kommt die Frage auf wozu denn die Frist da ist, wenn sie ohne Konsequenzen verstreichen darf.

Beispiel 2: Man muss auf Kundenwunsch mit einem zweiten Dienstleister zusammenarbeiten (etwa weil der Design macht und die eigene Agentur die technische Umsetzung). Es gilt das Gleiche wie in Beispiel 1, auch hier sollte es für Übergaben und Bugfixes angemessene Termine geben damit im Problemfall der Kunde den anderen Dienstleister nicht noch in Schutz nehmen muss. Insbesondere dürfen Probleme in der Zusammenarbeit (nicht eingehaltene Übergaben) nicht zu spät dem Kunden mitgeteilt werden. Das fällt unter "Den Hof sauber halten", ich komme in einem späteren Posting darauf zurück.

Eine Frist nicht zu setzen signalisiert Kunden und anderen Projektbeteiligten übrigens, dass die Lieferung im Zweifelsfall einen Tag vor Deadline erfolgen kann. Und das völlig zu recht.