Zusammenfassung - wintersemester iitp internationales it.projektmanagement PDF

Preview

Summary

International IT- Project ManagementProjekt Definition Ein Projekt ist temporäres Bemühen um ein besonderes Produkt, einen Service oder bestimmtes Ergebnis zu entwickeln  Bsp. Cloud Service installieren, ERP System integrieren, Messungen zur Kostenreduzierung eines BauteilsCharakteristika eines Pr...

Description

International IT- Project Management Projekt Definition  

Ein Projekt ist temporäres Bemühen um ein besonderes Produkt, einen Service oder bestimmtes Ergebnis zu entwickeln Bsp. Cloud Service installieren, ERP System integrieren, Messungen zur Kostenreduzierung eines Bauteils

Charakteristika eines Projekts       

Es ist immer zeitlich begrenzt Oftmals in verschiedenen Schritten umgesetzt Benötigt Ressourcen Hat immer eine besondere, spezifische Zielsetzung Kommt mit bestimmten bekannten und unbekannten Risiken Meist ein Projekt Sponsor (oder Besitzer), welches Budget bestimmt, Fortschritt aufzeichnet, Zwischenziele setzt & die Art wie Probleme angegangen werden Wirt evtl., aber evtl. auch nicht vollendet

Unterschied zwischen Projekt und Operation 



Projekt: Definition s.O o Projekte können groß oder klein sein und viel oder wenig Zeit beanspruchen o Projekte enden, wenn ihr Ziel erfüllt ist oder die vereinbarte Zeit abgelaufen ist Operation: Ist Arbeit um die „Früchte“, Kapital aus einer Unternehmung zu ziehen/ ernten o Operationen sollten widerkehrendes Einkommen generieren o Den Wert einer Unternehmung steigern o Einkommen und Wert einer Unternehmung sichern o Operationen ändern sich etvl. Oder werden beendet, aber werden als langhaltige Aufgabe geplant o Bsp. Cloud Service betreuen, Büroräume regelmäßig säubern, Autoteile produzieren

Geschäftsprozess 



Ein Geschäftsprozess ist eine Sammlung von strukturierten und gut beschriebenen Aufgaben, welche zu einem bestimmten Ergebnis, welches immer wieder wiederholt wird, führt. o Unterschied zwischen Operationen und Geschäftsprozessen? – Operationen sind eine Ansammlung von Geschäftsprozessen o Projekt oder Prozess/ Operation? – Nicht immer eindeutig, kommt auf Perspektive an. Finanzprüfung ist für Prüfungsunternehmen ein Projekt, aber ein Prozess für die geprüften Ergebnis eines Geschäftsprozesses könnte ein Produkt, ein Service, eine Veränderung oder eine Information sein

Taktik & Strategie    

Ein Projekt ist unterteilt in Teile Oftmals sinnvoll große Projekte in Unter-Projekte zu gliedern Ein Projektportfolio ist eine Sammlung von Projekten aufgrund gleicher Ziele oder Methoden Ein Programm ist eine großes Langfristiges Ziel, welches in verschiedenen Projekten umgesetzt wird



Je größer der Umfang, desto mehr wechseln die Leitungsfragen von Taktik (machen wir die Sachen richtig) zu Strategie (machen wir die richtigen Sachen)

Warum Projektmanagement formalisieren?  

Um die Komplexität zu bewältigen Systematische Herangehensweise hilft o Große Aufgaben in kleinere zu unterteilen o Ressourcen effektiv zu nutzen o Kunden zu integrieren und Anforderungen zu versammeln o Zeitersparnis (Parallelität der richtigen Dinge) o Kosten und Cash Flow im Auge o Früher Problemerkennung o Erleichtert lernen für spätere Projekte o Erhöht die Zufriedenheit im Team o Erleichtert die Arbeit

Die Drei Dimensionen (Koordinatensystem) / Generelle Ziele des Projekt Managements   

Scope / Umfang -> Werden die Ziele erreicht Time / Zeit -> werden die Resultate pünktlich erbracht Cost / Kosten -> bleiben die Kosten innerhalb des Budgets



Erfolgreiches Projektmanagement bedeutet alle drei Ziele (Scope, Time & Cost) zur Zufriedenheit des Projekt Sponsors zu erfüllen

Projekt Management Lebenszyklus (PMLC)

Die Fünf Prozessschritte des Projekt Managements („process groups“)     

Scoping -> Projektziele verstehen, Anforderungen erkennen. Danach „Go“ für den nächsten Step erhalten Planning -> Arbeitspakete bestimmen, Ressourcen Planen (Budget, Zeit, Personal etc.), Rollen und Arbeitsschritte dokumentieren Launching -> Team bilden und Verantwortung und Grundregeln bestimme Monitoring & Controlling -> Änderungsanfragen bearbeiten, Probleme entdecken & beheben, Projekt dokumentieren Budget im Auge behalten Closing -> Projekt Ergebnis beurteilen, Potenzial für Verbesserung identifizieren, Team belohnen und „entlassen“

Project life cycle with slightly different naming Charakteristika von IT- Projekten     

Wenig Lieferanten involviert Relativ einfach die Anforderungen während der Arbeit zu verändern Oftmals möglich Probleme auch kurz vor Fertigstellung zu beseitigen Lösungen können von kleinem Ansatz zu sehr aufwendigem Ansatz wachsen Wiederverwenden von „Teilen“ kann Kosten sparen

         

Lösung kann günstig kopiert/ vervielfältigt werden Angestrebtes Ergebnis ist nicht immer klar Oftmals nicht möglich das Endprodukt komplett zu spezifizieren, vom Kunden Ergebnis oft Komplex und einzigartig, bevor man es vervielfältigt Technologische Fortschritte während Projekt, monatlich neue starke Entwicklertools Qualität des Ergebnisses oftmals schwer zu bestimmen Entwicklung stoppt nicht wirklich (Patches, Updates, neue Interfaces) Alte Systeme können eine Herausforderung sein Viele Aspekte werden während des Projektes klar Die Projektumgebung ist agil, wenn man viele Änderungen bezüglich der Technologie, der Anforderungen und/ oder des Marktes zu erwarten hat

Wann nutzt man Traditional Linear Project Management (TLPM)  

 

Gut für Projekte mit geringer Komplexität -> nutzbar für unerfahrene Teams Projektanforderungen (Scope) sollte klar definiert sein, Änderungen unwahrscheinlich Die Technologie sollte bekannt und erprobt sein -> auch keine enge Kundenintegration Projektumgebung sollte stabil sein (geringe Risiken) -> Standort unabhängig, Outsourcing ist einfach

Wann nutzt man TLPM   

Modernisierung einer kleineren Webseite Geschäftsprozess in bestehendes ERP- System integrieren Gewöhnliche Telekommunikationsinfrastruktur in eine Firma aufbauen

Wasserfallmodell   

Sequenzieller Prozess mit Anforderungen, Design, Implementierung, Verifizierung & Wartung Nächste Phase wird erst bearbeitet, wenn vorherige überprüft und verifiziert ist Modell kommt aus Zeit vor Softwareentwicklung -> wird genutzt wo Änderungen sehr kostspielig sind

Wasserfallmodell Pro & Contra Pro: n     

Einfach und gut strukturiert Fehler zu verbessern ist zu Beginn günstiger Strukturierte Vorgehensweiße hilft bei Dokumentation Ok für stabile Projekte Passt für unerfahrene / low- peforming Teams

Contra:   

Software Projekte sind selten stabil & erfordern ein nach justieren der Anforderungen Nicht für agile Projekte Schwer Prototypen und Kunden in den Prozess zu involvieren

Traditional incremental Project Management (TiPM)

Wann nutzt man TiPM

   

Passen für Projekte mit geringer und mittlerer Komplexität -> für Teams mit etwas Erfahrung Die groben Anforderungen sind klar, aber manche Details fehlen -> höhere Aufmerksamkeit der PM Die Technologie muss ausgereift sein und gut verstanden werden -> Standortungebunden, Outsourcing relativ leicht Stabile Projektumgebung -> Kunden können einbezogen werden

Wann nutzt man TiPM  

Smartphone App entwickeln mit bekannten Funktionen aber unklaren Interface und Nutzungskonzept Montagekosten eines Wlan Routers reduzieren

V- Modell    

Erweiterung des Wasserfallmodells Ähnelt iterativen Prozess und erlaubt so Feinjustierungen Phasen: Projekt Definition, Implementierung, Projekt Test und Integration, Verifizierung & Validierung V Modell ist Entwicklungsstandard des German public sector

V- Modell Pro & Contra Pro:     

Relativ einfach und gut strukturiert Einfache Übertragung, wenn Entwickler das W- Modell kennen Struktur erleichtert Aufzeichnungen Ok für stabile Projekte Befürworter meinen das Modell entwickelt sich mit der Zeit

Con:      

Zu einfach um Entwicklungsprozess zu zeigen, eher eine Managementsicht auf die Dinge Manager sind evtl angetan von der Einfachheit und bestehen auf Folgen der schritte Nur eine leichte Abänderung des W- Modells Viele Definitionen des Modells -> keine Eindeutigkeit Bekräftigt Vorgefertigte Test Skripts zu nutzen, anstatt zu testen Besser als das Wasserfallmodell, aber trotzdem nicht für Agile Projekte geeignet

Agile Iterative Project Management (AiPM)

Wann nutzt man AiPM   

Team sollte gut zusammenarbeiten, max. 20 Leute im Team, bei größeren Teams -> Sub-projects nötig Team sollte an einem Ort arbeiten Benötigt erfahrenen Projektmanager, People skills sind sehr wichtig, Top Management, Sponsor sollte akzeptieren, dass Risiken eingegangen werden -> TM support ist essenziell

AiPM Pro & Contra Pro:  

Passend für Projekte mit höherem Risiko Projektziele sind klar definiert, Herangehensweise wie dies erreicht wird ist unklar

 

Kein Arbeitsplan wie bei TLPM, aber ein Zeitplan High Performing Entwickler wollen oftmals Flexibilität

Cons:     

High Performing Team benötigt Benötigt mehr Flexibilität und deshalb schwereres controlling Team muss mit Rückschlägen klarkommen, Management muss sie motivieren Niedrigere Effizienz bei nicht komplexen Aufgaben Ungewiss wieviel Zeit und Budget benötigt wird

Extreme Project Management (EPM)

Wann nutzt man EPM      

Für richtige R&D Projects (research & development) Zum Entwickeln von anspruchsvollen Produkten basierend auf einer „Vision“ Wenn der Markt und der Wettbewerb sehr agil sind Wenn viele Fahler erwartet werden, nur für hoch qualifizierte Teams PM muss hohen Grad an Freiheit erlauben, TM support ist essenziell Controlling ist sehr schwer, eher Gefühl als bloße Zahlen

Zum Entwickeln eines Iphone DNA Sequenzer für den Massen Markt Klassen Traditionell linear  

Wasserfallmodell Rapid Development Wasserfall

Traditionell Incremental 

V- Modell

Klassifizierung von Projekten         

Risiko Dauer Erfahrung des Teams Tradition des Unternehmens oder der Industrie Unternehmenskultur Komplexität Kundentyp Wettbewerb Reife der Technologie

Standradentscheidung

agil - Scrum Extreme - INSPIRE

Rollen und Fähigkeiten des Teams & des Projektmanagers Traditionell  

Projektmanager definiert Anforderungen mit Kunden, definiert Arbeitspakete, erteilt Arbeiten an Mitarbeiter und Sanktionen für langsamen Fortschritt Team arbeitet

Agil  

Projektmanager ist mehr ein Moderator des Prozesses Team bestimmt Anforderungen mit PM & Kunden, bricht Projekt in Arbeiten runter und organisiert Arbeitszuweisung

Scoping: Interessensgruppen Analyse (stakeholder analysis) 

Hauptfragen während der Scoping Phase o Was möchten oder sollen wir tun? o Wie können wir später evaluieren wie gut wir es gemacht haben? o Sollen wir das Projekt starten

Schritte der Interessensgruppen Analyse (stakeholder analyses) 1. 2. 3. 4. 5. 6. 7.

Interessensgruppen bestimmen (wer) Interessen vergleichen (was und warum) Einfluss beurteilen (hoch/ niedrig x positiv/negtaiv) Schritte 1-3 überdenken Priorisieren Strategie definieren, um mit allen Interessensgruppe klar zu kommen Verantwortlichkeiten der nächsten Schritte bestimmen

Schritte 1: Interessensgruppen bestimmen 



Interessensgruppen sind Personen, die im Projekt involviert oder betroffen sind o Kunde/ Sponsor o Endkonsument o Systemnutzer o Projekt Manager & Team o Zulieferer o Unterstützung in Organisation o Interessen Gruppen, Lobbys etc. o Presse etc… Sollte möglichst allumfassend sein

Schritt 2: Interessen vergleichen    

Was möchte die Organisation erreichen? Was möchten deren Chefs persönlich erreichen? (evt unterschied zur Organisation) Was treibt sie an? Höhere Strategie, Vision? Geld? Angst? Publicity? So viele Blickwinkel wie möglich nutzen

Schritt 3: Einfluss der Interessensgruppen bestimmen   

Interessensgruppen clustern aufgrund von Interesse & Macht etc. Antwortpotential in verschiedenen Situationen beurteilen Oftmals gut Experten zu involvieren, besonders bei Technischen Herausforderungen

Schritt 4: Schritte 1-3 überdenken    

Oftmals erscheinen neue Interessensgruppen während Schritt 2 Vollständigkeit ist der Schlüssel „Out oft he box“ denken Perspektive aller Interessensgruppen bedenken

Schritt 5: Interessensgruppen Priorisieren    

Die Zahl an Interessensgruppen variiert von Projekt zu Projekt (Größe, Wichtigkeit, Zahl der beeinflussten) Zu lange Listen führen zu langer Wunschliste und widersprechenden Wünschen Priorisierung ist nötig, um relevante Interessensgruppen zu bestimmen Gruppierungen von 3-5 in nicht relevant, könnte relevant werden, relevant und entscheidend

Schritt 6: Interessensgruppen Management Strategie bestimmen  

Wie mit jeder Interessensgruppe umgehen? o Level der Aufmerksamkeit: involvieren, informieren, überwachen, ignorieren Was wollen sie? Zugeständnisse machen, Einflussverringern, diskreditieren etc.

Was sind Anforderungen?  

Ein funktionelles oder physisches Bedürfnis / Anforderungen variieren von „nice to have“ zu „muss“ Spezifikation -> explizite Sammlung von Anforderungen, welches befriedigt erden muss

Warum aufgaben formalisieren?         

Anforderungen sind nicht immer eindeutig Kommen von vielen Quellen Nicht immer einfach in Worte zu packen Viele verschiedene Typen von Anforderungen mit verschiedenem Level an Details Anzahl an Anforderungen kann zu viel werden, wenn sie nicht kontrolliert werden Anforderungen sind nicht unabhängig und kreieren Konflikt Situationen Viele interessierte und verantwortliche Parteien Änderungen als Resultat sich veränderter Geschäftsbedingungen Kann sich verändern

Anforderungsdefinition strukturieren     

Geschäftsanforderungen Nutzeranforderungen (stakeholder) Funktionsanforderungen (solution) Serviceanforderungen (non-functional) Bei sehr komplexen Projekten sind die Typen von Anforderungen eine Dimension und Stakeholderanalyse die zweite Dimension

Kategorien von Anforderungen Funktionell: was muss ein Produkt oder Service tun/erfüllen Nicht funktionell: Eigenschaften bestimmen, die der Service oder das Produkt erfüllen muss Global: Höchstes Level an Anforderungen, generelle Anforderungen Projekt Einschränkungen: limitierende Entscheidungen, Regeln an, die sich das Team halten muss Anforderungen: „nice to have“ or “an ultimate must”: 



 

Was Kunde möchte entspricht nicht immer dem was er braucht Projekt Manager sorgt dafür, dass Kunde das bekommt was er braucht Gefahren: Unrealistische Erwartungen Zusätzliche Anforderungen, Arbeit ohne oder für

entbehrlichen Nutzen/ Wert Bemerkungen beim Dokumentieren von Anforderungen 

Sichere Dokumentation ist eins der wichtigsten Kriterien des hoch qualitativen Projekt Management

Dokumentation sollte: 

Verständlich, korrekt, komplett, unterschrieben & auf Widersprüche gecheckt sein

Überwachungsmethode 

Hilfreich um Laborintensive Prozesse bei Produktion und Logistik zu verbessern

Stärken  

Spezifische Beschreibungen der Handlungen sind nötig Effektiv, wenn Routine Aktivitäten schwer zu beschreiben sind

Risiken   

Dokumentieren und Videos aufnehmen sind Zeitintensiv, teuer und illegal? Missverständnis was beobachtet wird Beobachtung beeinflusst Handlungen der beobachteten

Anforderungen wiederverwenden  

Eine Liste oder Struktur von Anforderungen und Beschreibungen in ähnlichen Kontext wiederverwenden Leichte Abweichungen zu bestehenden Anforderungen

Stärken    

Anforderungen sind schnell bestimmt Redundantes wird reduziert Kunden sind zufrieden wegen vorherigen Beweises Qualitätsverbesserung

Risiken   

Investments zum Entwickeln von Archiven und Bibliotheken etc Evtl Verletzung des geistigen Eigentums Ähnlichkeiten vielleicht missverstanden

Prototypen Stärken      

Innovative Ideen können erstellt werden Nutzer erkennen Anforderungen, die fehlen Kundenfokusiert Früher Beweis des Konzepts Simulation Nutzer bestärkt in was sie wollen

Schwächen  

Spezielle Fähigkeiten benötigt Keine Dokumentation

Methoden, um Anforderungen zu entwickeln     

Interview / Gruppengespräche Markt Analyse, Literatur Studie Beobachtung Anforderungen wiederverwenden Prototypen / Prozess Modellierung

Interview Methode 

Interview vom PM mit relevanten Interessensgruppen

Stärken  

End Nutzer Beteiligung Beschreibung der Funktionen und des Prozesses

Schwächen   

Beschreibung passt evtl nicht mit dem gebrauchten/ gewollten überein Ohne Struktur wissen die Interessensgruppen evtl nicht welche Information benötigt werden Anforderungen evtl ignoriert, wenn Analyst voreingenommen ist

Gruppen Gespräch Methode  

Treffen von Kunden, PM, Interessensgruppen bei dem die Anforderungen von jedem besprochen werden Oftmals wird mit Moderator gearbeitet, Brainstorming, flipcharts, Diskussionen

Stärken  

Perfekt für übergreifende Prozesse Detaillierte Anforderungen, welche direkt dokumentiert und verifiziert werden

Schwächen  

Untrainierte Moderatoren können zu negativen antworten führen Zeit & Kosten des Planens können sehr hoch sein

Marktanalyse & Literatur Studie

 

Strukturierte Übersicht, über was existiert -> oftmals gleiches/ ähnliches Problem schon gelöst Tools: Websuche, Literatur suche, Patent Analyse, Analyse der Mitbewerber, Tests Nutzer Erfahrung etc.

Stärke  

Perfekt um Übersicht zu erlangen und überarbeitete Struktur für Anforderungen Je nach dem was existiert sind sehr detaillierte insights nötig

Schwächen  

Copyright Probleme, Verletzung geistigen Eigentums Nicht adaptiert an leicht veränderte Anforderungen

Was ist ein Anwendungsfall?    



Anwendungsfall: Kombination aller möglichen Szenarios, welche passieren können, wenn versucht wird ein bestimmtes Ziel mit Hilfe des Systems zu erreichen Ziel: Als neuer Nutzer registrieren, Raumtemperatur erhöhen, Playlist erstellen etc. Interaktion: Schritt, den der Nutzer unternimmt, um Ziel zu erfüllen (click on register etc.) Falldiagramm: Methode zum Modellieren der Struktur und dem Verhalten eines Softwaresystems o Hilft die Interaktion zu bestimmen, um ein bestimmtes Ziel zu erreichen o Ein Falldiagramm ist ein Verhaltens Diagramm -> es zeigt das erwartete Verhalten eines Systems -> deshalb wird es genutzt, um Anforderungen zu spezifizieren Prozesse werden nicht mit Falldiagrammen repräsentiert -> Prozesse kann man mit Aktivitätsdiagrammen und Flussdiagrammen zeigen

Systemgrenzen   

Die Wahl des Systemgrenzen beeinflusst die Anwendung Grenzen sind gezogen, um die nötigen Informationen zu beinhalten Was nötig ist und was nicht, liegt an der Perspektive

Relationen: Gerade Linien: Relation zwischen Darsteller und Anwendungsfall Gepunktete Linien: Relationen zwischen zwei Anwendungsfällen: umfassend und erweitert Include (umfassend): Anwendungsfall ist eingeschlossen Extend (erweitert): evtl abhängig von Zustand -> weitere Aktion

Use case: Power up/down • Actors: Home Owner • Type: Primary and essential • Description: The Home Owner turns on or off the heating system. • If “power down” ▪ Perform “turn_off_system” • If “power up” ▪ Perform “turn_on_system” ▪ If room too cold + Perform “Temperatu...