Project Management Basics

1. Einführung und Überblick (Thematik und Zielsetzung)
2. qualitative Begründung
   1. Nutzenargumentation in Prosa; Umfang und Abgrenzung
   2. Optional: Risiko- und Sensivitätsanalyse
3. quantitative Begründung
   1. Annahmen und Methoden (wichtigste Annahmen, Finanzkennzahlen, Kostenmodell)
   2. betriebswirtschaftliche Auswirkungen (Cash-Flow-Berechnung, Ergebnisanalyse)
4. Fazit und Zusammenfassung

• Methode zur Wertbestimmung einer Investition, die heute getätigt wird
• Heutiger Wert des investierten Kapitals allen Ausgaben und Erträgen (Cash Flow) gegenüberstellen (Zinsen berücksichtigen!)
• zukünftige Cash Flows werden auf den heutigen Wert zurückgerechnet (abgezinst), woraus sich der Barwert oder Net Present Value (NPV) ergibt
• als Zienssatz dient die unternehmensinterne Mindestrendite
• abgezinste Erträge > abgezinste Zahlungen: Investitionen lohnt sich
• abgezinste Erträge < abgezinste Zahlungen: Investitionen lohnt sich nicht

• Investitionen
  • heute: CHF 100.-
  • in einem Jahr: noch einmal CHF 100.-
• Ertrag
  • in zwei Jahren: CHF 105.-
  • in drei Jahren: noch einmal CHF 110.-
• Kostenseite
  • heute fällig: CHF 100.-
  • in einem Jahr fällig: heute CHF 96.15 zu 4% anlegen, um in einem Jahr CHF 100.- zu haben
  • Kosten insgesamt: CHF 196.15
• Einnahmeseite
  • CHF 105.- in einem Jahr sind heute bei 4% Zins CHF 97.08 wert
  • CHF 110.- in drei Jahren sind heute bei 4% Zins CHF 97.79 wert
  • Einnahmen insgesamt: 194.87

Das Geschäft lohnt sich nicht!

\(CashFlow=NetPresentValue*(1+i)^n\\NetPresentValue=\frac{CashFlow}{(1+i)^n}\)

• Klare resultatorientierte Gliederung der bevorstehenden Gesamtaufgabe in einzelnen plan- und kontrollierbare Teilaufgaben bzw. Arbeitspacketen

• klassich:

  • Arbeitspakete als kleinste Planungseinheit

• hybrid:

  • ProductBacklog als priorisierte Liste aller Epics

  • Detailplanung erfolgt rollend im SprintBacklog

• Verschafft einen Überblick über die Bestandteile des zu schaffenden Objekts.

• Die Arbeitspakete werden aus den Resultaten abgeleitet

1. Mapping der Anforderungen auf die Resultate
   1. pro Paarung kann in der Regel ein Arbeitspaket gebildet werden
2.  Benennung und Beschreibung der Arbeitspakete (Name und Kurzbeschreibung)
3. Schätzung des Aufwandes
   1. Aufwand in Personentagen oder -Wochen
4. Vorläufer (Nachläufer)
   1. Feststellung der logischen Abhängigkeiten der Arbeitspakete

1. Nettoaufwand schätzen pro Arbeitspacket. (mittels Schätzmethode, ohne Berücksichtigung von potentiellen Einflüssen)

2. Bruttoauwand schätzen pro Arbeitspacket. (mögliche Einflussgrössen und Risiken definieren, Miteinbezug in die Aufwandschätzung)

3. Gesamtaufwand des Projektes schätzen

• Die Personen die das Projekt durchführen, sollen auch die Schätzung vornehmen

• Tasks möglichst weit herunterbrechen mittels Arbeitspaketen

• Bei grösserer Unsicherheit besten und schlechtesten Wert schätzen und Mittelwert in die Planung übernehmen

  • Alternativ kann auch eine Reserve von ca. 10% - 20% zur Schätzung addiert werden

• Während dem Projekt aktuelle Resultate aufnehmen und vergleichen

• «Delphi Wideband»-Verfahren
  • Projektleiter schildert Experten das Projektvorhaben, mit strukturierten Arbeitspaketen
  • Experten ermitteln unabhängig voneinander ihre geschätzten Aufwendung
  • Falls Schätzungen stark abweichend, neue Runde mit entsprechender Rückmeldung an Experten
  • Der arithmetische Durchschnittswert ist die endgültige Aufwandschätzung. Der Projektleiter entscheidet!
• Timeboxing-Verfahren
  • Beim Timeboxing-Verfahren schätzt man keinen Aufwand, sondern gibt einen maximalen Aufwand (timebox) vor.
  • Nach Erreichen des Aufwandes werden die Arbeiten gestoppt.
  • Die Realisierung des Proof of Concept (PoC) erfolgt nach dem Timeboxing-Verfahren

• die Zuordnung von Arbeitsaufwänden (Arbeitspakete) zu den Projekt-MA und
• die Verteilung der Arbeitspakete auf die Zeitlinie

• Input: Arbeitspakete inklusive Aufwandplanung und Ablaufplan
• Ziel: Die Zuteilung (zu MA und auf die Zeitlinie) und die Dauer der Arbeitspakete des Projekts ermitteln
• Output: Dauer der Arbeitspakete und Projektdauer
• Lieferobjekt: Ressourcenplan, Kapazitätsbelastungsdiagramm

1. Festlegung der für die Arbeiten benötigten Profile und Zuordnung zu den Arbeitspaketen

2. Sichtung der verfügbaren Mitarbeiter und deren Profile und Zuordnung Mitarbeiter zu Arbeitspaketen

3. Verteilung der Aufwände pro Arbeitspakete und Mitarbeiter auf die Zeitachse unter Beachtung der Auslastung der Mitarbeiter.

• Aus den Arbeitspaketen ergeben sich die benötigten Skillprofile. Diese müssen zu Beginn der Ressourcenplanung für das jeweilige Projekt festgestellt werden.

• Sind diese bekannt, können in einem zweiten Schritt die Mitarbeiterprofile gesichtet und die passenden Mitarbeiter ausgewählt werden.

• Bei fehlenden Skills muss man allenfalls externe MA-Ressourcen zurückgreifen.

• PeBe = Personalbedarf (pro Arbeitspaket)

• Aufw = Aufwand (Personentage)

• Time = Dauer (Tage)

• PeBe = Aufw / Time

• Die Planungsaufgaben werden beim hybriden Vorgehen nicht schon in der Initialisierungsphase, d.h. nicht «up front» für das ganze Projekt erledigt.

• Zu Beginn wird nur der Meilensteinplan gemacht und es wird die Sprintdauer für die Konzeptions- & Realisierungsphase festgelegt.

Beim agilen Vorgehen liegt die Verantwortung für die Ablauf- und Ressourcenplanung beim ProductOwner und erfolgt auf zwei Ebenen:

1. ProductBacklog
2. SprintBacklog

Im Gegensatz zur klassischen Anforderungsliste ist das ProductBacklog am Ende der Initialisierungsphase:

• nicht vollständig, gibt aber einen guten Überblick (80%)
• gilt eine Anforderung immer nur als «proposed»
• sind die Anforderungen nicht endgültig priorisiert

• Da am Ende eines Sprints immer «potentially shippable» Software vorliegen muss, sind alle dazu erforderlichen Tätigkeiten zu planen und zu schätzen
• Es ist wichtig, dass alle Teammitglieder die Aufwände schätzen.
• Das Team verpflichtet sich auf das Sprintziel ⇒ Commitment.

• Input: Organisationsplan
• Ziel: Ermittlung, Optimierung und Finanzierung der im Projekt anfallenden Kosten
• Output: Dokumentierte Kosten
• Lieferobjekt: Projektkostenplan

• Situation durch viele Variablen beschrieben
• stark vernetzte, gegenseitig abhängige Variablen
• Polytelie: gegenseitig beeinflussende oder gar widersprüchliche Ziele
• Intransparenz bei Variablen, Abhängigkeiten, Zielstellung
• hohe Dynamik der Problemsituation: unvorhersehbare Änderungen

• Englisch
  • application of knowledge, skills, tools and techniques
  • to project activities
  • to meet project requirements
• Deutsch
  • Anwendung von Wissen, Fähigkeiten, Werkzeugen und Techniken
  • um Aktivitäten zu planen
  • um Projekt-Anforderungen zu erfüllen

• Projekterfolg
  • Erreichen des vorgegebenen Ziels/Produktes
  • ohne den Zeitrahmen oder den Kostenrahmen zu überschreiten
• Projektmisserfolg
  • Ziel/Produkt nicht erreicht oder
  • Zeitrahmen oder Kostenrahmen überschritten

Quadrat mit vier Ecken und konstanter Fläche:

1. Zeit
2. Kosten
3. Leistung
4. Qualität

Ändert sich ein Parameter (eine Ecke), müssen sich auch andere Ecken ändern, sodass die Fläche konstant bleibt.

Beispiel: Mehr Leistung in gleicher Zeit bei gleichen Kosten? Reduktion der Qualität!

• projektübergreifende Vorgehensmethode oder Regelung
• zur Bearbeitung/Umsetzung von Aktivitäten/Ergebnissen eines Vorhabens
• aus Sicht des gesamten Projektzyklus/Produktlebenszyklus

• [Projektimpuls]
• Initialisierungsphase
• Konzeptionsphase
• Realisierungsphase
• Einführungsphase
• [Nutzung]

• [Phase: Ergebnis]
• Initialisierung: Lastenheft
• Analyse: Pflichtenheft
• Entwurf: Softwarearchitektur
• Realisierung: Softwarekomponenten
• Einführung: Handbücher
• Nutzung

Zu jeder Analyse- und Konzeptionsphase gibt es eine Testphase:

• customer requirements (verified by) acceptance tests
• detailed requirements (verified by) system tests
• system design (verified by) integration tests
• implementation/refactoring

• iterativ
  • Aktivitäten des Entwicklungszyklus werden mehrmals durchlaufen
  • bereits aus frühen Iterationen resultieren lauffähige Prototypen
• inkrementell
  • jeder Release hat einen grösseren Funktionsumfang als dessen Vorgänger

• agil, iterativ und inkrementell
• 3 Säulen:
  • Transparenz
  • Überprüfung
  • Anpassung
• unterstützt Entwicklung komplexer Produkte
• besteht aus:
  • Scrum-Teams
  • Rollen
  • Ereignissen
  • Artefakten
  • Regeln
• Feedback maximieren durch iterative und inkrementelle Produktlieferung
  • dadurch steht immer eine potenziell gebrauchsfertige und nutzbare Version des Produktes zur Verfügung

• das "Herz" von Scrum
• gleichmässige und feste Dauer ("timeboxing")
• liefert fertiges, getestetes, potenziell auslieferbares Produktinkrement
• Bestandteile:
  • Sprint Planning
  • Daily Meeting
  • Entwicklungsarbeit
  • Sprint Review (Abnahme)
  • Sprint-Retrospektive
• ermöglichen Vorhersehbarkeit und Anpassung an Planung/Zielsetzung durch regelmässige Überprüfung des Arbeitsfortschritts

• ProductBacklog verwalten (laufend):
  • Einträge erfassen und ausformulieren
  • Einträge nach Fertigstellungsreihenfolge ordnen (priorisieren)
  • Pflege ("Grooming")
• Sprintplanung (zu Beginn jedes Sprints):
  • Inhalt von Sprint-Backlog mit Entwicklungsteam verhandeln
• Sprintabschluss (bei Sprintende):
  • Inkrement gemäss Testplan ("accepted"-Kriterien) freigeben
  • Restarbeit ermitteln und hochrechnen
• keine übergeordnete Projektplanung

• Auswahl der Organisationsform
• Erstellen der Projektorganisation
• Zuordnung von Aufgaben, Kompetenzen, Verantwortung (AKV)
• Festlegen der Form der Informationsvermittlung und Projektdokumentation
• Bestimmung und Zuordnung von Sachmitteln

• Aufbau- und Ablauforganisation zur Abwicklung eines Projekts (temporäre Projektorganisation)
• Grundformen:
  • reine Projektorganisation (Linien-Projektorganisation)
  • Projektkoordination (Stab-Linien-Projektorganisation)
  • Matrix-Projektorganisation
  • Mischformen

• Die Projektmitarbeiter werden für die Dauer des Projektes aus ihrer Linie herausgelöst
• Kompetenzen des Projektleiters:
  • finanziell
  • fachlich
  • disziplinarisch
  • administrativ
• die volle Projektverantwortung liegt beim Projektleiter

• Die Projektmitarbeiter verbleiben in ihrer Linie
• Kompetenzen des Projektleiters:
  • Koordination
  • keine Weisungsbefugnis
• der Projektleiter hat nur eine beschränkte Projektverantwortung

• Die Projektmitarbeiter haben während der Dauer des Projekts zwei Vorgesetzte (Projektleiter/Abteilungsleiter)
• Kompetenzen Projektleiter:
  • Was
  • Wann
• Kompetenzen Linienleiter
  • Wer
  • Wie
  • Wo
  • Womit
• der Projektleiter hat nur eine beschränkte Projektverantwortung

• Software Development agile
• auf Scrum gestützt: iterativ-inkrementelles Vorgehen
• auf eine künstliche Trennung von Konzeption und Realisierung wird verzichtet

• Projektleiter
• ProductOwner
• Scrum Master (optional)
• Scrum Team

In einem Schulprojekt könnten mehrere Rolle von einem Studierenden eingenommen werden.