IT-Projektmanagement Das Buch „IT-Projektmanagement“ von Andreas Kitz wendet das umfangreiche Thema des Projektmanagements auf den speziellen Bedarf von Softwareentwicklungen an. Warum diese Thematik gerade in IT-Projekten so stiefmütterlich behandelt wird, weiß sicher niemand mit letzter Gewissheit zu sagen. Daß es bei der Durchführung von Projekten gebraucht wird, könnte man an hinreichend vielen Beispielen zeigen. Ein eindrucksvoller Beweis dafür ist der sogenannte „Chaos Report“ der Standish Group von 1995. Damals wurde festgestellt, daß gerade mal 31% der begonnenen Softwareentwicklungen auch mit Erfolg beendet wurden. Die weitaus größere Anzahl an begonnenen Projekten überschritten entweder deutlich ihr Budget, oder wurde bereits vor Abschluß eingestellt. Gerade bei IT-Projekten sind nämlich die Ursachen eines möglichen Mißerfolgs meist schon vor dem eigentlichen Entwicklungsbeginn zu suchen. Durch eine unzureichende Absprache mit dem Auftraggeber, grobe Fehleinschätzungen des Arbeitsaufwand oder eine mangelnde Spezifikation des Produkts, kann ein Projekt schon vor der Realisierung zum Scheitern verurteilt sein. Aber auch nach einer ausgezeichneten Vorbereitung können schlechtes Controlling und unzureichende Qualitätsprüfungen während der Projektdurchführung das Scheitern eines Projekts bedeuten. Im vorliegenden Buch bemüht sich nun der Autor, Andreas Kitz, die wesentlichen Grundbegriffe des IT-Projektmanagements anzusprechen. Was dabei herauskommt ist ein ganz interessanter Vortrag über die Möglichkeiten und Verfahren eines gesteuerten Projektmanagements. Somit dürfte auch direkt klar sein, daß dieses Buch an Einsteiger auf dem Themengebiet Projektmanagement adressiert ist. Wer ernsthaft an Ansätzen und Theorien auf diesem Gebiet interessiert ist, sollte zu einem anderen Buch greifen. Unerfahrene Leser werden aber dank der sehr prosaischen Beschreibung schonend mit dem Thema bekannt gemacht. Dabei beginnt der Autor zunächst mit einer Beschreibung der harten Projektziele, um auch nochmals jedem Leser klar zu machen, daß gleichermaßen die Vollendung des Projekts, aber auch die Kosten, das Einhalten eines Termins, sowie die Qualität im Vordergrund einer jeden Planung stehen müssen.Die folgenden Beschreibungen zur Organisation eines Projekts bilden meiner Meinung nach den Kern des Buches und lesen sich auch ganz interessant. Endlich werden einmal die Rollen innerhalb einer Projektgruppe übersichtlich spezifiziert. Das verschafft gemeinsam mit den Beschreibungen des Projekt-, Qualitäts- und Konfigurationsmanagements einen guten ersten Einblick in den Ablauf eines realen IT-Projektmanagements. Die restlichen Teile des Buches lesen sich dann leider ein wenig enttäuschend. Ich kann weder der Dokumentbeschreibung noch den Textfetzen zur „menschlichen Komponente“ etwas abgewinnen.Das verheißungsvolle Kapitel „Softwareentwicklung in der Praxis“ spiegelt zwar einen mehr oder weniger chronologischen Ablauf eines realen Projekts mit den eingesetzten Maßnahmen wieder, wärmt aber im Prinzip lediglich die vorangehenden Kapitel auf. Es fallen sehr viele Stichwörter, auf die dann allerdings selten detailiertere Beschreibungen folgen. Kernpunkt meiner Kritik zu den letzteren Teilen des Buches ist einfach, daß man mit vielen der angesprochenen Stichwörter einfach nichts anfangen kann. Was hilft es zum Beispiel eine Menge an Schätzmethoden namentlich zu kennen, ohne deren Verwendung an einem Beispiel oder einer längeren Beschreibung aufgezeigt zu bekommen. An anderer Stelle könnte es ziemlich frustriert sein, eine zweiseitige Zusammenfassung zu UML zu lesen, wenn man sich über die Anwedungsfälle nicht im klaren ist. Die Dokumentbeschreibung betreffend, findet sich eine ähnliche Situation. Als Einsteiger finde ich jede Menge Dokumente deren Verwendung mir auch nach dem kurzen einführenden Satz verschlossen bleibt. Als Sachkundiger kann ich nur über den Versuch lächeln ein Pflichtenheft auf zwei Seiten spezifizieren zu wollen. Man könnte darüber den Eindruck gewinnen, daß es dem Autor zwar wichtig war, alle Stichwörter des IT-Projektmanagements einmal anzuschneiden, ohne jedoch als Konsequenz daraus ein wenig weiter ins Detail gehen zu wollen. Positiv erwähnenswert sind noch die jeweils am Kapitelende zusammengefaßten Probleme/Gegenmaßnahmen, die sich aus der gerade besprochenen Thematik ergeben. In einer einfachen tabellarischen Form faßt der Autor kurz Konfliktfälle mit den entsprechenden Gegenmaßnahmen und Konsequenzen zusammen. In der Praxis könnte man solche Tabellen tatsächlich dazu benutzen, um im entsprechenden Konfliktfall einen ersten Lösungsansatz zu finden. Zu dem Buch „IT-Projektmanagement“ bleibt abschließend eigentlich nur zu sagen, daß es zwar unterhaltsam, aber nicht zwingend notwendig ist. Vielleicht ist es recht gut plaziert, um Einsteigern die Bedeutung eines wohlorganisierten Projekts klar zu machen. Aber beim besten Willen: Ich kann mir einfach nicht vorstellen, daß man unerfahrene Einsteiger mit der Planung eines umfangreichen Projekts betraut. In der Regel werden zu diesem Zweck spezialisierte Mitarbeiter eingesetzt. Diese sollten einen differenzierteren Zugang zu der Thematik haben, als das Buch auf die Schnelle vermitteln kann. In kleineren Projekten lohnt eine Vorgehensweise nicht, wie sie im Buch vorgestellt wird. Somit bleibt immer noch die Frage des Selbstzwecks offen ...

Das Buch „IT-Projektmanagement“ von Andreas Kitz wendet das umfangreiche Thema des Projektmanagements auf den speziellen Bedarf von Softwareentwicklungen an. Warum diese Thematik gerade in IT-Projekten so stiefmütterlich behandelt wird, weiß sicher niemand mit letzter Gewissheit zu sagen. Daß es bei der Durchführung von Projekten gebraucht wird, könnte man an hinreichend vielen Beispielen zeigen.

Ein eindrucksvoller Beweis dafür ist der sogenannte „Chaos Report“ der Standish Group von 1995. Damals wurde festgestellt, daß gerade mal 31% der begonnenen Softwareentwicklungen auch mit Erfolg beendet wurden. Die weitaus größere Anzahl an begonnenen Projekten überschritten entweder deutlich ihr Budget, oder wurde bereits vor Abschluß eingestellt. Gerade bei IT-Projekten sind nämlich die Ursachen eines möglichen Mißerfolgs meist schon vor dem eigentlichen Entwicklungsbeginn zu suchen. Durch eine unzureichende Absprache mit dem Auftraggeber, grobe Fehleinschätzungen des Arbeitsaufwand oder eine mangelnde Spezifikation des Produkts, kann ein Projekt schon vor der Realisierung zum Scheitern verurteilt sein. Aber auch nach einer ausgezeichneten Vorbereitung können schlechtes Controlling und unzureichende Qualitätsprüfungen während der Projektdurchführung das Scheitern eines Projekts bedeuten.

Im vorliegenden Buch bemüht sich nun der Autor, Andreas Kitz, die wesentlichen Grundbegriffe des IT-Projektmanagements anzusprechen. Was dabei herauskommt ist ein ganz interessanter Vortrag über die Möglichkeiten und Verfahren eines gesteuerten Projektmanagements. Somit dürfte auch direkt klar sein, daß dieses Buch an Einsteiger auf dem Themengebiet Projektmanagement adressiert ist. Wer ernsthaft an Ansätzen und Theorien auf diesem Gebiet interessiert ist, sollte zu einem anderen Buch greifen. Unerfahrene Leser werden aber dank der sehr prosaischen Beschreibung schonend mit dem Thema bekannt gemacht.

Dabei beginnt der Autor zunächst mit einer Beschreibung der harten Projektziele, um auch nochmals jedem Leser klar zu machen, daß gleichermaßen die Vollendung des Projekts, aber auch die Kosten, das Einhalten eines Termins, sowie die Qualität im Vordergrund einer jeden Planung stehen müssen.Die folgenden Beschreibungen zur Organisation eines Projekts bilden meiner Meinung nach den Kern des Buches und lesen sich auch ganz interessant. Endlich werden einmal die Rollen innerhalb einer Projektgruppe übersichtlich spezifiziert. Das verschafft gemeinsam mit den Beschreibungen des Projekt-, Qualitäts- und Konfigurationsmanagements einen guten ersten Einblick in den Ablauf eines realen IT-Projektmanagements. Die restlichen Teile des Buches lesen sich dann leider ein wenig enttäuschend. Ich kann weder der Dokumentbeschreibung noch den Textfetzen zur „menschlichen Komponente“ etwas abgewinnen.Das verheißungsvolle Kapitel „Softwareentwicklung in der Praxis“ spiegelt zwar einen mehr oder weniger chronologischen Ablauf eines realen Projekts mit den eingesetzten Maßnahmen wieder, wärmt aber im Prinzip lediglich die vorangehenden Kapitel auf. Es fallen sehr viele Stichwörter, auf die dann allerdings selten detailiertere Beschreibungen folgen.

Kernpunkt meiner Kritik zu den letzteren Teilen des Buches ist einfach, daß man mit vielen der angesprochenen Stichwörter einfach nichts anfangen kann. Was hilft es zum Beispiel eine Menge an Schätzmethoden namentlich zu kennen, ohne deren Verwendung an einem Beispiel oder einer längeren Beschreibung aufgezeigt zu bekommen. An anderer Stelle könnte es ziemlich frustriert sein, eine zweiseitige Zusammenfassung zu UML zu lesen, wenn man sich über die Anwedungsfälle nicht im klaren ist. Die Dokumentbeschreibung betreffend, findet sich eine ähnliche Situation. Als Einsteiger finde ich jede Menge Dokumente deren Verwendung mir auch nach dem kurzen einführenden Satz verschlossen bleibt. Als Sachkundiger kann ich nur über den Versuch lächeln ein Pflichtenheft auf zwei Seiten spezifizieren zu wollen. Man könnte darüber den Eindruck gewinnen, daß es dem Autor zwar wichtig war, alle Stichwörter des IT-Projektmanagements einmal anzuschneiden, ohne jedoch als Konsequenz daraus ein wenig weiter ins Detail gehen zu wollen.

Positiv erwähnenswert sind noch die jeweils am Kapitelende zusammengefaßten Probleme/Gegenmaßnahmen, die sich aus der gerade besprochenen Thematik ergeben. In einer einfachen tabellarischen Form faßt der Autor kurz Konfliktfälle mit den entsprechenden Gegenmaßnahmen und Konsequenzen zusammen. In der Praxis könnte man solche Tabellen tatsächlich dazu benutzen, um im entsprechenden Konfliktfall einen ersten Lösungsansatz zu finden.

Zu dem Buch „IT-Projektmanagement“ bleibt abschließend eigentlich nur zu sagen, daß es zwar unterhaltsam, aber nicht zwingend notwendig ist. Vielleicht ist es recht gut plaziert, um Einsteigern die Bedeutung eines wohlorganisierten Projekts klar zu machen. Aber beim besten Willen: Ich kann mir einfach nicht vorstellen, daß man unerfahrene Einsteiger mit der Planung eines umfangreichen Projekts betraut. In der Regel werden zu diesem Zweck spezialisierte Mitarbeiter eingesetzt. Diese sollten einen differenzierteren Zugang zu der Thematik haben, als das Buch auf die Schnelle vermitteln kann. In kleineren Projekten lohnt eine Vorgehensweise nicht, wie sie im Buch vorgestellt wird. Somit bleibt immer noch die Frage des Selbstzwecks offen ...

geschrieben am 20.05.2005 | 716 Wörter | 4648 Zeichen