Projektbericht - wuecampus2.uni-wuerzburg.de · K1 Keine laufenden Kosten während der Entwicklung...

Projektbericht

Planung und Realisierung des innovativen und erfolgreichen Internet-Unternehmens

Projektteam 4:

Moritz Albert

Pascal Becker

Ann-Kathrin Kraft

Robert Schmauder Hauke Thorenz

Erstellt im Rahmen der Vorlesung

„Professionelles Projektmanagement in der Praxis“, SS 14

Prof. Dr. P. Tran-Gia Prof. Dr. H. Wehnes

Julius-Maximilians-Universität Würzburg

Projektbericht Stand: 4.7.14

Universität Würzburg Professionelles Projektmanagement in der Praxis Seite 2 von 44

Inhaltsverzeichnis

1. Projekt / Projektziele ........................................................................................................... 4

1.1 Projektbeschreibung .................................................................................................... 4

1.2. Zielbeschreibung .......................................................................................................... 7

2. Projektumfeld, Stakeholderanalyse .................................................................................. 14

2.1 Projektumfeldanalyse, Umfeldfaktoren ..................................................................... 14

2.2 Stakeholder (Interested Parties) ................................................................................ 15

3. Risikoanalyse ..................................................................................................................... 19

3.1 Erfassung, Klassifizierung und Beschreibung der Risiken .......................................... 20

3.2 Quantitative Bewertung der Risiken und Maßnahmen zur Risikobegegnung .......... 21

4. Projektorganisation ........................................................................................................... 24

4.1 Organisationsform des Projektes ............................................................................... 24

4.2 Kommunikation.......................................................................................................... 25

5. Phasenplanung .................................................................................................................. 29

5.1 Beschreibung der Projektphasen und der Meilensteine ........................................... 29

5.2 Veranschaulichung der Projektphasen ...................................................................... 31

6. Projektstrukturplan ........................................................................................................... 32

6.1 Darstellung und Codierung des PSP........................................................................... 32

6.2 Arbeitspaketbeschreibung ......................................................................................... 35

7. Ablauf- und Terminplanung .............................................................................................. 37

7.1 Vorgangsliste .............................................................................................................. 37

7.2 Vernetzter Balkenplan oder berechneter Netzplan ................................................... 38

8. Einsatzmittel- / Kostenplanung ......................................................................................... 39

8.1 Einsatzmittelbedarf / Einsatzmittelplan .................................................................... 39

8.2 Projektkosten ............................................................................................................. 41



Abbildungsverzeichnis Abbildung 1: Projektsteckbrief ................................................................................................................ 7 Abbildung 2: Zielhierarchie .................................................................................................................... 11 Abbildung 3: Zielbeziehungsmatrix ....................................................................................................... 12 Abbildung 4: Stakeholder-Portfolio ....................................................................................................... 18 Abbildung 5: Der Prozess des Risikomanagements ............................................................................... 19 Abbildung 6: Graphische Darstellung der Projektorganisation ............................................................. 24 Abbildung 7: Grafische Darstellung der Projektphasen (grob) .............................................................. 31 Abbildung 8: Gemischtorientierter PSP für das Projekt Tokana ............................................................ 34 Abbildung 9: Ressourcen-Histogramm .................................................................................................. 40 Abbildung 10: Kostengang ..................................................................................................................... 42 Abbildung 11: Kummulierte Kosten ....................................................................................................... 42 Abbildung 12: Kostenarten .................................................................................................................... 43 Abbildung 13: Kostenstatus ................................................................................................................... 43 Abbildung 14: Kostenart ........................................................................................................................ 44

Tabellenverzeichnis Tabelle 1: Zieltabelle ................................................................................................................................ 8 Tabelle 2: Detailbetrachtung der Projektziele ....................................................................................... 13 Tabelle 3: Nicht-Ziele von Tokana .......................................................................................................... 13 Tabelle 4: Projektumfeld ........................................................................................................................ 14 Tabelle 5: Umfeldschnittstellen-Matrix (soziale Einflussfaktoren) ........................................................ 15 Tabelle 6: Stakeholdermatrix ................................................................................................................. 17 Tabelle 7: Identifiziert Hauptrisiken – Tokana ....................................................................................... 20 Tabelle 8: Quantitative Risikobewertung und Maßnahmenbeschreibung ............................................ 22 Tabelle 9: Quantitative Maßnahmenbewertung und -entscheidung .................................................... 22 Tabelle 10: Maßnahmenplanung ........................................................................................................... 23 Tabelle 11: Funktionen der Beteiligten .................................................................................................. 25 Tabelle 12: Kommunikationsplan von Tokana ....................................................................................... 28 Tabelle 13: Phasenplan des Tokana-Projekts ......................................................................................... 30 Tabelle 14: Meilensteinplan des Tokana-Projekts ................................................................................. 31 Tabelle 15: Arbeitspaket Coupon .......................................................................................................... 35 Tabelle 16: Arbeitspaket Storyboard ..................................................................................................... 36 Tabelle 17: Vorgangsliste – Tokana ........................................................................................................ 37 Tabelle 18: Vernetzter Balkenplan - Tokana .......................................................................................... 38 Tabelle 19: Rollen .................................................................................................................................. 39 Tabelle 20: Ressourcenverteilung .......................................................................................................... 40 Tabelle 21: Kostenplan........................................................................................................................... 41



1. Projekt / Projektziele

1.1 Projektbeschreibung

Die Projektbeschreibung fasst alle wesentlichen und relevanten Merkmale eines Projektes in

kompakter und nachvollziehbarer Form zusammen.

Tokana ist ein innovatives, webbasiertes Wertmarkensystem. Mit Tokana erfolgt die

Bezahlung bzw. der Kauf von Getränken und Speisen auf Veranstaltungen, Festivals und

privaten Feiern unkompliziert und schnell. Über ein Webportal können Veranstalter Events

erstellen und öffentlich promoten bzw. nur einem ausgewählten Besucherkreis zugänglich

machen. Die Besucher können über mehrere, in das System integrierte, Bezahldienste (u.a.

PayPal) bereits im Vorfeld der Veranstaltung digitale Wertmarken erwerben, welche

anschließend gegen Produkte (z.B.: Getränke, Speisen) eingelöst werden können. Dies erfolgt

bequem über das Scannen eines generierten QR-Codes auf einem Smartphone des

Besuchers durch das Veranstaltungspersonal. Nicht verwendete Wertmarken können

jederzeit mit einem Tastendruck umgetauscht werden. Dazu wird automatisch der jeweilige

Geldbetrag auf das hinterlegte Konto (z.B.: PayPal-Konto) zurücküberwiesen. Zusätzlich zeigt

das Webportal unter anderem Statistiken über bereits ausgegebene, bzw. eingenommene

Geldbeträge an.

Rollenbeschreibung

Zu Beginn des Projektes wird vom Team ein Projektleiter bestimmt. Dieser ist maßgeblich für die Organisation und Leitung des Projekts verantwortlich. Darüber hinaus ist er mit der Festlegung von priorisierten Projektzielen, sowie der Sicherstellung des Erreichen selbiger durch die Festlegung und Verteilung von Projektressourcen (Personal und Arbeitsmittel), die Kommunikation mit den Projektpartnern, sowie die Klärung von Konflikten im Projektteam betraut. Die Rolle des Projektleiters rotiert beim Projekt Tokana unter allen Projektteammitgliedern in einem zweiwöchigen Turnus. Die genauen Zeiträume können dem Projektsteckbrief entnommen werden. Das Projekt wird ohne externen Auftrag durch das im Projektsteckbrief genannte Projektteam in Eigenregie durchgeführt. Es existieren somit im vorliegenden Fall keine externen Projektauftraggeber.

Projektsteckbrief

Der Projektsteckbrief fasst in einer übersichtlichen und knappen Form die wichtigsten Projektdaten zusammen. Somit kann ein schneller Überblick über das Projekt gewonnen werden. Aufgelistet werden der Projektname und -logo, die Projektbeschreibung, das Projektstart- und Projektendereignis, sowie Projekttermine, Projektziele, Projektphasen, Projektmitglieder, Projektleiter, Projektauftraggeber, Projektressourcen und benötigte Projektmittel. Der Projektsteckbrief des Tokana-Projekts ist auf den folgenden Seiten dargestellt.



PROJEKT STECKBRIEF

Projektname Tokana (vorläufiger Arbeitstitel) Abgeleitet von „Token“ (Bon, Wertmarke)

Projektlogo

Kurzbeschreibung des Projekts (Inhalt / Zweck)

TOKANA ist ein innovatives, webbasiertes Wertmarkensystem. Mit TOKANA erfolgt die Bezahlung bzw. der

Kauf von Getränken und Speisen auf Veranstaltungen, Festivals und privaten Feiern unkompliziert und

schnell. Über ein Webportal können Veranstalter Events erstellen und öffentlich promoten bzw. nur einem

ausgewählten Besucherkreis zugänglich machen. Die Besucher können über mehrere, in das System

integrierte, Bezahldienste (u.a. PayPal) bereits im Vorfeld der Veranstaltung digitale Wertmarken

erwerben, welche anschließend gegen Produkte (z.B.: Getränke, Speisen) eingelöst werden können. Dies

erfolgt bequem über das Scannen eines generierten QR-Codes auf einem Smartphone des Besuchers durch

das Veranstaltungspersonal. Nicht verwendete Wertmarken können jederzeit mit einem Tastendruck

umgetauscht werden. Dazu wird automatisch der jeweilige Geldbetrag auf das hinterlegte Konto (z.B.:

PayPal-Konto) zurücküberwiesen. Zusätzlich zeigt das Webportal unter anderem Statistiken über bereits

ausgegebene, bzw. eingenommene Geldbeträge an.

Projektziele

Erstellung eines funktionsfähigen (horizontalen) Prototyps zur Demonstration der Funktionsweise und der zentralen Funktionen der Webanwendung

Geldtransfer auf Veranstaltungen optimieren (Ablauf, Geschwindigkeit)

Portal + App helfen beim Vermeiden von Warteschlagen

Visualisieren von Einnahmen / Ausgaben (Statistiken für Veranstalter + Kunden → mehr Transparenz)

Evtl. zusätzliche Features (Achievements, Gamification, Promotion...)

Projektstarttermin 14.04.2014

Projektendtermin 07.07.2014



Meilensteine

Projektstart 14.04.

Recherche der Marktsituation 23.04.

Zieldefinition und Anf.-Analyse 24.04.

Pflichtenheft erstellt 04.05.

Aufgabenblock 1 fertig 12.05.



Zusammenführung Module 23.06.

Funktionsfähigkeit gewährl. 30.06.

Vorbereitungen Abschl. Fertig 07.07.

Abgabe Projektb. / Abschluss 07.07.

Projektressourcen und -kosten

Teilweise werden mehrere Funktionen von einer Person übernommen.

Ressourcenart Mengen-einheit

Kosten (€)

Programmierer 2 Personen -

UX-Designer 4 Personen -

Server-Admin 1 Person -

Projektauftraggeber

Prof. Dr. H. Wehnes

Kunde / Nutzer

Veranstalter (Events, Feiern...)

Besucher der Events

Projektleiter

Zeitraum Name

07.04. - 20.04. Hauke Thorenz

21.04. - 04.05. Moritz Albert

05.05. - 18.05. Robert Schmauder

19.05. - 01.06. Pascal Becker

02.06. - 15.06. Ann-Kathrin Kraft

16.06. - 29.06. Ann-Kathrin Kraft

30.06. - 07.07. Hauke Thorenz

Teammitglieder

Name Studiengang

Moritz Albert Human-Computer-Interaction

Pascal Becker Human-Computer-Interaction

Ann-Kathrin Kraft Human-Computer-Interaction

Robert Schmauder Luft- und Raumfahrt-Informatik

Hauke Thorenz Human-Computer-Interaction



Voraussichtliche Behinderungen / Störungen

Urlaubsbedingte / Terminbedingte Ausfälle einzelner Teammitglieder

Krankheitsbedingte Ausfälle einzelner Teammitglieder

Klausuren und andere studiums-relevante Verpflichtungen der Teammitglieder

Schwierigkeiten bei der Implementierung und Gewährleistung sicherheitsrelevanter Bestimmungen bzw. Datenschutzbestimmungen

Abbildung 1: Projektsteckbrief

1.2. Zielbeschreibung

Ein Projektziel ist definiert (DIN 69901-5:2009), als die Gesamtheit an Einzelzielen, die durch das Projekt erreicht werden sollen, bezogen auf Projektgegenstand und Projektablauf. Klare Zielformulierungen und Zielsetzungen sind für den Projekterfolg unabdingbar. Sie besitzen fünf grundlegende Funktionen:

Kontrollfunktion: Projekterfolg wird überprüfbar; Zielabweichungen lassen sich früh erkennen.

Orientierungsfunktion: "Road Map" des Projekt; Korrektur falscher Erwartungen; alles wissen „wo die Reise hingeht“

Verbindungsfunktion: Mitarbeitermotivation durch Einbindung in Zielformulierungen. „Wir“-Gefühl wird gestärkt

Koordinationsfunktion: Zielprioritäten erleichtern Koordination der einzelnen Projekttätigkeiten

Selektionsfunktion: Entscheidungen im Projektverlauf werden erleichtert Um diese Funktionen in bestmöglichem Umfang zu erfüllen, sollten Ziele "SMART" formuliert werden. Dies bedeutet, dass Ziele nach folgenden Kriterien formuliert sein sollten:

Spezifisch: Was soll erreicht werden? Ziele sollen präzise und wenn möglich positiv formuliert sein.

Messbar: Welches sind die Messkriterien? Zielmaßstab um das Erreichen eines Ziels mess- und kontrollierbar zu machen.

Attraktiv: Ziele sollen anspruchsvoll und herausfordernd formuliert sein. Gleichzeitig kann das „A“ aber auch für "aktiv beeinflussbar" stehen, was bedeutet, dass durch eine Verschiebung der zur Verfügung stehenden Ressourcen die Erreichung eines Ziels beeinflusst werden kann.

Realisierbar: Ziele sollen immer so formuliert werden, dass sie unter den gegebenen Umständen und mit den vorhandenen Ressourcen erreicht werden können.

Terminiert: Eine Frist setzen, bis zu der die Ziele erreicht werden sollen. Ggf. kann auch eine ergänzende Vereinbarung von terminierten Zwischenzielen formuliert werden.

Projektziele können unterschiedlich kategorisiert und priorisiert werden. Prinzipiell unterscheidet man zwischen Ergebniszielen (Ziele, die am Ende des Projektes erreicht sein



sollen; z.B.: Lieferobjekte in einer bestimmten Qualität) und Vorgehenszielen (Ziele, die im Projektverlauf erreicht werden sollen; z.B.: Zufriedene Projektmitarbeiter). Darüber hinaus kann eine Priorisierung in Muss-, Soll- und Kann-Zielen erfolgen:

Muss: Ziele, die vollständig erreicht werden müssen, sonst scheitert das Projekt.

Soll: Ziele, die weitestgehend erreicht werden sollen, sonst scheitert das Projekt.

Kann: Wünschenswerte Ziele, Projekt scheitert bei Nicht-Erfüllung nicht. Klassifiziert werden Projektziele grundsätzlich in vier Kategorien:

Terminziele: Ziele, die terminlichen Charakter besitzen (z.B.: Projektstart erfolgt)

Kostenziele: Ziele, die finanziellen Charakter besitzen (z.B.: Einhaltung eines best. Budgets)

Leistungszeile: Ziele, die leistungsorientierten Charakter besitzen (z.B.: Gute Umfrageergebnisse)

Soziale Ziele: Ziele, die sozialen Charakter besitzen (z.B.: Keine Überstunden) Bei der Zielentwicklung sollte generell nach folgendem Prinzip vorgegangen werden: Ziele sammeln und formulieren, Ziele clustern und priorisieren, Gegenseitige Beeinflussung von Zielen analysieren und Zielkonflikte erkennen (Zielbeziehungsmatrix), Nicht-Ziele benennen, Ziele messbar machen, Ziele mit Team und Auftraggeber abstimmen, Ziele in den Projektantrag als Projektziele aufnehmen und abschließend ggfs. Ziele nochmals schärfen. Bei großen Projekten bietet sich prinzipiell ein Zieldefinitionsworkshop an. 1.2.1 Zieltabelle Die Projektziele im vorliegenden Projekt Tokana wurden im Team identifiziert und in der nachfolgenden Zieltabelle zusammengefasst. Hierzu wurden die Ziele zudem priorisiert und messbare Erfolgskriterien festgelegt.

Tabelle 1: Zieltabelle

Nr. Zielformulierung Klassifizierung Priorität Messkriterium

Terminziele T1 Projektstart erfolgt Terminziel Muss Projektstart am 14.04.2014

erfolgt.

T2 Recherche und Analyse der Marktsituation

Terminziel Soll Mind 3 "Konkurrenten" anhand einer Onlineanalyse analysiert.

T3 Zieldefinition und Anforderungsanalyse

Terminziel Muss Alle Ziele sind bis 24.04.2014 smart definiert.

T4 Pflichtenheft erstellt Terminziel Soll Pflichtenheft ist am 30.04.2014 vollständig (vgl. Standards) angefertigt.

T5 Aufgabenblock 1 abgearbeitet

Terminziel Soll Alle im Block definierten Aufgaben wurden



zufriedenstellend durchgeführt.


Terminziel Soll Alle im Block definierten Aufgaben wurden zufriedenstellend durchgeführt.


Terminziel Soll Alle im Block definierten Aufgaben wurden zufriedenstellend durchgeführt.

T8 Zusammenführung der Module und Test

Terminziel Muss Zusammenspiel aller Module funktioniert ohne Probleme.

T9 Funktionsfähigkeit und Vollständigkeit der Software gewährleistet

Terminziel Soll Abgleich der Funktionen mit den Anforderungen und Zielen ist zufriedenstellend.

T10 Vorbereitung Abschlusspräsentation abgeschlossen

Terminziel Muss Alle Unterlagen und erforderlichen Projektdokumente wurden erstellt und liegen in der finalen Version vor.

T11 Abgabe des Projektberichts und Projektabschluss

Terminziel Muss Projektbericht und Anwendung sind am 07.07.2014 komplett fertiggestellt und bei der Prüfungskommission eingereicht.

Kostenziele K1 Keine laufenden Kosten während der Entwicklung

Kostenziel Soll Es wurden keine Geldmittel eingesetzt.

K2 Nutzung von kostenfreier Software

Kostenziel Kann In keinem Teil der Software wurde eine lizenzpflichtiges Modul genutzt.

Leistungsziele L1 Sicherheitsstandards

gängiger Bezahlsysteme werden eingehalten

Leistungsziel Muss Richtlinien xy (sind noch zu definieren) wurden beachtet.

L2 Technische Dokumentation der Anwendung wird angefertigt

Leistungsziel Kann Zum Umgang und zur Funktionsweise der Software existiert ein detailliertes Handbuch

L3 Design und Aufbau der Anwendung entspricht den Grundsätzen der Dialoggestaltung (ISO 9241-110)

Leistungsziel Soll Die Software wird nach Fertigstellung entsprechend der ISO Norm geprüft.

L4 Funktionsfähiger, vertikaler Prototyp bis Projektende fertiggestellt

Leistungsziel Soll Alle für das Erreichen der Zielvoraussetzung notwendigen, definierten Use-Cases können mit dem



Prototyp durchlaufen werden

Soziale Ziele S1 Wöchentliches Meeting Soziales Ziel Soll Jede Woche hat mindestens

ein Treffen aller Teilnehmer in Persona stattgefunden.

S3 Ausgeglichenes und konstantes Engagement aller Beteiligten

Soziales Ziel Soll Arbeitszeiten wurden korrekt protokolliert und keiner der Beteiligten weicht um mehr als 20 Prozent vom Mittelwert aller ab.

1.2.2 Zielhierarchie Die Zielhierarchie gibt einen guten Überblick über die gruppierten Projektziele. Die Farben kennzeichnen zusätzlich die Priorisierung in Muss-, Soll- und Kann-Zielen. Die Zielhierarchie des Tokana-Projekts wurde im Team angefertigt. Die definierten Terminziele entsprechen prinzipiell den, im Projektsteckbrief genannten, Meilensteinen. Die Kostenziele ergeben sich, wie folgt: Keine laufenden Kosten während der Entwicklung (beispielsweise Serverkosten etc.) und Nutzung lizenzfreier Software. Die Leistungsziele betreffen besonders die Einhaltung gängiger Sicherheitsstandards und Normen bzw. Gestaltungs-Guidelines. Als soziale Ziele wurden wöchentliche Meetings und eine gerechte Aufteilung der Arbeitsaufgaben identifiziert.



Abbildung 2: Zielhierarchie



1.2.3 Zielbeziehungen In einer Zielbeziehungsmatrix kann die Zielverträglichkeit aller Ziele übersichtlich veranschaulicht und evtl. auftretende Konflikte schnell erkannt werden. Hier bei unterscheidet man fünf Zielbeziehungen:

Neutral: Die Ziele haben aufeinander keinen Einfluss

Identisch: Die Ziele sind identisch eines der Ziele entfernen

Komplementär: Die Ziele fördern sich gegenseitig. Ein höherer Erfüllungsgrad des einen Ziels hat automatisch einen höheren Erfüllungsgrad des anderen Ziels zur Folge

Konkurrierend: Die Erfüllung des einen Ziels führt zu Abstrichen beim Erfüllungsgrad des anderen Ziels: -> Zielkonflikt

Antinom: Sie schließen einander aus. D. h. wird das eine Ziel erreicht, so ist es nicht möglich, auch das andere Ziel zu erreichen Bereinigung vornehmen

Die Zielbeziehungsmatrix wurde im vorliegenden Projekt im Team angefertigt. Ein Großteil der Zielbeziehungen wurde als „neutral“ bewertet. Im Bereich der Termin- und Leistungsziele ergaben sich einige komplementäre Beziehungen. Konkurrierende, antinome und identische Beziehungen traten nicht auf.

Abbildung 3: Zielbeziehungsmatrix



1.2.4 Detailbetrachtung Alle Projektziele werden nochmals in übersichtlicher Form (Tabelle) im Detail dargestellt. Jedes Ziel erhält eine ausführliche Beschreibung, um später von allen Projektbeteiligten bestmöglich nachvollzogen werden zu können. Die folgende Tabelle zeigt einen Auszug aus der Detailbetrachtung des Projektes Tokana.

Tabelle 2: Detailbetrachtung der Projektziele

1.2.5 Nicht-Ziele

Mindestens genauso wichtig, wie die detaillierte Dokumentation der Projektziele anzufertigen, ist es, sogenannte Nicht-Ziele zu definieren. Dazu zählen alle Komponenten bzw. Deliverables (siehe Kap. 5.1), die nicht Teil der Projektplanung und des Lieferumfangs sind. Sie werden unter keinerlei Umständen vom Projektteam umgesetzt. Eine genaue und umfangreiche Dokumentation schützt den Auftragnehmer vor falschen Erwartungen seitens des Auftraggebers und vor potentiellen Regressansprüchen / Haftungsansprüchen. Die folgende Tabelle zeigt einen Ausschnitt aus den Nicht-Zielen des Projektes Tokana.

Tabelle 3: Nicht-Ziele von Tokana

So wurde beispielsweise beschlossen die Software während der Entwicklung nur lokal zu betreiben, um sicherheitskritische Elemente ohne größeres Risiko ausprobieren zu können. Zudem handelt es sich bei dem Tokana-Projekt nicht um ein neues Bezahlsystem (wie z.B. PayPal).



2. Projektumfeld, Stakeholderanalyse

2.1 Projektumfeldanalyse, Umfeldfaktoren

Die Projektumfeldanalyse ist ein wesentlicher Bestandteil der Initialisierungsphase eines Projektes. Das Projektumfeld beeinflusst das Projekt auf verschiedenste Art und Weise und wird seinerseits vom Projekt beeinflusst. Es ist demzufolge wichtig, das Projektumfeld zu Projektbeginn genau zu analysieren. Ziele der Projektumfeldanalyse sind dabei, die wichtigsten Einflussfaktoren auf das Projekt zu identifizieren und zu bewerten. Projektumfeldfaktoren können in interne und externe Umfeldfaktoren klassifiziert werden. Das interne Umfeld bezieht sich auf Umfeldfaktoren innerhalb der Unternehmens-organisation. Hierzu zählen unter anderem die Geschäftsführung, das Projektteam, andere Projekte sowie der Auftraggeber des vorliegenden Projekts. Das externe Umfeld besteht aus Faktoren außerhalb der Unternehmensorganisation. Von Interesse sind hierbei alle Einflüsse, die von außen auf das Projekt einwirken können. Beispiele sind gesetzliche Vorgaben, Kunden, Partner, Lieferanten und externe Dienstleister. Umfeldfaktoren sollten ebenfalls in Sach- und Sozialfaktoren eingeteilt werden. Sachfaktoren beziehen sich auf das natürliche, technische und ökonomische Umfeld. Zu den Sozialfaktoren zählen das rechtlich-politische sowie soziokulturelle Umfeld. Hierzu wird eine Projektumfeld-Tabelle angefertigt. Die Projektumfeld-Tabelle für das Projekt Tokana ergibt sich wie folgt:

Tabelle 4: Projektumfeld

Sind alle vier Einflussfaktoren-Gruppen identifiziert, wird die jeweilige Einflussgröße der einzelnen Faktoren bewertet und in einer Schnittstellenmatrix festgehalten. Die folgende Umfeldschnittstellen-Matrix führt alle zentralen, sachlichen Projektumfeld-faktoren des Projekts Tokana auf.



Tabelle 5: Umfeldschnittstellen-Matrix (soziale Einflussfaktoren)

Neben einer Beschreibung der sozialen Einflussfaktoren wurde im Projekt Tokana jeweils eine konkrete Maßnahme festgehalten, die dazu beitragen soll die Einstellung und den Einfluss eines bestimmten Faktors auf das Projekt in eine gewünschte Richtung zu lenken. Beispielsweise ist eine positive Einstellung des Gesetzgebers zum Projekt nur dadurch erreichbar, dass Gesetze (z.B. das Datenschutzgesetz) genauestens eingehalten werden. Dies kann unter anderem durch eine intensive Schulung der betroffen Teammitglieder erreicht werden. 2.2 Stakeholder (Interested Parties)

Neben der Projektumfeldanalyse stellt auch die Stakeholderanalyse einen zentralen Bestandteil der Initialisierungsphase dar. Stakeholder (engl. stake: Anspruch, Interesse, Erwartung oder Forderung) sind Einzelpersonen, Personengruppen, oder Organisationen, die am Projekt beteiligt, am Projektverlauf/-ergebnis interessiert oder von den Auswirkungen des Projektes betroffen sind. Dabei gibt es fünf prinzipielle Stakeholdergruppen.

1. Kunden als Auftraggeber des Projektes und Anwender bzw. Nutzer des Projektproduktes

2. Das Unternehmen, das das Projekt durchführt mit verschiedenen Funktionsträgern (Vorstand/ Geschäftsführung, Personalrat, Datenschutzbeauftragter, Projektmanagement, Office u.a.)

3. Mitarbeiter in verschiedenen Rollen (Projektleiter, Projektcontroller, Teammitglied, Projektadministrator, Mitglieder von Lenkungsausschüssen u.a.)

4. Lieferanten und Subauftragnehmer (Subunternehmer, Berater, Ingenieurbüros, sonstige Dienstleister wie Versicherung, Finanzen u.a.)

5. Die Gesellschaft (Anlieger, Behörden, Bürgerinitiativen, Gesetzgeber u.a.)

Stakeholder können durch die Projektziele/-ergebnisse und der Einflussnahme auf das Projekt nach ihrer Betroffenheit in Kategorien eingeteilt werden.



Die Betroffenheit gliedert sich in den Grad (gering – mittel – stark) und die Art (positiv – negativ). Daraus ergibt sich die Einstellung zum Projekt (Art der Einstellung: positiv – neutral – negativ). Promotoren (Projektbefürworter) unterstützen das Projekt, wohin gegen Opponenten (Projektgegner) für Widerstand sorgen. Dabei ist zu beachten, ob es sich um Vermutungen oder Fakten handelt. Die Einflussnahme beschreibt die Macht auf das Projekt (gering – mittel – stark). Ziel des Stakeholdermanagements ist, alle Stakeholder mit ihren Interessen, Einstellungen und Einflussmöglichkeiten zu kennen, um geeignete Maßnahmen zur Akzeptanz des Projektes ableiten zu können. Das Stakeholdermanagement hat die Aufgabe die Anforderungen und Erwartungen der Stakeholder zu ermitteln, diese bei der Zielsetzung, Projektplanung und –durchführung zu berücksichtigen, Strategien und Maßnahmen zu entwickeln, die Projektstakeholder aktiv und proaktiv zu betreuen (insbesondere der einflussstarken Entscheider) sowie Stakeholdermaßnahmen zu steuern und zu überwachen. Der Prozess des Stakeholdermanagement besteht aus vier Schritten. Zuerst werden die Stakeholder identifiziert. Dabei werden meist in einem Workshop mit Projektbeteiligten/ -betroffenen Kernfragen gestellt (z.B. Welche Prozesse werden durch das Projekt wesentlich verändert? Wer könnte Widerstände (Ängste, Befürchtungen) gegen das Projekt haben?). Das Ergebnis ist eine Stakeholderliste, die als Basis für die Analyse der Stakeholder dient. Im zweiten Schritt wird eine Analyse für jeden Stakeholder zu folgenden Punkten gemacht.

Einstellung zum Projekt: positiv +, neutral o, negativ –

Erwartungen / Unterstützung (+) bzw. Befürchtungen / Widerstände (-)

Betroffenheit: hoch, mittel, gering

Macht / Einfluss auf das Projekt: hoch, mittel, gering Die Projektverantwortliche versetzen sich dabei in die Situation der Stakeholder. Ergebnis ist eine Stakeholdermatrix (Interessenmatrix), die einen Gesamtüberblick über das Projekt verschaffen soll. Im Rahmen des Projekts Tokana wurde die Stakeholdermatrix auf der folgenden Seite angefertigt.

Der dritte Schritt ist eine Maßnahmenplanung. Ziele der Maßnahmen sind dabei Widerstände zu verringern und die Unterstützung der einzelnen Stakeholder zu verstärken. Hierfür gibt es drei grundsätzliche Strategien. Bei der partizipativen Strategie wird der Stakeholder als Partner betrachtet. Der Partner ist am Lenkungsausschuss sowie an der Mitarbeit am Projekt beteiligt und erhält regelmäßig Informationen. Bei der diskursiven Strategie soll durch Verhandlungen und Konfliktmanagement ein Ausgleich der verschiedenen Stakeholderinteressen stattfinden. Die repressive Strategie versucht durch Druck auf die Stakeholder die Ziele zu erreichen. Sie ist in der Regel nicht empfehlenswert, da sie ethisch nur schwer vertretbar ist. Für einzelne Stakeholder kann eine Kombination der Strategien sinnvoll sein. Bei der Maßnahmenplanung unterscheidet man zwischen Maßnahmen zur Verringerung der



Widerstände (z.B. Abbau von Ängsten und Befürchtungen) und Maßnahmen zur Stärkung der Förderer. Bei den Maßnahmen zur Verringerung von Widerständen, wird eine Win-Win-Situationen angestrebt, es werden Pro-Kontra-Argumente herausgearbeitet und „Botschaften“ für Zielgruppen erarbeitet sowie eine Vertrauensbasis geschaffen. Grundlegend ist eine ehrliche und klare Kommunikation und evtl. Partizipation in der Projektarbeit. Maßnahmen zur Stärkung der Förderer beinhalten eine lückenlose Information der Förderer. Es wird ein persönlichen Draht aufgebaut und Meinungsbildnern sowie Multiplikatoren werden einbezogen.

Tabelle 6: Stakeholdermatrix

Maßnahmen und die erwarteten Lageveränderungen können in einem Stakeholder-Portfolio visualisiert werden. Die Einflüsse und Unterstützung bzw. Widerstände der einzelnen Stakeholder werden anschaulich dargestellt und Key-Stakeholder (Stakeholder mit hohem Einfluss und hoher Betroffenheit) werden identifiziert. Die folgende Abbildung zeigt das Stakeholder-Portfolio des Tokana-Projekts.



Abbildung 4: Stakeholder-Portfolio

Die grauen Kreise in Abbildung 4 stellen den Einfluss und die Einstellung der einzelnen Stakeholder ohne den Einsatz gezielter Maßnahmen dar. Die grünen Kreise hingegen verdeutlichen die Auswirkung gezielter Maßnahmen. Die Einstellung von Stakeholder 5 (Gesetzgeber) auf das Projekt könnte beispielsweise durch die, in der Stakeholdermatrix genannten Maßnahmen, positiv beeinflusst werden. Der vierte Schritt ist das Controlling (Monitoring und Steuerung). Wichtig ist, dass die Ergebnisse der Stakeholderanalyse projektinternen Charakter haben. Dies bedeutet, dass sie nicht nach außen gehen. Dazu wird im Projektverlauf mehrfach eine Projektstakeholderidentifikation und -analyse durchgeführt. Stakeholderidentifikation und -analyse stellen immer nur eine Momentaufnahme dar. Der geeigneter Zeitpunkt für eine Neubetrachtung/-bewertung ist der Beginn einer neuen Projektphase. Beispiele für Controlling-Fragen sind: Gibt es neue Stakeholder? Waren die durchgeführten Maßnahmen erfolgreich? Die Macht- und Betroffenen-Stakeholder haben einen unterschiedlichen Einfluss auf die Akzeptanz und das Projektergebnis. Der Einfluss der Macht-Stakeholder ist zum Projektbeginn am größten und nimmt im Projektverlauf stetig ab. Wohingegen der Einfluss der Betroffenen-Stakeholder anfangs gering ist und mit fortschreitendem Projektverlauf steigt.



3. Risikoanalyse

In diesem Kapitel sollen die Grundlagen der Risikoanalyse und des Risikomanagements im Projektmanagement vermittelt werden. Dieser oft unterschätzte Teilbereich des Projektmanagements spielt auch noch bei Großprojekten eine sehr bedeutende Rolle und kann bei einer unzureichenden Behandlung zu fatalen Fehlentscheidungen und zum Scheitern von Projekten führen. Ein intensives und korrekt durchgeführtes Risikomanagement ist daher essenziell für eine erfolgreiche Durchführung eines Projekts. Als Risiko bezeichnet man im Projektmanagement allgemein ein Ereignis das sich in den zwei Dimensionen Eintrittswahrscheinlichkeit (EW) und Tragweite (TW) ausbreitet. Die Eintrittswahrscheinlichkeit bezeichnet hierbei die Wahrscheinlichkeit mit der es zu dem Ereignis kommt, die Tragweite die positiven bzw. negativen Konsequenzen im Eintrittsfall des Ereignisses. Konsequenzen können bspw. Auswirkungen auf Projektergebnisse, Termine oder das Budget sein. Das Produkt aus Eintrittswahrscheinlichkeit und Tragweite wird als Risikofaktor (RF) bezeichnet:

RF := EW * TW Der systematische Prozess zum Handhabung von Risiken wird als Risikomanagement bezeichnet. Er umfasst dabei die Teilprozesse Risikomanagementplanung, -identifikation, -analyse / -bewertung, -behandlung, -controlling und Erfahrungssicherung. Diese Schritte werden im Folgenden näher erläutert. Zu Beginn ist es wichtig zu beachten, dass die vier Schritte der Risikoidentifikation, -analyse, -behandlung und -controlling nicht einmalig sequentiell abgearbeitet werden. Viel wichtiger ist dagegen eine iterative Bearbeitung. Im Anschluss an das Risikocontrolling sollte es zu einer erneuten Identifikation der durch die Änderungen entstandenen Risiken kommen. Die Erfahrungssicherung erfolgt auch nicht im Anschluss sondern parallel zu allen anderen Teilprozessen des Risikomanagements und sollte ständig stattfinden.

Abbildung 5: Der Prozess des Risikomanagements



Die Risikomanagementplanung umfasst alle Aufgaben die mit der Festlegung des Vorgehens für das Risikomanagement im vorliegenden Projekt zu tun haben. Hierzu gehören eine Verteilung der Rollen und Verantwortlichkeiten, die Festlegung von Zeitpunkten für Risikoanalysen im Projektverlauf, das Erstellen von Verfahren, Templates und ähnlichem, die Kommunikation von Projektrisiken und Maßnahmen sowie die Klärung des Vorgehens zur Erfahrungssicherung. Ergebnis der Planung sollte ein Risikomanagementplan sein, sowie ein gewecktes Bewusstsein der Teammitglieder für Risiken im Projekt. In diesem Prozess ist es auch wichtig eine gewisse Risikokultur zu beachten: Allen Projektmitgliedern sollte es möglich gemacht werden Risiken ansprechen zu dürfen. Genauso wichtig ist es, dass die Projektleitung bzw. das Kernteam sich aktiv um die Behandlung von Risiken kümmern und die Ergebnisse kommunizieren. 3.1 Erfassung, Klassifizierung und Beschreibung der Risiken

Zur Risikoidentifikation gibt es eine Reihe verschiedener Techniken. Diese kann bspw. im Rahmen eines Risiko-Identifikations-Workshops mit Kreativitätstechniken wie Brainstorming oder Mind-Mapping stattfinden. Alternativ lassen sich auch Checklisten oder Expertenbefragungen durchführen, auch Szenario- oder Simulationsmethoden kommen hier zum Einsatz. Wichtig ist lediglich, dass alle qualifizierten Kräfte aus allen betroffenen Unternehmensarbeiten bei der Risikoidentifikation zusammenarbeiten, da sich Risiken in ihrer Art sehr unterscheiden können. Neben technischen, personellen oder wirtschaftlich / kaufmännischen Risiken können auch politische, vertragliche oder Wettbewerbs- und Marktrisiken sowie Projektumfeldrisiken auftreten. Im Projektmanagement können diese in Ressourcen-, Zeit-, Kosten- und Qualitätsrisiken klassifiziert werden. Für jedes identifizierte Risiko wird eine Wirkungskette aufgestellt: Diese unterteilt das Risiko in seine drei Bestandteile Ursache, Risikoereignis und Auswirkung. Die Ergebnisse der Identifikation werden, aufgeteilt in diese drei Bestandteile, in einer Risikotabelle gesammelt.

Für das Projekt Tokana wurden die wichtigsten und schwerwiegendsten Risiken in einer erweiterten Gruppensitzung ermittelt und aufgelistet. Dabei ergaben sich folgende fünf

Szenarien.

Tabelle 7: Identifiziert Hauptrisiken – Tokana



3.2 Quantitative Bewertung der Risiken und Maßnahmen zur Risikobegegnung

Die Risikoanalyse und -bewertung kann auf zwei verschiedene Arten erfolgen: Bei einer Qualitativen Bewertung werden Eintrittswahrscheinlichkeit und Tragweite in Klassen wie bspw. gering, moderat und hoch unterteilt. Vorteil dieser Bewertung ist die schnelle Einordnung der Risiken sowie die mögliche Darstellung in einer Risikomatrix. Im Kontrast hierzu steht die Quantitative Risikobewertung. Die Eintrittswahrscheinlichkeit eines Risikos wird hierbei prozentual angegeben, die Tragweite monetär. Aus diesen beiden Werten lässt sich mathematisch ein ebenfalls monetärer Risikowert berechnen. Vorteil dieser Bewertung ist die vertiefende Betrachtung durch fixe Zahlenwerte im Vergleich zur tendenziell subjektiveren Einstufung der qualitativen Bewertung. Die Risikoanalyse erfolgt in einem ersten Schritt oft qualitativ, woraufhin in einem zweiten Schritt die erkannten Hauptrisiken nochmals quantitativ bewertet werden. Eintrittswahrscheinlichkeit und Tragweite auf Zahlenwerte zu fixieren stellt sich bei der Quantitativen Bewertung oft als schwierig heraus. Für den Wahrscheinlichkeitswert lässt sich hierfür zum Beispiel eine Annualisierung vornehmen. Hierbei wird anhand vergleichbarer Projekte bestimmt wie häufig ein Schadensereignis in einem bestimmten Zeitraum von einigen Jahren auftritt. Dieser Wert wird dann rechnerisch auf den Zeitraum des Projekts angeglichen. Die Risikobehandlung kann auf vier verschiedene Arten vorgenommen werden: Risikovermeidung, -verhinderung, -verlagerung und -akzeptanz. Bei der Risikovermeidung wird das Risiko durch Ursachenbeseitigung ausgeschlossen, dies sollte vor allem bei Risiken mit großer Tragweite und Eintrittswahrscheinlichkeit vorgenommen werden. Ist die Tragweite nicht ganz so groß sollte es zur Risikoverminderung kommen. Hierfür werden präventive Maßnahmen zur Reduktion der Eintrittswahrscheinlichkeit vorgenommen. Eine Risikoverlagerung eignet sich bei hoher Tragweite aber geringer Eintrittswahrscheinlichkeit. Das Risiko wird dabei auf Dritte wie zum Beispiel Auftraggeber oder Versicherungen transferiert. Bei Risiken mit geringer Eintrittswahrscheinlichkeit und Tragweite kann auch eine Akzeptanz des Risikos vorgesehen werden. Besonders wenn Aufwände für Gegenmaßnahmen höher sind als der Schadenswert ist dies von Vorteil. Allgemein lässt sich eine Maßnahmenentscheidung daran treffen, ob der Risikowert nach Umsetzung der Maßnahme summiert mit den Kosten der Maßnahme kleiner ist als der Risikowert ohne Umsetzung der Maßnahme. Ist dies der Fall sollte die Maßnahme umgesetzt werden. Für das Projekt Tokana wurden im Team zuerst die Risiken und anschließend die möglichen Maßnahmen analysiert und bewertet. Daraus ergab sich folgende Einschätzung:



Tabelle 8: Quantitative Risikobewertung und Maßnahmenbeschreibung

Tabelle 9: Quantitative Maßnahmenbewertung und -entscheidung

Anschließend an Analyse und Beschluss der durchzuführenden Maßnahmen wurden diese, soweit bereits möglich, geplant und feste Termine vereinbart. An diesen Terminen sollen die geplanten Maßnahmen im Team umgesetzt werden. Die Planung der Maßnahmen ist in der folgenden Tabelle zu sehen.



Tabelle 10: Maßnahmenplanung

Nach der Risikobehandlung erfolgt das Risikocontrolling. Die Verantwortung hierfür liegt beim Projektleiter bzw. leitenden Risikomanager. Ziel ist eine laufende Verfolgung und Steuerung der Maßnahmen aus der Risikoplanung. Hierfür ist es wichtig ein Frühwarnsystem einzurichten das aufgrund von Anreizen, Symptomen und Ereignissen Gefahren und Risiken frühzeitig erkennen kann. Auch die Beachtung sogenannter schwacher Signale ist hierbei wichtig: Gerüchte, Drohungen, erhöhte Krankheitsquoten oder Misstrauen im Team gehören hierzu. Wichtig ist es auch eine regelmäßige Risikoüberprüfung durchzuführen, da sich die Risikosituation im Projektverlauf ständig ändert. Gelegenheiten hierfür bieten Jour Fixe oder Lenkungsausschusssitzungen, Meilensteine oder besondere Ereignisse in verschiedener Form. Treten bei einer neuen Analyse Änderungen auf sind Risikotabellen zu aktualisieren, Maßnahmenpläne anzupassen oder Personaleinsatzpläne zu aktualisieren. Der letzte Schritt im Risikomanagement beschreibt die Erfahrungssicherung. Hierfür ist es wichtig schon während des Projektverlaufs identifizierte und nicht identifizierte eingetretene Risiken zu protokollieren. Auch Fehleinschätzungen, die Effektivität von einzelnen Maßnahmen sowie des gesamten Risikomanagements sind zu bewerten und Optimierungsmöglichkeiten aufzuzeigen. Die Ergebnisse können beispielsweise in einer Erfahrungsdatenbank dokumentiert werden und so Vorlagen für weitere Projekte überarbeitet werden.



4. Projektorganisation Da Projekte stets ein zeitlich begrenztes Unterfangen sind, müssen sie in das Tagesgeschäft und damit in das Unternehmen eingeordnet werden. Hierzu eignen sich unterschiedliche Organisationsformen mit unterschiedlichen Vor- und Nachteilen:

1. Autonome Projektorganisation: Mitarbeiter sind ausschließlich Projekten zugeordnet und haben keine anderen Verpflichtungen in der Linienorganisation. Das Projekt könnte auch als eigene Linie gesehen werden.

a. Vorteile: Projektleiter kann vollständig über das Personal verfügen. Personal kann sich vollständig auf das Projekt konzentrieren.

b. Nachteile: Ungewisser verbleib der Projektmitglieder, nach dem Projekt. 2. Matrix Projektorganisation: Mitarbeiter gehören sowohl zur Linie, als auch zum

Projekt. a. Vorteile: PL hat entsprechende Verfügungsgewalt. Projekt kann recht einfach

in vorhandene Strukturen eingebettet werden. b. Nachteile: Arbeitnehmer unterstehen sowohl PL als auch der Linienleitung.

Eine gute Kommunikation von PL und Linien Leitung ist nötig um das „Scheidungskinderphänomen“ zu vermeiden.

3. Stabs-/Einfluss Projektorganisation: Mitarbeiter gehören zur Linie. PL wickelt Projekt ohne Entscheidungsbefugnis ab.

a. Einfach in das Unternehmen zu integrieren. b. Projektleiter und Projekt sind auf das Wohlwollen der Linien Leitung

angewiesen. 4.1 Organisationsform des Projektes

Das Projekt Tokana wird im Rahmen einer autonomen Projektorganisation durchgeführt. Dies ergibt sich aus der Tatsache, dass es kein Unternehmen gibt, dem die Gruppenmitglieder angehören. Entsprechend gibt es keine Linien denen einzelne Mitglieder angehören könnten. Die Mitarbeiter sind als Freelancer an zu sehen, welche sich für dieses Projekt zusammengefunden haben.

Abbildung 6: Graphische Darstellung der Projektorganisation



Tabelle 11: Funktionen der Beteiligten

Rolle Person Aufgaben (A) Befugnisse (B) Verantwortung (V)Rolle Person Aufgabe Befugnisse Verantwortung

Designer PB, MA - Stlyeguides entwerfen

- Logoentwurf

- Icons gestalten

- Farbkonzept erstellen

-Zugriff auf relevante

Projektordner

- Zugriff auf Ergebnisse der

Marketinganalyse

- termingerechte Abgaben

- Kundenwünsche

berücksichtigen

- Einhalten von

Gestaltungsgrundsätzen

Usability-

Experte

MA, AK - Use-Cases entwerfen

- Storyboards erstellen

- Klick-Prototypen entwerfen


Projektordner

- Zugriff auf Ergebnisse der

Marketinganalyse


- Einhalten von Guidelines

(z.B:Grundsätze der

Dialoggestaltung)

Software-

Engineer

HK, RS -Backend-Entwicklung

- Datenbanken erstellen und

verwalten

- Testing


Projektordner

- Zugriff auf Datenbanken


- Gewährleistung der

Funktionsfähigkeit und Sicherheit

der Sowftware

Projektleiter PB, MA, AK, HK,

RS

- Projektcontrolling

- Daten

-Zugriff auf alle Projektordner - Projekterfolg sicherstellen

- Kommunikation aufrecht

erhalten

- Meetings planen

- Datenkonsitenz verschiedener

Dokumente sicherstellen

Auftraggeber Prof. Wehnes - Ansprechpartner bei Problemen

- Bewertung des Projektberichts

und Prototyps

- Vermitteln des benötigten

Know-Hows

Keine - gerechte Bewertung

durchführen

- Qualität der Lerninhalte

sicherstellen

4.2 Kommunikation

Einer der wichtigsten Erfolgsfaktoren in einem Projekt ist die Kommunikation. Dabei gilt, der Empfänger bestimmt die Botschaft. Die beabsichtigte Botschaft des Senders kommt bei diesem gefiltert an. Das Shannon-Weaver-Modell beschreibt den Kommunikationsablauf zwischen Sender und Empfänger. Der Sender setzt den Kommunikationsprozess in Gang, indem er eine Nachricht formuliert und das Übertragungsmedium wählt. Der Empfänger nimmt die Nachricht entgegen und entschlüsselt sie. Dabei stellt der Übertragungskanal die Verbindung zwischen Sender und Empfänger dar. Vom Empfänger geht ein Feedback in Form einer Reaktion zurück an den Sender. Als Grundregeln für eine gute Kommunikation definiert Watzlawick fünf Axiome.

1. Man kann nicht nicht nicht kommunizieren 2. Jede Kommunikation hat einen Inhalts- und Beziehungsaspekt

Der Beziehungsaspekt bestimmt den Inhaltsaspekt. 3. Kommunikation ist immer Ursache und Wirkung

Wenn zwei Personen sprechen oder handeln, so bedingt das Verhalten der einen Person das Verhalten der anderen. Dabei erleben beide oft das Verhalten der anderen Person als Ursache des eigenen Verhaltens.

4. Menschliche Kommunikation bedient sich analoger und digitaler Modalitäten. Es ist nicht wichtig, was A sagt, sondern wie es bei B ankommt.

5. Kommunikation ist entweder symmetrisch oder komplementär Je nachdem ob die Beziehung zwischen den Partner auf Gleichgewicht oder Unterschiedlichkeiten beruht.



Kommunikation kann auf verschiedenen Ebenen unterschieden werden. Das Eisbergmodell beschreibt auf Sachebene, was kommuniziert wird. Dies läuft bewusst ab. Hier werden Fakten und Argumente ausgetauscht. Die Beziehungsebene bezieht sich auf mehr oder weniger unbewusste Prozesse. Die Form, Art und Weise beschreibt, wie kommuniziert wird. Projektleiter, die sich nur auf die Sach- und Inhaltsebene konzentrieren, übersehen oftmals die menschlichen Bedürfnisse, Erwartungen und Gefühle der Stakeholder. Eine genaue Stakeholderanalyse ist deshalb unverzichtbar. Bei internationalen Projekten sind zudem die kulturellen Gegebenheiten des Kommunikationspartners zu beachten. Das 4-Seiten Modell (synonym Nachrichtenquadrat, Kommunikationsquadrat, Vier-Ohren-Modell) nach Schulz von Thun ist eine Erweiterung und Verfeinerung des Sender-Empfänger Modells. Jede Nachricht besteht aus 4 Seiten. Neben der Sach- und Beziehungsebene gibt es die Selbstoffenbarung und den Appell. Die Selbstoffenbarung ist die Meinung des Senders zu einem bestimmten Sachverhalt. Der Appell stellt die Aufforderung an den Empfänger dar. Auch hier kommt es hauptsächlich auf die Interpretation des Empfängers an. Diese kann auf allen vier Ebenen sehr unterschiedlich ausfallen. Die Projektkommunikation wird als wirksamer Austausch von Informationen zwischen den Projektbeteiligten definiert (NCB 3.0). Anforderungen sind, dass die richtige Information an die relevanten Stakeholder in einer ihren Erwartungen entsprechenden und einheitlichen Form weitergegeben werden muss, dass die Kommunikation zweckorientiert sowie klar verständlich und aktuell sein sollte. Nach Bohinc (2008) ist die Kommunikation die wichtigste Fähigkeit für einen erfolgreichen Projektmanager (Beschreibung: Kommuniziert engagiert; fasst Ergebnisse zusammen; stellt Fragen, um Sachverhalte zu klären; ist ein geschätzter Gesprächspartner für Mitarbeiter und Kunden). Das Projektkommunikationsmanagement besteht aus der Kommunikationsplanung (Anforderungen der Stakeholder, Kommunikationstechnologie, Kommunikationswege), der Informationsverteilung (Termingerechte Bereitstellung relevanter Informationen), dem Projektreporting (Fortschrittsberichtswesen: Sammeln und aufbereiten von Fortschrittsinformationen: Statusreports, Trendanalysen, EVAs usw., Planfortschreibungen erarbeiten und kommunizieren) und dem administrativen Abschluss (Erzeugen und sammeln von Informationen, um eine Projektphase oder den Projektabschluss zu formalisieren). Um eine gute Kommunikation sicher zu stellen, sollten folgende Regeln beachtet werden:

1. Aktives Zuhören 2. Fragen stellen 3. Sicher stellen, dass der Gesprächspartner einen verstanden hat. 4. Sorgsam wählen, was gesagt und getan wird, damit andere einen verstehen. 5. Körpersignale beachten 6. In der „ich“-Form kommunizieren 7. Persönlichen Eindrücke und Wünsche klar aussprechen 8. Denkanstöße geben 9. Kurze Kommunikationswege wählen



Die Kommunikation in Projekten lässt sich ganz allgemein in die Bereiche interne und externe Kommunikation einteilen. Die projekt-interne Kommunikation bezieht sich auf Informationen innerhalb des Projektteams. Sie beinhaltet Besprechungen, Rückmeldungen an Projektmitarbeiter, AP-Verantwortlichen und Teilprojektleiter, sämtliche Planungsdaten sowie die Rückmeldung über Ergebnisse von Besprechungen mit externen Stakeholdern. Bei der projekt-externen Kommunikation handelt es sich um Informationen, die an Stakeholder außerhalb des Projekts gegeben werden. Dazu gehören Berichte (Status und Abschluss), Präsentationen sowie Marketing-Maßnahmen. Die Kommunikationsplanung hat das Ziel Projektstakeholder zeitnah, angemessen, proaktiv und ehrlich über den Projektfortschritt und besondere Projektereignisse zu informieren. Planungskomponenten sind Informationswege und –verantwortliche (Sender und Empfänger der Informationen), Informationsinhalte, Rahmen: Sitzung, Pressekonferenz, Kongress/ Fachtagung), Informationsarten und –medien (Mündlich: Vorträge, Einzelgespräche, Meetings; Schriftlich: Mail, Brief, Projektplattform, Unternehmensnachricht) sowie die Informationshäufigkeit (Zeitpunkte, periodische Termine sowie anfängliche, wiederholte und abschließende Kommunikation). Zur systematischen Planung und effektiven Gestaltung der Projektkommunikation sind fünf W-Fragen hilfreich.

1. Wer sind die Stakeholder? 2. Was sind die Inhalte? 3. Welche Form/ Maßnahmen werden genutzt? 4. Wer ist der Verantwortliche? 5. Wann sind Termine?

Projektbesprechungen dienen dem direkten Informationsaustausch und sind Grundlage einer direkten Projektsteuerung, insbesondere bei Schwierigkeiten. Sie können in drei Arten eingeteilt werden. Regelmäßige Besprechungen sind fest vereinbarte Termine (Jour fixe) für Statusbesprechungen. Ergebnis-gesteuerte Projektbesprechungen haben das Ziel Entscheidungen über das weitere Vorgehen im Projekt, den Start oder Abschluss von Phasen und Meilensteinen zu treffen. Bei ereignis-gesteuerten Projektbesprechungen werden unerwarteten Ereignisses im Projektverlauf (z.B. einer Krise) besprochen. Professionelles Meeting-Management bedarf einer sorgfältigen Vorbereitungen, einer strukturierten Durchführung nach dem IDEE-Prinzip (Information, Diskussion, Entscheidung, Ergebnissicherung) sowie einer wirkungsvolle Nachbetrachtung. Die folgende Tabelle stellt die Kommunikationsplanung des Projekts Tokana mit verschiedenen Projektpartnern dar.



Tabelle 12: Kommunikationsplan von Tokana

ZielgruppeInhalte/

Botschaften erwartete Wirkung

Kommunikations-

medium

Verant-

wortlicherBeteiligte

Termin /

FrequenzStatus

VeranstalterPrototyp testen +

Feeback einholen

Verbesserungs-

vorschlägeMeeting AK Team 1x

noch nicht

erledigt

GästePrototyp testen +

Feeback einholen

Verbesserungs-

vorschläge

Fragebogen,

InterviewAK Team 1x

noch nicht

erledigt

Auftraggeber

Stand des Projekts,

Wissen über

Projektmanagement

Projekterfolg,

Kompetenzerwerb

E-Mail,

WueCampus,

Projektbericht,

Protokolle,

Vorlesung

AK Team wöchentlich in Arbeit

Drittanbieter

(z.B. Paypal)

Richtlinien zur

Einbindung

Funktionsfähigkeit

des Prototyps Website HT RS 1x

noch nicht

erledigt

VersicherungenAnforderungen,

Vorgaben, RichtlinienRechtsschutz E-Mail, Telefon MA Team nach Bedarf

noch nicht

erledigt

TeamInterna,

Projektmanagement

Projekterfolg,

TeamgeistMeeting AK Team wöchentlich in Arbeit



5. Phasenplanung

Ein Projekt gliedert sich prinzipiell in mehrere, durch sogenannte Meilensteine klar voneinander abgegrenzte, Projektphasen. Diese können, je nach Projekt, sowohl sequentiell als auch (teilweise) parallel ablaufen. Laut Definition wird in einem Phasenplan „das Projekt übersichtlich durch mehrere (meist zeitlich aufeinanderfolgende) Projektphasen, die sich sachlich voneinander unterschieden, dargestellt“. Die Ziele des Phasenplans sind zum einen die Reduzierung der Komplexität von Projekten. Darüber hinaus basieren weitere Planungsschritte und Dokumente (z.B.: Projektstrukturplan) auf dem Phasenplan und er beschränkt das Projekt-Risiko (Go- oder Nogo-Entscheidungen). 5.1 Beschreibung der Projektphasen und der Meilensteine

Für die Erstellung des Phasenplans ist es wichtig, die zentralen Eigenschaften und Anforderungen des vorliegenden Projektes zu kennen. Hierzu gehören u.a. die Projektziele, Projekttermine und die Projektkosten. Aus diesen Daten können die einzelnen Phasen für den Phasenplan abgeleitet werden. Zudem werden auch sogenannte „Deliverables“ (Lieferobjekte oder Liefergegenstände) bestimmt, die zum jeweils festgelegten Zeitpunkt (meist im Rahmen eines Meilensteins) fertig vorliegen, bzw. dem Auftraggeber komplett übergeben werden müssen. In jeder Phase werden somit verschiedene Liefergegenstände produziert, die auch als Maß für einen erfolgten Abschluss der Phase dienen können. Sind bestimmte Deliverables noch nicht fertiggestellt, muss der Abschlusstermin der jeweiligen Phase verschoben werden. Dies sollte jedoch stets vermieden werden, da der Auftraggeber in den meisten Fällen mit einer pünktlichen Leistungserbringung rechnet. Deliverables können sowohl materieller als auch immaterieller Natur sein. Unterschieden wird deshalb zwischen Product Deliverables (Teile / Komponenten des Endprodukts) und Process Deliverables (Lieferobjekte die für den Projektverlauf wichtig sind wie beispielsweise Prototypen oder Dokumente). Bestimmte Deliverables verbleiben beim Projektteam (intern), andere sind (auch) für den Auftraggeber bestimmt. Alle erforderlichen Deliverables werden in eine logische Reihenfolge gebracht und anschließend in einzelne Phasen unterteilt. Die Dauer einer Phase ergibt sich zwangsläufig aus der Menge und der Komplexität der jeweils anzufertigenden Deliverables. Nahezu alle (Software-)Projekte gliedern sich in fünf Phasen:

Initialisierung

Definition

Planung

Durchführung

Abschluss



Es existieren verschiedene Vorgehensmodelle an denen sich die Projektleiter bei der Planung von Projekten orientieren können (z.B.: Wasserfallmodell, Spiralmodell, V-Modell…). Im vorliegenden Projekt wurden die Bestandteile des generellen Vorgehensmodells nahezu vollständig übernommen. Die Phasen untergliedern sich in Planung, Konzeption, Realisierung, Optimierung und Abnahme. Sie können der folgenden Phasen-Tabelle entnommen werden:

Tabelle 13: Phasenplan des Tokana-Projekts

In der Planungsphase des Projekt Tokana werden erste grundlegende Arbeiten durchgeführt. Hierzu zählen die generelle Planung des Projekts (Anlegen der notwendigen Dokumente, Verteilen von Aufgaben etc.) und die Erstellung eines Marketingkonzepts, das u.a. eine kleine Marktforschung (zu konkurrierenden Anbietern) beinhalten soll. In der Konzeptionsphase wird die genaue Funktionsweise des geplanten Wertmarkensystems und das äußere Erscheinungsbild erarbeitet und definiert. Hierzu gehören ein Sicherheitskonzept, die Konzeption von Handlungsabläufen (Use-Cases) etc. Die eigentliche Programmierung und Umsetzung des Wertmarkensystems erfolgt in der anschließenden Realisierungsphase. Sie dauert dementsprechend auch am längsten. Das Ergebnis der drei ersten Phasen soll in der Optimierungsphase einigen Tests unterzogen werden, um sowohl die Akzeptanz bei den Nutzern zu überprüfen, als auch einen sicheren und korrekten Funktionsumfang des Portals zu gewährleisten. Die letzte Phase ist relativ kurz und wird im Projekt als Abnahmephase deklariert. In dieser Phase werden die Projektergebnisse für die Abschlussveranstaltung dokumentiert und Restarbeiten abgeschlossen. Projektphasen werden üblicherweise mit Meilensteinen voneinander abgegrenzt. Meilensteine werden definiert als „Ereignisse von besonderer Bedeutung für den Projektverlauf“ (DIN 69900:2009). Sie dienen allgemein der Überprüfung des Projektfortschritts und geben Vorgaben für den Übergang in die nächste Projektphase.



Meilensteine können sowohl externer (Meilensteine mit Auftraggeber bzw. Lenkungsausschuss) als auch interner (Projektinterne Kontrollpunkte) Natur sein. Meilensteine können auch als sogenannte Quality Gates (spezielle Meilensteine) die Freigabeentscheidung für die nächste Projektphase bestimmen. Hierbei werden die Ergebnisse der vorangegangenen Phase mit Hilfe festgelegter Qualitätskriterien überprüft und im Idealfall von externen Gutachtern bewertet. Fällt die Bewertung positiv aus kann die nächste Projektphase begonnen werden und evtl. Geldmittel zur Verfügung gestellt werden, andernfalls müssen Nachbesserungen vorgenommen oder, im schlimmsten Fall, das Projekt abgebrochen werden. Die Meilensteine des Projekts Tokana wurden, wie folgt, erarbeitet und in einem Meilensteinplan dokumentiert:

Tabelle 14: Meilensteinplan des Tokana-Projekts

5.2 Veranschaulichung der Projektphasen

Ein Balkendiagramm eignet sich sehr gut, um die Projektphasen übersichtlich in grafischer Form darzustellen. Die folgende Grafik zeigt den groben Projektverlauf des Projekts Tokana:

Abbildung 7: Grafische Darstellung der Projektphasen (grob)



6. Projektstrukturplan Der Projektstrukturplan (PSP) ist der „Plan der Pläne“ mit dem Ziel einen Gesamtüberblick über alle Aufgaben (Arbeitspakete) des Projektes zu bekommen und ein gemeinsamen Verständnis zu schaffen. Dies wird durch die Reduktion von Komplexität, Schaffung von Transparenz sowie durch die Erkennung von Schwerpunktaufgaben, Zusammenhängen und kritischen Abhängigkeiten erreicht. Nach Definition der DIN 69901-5:2009 ist der Projektstrukturplan eine vollständige, hierarchische Darstellung aller Elemente (Teilprojekte, Arbeitspakete) der Projektstruktur als Diagramm oder Liste. Die Projektgesamtaufgabe ist das Wurzelelement, das hierarchisch an oberster Stelle steht. Ganz unten stehen die Arbeitspakete, die nicht mehr zu unterteilenden Aufgaben darstellen. Projektplanung erfolgt in Stufen. Zuerst wird der PSP erstellt. Daraus werden Arbeitspakete abgeleitet. Es folgt eine Aufwandsschätzung und die Ermittlung von Abhängigkeiten. Daraufhin werden der Ablauf und Termine sowie in der letzten Stufe die Einsatzmittel und Kosten bestimmt. Der Plan wird laufend optimiert. Ergänzende Planungen sind u.a. der interne und externe Kommunikationsplan mit Berichtswegen, Qualitätsplanung, Chancen- und Risikomanagement sowie einer Tooleinsatzplanung. Der PSP ist die Grundlage für sämtliche nachgelagerten Planungen (Ablauf, Termine, Ressourcen, Kosten usw.) und für die Steuerung der Projektdurchführung. Es gibt zwei Vorgehensstrategien für die Erstellung von Arbeitspaketen. Der Top-Down Ansatz beginnt mit dem Gesamtprojekt. Es folgt die Gliederung in Teilprojekte bzw. Hauptaufgaben und eine weitere stufenweise Zerlegung bis die Arbeitspaketebene erreicht ist, nach dem Motto: „vom Groben zum Feinen“. Beim Bottom-Up Ansatz werden zuerst Aufgaben (Brainstorming, Metaplan, Mind Mapping) gesammelt. Daraufhin werden diese nach einem bestimmten Kriterium (Clustern) strukturiert. Der Aufbau der Projektstruktur ist die Hierarchie der Aufgaben. Zuletzt werden fehlende Aufgaben ergänzt und Dubletten entfernt.

6.1.1 Darstellung und Codierung des PSP

Es gibt verschiedene Gliederungsprinzipien für Projektstrukturpläne. Gliederungskriterien des objektorientierte PSP sind alle materiellen und immateriellen Objekte, Komponenten und Bauteile des erwarteten Produktes (alle Liefer- und Leistungsobjekte). Ein Nachteil des objektorientierten PSP ist, dass nicht alle Aufgaben (Funktionen) zum Erreichen des Projektziels (z.B. Projektmanagement) erfasst werden. Beim funktions- bzw. tätigkeitsorientierten PSP werden alle Tätigkeiten, die durchzuführen sind, um das Ergebnisziel zu erreichen als Gliederungskriterium einbezogen. Mangel ist hier die fehlende Komponentenstruktur.



Der phasenorientierte PSP wird nach den einzelnen Arbeitsphasen gegliedert, die nötig sind um das erwartete Ergebnis zu erreichen. Dabei kann man sich am Projektablauf orientieren. In der Praxis sind Mischformen üblich. Gemischtorientierte PSPs kombinieren mehrere Gliederungsprinzipien. Gliederungskriterien sind folglich Objekte, Tätigkeiten und Phasen. Es wird auf jeder horizontalen Strukturierungsebene grundsätzlich nur eine Logik verwenden. Im Projekt Tokana wird ebenfalls ein gemischtorientierter PSP verwendet, da sowohl im objektorientierten als auch im funktionsorientierten PSP nicht alle Komponenten dargestellt werden können. Die Codierung erfolgte auf Basis der Phasen (Anfangsbuchstaben) und einer zusätzlichen eindeutigen Nummer.



Abbildung 8: Gemischtorientierter PSP für das Projekt Tokana



6.2 Arbeitspaketbeschreibung

Arbeitspakete sind die kleinsten Bausteine des Projekts. Ein Arbeitspaket (AP, engl. Work Package, WP) wird als eine in sich geschlossene Aufgabenstellung innerhalb eines Projektes, die bis zu einem festgelegten Zeitpunkt mit festgelegte, Ergebnis und Aufwand vollbracht werden kann, definiert (DIN 69901-5:2009). Die Beschreibung der APs erfolgt mittels AP-Formularen. Kriterien für Arbeitspakete sind, dass jedes AP ist eine Art „Mini-Projekt“ mit Ziel, Deliverable, Dauer, Aufwand, Ressourcen und Kosten ist. Es müssen eindeutig personifizierte Verantwortlichkeiten gegeben sein. Projektleiter und AP-Verantwortlicher definieren das AP. Es muss klare Schnittstellen zu vor- und nachgelagerten Paketen bezüglich Voraussetzungen für die Durchführung geben. Die Abhängigkeiten (zeitlich, logisch) zu anderen APs sollen aufgezeigt werden. Zudem darf es keine Überschneidung mit anderen APs geben.

Tabelle 15: Arbeitspaket Coupon

Arbeitspaket-Formular

Projekt Tokana Projekt-Nr. 1

Arbeitspakettitel: Coupon AP-Verantwortlicher

Hauke, Robert

Ersteller Ann-Kathrin Erstelldatum 16.05.2014

Version 1.0 PSP-Code R13

Vorgänger-APs - Nachfolger-APs -

Ziele des AP Programmierung der Coupons

Voraussetzungen (Input)

Ergebnisse des Navigations- und Sicherheitskonzepts

Aktivitäten / Termine

Deliverables (Output) Programmierte Coupons

Anfangstermin Mon 26.05.14 Dauer 24 Std.

Endtermin Mit 28.05.14 Aufwand 48 Std.

Ressourcen Hauke, Robert Kosten 1680 €



Tabelle 16: Arbeitspaket Storyboard

Arbeitspaket-Formular

Projekt Tokana Projekt-Nr. 1

Arbeitspakettitel: Storyboard AP-Verantwortlicher

Pascal;Ann-Kathrin;Moritz

Ersteller Pascal Erstelldatum 16.05.2014

Version 1.0 PSP-Code K21

Vorgänger-APs Planung, Sicherheitskonzept

Nachfolger-APs Farbe/Form; Dokumentation

Ziele des AP Erstellen von Storyboards zum Veranschaulichen der Abläufe der Nutzerinteraktion

Voraussetzungen (Input)

Ergebnisse aus Planungsphase und Sicherheitskonzepte

Aktivitäten / Termine

Deliverables (Output) Storyboards zur Nutzerinteraktion

Anfangstermin Die 20.05.14 Dauer 4 Std.

Endtermin Die 20.05.14 Aufwand 12 Std.

Ressourcen Pascal;Ann-Kathrin;Moritz

Kosten 420 €

Jedes AP hat einen Projektstrukturcode, was der Übersichtlichkeit dient. Der PSP-Code ist ein Nummerierungssystem, mit dem alle Komponenten des PSP eindeutig gekennzeichnet werden. Aus der Nummerierung wird ersichtlich, zu welcher Ebene das Element gehört. In Tabelle 15 - AP Coupon lautet der PSP-Code „R13“. „R“ kennzeichnet die Realisierungsphase. Für das AP Storyboard in Tabelle 16 gibt es zudem Vorgänger- und Nachfolger-APs. Es gibt verschiedene Stadien, die jedes Arbeitspaket durchläuft. Zuerst werden APs identifiziert. Jedes AP wird bei der PSP-Erstellung ermittelt. Daraufhin werden die APs geplant. Dabei wird die AP-Beschreibung erstellt. Ist das AP beauftragt, so ist der AP-Verantwortliche benannt und die Übertragung des AP an ihn ist erfolgt. Der Status offen bedeutet, dass mit der AP-Bearbeitung noch nicht begonnen wurde. Ist dies jedoch der Fall, ist es in Arbeit. Erledigt ist ein AP, wenn es vollständig bearbeitet wurde. Zuletzt wird jedes Arbeitspaket nach den vereinbarten Kriterien abgenommen.



7. Ablauf- und Terminplanung

Um einen Reibungslosen Ablauf des Projektes zu gewährleisten werden alle auszuführenden Arbeitspakte ausführlich geplant und in einem zusammenhängenden Plan mit festen Terminen versehen. Somit wird der gesamte, geschätzte Verlauf des Projektes klar und eindeutig definiert. Im Verlauf dieser Planung werden eine Vorgangsliste sowie ein vernetzter Balkenplan erstellt. Dies schafft einen klaren Überblick über das gesamte Projekt sowie alle einzeln abzuarbeitenden Arbeitspakete und ihre Abhängigkeiten von einander.

7.1 Vorgangsliste

Nachdem alle notwendigen Arbeitspakte ausführlich, inklusive geschätzter Dauer und Abhängigkeiten, beschreiben wurden, werden diese in einer Vorgangsliste aufgeführt um den vollständigen Realisierungsprozess des Projektes darzustellen. Daraus kann die vollständige Dauer sowie der geplante Ablauf des Projekts ermittelt werden.

Tabelle 17: Vorgangsliste – Tokana



7.2 Vernetzter Balkenplan oder berechneter Netzplan

Durch die Vorgangsliste kann eine genaue Planung aller Tätigkeiten über den Projektverlauf hinweg geschehen. Durch die Abhängigkeiten und jeweilige geplante Dauer der Arbeitspakte können nun konkrete Termine für den Abschluss von Projektphasen festgelegt werden. Anhand von diesem Plan kann der geplante Projektverlauf im Voraus überblickt, sowie im Nachhinein der tatsächliche Verlauf mit dem geplanten verglichen werden. Der vernetzte Balkenplan gibt einen graphischen Überblick über geplante zeitliche Abläufe und Abhängigkeiten zwischen den Arbeitspaketen.

Tabelle 18: Vernetzter Balkenplan - Tokana



8. Einsatzmittel- / Kostenplanung Fünfte und letzte Stufe der Projektplanung ist die Planung von Ressourcen und Kosten (nach 1. Projektstrukturplan, 2. Arbeitspaketen, 3. Aufwandsschätzung und Abhängigkeiten, 4. Ablauf und Termine). Anschließend wird der Plan optimiert. Ergänzend zu diesen Planungen können Kommunikationsplanung, Qualitätsplanung, Chancen und Risikomanagement sowie Tooleinsatzplanungen durchgeführt werden. Ressourcenplanung bzw. Einsatzmittelplanung hat die Ermittlung der für die Umsetzung des Projektes notwendigen Ressourcen, sowohl qualitativ als auch quantitativ, zum Ziel. Nur wenn die Ressourcen zur richtigen Zeit, am richtigen Ort und mit der nötigen Qualität und Quantität zur Verfügung stehen, ist Einhalten des Terminplans möglich. Grundsätzlich wird unterschieden zwischen Personellen Ressourcen und Sachmitteln. Eine Engpass-Ressource ist eine für das das Projekt besonders wichtig, steht jedoch aufgrund von Engpässen nur eingeschränkt zur Verfügung. 8.1 Einsatzmittelbedarf / Einsatzmittelplan

Das Vorgehen bei der Ressourcenplanung 1. Bedarf ermitteln: SOLL-Bedarf pro AP 2. Ressourcen Verfügbarkeit feststellen: Verfügbare IST-Kapazitäten im entsprechenden

Zeitraum 3. Ressourcenplan erstellen: Zuordnung von APs und Ressourcen 4. Verfügbarkeit der Ressourcen absichern: Kommunikation mit Linienverantwortlichen

Bei der Personalressourcenplanung muss die Qualifikationen berücksichtigt werden. Deshalb werden zuerst Rollen definiert für die dann die entsprechenden Personen ausgesucht werden.

Tabelle 19: Rollen



Tabelle 20: Ressourcenverteilung

Die Ressourcenauslastung muss überprüft werden, z.B. mit einem Ressourcen-Histogramm. Ist für einen Mitarbeiter z.B. an einem Tag 8 Stunden Arbeit an zwei Arbeitspakten vorgesehen, ist dies an der Ganglinie zu sehen, welche den Auslastungsverlauf anzeigt.

Abbildung 9: Ressourcen-Histogramm



In diesem Fall ist ein Kapazitätsausgleich nötig. Grundsätzliche Maßnahmen hierzu sind:

Nutzung von Puffern

Zusätzliches Personal

Externe Spezialisten

Reduktion des Projektumfangs

Verschiebung des Projektendtermins Es wird unterschieden zwischen Termintreuer Ressourcenplanung, bei welcher die Erforderlichen Ressourcen ermittelt werden um den vorgegebenen Termin einzuhalten, und Kapazitätstreuer Ressourcenplanung, bei der das Projekt so früh wie möglich, mit den gegebenen Ressourcen abgeschlossen wird. 8.2 Projektkosten

Beispiele für Kostenarten:

Personalkosten

Reisekosten

Schulungskosten

Externe Beratung

Hardware

Software

Verbrauchsmaterial

Finanzmittel Ein Kostenplan stellt die für ein Projekt anfallenden Kosten mit Zeitlichem Verlauf dar. Dieser setzt sich aus den Kosten für die Ressourcen für jedes APs zusammen.

Tabelle 21: Kostenplan



Folgende Darstellungen der Kosten über die Zeit sind möglich:

Der Kostengang

Abbildung 10: Kostengang

Kummulierte Kosten

Abbildung 11: Kummulierte Kosten



Kostenarten

Abbildung 12: Kostenarten

Fälligkeit der Kosten

Die Verteilung der Kosten sollte beachtet werden, kann es doch zu massiven Spitzen kommen. Bei gleichmäßiger Verteilung über die Zeit spricht man von Gleichverteilung. Fallen die Kosten am Anfang des Projektes an, spricht man von der Anfangsverteilung. Entsprechend von der Endverteilung, wenn die Kosten am Ende auftreten.

Kosten für Tokana

Bei einem Stundenlohn von 35€ sah er Kostenstatus am 14.4. wie folg aus:

Abbildung 13: Kostenstatus

0,00 €

500,00 €

1.000,00 €

1.500,00 €

2.000,00 €

2.500,00 €

3.000,00 €

3.500,00 €

4.000,00 €

4.500,00 €

5.000,00 €

Moritz Albert Pascal Becker Ann-KathrinKraft

RobertSchmauder

HaukeThorenzIst-Kosten Restkosten



Generell sind für Tokana Kosten von 20743,33€ angesetzt. Diese fallen vollständig auf Personalkosten

Abbildung 14: Kostenart

Art: Arbeit

Projektbericht - wuecampus2.uni-wuerzburg.de · K1 Keine laufenden Kosten während der Entwicklung...

Documents

Transcript of Projektbericht - wuecampus2.uni-wuerzburg.de · K1 Keine laufenden Kosten während der Entwicklung...