|


| |
Ein Roman über Projektmanagement
Der renommierte Berater und Autor Tom DeMarco (u.a.
Spielräume. Projektmanagement
jenseits von Burn-out, Stress und Effizienzwahn) hat mit diesem Buch das absolut lesenswerte Meisterwerk vollbracht, ein
Lehrbuch über IT-Projektmanagement in einem spannenden Roman zu verpacken!
Vom Konzept her grob angelehnt an die Kurzgeschichten des Physikers George
Gamov, welcher in den dreißiger Jahren einen gewissen Mr. Tompkins in irreale
Welten entführte, in denen jeweils einzelne Gesetze der Physik so verdreht
sind, dass dadurch, didaktisch ungemein geschickt, die Bedeutung dieser Gesetze
dem Leser offenbar und verständlich wird.
So heißt denn auch der Held des Romans von DeMarco Mr. Webster Tatterstall
Tompkins, oder einfach nur Mr. T., seines Zeichens Projektmanager in der
IT-Branche. Die Geschichte beginnt mit der etwas trüben Aussicht des baldigen
Arbeitsplatzverlustes von Mr. T. Durch eine glückliche Fügung des Schicksals
wird er allerdings entführt (!) und soll fortan in einem fernen Phantasieland
(das frühere Ostblockland Morovien) ein Mega-Projekt leiten, welches einen fast
unmöglichen Termin einzuhalten hat. Von vornherein wird dieses Projekt
allerdings so ausgelegt, dass verschiedene Gruppen simultan an diesem Projekt
arbeiten, wobei unterschiedliche Managementstile ausprobiert werden - und daraus
Schlüsse über ein ideales Projektmanagement gezogen werden können. Genauer
gesagt handelt sich das Ganze um ein gigantisches Projektmanagementlabor! An
vielen Stellen des Buches merkt der in der IT-Branche erfahrenen Leser, dass die
geschilderten Geschehnisse - trotz des kreativen Rahmens, in denen sie spielen -
oft nur allzu real sind.
Mr. Tompkins notiert wichtige Einsichten stets in seinem eigens dafür
angelegten persönlichen Tagebuch, wobei diese Passagen in serifenloser Schrift
eigens hervorgehoben sind. Einige ausgewählte Einsichten sollen im folgenden
kurz dargestellt werden.
 | Vier Grundsätze guten Managements
Ganz nach DeMarco-Manier kommt auch für Mr. T an erster Stelle der
Mensch - mit allem, was dazugehört: Auswahl der richtigen Leute, Auswahl
der richtigen Aufgaben für diese, Motivation und Teamgeist. Das ist es, was
für ihn überhaupt 'Management' im besten Sinne des Wortes ausmacht. Zitat
(S. 24): "Alles andere sind Administrivialitäten". |
 | Sicherheit und Veränderung
Nur Menschen, welche sich sicher fühlen und keine Angst vor
Machtmissbrauch haben, sind auch offen für Veränderung. Veränderung ist
eine entscheidende Voraussetzung für erfolgreiche Projektarbeit. |
 | Negative Verstärkung
Drohungen motivieren nur bedingt zu höheren Leistungen.
Umgekehrt ergibt sich für den Drohenden die unangenehme und oftmals nicht
bedachte Konsequenz, die Drohung beim (evtl. unausweichlichen) Scheitern,
umsetzen zu müssen. |
 | Vorstellungsgespräch und Personalbeschaffung
Lebensläufe dienen nur zur Vorauswahl ("zum besseren
Mischen der Karten"). Worauf es in erster Linie ankommt, ist das
richtige Bauchgefühl - wobei "zwei Bäuche besser als einer
sind". Neu eingestellte Personen sollte man bitten, zuerst ein Projekt
zu leiten, dessen Anforderungsprofil sie auch früher schon gerecht werden konnten. |
 | Produktivitätsverbesserungen
Hier helfen keine Schnellschüsse, sondern nur langfristige
Investitionen. |
 | Risikomanagement
Projektmanagement bedeutet Risikomanagement. Über ursächliche
Risken (nicht bloß über deren negative Folgen) muss zu jedem Zeitpunkt
akribisch Buch geführt werden. Zusätzlich muss bei jedem möglichen Risiko
das allererste Symptom antizipiert werden können, durch das es sich
ankündigt. Evtl. sollte für diese Aufgabe sogar ein Risikobeauftragter
eingesetzt werden.
Generell ein Problem ist, dass schlechte Nachrichten ungern 'nach oben'
kommuniziert werden - was für ein erfolgreiches Projekt allerdings zwingend
notwendig ist. Zu diesem Zweck sollte ein anonymer Kanal eingerichtet
werden. |
 | Teamgeist
Betrachten Sie ein eingeschworenes Team als eines der
Projektergebnisse - und setzen sie es in dieser Zusammenstellung für neue
Projekte ein. |
 | Modellierung und Simulation des
Entwicklungsprozesses
Um die unentbehrlichen Instinkte der Manager untereinander
abzugleichen, zu kommunizieren und zu quantifizieren sowie sich selber über
Wechselwirkungen klar zu werden, sollten diese modelliert und die
Konsequenzen simuliert werden. Hier wird von DeMarco explizit
Toolunterstützung angeraten (ithink®). |
 | Pathologische Politik
Die Ausführungen DeMarcos zum Thema Politik sind besonders
aufschlussreich. Zuerst ein Zitat (S. 110): "Politik ist eine edle
Wissenschaft. Sie ist eine der wissenschaftlichen Disziplinen des
Aristoteles, der fünf Zweige der Philosophie. Da gab es die Metaphysik, die
Logik, die Ethik, die Ästhetik und die Politik. Die edle Wissenschaft der
Politik ist das, was wir drei in den letzten drei Monaten praktiziert haben.
Wir haben ein Gemeinwesen aufgebaut, in dem ein ethisches und harmonisches
Zusammenwirken zur Verwirklichung eines gemeinsamen Ziels möglich ist. Das
ist Politik. Wir sollten nicht den Fehler machen, Belok [der Böse, A.d.V.]
und alles wofür er steht, mit einem guten aristotelischen Begriff zu
adeln." Bingo! - Alles, was gemeinhin negativ mit 'Politik' bezeichnet
wird, wird fortan im Buch als 'pathologische Politik' bezeichnet. Diese
kommt in den besten Organisationen vor, da sich gemeinsame und persönliche
(insbesondere Macht-) Interessen überlagern - oder sogar entgegenstehen
(s.a. Wahnsinnskarriere).
Pathologische Politik hat im Kontext des Projektmanagements oftmals zur
Folge, dass Projekte heillos überbesetzt werden, um sich bei der
Nichteinhaltung v. Terminen genügend exkulpieren zu können. Zum optimalen
Staffing von Projekten kommt DeMarco aber später noch ausführlicher.
Leider ist es so, dass man pathologische Politik nicht von unten her heilen
kann - man kann allenfalls seine Zeit damit verschwenden, es trotzdem zu
versuchen - und schlimmstenfalls seine eigene Position dabei gefährden. Die
einzige Möglichkeit ist oftmals, der Sache zu trotzen - und zu warten.
Manchmal passiert dann doch das Unerwartete. |
 | Metriken
Hierbei zeigt DeMarco auf, wie mit Hilfe von Erfahrungen aus
früheren Projekten Produktivitätsberechnungen abgeleitet werden können.
Dabei müssen Maße für die Komplexität des zu entwickelnden Produktes
gefunden werden, um eine Vergleichsbasis zu haben und qualifizierte
Aufwands- und Zeitschätzungen abgeben zu können. |
 | Prozess und Prozessverbesserung
Gute Mitarbeiter bemühen sich um kontinuierliche
Prozessverbesserung - auch ohne offiziell aufgesetzte Programme. Im
Gegenteil kosten solche Programme Zeit und Geld. Mehr als ein Programm zur
Methodenverbesserung kann kein Projekt verkraften. Auch liegt die Gefahr bei
standardisierten Methoden darin, dass Abkürzungen übersehen werden.
Allerdings hat dies bei überbesetzten Projekten oft Methode, damit auch
jeder etwas zu tun hat... |
 | Leistungsverbesserungen
Die einzige Möglichkeit, die Leistung innerhalb eines Projektes
substanziell zu verbessern, liegt in der Ausdehnung der Entwurfsphase - auf
Kosten der Debuggingphase. Ersteres überkompensiert Letzteres. |
 | Druck
"Menschen unter Druck denken nicht schneller". Quintessenz
dieses Abschnittes ist, dass kurzzeitige Anspannungen und Mehrarbeit
produktivitätserhöhend wirken - längerfristig allerdings genau den gegenteiligen
Effekt erzielen. Auch hier gilt wieder, dass Manager deshalb so gerne zum Mittel
der Mehrarbeit greifen, um sich hinterher besser exkulpieren zu können. |
 | Zorn und Verachtung
Zorn und Verachtung wirkt oft ansteckend auf die jeweils darunter
liegenden Ebenen (Nachahmung). Geringschätzung der Mitarbeiter ist jedoch
weniger ein Zeichen deren Unzulänglichkeit - sondern der des Managers.
Größere Leistungen werden auf jeden Fall damit nicht erreicht.
"Straff und Taff" ist die Formel, nach der in gescheiterten
Unternehmungen diejenigen greifen, die für das Scheitern verantwortlich
sind. Was also oftmals dahintersteckt ist schlicht und ergreifend
Angst. |
 | Spezifikationen
Eine Spezifikation muss mindestens eine vollständige Aufzählung
der Ein- und Ausgaben enthalten. Weiterhin sollten alle Reaktionen
veranlassende Ereignisse aufgeführt sein. Die eigentliche Komplexität
eines Systems liegt in der Transformation der Ein- in Ausgaben, diese selbst
sind jedoch verhältnismäßig einfach. Mehrdeutigkeiten, Ungenauigkeiten
oder sogar Auslassungen deuten auf Interessenkonflikte innerhalb des die
Spezifikation erstellenden Teams hin. Allerdings neigen Menschen, die
solcherart Spezifikationen auszuwerten haben, den Fehler bei sich selbst zu
suchen. |
 | Konflikte
Bei Projekten an denen mehrere Parteien beteiligt sind, sind
Konflikte unvermeidlich und nicht etwa ein Zeichen für unprofessionelles
Verhalten. Wichtig ist vor allem, dass die Gewinnbedingungen aller
Parteien auf den Tisch kommen. Besonders anfällig ist die Phase der
Systementwicklung und -installation. Die meisten Organisationen verfügen
über schlechte Konfliktlösungsfähigkeiten. Im Buch wird die Möglichkeit
der Mediation erklärt. Schönes Zitat (S. 196): "Wir stehen beide auf
der gleichen Seite; es ist das Problem, das auf der anderen Seite
steht." Das stimmt insofern, als dass, wenn alle Parteien sich die
Gemeinsamkeiten sowie die Konsequenzen eines Scheiterns klarmachen,
diese meist eher an einer konstruktiven Lösung des Konflikts interessiert sind. |
 | Rolle des Katalysators
Dies ist wieder besonders spannend, da ein Beispiel für eine
sogenannte 'katalytische Persönlichkeit' gegeben wird. Diese bewirken eine
harmonische und produktives Zusammenarbeiten des Teams, was eine sehr
wichtige und wertvolle Rolle ist! (Vielleicht fallen dem einen oder anderen
ja Beispiele aus eigener Anschauung ein...) |
 | Mitarbeiterzahl
Dies halte ich persönlich - neben dem Kapitel über
pathologische Politik - für eines der Wichtigsten in dem Buch. DeMarco
beschreibt die ideale Personalausstattung in einem Projekt. Insbesondere
erklärt er, warum eine Überbesetzung in der Entwurfsphase meist absolut
kontraproduktiv ist - und man besser mit einem kleinen Kernteam starten
sollte. Der Hauptgrund ist der, dass die Verteilung der Arbeit an die
Mitarbeiter im Projekt, welches eines der Hauptaufgaben der Entwurfsphase
ist, isomorph zu der Unterteilung des Systems in seine Teile ist.
Insbesondere bei in der Anfangsphase überbesetzten Teams ergeben sich zwei
Effekte. Erstens können die Teammitglieder sowieso nicht effektiv
kommunizieren, da es einfach zu viele sind. Zweitens müssen möglichst
schnell alle beschäftigt werden, so dass der Schnellschuss der Aufteilung
die spätere funktionale (Produkt) und organisatorische (Team) Aufteilung
präjudiziert. Dieser Teufelskreis führt zu größtmöglichem Overhead
durch maximale gegenseitige Abhängigkeiten, Schnittstellenproblemen,
Redundanzen und Besprechungen, Meetings, Jour Fixes...
Ideal wäre eine Aufstockung erst dann, wenn die Entwurfsphase beendet ist
und eine klare Aufteilung möglich wird. |
 | Meetings
Halten Sie Meetings klein. Die einfachste Möglichkeit hierzu ist
eine vorab verschickte Tagesordnung, die auch garantiert eingehalten wird -
so dass keiner befürchten muss, etwas zu versäumen. |
Bezogen auf den Titel des Buches kommt in Mr. T. gegen Ende der schreckliche
Verdacht auf, "dass Projekte mit einem aggressiven Terminplan später
abgeschlossen werden, als das mit einem vernünftigeren Terminplan der Fall
gewesen wäre." (S. 223)
Zum Schluss noch ein Bonmot über den Gesunden Menschenverstand
(S. 261):
 | Ein Projekt braucht sowohl Ziele als auch Termine. |
 | Sie sollten sich voneinander unterscheiden. |
... und ein weiteres schönes Zitat (S. 212): "Nicht das, was wir nicht
wissen, bringt uns zu Fall ... sondern das, was wir fälschlicherweise zu wissen
glauben".
Damit es Ihnen nicht auch so geht, lesen Sie dieses Buch!
|