IT-Projektmanagement

Dient dazu, Erfahrungen aus dem Projekt auch außerhalb des Projekts, sowie spätere Projekte zu nutzen

Erfahrungsberichte dokumentieren und bewerten positive wie negative Erfahrungen

Erfahrungsberichte werden am Ende des Projekts im Rahmen des Projektabschlussberichts veröffentlicht (während des Projektes erfolgt die Doku über Erfahrungsprotokolle)

Es können mehrere Berichte für unterschiedliche Interessenten erstellt werden

• Alle formell zu bearbeitenden Punkte werden hier dokumentiert: z.B. Change-Requests, Abweichungen, Probleme
• jeder Offene-Punkt-Bericht enthält:
  • Beschreibung
  • Analyse möglicher Auswirklungen
  • konkrete Empfehlungen zum weiteren Umgang
• Register mit offenen Punkten wird beeinhaltet alle offenen Punkte

• Bericht informiert über den Status eines  oder mehrerer Produkte
• Scope können alle Produkte oder ein Teil eines Projekts oder ein einzelnes Produkt sein
• Folgende Informationen können sie beinhalten:
  • aktueller Status,
  • Datum von Statusänderungen,
  • Zustand des Produkts,
  • Ablageort oder Lagerort,
  • Verantwortlicher und Benutzer,
  • Liste zugehöriger Elemente,
  • offene Punkte.

Teamstatusberichte liefern dem Projektmanager Informationen über den Arbeitsfortschritt der Teams bei der Bearbeitung definierter Arbeitspakete.

• Durch den Projektmanager werden regelmäßig in definierten Abständen Projektstatusberichte angefertigt.
• Dienen dazu,  dem Lenkungsausschuss über den aktuellen Stand des Projektes, erzielten Fortschritte sowie über potenzielle Probleme im Projekt zu informieren.

• Die tatsächlich erzielten Projektergebnisse werden mit den Vorgaben aus Projektleitdokument verglichen und dokumentiert.
• Erfahrungen aus dem Projekt werden ebenfalls dokumentiert
• Informationen über noch nicht fertiggestellte Arbeiten, drohende Risiken oder mögliche Produktanpassungen werden an die Betriebsverantwortlichen weitergegeben.
• Inhalte des Projektabschlussberichts sind:
  • zusammenfassender Bericht des Projektmanagers,
  • Projektbewertung in Bezug auf den Business Case,
  • Bewertung der Zielerreichung,
  • Bewertung der Leistung des Projektteams,
  • Bewertung der Produktqualität,
  • Dokumentation der Aktivitäten zur Qualitätssicherung,
  • Dokumentation der Produktabnahmen,
  • Liste von Spezifikationsabweichungen (fehlende Produkte, Qualitätsabweichungen),
  • Bestätigung des Kunden zur Produktübernahme,
  • Empfehlungen für Folgeaktivitäten (z. B. Behandlung offener Punkte),
  • Erfahrungsbericht.

• Bericht wird nach Abschluss jeder Phase erstellt.
• Beinhaltet den Überblick über Ergebnisse dieser Phase und Auswirkungen auf den Projektstatus
• Dient dem Lenkungsausschuss als Grundlage für Entscheidung über die nächsten Projektschritte
• Lenkungsausschuss stehen verschiedene Optionen zur Verfügung:
  • Freigabe nächste Projektphase
  • Änderung des Projektumfangs
  • Änderung der Termine oder Qualität der Ergebnisse
  • Abbruch des Projekts
• Folgende Komponenten sollte ein Phasenabschlussbericht haben:
  • Zusammenfassung der Phasenergebnisse durch den Projektmanager,
  • Beurteilung der Auswirkungen auf den Business Case,
  • Bewertung, ob die bisherigen Ergebnisse der Zielsetzung des Projekts entsprechen
  • Bewertung, ob die Phasenziele erreicht wurden,
  • Bewertung der Teamleistung durch den Projektmanager
  • Bewertung der Produkte bezüglich Qualität, Abnahme, Abweichungen und Empfehlungen für nachfolgende Aktionen
  • Hinweis auf offene Punkte und Risiken
  • Prognose des Projektmanagers für den weiteren Projektverlauf.

• Name
• Kurzbeschreibung
• Voraussetzungen
• Ergebnis
• Abschlussmeilenstein

Untergliedert das Projekt in Teilaufgaben bzw. Arbeitspakete.

Siehe Skript

Checkliste für Ressorucenanforderungen (Wie viele Personen --> Anzahl, Qualifikation | Welche Sachmittel --> Räume, Materialien, ...)

Kapazitätsgebirge (strecken, verschieben)

1. Personalkosten
1.1 Entwicklung
1.2 10% Gemeinkosten

2. Sachmittelkosten (i.d.R. 5% von 1)

3. Externe DL

4. Risikozuschlag

5. Gewinnzuschlag

Risiko = Eintrittswahrscheinlichkeit x Schaden

Darstellbar auf Einflussmatrix

1. Phaseneinteilung
2. PSP
3. Ablauf- und Terminplan
4. Ressourcenplanung
5. Kostenplan
6. Risikoanalyse

„Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht." - und nicht in dem Maß, wie komplex sie
wirklich ist.

• Erreichbare Ziele setzen (individuell, Gruppe)
• Mit gutem Beispiel vorangehen (Lead by Example
• Erfolge feiern
• Regelmäßiges Feedback
• Die Projektbedeutung betonen

- Verlust von Know-How

- Unsicherheit im Team

- Verlust von Arbeitskraft (bei schwieriger Nachbesetzung)

=========================

+ neue Sichtweisen

+ Netzwerk des Kollegen

• geringe Motivation
• unterschiedliches Wissen
• Kulturunterschiede
• Infrastruktur
• hohe Flukturation der Offshorer
• Hohe Reisezeit
• Zeitverschiebung
• Qualitätsansprüche

• Vorprojekte/Prototypen durchführen
• Anforderungen konkret machen
• Anforderungen verkleinern/detaillieren
• Experten fragen
• Externe Meinungen einbeziehen
• Budgetkorridor, Min Maxwerte schätzen
• Nachschätzungen durchführen
• Möglichst spät schätzen
• Puffer einbauen
• „Politische“ Schätzungen vermeiden

• Verteilung
• Erfahrung der MA
• MA-Fluktuation
• Programmiersprache
• Unterstützung

• Software ist meist einmalig
• Softwareentwicklung wird von Rahmenbedindungen (Zeit und Budget) begrenzt

sehr klein: alle

klein: ab 3 MA, ab 0,5 Personenjahre, ab 0,05 Mio EUR

mittel: ab 10 MA, ab 5 Personenjahre, ab 0,5 Mio EUR

groß: ab 50 MA, ab 50 Personenjahre, ab 5 Mio EUR

sehr groß: ab 150 MA, ab 500 Personenjahre, ab 50 Mio EUR

Spezifisch

Messbar

Akzeptiert / Attraktiv

Realistisch

Terminiert

• Betriebsrat (kann viele Projekte kippen: Datenschutz, Arbeitsteit, Barrierefreiheit)
• Auftraggeber (finanzieller Rahmen, Abnahme)
• QM
• GF
• Lenkungsausschuss
• Key User
• PMO

Kopf mit:

• Bezeichnung des Projektes
• Einreicher
• Organisationseinheit
• Datum

1. Was muss erreicht werden?

2. Was muss getan werden?

3. Warum ist dies notwendig?

4. Zu welchem Zeitpunkt?

5. Was passiert bei Verspätung?

6. Was passiert bei Nichterreichen?

7. Welche Ressourcen sind notwendig?

8. Auffand und Kosten

9. Vorraussetzungen / Rahmenbedingungen

10. Schnittstellen / Abhängigkeiten

Baseline-Managementprodukte legen Ausgangspunkte für den Projektverlauf fest und unterliegen während des Projekts einer formalen Änderungssteuerung:

• Arbeitspaket
• Business Case
• Kommunikationsmanagementstrategie
• Konfigurationsmanagementstrategie
• Nutzenrevisionsplan
• Plan (Projekt, Phase, Team)
• Produktbeschreibung
• Produktbeschreibung des Projektendprodukts
• Projektbeschreibung
• Projektleitdokumentation
• Qualitätsmanagementstrategie
• Risikomanagementstrategie

Aufzeichnungen sind dynamisch und dokumentieren den Projektfortschritt:

• Erfahrungsprotokoll
• Konfigurationsdatensatz
• Projekttagebuch
• Qualitätsregister
• Register offener Punkte
• Risikoregister

Berichteliefen den Status bestimmter Projektaspekte:

• Ausnahmebericht
• Erfahrungsbericht
• Offener-Punkt-Bericht
• Phasenabschlussbericht
• Produktstatusauskunft
• Projektabschlussbericht
• Projektstatusbericht
• Teamstatusbericht

Projektauftrag: unklar, Anforderungen nicht spezifisch definiert

Projektkalkulation: Aufwände unzureichend geschätz

Ausgangssituation: Projekterschwernis durch Altlasten (fehlende Innovationsbereitschaft
beteiligter Teammitglieder, Verharren in überholter Technik)

Projektabgrenzung: nicht abgegrenzt

Methoden: Falsche Methodenwahl, Unzureichende Methodenkenntnis zur Projektplanung

Organisation: Fehlendes Entscheidungs bzw. Controlling Gremium, Unzureichende Delegation von Verantwortung durch die Projektleitung

Externe Partner: Probleme bei Auswahl der Kooperationspartner, Unzureichende Qualifikation der externen Unterstützter

Projektteam: Inkompetente Teammitglieder bzw. Entscheidungsträger (unzureichende Fachkompetenz), Herkunft und Sprachunterschiede der Teammitglieder, unklare Aufgabenstellungen für die Teammitglieder

Projektleitung: Kompetenzgerangel, Führungsschwäche

Fachabteilung: Fehlende Benutzerakzeptanz zu den Projektzielen, Mangelnde Information der Fachabteilung

Unternehmensleitung: Mangelnde Unterstützung der Projektarbeit, Warten auf Entscheidungen

Anforderungen: werden nicht überprüft bzw. nicht einbezogen, unzureichende Strukturierung

Kosten/Ressourcen: pauschale Kostenplanung, falsche Ressorucenplanung

Termine: nach Wunschdenken

Vorgehen: Eingreifen wenn es zu spät ist, Abweichen von Zielen, keine Priorisierung

Reviews: zu locker bzw. fehlen

Berichtswesen: unzureichend / fehlt

Zeit und Kosten fix

agil: Qualität fix und Quantität flexibel (solige Basis, spätere Sprints können nachliefern)

klassisch: Quantität fix und Qualität flexibel

Wissen über Anforderungen und Technologie auf den Axen

beides bekannt: einfach

eines bekannt und das andere so mittel: kompliziert

beides unbekannt: chaotisch

dazwischen: komplex

Kompliziert: wenn man an Handbuch schreiben kannn

Komplex: mehrer Faktoren beeinflussen das system (Auswirkung der Faktoren ebenfalls nicht bekannt)

Achsen: Autonomie und  Ausrichtung

Startup vs. Behörde

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Product-Backlog

Product Owner

Sprint-Backlog

Scrum-Master

Sprint (Störungsfrei)

Daily Scrum

Sprint Review

Sprint Retroperspektive