| Der Titel klingt etwas morbide - Post Mortem. Als Softwareentwickler kennt man den Begriff aus der Welt des Debuggens, "Post Mortem" bedeutet Fehler suchen, nachdem ein Programm abgestürzt ist. Dieses Buch befasst sich nun aber nicht mit der Fehlersuche in der Software - sondern letztlich mit einer Art Fehlersuche im Projekt.
Es geht dem Autor hier darum nach Abschluß eines Software-Projekts die gemachten Erfahrungen zu sammeln und zu verarbeiten, bevor es weiter zum nächsten Projekt geht. Wichtig ist dabei sein Ansatz, daß es aus jedem Projekt etwas zu lernen gibt! Ist ein Projekt gescheitert, so kann man lernen warum es scheiterte - aber auch in solchen Projekten gab es Dinge, die gut funktionierten. Welche waren dies? Und bei erfolgreichen Projekten läuft es auch anders herum: nicht alles hat gut geklappt. Vor allem interessiert doch auch, warum dieses Projekt erfolgreich war. Warum gerade dieses? Was war der wesentliche Punkt? Denn diesen zu erkennen verhilft auch in der Zukunft zu erfolgreichen Projekten.
Das Buch ist vom Thema her eher trocken, aber durch die Erzählung aus der ich-Perspektive heraus bleibt es flüssig lesbar.
Der Autor versucht vor allem durch Fallbeispiele und die Vorbereitung von fiktiven Abschlußgesprächen dem Praktiker Hilfsmittel und Werkzeuge an die Hand zu geben. Ausführlich geht er dabei auch auf die persönlichen Konflikte zwischen Projektteilnehmern und die Konflikte zwischen Mitarbeitern und den Auftraggebern/Geschäftsleitung ein, einige der hier geschilderten Konflikte werden beim Leser sicherlich zu Aha-Effekten oder Wiedererkennungseffekten führen.
Für Personen mit Verantwortung für Softwareprojekte sicherlich lesenswert. Zu beachten ist allerdings, daß der Autor von relativ großen Projektteams ausgeht - die meisten Leute werden mit wesentlich kleineren Teams arbeiten. Trotzdem sind nützliche Informationen zu finden.
| 
