- Prozessneugestaltung
- Ausgangsfrage zur Prozessneugestaltung:
In welcher Prozesskategorie wird welcher Prozess neu gestaltet?
→ Unternehmensprozesse
→ Tural on Management
- Prozessoptimierung
- Ausgangsfrage zur Prozessoptimierung:
In welcher Prozesskategorie soll welcher Prozess optimiert werden?
→ Unternehmensprozesse
→ Tural on Management
- Prozessrestrukturierung
- Ausgangsfrage zur Prozessrestrukturierung:
In welcher Prozesskategorie wird welcher Prozess restrukturiert?
→ Unternehmensprozesse
→ Tural on Management
- Prozesssanierung
- Ausgangsfrage zur Prozess Sanierung:
In welcher Prozesskategorie soll welcher Prozess saniert werden?
→ Unternehmensprozesse
→ Tural on Management
- Prozessvermögen der Organisation PVO
- siehe Organizational Process Assets OPA
- Qualifizierung
- Qualifizierung ist die Einheit der Unterscheidung Lernen | Üben.
Maßnahmen zur Qualifizierung bestehen aus trivialen und komplexen Vorgängen.
→ trivialer Lernvorgang
→ komplexer Lernvorgang
- Qualität planen
Engl. 8.1 Plan Quality
Von PMI zu Scrum :
Qualität wird durch Done-Kriterien definiert. Qualitätssichernde Maßnahmen sind Teil der Sprintplanung. Maßnahmen, die nicht vom Team gemacht werden, werden nicht explizit adressiert, können aber wichtig sein.
- Qualitätsmanagement in Projekten
- engl. Project Quality Management
Qualitätsmanagement in Projekten werden in drei Prozessen gelebt, dass die angeforderte Qualität in oszillierenden Wechselwirkungen mit Kosten und Zeit erreicht wird.
Drei Prozesse des Qualitätsmanagement in Projekten
- Qualität planen
- Qualitätssicherung durchführen
- Qualitätslenkung durchführen
- Qualitätssicherung durchführen
- Engl. 8.2 Perform Quality Assurance
- Ressourcen für Vorgänge schätzen
- 6.3 Estimate Activity Resources
Von PMI zu Scrum : Aufwandschätzung wird vom Team gemacht
- Risiken identifizieren
- Engl. 11.2 Identify Risks
Eingangsgrössen vom Projekt Prozess Risiken identifizieren sind
- 1. Risk management plan
- 2. Activity cost estimates
- 3. Activity duration estimates
- 4. Scope baseline
- 5. Stakeholder register
- 6. Cost management plan
- 7. Schedule management plan
- 8. Quality management plan
- 9. Project documents
- 10. Enterprise environmental factors
- 11. Organizational process assets
Der Projekt Prozess Risiken identifizieren konsumiert sinnverarbeitend die Leistungen von folgenden vorgelagerten Projekt Prozessen:
- 11.1 Plan risk management
- 7.1 Estimate costs
- 6.4 Estimate activity duration
- 5.3 Create WBS
- 10.1 Identify stakeholder
- 8.1 Plan quality
- Linienprozesse vom Unternehmen
Die Ausgangsgrösse vom Projekt Prozess Risiken identifizieren ist das Risikoregister.
Diese Ausgangsgrössen werden sinngekoppelt von folgenden nachgelagerten Prozessen konsumiert:
- 11.3 Perform qualitative risk analysis
- 11.4 Perform quantitative risk analysis
- 11.5 Plan risk responses
- 11.6 Monitor and control risks
- 7.1 Estimate costs
- 8.1 Plan quality
- 12.1 Plan procurements
Mögliche Methoden, Techniken, Werkzeuge zur Gestaltung des Projekt Prozesses Risiken identifizieren sind
- 1. Dokumentation Reviews
- 2. Information gathering techniques – Informationssammlung Techniken
- 3. Checklisten Analysen
- 4. Assumptions analysis - Annahmenanalysen
- 5. Diagramming Techniken
- 6. SWOT Analysen
- 7. Expertenmeinungen - Fachurteile
- Risiko
- Zur Definition von Risiko in komplexem Umfeld verwenden wir die Unterscheidungen Risiko | Gefahr und Risiko | Chance.
Jenseits dieser Unterscheidung ist Schicksal.
Risiko | Gefahr
Innerhalb der Unterscheidung Risiko | Gefahr ist es ein Risiko, das Risiko zu ignorieren.
Kann man einer Gefahr vorbeugen, verkleinert man das Risiko.
Wenn man das Risiko eingeht, das Risiko nicht wahrzunehmen, macht man sich schuldig.
Risiko als Begriff der Unterscheidung Risiko | Sicherheit zu verwenden, setzt triviale Strukturen voraus und für dynamische Märkte nicht geeignet.
Beispiel:
Der Pilot eines zweisitzigen Fliegers geht Risiken ein. Der Begleiter setzt sich Gefahren aus. (Oder wähnt er sich in Sicherheit?).
- Risikoanalyse qualitativ durchführen
- Engl. 11.3 Perform Qualitative Risk Analysis
- Risikoanalyse quantitativ durchführen
- Engl. 11.4 Perform Quantitative Risk Analysis
- Risikobewältigungmaßnahmen planen
- Engl. 11.5 Plan Risk Responses
→ Magisches Hexagon
- Risikobewältigungsmaßnahmen planen
- Engl. 11.5 Plan Risk Responses
Eingangsgrössen vom Projekt Prozess Risikobewältigungsmaßnahmen planen
- 1. Risk register
- 2. Risk management plan
Der Projekt Prozess Risikobewältigungsmaßnahmen planen konsumiert die Leistungen von zwei vorgelagerten Projekt Prozessen:
- 11.2 Identify risks
- 11.1 Plan risk management
Ausgangsgrössen vom Projekt Prozess Risikobewältigungsmaßnahmen planen
- 1. Risk register updates
- 2. Risk-related contract decisions
- 3. Project management plan updates
- 4. Project document updates
Diese Ausgangsgrössen werden von drei nachgelagerten Prozessen konsumiert:
- 11.2 Identify register
- 12.1 Plan procurements
- 4.2 Develop project management plan Project documents
Mögliche Methoden, Techniken, Werkzeuge sind
- 1. Strategien für negative Risiken -Gefahren-
- 2. Strategien für positive Risiken -Chancen-
- 3. Contingent response strategies
- 4. Expertenurteile - Fachurteile
- Risikomanagement in Projekten
- engl. Project Risk Management
Der Begriff Risiko wird in der Praxis sehr heterogen und kontextbegozen festgelegt. Häufig erfolgt eine Festlegung nur anhand ursachen- und wirkungsbezogenen Bestimmungen. Diese Beschreibung setzt triviale Projektstrukturen voraus. Für Projekte, die überwiegend formalisiert geplant und gelenkt werden können, trifft dieses Risikoverständnis zu.
Für komplexe Projekte mit Überraschungseffekten aus der Projektumwelt gehen wir von externen und internen Risiken aus. Vor allem für externe Risiken definieren wir Risiken anhand der Unterscheidungen Risiko | Chance und Risiko | Gefahr.
Unser Verständnis orientiert sich am Risikomanagement im Kontext der wertorientierten Projektführung, wobei wir als Wert den Wert von Projektergebnissen verstehen.
Risikomanagement in dynamischem Umfeld ist nicht Projektmanagement für Erwachsene (wie manch einer Projektmanagement Guru denkt), sondern - unabhängig vom Alter - ein kritischer Erfolgsfaktor für alle Projektbeteiligte.
Sechs Prozesse des Risikomanagement in Projekten sind
- Risikomanagement planen
- Risiken identifizieren
- Qualitative Risikoanalyse durchführen
- Quantitative Risikoanalyse durchführen
- Risikobewältigungsmaßnahmen planen
- Risiken überwachen und steuern
Unterscheidungen für präzise Beschreibung des Risikomanagement in Projekten:
- Risiko | Chance
- Risiko | Sicherheit
- Risiko | Gefahr
- Risikomanagement | Konfliktmanagement
- Risikomanagement | Krisenmanagement
- Risikomanagement planen
- Engl. 11.1 Plan Risk Management
Von PMI zu Scrum :
Scrum adressiert Risiken, indem risikoreiche Requirements hochpriorisiert werden.
- Robert Rosen - Four Global Literacies
- Robert Rosen definierte aufgrund von Befragungen von Führungskräften aus 30 Ländern vier global Literacies.
- Personal Literacy – understanding and valuing yourself
- Social Literacy – engaging and challenging people
- Business Literacy – focusing and mobilizing your business
- Cultural Literacy – valuing and leveraging cultural difference
Aus diesen vier Literacies soll eine neue, internationale Businesssprache entstehen, die Führungskräfte erlernen müssen, so wie Kinder lesen und schreiben lernen müssen.
Robert Rosen empfiehlt, die Entwicklung der Global Literacies langfristig zu planen und den erzielten Erfolg laufend zu bewerten und zu messen.
Wer sich dem globalen Wettbewerb nicht stellt, riskiert nach Rosen, von diesem überrollt zu werden.
Literacy
Mit dem Begriff "Literacy" werden nicht nur die Fähigkeiten des Lesens und Schreibens bezeichnet, sondern auch Text- und Sinnverständnis, Erfahrungen mit der Lese- und Erzählkultur der jeweiligen Gesellschaft, Vertrautheit mit Literatur und anderen schriftbezogenen Medien (inkl. Internet) sowie Kompetenzen im Umgang mit der Schriftsprache.
Literacy wird bereits in der frühen Kindheit grundgelegt.
Buchtipp:
Rosen, R.: Global Literacies. Lessons on Business Leadership and National Cultures. New York 2000.
- Ruck
- siehe Scrum
- Scrum
- Webpräsenzen Scrum.com und Scrum.de haben mit dem Projektmanagement auf Anhieb nichts zu tun.
Oder doch? Der Gestaltungsrahmen Scrum für überschaubare IT Software-Entwicklungsprojekte könnte eher mit ruck (das angeordnete Gedränge im Rugby-Union-Sport) identifiziert werden.
Scrum - das Angeordnete Gedränge ist in verschiedenen Varianten des Rugbysports die Standardsituation, um das Spiel nach kleineren Regelverstößen, einem unerlaubten Vorwärtsspielen des Balles oder nach einem Aus (nur im Rugby League) neu zu starten. Einwurf erhält die Mannschaft, die den Regelverstoß nicht begangen hat.
Scrum soll den IT Software-Entwicklungsprojekten ermöglichen, dass ihre Eigendynamik sich kontinuierlich am Dynamikgefälle zwischen ihrer Umwelt und sich selbst orientiert.
Die Fähigkeit zur Selbstorganisation des Projektteams ist für Scrum Projekte der kritische Erfolgsfaktor. Das Projektmanagement bezieht sich dafür auf Führung ohne Steuerung.
- Scrum Master
- Die primäre Aufgabe vom Scrum Master ist die Eigendynamik des Projektes auf das Maß der Umweltdynamik zu bringen und dafür zu sorgen, dass sich das Dynamikgefälle nicht zu Ungunsten des Projektes verschiebt.
Dafür schützt er das Team während der Iterationen (Scrumisten nennen sie Sprint) vor aus der Projektumwelt kommenden Störungen.
Damit die Eigendynamik des Projektes nicht in chaotische Zustände ausufert, trägt er Sorge für die Einhaltung des Scrum Regelwerkes und räumt Hindernisse, die in täglichen Daily Scrums adressiert werden, aus dem Weg, indem er aufkommende Fragen und Probleme zeitnah klärt.
Der Scrum Master ist Projektmanager, der das Projektteam führt, ohne es zu steuern. (Uns sind Projektmanager bekannt, die diese Art der Teamführung seit vielen Jahren praktizieren, ohne dabei zu wissen, dass sie Scrum Master genannt werden können.)
Ken Schwaber hat bewusst einen anderen Namen als Projektmanager gewählt, weil es sich dabei um eine andere Verantwortlichkeit handelt. In der Praxis geht die Rollenbesetzung oft schief, weil man es lediglich dabei belässt, die Rolle des Projektmanagers "umzutaufen".
Wir bezeichnen Scrum Master » der Erkenntnisbaum des Scrum Projektes «.
- Scrum Product Backlog
- Product Backlog enthält alle Anforderungen.
Im Product Backlog dürfen alle Projekt Stakeholder Einträge vornehmen. Dies setzt voraus, dass man alle Stakeholder möglichst lückenlos identifiziert und für Berechtigungen eine Selektion vornimmt.
Der Product Backlog Owner ist jedoch der Product Owner. Er darf die Einträge priorisieren.
Wenn die Umsetzung offener Backlog Einträge weniger an Wert bringt, als die Umsetzung kostet, ist das Projekt zu Ende.
Wie im realen Unternehmensleben:
Wenn die Nutzung der knappen Ressourcen im Prozess nicht den geplanten (erhofften) Wert (als Output) generiert, dann ist auch ein Scrum Projekt nicht wertschöpfend.
- Scrum Product Owner
- Mit dem Begriff Product Owner werden Weder-Fisch-Noch-Fleisch-Rollen wie Sponsor konsequent aus der Welt geschaffen.
Tatsächlich hat jedes Projekt einen Auftraggeber zu haben, der sein Geschäft mit den Ergebnissen des Projektes besser machen will und deswegen ein Projekt in Auftrag gibt, z.B. der Owner eines Geschäftsprozesses, der seinen Prozess optimieren möchte. Dieser Auftraggeber hat also das Problem selbst an der Backe. Er vertritt nicht die Interessen von Dritten.
Unter diesem Aspekt ist die Person mit der Backe ( Product Owner in Scrum ) der Herr aller Anforderungen an das Projekt, die im Product Backlog erfasst werden. Während des Projektes ist er die letzte Instanz, um die Anforderungen zu priorisieren bzw. umzusortieren. Er darf seine Unterschrift darunter setzen. Sonst keiner.
Sein Fokus liegt dabei auf Return on Investment RoI, was eigentlich auch ohne Scrum selbstverständlich sein sollte. Denn für jedes Projekt gibt das Unternehmen bekanntlich Geld aus. Übrigens Earned Value Management basiert auf der gleichen betriebswirtschaftlichen Sichtweise.
Aus Sicht des Anforderungsmanagements betrachtet ist er gleichzeitig die Kommunikationsbrücke und der Erkenntnisknoten zwischen relevanten Stakeholder in der Projektumwelt wie Anwender in seinen Linienprozessen, Manager, Behörden und dem Projektteam.
- Formulierung und Koordination der Anforderungen aller relevanten Stakeholder
- Pflege und Priorisierung des Backlog (der Liste der Anforderungen)
- Abnahme von Sprint Ergebnissen (der Ergebnisse einzelner Iterationen)
Noch schöner kann die Welt nicht sein: Der Auftraggeber sagt nicht nur genau, was er will, sondern er verfolgt bis zum Projektende die Umsetzung seiner Anforderungen. Der Projektmanager (Scrum Master) ist der Dienstleister und steckt seine Halbwahrheiten in die Beschreibung und Aktulaisierung der Anforderungen nicht.
In der Scrum Praxis wird die Rolle in unterschiedlichen Variationen, zum Teil verwässert, gelebt. Öfters bieten sich auch externe Berater als Product Owner an.
- Scrum Selbstorganisation
- Mit Selbstorganisation bezeichnen wir all jene nichtrivialen Prozesse, die dafür sorgen, dass ein soziales System wie Scrum Team eine Ordnung bekommt und aufrechterhalten bleibt. Dazu gehört auch, dass das System auf Änderungen von innen und aussen reagieren kann, flexibel bleibt und einen neuen Gleichgewichtszustand findet. Selbstorganisation bedeutet nicht, dass sich die Teammitglieder im Scrum Team selber organisieren, sondern sie ist eine Eigenschaft des sozialen Systems Scrum Team selber.
Projektteams sind komplexe soziale Systeme, die von einem Projektleiter nicht zu 100% überblickt und gesteuert werden können. Die Selbstorganisation lebt von in der Peripherie getroffenen Entscheidungen eigenständig handelnder Teammitglieder. Alle müssen den Handlungen vertrauen können. Gunter Netzer bringt es seiner Bild-Kolumne am 04. Juli 2010 auf den Punkt:
"...
Die Spieler verstehen sich untereinander nicht nur spielerisch, sondern auch menschlich. Es gibt keine Streitigkeiten, keinen Neid. Das hat nichts mit 11-Freunde-Romantik zu tun. Gegenseitiges Vertrauen ist aber auch im heutigen Profigeschäft die Voraussetzung, um gemeinsam nach wochenlanger Vorbereitung das große Ziel zu erreichen.
..."
Das Scrum Team wird zur Selbstorganisation fähig, indem es in jedem Sprint auf Basis von aktuellen Priotitäten im Product Backlog den Inhalt und Umfang ( Scope ) eines Increment of Potentially Shippable Functionality selbst modifiziert. Reviews und Retrospektiven nach jedem Sprint dienen zu diesem Zweck.
Die Voraussetzung für die Selbstorganisation ist, dass keine Steuerung von außen erfolgt. Das Scrum Team muß seine Entscheidungen eigenständig treffen.
Scrum Master darf keine steuernden Anweisungen geben.
Die Selbstorganisation ist auch mit PMI® Gestaltungsrahmen möglich. Projektmanager und Projektteam nach PMI® müssen gemeinsam die Selbstorganisation verstehen und für das jeweilige Projekt definieren. Die Enterprise Environmental Factors EEF können externe Referenzen verkörpern, die für die Selbstorganisation des Projektteams wie Luft und Wasser nötig sind.
Im Idealfall müßte der Auftraggeber im Project Charter als Product Owner fungieren.
→ Denkfehler
- Selbstorganisation kann in systemischen Soft Skill Seminaren gelernt werden: wenn alle über emotionale Intelligenz verfügen, dann müßte man nur noch Selektion der Information, Selektion der Mitteilung und Selektion der Annahme / des Verstehens in Griff bekommen.
- Agile Projekte lassen sich mit System Dynamics simulieren: viel Spaß beim Loops Hopping!
- Soft Facts und Management Entscheidungen lassen sich ebenfalls mit System Dynamics gut modellieren. Die Grundvoraussetzung dafür wäre, dass der Manager all seine Gedanken ohne Zeitverluste offen legt. (Die Gedanken sind Operationen des Bewußtseinsystem des Menschen. Pro Tag sind ca. 60.000 Operationen, die das Bewußtsseinssystem abarbeitet.)