Skip to content

IT-Projektmanagement ...



Das Büchlein, Taschenbuch mit rund 200 Seiten, "IT-Projektmanagement" hat mir sehr gut gefallen. Es versucht das nahezu unmögliche: Einen Überblick über das Projektmanagement in der IT zu geben und das ist dem Autoren meiner Ansicht nach - mit einer Ausnahme (siehe weiter unten) - auch gelungen.

Der Schreib- und Erzählstil ist manchmal etwas "launisch", aber gerade das macht es zur kurzweiligen Lektüre.

Die Zielgruppe des Buches sind Projektleiter, damit zähle ich nicht dazu, da ich eher Projektmitarbeiter bin als Projektleiter. Trotzdem lohnt es sich immer, einen Blick über den Tellerrand zu werfen. Und auch als Projektmitarbeiter schadet es nicht, das "grössere Ganze" zu verstehen.

In dem Buch sind neben einer generellen Erklärung, wie Projekte funktionieren und wer und wie die einzelnen Rollen in einem Projekt besetzt auch eine grosse Anzahl von sehr wertvollen Praxistipps zu finden.

Dem Umfang ist geschuldet, dass nicht auf verschiedene Projektmanagement-Methoden eingegangen wird, dafür lassen sich die Empfehlungen aber auch Methoden-übergreifend verwenden. Ein kurzer Ausflug zum agilen Projektmanagement rundet das Buch inhaltlich ab.

Was mir richtig gut gefallen hat, ist ein Phasenplan, der bei der Planung eines Projektes helfen kann.

Kommen wir zum einzigen grossen Kritikpunkt, den ich habe. Den Autoren habe ich per E-Mail informiert, aber leider noch keine Antwort bekommen.

Das, was mir nicht so gut gefällt, ist, dass es in dem Buch leider vorrangig um Softwareprojekte und dort auch nur um den Entwicklungsteil geht, meiner Erfahrung nach laufen die Soft- und Hardwareentwicklung parallel, genauso wie Performance-Tuning von beiden "Gewerken" ausgeführt wird.

Im Rahmen meiner beruflichen Laufbahn habe ich einige Projekte und Teilprojekte erfolgreich zum Abschluss gebracht. Meine Hauptarbeitsgebiete sind aber System Engineering and Administration, früher auch Database Administration, daher achte ich natürlich auch genau darauf.

Leider ist es so, dass die IT aus (wenigstens) zwei "Welten" besteht, die oft sehr getrennt von einander agieren, erst das Modell der DevOps bringt die beiden Welten zusammen. Es gibt verschiedene Anforderungen. Das Software Engineering wird meiner Erfahrung nach meist durch die Featurewünsche ("funktionale Anforderungen") der Fachabteilungen getrieben und das System Engineering durch den Stabilitätswunsch, beide Bereiche teilen sich zu dem die "non-funktionale Anforderungen", hier insbesondere, aber nicht ausschliesslich, das Performance-Tuning.

Der Systembetrieb wird bei grösseren Projekten häufig vergessen, was auch oft dazu führt, dass Projekte in diesem Bereich eine Menge Reibungsverluste haben. System Engineering steht häufig in der Wertigkeit weit hinter dem Software-Engineering. Das sind meine Erfahrungen in verschiedenen Firmen.

Die unterschiedlichen Ausrichtungen zeigen sich auch im Buch. Die Phase nach Ende des Projektes wird als "Wartung" beschrieben, für mich ist das "Betrieb".

Die Zielplattform wird erst in Phase 10 aufgebaut, das ist für mich zu spät. Ich habe schon in Projekten mit Datenbankentwicklern zu tun gehabt, die das ständige Mantra vor sich hin murmelten, dass das alles unter Oracle anders funktionieren würde, Vorgabe war DB2.

Dass ich auf dieses "Reizthema" besonders reagiere, hat nichts mit der Qualität des Buches zu tun, es ist vielmehr ein allgemeiner Umstand, den ich sehr häufig antreffe.

Anmerkung: Ich habe das Buch kostenlos als Rezensionsexemplar bekommen.

Bücher für Projektmanager ...

Stefan Hagen fragt in seinem Blog Welche Bücher sollte man als PM gelesen haben? und startet eine entsprechende Umfrage auf Tricider. Das Resultat interessiert mich.

Tricider kannte ich vorher gar nicht, es scheint aber eine bessere Hilfe zur Entscheidungsfindung zu sein als Doodle. Doodle ist dafür bei der Terminfindung ungeschlagen.