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.

Warum überhaupt "undogmatisch"?

Wenn Techniker über Projektmanagement reden oder schreiben geht es in der Regel um Vorgehensmodelle - was heute Agile Development ist, war vor ein paar Jahren der Rational Unified Process (kennt den überhaupt noch jemand?) und in der Computersteinzeit das Wasserfallmodell, das sich nach wie vor großer Beliebtheit erfreut (es ist also sozusagen der Quastenflossler unter den Projekt-Management-Moden...). Zu Phasen, Prozessen, Erhebung von Anforderungen, Architekturen und dergleichen mehr möchte ich mich aber eher weniger auslassen (deshalb habe ich mir erlaubt dieses Blog als undogmatisch zu bezeichnen), das können andere besser.

Tatsächlich gibt es Grundprinzipien und Tricks die unabhängig vom Vorgehensmodell in IT-Projekten immer mal wieder wichtig werden und die gerade für Einsteiger ausgesprochen hilfreich sind. Während ich versucht habe, zumindest einige davon zu formulieren, ist mir aufgefallen, wie schwer es ist sie griffig zusammenzufassen. Vielleicht ist genau das der Grund dafür dass man sie so selten liest. Einige Beispiele worum es geht:

• Festpreisangebote ohne ausreichendes Briefing
• Kundenführung
• Die "Hidden Agenda" des Kunden und der Projektkollegen
• Projektpolitik. Wie hält man den Hof sauber? (ein echtes ÄhBäh-Thema, was ein echter Tekkie ist steht über solchen Dingen. Aber wartet ab bis ich was dazu schreibe...)
• Richtiges Eskalieren
• Was tun wenn es eng wird?

Kickoff

Es geht los, mein erster Post in meinem ersten eigenen Blog. Es hat eine Weile gedauert bis ich mir über die Antwort auf die Frage im Klaren war die sich der eine oder andere Blogger sicher schon gestellt hat: Habe ich der Welt irgend etwas mitzuteilen? Etwas das interessanter ist als der Umstand, dass mir gestern ein Glas Milch umgekippt ist?

In meinem Fall habe ich mich entschlossen über Technisches Projektmanagement im Allgemeinen und in Bezug auf Online-Projekte im Besonderen zu schreiben, weil das nicht nur mein Mitteilungsbedürfnis befriedigt sondern vielleicht sogar für andere einen Nutzwert hat. Ich mache seit 12 Jahren Online-Projekte, davon 3 als Entwickler, 4 als Technischer Projektmanager und 5 als Teamleiter der immer noch Projekte macht. Da muss ja was hängengeblieben sein was relevant ist.