Projektmanagement

•   Potentielle Einflussmöglichkeiten („Macht“) der Stakeholder im Hinblick auf die Projektziele untersuchen
•   Einstellung der Stakeholder im Hinblick auf die Projektziele untersuchen
•   Außerdem
  • Stärken- und Schwächenprofil der Stakeholder erstellen
  • Einfluss und Einstellung der Stakeholder auf die Projektziele dokumentieren

•   Strategie der Stakeholder abschätzen
•   Wie werden die Stakeholder handeln?

Möglichkeit der Beeinflussung und Steuerung des Stakeholders untersuchen

•   Unmittelbarer Einfluss auf Stakeholder möglich
•   Nur mittelbarer Einfluss möglich
•   kaum Einflussmöglichkeit auf Stakeholder

Im nächsten Schritt sind konkrete Maßnahmen zu planen

•   Die grundsätzlichen Optionen, dargestellt als Portfolio:

•   Partizipative Strategien
  • Stakeholder zu Partnern in der Projektarbeit zu machen
  • Informationsveranstaltungen, Tag der offenen Tür, etc.
•   Diskursive Strategien
  • Sachliche Auseinandersetzung
  • Konflikt offen legen, Ausgleich gewähren
•   Repressive Strategien
  • Beeinflussung und Steuerung des Umfeldes über vorgesetzte Dienststellen, Geschäftsleitung und sonstige Akteure mit direktem Einfluss auf relevante Stakeholder verstanden
  • Selektive Information vom Projekt an die Stakeholder, scheinbare Beteiligung, etc.

•   Welcher Stakeholder wird
•   durch welche Kommunikationsmaßnahme
•   mit welchem Inhalt
•   und welcher Frequenz
•   in welchem Umfang und
•   in welcher Art informiert?
•   Wer ist der/die Verantwortliche/r dafür im Projekt?

•   Stakeholder mit Konfliktpotential müssen im Risikomanagement berücksichtigt werden.
•   Stakeholdermanagement ist ein iterativer Prozess
•   Die Ergebnisse der Stakeholderanalyse sind regelmäßig zu prüfen und zu aktualisieren

•   Ein Ziel ist ein angestrebter zukünftiger Zustand
•   Definition (DIN 69901-5:2009):
  • Projektziel ist die "Gesamtheit von Einzelzielen, die durch das Projekt erreicht werden sollen, bezogen auf Projektgegenstand und Projektablauf.“
  • Zieldefinition: „quantitative und qualitative Festlegung des Projektinhaltes und der einzuhaltenden Realisierungsbedingungen, z.B. Kosten und Dauer, in Zielmerkmalen mit meist unterschiedlichen Zielgewichten (z.B. Muss- und Kann-Ziele).“

•   Entscheidung/Selektion
  • Prüfung von Alternativen,
  • Abwägen von Entscheidungen im Projektverlauf
•   Kontrolle
  • Vergleich Soll/Ist. Ist das Projekt (ganz/teilweise) erfolgreich? Abweichungen lassen sich erkennen.
•   Motivation/Verbindung
  • Mitarbeitermotivation durch Einbindung in Zielformulierung und laufende Information zum Gesamtstatus: „Wir“-Gefühl
•   Koordination
  • Ausrichtung der Aktivitäten der einzelnen Projektmitglieder. Zielprioritäten erleichtern die Koordination der einzelnen Projekttätigkeiten
•   Information
  • Kenntnis über zukünftige Aktivitäten
•   Legitimation
  • Daseinsberechtigung des Projekts

•   Eisernes Dreieck
•   SMART-Kriterien
•   Messbare Ziele
•   Ziele und Nicht-Ziele
•   Ergebnis- und Vorgehensziele
•   Priorisierung von Zielen
•   Beziehungen zwischen Zielen

Ziele müssen quantitativ messbar sein, damit am Ende des Projektes eine objektive Prüfung stattfinden kann, ob das Ziel „erfolgreich“ erreicht wurde.Vorgehen:

•   Relevante Zielgrößen ermitteln und festlegen
•   Zahlen oder zumindest Größenordnungen, Zahlenintervalle, Minimal- oder Maximalziele hierfür vereinbaren
•   Sog. Abnahme- bzw. Akzeptanzkriterien formulieren

•   Projektlenkungsausschuss
  • (auch: Lenkungssauschuss) Lenkungsgremium, welches die wesentlichen Entscheidungen für ein Projekt trifft
  • Umsetzen von Entscheidungen der Unternehmensführung
  • Projektziele definieren oder genehmigen
•   Projektleiter/in bzw. Projektmanager/in
  • Führt das Team und ist für die reibungslose Durchführung des Projekts zuständig
  • Ergebnisverantwortung für Projekt
  • Vergabe der Aufgaben und Weisungsbefugnis innerhalb des Projekts
•   Teilprojektleiter/in, Arbeitspaketverantwortliche/r
  • Zuständig für ein Teilprojekt oder Arbeitspaket
  • Führung der Mitarbeiter im Teilprojekt/Arbeitspaket
•   Projektteam / Projektkernteam bzw. Projektteammitglied
  • Übernimmt dauerhaft oder temporär die unterschiedlichen Rollen und Aufgaben im Projekt
  • Eigenverantwortliche, fristgerechte Durchführung vereinbarter Arbeiten mit den vereinbarten Mitteln

•   Steuerungsgremium (auch: Steering Commitee)
  • Trifft im Bezug auf Projekte die strategischen Entscheidungen
•   Project Management Office (PMO)
  • Zentrale Anlaufstelle für das Projektmanagement im Unternehmen
•   Projektauftraggeber/in
  • Erteilt den Projektauftrag
  • Nimmt Projektergebnisse ab
•   Fachausschüsse
  • Vertreten Interessen von Kunden, Anwendern, Fachabteilung o.ä.
•   Projektcontroller/in
  • Projektübergreifende und projektbezogene Überprüfung der Aufgabenstellung und Zielsetzung
•   Projektsekretär/in
  • Zuständig für Dokumentenablage
  • Organisation des Tagesgeschäfts

R esponsible (verantwortlich):Verantwortlich dafür, dass die Aufgabe umgesetzt wird

A ccountable (zuständig):Verantwortlich im kaufmännischen und juristischen Sinn (Auftraggeber)

C onsulted (PMI: Consult) (beraten):Derjenige, der zur Umsetzung der Aufgabe herangezogen werden kann (bidirektionale Kommunikation)

I nformed (PMI: Inform) (informieren):Wird über das Ergebnis/den Fortschritt informiert (unidirektionale Kommunikation)

•   Projektrisiko nach DIN 62198:2014-8 (Risikomanagement für Projekte - Anwendungsleitfaden (auch: IEC 62198:2013)): Kombination aus der Eintrittswahrscheinlichkeit eines bestimmten Ereignisses und seinen Folgen für die Projektziele.
•   Als Risiken werden hier mögliche Ereignisse und Situationen bezeichnet, die für ein Projekt gegenüber der Planung nachteilige Folgen haben.
•   Risiko ist ein Problem, das erst noch auftreten muss
•   Problem ist ein Risiko, welches aufgetreten ist

•   Definieren und Ausrichten
  • Was sind die generellen Ziele des Risikomanagements?
  • Welche Vorgaben existieren für das Risikomanagement?
•   Risiken identifizieren
  • Welche Risiken könnte es geben?
•   Risiken bewerten, priorisieren, analysieren
  • Wie signifikant sind die Risiken? Wie häufig sind sie?
  • Welche Auswirkungen haben sie?
  • Welches sind die wichtigsten Risiken?
•   Maßnahmen planen
  • Was können wir tun?
  • Was wollen wir tun?
  • Wie bewältige ich ein Risiko?
•   Risiken behandeln
  • Maßnahmen durchführen
•   Risiken verfolgen und kontrollieren
  • Wie erfolgreich sind wir?
  • Wie verändern sich unsere Risiken?

•   Datum des Eintrags
•   Identifizierer / Name des Risikos
•   Beschreibung des Risikos
•   Auslösendes Ereignis des Risikos
•   Risikokategorie (kaufm, Umwelt …)
•   Ursache(n) des Risikos
•   Frühwarnindikatoren
•   Wirkungszusammenhänge verschiedener Ereignisse („negative Synergien“)
•   mögliche Tragweite in Bezug auf Kosten, Termine, Ergebnisqualitäten etc.

Den Maßstab der Priorisierung ergibt sich aus dem Produkt von Ausmaß und Eintrittswahrscheinlichkeit die RisikokennzahlRisikokennzahl = Ausmaß x Eintrittswahrscheinlichkeit

•   Festlegen der weiteren Bearbeitung im RM auf der Grundlage der Risikokennzahl und Abgrenzung von Klassen:
•   Klasse 1: <= 3 zu vernachlässigen
•   Klasse 2: 4 - 6 niedrig
•   Klasse 3: 8 -12 mittel
•   Klasse 4: 15 -16 groß
•   Klasse 5: 20 -25 bestandsgefährdend

•   1. Schadensverhindernde (präventive, vorbeugende) Maßnahmen mit dem Sinn, Risiken nicht passiv abzuwarten, sondern ihnen rechtzeitig und gezielt entgegenzutreten
  • Vermeidung / Prävention („Risk Mitigation Plans“)
  • Evaluierung, Prototypen, Zukauf von Leistungen etc.
•   2. Schadensmindernde (korrektive) Maßnahmen mit dem Sinn, eingetretene Risiken in ihrer Auswirkung schnellstmöglich zu begrenzen, z.B. durch
  • Notfallpläne/Eventualfallpläne („Contingency Plans“)
  • Katastrophenpläne
•   Die möglichen Maßnahmen sind festzuschreiben, zu kalkulieren, auszuwählen und Verantwortlichen zuzuordnen. Die Risiko- und Maßnahmenplanung ist auch Gegenstand des Projektcontrollings.

•   Ziel:
  • Beginne im Kleinen
  • Halte die Spirale so eng wie möglich
  • Erreiche so die Entwicklungsziele mit minimalen Kosten
•   Bei der Zielbestimmung werden auch Qualitätsziele bestimmt
•   Sog. risikogetriebenes Modell
  • Risikoanalyse ist Bestandteil jedes Phasendurchlaufs
•   Für jede Aktivität und jeden Ressourcenverbrauch wird gefragt
  • "Wie viel ist genug?"
  • Dadurch wird ein „Overengineering“ vermieden.
  • Entwicklung in kleinen Schritten
•   Neuerung: Phasen werden mehrfach durchlaufen
•   Das Spiral-Modell ist ein sog. iterativ-inkrementelles Modell:
  • Jede Spirale stellt einen iterativen Zyklus durch dieselben Schritte dar
  • Phasen werden mehrfach durchlaufen (= Iterativ)
  • Lösung wird stückweise entwickelt und ggf. ausgeliefert (= Inkrementell)
•   nicht-lineares Vorgehensmodell

•   Weiterentwicklung des Phasenmodells speziell für die Softwareentwicklung.
•   Streng sequenzielles Vorgehen
  • Jede Phase muss beendet sein, bevor die nächste anfängt
  • Phasen werden 1x durchlaufen
  • Phasenbezeichnungen variieren
•   Jede Phase wird beendet mit einem Meilenstein, auf dem die folgende Phase aufbaut
  • Bündelung von Aktivitäten der Entwicklung in der „richtigen“ Reihenfolge
  • Jeweils fertige Ergebnisse, z.B. Entwurfe, System
•   Rückkopplungen möglich, jedoch nur zwischen benachbarten Phasen
•   Grundlegende Philosophie: Aufteilung gemäß Entwicklungstätigkeiten
  • Analyse, Architekturentwurf, Implementierung, Betrieb
•   Dokumentgetriebenes Modell
  • Zuerst werden Dokumente erzeugt
  • Konkretes Ergebnis (z. Beispiel lauffähige Software oder funktionierendes Produkt) wird erst sehr spät erstellt
•   Problem: Tests finden erst am Ende des Prozesses statt

Risiken:

•   Benutzerbeteiligung nur in den ersten Phasen
•   In den frühen Phasen Dokumentation wichtiger als lauffähiges System („dokumentengetriebenes Modell“)
•   Lauffähige Ergebnisse (Produkte) erst am Ende / sehr spät
•   Mangelnde Flexibilität
•   Kontrolle des Projektfortschritts schwierig
•   Umplanung aufwändig
•   Test finden (zeitlich) sehr spät statt („Testberg“)

•   Gut verständlich
•   Einfache Projektorganisation
•   Vorlage für viele Organisationen
•   Gut geeignet für risikoarme Vorgehen, z.B. Ausschreibungs- und Vergabeverfahren
•   Formal einfache Fortschrittskontrolle
•   Geringer Managementaufwand

Risiken:

•   Höherer Managementaufwand
•   Schwierig, richtige Größe von Iterationen zu finden
•   Juristisch schwierig, da kein festgelegter Lieferumfang
•   Keine festgelegte Projektdauer
•   Keine Aussage über Gesamtaufwand

•   Flexibles Modell
•   Risikominimierung durch kontinuierliche Evaluierung
•   Umplanung relativ einfach
•   Entwicklung kann wesentlich leichter umdirigiert werden, wenn die Erkenntnisse dies erfordern
•   Frühzeitig lauffähige Systeme / Ergebnisse oder frühe Erstellung von Prototypen
•   Fehler und ungeeignete Alternativen werden frühzeitig eliminiert
•   Projekt kann nach jeder Iteration beendet werden

•   „Spielzug“
•   Projekte schreiten in Serien von „Sprints“ voran
•   Zu erstellende Feature werden definiert durch ein Sprintziel; festgelegt vom Product Owner
•   Feature sind als Listeneinträge im Produkt Backlog festgehalten
•   Führt zu einem Ergebnis:
  • „potentially shippable product increment“: Potentiell auslieferbare Produkterweiterung
•   Nur so viele Features, wie das Team an Kapazität hat
•   Fester Zeitrahmen:
  • Maximal 30 Kalendertage, heute häufig zwei Wochen, auch schon mal eine Woche
  • Konstante Dauer
•   Kein spezifisches Entwicklungsvorgehen, Methoden, Techniken vorgeschrieben
•   Das Produkt wird während des Sprints entworfen, kodiert und getestet
  • Keine Phasen im Sprint
•   Plane Sprintdauer abhängig davon, wie lange Veränderungen vom Sprint ferngehalten werden können

•   In etwa Produkt-Manager, Produkt-Verantwortlicher
•   Ist verantwortlich für das finanzielle Ergebnis des Projekts (ROI)
•   Hat die Produkt-Vision
•   Entscheidet, was geliefert werden soll
•   Definiert Produkt-Features (=Anforderungen)
  • Konsolidiert die Anforderungen der Stakeholder
•   Priorisiert Einträge im Product Backlog
  • abhängig von ihrem Wert für Kunden etc.
•   Ernannt vom Management
•   Entscheidet über Release-Daten und den Umfang des Produkts
•   Passt Features und Prioritäten vor jeden Sprint an
•   Akzeptiert Ergebnisse oder weist sie zurück
•   verteilt keine Aufgaben im Team

•   Liefert die am höchsten priorisierten Features, wie vom Product Owner festgelegt. Deshalb auch als Feature Team bezeichnet.
•   Das Team entscheidet, wie viel geliefert werden kann
•   Organisiert sich selbst
  • Manager weist keine Arbeiten zu
  • Manager entscheidet nicht für das Team
  • Für das Lösen von Konflikten selbst verantwortlich
•   Größe nicht festgelegt: typische Größe 5-9 Personen
•   Keine festgelegten Rollen im Team
•   Kein Multitasking in mehreren Projekten
•   Alle notwendigen Kenntnisse sollten im Team verfügbar sein: Entwickler, Business Analytiker, Tester etc.
•   Eingespielt: Bleibt idealerweise über längere Zeit zusammen
•   Zugehörigkeit nicht im Sprint wechseln

•   Verantwortlich für die Einhaltung der Scrum-Werte und -Praktiken
  • führt Scrum ein
•   Beseitigt Hindernisse: „Aus-dem-Weg-Räumer”
  • schützt das Team vor äußeren Störungen
  • stellt sicher, dass das Team produktiv ist
•   Unterstützt die Zusammenarbeit zwischen allen Rollen und Scrum Team-Mitgliedern
•   Kein Projektmanager!
  • keine Weisungsbefugnis
•   Übernimmt Verwaltungsaufgaben
•   Wird vom Team ernannt;
  • ggf. wird ein Scrum Master vorgeschlagen, der vom Team akzeptiert werden muss

•   Eigentum und gepflegt vom Product Owner
•   Enthält u.a. Anforderungen in Form von sog. Features
  • Eigentlich „product backlog items“ PBI oder dt. PBE
  • Werden oft in Form von sog. „User Stories“ formuliert
•   Anforderungen können von allen Product Backlog Stakeholdern kommen
•   Jederzeit änder- und erweiterbar:
  • Kann immer geändert werden, wenn sich Anforderungen ändern
•   Erfordert Input vom Team
  • Das Entwicklungsteam schätzt die relative Größe der Features
  • Team unterstützt beim Priorisieren und Formulieren von PBE
•   kein Vertrag zwischen Product Owner und Team
•   keine Liste mit Aufgaben, die notwendig sind, um die Anforderungen zu erfüllen
•   kein Projektstrukturplan
•   kein Lösungskonzept

•   Eigentum des Entwicklungsteams
•   Gepflegt vom Entwicklungsteam
•   Enthält alle Aufgaben, um das Sprint-Ziel zu erreichen
•   Zu den Einträgen aus dem Product Backlog, die das Team im Sprint realisiert, werden die Tasks formuliert
•   Lebendes Dokument; verändert sich während des Sprints, weil u.U. neue Tasks hinzukommen
•   Die Aufgaben sollten klein sein (Idealerweise an einem Tag abzuschließen)
•   Täglich wird der geschätzte Restaufwand für die Tasks in Stunden eingetragen
•   Sprint Backlog ist keine Zeiterfassung!

•   Analyse der Trends bei den noch zu erreichenden Meilensteinen
•   Effektive Methode zur Überwachung des Projektfortschritts
•   Zu jedem Berichtszeitpunkt wird bei den AP-Verantwortlichen der
•   voraussichtliche Termin für das Erreichen der zukünftigen Meilensteine abgefragt
•   Erfordert geringen Aufwand
•   Basis:
  • aussagekräftige Meilensteine
  • regelmäßige Berichtszeitpunkte
•   Keine zusätzlichen Anforderungen z.B. an die Kostenrechnung
•   Darstellung:
  • X-Achse: Zeitachse mit den Terminen der Berichtszeitpunkte
  • Y-Achse: Zeitachse mit den geplanten Meilenstein-Terminen
•   Wird als eines der wichtigsten Instrumente des PM bezeichnet

•   Keine Terminverschiebungen: Termin kann gehalten werden

•   Erhebliche Unsicherheit bei den Terminaussagen:
•   Der Gesamttermin ist damit ebenfalls äußerst unsicher, da Prognose sich ständig ändert

•   Zu optimistische Planaussagen gemacht:
•   Erheblicher Terminverzug.

•   Gegen Ende werden schlagartig Terminverschiebungen angekündigt:
•   Es mangelt an frühzeitigen realistischen Terminaussagen. Terminverzögerungen wurden möglicherweise verschwiegen.

•   Eine der Tendenzen ist unrealistisch.
•   Abhängigkeiten prüfen und Prognosen hinterfragen.