Please enable JavaScript.

Coggle requires JavaScript to display documents.

Projektmanagement - Coggle Diagram

- - - - Idelatyp, Phasen nachheinander abgearbeitet
    - - Häufigste, manche Tätigkeiten finden parallel statt
      - teilweise auch bewusste Überlappungen zum Gedankenaustausch
    - - kontinuierliche Abstimmungen zwischen allen Beteiligten
      - insb. bei komplexen Softwareprojekten
    - - wenn Änderungen eher Regel aus Ausnahme sind
      - Weiterentwicklung der Inkrementalen
  - - - Einflussprojektorganisation
        
        gibt Aufgaben an Linienvorgesetzte, die geben es weiter
        
        koordinierrt Projekt, hat aber wenig Einfluss und Verantwortung
        
        Projektleitung als Stabstelle, GL untergeordnet
      - reine Projektorganisation
        
        bei komplexen Projekten
        
        Projektleiter und Mitarbeiter kümmern sich ausschließlich um Projekt
        
        volle Konzentration auf Projekt, wie eine eigene Abteilung
      - Matrixprojektorganisation
        
        Mitarbeiter sind Projektleiter und Linienvorgesetzten unterstellt
        
        erfordert gegenseitiges Verständnis, Respekt und klare Regelungen
    - - Auftraggeber
        
        erteilt Projektauftrag mit Beschreibung, Ziel, Namen der Beteiligten, Mittel, Termine...
        
        meist GF oder Gremium
      - Auftragnehmer
        
        z.B. Unternehmen, das Projekt umsetzt
      - Projektgremien
        
        Planungsgremien (planen Projekt)
        
        Beratungsgremien (gewährleisten Kommunikatiosnfluss zwischen Fachbereichen)
        
        Steuerungsgremien (nicht nur beratend, sondern auch steuernd tätig)
        
        Entscheidungsgremien (unterstützen Projektleiter)
        
        Aufgaben, Regeln, Mitglieder etc. der Gremien sollten schriftlich fixiert werden
      - Anwender
        
        Kunde
      - Projektleiter
        
        verantwortlich für Realisierung
        
        baut Projektteam auf
        
        delegiert Aufgaben
        
        informiert Entscheider
        
        kontrolliert Fortschritt
        
        erstellt Projektplan
      - Projektmitarbeiter
        
        erledigen Projektaufgaben
        
        verantworten Arbeitspakete
        
        informieren, holen Infos ein
        
        Teamentwicklungsuhr
        
        Orientierungsphase
        
        Kampfphase
        
        Organisationsphase
        
        Arbeitsphase
      - bei Scrum Projekten
        
        Product Owner
        
        vertritt Kundeninteressen
        
        brieft Projektteam
        
        fasst Anforderungen im Product Backlog zusammen
        
        Scrum Master
        
        agiert als Coach und Experte
        
        kennt sich mit Scrum-Projekten aus
        
        Development Team
        
        setzen Kundenanforderungen um
        
        holen sich Aufgaben aus Taskboard
        
        idealerweise 3-8 Personen
    - - hier laufen Infos zusammen
      - Rückzugs- und Dokumentationsort
      - eher bei Riesenprojekten, sonst Konferenzen
- - - - Plan-Ist-Vergleich mit Terminplan
      - Terminrückmeldungen in Meetings, Formulare
      - Verschiebungen im Terminplan und Netzplan aktualisieren
      - Termintrendanalyse bei langjährigen Projekten (Plan-Plan-Vergleich - hier werden Plantermine regelmäßig angepasst)
      - bei Scrum-Projekten Timeboxing - reicht Zeit nicht aus, wird Umfang in Abstimmung mit Kunden reduziert
    - - Stundenaufschreibungen
      - Aufwände pro MA und Arbeitspaket erfasst
      - Trennung interne und externe Kosten
      - Plan-Ist-Analysen
      - Kostentrendanalysen bei komlexen langjährigen Projekten
      - bei Scrum-Projekten: Team Velocity (Schätzung Arbeitsaufwand für user Story, wird von Sprint zu Spring genauer)
    - - Qualitätskontrolle (Anforderungen erfüllt, aber auch ob z.B: Prozesse gut liefen)
      - Fortschrifttskontrolle (Betrachtung aller drei Faktoren des magischen Dreiecks gleichzeitig)
      - bei Scrum-Projekten Definition of Done (Mindestanforderungen erfüllt), Review (Kunde zufrieden) und Retrospektive (Prozesse gut?)
    - - Fakten über den Arbeitsfortschritt
      - Risikofelder aus der Projektumgebung (z.B. Personalsituation, Motivation etc.)
      - Daten aus Abfragen, Trendanalysen, Beobachtungen und Besprechungen
- - - - Projektleiter spezifiert sie und fixiert sie im Anforderungskatalog
      - im klasscischen PM: Enziel
      - leiten sich aus übergeordneten Zielen ab, kommen meist von GF
    - - beschreibt auf Grundlage des Anforderungskataloges Erwarten, Aufgaben und Pflichten
      - enthält Anforderungen, Ziele, Termine, groben Rahmen
    - - Arbeitspakete definieren und hierarchische Struktur erstellen
      - Zuordnung von Verantwortlichen
      - Arbeitspakete sollten max. 1 Monat dauern und von so wenigen Personen wie möglich bearbeitet werden
      - Verknüpfungen darstellen
      - gibt Projekt Struktur, hilft bei Kontrolle, Berichterstattung und Dokumentation, gibt Rahmen vor
    - - Ableitung von genauen Aufgaben aus Arbeitspaketen
      - Was ist zu tun? Wer macht es? Welcher Aufwand? Wie viele Mitarbeiter?
      - Netzplantechnik empfohlen
        
        sagt aus, welche Vorgänge aufeinander aufbauen wie diese einander zugeordnet sind
        
        Aufgaben auflisten, Vorgänger und Nachfolger bestimmen
        
        Dauer eintragen
        
        frühesten Beginn und frühestes Ende für Ereignisse ermitteln
        
        spätesten Beginn und spätestes Ende für Ereignisse ermitteln
        
        Abhängigkeiten und Pufferzeiten berücksichtigen
    - - Aufgaben werden in zeitliche Reihenfolge gebracht
      - Festlegung Beginn- und Endtermine, Meilensteine
      - Festlegung kritischer Pfad (welche Termine a.j.F. einzuhalten, damit sich Projekt nicht verzögert)
    - - entweder auf Basis von Erfahrungswerrten und Expertenschätzung
      - Kostenartenplan erstellen
      - alles genau zuordnen, interne und externe Kosten trennen
    - - Ermittlung der verfügbaren Personalkapazität
        (Wer kommt in Frage? Wie viel Zeit stehen diese zur Verfügung?)
      - Berechnung des Personalbedarfs
        (auf Basis des Aufgabenplans)
      - Vergleich von Personalkapazität mit Personalbedarf
        (realisierbar?)
      - Optimierung der Personalauslastung
        (z.B. Mitarbeiter unkritischer Arpeitspakete helfen woanders aus)
    - - Sicherstellung, dass z.B. immer genug Arbeitsmaterial verfügbar ist (Projektleiter kümmert sich)
    - - aus Zielen ableiten, wann Projekt erfolgreich ist (z.B. Kennzahlen, bestimmte Eigenschaften)
      - im Qualitätsplan dokumentieren
      - wichtig für Abnahme am Ende des Projektes
    - - vorab Checkliste erstellen
        
        Wirtschaftliche Risiken (z.B. zu hohe Kosten, Vetragsleistungen werden nicht gehalten, Insolvenz des App-Anbieters)
        
        Politische Risiken (z.B. App wird im tagungsland blockiert, Verstoß gegen Datenschutzrichtlinien bei TN-Daten)
        
        Risikofaktor „Mensch“ (z.B. Fehlendes Fachwissen, fehlende Erfahrung, PL überfordert)
        
        Technische Risiken (z.B. App funktioniert nicht auf allen Geräten, WLAN vorort klappt nicht, nicht ausreichend Testgeräte=
      - Risikoanalyse
        
        Aufgabe
        (z.B. funktionieriende App erstellen)
        
        Risiko
        (z.B. funktioniert nicht auf allen Geräten)
        
        Risikograd (1-10)
        (z.B. 8)
        
        Ursache
        (Geräte und Betriebssysteme der TN zu alt)
        
        Auswirkungen auf
        (TN können App nicht nutzen und sind verärgert)
        
        Maßnahmen
        (wichtigste Geräte ermitteln und durch Tests sicherstellen, dass es dort klappt)
    - - hier verwaltet PL alle Ulas zum Projekt
      - Verträge, Pläne, Berichte, Kosten...
  - - - verwandte User Stories in Epic zusammengefasst und in Prodct Backlog als Anforderungen gesammelt und priorisiert
      - Anforderungen werden als Use Case formuliert und in User Story spezifisiert
      - für jede User Story gibt es Definition of Done (d.h. was gehört zur vollständigen Umsetzung)
    - - Sprint-Planung
      - Sprint-Durchführung
      - Sprint-Review (Einbeziehen des Kunden)
      - Sprint-Retrospektive (Beleuchten der Prozesse)
      - Inkrement (freigegebenes Teilergebnis)
      - bei Scrum = Sprint, ansonsten Iteration
    - - wird am Anfang nur grob bestimmt
      - wird in Sprint-Planung für jeden Sprint definiert (Teilziele)
    - - Unser Stories werden in Taskboard für jeweiligen Sprint übertragen (1. Spalte)
      - werden dann in Aufgaben heruntergebrochen
        (2. Spalte)
      - Teammitglieder greifen sich Aufgaben und packen Sie in Spalte "in Arbeit" (3. Spalte)
      - erledigte Aufgaben in Spalte erledigt (4. Spalte)
    - - Sprints haben immer die gleiche zeitliche Länge (1 Woche bis 60 Tage),
      - werden zu Beginn des Projektes je nach Gesamtdauer des Projektes, Teamgröße und Komplexität festgelegt
    - - Development Team wird zu Beginn des Projektes festgelegt
      - bleibt in der Regel unverändert über die gesamte Projektdauer
    - - stehen am Anfang fest
    - - muss auch hier sichergestellt werden, Team kümmert sich
    - - Für jede User Story, die innerhalb eines Sprints bearbeitet wird, wird Definition of Done festgelegt
      - wenn erfüllt, Freigabe
    - - erfolgt durch Gewichtung im Produkt Backlog