- Risikoanalyse quantitativ durchführen
- Engl. 11.4 Perform Quantitative Risk Analysis
- Risikobewältigungsmaßnahmen planen
- 11.5 Plan Risk Responses
- Ausgangsleistungen vom Projektprozess Risikobewältigungsmaßnahmen planen
2. Risk-related contract decisions - Risikobezogene vertragliche Entscheidungen
3. Project management plan updates - Projektmanagementplan-Aktualisierungen
4. Project document updates - Aktualisierungen der Projektdokumente
- Diese Ausgangsleistungen werden von drei nachgelagerten Projektprozessen konsumiert:
11.2 Identify risks - Risiken identifizieren
12.1 Plan procurements - Beschaffung planen
4.2 Develop project management plan - Projektmanagementplan entwickelnProjektdokumente sind keine Leistungskonsumenten. Die Darstellung im PMBoK Seite 302 ist aus Sicht des Prozessmanagements nicht richtig.
- Eingangsleistungen vom Projektprozess Risikobewältigungsmaßnahmen planen
2. Risk management plan - Risikomanagementplan
- Der Projektprozess Risikobewältigungsmaßnahmen planen konsumiert die Leistungen von zwei vorgelagerten Projektprozessen:
11.1 Plan risk management - Risikomanagement planen
- Mögliche Methoden, Techniken, Werkzeuge sind
1. Strategien für negative Risiken -Gefahren-
2. Strategien für positive Risiken -Chancen-
3. Contingent response strategies - Risikobewältigungsstrategien
4. Expertenurteile - Fachurteile
- Risikomanagement in Projekten
- engl. Project Risk Management
Der Begriff Risiko wird in der Praxis sehr heterogen und kontextbezogen 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 ein 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
→ Mehr zu Risikomanagement in Projekten
→ Risikomanagement in Projekten Seminar
- 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 agilen 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 Ergebnis-Verantwortung wird auf zwei Rollen verteilt:
- Product Owner für Projekt- sowie Release-Ergebnisse
- Scrum Team für Sprint-Ergebnisse
Jedes einzelne Mitglied im Scrum Team trägt nicht nur für sein eigenes Tun, sondern auch für das gemeinsame Produkt Verantwortung.
In unseren Projekten hören wir zu Beginn öfters das Argument: "Unsere Projektmitarbeiter übernehmen aber nicht gerne Verantwortung und machen nur das, was der Projektmanager ihnen vorgibt."
Pech. Die Scrum Team Mitglieder haben gar keinen Chef, Signora! Sie müssen nach dem Leitbild "Selbst ist die Frau/der Mann" agieren.
Was ist mit dem Scrum Master? Er nimmt dem Scrum Team keine operative Verantwortung ab.
Die Fähigkeit zur Selbstorganisation des Projektteams ist für Scrum Projekte der kritische Erfolgsfaktor.
- Scrum Entwicklungs-Team
- Das Scrum Entwicklungs-Team als Auftragnehmer vom Product Owner verantwortet die Aufgabe, den aktuellen Sprint Backlog umzusetzen und an den Product Owner die gemeinsam mit ihm festlegten Ergebnisse zu liefern.
Hierbei organisiert es sich selbst. Anders ausgedrückt: Als soziales System stellt sich autodynamisch selbst her. Dabei schließt sich das Scrum Entwicklungs-Team während des Sprints von seinen Umwelten operational ab.
Die zentrale Operation des Scrum Entwicklungs-Teams als soziales System ist Kommunikation.
Kommuniziert wird über
- Scope -zu finden im Sprint Backlog-
- Qualität
- Zeit -Sind wir in der Time Box?-
- Kosten
- Ressourcen -Kollege braucht Unterstützung!-
- Risiken
und über Wechselwirkungen unter diesen 6.
Dies bedeutet, dass die einzelnen Scrum Entwicklungs-Team Mitglieder doch vom Projektmanagement Ahnung haben müssen. Die Frage ist: Wie viel Ahnung?
Das Scrum Entwicklungs-Team wird cross-funktional besetzt und definiert keine differenzierenden Rollen wie Entwickler, Techi, Architekt, Datenbank-Koryphäe, Designer, Prozessmanagement Schwafler.
Die eigene Organisation festzulegen, ist die Aufgabe des Scrum Entwicklungs-Teams. Die besondere Herausforderung ist die cross-cultural Kommunikation:
Mit der Unterscheidung von Umwelten und Scrum Entwicklungs-Team selbst kommt das emergente Verhalten zustande. Die Wahrnehmung der Umwelten durch das Scrum Entwicklungs-Team ist stets selektiv, z.B. wichtig | unwichtig im Zusammenhang mit dem Abarbeiten vom Sprint Backlog.
Product Owner als sein Auftraggeber und Scrum Master als sein Coach gehören zur Umwelt des Scrum Entwicklungs-Team.
Denkfehler: Teilnahme an Soft-Skill-Trainings befähigt zur Selbstorganisation.
- Scrum Master
- Die primäre Aufgabe vom Scrum Master ist das Scrum Team dabei zu begleiten, die Eigendynamik des Sprints auf das Maß der Umweltdynamik, vor allem auf die Release-Dynamik zu bringen und dafür zu sorgen, dass sich das Dynamikgefälle nicht zu Ungunsten des Sprints verschiebt.
Dafür schützt er das Scrum Team während der Iterationen (Scrumisten nennen sie Sprint) vor den aus der Projektumwelt kommenden Störungen: Er begleitet das Scrum Team bei der Abkapselung während der Sprintdauer - 2 bis 4 Wochen.
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. Er ist der Eigner vom Impedement Backlog.
Der Scrum Master ist ein Dienstleister, der das Scrum Team begleitet, ohne es wie eine Trivialmaschine 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 für Scrum Master 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".
Die Aufgaben des tradierten Projektmanagers werden in Projekten nach agilem Projektmanagement auf drei Rollen verteilt.
Für uns ist die Rolle Scrum Master die drittwichtigste Rolle unter den drei Scrum-Rollen.
- Scrum Selbstorganisation
Mit Selbstorganisation bezeichnen wir all jene nichttrivialen 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 Prioritä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 muss 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üsste 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üsste 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 Bewusstseinssystems des Menschen. Pro Tag sind ca. 60.000 Operationen, die das Bewusstseinssystem abarbeitet.)
→ Selbstorganisation und Projektmanagement
<< Anfang < Vorherige 11 12 13 14 15 16 17 18 19 20 Nächste > Ende >>