Projektmanagement 5. Frameworks und Normen im IT- Projektmanagement Dozentenversion!!! 1 © Prof. Dr. Walter Ruf

Projektmanagement

5. Frameworks und Normen im IT-Projektmanagement

Dozentenversion!!!

1© Prof. Dr. Walter Ruf

5. Frameworks und Normen im IT-Projektmanagement

5.1 V-Modell XT5.2 PRINCE 2

5.2.1 Die 7 Grundprinzipien5.2.2 Themen5.2.3 Überblick: Prozesse von PRINCE25.2.4 Merkmale und Besonderheiten

5.3 PMBOK Guide5.3.1 Grundstruktur und Aufbau5.3.2 Areas of Knowledge5.3.3 Überblick Projektprozesse 5.3.4 Prozesse Phase 1: Vorbereitungsphase5.3.5 Prozesse Phase 2: Planungsphase5.3.6 Prozesse Phase 3: Durchführung5.3.7 Prozesse Phase 4: Einführung5.3.8 Prozesse Phase 5: Abschlussphase


5.1 V-Modell XT

• Das V-Modell XT beinhaltet konkrete, standardisierte Vorgehensweisen. In den einzelnen Vorgehensschritten werden zu erstellende Ergebnisse definiert und hierfür Verantwortlichkeiten zugeordnet. Im Mittelpunkt stehen die Fragen „Wer“ muss „Was“, „Wann“ in einem IT-Projekt machen

(vgl. V-Modell XT, Version 1.2.0 S. 1-3).


Aktuelle Doku zum V-Modell XT

Ziele vom V-Modell XT

• Minimierung der Projektrisiken• Qualitätsverbesserungen • transparente Kostendarstellung• Kommunikation zwischen allen Beteiligten• offen gegenüber Modelländerungen


Grundkonzeption des V-Modells XT

• Systementwicklungsprojekt eines Auftraggebers• Systementwicklungsprojekt eines Auftragnehmers• Einführung und Pflege eines organisatorischen

Veränderungsmodells

5

Den Kern des V-Modells XT bilden die Vorgehensbausteine. Hierbei handelt es sich um selbständig entwickelbare und änderbare Einheiten. Sie bestehen aus Aktivitäten, die sich aus Teilaktivitäten zusammensetzen lassen, aus Produkten, die aus mehreren Themen bestehen können und aus Rollen, die die Verantwortung für einen Entwicklungsteil tragen.

© Prof. Dr. Walter Ruf

Bestandteile von Vorgehensbausteinen

6

Produktgruppe Aktivitätsgruppe

Produkt

Thema

Aktivität

Teilaktivität

1..*

1

*

1

stellt fertig 0/11

bearbeitet ***

1

1..*

1

ist verantwort-lich für

0/1 *

wirkt mit* *

Rolle

„wer“ „wofür“ „was“

ProdukteAktivitäten

Vorgehensbaustein


Produktgliederung

7

Produkte im V-Modell XT

Produktbereich: Projekt (-Managment)

Produktgruppe: Planung und Steuerung

Produkt: Projektfortschritts-entscheidung

Produkt: Projekthandbuch

Produkt: ...

Produktgruppe: Berichtswesen

Produkt: Besprechungsdokument

Produktgruppe: Konfigurations- und Änderungsmanagement

Produkt: Problemmeldung / Änderungsantrag

Produktgruppe: Prüfung

Produkt: Prüfspezifikation Prozess

Produkt: Prüfprotokoll Prozess

Produktgruppe: Ausschreibungs- und Vertragswesen

Produkt: Ausschreibung

Produkt: Vertrag

Produktgruppe: Angebots- und Vertragswesen

Produkt: Angebot

Produkt: Vertrag (von AG)

...

...

...

...

...

Produktbereich: Entwicklung

Produktgruppe: Anforderungen und Analysen

Produkt: Anforderungen (Lastenheft)Produkt: Make-or-Buy-Entscheidung

Produkt: ...

Produktgruppe: Systemelemente

Produkt: SW-Komponente

Produkt: SW-Modul...

Produktgruppe: Systementwurf

Produkt: Systemarchitektur

Produkt: Datenbankentwurf

...

...

Produkt: Implementierungs-, Integrations- und Prüfkonzept SW

Produktgruppe: Logistische Konzeption

Produkt: Spezifikationlogistische Unterstützung...

Produktgruppe: Logistikelemente

Produkt: Nutzungs-dokumentation...

Produktgruppe: Systemspezifikationen

Produkt: Gesamtsystem-spezifikation (Pflichtenheft)

...Produkt: SW Spezifikation

Produktbereich: Organisation

Produktgruppe: Prozessverbesserung

Produkt: Organisations-spezifisches Vorgehensmodell...


Vorgehensbaustein Landkarte

Beim Zuschnitt des V-Modells XT auf genau ein IT-Projekt hin erfolgt eine spezifische Auswahl von Vorgehensbausteinen.


Projektdurchführungsstrategie

Das V-Modell XT ist so flexibel ausgelegt, dass u.a. sowohl das Grundmodell für sequentielle als auch inkrementelle oder evaluative Vorgehensmodelle unterstützt werden können.


Bausteine beim V-Modell XT


Entscheidungspunkte für die Projektdurchführungsstrategie


Anwendungsbeispiel (Strukturierung der Entscheidungspunkte)

12

Abnahmeerfolgt

Lieferungdurchgeführt

Systemintegriert

System-elementerealisiert

Anforde-rungen

festgelegt

Systemspezifiziert

Systementworfen

Feinentwurfabgeschlos-

sen

Verifizierung und ValidierungR

ealisierung und IntegrationS

pezi

fikat

ion

und

Zer

legu

ng


Projektplanung (projektspez. Durchführungsstrategie)

13

Projektdefiniert

Projektbeauftragt

Systemspezifiziert

Systementworfen

Iterationgeplant

Projektgenehmigt

Feinentwurf abgeschlossen

Abnahmeerfolgt

Systemintegriert

Feinentwurfabgeschlossen

Systemelementerealisiert

Projektabgeschlossen

Systemelemente realisiert

Legende:

Alle V-Modell-Projekte

OrganisationsspezifischesVorgehensmodell

AG/AN-Schnittstelle

Systementwicklung

Lieferungdurchgeführt

Angebotabgegeben


V-Modell XT Projektassistent


Tailoring


Festlegung der Entscheidungspunkte


Datenübernahme nach MS-Project


V-Modell XT

• Das V-Modell XT Bund ist eine auf die Bedürfnisse der Behörden angepasste Erweiterung des flexiblen Vorgehensmodell V-Modell XT.

• http://www.cio.bund.de/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html


http://www.cio.bund.de/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html

http://www.cio.bund.de/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html

V-M

odel

l XT

Wer

kzeu

ge

© Prof. Dr. Walter Ruf 19

http://v-modell.iabg.de/index.php?option=com_content&task=view&id=27&Itemid=51




microTOOL


http://www.microtool.de/instep/de/prod_vxt_edition.asp

Filmabruf:http://87.119.196.114/filme/instep/vmodellxt/projektplanung/Projektplanung.html




http://87.119.196.114/filme/instep/vmodellxt/projektplanung/Projektplanung.html




Erfolgsfaktoren – Fallstricke - Praxistipp

• Beginnen Sie kein IT-Projekt ohne Festlegung eines Vorgehensmodells.

• Wählen Sie ein Vorgehensmodell nach den folgenden Kriterien Vollständigkeit, Systematik, Modularität, Allgemeingültigkeit und Anpassbarkeit aus (vgl. Bunse, C.; Knethen, A.: (2002), S. 101).

• Passen Sie das Vorgehensmodell auf das konkrete Projektvorhaben an.

• Sorgen Sie dafür, dass alle Projektbeteiligten (Kunden, Partner, Anwender, Entwickler, …) Kenntnis über das Vorgehensmodell erhalten.

• Das Vorgehensmodell stellt eine wichtige Komponente in der Projektdokumentation dar und kann für spätere IT-Projekte verwendet werden.

• Die Erfahrungen mit einem bestimmten Vorgehensmodell bei einer konkreten Projektumsetzung sind von erheblichem Wert für Folgeprojekte.


5.2 PRINCE2

• PRINCE = Projects in Controlled Environments• Bei PRINCE2 handelt es sich um ein „Vorgehensmodell für das

Projektmanagement, das aus Prozessen, Komponenten, Techniken und einem Phasenmodell besteht.“Linssen, O.; Rachmann, A.: P.: PRINCE2 – ein prozessorientierter Projektmanagementansatz, in: HMD Heft 2008; S. 69.

• basiert auf Erfahrungen (Best Practices)• Copyright-Inhaber: Office of Government Commerce (OGC).

– Entwicklung beginnt bereits im Jahr 1989 (Central Compuer and Telecommunications Agency)

– mehrere Überarbeitungen (letzter Refresh: 2009)Offizielle Seite: http://www.prince-officialsite.com/

– stärkste Verbreitung in Großbritannien


http://www.prince-officialsite.com/

http://www.prince-officialsite.com/

• PRINCE2 basiert auf:1. Grundprinzipien

Durch die Grundprinzipien wird die grundsätzliche Philosophie der Methode festgelegt.

2. ThemenThemen stellen die Bereiche (Aspekte) dar, die während der Projektumsetzung fortlaufend betrachtet werden.

3. ProzessenMit den Prozessen werden Aktivitäten, Produkte und Verantwortlichkeiten definiert.

• Es wird gefordert, dass die Methode auf jedes Projekt hin angepasst werden muss. Die Anpassung geschieht primär bei den Prozessen. Die Grundprinzipien sollen erhalten bleiben.


5.2.1 Die 7 Grundprinzipien

1. Fortlaufende geschäftliche Rechtfertigung (Business Case)Jedes Projekt braucht eine wirtschaftliche Rechtfertigung. Diese sollte am Anfang beschrieben werden – kann sich jedoch während des Projektablaufs ändern.

2. Lernen aus Erfahrung– positive und negative Erkenntnisse dokumentieren. – PRINCE2 fordert die Konservierung der Erkenntnisse– Nutzung von gesammelten Erkenntnissen aus

abgeschlossenen Projekten

3. Definierte Rollen und Verantwortlichkeiten– Unternehmensvertreter („Projekt als Investition“)– Benutzervertreter („Nutzbarkeit der Projektergebnisse“)– Lieferantenvertreter („Bereitstellung von Know-how für die

Umsetzung“)24© Prof. Dr. Walter Ruf

Die 7 Grundprinzipien (Fortsetzung)

• 4. Steuern über Managementphasen– Anzahl Phasen kann frei gewählt werden (mindestens 2 Phasen)– Phasenende stellt einen Entscheidungszeitpunkt dar, in dem

dargestellt wird:• aktueller Projektstatus• Business Case für das Projekt• Pläne für die Weiterentwicklung

• 5. Steuern nach dem Ausnahmeprinzip– „Management by Exception“

• 6. Produktorientierung– Projektergebnisse nennt man Produkte– jedes Produkt gilt es am Anfang klar zu definieren– zu jedem Produkt soll festgelegt werden, wie dessen Vollständigkeit

geprüft werden kann


Die 7 Grundprinzipien (Fortsetzung)

• 7. Anpassung an die Projektumgebung– Tailoring– Anpassung der Prozesse an die Projekterfordernisse

• Anpassung an Projektumfang• Anpassung an Projektgröße / Ausgestaltung

Das Tailoring verhindert eine Projektumsetzung nach einer einzigen Lehrbuchvorlage.


5.2.2 Themen

• Durch 7 Themen sollen die Grundprinzipien „befriedigt“ werden. – Grundprinzipien werden aufgegriffen und konkretisiert. – Themen stellen die Vorstufe für Prozesse dar.

1. Business CaseKonkretisierung des Prinzips „Fortlaufende geschäftliche Rechtfertigung“– Gegenüberstellung von Kosten dem Nutzen– Risikobetrachtung.– Bei Projektänderungen muss der Business Case ggf. neu angepasst

werden.2. Organisation

– Konkretisierung des Prinzips „Definierte Rollen und Verantwortlichkeiten

– Festlegung der Zuständigkeiten der Projektbeteiligten– Festlegung von Verantwortlichkeiten– Festlegung von klaren Kommunikationsstrukturen


Themen (Fortsetzung)

3. Qualität– Konkretisierung des Prinzips „Produktorientierung“ und „Lernen aus

Erfahrung“– Festlegung von Qualitätskriterien in Prduktbeschreibungen

• diese können die Voraussetzung für die Abnahme bilden– Qualitätsmanagement

• Qualitätsplanung, - steuerung, - sicherung– Integration regelmäßiger Retrospektiven

4. Pläne– die Steuerung eines Projektes basiert auf Plänen– Pläne beschreiben „wie, wann und von wem ein oder mehrere Ziele

erreicht werden.“– Plan = Simulation der Zukunft

5. Risiken– jedes Projekt birgt Risiken– Risikobetrachtung ist essenziell für jedes Projekt durchzuführen


Themen (Fortsetzung)

6. Änderungen– Änderungen sollen weder ignoriert noch durchgewunken noch

verloren gehen.– Änderungen sind im Hinblick auf den Business Case zu

beurteilen.

7. Fortschritt– regelmäßiger Vergleich der erbrachten Leistungen im Projekt

mit den Planzielen– dient der geschäftlichen Rechtfertigung


Prozesse

• PRINCE2 unterscheidet 7 Prozesse, die projektspezifisch anzupassen sind.

• Prozessmodell von PRINCE2

30

Wag

ner,

A.;

Zille

r, C

.: IT

-Pro

jekt

man

agem

ent:

klas

sisc

h-ag

il, in

: Kam

mer

er, S

.; La

ng,

M.;

Am

berg

, M.:

IT-P

roje

ktm

anag

mee

nt M

etno

den

– B

est P

ract

ices

von

Scr

um b

is

PR

INC

E2,

201

2; S

. 178


5.2.3 Überblick: Prozesse von PRINCE2

1. Vorbereiten eines Projektes– Soll das Projekt überhaupt gestartet werden?

• Erste Kosten- / Nutzenschätzungen• vorläufiger Business Case• Klärung von Verantwortlichkeiten

2. Initiieren eines Projektes– Konkretisierung des Vorbereitungsprozesses

• Wie soll das Projekt gesteuert werden?• Welche Projektergebnisse können erwartet werden?• Tailoring (Anpassung der Prozesse)

3. Lenken eines Projektes– Unterstützung für den Lenkungsausschuss durch

Bereitstellung von Informationen– Freigabe von Phasenplänen für Folgephase


Überblick Prozesse von PRINCE2 (Fortsetzung)

• Steuern der Phase– „Tagesgeschäft“ eines Projektmanagers– Koordination von Arbeiten– Verwaltung von Risiken und offenen Punkten– Erfassung Projektfortschritt

• Managen eines Phasenüberganges– Arbeiten nach jeder Phase / Verantwortung: Projektmanager– Informationsversorgung für den Lenkungsausschuss– Retrospektive der vorhergehenden Phase

• Managen der Produktlieferung– Erstellung der Projektergebnisse– Maßnahmen zur Qualitätsprüfung– Abnahmedokumentation


5.2.4 Merkmale und Besonderheiten

• Projektmanager trägt die Verantwortung für eine Phase

• die Gesamtverantwortung trägt der Lenkungsausschuss

• die Verantwortung für die Nutzung trägt der Benutzervertreter

• Links: (Templates)http://www.copargo.de/de/downloads/


http://www.copargo.de/de/downloads/

http://www.copargo.de/de/downloads/

Ablauf eines PRINCE2: 2009 Projekts

34http://www.amazon.de/2009-PRINCE2-Projekts-process-PRINCE2-Project-%C3%9Cbersichtsgrafik/dp/3000181962/ref=pd_cp_eb_0


Quelle: http://www.copargo.de/fileadmin/pdf/P2%20Prozesse%20v7_A4%20Kopie.jpg

http://www.copargo.de/fileadmin/pdf/P2%20Prozesse%20v7_A4%20Kopie.jpg



5.3 PMBOK Guide

• PMI = Project Management Institut– Gründung 1969 USA (Atlanta)– mehr als 650.000 Mitglieder– mitgliedstärkste Vereinigung im Bereich Projektmanagement

• PMBOK Guide = Guide to the Project Management Body of Knowledge – weit verbreiteter Projektmanagement-Standard– anerkannt durch: ANSI und IEEE

• PMI führt Zertifizierungen durch– CAPM Certified Associate in PM; PMP Project Management

Professional• In Deutschland findet man Chapter in Berlin, München,

Frankfurt und Köln


PMBOK Guide

• enthält eine Sammlung von „Best Practices“• die Empfehlungen sind generisch aufgebaut und

eignen sich für eine Vielzahl von Projekten– Industrieanlagenbau, Organisationsprojekte

PMBOK Guide kann auch für Softwareentwicklungsprojekte verwendet werden!

„Mit dem PMBOK Guide lassen sich theoretisch auch Softwareprojekte durchführen; ohne eine spezifische Anpassung fällt eine pragmatische, effiziente und effektive Umsetzung jedoch sehr schwer.“ von Brisinski, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; 2010, S. 16

Frameworks gilt es unternehmens- und projektspezifisch anzupassen!


5.3.1 Grundstruktur und Aufbau PMBOK Guide

• PMBOK-Guide kommt ohne Phasenmodell aus


PITPM auf der Basis vom PMBOK-Guide

• PITPM = Praktisches IT-Projektmanagement– Adaption des PMBOK-Guide für

die Softwareentwicklung von N. Spitczok; G. Vollmer: Pragmatisches IT_Projektmanagement; Softwareentwicklungsprojekte auf Basis des PMBOK Guide führen; dpunkt.verlag 2010


5.3.1 Grundstruktur und Aufbau


• Projekte werden in 5 Phasen und 9 Areas of Knowledge eingeteilt

5.3.2 Areas of Knowledge (1)

1. Integrationsmanagement (Project Integration Management)– Integration aller Knowledge Areas (Anforderungen,

Bedürfnisse usw.)– Stakeholder-Management (Koordination aller Personen, die

Einfluss auf das Projekt haben)

2. Inhalts- und Umfangsmanagement (Project Scope Management)– Festlegung und Begrenzung des Projektumfanges

3. Qualitätsmanagement (Project Quality Management)– frühzeitige Integration von Qualitätsaspekten in alle

Teilbereiche des Projektes

4. Kommunikationsmanagement (Project Communication Management)– Kommunikation mit Stakeholdern, Partnern und

Projektbeteiligten© Prof. Dr. Walter Ruf 41

Areas of Knowledge (2)

5. Risikomanagement (Project Risk Management)5. Vermeidung / Bewältigung von Risiken

6. Zeit- und Teammanagement (Project Human Resource Management / Time Management)– Festlegung von Rollen– Erstellung eines Projektplanes

7. Beschaffungsmanagement (Project Procurement Management)– Beschaffung von externen Ressourcen und Materialien

8. Kostenmanagement (Project Cost Management)– Kostenschätzungen– Einhaltung von Projektbudgets

9. Softwareentwicklungsmanagement (gibt es im PMBOK-Guide nicht)– Einbindung der Prozesse der Softwareentwicklung in das PM


PITPM-Projektphasen (1)

1. Vorbereitungsphase– Projektauftrag– Definition Projektumfang– erste Risikoeinschätzung– …

2. Planungsphase– Konfiguration des Projektes (Managementplan)– Detailplanung des Projektes (Umsetzung der Anforderungen

in einen realen Plan)– Iterationsplanung– …

3. Durchführungsphase– Umsetzung des Projektes– Steuerung der Prozesse

© Prof. Dr. Walter Ruf 43vgl. Spitczok, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; S. 30

PITPM-Projektphasen (2)

4. Einführung– Planungen für den Produktivbetrieb– Rollout des Produktes

5. Abschlussphase– formeller Projektabschluss– Abschluss der Verträge– Dokumentation der Erkenntnisse


vgl. Spitczok, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; S. 31

PITPM-Projektkontrollpunkte

• Kontrolle wird als ein eigener Prozess verstandenK1: Projektauftrag erteiltK2: Projekt konfiguriertK3: Projektplanung abgenommenK4: Planung der Iterationen abgenommenK5: Bereitstellung zur AbnahmeK6: Abnahme erteiltK7: ProduktionsstartK8: Projektende


5.3.3 Überblick Projektprozesse (Hauptprozesse)


5.3.3 Überblick Projektprozesse

© Prof. Dr. Walter Ruf 47http://pitpm.net/index.php/poster: Abruf am 2.2.2013

http://pitpm.net/index.php/poster



http

://pi

tpm

.net

/inde

x.ph

p/po

ster

: Abr

uf a

m 2

.2.2

013

Zuordnung von Artefakten zu Prozessen und Phasen



5.3.4 Prozesse Phase 1: Vorbereitungsphase V.1 Projektumfang bestimmen

• V.1.1 Leistungsumfang bestimmen– Projekt- und Produktziele festlegen– Produktabnahmekriterien festlegen– …– Eingangsartefakte

• Vom Auftraggeber bereitgestellte Dokumente

– Methoden, Techniken, Werkzeuge• Erhebungsmethoden; Workshop;

– Ergebnisartefakte• Projektumfangsbeschreibung

(Projektumfangsbeschreibung.docx)

• V.1.2 Risiken identifizieren– Eingangsartefakt: Projektumfangsbeschr.– Ergebnisartefakt: Risikoregister


Übung

Prozess V1: Projektumfang bestimmen (2)

• V 1.3. Aufwand abschätzen– Grobschätzungen (+/- 50% Genauigkeit)– Feinschätzungen (+/- 5-10% Genauigkeit)

• Methoden zur Aufwandschätzung– im PMBOK wird auf PERT-Schätzung hingewiesen:

– Schätzklausur, Analogieschätzung• Ausgangsartefakt

– Aufwandschätzung


Prozess V2: Projekt beantragen

• Prozessüberblick


Spi

tczo

k, N

.; Vo

llmer

, G.:

Pra

gmat

isch

es IT

-Pro

jekt

man

agem

ent;

S. 5

2

Prozess V.2.1: Projektauftrag entwickeln

• Festlegung einer Directorystruktur• Checkliste zur Projektinitialisierung• Ergebnisartefakt: Projektauftrag

(Weiterentwicklung)


Übung

5.3.5 Prozess Phase 2: Planungsphase

• Spezifikation des Endproduktes• Erstellung Projekthandbuch• Entwicklung PSP (Projektstrukturplan) • Verfeinerung der Risikoanalyse

• Die Planungsphase ist für das Projektmanagement die arbeitsaufwändigste Phase. Es gilt die Prozesse für das Endprodukt festzulegen.


Prozess P.1.1 Projektorganisation festlegen

• Klärung Projektmitglieder und Organisationsstruktur


Maitre = Titel von dem Namen einer AmtspersonMaît|re* de Plai|sir der bei einer Veranstaltung das Unterhaltungsprogramm arrangiert u. leitet, der bei einem Fest für die Unterhaltung der Gäste sorgt.

Prozess P.1.2 Kick-off-Veranstaltung

• Treffen mit allen Projektteilnehmern– Projektteam, Linienstellen,

Serviceorganisation, …• Zwecke

– Klärung Projektziel /-zeitraum– Meilensteine– Sponsoren– Vorstellung Projektteilnehmer– …

• Ergebnisartefakt: Protokoll Kick-off-Workshop


Übung

Prozess: P1.3 Projektmanagementplan entwickeln

• Scope Management Plan• Requirement Management Plan• Schedule Management Plan (PSP)• Cost Management Plan• Human Resource PlanErgebnisartefakte• Projektmanagementplan


Prozess P.2 Anforderungsmanagement konfigurieren

• Ziel: Festlegung von Vorgaben für die Durchführung der Anforderungsanalyse

• Festlegung der Infrastruktur für die Entwicklung

• Prozess: P 2.1 Anforderungsanalyse planen– Beschreibung von

Anwendungsfällen (Use Cases)

• Anwendungsfälle beinhalten eine Sammlung von Aktionen

oft ist es schwierig in einer frühen Projektphase die Anwendungsfälle vollständig zu beschreiben


Prototypingmodell

Spitczok, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; S. 68

Bei der Festlegung der Infrastruktur für die Entwicklung geht es z.B. auch um die Definition der Entwicklungstools.Anforderungsanalyse = Requirement Engineering (Festlegung der qualitativen und quantitativen Anforderungen aus der Sicht des Auftraggebers)Als Endergebnis wird ein Anforderungsdokument erstellt, das später Teil vom Pflichtenheft wird.

Prozess P.2.2 – 3.2

• P 2.2: Änderungsanforderungen definieren– Wie geht man mit Änderungsanforderungen um?

• Bereitstellung von Rechner, Betriebssystem, Netzwerk, Zugänge• P 3: Qualitätsplanung konfigurieren

– P.3.1 Qualitätsplan erstellen• Festlegung von konkreten Qualitätsstandards und deren

Umsetzung• Ergänzung des Projektplanes um das Kapitel „Qualitätsplanung“

– P.3.2 Testkonzept erstellen• Im Testkonzept wird beschrieben, welche Systembestandteile zu

welchem Zeitpunkt wie zu testen sind.• Basis ist das Anfoderungsdokument

Das Ergebnis wird in einem Testkonzept festgehalten.


Änderungsanforderungen wird es im Projektverlauf mit hoher Wahrscheinlichkeit geben.

Prozess P.4 – P.6

• P.4 Kommunikationsplanung– „Wie soll mit den Stakeholdern kommuniziert werden?“

• Das Ergebnis wird im Projektmanagementplan festgehalten.

• P.5 Risikoplanung konfigurieren– Klärung von Prinzipien und Regeln für das

Risikomanagement– Reporting festlegen


• P.6 Beschaffungsplanung konfigurieren– Planung von Waren- und Dienstleistungsbeschaffung



Übung

Prozesse P.7 – 7.2

• P.7 Softwareentwicklung konfigurieren • P. 7.1 Auswahl des Prozessmodells für die Entwicklung

• reine phasenorientierte Vorgehensmodelle sind problematisch– iterative Vorgehensmodelle – agile Vorgehensmodelle Auswahl eines Prozessmodells und Festlegung der dazu

notwendigen Aktivitäten Das Ergebnis ist ein projektspezifisches Vorgehensmodell!

• P.7.2 Bereitstellung der Softwareentwicklungswerkzeuge – Identifikation, Beschaffung, Installation und Bereitstellung von allen

für die Entwicklung erforderlichen Tools• DBMS, Testwerkzeuge, SES


„Einfaches – strikte“ phasenorientiertes Vorgehensmodell sind ineffizient und nicht praktikabel, da keine zusätzlichen oder veränderten Anforderungen berücksichtigt werden können.

Prozess P.8: Anforderungen spezifizieren

• Erhebung – Bestimmung und Beschreibung von Anforderungen ist die Basis für eine erfolgreiche Entwicklung!

• P.8.1 Fragebogen für die schriftliche Befragung– Was wollen die „Kunden“

• Wer ehrliche Antworten will, sollte Vertraulichkeit zusichern• übersichtlich gestaltete Fragebogen• Fortschrittskennzeichnung• Raum für individuelle Hinweise

• P.8.2 Qualitätssicherung des Fragebogens– Verständlichkeit der Fragen – „Test“ eines Fragebogens– Ergebnis: Fragebogen für eine schriftliche Befragung

• An Stelle einer schriftlichen Befragung können auch Interviews durchgeführt werden.

• P.8.3 Schriftliche Befragung durchführen• P.8.4 Interviewleitfasen erstellen• P.8.5 Qualitätssicherung des Interviewleitfadens

durchführen• P.8.6 Interviews durchführen / protokollieren


Übung

Prozess P.8: Anforderungen spezifizieren (2)

• P.8.7 Analyse unternehmensspezifischer Arbeits- und Geschäftsprozesse– Darstellung der vorhandenen Abläufe und der neuen, geplanten

Abläufe (z.B. mit eEPK-Diagrammen)• P.8.8 Anforderungsdokument erstellen

– man unterscheidet:• funktionale Anforderungen (z.B. Stammdatenerfassung)• nicht funktionale Anforderungen (z.B. Aussehen und Handhabung,

Antwortzeitverhalten, Erweiterbarkeit, …)– GUI-Entwürfe

• Entwürfe zur grafischen Benutzeroberfläche sollten frühzeitig den späteren Usern vorgestellt werden.

• P.8.9 Qualitätssicherung des Anforderungsdokuments• P.8.10 Testfälle erstellen• P.8.11 Abnahmetestfälle erstellen


Das Ziel ist es ein vollständiges Dokument mit allen aktuell bekannten Anforderungen zu erstellen. (In SCRUM bezeichnet man dieses Dokument als Product Backlog.)

Prozess P.8: Anforderungen spezifizieren (3)

• P.8.12 Erster Projektstrukturplan– PSP = Projektstrukturplan (work breakdown structure)– PSP ist die Basis für

• Kostenermittlung im Projekt• erforderlicher Arbeitseinsatz• Liefergegenstände• …

– PSP kann iterativ entwickelt werden – Hierarchische Gliederung ist ratsam– PSP enthält die Arbeitspakete aus der Anforderungsdefinition

(Anforderungskokument) Werkzeug Projectmanagement Software (z.B. MS-Project)

P.8.13 Anforderungsdokumentation abnehmen


P.9 Risikobewältigung starten

P.9.1 Risiken identifizieren P.9.2 Risiken bewerten und priorisieren

– Ergebnisartefakt: Ergänzung Risikoregister

P.9.3 Maßnahmen zur Risikobewältigung

– Strategie: Vermeidung – Übertragung – Minderung - Annahme


Prozess: 10 Projektplan erstellen

• Plan für das Gesamtprojekt• Meilensteine (für Releasestände; Präsentationen; Iterationen)P.10.1 Aufgaben aufstellen und in PSP eingliedernP.10.2 Ressourcen planen

– jedes Arbeitspaket wird später von einem MA verantwortet– Ermittlung der Vorgangszeiten (frühester Anfang/Ende; spätester

Anfang/Ende)– Ermittlung vom kritischen Pfad


Prozess: 10 Projektplan erstellen

• P10.3 Projektplan umsetzen– Empfehlungen

• sprechende Namen für die Arbeitsgänge• realistische Zeitschätzungen• Übersichtlichkeit• Granularität (auf der untersten Ebene sollten Arbeitspakete

gebildet werden)– Vorschlag: Dauer für ein Arbeitspaket ca. 2 – 7 Tage– Vorschlag: keine Überstundenplanung / keine Wochenendarbeit

– Ergebnis: Ganzheitlicher Projektplan


Übung

Prozess: P.10.4 – P.13

• P.10.4 Projektteam aufstellen• P.10.5 Projektteam formen und entwickeln

– ggf. Schulungsmaßnahmen planen• P.11 Beschaffung planen

– Zuordnung von Beschaffungsmaßnahmen (wie externer Berater; Lizenzen, Versicherungen) zu Vorgängen und deren zeitliche Festlegung

• P.12 Kostenplanung initialisieren– Voraussichtliche Projektkosten ermitteln

• Kostenverlaufsplan erstellen• P.13 Iterationen planen

– Anforderungen an Iterationen festlegen• Festlegung der Iterationsinhalte• mehrere Iterationen führen zu einem auslieferbaren Release


Prozess P.14 Softwareentwicklung für aktuelle Iteration planen

• Voraussetzung für iterative / agile Softwareentwicklung – P.14.1 Spezifikation erstellen

• Ergebnisartefakt: Spezifikationsdokument GUI-Modell– P.14.2 Qualitätssicherung der Spezifikation – P.14.3 Spezifikation abnehmen und freigeben– P.14.4 Entwurf erstellen– P.14.5 Qualitätssicherung des Entwurfsdokuments

durchführen– P.14.6 Entwurf abnehmen und freigeben


5.3.6 Prozesse Phase 3: Durchführung


Spi

tczo

k, N

.; Vo

llmer

, G.:

Pra

gmat

isch

es IT

-Pro

jekt

man

agem

ent;

S. 1

52

Prozess: D.1- D.2

• D1 Projekt steuern– D.1.1 Projekt führen

• Durchführung von Iterationen stehen im Mittelpunkt• Projektmanager hält die für den Kunden wichtigen

Ereignisse im Projektlogbuch fest– D. 1.2 Projektverlauf überwachen und steuern

• Vergleich der Istwerte mit dem Projektplan• Führung der Liste „Offene Punkte“

• D.2 Projektumfang kontrollieren und anpassen– D.2.1 Projektumfang verifizieren

• Die einzelnen gelieferten Teilergebnisse sollen vom Kunden abgenommen werden

• Ergebnisartefakt: Erkannter Änderungsbedarf– D.2.2 Change Request verfassen

• anerkannte Änderungsbedarfe führen zu einer Änderungsanforderung einem „Change Request“ (CR)(nur wenn dadurch zusätzliche Kosten und Entwicklungszeitänderungen entstehen)


Prozess D.3 Produktqualität kontrollieren

• zu jedem Iterationsschritt gehören abschließende Tests

• D.3.1 Testplan erstellen– Beispiele: Komponententest; Integrationstest;

Schnittstellentest; Lasttest, Systemtest, Abnahmetest• D.3.2 Tests durchführen

– Ergebnisartefakt: Testprotokoll• D.3.3 Test dokumentieren


Prozess D.4 Projektkommunikation

• D.4.1 Stakeholder einbeziehen und informieren– Stakeholder haben maßgeblichen Einfluss auf das Projekt– Tipp: Transparenz schaffen – Vertrauen gewinnen

Probleme nicht verschleppen oder verschleiern!• D.4.2 Projektstatusbericht erstellen

– Inhalt: erledigte / offene Punkte; Risiken; Ressourcenverbrauch; erreichte Meilensteine;

– Ergebnisartefakt: Statusbericht


Übung

Prozess D.5 Risiken überwachen

• D.5.1 Bestehendes Risikoregister abgleichen und ergänzen– ggf. Risikoworkshop durchführen– Ergebnisartefakt: aktualisiertes Risikoregister

• D.5.2 Maßnahmen zur Risikobewältigung planen


Prozess D.6: Projektteam steuern

• Erstellung dedizierter Arbeitsauftrage für jedes Teammitglied– Integration von jungen Projektmitgliedern ins Team– Rücksicht auf unterschiedliche Charaktere

• D.6.1 Zusammenstellung von Entwicklungsteams• D.6.2 Teammitglieder ein uns ausplanen

– Vorsicht bei der Speicherung personenbezogener Daten! (ggf. Abstimmung mit Mitarbeitervertretung)

• D.6.3 Arbeitsaufträge für Teammitglieder erstellen– Arbeitsaufträge können z.B. aus MS-Project heraus

generiert werden.– Inhalt von Arbeitsaufträgen: Bezeichnung; Abgrenzung;

Voraussetzung; Besondere Risiken; Arbeitsunterlagen


Übung

Prozess D.7 Externe Leistungen kontrollieren

• in vielen Projekten benötigt man externe Leistungen – z.B. Formulierung von Allg. Geschäftsbedingungen durch

einen Juristen; Installation von Glasfaserkabel durch Elektriker

• D.7.1 Externe Leistungen kontrollieren• D.7.2 Externe Leistungen abrechnen• D.7.3 Vertrag kündigen

– sofern die Leistung des externen Dienstleisters nicht mehr benötigt wird

• D.7.4 Dienstleister bewerten


Prozess D.8 Projektkosten kontrollieren

• Kostenkontrolle ist eine zentrale Aufgabe des PM• D.8.1 Projektkosten erfassen

– Nur mit den erfassten Kosten ergibt sich noch keine Projektkontrolle!

– Zur Projektbewertung benötigt man noch den Fertigstellungsgrad.

– Soll-/ Istvergleich erfolgt über den Projektplan• D.8.2 Projektkosten aktualisieren


Prozess: D.9 Softwareprodukt entwickeln

• D.9.1 Software implementieren– Quellcode wird erzeugt

• D.9.2 Softwarekomponenten testen• D.9.3 Softwarekomponenten integrieren • D.9.4 Softwareprodukt testen


Spi

tczo

k, N

.; Vo

llmer

, G.:

Pra

gmat

isch

es IT

-Pro

jekt

man

agem

ent;

S. 1

88

Prozess D.10 Abnahmetest durchführen

• vertragliche Regelungen zur Abnahme vorsehen!

• D.10.1 Abnahmebereitschaft erklären– PM muss dem Auftraggeber gegenüber die

Abnahmebereitschaft erklären– Teilabnahmen, Ersatz für nicht

durchgeführte Abnahmen usw.• D.10.2 Abnahmetest koordinieren• D.10.3 Abnahmetest durchführen• D.10.4 Abnahme erklären• D.10.5 Liefergegenstand nachbessern


Übung

5.3.7 Prozesse Phase 4: Einführung

• Die Einführung eines neuen Softwaresystems muss gut geplant werden. – Parallelbetrieb zur bestehenden Lösung– sukzessive Einführung

• Rollout Zeitfenster festlegen– Umstellung zu einem Zeitpunkt

• Planung der Schulung für Key-User• E.2 Produkt einführen

– Übernahme der Verantwortung geht auf den Kunden über


Prozess E.2 Produkt einführen

• E.2.1 Produkt einführen– Übernahme der Verantwortung geht auf den Kunden über

• E.2.2 Produktverantwortung abgeben


5.3.8 Prozesse Phase 5: Abschlussphase

• Formelle Beendigung des Projektes• Projektabschlussberichte / Zusammenfassung der

Dokumente• A.1 Projekt abschließen• A.2 Risikoregister schließen• A.3 Teammitglieder ausplanen

– Teammitglieder in neue Organisationsform überführen– Projektabschlussworkshop durchführen– Verträge beenden– Projektkostenrechnung abschließen– Abschlussbericht und Feedback erstellen– Entwicklungsprozess bewerten


Bewertung PMBOK-Guide

• Vorteile– umfassender, weit verbreiteter Standard– regelmäßige Anpassung und Überarbeitung– gut nachvollziehbare Umsetzung von Projekten– hohe Granularität der Prozesse– anerkannter Standard (IEEE; ANSI)

• Nachteile– durch die breite Anwendbarkeit besteht ein hoher

Tailoringaufwand für die konkrete Projektanpassung– beinhaltet keine PM-Methodik– geringe Flexibilität im Vergleich z.B. zu PRINCE2– hoher Administrationsaufwand– Phasenmodell muss zusätzlich erstellt werden– keine Dokumentenvorlagen vom PMI


IPMA

• IMPA International Project Management Association

• In Deutschland hat IPMA mit der GMP eine höhere Popularität als das PMI.


Interessante Links

• Deutsche Gesellschaft für Projektmanagement (GPM)– http://www.gpm-ipma.de/startseite.html

• GPM-Blog– http://gpm-blog.de/

• OpenPM (Verein für Projektmanagement)– https://www.openpm.info/dashboard.action

• PMI Deutschland– http://www.pmigc.de/

• Projektmanagement Blog– http://www.pm-handbuch.com/


http://www.gpm-ipma.de/startseite.html

http://www.gpm-ipma.de/startseite.html

http://gpm-blog.de/

http://gpm-blog.de/

https://www.openpm.info/dashboard.action

https://www.openpm.info/dashboard.action

http://www.pmigc.de/

http://www.pmigc.de/

http://www.pm-handbuch.com/

http://www.pm-handbuch.com/

Documents

Projektmanagement 5. Frameworks und Normen im IT- Projektmanagement Dozentenversion!!! 1 © Prof. Dr. Walter Ruf