Jedes Projekt ist individuell (sonst wäre es kein Projekt!). Damit ergibt sich auch eine individuelle Herangehensweise, welche sich jedes Mal neu erfinden muss. Richtig?
Falsch! Es muss nicht immer das Rad neuerfunden werden. Sicher, eine ganz individuelle Herangehensweise – jedes Mal von Grund auf neu – bietet optimale Chancen auf herausragende Projektergebnisse. Es steht nur niemals die Projektqualität (heißt Planungs- und Umsetzungsqualität) allein im Vordergrund, sondern auch die Wirtschaftlichkeit (Budget) und die Projektzeit (Meilensteine).
Diese Konflikte können auf verschiedene Art und Weise entschärft werden. Beispielsweise kann die Projektzeit mit Simultaneous Engineering gesenkt werden, die Ergebnis- und Prozessqualität dabei sogar gesteigert werden. Eine weitere Möglichkeit, welche den Einsatz von Simultaneous Engineering fördert, ist die Standardisierung.
Ishikawa-Diagramme dienen der Darstellung von Ursachen, die zu einer Wirkung führen und wurden vom japanischen Chemiker Ishikawa Kaoru 石川馨 erfunden. Die Wirkung kann positiv sein, meistens werden in Ishikawa-Diagrammen jedoch negative Wirkungen (Fehler) dargestellt, welche untersucht werden.
Ein alternativer Begriff für ein Ishikawa-Diagramm ist Ursache-Wirkung-Diagramm (bzw. engl. Cause and Effect Diagram).
Diese Art der Diagrammgestaltung soll Ursachen darstellen, die zu einem definierten Fehler führen. Ishikawa-Diagramme finden daher insbesondere Anwendung im Qualitätsmanagement. Auch in Fachbereichen, welche sehr viele Faktoren bzw. Parameter berücksichtigen müssen, beispielsweise die Fertigung und Logistik, sind Ishikawa-Diagramme eine verbreitete Technik zur Veranschaulichung.
Ishikawa-Diagramme sind beispielsweise eine häufige Methode zur Analyse-Darstellung von Fehlerursachsen im Sinne von Poka Yoke in der Fertigung.
Stellen Sie sich vor, Sie kommen an Ihren neuen Arbeitsplatz, freuen sich auf neue Aufgaben, bei denen Sie bereits wissen, was Sie tun sollen,…. nur es fehlen Ihnen die Zielvorgaben.
Ein mögliches Szenario wäre beispielsweise, dass Sie sich als Programmierer mit einer neuen Entwicklungsumgebung beschäftigen sollen oder als Einkäufer mit Methoden der Lieferantenentwicklung.
Etwas Entscheidendes fehlt hier: Klare Zielvorgaben!
Ziele müssen Mitarbeitern vorgegeben oder – besser – mit ihnen vereinbart werden. Von den Zielen und der Zielerreichung betroffene Mitarbeiter sollten an der Zieldefinition mitwirken können, denn sie sind die ausführende Kraft und in der Regel, wenn die Stelle richtig besetzt wurde, die wirklichen Experten für die Zielerreichung, auf deren Meinung und Erfahrung nicht verzichtet werden sollte. In der Arbeitswelt findet sich schnell Resignation gegenüber „Denen da oben“, welche wenig Einsicht in die Umsetzungspraxis haben, aber ohne Rücksprache – zum Teil unrealistische – Ziele vorgeben.
Vorgesetzte sollten Ziele also nicht alleine definieren und auch nicht einfach die Aufgaben zur Zielerreichung auf Mitarbeiter ohne ihre Mitwirkung herunterbrechen. Den Mitarbeitern muss es organisatorisch ermöglicht werden, Feedback bereits zur Zeit der Zieldefinition geben zu können und sie müssen für Feedback motiviert werden, denn dann fühlen sie sich für die Sinnhaftigkeit und Erreichung von Zielen mitverantwortlich.
Ziele müssen über alle Hierarchieebenen besprochen werden. Es reicht nicht aus, wenn die Geschäftsführung Oberziele definiert, diese jedoch nicht in Teilzielen gegliedert die untersten Hierarchieebenen erreichen.
Wissensmanagement (engl.: Knowledge Management) ist die methodische Unterstützung, Steuerung und Kontrolle von Prozessen zum Ausbau von Wissensbasen einer Organisation oder Person. Wissensbasen sind Informationen und deren Interpretation, die zur Lösung von Problemen notwendig oder hilfreich sind. Gutes Wissensmanagement ist zwingend Bestandteil gutem Innovationsmanagements.
Der harte Kern jeden Wissens sind Daten, welche mit einer Bedeutung versehen, Informationen sind. Informationen ergeben Wissen, wenn diese aus einem bestimmten Kontext heraus interpretiert werden (können) und entsprechend darauf reagiert werden kann.
Ziele des Wissensmanagement sind:
Förderung der Aneignung von neuem Wissen
Beispielhafte Leitfrage: „Wie können unsere Mitarbeiter den Umgang mit neuen Verfahren lernen?“
Schaffung von Möglichkeiten zur Nutzung von bestehendem Wissen
Beispielhafte Leitfrage: „Welche Organisation fördert innovatives Denken?“
Verhinderung von Verlust des Wissens
Beispielhafte Leitfrage: „Wie kann ein Know-How-Verlust trotz Fluktuation verhindert werden?“
Projektmanagement befasst sich mit vielen Zahlen, die Aussagen (Eigenschaften wie Kosten, Anzahl, Größe usw.) über Komponenten (Aufgaben, Prozesse, Teile, Produkte, Module usw.) der Projekts treffen.
Um den Überblick zu behalten und Entscheidungen treffen (und rechtfertigen) zu können, ist es notwendig, die Zahlen miteinander zu verknüpfen, so dass die Werte der Komponenten veranschaulicht werden.
Dafür sollten die Komponenten in Klassen aufgeteilt werden, klassischerweise in drei Klassen A, B und C (daher ABC-Analyse), aber auch eine Aufteilung in mehr als drei Klassen ist denkbar.
Projektstrukturpläne (DIN 69901) sind eine Form von Organigrammen und dienen der Projektplanung als Basisinformationsquelle. Auf Grundlage der Projektstrukturpläne wird die Terminplanung, die Ablauffestlegung und Projektkostenplanung gemacht, die Projektstruktur wird in dieser Form in der Regel in das Pflichtenheft übertragen und spiegelt sich gegebenenfalls in der Gliederung des Pflichtenhefts und weiterer projektzugehöriger Dokumentationen wieder.
Projektstrukturpläne bestehen aus mehreren Gliederungsebenen und Arbeitspaketen. Arbeitspakete sind die Einheiten, welche in der untersten Ebene eines Projektstrukturplans vorgeben, was gemäß einer Spezifikation zu tun ist. Für Arbeitspakete muss es demnach eine klar abzugrenzende Spezifikation geben, für die Erfüllung nur ein Verantwortlicher unterstellt sein darf.
Ebenen-Einheiten, welche Arbeitspakete beinhalten, werden als Teilaufgaben angesehen.
Die Arbeitspakete sollten gegenüber der Projektlaufzeit/-größe nicht zu groß sein, jedoch ein genügendes Arbeitsvolumen umfassen, welches einer oder mehrerer Projektphasen gleich kommt. Risikoreiche Arbeitspakete (z. B. wegen fehlender Erfahrung auf dem Gebiet) sollten jedoch überschaubar klein gehalten sein, während Arbeitspakete, welche eher Routinetätigkeiten beinhalten, auch größer ausfallen dürfen.
Dass ein Arbeitspaket einer eigenen Projektphase zuordenbar ist, gilt als besonders gut planbar und sehr zu empfehlen, ist in der Praxis aber nicht immer umsetzbar.
Die Aufstellung eines Projektstrukturplans erfolgt:
Komplexe Aufgabenstellungen, die innerhalb eines zeitlichen Rahmens zu lösen sind, lassen sich nicht von einer einzelnen Personen und ohne Planung lösen. Projekte werden daher nach einem, von mehreren Personen geschaffenen System aus Arbeitsteilung angegangen. Nach diesem System werden die nötigen Ressourcen beschafft, kombiniert und koordiniert.
Dieses von Menschen erschaffene System wird als Management bezeichnet. Das Wort „Management“ kommt aus dem Englischen (bzw. ursprünglich aus dem Lateinischen) und hat merkwürdigerweise keine eindeutige deutsche Übersetzung gefunden. Ich würde „Management“ als „Verwaltung und Führung“ übersetzen, „Projektmanagement“ könnte man daher mit „Projektführung und -verwaltung“ übersetzen. Projekt-Management bedeutet in diesem Sinne projektzielgerichtete Planung und Organisation [Verwaltung] sowie Führung mit Kontrolle über die Projektdurchführung.
Projekt-Management wird ferner auch nach der DIN 96901 als Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln zur Abwicklung eines Projektes definiert.
Projekt-Management ist eine Organisation des Projekts, welche selbst (idealerweise vor Beginn der Kernprozesse) entwickelt werden muss, insbesondere im Hinblick auf Entscheidungs-, Arbeits- und Kommunikationsschritte. Dafür müssen die Personen, welche die projektleitenden Positionen einnehmen, über Wissen um Projektmanagementmethoden verfügen und Führungskompetenzen haben. Die Projektleiter (oder Projektmanager) müssen Projektmanagementmethoden beherrschen und auch über Sozialkompetenz und Fachkompetenz verfügen.
Dem Projektleiter wird die Verantwortung über das Projekt, der Koordinierung aller Ressourcen und der termingerechten Realisierung aller Ziele des Projekts zugewiesen. Zu den Aufgaben des Projektleiters zählen z. B. die Definition der Projektzielsetzung, Erstellung des Projektauftrags, Kommunikation mit den Auftraggebern und der Abstimmung der Ziele und Konditionen mit diesen. Der Projektleiter vertritt das Projekt nach außen (innerbetrieblich und extern) und ist zentraler Verbindungspunkt auch für Projektmitarbeiter. Der Projektleiter sorgt für die Klärung notwendiger Ressourcen und sorgt auch für deren Bereitstellung und Koordination für das Projekt. Grundsätzlich ist auch Aufgabe des Projektleiters, ein Projektteam zu bilden. Um die Handlungsfähigkeit des Projektleiters zu ermöglichen, muss er einen direkten Draht zur Geschäftsführung (Bezüglich Auftrag und dessen Abwicklung) und der Personalabteilung pflegen können.
Diplom Informatiker Pascal Mangold stellt in seinem kurzbündigem Buch IT-Projektmanagement kompak seine Erfahrung im IT-Projektmanagement vor und gibt reichliche Tipps mit garantierten „Aha-Effekten“.
Das Buch ist keinesfalls ein sachliches, wissenschaftliches Buch, sondern ein locker geschriebener Ratgeber, bei dem man merkt, dass der Autor Erfahrung mitbringt, diese aber leicht nachvollziehbar weitergeben möchte. Das Preis-Leistungsverhältnis (etwa 10-15 Euro für 108 unterhaltsame Seiten) halte ich für noch gut. Das Buch ist mittlerweile in der 3. Auflage zu haben, ich habe noch die 2. Auflage, auf welche sich diese Rezension bezieht.
Wer in der Software-Entwicklung gearbeitet oder mal ein paar Projekte auch nur miterlebt hat, wird sich zu vielen beschriebenen Situationen im Buch immer wieder „das kenne ich doch!“ denken. Dieses Büchlein ist daher in vielen deutschen Büros, vornehmlich von Projektleitern, zu finden. So hatte auch der Projektleiter bei meinem letzten Arbeitgeber dieses Buch als Pausenlektüre.
Mein Fazit für dieses Buch und allgemein für die Projektleitung: Man lernt etwas mit diesem Buch, jedoch nur, wenn man die dazugehörige Eigenerfahrung sammelt. Mit dem Buch wird man sich die bewusste und vor allem unbewusste Erfahrung noch mal vor Augen führen und ein zweites Mal (und diesmal garantiert bewusst) verarbeiten und als etwas Gelerntes abspeichern.
Das Buch ohne zugehörige Erfahrung zu lesen, ist vielleicht unterhaltsam und bereitet ein bisschen auf Projektmanagement vor, in die meisten Projektfallen wird man als Newbie aber sicherlich auch mit dieser Lektüre noch treten.
Dennoch findet man viel Wahrheit, die auch schon oder gerade im Vorfeld (also vor einem Projekt) nützlich ist, zusammenfassend als Zitat aus dem Buch…
Projekte scheitern nicht an Technik, sondern an Menschen und ihrem Glauben, irgendwie ließe sich jedes Ziel schon erreichen. Oft gibt es nicht einmal ein Ziel, geschweige denn, ein gemeinsames.
