Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com Mit systematischen Projektmanagement zum Erfolg Eine Einführung in den internationalen Standard Was ist überhaupt ein Projekt? Inhalts- und Umfangsmanagement Terminmanagement Kostenmanagement Personalmanagement Beschaffungsmanagement Kommunikationsmanagement Risikomanagement Qualitätsmanagement Integrationsmanagement von Christoph Jeggle Eine Einführung in den internationalen Standard Viele Menschen beschäftigen sich mit Projektmanagement, gerade auch unter den Lesern dieses Newsletters. Der Begriff des Projektmanagements wird aber durchaus sehr unterschiedlich verstanden, basierend auf dem, wie Projekte erlebt werden. Für manche hat der Begriff vielleicht auch einen unangenehmen Beigeschmack, weil das letzte Projekt gerade in einem mittleren Desaster endete. Die Artikelreihe, die mit dieser Folge beginnt, versucht, Projektmanagement trotz der vielen unterschiedlichen Ansichten darüber eindeutiger zu fassen. Wer zunächst Definitionen sucht, ist bei der DIN immer gut aufgehoben. Auch das Projektmanagement ist hier genau definiert. Nach DIN 69901 umfasst Projektmanagement die „Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes“. Aber worin besteht denn diese Gesamtheit? Eine Möglichkeit, Projektmanagement in seiner Gesamtheit unabhängig von einzelnen Branchen zu erfassen, besteht in dem Ansatz des „PMBOK Guide“. Dieses vom Project Management Institute (PMI) herausgegebene Standardwerk versucht etwas sehr Mutiges. PMBOK ist die Abkürzung für Project Management Body of Knowledge, frei übersetzt „ Die Gesamtheit des Projektmanagementwissens“. Das erinnert ein wenig an die Versuche der sogenannten Enzyklopädisten des 18. Jhd., die sich zum Ziel gesetzt hatten, das gesamte damalige Wissen zusammenzutragen. Genauso wenig, wie die damaligen Versuche mit der Erweiterung des Wissens Schritt halten konnten, wird der „PMBOK Guide“ das gesamte Wissen über Projektmanagement wirklich erfassen können. Dennoch stellt er einen sehr interessanten Versuch dar, Projektmanagement branchenübergreifend und länderübergreifend systematisch, wissenschaftlich fundiert, aber dennoch nicht wirklichkeitsfremd darzustellen. Der „PMBOK Guide“ beschreibt die Prozesse und dazugehörigen Wissensgebiete des Projektmanagements. Mit diesen werden sich die folgenden Artikel beschäftigen. Bleiben wir in diesem Artikel zunächst bei den Grundlagen. Was ist überhaupt ein Projekt? Nicht alles, was Menschen geplant und organisiert tun, ist ein Projekt. Die Buchhaltung in einem Unternehmen sollte kein Projekt sein, sondern ein fortlaufender Arbeitsablauf, der sich beständig wiederholt. Die Einführung einer neuen Methode der Buchhaltung inklusive der dazugehörigen Software stellt allerdings ein Projekt dar, denn sie ist zeitlich begrenzt – irgendwann ist die Buchhaltung umgestellt – sie ist einmalig – die Umstellung der Buchhaltung wird in dieser Form im Unternehmen nie wieder durchgeführt – und sie führt zur Schaffung eines Produktes oder Dienstleistung – es sollte zumindestens festgelegt sein, was am Ende herauskommen soll. Natürlich gibt es Projekte, die zu keinem Ende zu kommen scheinen, und deren Ergebnis ungewiss und undefiniert erscheint. Das sind eben Beispiele für misslungene Projekte, aber widersprechen keineswegs der Definition. Diese Definition sei hier noch einmal zusammengefasst: Ein Projekt ist ein zeitlich begrenztes Vorhaben zur Schaffung eines einmaligen Produktes oder einer Dienstleistung*. Die zeitliche Begrenzung ist eine ganz entscheidende Eigenschaft eines Projektes. Ein Projekt will ein Ziel erreichen. Ist das Ziel erreicht, endet das Projekt. Das Setzen eines neuen Zieles im Anschluss daran bedeutet ein neues Projekt. Ein Arbeitsablauf oder Geschäftsprozess hingegen verfolgt kein spezifisches Ziel, sondern dient der Aufrechterhaltung z.B. eines Geschäftsbetriebes. Das Ziel eines Projektes ist einmalig. Es können ruhig sehr viele ähnliche Häuser in Fertigbauweise gebaut werden. Dennoch ist der Bau jedes Hauses einmalig, an einem eigenen Ort in einer eigenen Umgebung. Eben ist von den Zielen gesprochen worden, die mit einem Projekt erreicht werden sollen. Diese können am Anfang eines Projektes nicht vollständig und unveränderlich feststehen. Dazu sind fast alle Projekte zu komplex und mit zu vielen Unwägbarkeiten behaftet. Stattdessen muss dieses Ziel, das am Anfang nur in seinen Grundzügen oder vielleicht sogar nur als Idee feststeht, progressiv und iterativ immer weiter herausgearbeitet werden. Das bedeutet in keiner Weise, dass die Ziele unverbindlich sind. Aber am Anfang steht mehr die Vision und nicht das im Detail ausgearbeitete Ziel. Das entwickelt sich – immer orientiert an der anfänglichen Zielvorgabe – weiter, wird detaillierter und damit verbindlicher. Aber jeder, der mit Projektmanagement zu tun hat, weiss, dass die Realität oft anders aussieht. Auf einer DIN A4 Seite werden kurz die Ziele eines Projektes angerissen. Das muss als Zielvorgabe zunächst reichen, um damit einen detaillierten Projektplan einschließlich verbindlicher Kostenschätzung für das Budget zu erstellen. Dass das nicht funktionieren kann, weiß jeder und muss sich dennoch auf dieses „Spiel“ häufig einlassen. Daher bedeutet gutes Projektmanagement immer auch eine Verweigerung gegen diesen Versuch, aus dem Undefinierten definitive Aussagen zu pressen. Das mag realitätsfremd klingen. Aber immer mehr setzt sich in der Wirtschaft die Ansicht durch, dass es für erfolgreiche Projekte notwendig ist, einer sinnvollen Systematik zu folgen und nicht einfach nur das Unmögliche möglich zu machen. Die Systematik mag oft von der täglich erfahrenen Realität abweichen. Dennoch steckt dahinter die Erkenntnis, dass erfolgreiche Projekte eine bestimmte Herangehensweise erfordern. Aber es geht nicht nur um eine Systematik. Es geht auch darum, Projektmanagement als eigenständige Tätigkeit mit einem erforderlichen spezifischen Profil zu sehen. Projektmanager werden häufig ausgewählt, wenn sie in ihrem Spezialfach qualifiziert und gut sind und deshalb befördert werden müssen. Die Erkenntnis, dass der Mensch, der z.B. ein exzellenter Entwickler ist, nicht unbedingt ein geeigneter Projektmanager ist, setzt sich nur langsam durch. Das Projektmanagement entwickelt sich jedoch zunehmend zu einem eigenen Berufsbild. Das dazu erforderliche Profil ähnelt mehr dem des Managers als dem des Fachspezialisten. Der Projektmanager löst nicht die fachlichen Probleme, sondern er sorgt dafür, dass die Probleme von Fachleuten gelöst werden. Der weitaus größte Teil der Tätigkeiten eines Projektmanagers besteht aus Kommunikation. Projektmanagement bedeutet darüber hinaus Führen im Sinne vom Vorgeben der Richtung und Motivation der Projektteammitglieder. Es bedeutet auch die Lösung von Konflikten, Verhandeln und Einflussnahme auf die Organisation, in der oder für die das Projekt durchgeführt wird. All dies sind Managementfähigkeiten, die eine Person zum guten Projektmanager machen. Das Project Management Institute (PMI) versucht im Project Management Body of Knowledge (PMBOK Guide) einen Standard für Projekte und ihr Management zu definieren. Zu dieser Standardisierung gehören die Prozesse, die das Projektmanagement ausmachen. Das sind: Initiierung, Planung, Steuerung, Ausführung und Abschluss. Sie werden aber besser als Prozessgruppen bezeichnet, da sie ihrerseits wieder aus Prozessen bestehen. Die folgende Grafik gibt eine Übersicht über die Prozessgruppen und ihren Zusammenhang: Keinesfalls dürfen diese Prozessgruppen mit Projektphasen verwechselt werden. Die Projektphasen gehören zum so genannten Projektlebenszyklus. Jede Phase bringt ein oder mehrere Ergebnisse, die zusammen das Ergebnis des Projektes bilden. Diese Phasen sind in einer bestimmten zeitlichen Anordnung, die sich durch den Projektgegenstand bestimmt. So hat ein Hausbauprojekt (z.B. mit den Projektphasen: Planung, Rohbau, Innenausbau, Technik, Außenanlagen, Abschluss) andere Phasen als ein Softwareentwicklungsprojekt (z.B. mit den Projektphasen: Konzept, Entwicklung, Implementierung, Abschluss). Jede Projektphase beinhaltet jedoch einige oder alle Projektmanagementprozesse. Das PMBOK betrachtet nun weniger die Phasen eines Projektes, da diese kaum standardisierbar sind, sondern interessiert sich mehr für die Prozesse, die notwendig sind, um ein Projekt erfolgreich durchzuführen. Diese Prozesse sind nicht auf bestimmte Phasen beschränkt, sondern werden idealerweise in jeder Phase eines Projektes mehr oder weniger durchgeführt. Wenn im Folgenden von der Prozessgruppe „Planung“ die Rede ist, darf das nicht mit einer Planungsphase eines Projektes verwechselt werden. Natürlich werden Planungsprozesse in der Planungsphase besonders intensiv durchgeführt, aber Planungsprozesse werden auch in jeder Phase eines Projektes durchgeführt und sind daher nicht auf eine bestimmte Phase beschränkt. Die Aneinanderreihung der Phasen eines Projektes entspricht dem Projektlebenszyklus. Er beschreibt den zeitlichen Ablauf des Projektes von seinem Anfang bis zu seinem Abschluss. Ein Prozess dagegen ist eine Folge von Aktivitäten, die ein Ergebnis hervorbringen. Die Beschreibung des Prozesses ist also weniger an der zeitlichen Einordnung als vielmehr daran, was der Prozess an Eingaben benötigt und welche Tätigkeiten erforderlich sind, um ein bestimmtes Ergebnis zu erzielen. Dementsprechend werden die einzelnen Prozesse, aus denen sich die Prozessgruppen zusammensetzen, mit ihren Eingangswerten (Input), den Werkzeugen und Verfahren innerhalb des Prozesses und den Ergebnissen, die erreicht werden sollen, beschrieben. Diese Herangehensweise an Projektmanagement ist durchaus nicht üblich. Gerade Abhandlungen über Projektmanagement in bestimmten Fachbereichen (z.B. für Softwareprojekte) versuchen eher einen Ansatz über die Projektphasen, um die zeitliche Abfolge von Projekten in diesem Bereich zu beschreiben. Beim prozessorientierten Ansatz geht es mehr darum, welche Ergebnisse erzielt werden müssen, um erfolgreich Projekte zu managen. Jeder Prozess benötigt aber auch Eingangswerte (Input), um das gewünschte Ergebnis hervorzubringen. Die Prozesse hängen miteinander zusammen, da das Ergebnis eines Prozesses der Eingangswert eines anderen Prozesses sein kann. Schauen wir uns nun die Prozessgruppen im Einzelnen an. Dabei geht es zunächst nur um einen groben Überblick. Die Details der einzelnen Prozesse werden in nachfolgenden Artikeln behandelt. Die Initiierung Hierbei geht es um die Freigabe eines Projektes bzw. einer Phase eines Projektes. Die Ergebnisse dieser Prozessgruppe sind Eingangswerte für die Prozessgruppe Planung. Die Planung Planung ist eine zentrale Tätigkeit des Projektmanagements. Daher ist diese Prozessgruppe die umfangreichste. Eine Fülle einzelner Prozesse bildet diese Gruppe. Einige sind hier aufgeführt: Planung und Definition des Inhalts und Umfangs (Scope) Zeitplanung Ressourcenplanung Kostenplanung Planung des Risikomanagements Entwicklung des Projektplans Diese zusammengefasst dargestellten Kernprozesse werden durch weitere Prozesse unterstützt. Dazu gehören: die Qualitätsplanung die Beschaffungsplanung die Kommunikationsplanung Die Ergebnisse der Planungsprozesse wiederum sind die Eingangswerte für die Ausführungsprozesse Die Ausführung Unter dem Blickwinkel des Projektmanagements gesehen ist der zentrale Prozess dieser Gruppe die Ausführung des Projektplanes. Dieser Kernprozess wird unterstützt durch begleitende Prozesse wie: Qualitätssicherung Teamentwicklung Vertragsabwicklung Die Ergebnisse der Prozessgruppe Ausführung sind wiederum Eingaben in die Steuerungsprozesse. Die Steuerung Die Steuerungsprozesse bestehen aus dem Berichtswesen und der integrierten Änderungssteuerung, mit der alle notwendigen Änderungen im Laufe des Projektes integriert werden. Unterstützt werden diese Prozesse durch die Steuerung der Änderungen an Inhalt und Umfang, der Steuerung der Kosten und der Zeitplanung. Zu den unterstützenden Prozessen gehören auch die Risikoüberwachung und die Qualitätslenkung. Die Ergebnisse dieser Prozessgruppe sind wiederum Eingangswerte in die Planung, die Ausführung und die abschließenden Prozesse. Der Abschluss Ein Projekt bzw. eine Phase benötigt einen Abschluss. Daher wird hierfür eine eigene Prozessgruppe vorgesehen, deren Prozesse aus der Vertragsbeendigung und dem administrativen Abschluss bestehen. Die Prozessgruppen stellen also ein ineinander verwobenes System von Prozessen dar, die in gegenseitiger Abhängigkeit stehen und deren ordnungsgemäße Durchführung für ein erfolgreiches Projekt notwendig ist. Die Prozesse dieser Gruppen lassen sich nach Wissensgebieten (knowledge areas) systematisieren. Jeder Prozess innerhalb der Prozessgruppen gehört zu einem der folgenden Wissensgebiete. Inhalts- und Umfangsmanagement(scope management) Terminmanagement (time management) Kostenmanagement ( cost management) Qualitätsmanagement (quality management) Personalmanagement (human resource mangement) Kommunikationsmanagement (communication management) Risikomanagement (risk management) Beschaffungsmanagement (procurement management) Integrationsmanagement (integration management) In diesem und den folgenden Artikeln beschäftigen wir uns jeweils mit ein oder zwei dieser Wissensgebiete. Inhalts- und Umfangsmanagement Zugegeben diese Bezeichnung klingt ein wenig holperig, aber es ist sehr schwer die englische Bezeichnung Scope wirklich adäquat zu übersetzen. Während der Scope eines Produktes die Eigenschaften und Funktionen bezeichnet, die das Produkt kennzeichnen, beschreibt der Scope eines Projektes die Arbeiten, die ausgeführt und abgeliefert werden müssen, um das Projektziel z.B. ein Produkt mit bestimmten Eigenschaften und Funktionalitäten, herzustellen. Die Prozesse dieses Wissensgebietes beschäftigen sich also mit der Sicherstellung, dass Inhalt und Umfang des Projektes definiert und jede Änderung kontrolliert werden. Die Prozesse dieses Wissensgebietes beschäftigen sich mit der fortschreitenden Verfeinerung der Beschreibung dessen, was in dem Projekt überhaupt geliefert werden muss. Bevor ein Projekt oder eine neue Projektphase überhaupt starten kann, bedarf es einer Initiierung. So wird die Autorisierung eines neuen Projektes oder einer neuen Phase in einem größeren Projekt bezeichnet. Diese Autorisierung geschieht durch die formale Entscheidung, ein Projekt zu starten oder es in eine neue Phase gelangen zu lassen. Das Projekt bzw. die Projektphase wird gewissermaßen in Auftrag gegeben. Und am besten wird auch gleich ein Projektmanager mit der Durchführung beauftragt. Leider ist gerade das oft nur eine Idealvorstellung. In der realen Welt der Projekte wird der Projektmanager oft erst sehr spät bestimmt. Das hat oft zur Folge, dass sie oder er in der entscheidenden Startphase eines Projektes noch nicht „an Bord“ war und nachher vollendete (Planungs-)Tatsachen entgegennehmen und durchführen muss. Bei der Initiierung sollte auch bereits dokumentiert werden, mit welchen Beschränkungen und Annahmen das Projekt begonnen wird. Bei vielen Projekten gibt es diese Beschränkungen und Annahmen nur unausgesprochen und undokumentiert. Es ist gut, wenn von vornherein allen Beteiligten klar ist, unter welchen Bedingungen das Projekt durchgeführt wird. So kann zum Beispiel in einem IT Projekt die Annahme bestehen, dass ein Werkzeug, das zur Entwicklung notwendig ist, rechtzeitig und zuverlässig verfügbar ist. Eine solche Annahme muss regelmäßig im Verlauf des Projektes auf ihre weitere Gültigkeit überprüft werden. Dieser Prozess der Initiierung gehört zur Prozessgruppe Initiierung. Die nächsten Prozesse in diesem Wissensgebiet bestehen aus der immer genaueren Beschreibung der Liefergegenstände und Leistungen des Projektes. Dabei wird aus der ersten groben Beschreibung des Projektes aus der Initiierung eine detailliertere Beschreibung des Projektesinhalts und –umfangs erstellt. Diese beinhaltet unter anderem die Projektbegründung, eine Beschreibung des Projektproduktes, eine Aufstellung der Dinge und Leistungen, die im Projekt erbracht werden müssen, und die Projektziele. Diese Ziele müssen auf jeden Fall quantifizierbar sein. Der Projektstrukturplan (work breakdown structure) verfeinert diese Beschreibung noch, indem die Hauptkomponenten weiter untergliedert werden. Diese Untergliederung sollte so weit durchgeführt werden, dass die Komponenten planbar sind. Diesem Projektstrukturplan kommt entscheidende Bedeutung zu. Was in ihm nicht definiert ist, gehört nicht zum Projekt. Er ist die Grundlage für jede weitere Planung und zugleich der Maßstab für die Überprüfung der Ergebnisse des Projektes. Diese Prozesse der Definition des Inhalts und Umfangs gehören zur Prozessgruppe Planung. Das Erreichen des als Projektziels vereinbarten Inhalts und Umfangs muss regelmäßig zu bestimmten Zeitpunkten im Projekt überprüft werden. Für jede Änderung des Inhalts und Umfangs muss es ein Steuerungssystem geben. Es muss klar sein, wer über Änderungen entscheiden darf. Diese Prozesse der Überprüfung und Steuerung gehören zur Prozessgruppe der Steuerung. In Projekt zeigt es sich immer wieder, dass viele Probleme durch eine zu ungenaue Festlegung des Inhalts und Umfangs oder durch die Unverbindlichkeit dieser Festlegung verursacht werden. Damit fehlt diesen Projekten jede Planungssicherheit, weil es entweder unklar oder schwankend ist, was das Projekt leisten muss. Terminmanagement Beim Terminmanagement sind wir bei dem, was häufig unter Projektmanagement verstanden wird: die Festlegung von Zeitplänen und Meilensteinen. Aber das ist nur ein Teil des Projektmanagement, wenn auch natürlich ein wichtiger. Terminmanagement ist nicht möglich, ohne dass von anderen Wissensgebieten Input geliefert wird. Beispielsweise wenn nicht klar ist, was in dem Projekt erreicht werden muss, und auch die zur Verfügung stehenden Ressourcen nicht bekannt sind und auch die Risiken, die in dem Projekt bestehen, nicht analysiert sind, steht eine noch so professionell aussehende Terminplanung auf einem unsicheren Fundament und ist damit fast wertlos. Die Zeitplanung eines Projektes basiert auf dem Projektstrukturplan. Wenn die Tätigkeiten im Projekt klar sind, die durchgeführt werden müssen, um die im Projektstrukturplan definierten Komponenten des Projektes zu erreichen, können diese Tätigkeiten in eine Abhängigkeit voneinander gebracht werden. Ein übliches Verfahren ist dabei die Darstellung dieser Abhängigkeiten in Netzplänen. Gleichzeitig kann die Dauer der Tätigkeiten abgeschätzt werden. Wenn beide Informationen, Abhängigkeiten und Dauer, vorliegen, wird daraus der Terminplan erstellt, aus dem der kritische Pfad berechnet werden kann. Dieser kritische Pfad ist die Abfolge von Tätigkeiten, die durch ihre Abhängigkeiten keinen zeitlichen Puffer haben. Jede Verspätung auf dem kritischen Pfad führt zu einer verspäteten Fertigstellung des Projektes. Den Tätigkeiten auf dem kritischen Pfad gilt deshalb das besondere Augenmerk des Projektmanagers. Diese Prozesse gehören zur Prozessgruppe Planung. Wie auch zum Inhalts- und Umfangsmanagement muss auch für das Terminmanagement ein Steuerungssystem eingerichtet werden, mit dem Änderungen im Terminplan durchgeführt werden können. Dieser Prozess gehört zur Projektgruppe Steuerung. Kostenmanagement Um die Kosten eines Projektes planen und managen zu können, bedarf es einiger Voraussetzungen. Eine dieser Voraussetzungen ist mit dem Inhalts- und Umfangsmanagement gegeben, das das Ergebnis oder Produkt des Projektes definiert. Basierend darauf wird durch das Zeitmanagement die Zeitplanung durchgeführt. Inhalts- und Umfangsmanagement und Zeitmanagement haben wir im letzten Artikel behandelt. Dem aufmerksamen Leser des letzten Artikels wird vielleicht nicht entgangen sein, dass die im Inhalts- und Unfangsmanagement erstellte Work Breakdown Structure nicht allein reicht, um eine Zeitplanung erstellen zu können. Es reicht nicht aus, nur zu wissen, was gemacht werden muss, sondern es ist auch wichtig zu wissen, mit welchen Ressourcen - sowohl Personen als auch andere Einsatzmittel - das Ziel erreicht werden kann. Dabei müssen nicht namentlich Personen bereits benannt werden, aber die fachlichen Anforderungen an die Personen müssen klar sein. Diese Ressourcenplanung gehört zum Kostenmanagement, da die verwendeten Ressourcen ein entscheidender Faktor für die Kosten sind. Zugleich ist die Ressourcenplanung aber auch ein wichtiger Input für die Zeitplanung, da diese von der Verfügbarkeit bestimmter Ressourcen abhängt. Die Ressourcenplanung gehört ebenso wie die im nachfolgenden beschriebenen Kostenschätzung und die Kostenplanung zur Prozessgruppe Planung. Bei der Kostenschätzung kommen nun alle zuvor geplanten Elemente zusammen: die Work Breakdown Structure, die Schätzung der Dauer der einzelnen Vorgänge und der ermittelte Bedarf an Ressourcen. Auch hier wird der Leser mit Projekterfahrung vielleicht denken, dass die Realität oft anders aussieht. Oft muss bereits eine Kostenschätzung im Projekt erfolgen, wenn weder Scope noch Zeit noch Ressourcen wirklich klar sind bzw. geplant werden konnten. In diesen Fällen bleibt nur eine Form von Analogieschätzung. Dabei wird das Projekt mit anderen ähnlichen Projekten verglichen, deren Kosten bekannt sind. Basierend darauf werden die Kosten des neuen Projektes geschätzt. Diese Schätzung ist natürlich sehr ungenau und mit dem Risiko behaftet, dass sich das neue Projekt als doch nicht so ähnlich wie gedacht herausstellt. Wenn die Faktoren Scope, Zeit und Ressourcen bereits vorliegen, kann besser mit der Bottom-up Schätzung gearbeitet werden. Dabei werden die einzelnen Arbeitspaket basierend auf den Faktoren Zeit und benötigte Ressourcen hinsichtlich ihrer Kosten geschätzt und zu den Gesamtkosten aufsummiert. Bei der Kostenplanung werden die so geschätzten Gesamtkosten entsprechend der Zeitplanung auf der Zeitachse verteilt. So entsteht der Kostenbasisplan, gegen den die tatsächlichen Ausgaben im Projekt zu bestimmten Zeitpunkten kontrolliert werden können. Aufgrund dieses Kostenplans kann eine Steuerung der Kosten erfolgen. In der einfachsten Form erfolgt diese Steuerung und Kontrolle über den Vergleich der tatsächlichen Projektkosten mit den im Kostenbasisplan geplanten Kosten zu einem bestimmten Zeitpunkt. Dieser Vergleich zeigt allerdings nicht die ganze Wahrheit, da hier nur Kosten betrachtet werden und nicht, was im Projekt zu dem Zeitpunkt erreicht worden ist. Eine Methode um die Scope, Zeit und Kosten gegenüber den geplanten Werten zu vergleichen und so das Projekt in seinen wesentlichen Faktoren unter Kontrolle zu halten, ist die Earned Value Analyse (EVA) oder übersetzt die Analyse des Fertigstellungswertes. Hinter dieser Analyse verbirgt sich eine Methode, den Grad der Fertigstellung der Projektergebnisse mit in die Kostenrechnung einzubeziehen, um so Scope, Zeit und Kosten zu berücksichtigen. Die Methode beruht auf drei Variablen. Die Methode analysiert immer den Zustand des Projektes zu einem bestimmten Zeitpunkt. Die erste Variable ist der Planned Value (PV). Dieser bezeichnet den Wert der Arbeit im Projekt, die zu einem bestimmten Zeitpunkt laut Planung fertig gestellt sein sollte. Hier ein Beispiel: Ein Projekt besteht aus vier Arbeitspaketen, die jeweils Kosten von € 1000 verursachen. Wenn zu einem bestimmten Zeitpunkt die Fertigstellung von drei dieser vier Pakete geplant ist, beträgt der Planned Value zu diesem Zeitpunkt € 3000. Die zweite Variable ist der Earned Value (EV). Das ist im Deutschen am ehesten mit Fertigstellungswert zu übersetzen. Dieser bezeichnet den Wert der Arbeit im Projekt, die zu einem bestimmten Zeitpunkt tatsächlich fertig gestellt ist. In unserem Beispiel: Von den geplanten drei fertig gestellten Paketen sind nur zwei fertig gestellt. Zu diesem Zeitpunkt beträgt der Earned Value € 2000. Die dritte Variable sind die Actual Cost (AC). Diese bezeichnen die Kosten, die zu einem bestimmten Zeitpunkt tatsächlich aufgelaufen sind. In unserem Beispiel sind € 2800 ausgegeben worden. Mit diesen drei Variablen lassen sich nun die Cost Variance (CV) und die Schedule Variance (SV) berechnen. Bleiben wir bei unserem Beispiel. PV beträgt € 3000, EV beträgt € 2000 und AC beträgt € 2800. Wenn in diesem Beispiel nur PV mit AC verglichen werden, also die Kostenplanung mit den tatsächlichen Kosten, sieht das Projekt so aus, als sei es auf dem richtigen Weg. Die tatsächlichen Kosten sind geringer als die geplanten Kosten. In Wirklichkeit aber müssen in diesem Projekt alle Warnlampen auf Rot stehen. Weder ist das mit den Kosten erreicht worden, was geplant war, noch sieht es so aus, dass das Projekt rechtzeitig fertig wird. Das lässt sich sehr einfach durch folgende Werte darstellen. Die Cost Variance (CV = EV – AC) beträgt in unserem Beispiel -800. Negative Zahlen bedeuten immer, dass das Budget überschritten worden ist. Nicht besser sieht es bei der Zeitplanung aus. Die Schedule Variance (SV = EV – PV) beträgt in unserem Beispiel -1000. Negative Zahlen bedeuten immer, dass die Zeitplanung überschritten worden ist. Mit weiteren Zahlen lässt sich das Ausmaß der Misere in unserem Beispiel noch verdeutlichen. Der Cost Performance Index (CPI) verdeutlicht, wie viel für jeden ausgegebene Kosteneinheit (Euro, Dollar, …) im Projekt erarbeitet worden ist. In unserem Beispiel beträgt der CPI = EV/AC, also 0,71, ein ziemlich verheerendes Ergebnis, da für jeden ausgegeben Euro nur 0,71 Euro an Gegenwert geschaffen worden sind. Der Schedule Performance Index (SPI) zeigt an, wie viel Prozent von dem geschaffen worden ist, was zu einem bestimmten Zeitpunkt geplant war. In unserem Beispiel beträgt der SPI 0,66. Das heißt, dass nur 66 Prozent von dem erreicht worden ist, was eigentlich hätte erreicht werden sollen. Mit den so berechneten Werten kann auch weiter berechnet werden, wie viel voraussichtlich das Projekt am Ende kosten wird (EAC = Estimate at Completion). Dazu wird die ursprüngliche Budgetplanung (BAC = Budget at Completion) durch den Cost Performance Index geteilt. Daraus ergibt sich in unserem Beispiel EAC = BAC/CPI = 4000 €/0,71 = 5634 €. Diese Formel stellt nur eine von mehreren Möglichkeiten dar, den EAC zu berechnen Sie geht davon aus, dass die bisher im Projekt gezeigte Performance sich nicht ändert. Wie werden nun die drei Ausgangsvariablen PV, EV und AC bestimmt? PV und AC stellen kein Problem dar. Der Planned Value (PV) ist die Summe der geplanten Kosten für die Arbeitspakete bis zum Analysezeitpunkt, die Actual Cost (AC) stellen die Summe der tatsächlichen Kosten für die Arbeitspakete im Projekt bis zum Analysezeitpunkt dar. Voraussetzung für diese Werte ist eine korrekte und gründliche Kostenplanung und Kostenkontrolle. Der Earned Value (EV) muss näher betrachtet werden. Um ihn zu bestimmen, muss der Grad der Fertigstellung der einzelnen Arbeitspakete festgestellt werden. Ein Arbeitspaket mit einem PV von € 1000 und einem Fertigstellungsgrad von 50% hat einen EV von € 500. Nur wie kann der Fertigstellungsgrad eines Arbeitspaketes wirklich gemessen werden? Oft wird das mit mehr zufälligen Schätzungen durchgeführt. Das erweist sich als untauglicher Weg. Besser ist es, sich von Anfang an auf eine der folgenden Regeln im Projekt festzulegen. die 50/50 Regel: Ein Arbeitspaket, das begonnen wurde, wird immer als zu 50% fertig gestellt angenommen. Erst wenn es fertig gestellt ist, kommen die restlichen 50% hinzu. die 20/80 Regel: Ein Arbeitspaket, das begonnen wurde, wird immer als zu 20% fertig gestellt angenommen. Erst wenn es fertig gestellt ist, kommen die restlichen 80% hinzu. die 0/100 Regel: Nur ein Arbeitpaket, das fertig gestellt ist, werden in der Earned Value Analyse mit ihrem Fertigstellungswert berücksichtig. Für nur angefangene Pakete wird ein Fertigstellungsgrad von 0% angenommen. Welche der Regeln verwendet werden sollte, hängt von der Größe der Arbeitspakete und der Anzahl der nicht fertig gestellten Pakete ab. Mit einer dieser Regeln ist es dann leicht möglich, den Earned Value zu berechnen. Personalmanagement In diesem Wissensgebiet geht es um den Umgang mit der Ressource Mensch im Projekt. Der Leser mag diese sehr sachliche Sicht auf den Menschen im Projekt entschuldigen. Aber tatsächlich ist die Perspektive des PMI® (Project Management Institute) vorgelegten Standards das Projekt. Und aus der Sicht des Projektes ist der Mensch eine Ressource neben anderen, wenn auch die wichtigste und oft auch die empfindlichste. Wenn in einem Projekt durch das Management des Inhalts und Umfangs (Scope), der Zeit und der Kosten festgestellt worden ist, was mit welchem Aufwand in welcher Zeit getan werden muss und welche Ressourcen allgemein dafür notwendig sind, ist es jetzt an der Zeit durch den Prozess der Organisation im Projekt festzulegen, welche Person oder Rolle für welche Aufgaben verantwortlich ist. Dieser Prozess gehört zum Wissensgebiet des Personalmanagements und wird am übersichtlichsten mit Hilfe einer Verantwortlichkeitsmatrix (Responsibility Assignment Matrix = RAM) durchgeführt. Diese Matrix besteht an einer Kante aus Arbeitspaketen und an der anderen Kante aus einzelnen Personen, Gruppen oder Rollen. Diese Art von Matrix kann auf unterschiedlichen Ebenen mit unterschiedlichem Detaillierungsgrad verwendet werden. In einer frühen Planungsphase des Projektes kann es sein, dass Arbeitspakete aus der Work Breakdown Structure Rollen zugewiesen werden. Zu einem späteren Zeitpunkt können diese Arbeitspakete dann einzelnen Personen namentlich zugewiesen werden. Wenn dann die Arbeitspakete durchgeführt werden, kann es notwendig sein, diese wieder in einzelne Aufgaben zu unterteilen, für die wiederum eine Matrix erstellt wird. Um die Matrix noch brauchbarer zu machen, kann ein Arbeitspaket eine bestimmte Art von Aufgabe zuweisen. Welche Aufgaben (hier V, T, Z, Ü, F) in einer solchen Matrix definiert werden, ist den Notwendigkeiten anzupassen. Wichtig ist aber, dass immer nur eine Person letztlich verantwortlich ist für ein Paket. Wird die Verantwortung auf mehrere Personen verteilt, gibt es erfahrungsgemäß große Probleme, das Arbeitspaket in der richtigen Zeit und im richtigen Umfang fertig zu stellen. Jeder der Verantwortlichen für das Arbeitspaket zeigt dann, nach dem Grund gefragt, auf den anderen Verantwortlichen. Basierend auf dieser Matrix und der Zeitplanung für das Projekt kann ein Personalmanagementplan entwickelt werden. Dieser legt fest, wann welche Person im Projekt gebraucht wird und wann sie wieder aus dem Projektteam entlassen werden kann. Dieser letzte Punkt ist sehr wichtig. Ein solcher Plan darf nicht nur festlegen, wann jemand gebraucht wird und deshalb in das Projektteam hereingeholt wird, sondern auch, wann jemand nicht mehr gebraucht wird. Damit wird verhindert, dass Arbeit generiert wird, nur um Leute zu beschäftigen (das gibt es!), und es wird ermöglicht, Projektteammitglieder lückenlos sofort in einem andere Projekt einzusetzen. Die Planung allein genügt natürlich nicht, die Leute müssen auch tatsächlich entsprechend dem Personalmanagementplan beschafft werden. Dabei muss auch bei internen Mitarbeitern von Beschaffung gesprochen werden, denn gerade bei sehr guten und damit auch sehr gefragten Mitarbeitern braucht der Projektmanager Verhandlungsgeschick, um die richtigen Leute zur richtigen Zeit zu bekommen. Die beiden Prozesse Organisation im Projekt und Beschaffung von Projektpersonal gehören zur Prozessgruppe Planung. Zur Prozessgruppe Ausführung gehört dagegen der Prozess der Teamentwicklung. Dieser Prozess soll dafür sorgen, dass die beschafften Projektteammitglieder tatsächlich als Team im Projekt zusammenarbeiten. Eine sehr wirkungsvolle Maßnahme dabei ist die Zusammenlegung oder zumindest räumliche Nähe von Projektteams. Da das häufig in globalen Projekten nicht möglich ist, müssen Veranstaltungen durchgeführt werden, die ein Wir-Gefühl im Projektteam bilden und fördern. Beschaffungsmanagement In diesem Wissensgebiet wird die Beschaffung von externen Leistungen oder Produkten, die für das Projekt notwendig sind, beschrieben. Es orientiert sich am üblichen Ablauf von Definition der Anforderungen, Angebotseinholung, Auswahl und Abwicklung. Im Detail kann aber das PMI® bei diesem Wissensgebiet nicht verleugnen, eine vom Ursprung her amerikanische Organisation zu sein. Die Sichtweise ist im Detail teilweise von den amerikanischen Verhältnissen geprägt. Dieses Wissensgebiet beschäftigt sich mit den Prozessen Beschaffungsplanung, in der festgelegt wird, was wann beschafft werden muss, Angebotsplanung, in der die Anforderungen dokumentiert und mögliche Anbieter identifiziert werden, Angebotseinholung Lieferantenauswahl Vertragsabwicklung Vertragsbeendigung Beschaffungs- und Angebotsplanung gehören zur Prozessgruppe Planung, Angebotseinholung, Lieferantenauswahl und Vertragsabwicklung zur Prozessgruppe Ausführung und die Vertragsbeendigung zur Prozessgruppe Abschluss. In diesem Zusammenhang soll die Rolle des Projektmanagers bei der Beschaffung betrachtet werden. Er hat insbesondere bei der Auswahl der Lieferanten und vor allem auch bei der Vertragsgestaltung eine wichtige Rolle, denn niemand kennt das Projekt so gut wie der Projektmanager (so sollte es zumindest sein). Der Projektmanager kennt die Risiken im Projekt und die speziellen Anforderungen, die das Projekt stellt. Leider ist es in der Realität häufig so, dass der Projektmanager erst ins Spiel kommt, wenn der Vertrag mit dem Lieferanten bereits geschlossen ist. Kommunikationsmanagement Der erste Prozess in diesem Wissensgebiet ist die Kommunikationsplanung. Dabei geht es um die Frage, wer kommuniziert mit wem in welcher Form. Dazu muss in einer so genannten Stakeholder Analyse festgestellt werden, wer in irgendeiner Form an dem Projekt aktiv oder passiv beteiligt ist. Jeder, der zu dieser Gruppe gehört, wird im Project Management Body of Knowledge (PMBOK Guide, Project Management Institute (Hrsg), A Guide to the Project Management Body of Knowledge, Ausgabe 2000, Deutsche Übersetzung, 2003, S. 6) Stakeholder genannt. Dieser Begriff ist kaum ins Deutsche zu übersetzen und wird daher auch in der deutschen Ausgabe des PMBOK Guides unübersetzt verwendet. Stakeholder sind alle, die am Projekt beteiligt oder vom Projekt betroffen sind. Deren Informationsbedürfnisse müssen analysiert werden. Sie unterscheiden sich sehr stark. Ein passiver Stakeholder, wie z.B. der Endanwender eines Produktes, das in einem Software-Entwicklungsprojekt entwickelt wird, hat allenfalls den Bedarf, gelegentlich über den Fortgang des Projektes informiert zu werden, vielleicht reicht es sogar, dass er nur am Ende des Projektes über die Fertigstellung informiert wird. Dagegen hat der Sponsor des Projektes einen ganz anderen Informationsbedarf, was Häufigkeit und Detaillierungsgrad angeht. Projektmanager und Projektmitarbeiter sind Stakeholder, die nicht nur einen Informationsbedarf haben, sondern auch viele Informationen liefern. Ein Kommunikationsplan sollte auf jeden Fall die Liste der identifizierten Stakeholder enthalten und für jeden dieser Personen oder Gruppen festlegen, in welcher Form und welcher Häufigkeit diese informiert werden und wer die Verantwortung für die Informationsweitergabe trägt. Die Form der Informationsweitergabe kann mündlich oder schriftlich, formell (z.B. offizieller Statusbericht, Besprechung mit Agenda und Protokoll) und informell (z.B. Memo, spontanes Gespräch) sein. Der Plan sollte auch die Vorgaben für bestimmte Informationsformen enthalten. Es erleichtert den Informationsfluss, wenn allen Beteiligten klar ist, welche Informationen z.B. in einem offiziellen Bericht erwartet werden. Dieser Kommunikationsplan stellt einen wichtigen, aber oft vergessenen Bestandteil des Projektplans dar. Bei der Durchführung des Projektes müssen die wichtigen Unterlagen in geeigneter Weise aufbewahrt und den dazu berechtigten Personen zugänglich gemacht werden. Dabei bietet sich natürlich eine elektronische Ablage der Informationen an, wenn die entsprechende Infrastruktur vorhanden ist. Zu diesen Unterlagen gehören insbesondere die Berichte, die im Laufe des Projektes zu den im Kommunikationsplan festgelegten Zeitpunkten erstellt werden müssen und die den aktuellen Status, die erreichten Fortschritte und den Ausblick auf den weiteren Verlauf des Projektes beschreiben. Diese Unterlagen sollten beim Ende des Projektes zusammen mit den so genannten Lessons learned in einem Projektarchiv aufbewahrt werden, um so als Erfahrungsschatz für künftige Projekte zur Verfügung zu stehen. Risikomanagement Das Risikomanagement stellt ein sehr komplexes Gebiet dar. Der PMBOK Guide beschreibt das Projektrisiko als „ein unsicheres Ereignis oder eine Bedingung, dessen/deren Eintreten eine positive oder negative Auswirkung auf ein Projektziel hat“ (PMBOK Guide, S. 217). Risiko ist also all das, was unsicher ist. Ein Risiko muss aber nicht unbedingt negative Folgen für das Projekt haben. Zu unterscheiden ist dabei zwischen bekannten und unbekannten Risiken. Bekannte Risiken können identifiziert werden und Maßnahmen eingeplant werden. Unbekannten Risiken kann der Projektmanager nur durch die Einplanung von allgemeinen Reserven begegnen. Der aufmerksame Leser wird inzwischen bemerkt haben, dass das PMI (Project Management Institute) in jedem der Wissensgebiete einen Prozess der Planung vorsieht. So ist es auch beim Risikomanagement. Im Risikomanagementplan wird festgelegt, wie in dem Projekt mit Risiken umgegangen wird. Dazu gehören Fragen wie: Wie oft innerhalb des Projektes werden Risikoanalysen durchgeführt? Wer führt diese Analysen durch? Wie und mit welcher Methodik werden die Analysen durchgeführt? Wie viel Budget steht dafür zur Verfügung? Wie werden die Risiken und der Umgang mit ihnen dokumentiert? Die Risikoidentifikation und –analyse kann in unterschiedlicher Intensität durchgeführt werden. Je risikobehafteter und umfangreicher ein Projekt ist, desto mehr wird in diesen Prozess zu investieren sein. Der erste Schritt der Risikoidentifikation und –analyse besteht in der einfachen Auflistung der Risiken. Diese können dann qualitativ analysiert werden. Diese Analyse kann in der Bewertung der einzelnen Risiken hinsichtlich ihrer Auswirkungen auf das Projektziel bestehen. Dabei ist es sehr sinnvoll, die Auswirkungen auf das Projektziel hinsichtlich der Bereiche Kosten, Zeit, Inhalt und Umfang (Scope) und Qualität zu betrachten. Um diese Auswirkung besser darstellbar zu machen, ist es üblich, einen Zahlenwert zu vergeben. Der Maßstab für die Vergabe der Werte ist vorher festzulegen. Dieser Auswirkungswert kann dann in einer Matrix in Beziehung zur Wahrscheinlichkeit gebracht werden. Das Produkt der beiden Werte gibt dann den Risikowert eines einzelnen Risikos an. So können Risiken, die unbedingt und gegebenenfalls auch mit hohem Aufwand im Auge behalten werden müssen, weil sie sehr wahrscheinlich und eine mittlere bis hohe Auswirkung haben, von denen unterschieden werden, die weniger wichtig sind, weil sie entweder sehr unwahrscheinlich sind oder nur geringe Auswirkungen haben. Bei der quantitativen Risikoanalyse wird das Risiko zusätzlich noch in Beziehung zu den finanziellen Auswirkungen gebracht. Bei Projekten mit hohem finanziellem Einsatz ist das sehr wichtig. Allerdings kann ein solches Verfahren sehr aufwändig sein. Nach der so erfolgten Identifikation und Analyse der Risiken muss geplant werden, wie diesen Risiken begegnet werden soll. Ein ganz wichtiger Faktor dabei ist, dass ein einzelnes Risiko einem Verantwortlichen zugewiesen wird, bevor überhaupt das Risiko tatsächlich eintritt. Durch diese Planung ist eine schnelle Reaktion mit bereits geplanten Schritten durch den Verantwortlichen möglich, ohne dass noch umfangreiche Rückversicherungen und Beratungen notwendig sind. Selbstverständlich muss dieser ganze Prozess überwacht werden. Dabei wird regelmäßig überprüft, ob die Liste der identifizierten Risiken noch vollständig ist, ob die vorgesehenen Maßnahmen bei den eingetretenen Risiken auch in erwarteter Weise gewirkt haben und ob Korrekturen an der Planung und Ausführung des Projektes notwendig sind. Ergebnisse dieser Überwachung sollten gesammelt und aufbewahrt werden, um so für das laufende und vor allem für kommende Projekte eine Erfahrungsbasis zu haben. Qualitätsmanagement Beschäftigen wir uns zunächst mit dem Begriff Qualität. Im landläufigen Verständnis wird er häufig im Sinne von Klasse verstanden. In diesem Sinne bedeutet qualitativ hochwertig ein Produkt hoher Klasse, z.B. sehr hochwertig im Sinne von einer Vielzahl von Funktionen. Das ist in diesem Zusammenhang nicht mit Qualität gemeint. Vielmehr bedeutet Qualität in diesem Zusammenhang die Erfüllung der Anforderungen, die an das Produkt gestellt werden und die Tatsache, dass die Anforderungen etwas wirklich Brauchbares beschreiben. Die Erfüllung unsinniger Anforderungen kann nicht Qualität darstellen. Erfüllen von Anforderungen bedeutet aber auch, dass diese Anforderungen nicht übertroffen werden müssen. Im Gegenteil. Diese Art „Vergolden“ ist nicht im Sinne der Qualität, wie sie im Projektmanagement verstanden wird. Im Projekt, an dessen Ende immer ein irgendwie geartetes Produkt steht, wobei Produkt durchaus auch eine Dienstleistung sein kann, geht es darum, die gestellten Anforderungen zu treffen, nicht zu überschreiten, da das in der Regel mit einem höheren Aufwand bezahlt werden muss, der aber nicht verlangt und wenn die Anforderungen sinnvoll sind, auch nicht gebraucht wird. Wenden wir uns nun den Prozessen zu, die zum Wissensgebiet Qualitätsmanagement gehören. Wie schon in vielen anderen Wissensgebieten, die das Project Management Institute (PMI) im Project Management Body of Knowledge (PMBOK; Project Management Institute (Hrsg), A Guide to the Project Management Body of Knowledge, Ausgabe 2000, Deutsche Übersetzung, 2003) beschreibt, steht am Anfang die Planung. In der Qualitätsplanung wird festgelegt, welche Qualitätsstandards im Projekt verwendet werden und wie diese Qualitätsstandards eingehalten werden können. Diese Planung entspricht dem Grundsatz, dass es besser ist, Qualitätsprobleme durch Vorbeugung zu verhindern als erst durch Prüfen zu entdecken. Qualitätsmängel sollen von vornherein vermieden werden und nicht erst bei der Überprüfung festgestellt werden. Gegenstand der Qualitätsplanung sind aber auch die Kosten. Selbstverständlich müssen die Kosten für die Qualitätsmaßnahmen in einem angemessenen Verhältnis zum Nutzen und zum Ausmaß der Qualitätsverbesserung stehen. In der Qualitätssicherung, dem zweiten Prozess innerhalb des Wissensgebiets des Qualitätsmanagements, geht es um die Tätigkeit, die notwendig sind, um sicherzustellen, dass die geplanten Qualitätsstandards auch erreicht werden. Das kann in der Form der Überprüfung von Prozessen durch Qualitätsaudits erfolgen oder in der Überprüfung der Ergebnisse von Qualitätskontrollen. In diesem Prozess, der das gesamte Projekt begleitet, muss auch darüber nachgedacht werden, ob die Standards, die in der Qualitätsplanung festgelegt worden sind, überhaupt noch ausreichend sind. Von der Qualitätssicherung ist die Qualitätslenkung zu unterscheiden. In diesem Prozess geht es um die Überprüfung einzelner Ergebnisse innerhalb des Projektes. Diese Werte sind dann wieder Grundlage für die Qualitätssicherung, weil sie deutlich machen, ob die geplanten Maßnahmen zur Einhaltung der Qualität ausreichend sind. Integrationsmanagement Dieses Wissensgebiet steht nicht ohne Grund am Ende dieser Reihe. Denn im Integrationsmanagement werden die vielen Plänen, die in den einzelnen Wissensgebieten erstellt worden sind, zu einem konsistenten Projektplan zusammengefügt, der Plan ausgeführt und die sich notwendigerweise während des Projektes ergebenen Änderungen im Plan werden gesteuert. Daraus ergeben sich die Prozesse Entwicklung des Projektplans, Ausführung des Projektplans und die integrierte Änderungssteuerung. Zunächst eine Anmerkung zum Begriff Projektplan. In der Praxis wird dieser Begriff häufig in einem stark eingeengten Sinn verwendet. Der Projektplan ist dann nur die in einer Projektmanagementsoftware erstellte Datei, die die Liste der Aufgaben, die Zeitplanung und die beteiligten Ressourcen enthält. Natürlich ist das ein wichtiger Bestandteil des Projektplans im Sinne des PMBOK, aber eben nur ein Bestandteil. Im Sinne des PMBOK besteht der Projektplan aus folgenden Bestandteilen: Projektauftrag Projektmanagementstrategie Beschreibung des Inhalts und Umfangs Projektstrukturplan Kostenschätzung, nach der Detailplanung: Kostenbasisplan Terminplan, nach der Detailplanung: Terminbasisplan Meilensteine Ressourcenplanung Risikomanagementplan Risikoanalyse einschließlich Risikobewältigung Managementplan des Inhalts und Umfangs Terminmanagementplan Kostenmanagementplan Qualitätsmanagementplan Personalmanagementplan Kommunikationsmanagementplan Risikomanagementplan Beschaffungsmanagementplan Offene Punkte und ausstehende Entscheidungen Dazu kommen noch die notwendigen Detailinformationen wie z.B. Dokumentationen, die begleitend den Projektplan ergänzen. Angesichts der Vielzahl von Elementen, aus denen ein Projektplan besteht, wird deutlich, wie aufwändig es sein kann, daraus ein konsistentes, in sich schlüssiges und widerspruchfreies Dokument zu machen. Die Ausführung des Projektplans besteht in der eigentlichen Projektarbeit, die begleitet werden muss durch regelmäßige Überprüfungen des Status, um sicherzustellen, dass die Arbeiten noch dem Projektplan entsprechen. Notwendige Änderungen müssen das vereinbarte Genehmigungsverfahren durchlaufen und im Projektplan sorgfältig dokumentiert werden. Der Projektplan ist dabei im Prozess der integrierten Änderungssteuerung jeweils zu aktualisieren. Rechtshinweis © CopyRight PROJECT CONSULT 2006 Autorenrechte Dr. Ulrich Kampffmeyer Rechtshinweis Autorenrechte Zum Download sind ausschließlich die Beiträge in der Rubrik Download vorgesehen. Als PDF bereitgestellte Beiträge enthalten auch die zugehörigen Grafiken. Download
Seitentitel: Artikel_Projektmanagement2, Zitierung: http://www.PROJECT-CONSULT.com/home.asp?SR=813 Zuletzt aktualisiert am: 4.8.2006
CopyRight © 1992-2012 PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH 20251 Hamburg, Breitenfelder Str. 17, Tel.: +49-40-46076220, E-Mail, Rechtshinweis Optimiert für MS Explorer 5.x, 6.x, 1024x768 Pixel, Cookies(on), JavaScript(on)
Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com