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

Risikomanagement 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.