Archive for the ‘PMBOK’ tag
Basic Concepts and Models in Project Management - An Introduction
PMBOK & PRINCE2 - eine gute Kombination
HIER finden Sie eine interessante Präsentation, die eine sinnvolle Kombination der beiden internationalen PM-Standards PMBOK und PRINCE2 propagiert und erläutert. Wirklich interessant, allerdings wohl nur für fortgeschrittene PM’s.
Qualitätsmanagement in Projekten
Qualitätsmanagement ist ein zentrales Wissensfeld im Projektmanagement. Was aber bedeutet QUALITÄT in Projekten?
Qualität definiert den Grad der Spezifikationserfüllung eines Projekts. Qualität ist immer relativ, d.h. der Kunde bestimmt, ob das Ergebnis von hoher oder geringer Qualität ist. Umso wichtiger ist es, möglichst früh zu verstehen, was der Kunde wirklich will und braucht. Und diese Kundenanforderungen / Spezifikationen gehören entsprechend dokumentiert und (schriftlich) vom Kunden freigegeben!
Welche zentralen Aufgaben beinhaltet das “Project Quality Management”?
- Quality Planning: Identifikation der relevanten Qualitätsstandards des Kunden. (Spezifikationen, Anforderungen…)
- Quality Assurance: geplanter, systematischer Managementprozess zur Sicherstellung einer hohen Projektqualität (= Kundenzufriedenheit) –> zentrale PM-Aufgabe, die sich über den gesamten Projektprozess erstreckt
- Quality Control: kontinuierliche Überwachung der Qualität der Projekt(zwischen)ergebnisse –> möglichst anhand von messbaren Werten/Kennzahlen und in enger Abstimmung mit dem Kunden
Was sind grundsätzliche Qualitäts-Prinzipien in Projekten?
- Customer satisfaction: Kundenbedürfnisse (Requirements) verstehen, evaluieren, definieren und managen, um so Kundenzufriedenheit sicher stellen zu können.
- Prevention over inspection: Die Kosten für die Prävention von Fehlern ist generell um ein Vielfaches geringer als entsprechende Änderungs- oder Korrekturkosten.
- Management responsibility: Um erfolgreich sein zu können (= on scope/on budget/on time –> on quality) müssen alle Teammitglieder in das Qualitätsmanagement eingebunden werden, und das Management muss ein entsprechendes Vorgehen vorleben und auch aktiv einfordern.
- Continuous improvement: Qualitätsmanagement ist ein kontinuierlicher Verbesserungsprozess (oder auch ein iterativer, sprich sich wiederholender Managementprozess). Um sich aber kontinuierlich zu verbessern, muss auch eine Kultur vorherrschen, die es ermöglicht, Fehler machen zu dürfen und vor allem, aus Fehlern zu lernen!
Meilensteine - unverzichtbare Orientierungspunkte in jedem Projekt
Die DIN 69900-1 definiert Meilenstein als “Ereignis besonderer Bedeutung“. Der PMBOK(R) Guide 2004 ergänzt dies um “usually completion of a major deliverable“, d.h. die Fertigstellung eines bedeutenden Projektergebnisses. (Quelle: projektmagazin.de/glossar)
Meilensteine bzw. ein Meilensteinplan sollten in jeder Projektplanung einen Fixbestandteil darstellen. Durch Meilensteine erhält ein Projekt eine Ablaufstruktur, zudem werden Ziele und Zwischenziele klarer und das Controlling (Leistungen, Termine, Kosten) wird erheblich erleichtert.
Häufig werden Meilensteine auch als
- Stop-or-Go Points,
- Quality Gates,
- Review Points oder auch
- Freigabe / Kundenfreigabe.
bezeichnet. Sie alle haben folgende Kriterien gemeinsam:
- Wesentliche Zwischenergebnisse des Projekts liegen vor.
- Der Auftraggeber / das Management / der Kunde entscheiden über die weiteren Schritte (Stop-or-Go).
- Häufig werden Meilenstein-Meetings abgehalten, um über den Status und das weitere Vorgehen zu beraten.
- Durch das Setzen von Meilensteinen entstehen Projektphasen, die sowohl sequenziell als auch parallel ablaufen können.
Wichtig ist, dass Meilensteine in jedem Fall schriftlich dokumentiert werden sollten. Folgende Punkte sind zumindest festzuhalten:
- Status Leistungen / Scope / Qualität
- Status Kosten / Ressourcen
- Status Termine
- Probleme / Open Issues
- Entscheidung(en)
Fazit: Meilensteine sind unverzichtbare Orientieungs- und Entscheidungspunkte in jedem Projekt.
Änderungsmanagement (Change Control)
Kein einziges Projekt läuft exakt so ab, wie es ursprünglich geplant wurde. Inhalte, Ziele, Rahmenbedingungen und Kundenanforderungen können sich verändern - das ist ganz normal. Trotzdem sorgen diese Veränderungen in der Praxis immer wieder für Verwirrung, zwischenmenschliche Konflikte und sogar Rechtsstreitigkeiten. Ein systematisches Änderungsmanagement ist deshalb ein wesentlicher Baustein eines professionellen Projektmanagements.
Es gibt sehr viel Literatur zum Thema Änderungsmanagement, insbesondere in den Bereichen IT-Projektmanagement und Product Lifecycle Management (PLM). Mir persönlich sind diese Vorgehensweisen oft zu bürokratisch und theoretisch.
Deshalb hier einige pragmatische Tipps, wie Sie mit Änderungen in Projekten umgehen können:
- Das Änderungsmanagement beginnt bereits mit der exakten und messbaren Ziel- und Inhaltsformulierung eines Projekts (Project Scope Management). Wenn Ziele und Inhalte unklar oder gar nicht dokumentiert sind, sind Konflikte in den Durchführungsphasen eines Projekts oft schon vorprogrammiert.
- Mein Tipp zum Project Scope Management: Versuchen Sie, die verschiedenen Lieferobjekte (= Deliverables) des Projekts möglichst klar und messbar zu beschreiben. Diese Lieferobjekte haben oft den Charakter von Meilensteinen, die auch entsprechend freigegeben werden müssen (z.B. durch den internen Auftraggeber oder den Projektkunden).
- In vielen Projekten fällt es zu Beginn schwer, die Lieferobjekte der späteren Projektphasen schon exakt zu spezifizieren. Hier besteht die Möglichkeit, zum Beginn einen Rahmenvertrag zu vereinbaren und dann jede einzelne Projektphase inkl. der jeweiligen Lieferobjekte und Inhalte im Detail festzulegen und zu beschließen.
- Wenn Änderungen eintreten, sollten Sie in 7 Schritten abgehandelt werden (siehe Change Control Beitrag bei Wikipedia):
- Die (gewünschte) Änderung wird dokumentiert. –> Record
- Die möglichen Auswirkungen der Änderung werden analysiert und bewertet. –> Impact Assessment
- Die Implementierung der Änderung in den laufenden Projektprozess wird geplant. –> Plan
- Die Änderungen werden erarbeitet. –> Build
- Die Änderungen werden getestet. –> Test
- Die Änderungen werden implementiert. –> Implement
- Die Änderungen werden abgeschlossen und freigegeben. –> Close
- Ich stelle oft fest, dass Menschen mentale Barrieren aufbauen, wenn sich Änderungen ankündigen. Im ersten Schritt ist es einfacher, Änderungen einfach zu ignorieren, zu akzeptieren oder zu bagatellisieren. Dies rächt sich aber fast zwangsläufig in einer späteren Projektphase. Deshalb mein Tipp: Stellen Sie sich den notwendigen Änderungen im Projekt. Sprechen Sie notwendige Änderungen an, auch wenn es weh tut. Schaffen Sie Transparenz und dokumentieren Sie ausreichend. Das heißt nicht, dass Sie einen Bürokratismus aufbauen sollen, doch meiner Einschätzung nach wird in 80-90 % der Projekte zu wenig dokumentiert. Und dies führt zu Konflikten, hohen Änderungskosten oder - wie bereits erwähnt - Rechtsstreitigkeiten. Häufig enden Projekte dann in einer Sackgasse.
- Und noch ein letzter Hinweis: Die Änderungen in einem Projekt gehen meist von den inhaltlichen Zielen aus - dem Project Scope. Diese Änderungen wirken sich dann meist auf die Kosten (Project Budget) sowie auf die Termine (Project Schedule) aus. Als Gedankenstütze und vor allem auch als Argumentationshilfe sollten Sie deshalb immer das Dreieck der Projektziele im Hinterkopf behalten.
Und noch ein allerletzter Hinweis: Oftmals wird Änderungsmanagement als “Change Management” in die englische Sprache übersetzt. Dies sorgt aus meiner Sicht oft für Missverständnisse, da Change Management im generellen Sprachgebrauch für Organisationsentwicklung und betriebliche Veränderungsprozesse steht. Ich empfehle deshalb den Begriff “Change Control” (übrigens auch der offizielle Terminus nach dem PMBOK).
Projekte erfolgreich managen (die Dritte)
Kommunikation ist ein (wenn nicht der) Schlüssel zum Projekterfolg. Was aber bedeutet das für die Praxis? Hier einige FAQ’s zu diesem Thema:
Kann man auch zu viel kommunizieren?
Ja, indem man die Teammitglieder mit (unnützen und schlecht organisierten) Meetings, e-Mails, Statusberichten, Dokumenten u.Ä. eindeckt. Dies kommt in der Praxis aber selten vor. Der Regelfall ist eher, dass viel zu wenig kommuniziert und informiert wird.
Wie sieht die perfekte Projektkommunikation aus?
Diese Frage kann so nicht beantwortet werden. Es gibt keine Patentrezepte. Mein Tipp: Versuchen Sie, sich als Projektleiter/in in die Lage der verschiedenen Stakeholder zu versetzen. Fragen Sie sich, welche Informationen für Sie relevant und wichtig wären, wenn Sie in dieser Position wären? Dann erkennen Sie meistens recht schnell, welcher Informations- und Kommunikationsbedarf besteht.
Wie kann man gezielt und professionell kommunizieren?
Das Kapitel “Project Communications Management” im PMBOK liefert einige gute und praktikable Ansatzpunkte:
- Communications Planning: Informations- und Kommunikationsbedürfnisse der Anspruchsgruppen (Stakeholders) werden identifiziert.
- Information Distribution: Informationen werden gezielt und zeitgerecht an die verschiedenen Anspruchsgruppen verteilt (schriftlich, persönlich, Meetings etc.).
- Performance Reporting: Sammlung und Verteilung von Leistungsdaten und -informationen zum Projektstatus. Hierzu gehören Statusberichte, Fortschrittsmessung anhand konkreter Kennzahlen sowie Prognosen.
- Manage Stakeholders: Die Anspruchsgruppen sollen so frühzeitig wie möglich informiert werden, insbesondere über Planänderungen, eingetretene Risiken etc. Persönliche Gespräche sind oft ein effektiver und vertrauensbildender Weg zur Kommunikation, aber auch Telefonate, e-Mails oder andere technikgestützte Kommunikationswege können zielführend sein.
Fazit: Eine zentrale Aufgabe des Projektmanagers / der Projektmanagerin muss es sein, die Projektanspruchsgruppen (Stakeholders) mit Informationen zu versorgen und Informationen systematisch einzuholen und einzufordern. Etliche Konflikte, Missverständnisse und sogar Rechtsstreitigkeiten (z.B. bei Kundenprojekten) entstehen aufgrund mangelhafter oder schlechter Kommunikation. Diesem Thema kann man in der Praxis kaum genug beimessen.
Projekte erfolgreich managen (die Zweite)
Nicolas Kübler hat gebeten, die Punkte meines Beitrags “Projekte erfolgreich managen…” näher auszuführen. Dieser Bitte komme ich hiermit nach.
Bevor Sie ein Projekt starten, sollten Sie sich überlegen, welche Methodik Sie anwenden möchten. Unter Methodik verstehe ich die Werkzeuge und Instrumente, um Komplexität zu reduzieren, Ziele und Inhalte zu planen, Transparenz zu schaffen, Informations- und Kommunikationsflüsse zu steuern etc.
Wichtig ist hierbei, dass sich die Methodik nach dem jeweiligen Projekt ausrichten und nicht umgekehrt. Ein Tischler verwendet ja auch nicht für jedes Möbelstück dieselben Werkzeuge. Sie sind als Projektleiter/in dafür verantwortlich, dass Sie sich überlegen, welche Methodik im jeweiligen Projekt Sinn machen könnte und wie Sie das Projekt gemeinsam mit Ihrem Team angehen.
Meine kostenlose Plattform PM-Handbuch.com könnte Ihnen zur Beantwortung der Methoden-Frage einige Anregungen geben. Allerdings beschränkt sich die Seite auf die wichtigsten und zentralsten Instrumente zur Initiierung, Planung, Abwicklung und zum Abschluss eines Projekts (= PM-Prozess). Wenn Sie sehr große und komplexe Projekte managen müssen, sollten Sie eventuell eine differenziertere Methodik anwenden (wie z.B. PMBOK oder PRINCE2).
Wichtig ist insbesondere, dass Sie den richtigen Einstieg in ein Projekt finden. Wie heißt es doch so schön? “Der Erfolg eines Projekts entscheidet sich bereits am Beginn.” Sie sollten also versuchen, möglichst viele Unsicherheitsfaktoren von Beginn an auszuschalten. Währen der Initiierung eines Projekts sind möglichst alle W-Fragen (Warum? Was? Wie? Wer? Wann? Wie viel?) zu beantworten. Dies erfordert oft ein entsprechendes “Standing” des/der Projektleiter/in. Denn vom Auftraggeber / Kunden bekommen Sie oft nur sehr unkonkrete Informationen und Anforderungen. Wenn Sie zulassen, dass ein Projekt auf einer derart wackeligen Fundament gestartet wird, dann dürfen Sie sich nicht wundern, wenn Sie schon bald mit Konfusion, Missverständnissen und Frustration konfrontiert sind.
Fazit: Ein professioneller Projektstart mündet in einem Projektauftrag mit klaren Zielen, Rollen, Meilensteinen, Budgets etc. Wenn Sie dieses Grundprinzip des Projektmanagements missachten, schwinden die Chancen auf ein erfolgreiches Projekt dramatisch. Ergänzend hierzu ist auch noch zu sagen, dass die “Grobplanung” bis hin zum Projektauftrag natürlich sehr viel mehr Überlegungen, MindMaps, Konzepte etc. enthalten kann, als die Punkte, die im Projektauftrag erfasst sind. Der Projektauftrag ist lediglich die schriftliche Zusammenfassung der Grobplanung.
To be continued…
Grenzen der Rationalität
Ein Zitat von Dhanu Kothari besagt:
“Ambiguities and uncertainties are part of project management. If rational approach worked every time we wouldn’t need project managers.”
Wie recht er doch hat. PMBOK, ICB, OPM3, PMMM, CMM, ITIL, PRINCE2 etc. sind allesamt durchdachte und tausendfach erprobte Standards oder Methodenkoffer. Doch sie können eben nur ein grobes Gerüst für gutes Projektmanagement darstellen.
Die Gründe für den Erfolg oder Misserfolg eines Projekts liegen fast immer im irrationalen, psycho-sozialen oder “soften” Bereich. Intuition, Bauchgefühl, soziale Fähigkeiten, Empathie und Erfahrung des Projektmanagers/der Projektmanagerin spielen hierbei eine zentrale Rolle.
Die besten ProjektmanagerInnen, die ich persönlich kenne, vereinen “hartes” Fach- und Methodenwissen mit “weichen” Fähigkeiten und Erfahrungswerten.
Ihr Stefan Hagen
Change Management
(Quelle: www.umsetzungsberatung.de - Sensationeller Change Management Guide!)
Gestern Nachmittag hat das traditionsreiche Vorarlberger Textilunternehmen WOLFF Wäsche Konkurs angemeldet. Diese bedauerliche Nachricht nehme ich zum Anlass, kurz einige Gedanken zum Thema Change Management los zu werden.
Was wird eigentlich genau unter “Change Management” verstanden? Ich bin davon überzeugt, dass man 10 unterschiedliche Definitionen zu hören bekommt, wenn man 10 unterschiedliche Personen befragt. Auf der Suche nach einer griffigen Definition bin ich bei Wikipedia fündig geworden - wen wundert’s.
“Unter Veränderungsmanagement (englisch change management) lassen sich alle Aufgaben, Maßnahmen und Tätigkeiten zusammenfassen, die eine umfassende, bereichsübergreifende und inhaltlich weit reichende Veränderung - zur Umsetzung von neuen Strategien, Strukturen, Systemen, Prozessen oder Verhaltensweisen - in einer Organisation bewirken sollen.”
Übrigens: Auch in der Welt des Projektmanagements wird vielfach von “Change Management” gesprochen - nämlich als Übersetzung für das deutsche “Änderungsmanagement”. In der englischen PM Terminologie wird Änderungsmanagement aber meines Wissens korrekt mit “Change Control” übersetzt (beispielsweise im PMBOK von PMI). Sollte ich aber falsch liegen, lasse ich mich gerne eines Besseren belehren.
Nun aber meine persönlichen Gedanken und Erfahrungswerte zum Thema Change Management:
- Der globale Wandel der Wirtschafts- und Gesellschaftssysteme wird immer dynamischer. Wer sich nicht ebenso dynamisch auf die neuen Rahmenbedingung einstellt, wird früher oder später vom Markt verschwinden.
- Change Management (im Sinne der obigen Wikipedia-Definition) wird weiter an Bedeutung gewinnen.
- Projektmanagement ist eine der wichtigsten Methoden, um Veränderungen umzusetzen. Man könnte auch sagen, um “die PS auf den Boden zu bringen.”
- Die große Herausforderung am Change Management ist, dass es keine Patentrezepte gibt. Jeder Veränderungsprozess hat seine eigenen Spielregeln und muss individuell geplant und umgesetzt werden.
- Das Gefährliche an Change Management Prozessen ist, dass sich Manager und Mitarbeiter oft an eingespielten Verhaltensweisen klammern - Widerstände sind vorprogrammiert. Frei nach dem Motto: “Was bisher richtig war, kann doch nicht plötzlich falsch sein.” Leider eben schon: Die Erfolgsrezepte früherer Tage können heute genau falsch sein.
- DIE Grundvoraussetzung für Veränderungsprozesse schlechthin: Top Management Commitment! Wenn die Führung nicht felsenfest hinter der Veränderung steht, muss man gar nicht erst anfangen.
- Die Prinzipien des systemischen Managements (auch Management-Kybernetik oder Vernetztes Denken) sind in Veränderungsprozessen von großer Bedeutung. Es gilt, den Hebel dort anzusetzen, wo mit einem vertretbaren Aufwand schnell etwas bewirkt werden kann.
- Veränderungsprozesse benötigen zudem klare, möglichst bild- und lebhafte Visionen, die auf konkrete Veränderungsziele herunter gebrochen werden.
- In Veränderungsprozessen besteht permanent die Gefahr, dass die destruktiven Kritiker - wie ich sie gerne bezeichne - Überhand gewinnen oder zumindest lauter schreien. Fokussieren Sie sich wenn möglich auf die positiven Kräfte im Unternehmen - auf die konstruktiven Kritiker.
- Die Visionen und Ziele der Veränderung müssen kontinuierlich kommuniziert werden. Studien haben gezeigt, dass Strategieänderungen zwischen 60 und 80 (!!!) mal kommuniziert werden müssen, bis sie greifen! Das heißt für das Management: “Walk the talk.”
- Und zu guter Letzt bin ich davon überzeugt, dass man für erfolgreiche Veränderungen eine große Portion an Durchhaltevermögen benötigt. Ich bezeichne das auch als “Energiemanagement”. Sie sollten dieses Thema im Kreis der Veränderungspromotoren (Change Agents) thematisieren und gezielt angehen.
In den nächsten Tagen werde ich über den PM-Blog.com noch einige - hoffentlich hilfreiche - Internet-Links zum Thema Change Management publizieren. Stay tuned…
Ihr Stefan Hagen
Risikomanagement Prozesse
Viele Unternehmen vernachlässigen auf sträfliche Art und Weise das Management von Risiken - insbesondere auch in Projekten. Dieser kurze Beitrag soll einige Ansätze und Best Practices aufzeigen, wie man Risiken begegnen kann.
Was sind Risiken?
Das PMBOK von PMI (Project Management Institute) definiert ein Risiko wie folgt:
“Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on at least one project objective, such as time, cost, scope, or quality.”
Wie sieht professionelles Risikomanagement aus?
Das PMBOK definiert folgende RM-Teilprozesse:
1) Risk Management Planning: Es wird auf der Basis der internen Standards, Richtlinien und Erfahrungswerte entschieden, wie das Risikomanagement im jeweiligen Projekt organisiert wird (z.B. Wie viel RM ist nötig? Wer ist für das RM zuständig? Haben wir Erfahrungswerte in dieser Projektart? Gibt es Risiko-Checklisten?)
2) Risk Identification: Die Identifikation von Risiken ist ein permanenter Prozess in Projekten. Potenzielle Risiken können über Dokumentenanalyse, Brainstorming, SWOT-Analyse oder auch spezifische Techniken wie Ursache-Wirkungs-Analysen (Cause-and-effect diagrams) identifiziert werden. Der Output dieses Teilprozesses sind Checklisten, Mindmaps und Ähnliches mit den identifizierten Risiken.
3) Qualitative Risk Analysis: Die identifizierten Risiken werden hinsichtlich ihrer Eintrittswahrscheinlichkeit (Probability) und ihrer Auswirkung (Impact) untersucht. Auf dieser Basis kann eine Priorisierung der Risiken vorgenommen werden (z.B. A, B und C-Risiken).
4) Quantitative Risk Analysis: Eine quantiative Risikoanalyse wird in der Regel nur bei hoch priorisierten Risiken durchgeführt. Es wird versucht, die Risiken näher zu spezifizieren, Auswirkungen und Wahrscheinlichkeit im Detail zu berechnen und verschiedene Szenarien zu simulieren.
5) Risk Response Planning: Geeignete Gegenmaßnahmen werden festgelegt, um Gefahren / negative Risiken auszuschließen, zu übertragen oder zu verringern und Chancen / positive Risiken herbeizuführen, mit den Beteiligten zu teilen oder auszubauen.
6) Risk Monitoring and Control: Das Risikomanagement ist ein kontinuierlicher Prozess über den gesamten Projektlebenszyklus hinweg. Potenzielle oder eingetretene Risiken sollten laufend idenfiziert und proaktiv gelöst werden.
Die hier kurz beschriebenen RM-Teilprozesse sind in dieser Form natürlich theoretisch. Wenn sie aber konsequent angewendet und vor allem pragmatisch an die jeweiligen Situationen und Rahmenbedingungen angepasst werden, sind deutlich bessere Projektergebnisse möglich (on scope, on budget, on time).
Ihr Stefan Hagen


