Projektmanagment

Projektmanagment

Projektmanagment


J. H.
Diese Lernkarten bieten einen umfassenden Überblick über Projektmanagement auf Universitätsniveau, mit Fokus auf Methoden wie Scrum, PRINCE2 und V-Modell. Sie behandeln Themen wie Projektorganisation, Aufwandschätzung, Qualitätsmanagement und Risikobewertung, wobei auch praktische Aspekte wie Präsentationstechniken und Dokumentation berücksichtigt werden. Ideal für Studierende und angehende Projektmanager, die fundierte Kenntnisse in der Planung, Steuerung und erfolgreichen Durchführung von Projekten erlangen möchten.
Flashcards
86
Students
5
Language
German
Category
Computer Science
Level
University
Created / Updated
11.06.2018 / 13.12.2022

Flashcards

Ein Projekt ist ein...

aussergwöhnliches Vorhaben

Auftrag ....... Abnahme

Analyse

Konzeption

Realisierung

Implementierung

Planen:

WAS müssen wir abgeklärt haben um Ziel mit vereinbarten Mittel in vereinbarten Zeit erreichen.

VOR BEGINN DES PROJEKTABSCHNITTS

Steuern:

Projekt so führen, dass mit MIttel und Zeit Projektscope erreicht wird

Kontrollieren:

Überprüfen, ob MIttel, Zeit zu Projektscope geführt haben

Wenn ja, weiter

Wenn nein, evtl Projekabschnitt nicht verlassen, Plan überarbeiten und nochmals durch Abschnitt

Projektmanagement, kreis

Steuerung --> Kontrolle --> Planung --> Steuerung .... 

Unter Projektmanagment wird die Gesamtheit der..

Führungsaufgaben, -organisation, -techniken und -mittel zur Abcklung eines Projektes verstanden

magische Dreieck

time scope budget

Scope

Ergebnisumfang

Qualtität

budget

Projektmitarbeiter

Ressourceninanspruchnahme seitens Auftraggeber

time

Endtermin

auch Meilensteine während Projektablaufs

System

System (Unternehmen)

Element (Abteilung)

Beziehung (Informationswege)

Programm

besteht aus einer Menge von Projekten, stehen in Beziehung miteinander

auch ein Projekt (Multi-Projekt)

Sequentielles Vorgehen

beliebige Ausprägungen bekannt

nur in kleinen Projekten anzutreffen

sagt nur, welche Ergebnisse im Zeitablauf zu erwarten sind

Wasserfallmodell

Problem, Planungsphase, Definitionsphase, Entwurfsphase, Implementierungsphase, Abnahme/Einführung, Betrieb

Wasserfallmodell mit Rücksprungoption

Zusätzlich zu Qualitätskontrolle am Ende gibt es die Möglichkeit, in die vorhergehende Phase zu gehen, falls das nötig ist

Agiler Ansatz

Projekt wird auf einzelne Entwicklungseinheiten herabgebrochen

Jede Entwicklungseinheit, für die im Vorfeld der Aufwand geschätzt wurde, wird eigenständig umgesetzt

Die Kontrolle im Anschluss schafft Erfahrungen, auf deren Basis neu geplant und Zielkorrekturen durchgeführt werden können. 

Scrum

wird häufig als Vorgehensmodell für agilen Ansatz gewählt

Use Case

sequentielle SW-Entwicklung

bündelt Szenarien, die eintreten können

abstrahiert von konkreten techn. Lösungen

formaler, auführlicher, umfangreicher

User Story

beschreibt, wie Anwender mit Produkt interagiert

unerstützen Planung auf PM-Ebene für beabsichtigte Funktionalität, Prio, Zuordnung Sprints

verwenden Sprache der User

User Story - Invest

Independant, Negotiable (verhandelbar), Valuable, Estimable, small, testable

Story Points

klassifizierten User Stories

je grösser die User Stories, desto weniger verlässlich sind die Schätzungen

fibonacci: immer die zwei vorhergehenden Zahlen addieren, relativ!

 

Story Mapping

Product Ower

verfolgt die selben Ziele wie ich

priorisiert Product Backlog

vertritt fachliche Auftraggeberschaft und User

Mitglied Scope Authority Board

kann in einem Sprint Review teilnehmen und Ergebnisse zurückweisen

Development Team

5-7, alle Skills vorhanden

selbstorganisiert

bricht User Stories zu Tasks

plant Sprint, 4-8h

Daily Scrum, 15min

Spring Review, 4h am Ende jedes Sprints

Scrum Task Board

physisch vorhanden, durch Sprintteam bedient und sichtbar sein, daily meeting davor

Sprint Burndown Chart

x-Achse: Zeit

y-Achse: Aufwand, Story Points oder Anzahl User Stories, dann aber schwer lesbar, Ideallinie nicht linear

Product Burndown Chart / Release Burndown Chart

Scrum Artifact : Increment

Increment ist Summe aller completed Tasks einer Sprints

muss anwendbar sein

Minimum Viable Product

erste, minimale funktionsfähige Summer von Increments, die einen User-Nutzen erzeugen. 

User muss bereit sein, testen oder anzuwenden

Zwischenstufe zu angestrebtem Produkt, muss geeignet sein, um Eindruck des angestrebten Prudukts zu erhalten bzw. Feedback zu geben

Agiler Ansatz: Programm

spätestens wenn Sprints parallelisiert werden, liegt ein Programm vor

Unterschied Projektantrag/Projektauftrag

 

oft synonym

Antrag "Bitte" für einen zu erstellenden Auftrag. Wenn Projektantrag als Antrag für einen Projektauftrag verstanden werden soll, muss dies so definiert sein. Ansonsten verbindlicher Vertrag

Projektauftrag, typische Bestandteile, 11

Kopfdaten (Bezeichung, Antragsdatum, Antragssteller, Auftraggeber)

Kurzbeschreibung (wer, was ist betroffen? was soll erreicht werden?)

Ausgangslage/Grund des Vorhabens (Motivation)

Ziel/Nutzen

Projektverlauf, Meilensteine

Ressourcen/Kosten

Projektorganisation, organisatorische Auswirkung

organisatorischer Umfang, Mitwirkungspflichten

Risikomanagement, Komplexität

nächste Schritte (bei go)

Unteschriften

Projektantrag - Fehler

roter Faden!
verbindliche Ausgangslage
Problemstellung --> Lösung
wer wann wie mitwirk
wann und wie abgeben

Konsens zwischen Auftraggeber/Auftragnehmer?
unklare Punkte wird Vertragspartner zu seinen Gunsten verstehen

Projektbeginn erst nach Unterschrift
wird vorher begonnen, hat Auftraggeber wahrscheinlich eine wirtsch. Interesse, die Unteschriftserbringungen zu verschleppen. 

Projekterfolg

gewünschte Resultate mit vorgesehenen MItteln innerhalb der geforderten Zeit in der geforderten Qualität

1/3 SWE Projekte erfolglos eingestellt
> 1/2 Kostenüberschreitung fast 200% zu teuer
nur 9% im Rahmen der Kosternschätzung
 

Projektrisiko

Höhe des Schadens für Unternehmen wenn Projektziele nicht erreicht werden

Einflussfaktoren Projektrisiken, 6

Entwicklungsbedingungen

Restriktionen

Projektbedingngen

Anwender

Produktbedingungen

Firmenbedingungen

Mögliche Beispiele für Risiken

Selbstüberschätzung

man weiss nicht, was man eigentlich will

unrealistische Leistungszusage in der Vorprojektphase

Unterschätzen der Komplexität 

Fehlende Normen und Standards für Analyse und Programmierung

Mangelnde Doku des abzulösenden Systems

Motivation

Analyse potentieller Probleme APP, Theorie und vier Phasen?

Risiken erkannt man nicht automatisch, müssen aktiv identifiziert werden, Checklisten reichen nicht

Laufend Risikoanalyse

- Suche nach potentiellen Probleme
- Gewichtung der potentiellen Probleme nach Eintrittswahrscheinlichkeit/Tragweite
- Identifikation und Umgebung wahrscheinlicher Ursachen
- Massnahmen zur Schadensminimierung definieren, falls Ursachen nicht verhindert werden können

PM kann zum Erfolg beitragen, wie?

dedizierte Meeting/Workshop/Brainstorming zu Risikoidentifikation/ -managment

erkennbare Risiken bereits im Auftrag erwähnen

korrekte Aufbereitung von Entscheidungsgrundlagen

Study