Glossar
7 Key Principles bestimmen den Projekterfolg!
Key Principles* (Grundprinzipien) bestimmen den Ablauf in der Natur, in der Mathematik und im Leben! Das Wort Prinzip stammt aus dem Lateinischen und bedeutet „Anfang, Beginn, Ursprung, Grundsatz“. Die Analyse abgeschlossener Projekte zeigt erstaunliche Unterschiede zwischen einem erfolgreichen Projekt und einem Projektdesaster. Ein Projekt ist erfolgreich, wenn das Projektziel im geplanten Zeit- und Kostenrahmen erreicht wird und die Stakeholder mit dem Abschluss zufrieden sind. Ein Projekt ist ein Desaster, wenn das Projektziel nicht erreicht wird oder der geplante Zeit- oder Kostenrahmen wesentlich überschritten wird oder die Stakeholder am Projekterfolg zweifeln!
Erfolgreiche Projekte folgen den 7 Key Principles, von der Projektidee bis zum Projektabschluss:
1. Das Ziel muss eindeutig und messbar sein.
2. Der Start bestimmt zu 80% den Projekterfolg!
3. Die Analyse managt Projekt- Risiken und Chancen.
4. Die Struktur legt die Rahmenbedingungen fest.
5. Die Steuerung navigiert das Projekt zum Ziel.
6. Qualität ist der Trigger und KVP die Steuerung.
7. Der Abschluss ist geplant & erfolgreich oder offen!
*Sind sinngemäß vergleichbar mit Grundprinzipien, erheben aber nicht denselben Anspruch.
Key Principle #1: Projektziel
#ProjektQuader
Das Projektziel beschreibt den geplanten SOLL-ZUSTAND zum Projektabschluss mit einer kurzen und prägnanten Projektvision (oder auch Leistungsziel genannt) und definiert: Die Leistung: Was soll gebaut, entwickelt oder konstruiert werden? Die Kosten: Wie hoch ist das Budget für das Gesamtprojekt? Und den Zeitrahmen vom Projektstart bis zum Projektabschluss.
- Das Projektziel definiert auch den SOLL-ProjektQuader
- Der Projektabschluss definiert den IST-ProjektQuader
Die Projektqualität = IST-/SOLL-ProjektQuader
Der SOLL-Leistungsumfang erhält normiert den Wert „1“ in der oben genannten Formel. Vergrößert oder verringert sich der Leistungsumfang bis zum Projektabschluss, dann ändert sich der IST-Leistungsumfang und wird größer (> 1) oder kleiner (< 1), immer normiert in Bezug auf den SOLL-Leistungsumfang.
Key Principle #2: Projektstart
Was gehört zu einem erfolgreichen Projektstart und wann „startet“ ein Projekt? Die Phase von der Projektidee bis zum offiziellen Projektstart wird als Konzeptphase oder Projektvorphase bezeichnet. In dieser Phase entwickelt sich ein Projekt von der ersten Idee bis zu der Entscheidung, ob es „real“ gestartet wird oder nicht. Viele Projekte bleiben in der Konzeptphase stecken und werden nie realisiert. Aus verschiedenen Gründen wie z.B. keine ausgereifte Projektidee, das Konzept kann nicht umgesetzt werden, kein klares Projektziel, kein Budget oder keine Zeit. Ein Projekt hat den Reifegrad zum Projektstart erreicht, wenn das Projektziel eindeutig und klar festliegt, das Projektbudget und die Ressourcen vorhanden sind oder beschafft werden können, der geplante Zeitrahmen zur Verfügung steht und die wichtigen Stakeholder dem Projekt zustimmen.
Projekte erfolgreich starten: PM Smart Start
1. Das eindeutige, messbare Projektziel.
2. Der Projektauftrag/Projektleitervertrag.
3. Die Projektregeln.
4. Die Projektorganisation.
5. Das Kick-Off-Meeting oder Starter-Workshop.
6. Das Lastenheft/Pflichtenheft.
7. Das Projekt betreffende Gesetze, Normen, Datenschutz-, Security-, Vorschriften und Richtlinien.
8. Die Projektstandardisierung (gibt es bereits ähnliche Projekte als Vorlage - Template?)
Key Principle #3: Projektanalyse
#ProjektRaum
Jedes Projekt befindet sich in einem ProjektRaum. Um den ProjektRaum zu kennen, muss dieser analysiert werden. Der ProjektRaum und das Projekt stehen in einer ständigen Wechselbeziehung. Auf Basis der Analyse können geeignete Maßnahmen und Strategien zur Steuerung der Wechselbeziehungen erarbeitet werden.
Zur ProjektRaum-Analyse gehören:
1.) Die Stakeholderanalyse,
2.) die Umfeldanalyse,
3.) die Risikoanalyse und
4.) die Projekt-Chancen-Analyse.
Die gegenseitige Beeinflussung von Projekt, Umfeld und Stakeholder, sowie die Fähigkeit mit diesen Wechselbeziehungen umzugehen, bestimmen maßgeblich den Projekterfolg. Deshalb sollte die Stakeholderanalyse zum Projektbeginn durchgeführt werden. Es ist wichtig, die Stakeholder zu identifizieren, den Grad ihrer Betroffenheit durch das Projekt festzustellen und ihre Einstellung zum Projekt zu kennen. Anhand dieser Informationen können Maßnahmen verabschiedet werden, die Stakeholder einzubinden und als „Unterstützer des Projektes“ zu gewinnen. Neben der Stakeholderanalyse liefert die Umfeldanalyse wichtige Erkenntnisse, wie Projekt und Umfeld in Wechselwirkung stehen. Projekte unterliegen Risiken und bieten auch Chancen. Die Projektrisiken zu kennen, zu bewerten, zu klassifizieren und entsprechende Maßnahmen zu deren Vermeidung schon vor dem Projektstart zu planen, ist ein wichtiger Baustein des Projekterfolgs. Neben den Risiken muss man auch die Chancen eines Projektes erkennen, damit daraus ein „Mehrwert“ z.B. für den Kunden, das Unternehmen, etc. generiert werden kann. Ohne einen Mehrwert für die wichtigen Stakeholder gäbe es auch nicht „dieses Projekt“. Denn: „Jedes Projekt ist einmalig!“
Key Principle #4: Projektstruktur
Die Projektstruktur zeigt die funktionale Gliederung des Projekts, weist das gewählte Vorgehensmodell aus, legt die wichtigen Arbeitspakete fest und definiert den Zeit- und Kostenplan. Unter der Projektstruktur versteht man im Projektmanagement die funktionale und logische Gliederung eines Projektes in Teilaufgaben und Arbeitspakete. Daraus entsteht der sogenannte Projektstrukturplan. Die Gliederung erfolgt meist in grafischer Form. Aus ihr geht hervor, wie das Projekt funktional strukturiert ist und was in diesem Projekt geplant und umgesetzt wird. Zum Grundprinzip Projektstruktur gehören der Projektstrukturplan, ein passendes Vorgehensmodell, der Projektphasenplan, die Festlegung der Arbeitspakete, der Meilensteinplan und der Kostenplan.
Zur Projektstruktur gehören:
1.) Der Projektstrukturplan,
2.) das gewählte Vorgehensmodell im Projekt,
3.) der Projektphasenplan,
4.) die Definition der wichtigsten Arbeitspakete,
5.) der Netzplan,
6.) der Meilensteinplan mit Meilenstein-Trendplan und
7.) der Kostenplan.
Der Projektstrukturplan gliedert das Projekt in funktionale und in sich abgeschlossene Teilprojekte bzw. Projektabschnitte. Auf der 1. Ebene wird das Projektziel definiert. Die 2. Ebene definiert die Teilprojekte bzw. Projektabschnitte. Die 3. Ebene beschreibt z.B. die einzelnen Arbeitspakete eines Projektabschnitts. Die Anzahl der Ebenen wird durch die funktionale Projektstruktur bestimmt und kann bei Groß- und komplexen Projekten recht umfangreich werden. Hierbei wird auf die Darstellung der einzelnen Arbeitspakete verzichtet, damit die funktionale Übersicht gewahrt bleibt. Der Projektstrukturplan bietet eine gute Übersicht des Gesamt-Projekts und darf in keinem Projekt fehlen.
Key Principle #5: Projektsteuerung
Die Projektsteuerung lenkt das Projekt und beruht auf der Fortschrittskontrolle. Die Fortschrittskontrolle ermittelt den aktuellen Ist-Stand und vergleicht diesen mit dem Soll-Stand in Bezug auf die erbrachte Leistung, die angefallenen Kosten und die verbrauchte Zeit. Liegen die Abweichungen außerhalb des Toleranzbereichs, dann sollten „notwendige Maßnahmen“ zur Erreichung des Soll-Stands eingeleitet werden. Die Projektkontrolle, auch Fortschrittskontrolle genannt, ist ein grundlegendes Steuerungsinstrument für den Projektleiter, um den aktuellen Ist-Projektstand und -fortschritt zu ermitteln. Erst wenn der aktuelle Ist-Projektstand bekannt ist, lassen sich Maßnahmen für den weiteren Projektverlauf ableiten.
Die Fortschrittskontrolle ist ähnlich wie das Navigationssystem im Auto: Ein Blick und der Fahrer weiß, ob er auf dem richtigen Weg ist, wie nah er seinem Ziel ist und wie lange es noch dauert um dort anzukommen. Aber leider ist die Fortschrittskontrolle nicht so exakt wie ein Navigationssystem und beruht auf „Messen“, „Wiegen“, „Zählen“ und „Schätzen“. Entwicklungs- oder Organisationsprojekte bieten oft nicht die Möglichkeit, den Leistungsfortschritt exakt zu ermitteln, weil die objektive Möglichkeit zum Messen, Wiegen oder Zählen fehlt. Hier ist man meist auf „Schätzungen“ angewiesen. Ein guter Quervergleich bietet der Kosten- und Zeitplan. Liegt die Schätzung im Rahmen des Kosten- und Zeitplans, dann scheint die Schätzung zu stimmen, muss aber nicht. Die Fortschrittskontrolle beginnt mit dem Projektstart und endet mit dem Projektabschluss. Der Projektleiter sollte die Fortschrittskontrolle im Projekt bzw. Projektteam vom Projektstart an verankern und die wichtigsten Stakeholder über den Projektstand und -Verlauf kontinuierlich (wöchentlich, monatlich) informieren. Damit wird sichergestellt, dass es während der Projektlaufzeit zu keinen „bösen Überraschungen“ kommt.
Key Principle #6: Qualität - KVP im Projekt
Qualität ist der Trigger und KVP die Steuerung. KVP im Projekt dient der kontinuierlichen Verbesserung der Projektqualität und ist ein erprobtes Tool für Projekt-De-Eskalationen. Der „Kontinuierliche Verbesserungs-Prozess“ (KVP) findet in vielen professionell gemanagten Projekten Anwendung und hat sich bestens bewährt, wenn es um die Verbesserung der Projektqualität und Projekt-Eskalationen geht. Im ProjektWorkbook wird eine Methodik zur kontinuierlichen Verbesserung vorgestellt, die in vielen komplexen- und Groß-Projekten Anwendung findet. Die Methode basiert auf der Analyse von sogenannten „KatastrophenProjekten” und wie diese durch KVP erfolgreich zum Projektabschluss geführt werden konnten.
Warum KVP im Projekt? Nicht alle Projekte laufen strikt nach Plan und es kommt oft zu Abweichungen im Leistungsumfang, im Kosten- oder Zeitplan. (Die drei Projektdimensionen!) Liegen die Abweichungen im Toleranzbereich, dann ist das Projektziel meist nicht gefährdet. Jedes Projekt hat einen umgebenden „ProjektRaum“. Aus diesem ProjektRaum heraus oder innerhalb des Projekts kann es zu plötzlichen und unerwarteten „Störungen“ kommen, die den weiteren Projektverlauf negativ beeinflussen. Innerhalb eines Projekts wären das z.B. technische Lösungen, die bei der Umsetzung nicht den gewünschten Erfolg bringen; oder aber die geplante Projektstruktur oder der geplante Projektablauf erweisen sich als fehlerhaft. Aus dem ProjektRaum heraus können dies z.B. negative Einflüsse einzelner Stakeholder sein, die das Projektziel gefährden. Das Risiko von Störungen, Fehlern und externen negativen Einflüssen ist gerade bei Projekten, wegen deren Einmaligkeit, größer als bei Routineabläufen. Diese negativen Einflüsse lassen sich leider nicht zu 100% verhindern, aber mit einer passenden Methode zumindest professionell managen. Die passende Methode im Projektmanagement ist KVP!
Key Principle #7: Projektabschluss
Wann ist ein Projekt erfolgreich abgeschlossen? Klare Antwort: Wenn das Projektziel im Kosten- und Zeitrahmen erreicht wurde und die wichtigen Stakeholder mit dem Projektziel zufrieden sind! Aber ganz so ideal ist der Sachverhalt in der Praxis leider nicht immer. Zum Projektabschluss gehören die Übergabe des Projektes an den Auftraggeber, (Kunden) sowie die Abnahme des Projektes durch den Auftraggeber. Zwischen der Übergabe und der Abnahme gibt es einen rechtlichen Unterschied. Unter einer Abnahme versteht man die Feststellung, dass das Leistungsziel (das Objekt des Projektziels) den vertraglichen Kriterien entspricht. Zur Abnahme sollte es deshalb auch immer ein Abnahmeprotokoll geben, das von den Vertragspartnern zu unterzeichnen ist.
Die Übernahme eines Projekts ist ein Besitzerwechsel vom Auftragnehmer an den Auftraggeber. Es findet ein Gefahrenübergang statt. Ab der Übernahme ist nicht mehr der Auftragnehmer, sondern der Auftraggeber für das Objekt des Projektziels verantwortlich. Zugleich beginnen meist die Gewährleistungs- und Garantiefristen zu laufen. Im Idealfall wird das Projekt ohne Beanstandungen und Mängel an den Auftraggeber übergeben. Der Projektabschluss wird durch ein Abnahme- und Übergabeprotokoll dokumentiert. Die Protokolle sollten von den Vertragspartnern gemeinsam unterzeichnet werden. Wie der Projektabschluss exakt gehandhabt wird, findet sich meist auch im (Projekt-) Vertrag.
Projekt-Deeskalation
Werden die 7 Grundprinzipien erfolgreicher Projekte nicht eingehalten dann besteht die Gefahr, dass sich kleine Probleme im Projekt zu einem Projektdesaster entwickeln.
Was ist ein Projektdesaster? Der Duden definiert „Desaster“ als ein verhängnisvolles Unglück, ein schweres Missgeschick, einen Fehlschlag, einen finanziellen Reinfall, ein Fiasko, einen Flop oder als einen GAU. Ein Desaster kann oft nur mit zusätzlichen Ressourcen unter Kontrolle gebracht werden kann. In diesem Sinne läuft ein Projekt ins „Desaster“, wenn folgende Kriterien eintreffen:
Projektdesaster-Kriterien
1. Das Projektziel wird verfehlt.
2. Das Projektziel = eine Projektwunschliste.
3. Die Kosten explodieren.
4. Der Projektabschluss ist ungewiss.
5. Der Projektleiter wird gewechselt.
6. Das Projektteam ist frustriert.
7. Das Management ist ratlos.
8. Die Stakeholder zweifeln am Projekterfolg.
Gerade digitale Transformations-Projekte bergen die Gefahr, dass das Projektziel zu einer Projektwunschliste mutiert. Gegen eine Projektwunschliste ist im Prinzip nichts einzuwenden, ABER jeder Projektwunsch ist dreidimensional: Wunsch (Leistung) = Kosten x Zeit. Der ProjektQuader vergrößert sich mit jedem Wunsch und die Projektqualität verringert sich!
Werden die „7 Key Principles“ nicht eingehalten dann besteht die Gefahr, ins Projektdesaster zu geraten!
Projektdesaster managen. „KVP im Projekt“ bietet eine praxiserprobte Methode, Projektdesaster aus der Eskalation zu führen! Eine praxistaugliche KVP-Methode: Die ständige Verbesserung: Probleme exakt beschreiben, den Schaden eindämmen, die Ursache herausfinden, Lösungen suchen, die optimale Lösung vereinbaren, die Lösung zeitnah im Projekt implementieren und auf Tauglichkeit prüfen.
1. Problemdefinition (Issue Definition)
2. „Erste Hilfe“ (Containment)
3. Ursachenanalyse (Root Cause Analysis)
4. Lösungssuche (Solution Search)
5. Lösungsauswahl (Agreed Solution)
6. Lösungsumsetzung (Implement Solution)
7. Lösungsprüfung (Verified Solution)
PM-Modelle
Projektmanagement (PM) Vorgehensmodelle beschreiben den idealtypischen Projektablauf zur optimalen Erreichung des Projektziels.
Nicht alle, aber einige Projektkategorien benötigen für einen optimalen Projektablauf oder auch „Project Workflow“ genannt, ein passendes Vorgehensmodell. Der klassische „Project Workflow“ ist das sequentielle Phasenmodell. Dies findet auch heute noch in den meisten Projekten Anwendung und hat sich in der Praxis gut bewährt. Auf Basis des Phasenmodells haben sich für unterschiedliche Projektkategorien, wie z.B. bei Entwicklungsprojekten, „passendere“ Vorgehensmodelle entwickelt.
Ist das Projektziel, der Soll-Leistungsumfang, der Kosten- und Zeitplan klar, eindeutig und messbar, dann eignen sich sequentielle Vorgehensmodelle. Zu diesen gehören das Phasen-, Wasserfall oder Schleifen-Modell. Was am Anfang definiert wurde, wird bis zum Projektabschluss konsistent durchgeführt. Dies hat für einige Projektkategorien Vorteile (z.B. Infrastrukturprojekte) und für andere Nachteile (z.B. Entwicklungsprojekte).
Wasserfall-Modell
Ist das Projektziel, der SOLL-Leistungsumfang, der Kosten- und Zeitplan klar, eindeutig und messbar, dann eignen sich sequentielle Vorgehensmodelle. Zu diesen gehören das Phasen-, Wasserfall oder Schleifen-Modell. Was am Anfang definiert wurde, wird bis zum Projektabschluss konsistent durchgeführt. Dies hat für einige Projektkategorien Vorteile (z. B. Infrastrukturprojekte) und für andere Nachteile (z. B. Entwicklungsprojekte). Der Name Wasserfall kommt von der häufig gewählten Darstellung der als Kaskade angeordneten Projektphasen.
Agiles Projektmanagement
Zu den iterativen PM-Modellen gehört das „Agile Projektmanagement“. Das iterative Modell stammt ursprünglich aus der Mathematik. Es ist die schrittweise Wiederholung von kleinen, geänderten Rechenvorgängen um sich der exakten Lösung bestmöglich zu nähern. Agiles Projektmanagement ist ein dynamischer Kreislauf, der sich gut für Softwareentwicklungsprojekte eignet z.B: Projektziel -> Konzept -> User Test -> Änderungen -> Konzept.
Das Wort „agil“ ist ein Adjektiv und bedeutet flink, wendig, lebhaft, gewandt, gelenkig, etc. Agiles Projektmanagement beschreibt eine spezielle Vorgehensweise von relativ kurzen Zyklen z.B: Konzepterstellung -> Entwicklung -> User Test (Feedback) -> Änderungen im Konzept und der Entwicklung -> erneuter User Test (Feedback), etc.
Das Ziel des „Agilen Projektmanagements“ ist es, die Ablaufprozesse flexibler, schlanker und schneller zu gestalten. Unter dem Oberbegriff „Agiles Projektmanagement“ sind speziell in der Softwareentwicklung weitere Vorgehensmodelle wie z.B. Scrum entstanden. Agiles Projektmanagement hat Vor- und Nachteile und lässt sich nicht in allen Projekten anwenden.
Scrum
Scrum (englisch Gewimmel, Gedränge), ist ein dynamisches PM-Modell und gehört vom Ursprung her zur „Agilen Softwareentwicklung“. Ist das Projektziel nicht eindeutig und messbar, dann kann Scrum gute Lösungsvarianten liefern. Das sogenannte „Scrum Framework“ definiert 3 Rollen: Product Owner, Development Team und Scrum Master. Der Product Owner ist für das Projektziel bzw. für das Produkt verantwortlich. Das Development Team ist für die Entwicklung bzw. Realisierung des Projektziels verantwortlich und der Scrum Master wirkt in der Rolle eines Projekt Coaches. Der Product Owner, das Development Team und der Scrum Master bilden ein „Scrum Team“. Das Scrum Team ist auch die Schnittstelle zu den wichtigen Stakeholdern.
Arbeitspakete und Arbeitsabschnitte werden als Sprint bezeichnet und Meetings werden als Ereignisse oder Events bezeichnet. Alle Ereignisse oder Events (Meetings) haben ein festes Zeitfenster, was nicht überschritten werden sollte.
Kanban
Kanban (Japanisch, auf deutsch Signal-Karte) beschreibt eine sehr gute Methodik zur Optimierung und Verbesserung von Arbeitsabläufen und Prozessen. Kanban kann relativ schnell und praktikabel in geeigneten Projekten zum Einsatz kommen. Kanban beschreibt 4 Grundprinzipien und 6 Kernpraktiken.
Die 4 Grundprinzipien:
1. Beginne mit der aktuellen Tätigkeit.
2. Vereinbarung einer kontinuierlichen Verbesserung und Weiterentwicklung. (KVP)
3. Laufende Prozesse, Rollen und Verantwortlichkeiten bleiben bestehen.
4. Verbesserungen (KVP) können nur umgesetzt werden, wenn sich alle Ebenen einer Organisation daran halten.
Die 6 Kernpraktiken:
1. Visualisierung der Arbeitsabläufe auf einem Kanban-Board. (Karten auf einem Whiteboard, eventuell auch Mind Map)
2. Begrenzung der Menge an angefangener Arbeit. Arbeitsabschnitte, -Pakete, werden Tickets genannt. Die Anzahl der Tickets (Work in Progress - WiP) die gleichzeitig (maximal) bearbeitet werden können, werden limitiert.
3. Den Arbeitsfluss messen und steuern.
4. Alle Regeln eines Prozessen werden definiert und dokumentiert (explizit machen).
5. Implementiere Feedback-Zyklen.
6. Verwendung von Modellen (Vereinfachung eines Prozesses) um Chancen für gemeinsame (kollaborative) Verbesserungen zu erkennen.
Die Anwendungsbereiche von Kanban eignen sich recht gut in agilen Projekten, wie z.B. IT- oder Softwareprojekten.
Six Sigma
Six Sigma beschreibt einen „kontinuierlichen Verbesserungsprozess (KVP). Die Historie geht auf den japanischen Schiffbau zurück und die Begriffe orientieren sich an japanischen Kampfsportarten. Six Sigma wurde in den 80er Jahren von Motorola in den USA entwickelt. Durch den erfolgreichen Einsatz bei GE (General Electric) erlangte Six Sigma eine große Popularität. Die am meisten eingesetzte Six-Sigma-Methode beruht auf dem „DMAIC-Zyklus“:
D = Dfine. In dieser Phase wird ein definierter Prozess bestimmt, exakt beschrieben und dokumentiert.
M = Measure. In dieser Phase wird der Prozess quantifiziert und „vermessen“. Six Sigma hat hier eine geeignete Messsystemanalyse (Measurement System Analysis, MSA) entwickelt.
A = Analyze. Dies ist die Analyse-Phase des Prozesses zur exakten Ermittlung und Dokumentation von Ursache und Wirkung.
I = Improve. In dieser Phase wird der Prozess optimiert, verbessert und in das Projekt implementiert.
C = Control. Der neue, verbesserte Prozess wird (z.B. mit statistischen Methoden) im Projekt überwacht, kontrolliert und gemessen.