Projektmanagementansätze

Projektmanagement soll dabei helfen neuartige, komplexe Problemstellungen planbar zu machen, und das Risiko bei der Durchführung zu scheitern zu minimieren. Es liegt auf der Hand, dass es - je nach Art der zugrundeliegenden Problemstellung - verschiedene Wege als Optimum beschrieben werden, die jedoch große Ähnlichkeiten aufweisen. So gibt es beim Projektmanagement Parallelen zum Eventmanagement oder auch zum Prozessmanagement, und allein beim Projektmanagement gibt es auch schon unterschiedliche Ansätze, je nachdem ob es sich etwa um IT-Projekte, Bauprojekte, Produkteinführungen etc. handelt. 

Hier folgt ein Überblick über weit verbreitete Projektmanagement-Ansätze, auf eine Auswahl davon wird weiter eingegangen. (Quelle: Wikipedia)

Formale Projektmanagementsysteme

• DIN 69900-69905, u. a. DIN 69901
• ISO 10006 Project Management Body of Knowledge (PMBOK Guide): PM-Standard des Projektmanagementverbandes Project Management Institute
• IPMA Competence Baseline ICB: PM-Standard des Projektmanagementverbandes International Project Management Association/ Deutsche Gesellschaft für Projektmanagement (GPM)
• PRINCE2: weit verbreitete Projektmanagementmethode in Großbritannien und den Niederlanden, zunehmend aber auch international und somit in Deutschland
• V-Modell: Vorgehensmodell; Standard für Projektmanagement IT-Entwicklung im öffentlichen Dienst in Deutschland
• HERMES ist die Projektmanagementmethode für Informatikprojekte in der schweizerischen Bundesverwaltung
• Project Management Maturity Model (PMMM) (vergleiche CMMI)
• IEC 62198 Project Risk Management

V-Modell

Dokumenten-Status und deren Übergänge Jedes definierte Produkt durchläuft vier Zustände:

1. geplant
   
2. in Bearbeitung
   
3. vorgelegt
   
4. akzeptiert
   

wobei folgende Übergänge zwischen diesen Zuständen möglich sind:

Tätigkeiten, die Produkte verändern, bezeichnet man als Aktivitäten; diese sind ihrerseits aus einzelnen Teilaktivitäten zusammengesetzt, die dann jeweils genau ein Thema behandeln. Inhaltlich verwandte Aktivitäten werden dabei wiederum zu Aktivitätengruppen zusammengefasst. Zu jeder Aktivität ist genau hinterlegt, welche Produkte sie benötigt bzw. verändert und welche Arbeitsschritte notwendig sind, um die gewünschte Modifikation herbeizuführen. Zu diesem Zweck ist jeder Aktivität ein Produktfluss und eine Abwicklung definiert. Während der Produktfluss beschreibt, aus welchen Aktivitäten die benötigten Eingabeprodukte mit welchem Zustand kommen, um dann in modifizierter Form bzw. modifiziertem Zustand an eine nachfolgende Aktivität weitergereicht zu werden, beinhaltet die Abwicklung genauere Anweisungen zur Durchführung der Aktivität.

Die zeitliche Abfolge der Aktivitäten ergibt sich somit aus der Verfügbarkeit der benötigten (Teil-)Produkte in einem bestimmten Zustand.

Beispiel für einen Projektablauf nach dem V-Modell

PMBOK Guide

In der Einführung bezeichnet sich das Werk als „Zusammenfassung des Wissens der Fachrichtung Projektmanagement“. Gemeint ist das Wissen über die Vorgehensweisen, die weithin als bewährte Praxis (PMBOK Guide: „best practice“) anerkannt wird. Die beschriebenen Methoden sind auf Projekte aus verschiedenen Anwendungsbereichen anwendbar, dazu gehören u.a. Bauwesen, Software-Entwicklung, Maschinenbau und Automobilindustrie.

Der PMBOK Guide ist prozessorientiert, d. h. er verwendet ein Modell, nach dem Arbeit durch Prozesse erledigt wird. Ein Projekt wird durch das Zusammenspiel vieler Prozesse durchgeführt. Anhand der Prozesse strukturiert der PMBOK Guide das gesammelte Methodenwissen. Für jeden Prozess werden Input, Output und Werkzeuge und Verfahren beschrieben.

Quelle: Wikipedia

Mehr Informationen zum Wissensgebieten und Prozessgruppen im Wikipedia-Artikel

SCRUM

Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können. Ein wesentlicher Teil der Anforderungen und der Lösungsansätze ist zu Beginn unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaffen werden. Anhand dieser Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase. In Scrum wird neben dem Produkt auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan (das Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (das Sprint Backlog) wird nur für den jeweils nächsten Zyklus (den Sprint) erstellt. Damit wird die Projektplanung auf das Wesentliche fokussiert.

Die empirische Verbesserung fußt auf drei Säulen:

1. Transparenz: Fortschritt und Hindernisse eines Projektes werden regelmäßig und für alle sichtbar festgehalten.
   
2. Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und sowohl das Produkt als auch das Vorgehen beurteilt.
   
3. Anpassung: Anforderungen an das Produkt, Pläne und Vorgehen werden nicht ein für alle Mal festgelegt, sondern kontinuierlich detailliert und angepasst. Scrum reduziert die Komplexität der Aufgabe nicht, strukturiert sie aber in kleinere und weniger komplexe Bestandteile, die Inkremente.
   

Ziel ist die schnelle und kostengünstige Entwicklung hochwertiger Produkte entsprechend einer formulierten Vision. Die Umsetzung der Vision in das fertige Produkt erfolgt nicht durch die Aufstellung möglichst detaillierter Lasten- und Pflichtenhefte. In Scrum werden die Anforderungen in Form von Eigenschaften aus der Anwendersicht formuliert. Die Liste dieser Anforderungen ist das Product Backlog. Diese Anforderungen werden Stück für Stück in zwei bis vier Wochen langen Intervallen, sogenannten Sprints umgesetzt. Am Ende eines Sprints steht bei Scrum die Lieferung eines fertigen Teilprodukts (das Product Increment). Das Produktinkrement sollte in einem Zustand sein, dass es an den Kunden ausgeliefert werden kann (potentially shippable product). Im Anschluss an den Zyklus werden Produkt, Anforderungen und Vorgehen überprüft und im nächsten Sprint weiterentwickelt.

Scrum ist für Teams mit einer Größe von drei bis neun Personen konzipiert. Größere Entwicklungsprojekte oder größere Entwicklungsabteilungen benötigen ein weitergehendes Framework, das die Koordination mehrerer Teams organisiert. Wenn diese Koordination den gleichen Prinzipien wie Scrum folgt, dann spricht man von Scaled Agile Frameworks.

Quelle: Wikipedia

International Competence Baseline

Die IPMA Competence Baseline (ICB) ist der internationale Projektmanagement-Standard der IPMA – International Project Management Association.

Die ICB ist die inhaltliche Grundlage für die internationale Anerkennung der nationalen Programme zur Zertifizierung von Projektmanagement-Personal über vier Qualifikations- und Kompetenz-Ebenen.

Diese sind zwischen der IPMA und ihren 40 Landesgesellschaften abgestimmt und werden im sogenannten 4-L-C-System beschrieben. Die ICB umfasst die drei Kompetenzfelder Technical Competences, Behavioural Competences und Contextual Competences, bestehend aus insgesamt 46 Elementen für die Beurteilung von Wissen und Erfahrung sowie von persönlichem Verhalten und dem allgemeinen Eindruck, die den Kompetenznachweis von Personen im Projektmanagement abrunden.

Quelle: Wikipedia

Projektmanagement in der Schule

Projektmanagement im Schulbereich kommt einerseits als Werkzeug zur Durchführung von Aktivitäten zum Einsatz, aber auch als Gegenstand des Unterrichts. Obwohl sich Projektmanagement an den Bedürfissen unternehmerischer Prozesse orientiert und damit per se Effizienzsteigerung bewirken soll, bleibt diese Effizienz bei der Vermittlung der Projektmanagementmethoden im Unterricht oft auf der Strecke. Obwohl manche Methoden vermittelt werden müssen, gibt es an der Schule keine Projekte, die diese erfordern würden.

In der Praxis würde man in so einem Fall nicht auf alle diese Methoden zurückgreifen, sondern eine Einschränkung auf eine Teilmenge an Projektmanagementmethoden vornehmen.

Als Basis für die weiteren Überlegungen in diesem Kurs kommt die ICB der IPMA zum Einsatz.