IT Project Management - HWZ

Steering Committte fällt zentrale Entscheide losgelöst von Projektleiter. Projektleiter ist z.B. extern oder intern und hat keine Kompetenzen. Sehr erfahrene Leute, erwarten klare Forderungen, Informationen. Klare Risiken, genaue Kosten etc. Auf fiese Fragen vorbereitet sein.

- Analyse

- Design (fachlich, technisch)

- Evaluation (Kandidaten testen, auswählen)

- Implementieren, Realisieren

- Testphase, Qualitätssicherung

- Marketing des Projektes/Produktes, Präsentation

- Inbetriebnahmen, Schulung

- Wartung (Fehlerbehebung, Upgrades für mehr Funktionalität, Optimierung)

Hermes, Srum, XP etc.

Analyse, Design, Implementierung, Testen

Jede Phase muss zu 100% abgeschlossen sein bis nächste beginnt

Nachteil: Zeitintensiv, gewisse Dinge werden zu spät entdeckt, moving targets (Markt ändert sich), bei Problemen zu letzter Phase zurück gehen und weiter zurück bis da wieder 100%. schwerfälliger Dinosaurier bis mal in Bewegung danach dafür aber richtig.

Vorteil: Klare Systemgrenze, Für Projekt bei dem viel Qualität gefragt ist, dafür Geld nicht und Zeit nicht

Scrum, kein exaktes Requirement, sondern Idee (z.B. bei Video)

Vorteil: schnell etwas greifbares, mit jeder Phase kann auf moving targets eingegangen werden, aber Achtung Teufelsquadrat, Probleme werden schnell erkannt und es kann schnell darauf reagiert werden. Team kann schneller egänzt werden

Nachteil: Budget kann ausarten, Ziele werden schlussendlich vielleicht gar nicht mehr erreicht, im ersten Moment schwer planbar, emotional für Manager, der damit keine Erfahrung hat eher high Risk

Diese Art auswählen wenn man schnell auf den Markt reagieren können muss, ich kann regelmässig bereits Teilergebnisse abliefern (Teilprodukte), muss aber sauber rüber gebracht werden.

Scrum wird als Framework und bewusst nicht als Vorgehensmodell bezeichnet, da es nur aus wenigen Regeln besteht.

Statt einem vollumfänglichen Plan wird in Scrum ein Detailplan (das Sprint Backlog]) nur für den jeweils nächsten Zyklus (dem Sprint) erstellt. Damit wird die Projektplanung auf das wesentliche fokussiert, um dadurch im Gegenzug eine hohe Planungsdisziplin zu ermöglichen.

Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um einen vollumfänglichen Plan erstellen zu können.

Die empirische Verbesserung beruht dabei auf drei Säulen: ^[7]

1. Transparenz: Der Fortschritt und die Hindernisse eines Projektes werden regelmäßig und für alle sichtbar festgehalten.
2. Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und sowohl das Produkt als auch das Vorgehen beurteilt.
3. Anpassung: Die Anforderungen an das Produkt, die Pläne und das Vorgehen werden nicht ein für alle Mal festgelegt, sondern kontinuierlich detailliert und angepasst (just-in-time.

Quelle: wikipedia

Software getrieben, 12 Grundmassnahmen definieren, dann das Team einfach laufen lassen

Prüfung keine Abfrage der 12 Grundmassnahmen, aber Idee kennen

z.B. zuerst Tests programmieren, damit danach Test automatisch über Programm laufen gelassen werden können (über Nacht)

2 vor einem PC, Fehler gleich erkennen, Seniors und Juniors zusammen, immer 2 Leute wissen über etwas Bescheid, somit Doku überflüssig, Paare werden regelmässig gewechselt, somit wissen schlussendlich alle über alles Bescheid, Wissen fehlt nicht falls jemand ausfällt

kurze Zyklen, täglich auf Deploymentrechner rauf spielen

Einer (Produktowner) sitzt in der Mitte des Entwicklungteams und muss alle Fragen zum Produkt entstehen beantworten und Entscheidungen treffen.

Vorteil: schnell etwas in der Hand, Fehler sind gut erkennbar, Machbarkeit ist ersichtlich

Nachteil: Da Prototyp bereits läuft, wird gleich mehr gefordert. Es ist nicht ersichtlich, das Fehlerbehebung etc. Gar noch nicht besteht, noch keine Sicherheitsvorkehrungen

Prototyp nie live einsetzen!

Verschiedenen Windowsversionen. z.B. Home, Premium etc.

Managementintensiv, frage der disziplin, eher weniger komplex

z.B. Fahrrad 100% zerlegen in Gestell ..%, Sattel ..%, Pedalen ..% etc. -> alle Unterteile zusammen müssen 100% ergeben.

Projekt in sinnvolle Einheiten zerlegen

Phasenorientiert (Analyse, Desigen), Objektorientiert (Video und Doku),

egal wie, hauptsach schlussendlich 100%

Achtung Qualitiymanagement dabei nicht vergessen

Am Schluss soll ein Produkt entstehen

Was sagt WBS nicht aus? Was fehlt da? -> Abhängigkeiten, was wollen wir erzeugen, nicht wie! Welche Reihenfolge, logische Abhängigkeiten werden nicht gesagt

z.B. wenn 1. tätigkeit beendet start 2. -> anfang zu ende

oder 1. Tätigkeit beendet, delta zeit = warten, start 2. -> anfang zu ende mit wartezeit

oder bei Auto herstellung: diverse Tätigkeiten sind gleichzeitig zu ende dann start nächste tätigkeit -> ende zu ende

Um Zeitdauer zu berechnen, Durchnittswert nehmen zwischen guten und schlechten Mitarbeitern, manchmal mehr Risiko eingehen manchmal mehr Zeit für Zwischenfälle einberechnen.

Wenn 2 Maurer gleichzeitig arbeiten, halbiert sich die Zeit theoretisch, aber in Praxis können sie sich im Weg stehen, Konflikte entstehen, Kommunikationsaufwand

Gewisse Tätigkeiten können durch mehr MA nicht verkürzt werden z.B. Schwangerschaft: 1 Frau braucht 9 1/2 Monate und 10 Frauen brauchen ebenfalls 9 1/2 Monate.

Personen * Anzahl Tage = Volumen

Volumen 1 Woche mit 2 Personen -> jede Person benötigt 2.5 Tage
 

Analyse: wie würde sich das aufs Projekt auswirken (Zeit, Geld etc), dann Auftraggeber vorlegen. Fall Auftraggeber dies immer noch wünscht:

entweder noch oben eskalieren (kann heikel sein)

oder Bettel hinschmeissen (bin ich wohl der falsche Projektleiter dafür), aber nur selten so dass es grosse Geste ist. Damit wird fullstop von projekt erreicht.

Fakten auf den Tisch legen, Rückgrat zeigen und nicht weich werden. (wenn ich überzeugt bin dass etwas nicht geht)

Kosten/Nutzenfaktor

dringlichkeit

low hanging fruits

Risiken

-

-

-

-

-

Anfang, Ende, danach Betrieb des Produktes

Ressourcen

Projektstruktur

Messkriterien (Qualität) ob Ziel erreicht wird

Unfähigkeit der Leute

wichtige Punkte / Leute werden vergessen

unrealistische Ziele

Unterschätzung von Risiko und Auwand

Output inzwischen nicht mehr relevant

fehlende Akzeptanz

Fehlerhaft

Komplexität (fachlich, technisch, durch Menge komplex)

weniger als 10% scheitern an technick

90% schlechte Kommunikation, schlechtes Stakeholdermanagement, schlechte Requirements

SMART= spezifisch, messbar, achievment (erreichbar), Ressourcen, Termin

englisch = Specific Measurable Accepted Realistic Timely

• Dynamik
• Ziele
• Risiko
• spezifische Organisation
• Neuartigkeit
• begrenzte Ressourcen
• Komplexität
• Kultur

siehe Bild

siehe Bild

siehe bild

siehe bild

siehe Bild

 -

-

Verständnis von der Strategie, Struktur und Kultur der Stammorganisation gewinnen und Differenzen zwischen Stammorganisation und Projektorganisation herausarbeiten.

Schnittstellen zwischen der Stammorganisation und der Projekt-, Programm- und Portfolioorganisation identifizieren und definieren.

-

verschafft Übersicht, zeigt die verschiedenen Prozessgruppen eines Unternehmens auf und gliedert sich wie folgt:

• Führungs-/Managementprozesse
• Ausführungs-/Kernprozesse
• Unterstützungs-/Supportprozesse

-

-

-

-

-