The Deadline

The Deadline von Tom DeMarco ist ein wahrer Klassiker der Projektmanagementliteratur. Ich hatte das Buch schon vor längerem gekauft, aber im Regal einstauben lassen, obwohl ich sein Buch Peopleware mochte. Stellt sich heraus, daß das ein Fehler war. Das Einstauben lassen, nicht der Kauf.

Es ist ein Softwareprojektmanagementbuch, das sich als Roman verkleidet hat. Und auch wenn es flüssig zu lesen ist, und oftmals auch witzig, so hat es als Roman doch wenig Wert. Aber diese Verpackung macht es deutlich leichter durchzuhalten.

Unser Protagonist ist ein Projektmanager, der kürzlich seinen Arbeitsplatz verloren hat, weil er zu viel Wahrheit ausgesprochen hat. Er wird von einer charmanten jungen Frau entführt, die für ein aufstrebendes früheres Ostblockland, das fiktive Monrovia, und dessen Softwareindustrie Talente „anwirbt“.

Monrovia hat jede Menge Softwareentwickler, einige Manager und das Ziel, größter Softwarelieferant der Welt zu werden. Sechs Softwareprodukte sind bereits geplant (allesamt Nachahmungen von Bestsellern wie Photoshop), und nun soll die Vision umgesetzt werden.

Außerdem wollen unser Protagonist und seine Manager einige Experimente am echten Softwareprojekt anstellen: mit je drei Teams für jedes der sechs geplanten Produkte können verschiedene Herangehensweisen verglichen und meßbar gemacht werden.

Der Roman führt in jedem Kapitel ein neues Problem ein (persönliche Konflikte zwischen Entwicklern oder enge Deadlines). Dazu kommt jeweils eine neue Person, die meistens ein weltberühmter Experte auf dem gerade relevanten Gebiet ist, und die an einem Nachmittag mal eben die Schlüsselerkenntnis zur Lösung des aktuellen Problems liefert. Das ist offensichtlich einer der Gründe, warum das Buch als Roman versagt.

Dem Leser muß glasklar sein, daß diese Experten keine echten Experten sind, sondern Stellvertreterfiguren für Tom DeMarco, die seine Überzeugungen präsentieren. Das ist auch völlig in Ordnung, schließlich ist das Buch Tom DeMarcos Darstellung, aber der Leser darf sich da nicht verwirren lassen. Die Buchfiguren hängen an den Lippen dieser Experten, stellen niemals eine Empfehlung in Frage, finden niemals Spannungen oder Widersprüche zu den Empfehlungen anderer „Experten“. Der Leser darf sich nicht einlullen lassen und genauso verhalten.

Jedes Kapitel endet mit einer Kurzzusammenfassung, was unser Protagonist gelernt hat. Und dort finden sich einige Goldstücke. Diese sind nie wirklich detailliert, eher Gedankenanstöße. Allerdings wird für keine dieser Anregungen ein Ansatz eines Beweises gegeben, das sind reine Ratschläge des Autors, die man hinnimmt oder eben nicht.

Auch wenn die meisten Gedankenanstöße ziemlich offensichtlich waren, manche sogar trivial, möchte ich ein paar davon hier wiederholen. Einige sind wichtig und waren mir zumindest teilweise neu. Andere waren mir nicht neu, aber sprachen besonders zu mir, weil ich persönliche Erinnerungen habe, die damit zusammenhängen. Wieder andere lösten eigene Gedanken aus, die ich nicht verlieren möchte. Also hoffe ich, daß diese Notizen mir das Wichtigste kurz zusammenfassen, so daß ich das Buch nicht immer wieder erneut lesen muß.

Anonyme Geständnisse

Eine der frühen Lektionen ist, daß es eine anonyme Möglichkeit geben sollte, Probleme die Hierarchie hinauf zu melden. Im Buch wird dies als richtige Zeremonie dargestellt, in Anlehnung an die römisch-katholische Beichte.

Dieser Mechanismus ist natürlich nicht aufs Berichten eigener Fehlschläge und Versäumnisse beschränkt. Vermutlich führt er eher dazu, daß Probleme in Bereichen gemeldet werden, die der Meldende nicht direkt in seiner Kontrolle hat.

Eine interessante Wendung im Buch ist, daß der „Beichtvater“ stets ganz genau weiß, wer der anonyme Meldende ist. Das dürfte auch realistisch sein, es gibt immer nur eine beschränkte Zahl von Leuten mit Wissen ums Thema und keiner besseren Möglichkeit, dies zu melden. Der „Beichtvater“ läßt aber niemals durchblicken, daß er ziemlich genau ahnt, wer das war. Das ist wohl wichtig, denn sobald diese Illusion der Anonymität gebrochen wird, werden die Meldungen abebben.

Risikoverantwortlicher

Risikomanagment ist im Projekt von herausragender Bedeutung. Auch wenn jedes Projektteammitglied die Aufgabe hat, Risiken zu managen, so sollte es doch einen expliziten Risikoverantwortlichen geben. Dieser Risikoverantwortliche muß (mit Unterstützung des Projektteams natürlich) Frühindikatoren für wichtige Risiken identifizieren, lange bevor diese Risiken eintreten, und dann ständig nach ihnen Ausschau halten.

Gefahren des „das schaffen wir“

Auch wenn viele Manager eine „das schaffen wir“-Haltung gut finden, so birgt diese die Gefahr, daß das Projektteam dahingehend vorgespannt wird, Risiken und Probleme eher nicht die Hierarchie hinauf zu melden.

Produktivität steigern

Es gibt keine Potentiale für kurzfristige Produktivitätssteigerungen, denn jedes vernünftige Projektteammitglied hat diese „low-hanging fruits“ bereits längst eigenständig ausgeschöpft, um persönlichen Frust zu verringern.

Ich denke, das ist eine Übertreibung, denn manchmal kann das Management dabei helfen, daß der Einzelne sich traut, solche Zeitfresser eliminieren. Beispielsweise hat einer meiner Vorgesetzten vor vielen Jahren einmal die Regelung getroffen, daß wir Projektteammitglieder explizit Tageszeiten festlegen (und bekanntgeben!) durften, in denen sie nicht ans Telefon gehen. Außerdem durften wir „Bitte nicht stören“-Schilder an unserem Schreibtisch im Großraumbüro aufstellen. Die Wirkung war meiner Erinnerung nach eher gering, denn das waren unzureichende Mittel, die Grundursache anzugehen.

Bauchgefühl modellieren

In einem sehr interessanten frühen Kapitel modellieren die Führungskräfte von Monrovias neuer Softwareindustrie explizit ihre Bauchgefühle dazu, wie viel Wirkung Schulungen oder Personalfluktuation auf die Fertigstellungsrate haben. Das bedeutet nicht nur, Diagramme zu zeichnen, sondern ein tatsächliches Modellierungsprogramm auf dem PC zu verwenden und die internen Zustandübergänge zu quantifizieren.

Dies dient nicht nur dazu, diese Bauchgefühle anderen Mitgliedern des Führungsteams mitzuteilen und diese gegeneinander abzugleichen und zu verfeinern. Es erlaubt auch, echte im Projekt ermittelte Metriken einzusetzen und dadurch das eigene Verständnis der Auswirkungen zu verbessern.

Das war vermutlich die größte Lehre des Buchs für mich. Ich habe noch etwas Zweifel an der Praktikabilität, nicht nur dem quantitativen Teil, sondern auch der Fähigkeit, überhaupt ein halbrealistisches Modell aufzustellen, aber es sieht so aus, als ob es tatsächlich Tools zu diesem Zweck gibt, die verkauft und benutzt werden.

Menschen mögen

Die Menschen, mit denen man arbeitet, tatsächlich zu mögen, und nicht nur so zu tun als ob, erleichtert es, Gemeinsamkeiten zu finden und sie zu überzeugen.

Druck

Druck wird oft als Mittel benutzt, mehr Arbeitsergebnisse und noch mehr Produktivität herauszuholen. Er ist kein geeigneteds Mittel dafür. Aber Druck kann, sorgsam und nur kurzzeitig angewendet, dem Projektteam die erhöhte WIchtigkeit einer Aufgabe signalisieren. Er ist daher nicht an sich schlecht, aber wird üblicherweise in destruktiver Weise eingesetzt (unfokussiert: zu viel und zu lang).

Zudem üben Menschen Druck auf ihre Untergebenen aus, um ihren Vorgesetzten zu zeigen, daß sie alles in ihrer Macht stehende getan haben, um das (wohl verpaßte) Ziel zu erreichen.

Innere Zweifel

Die meisten Menschen haben ein paar innere Zweifel an ihren Fähigkeiten oder ihrer Intelligenz. Deshalb trauen sie sich nicht, etwas zu sagen, wenn ein Dokument unverständlich scheint, denn alle anderen scheinen es ja wunderbar zu verstehen. In Wirklichkeit haben vermutlich alle dieselben Gedanken, aber das Problem ist selbstverstärkend und dadurch wird es verdeckt.

Spezifikation

Die Mindestanforderung, damit ein Dokument als Spezifikation betrachtet werden kann, ist, daß es beiderlei besitzt:

Ich persönlich würde mindestens noch einen dritten Teil hinzufügen: Daten und (innerer) Zustand. Mit Datenstrukturen zu beginnen und erst dann Operationen auf ihnen zu definieren ist oftmals vorteilhaft.

Mehrdeutigkeiten verdecken Konflikte

Mehrdeutige Formulierungen in Spezifikationen kommen oft daher, daß noch ein unaufgelöster Konflikt zwischen Stakeholdern schwelt, und der Autor nicht klar und präzise sein kann, weil er den schwelenden Konflikt damit entscheiden würde.

Diese Erkenntnis war mir neu. Ich denke aber auch, daß viele Mehrdeutigkeiten in Spezifikation nicht aus Konflikten ohne Auflösung herrühren, sondern aus fehlenden Informationen. Warum kann der Auto nicht einfach herumfragen, bis er die Antwort kennt? Oftmals weil Entscheidungen, die zum Thema notwendig sind, noch nicht gefällt wurden und in der Verantwortung eines ganz anderen Teams liegen. In gewisser Weise kann man dies als Planungskonflikt bezeichnen, schätze ich, aber ich würde es dennoch nicht unter der Überschrift „Konflikt“ einsortieren wollen.

Personelle Besetzung

Beginnen Sie das Projekt mit wenigen Mitarbeitern und erstellen Sie ein ordentliches Design. Es können nicht mehr als eine Handvoll Projektteammitglieder sinnvoll mitarbeiten, denn in dieser Phase muß jeder einen Überblick über das Gesamtbild haben, es ist keine Spezialisierung möglich.

Wenn das Projekt in die Phasen kommt, in denen wohldefinierte Arbeitspakete individuell bearbeitet werden können (insbesondere Programmierung), dann erweitern Sie das Projektteam massiv.

Als Spätdazukommer in einem früheren Großprojekt erzählten mir Kollegen einmal, wie es vor meiner Zeit aussah. Das kleine Designteam war am Rotieren und erarbeitete am laufenden Band Spezifikation für die voll besetzten Teilprojektteams (ungefähr ein Dutzend Teams), aber sie waren damit natürlich heillos überfordert. Also saßen die Teams hauptsächlich herum und hatten nichts zu tun.

Andererseits weiß ich noch genau, daß ich es schade fand, nicht zu Beginn gleich dabeigewesen zu sein. So viele Entscheidungen hatten nicht nur in Design (und Sourcecode!) Niederschlag gefunden, sondern auch eine Art Folklore. Das ursprüngliche Designteam war weitergezogen und zu manchen Themen wußte niemand im Unternehmen mehr, warum bestimmte Richtungen eingeschlagen worden waren. Niemand mehr übrig, den man hätte fragen können.

Wut = Angst

Im Berufsleben zeigt niemand Angst, weil das peinlich wäre. Wut ist ein halbwegs akzeptables Ersatzgefühl, daher schlagen Menschen los, wenn sie Angst vor etwas haben.

Doch wenn jeder um diese Ersetzung weiß, dann wird dasselbe Gefühl der Peinlichkeit solche wütenden Ausbrüche unterdrücken.