Transfernachweis

zur Zulassung zum Zertifizierungsverfahren

 

von Diplom-Informatiker (FH)
Günter Reisacher

GRIT-Consult

Am Mühlenweiher 22

D-88299 Leutkirch

 

 

 

 

MPV-Tool

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1     Projekt / Projektziele............................................................................................. 5

1.1      Projektbeschreibung.......................................................................................................... 5

1.1.1      Projektsteckbrief......................................................................................................... 5

1.1.2      Rollenbeschreibung.................................................................................................... 6

1.1.3      Unternehmensbeschreibung...................................................................................... 6

1.2      Zielbeschreibung / Zielhierarchie....................................................................................... 7

1.2.1      Ziele............................................................................................................................ 7

1.2.2      Zielhierarchie.............................................................................................................. 9

1.2.3      Zielbeziehungen.......................................................................................................... 9

1.2.3.1     Standardreporterstellung – Excelexport der Ergebnisse............................................... 10

1.2.3.2     Einhaltung Endetermin – Einhaltung des Projektbudgets............................................. 10

1.2.3.3     Zugang für alle Einkäufer – Generische Reports.......................................................... 10

2     Projektumfeld, Stakeholder.......................................................................... 11

2.1      Projektumfeld, Umfeldfaktoren........................................................................................ 11

2.1.1      Projektumfeldanalyse............................................................................................... 11

2.1.2      Schnittstellenbeschreibung Projekt-Projektumfeld.................................................. 12

2.2      Stakeholder (Interested Parties)...................................................................................... 12

2.2.1      Stakeholderbeschreibung......................................................................................... 12

2.2.2      Stakeholderanalyse.................................................................................................. 15

2.2.3      Stakeholdersteuerung.............................................................................................. 16

3     Risikoanalyse............................................................................................................... 17

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

3.2      Bewertung der Risiken und Maßnahmen zur Risikobegegnung..................................... 19

4     ProjektorganisatiON............................................................................................. 24

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

4.1.1      Matrixorganisation des Projektes MPV-Tool............................................................. 25

4.1.2      Rollenbeschreibung der Projektrollen...................................................................... 25

4.1.2.1     Projektleiter............................................................................................................. 25

4.1.2.2     Chefentwickler......................................................................................................... 26

4.1.2.3     Entwickler............................................................................................................... 27

4.1.2.4     Analyst................................................................................................................... 27

4.1.2.5     Fachbereichsleiter................................................................................................... 28

4.1.2.6     Mitarbeiter Fachbereich Einkauf – System and Tools.................................................. 28

4.1.2.7     Repräsentanten der Anwender (Einkäufer).................................................................. 28

4.2      Entscheidungsgremien, Eskalation................................................................................. 29

5     PhasenplanunG.......................................................................................................... 30

5.1      Beschreibung der Projektphasen und der Meilensteine.................................................. 30

5.1.1      Beschreibung der Projektphasen............................................................................. 30

5.1.2      Beschreibung der Meilensteine................................................................................ 31

5.2      Veranschaulichung der Projektphasen........................................................................... 32

6     ProjektstrukturplaN.......................................................................................... 33

6.1      Darstellung und Codierung des PSP.............................................................................. 34

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

6.2.1      Lastenheft erstellen.................................................................................................. 35

6.2.2      Fachlich-technischer Test........................................................................................ 36

7     Ablauf- und TerminplanunG............................................................................... 37

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

7.2      Vernetzter Balkenplan oder berechneter Netzplan......................................................... 39

8     Einsatzmittel- / Kostenplanung....................................................................... 40

8.1      Einsatzmittelbedarf / Einsatzmittelplan........................................................................... 40

8.1.1      Einsatzmittel und deren Qualifikation....................................................................... 40

8.1.2      Einsatzmittelbedarf................................................................................................... 41

8.1.3      Einsatzmittelplanung................................................................................................ 43

8.2      Projektkosten................................................................................................................... 45

8.2.1      Arbeitskostenanfall................................................................................................... 45

8.2.2      Sachmittelkostenanfall............................................................................................. 47

8.2.3      Gesamtkostenanfall.................................................................................................. 49

9     Soziale Kompetenz.................................................................................................... 51

9.1      Teamarbeit (Teambildung, Konflikte).............................................................................. 51

9.1.1      Theorie...................................................................................................................... 51

9.1.2      Praxisbeispiel aus diesem Projekt........................................................................... 52

9.1.3      Verbesserungsvorschlag......................................................................................... 52

9.2      Führung (Führungsstile, Entscheidungsfindung)............................................................ 52

9.2.1      Theorie...................................................................................................................... 52

9.2.2      Praxisbeispiel aus diesem Projekt........................................................................... 54

9.2.3      Verbesserungsvorschlag......................................................................................... 54

10       Wahlelemente......................................................................................................... 55

10.1    Projektstart, Projektende................................................................................................. 55

10.1.1    Theorie...................................................................................................................... 55

10.1.1.1   Projektstart............................................................................................................. 55

10.1.1.2   Projektende............................................................................................................. 55

10.1.2    Praxisbeispiel aus diesem Projekt........................................................................... 55

10.1.3    Verbesserungsvorschlag......................................................................................... 56

11       AnhanG.......................................................................................................................... 57

11.1    Abkürzungsverzeichnis................................................................................................... 57

11.2    Glossar............................................................................................................................ 58

11.3    Abbildungs- / Tabellenverzeichnis................................................................................... 58

12       Anlagen........................................................................................................................ 60

12.1    Anlagenverzeichnis......................................................................................................... 60

12.2    Anlage 1: Verwendete Literatur....................................................................................... 60

 

1             Projekt / Projektziele

1.1               Projektbeschreibung

Die Projektbeschreibung soll kurz und knapp die wichtigsten Merkmale des Projektes darlegen. Man könnte die Projektbeschreibung auch als Management-Summary bezeichnen.

 

1.1.1           Projektsteckbrief

 

Projektbezeichnung:

Erstellung eines Software-Tools um Materialpreisveränderungen im Einkauf darzustellen

Projektumfeld (WO):

Der Zentraleinkauf des Unternehmens beauftragt die betriebsinterne IT das benötigte Software-Tool zu erstellen, um hiermit Berichte für die Geschäftsführung zu erstellen und die Materialpreisveränderungen zu verfolgen

Projektinhalt (WAS):

-          Analyse der Anforderungen

-          Erstellung Lastenheft

-          Erstellung Pflichtenheft

-          Implementierung des Tools

-          Testsystem zur Verfügung stellen

-          Dokumentation des Tools

-          Produktivsystem zur Verfügung stellen

-          Erstellung Benutzerhandbuch

-          Schulung der Key-User

 

 

Plan-Termine:                             Start: 01.01.2008                           Ende: 02.02.2009

Zwischentermine:                                  29.04.2008: Planung abgeschlossen

                                                               17.10.2008: Implementierung abgeschlossen

 

Projektaufwand in MT:                                                                       davon Projektmgt:

interne Mitarbeiter:                                186                                           23

externe:                                                 50                                                                                     

 

Projektbeteiligte:

Leiter Fachbereich, Mitarbeiter Fachbereich – Systems and Tools, Analyst, Leiter Entwicklung, Mitarbeiter Entwicklung, Projektleiter, Leiter IT

 

Machtpromotor:
Leiter Einkaufsabteilung

 

Fachpromotor:

Leiter Fachbereich

 

 

Projektrisiken/Behinderungen:
- ungeplanter Zusatzaufwand

- Ressourcenengpass /-wegfall

Tabelle 1: Projektbeschreibung MPV



 

1.1.2           Rollenbeschreibung

Meine Rolle im Projekt MPV ist:

-          Projektleiter

 

In der Rolle Projektleiter bin ich verantwortlich für:

-          Projektplanung

-          Termineinhaltung

-          Budget-Einhaltung

-          Steuerung der Projektbeteiligten

-          Informieren der Projektbeteiligten

-          Reporting an die Führungskräfte

 

 

1.1.3           Unternehmensbeschreibung

Das Unternehmen, in welchem dieses Projekt abgewickelt wurde, stellt hauptsächlich Bordnetzsysteme für die Automobilindustrie her. Dies jedoch für nahezu alle Automobilhersteller weltweit.

Die Entwicklung der Bordnetzsysteme findet in Deutschland statt. Die Produktion der Bordnetzsysteme hingegen wird weltweit in den Produktionswerken erledigt.

 

Das Unternehmen hat eine eigene IT-Abteilung. Diese erstellt unter anderem für die internen Abteilungen, wie z.B. Logistik, Qualitätsmanagement oder Einkauf Software-Tools. In dem hier beschriebenen Projekt erstellt die interne IT-Abteilung ein Software-Tool für den internen Zentraleinkauf.


1.2               Zielbeschreibung / Zielhierarchie

 

1.2.1           Ziele

Die Projektziele müssen festgelegt werden, dass sich alle Projektmitarbeiter im Klaren sind, was das Ergebnis des Projektes sein soll. Hierzu müssen die Ziele als erstes formuliert werden, es müssen die Messkriterien für die einzelnen Ziele festgelegt und die Ziele müssen kategorisiert und priorisiert werden um die Ziele genau zu spezifizieren und den Stellenwert zu bestimmen.

 


ID

Zielformulierung

Messkriterium

Zie-le[1]

Klas-se[2]

Prio[3]

MKS[4]

Z1

Auswertung der Daten aller Werke

Es müssen die Daten aller Werke für die Auswertungen zur Verfügung stehen

E

F

1

M

Z2

Vergleich beliebiger Zeiträume von Wareneingängen

Es müssen zwei beliebige Zeiträume von Wareneingängen bezüglich der Einkaufspreise verglichen werden können

N

F

1

M

Z3

Erstellung von Standardreports für das Reporting zur Geschäftsleitung

Die Anwendung muss Standardreports zum Reporting für die Geschäftsführung zur Verfügung stellen

N

F

1

M

Z4

Überprüfung des Einkaufsziels anhand der Anwendung

Die Anwendung muss die Materialpreisveränderung des Berichtsjahres im Vergleich zum Vorjahr für den kompletten Einkauf liefern

N

F

1

M

Z5

Exakte und richtige Berechnung der Materialpreisveränderung

Die Materialpreisveränderung muss anhand der vorgegebenen Berechnungsformeln berechnet werden

E

F

1

M

Z6

Erstellung von generischen Reports um die Einkäufer bei der Kontrolle der Materialpreisveränderung zu unterstützen

Die Anwendung muss die Möglichkeit anbieten, generische Reports zu erstellen

N

F

2

M

Z7

Einhaltung des Endetermins

Der Endetermin 02.02.2009 darf nicht überschritten werden

V

Z

2

M

Z8

Benutzerhandbuch erstellen

Ein Benutzerhandbuch muss erstellt werden, welches jede Funktion der Anwendung detailliert beschreibt

V

F

2

M

Z9

Einhaltung der definierten Meilensteine

Die vorgegebenen Meilensteine müssen eingehalten werden bezügl. Termin, Kosten und Leistung

V

Z

2

M

Z10

Dokumentation der Anwendung erstellen

Die Anwendung muss entsprechend den Unternehmens-Richtlinie „Dokumentation von Softwareanwendungen“ dokumentiert werden

V

F

3

M

Z11

Die Daten müssen Tagesaktuell sein

Die Daten vom Vortag müssen in den tagesaktuellen Reports vorhanden sein

N

F

3

M

Z12

Einhaltung des veranschlagten Budgets für das Projekt

Das Projektbudget von ca. 200.000,- Euro darf nicht überschritten werden

V

K

3

S

Z13

Erstellung der Reports ohne manuellen Zusatzaufwand

Sowohl die Standardreports als auch die generischen Reports müssen ohne manuellen Zusatzaufwand von der Anwendung erstellt werden

N

F

3

S

Z14

Ergebnisse müssen nach Excel exportiert werden können

Der angezeigte Report muss 1:1 in Excel abgebildet sein

E

F

4

M

Z15

Einhaltung des Starttermins

Der Starttermin 01.01.2008 muss eingehalten werden

V

Z

4

S

Z16

Browserbasierte Anwendung

Die Anwendung muss in einem Internet-Browser laufen

E

 

5

S

Z17

Zugang für alle Einkäufer zur Anwendung

Alle Einkäufer müssen auf die Anwendung zugreifen können

N

S

2

M

 

Tabelle 2: Zielbeschreibung


1.2.2           Zielhierarchie

Über die Zielhierarchie kann verdeutlicht werden, welches der Ziele das Globalziel ist, was es in dem Projekt für Zielklassen gibt und wie diese weiter verfeinert werden in Zielunterklassen. Ebenso sind hier, in einer übersichtlichen Form, die Zielformulierungen und das zugehörige Maß der Zielerreichung dargelegt. Die grafische Darstellung ermöglicht es, einen sehr schnellen Überblick über die Ziele zu erhalten.

Abbildung 1: Zielhierarchie

1.2.3           Zielbeziehungen

Es gibt drei Arten von Zielbeziehungen:

  1. Komplementärbeziehung
    Komplementärbeziehung bedeutet, dass ein größerer Erfüllungsgrad des Zieles A auch zu einem besseren Erfüllungsgrad beim Ziel B führt.

  2. Konkurrenzbeziehung
    Konkurrenzbeziehung bedeutet, dass ein größerer Erfüllungsgrad beim Ziel A nur erreicht werden kann, wenn beim Ziel B Abstriche gemacht werden. Hier müssen die konkurrierenden Ziele priorisiert werden, dass wenn nötig, beim entsprechenden Ziel der Erfüllungsgrad erhöht und beim jeweils richtigen anderen dann der Abstrich gemacht wird.

  3. Neutralbeziehung
    Neutralbeziehung bedeutet, dass mehrere Ziele unabhängig voneinander erfüllt werden können. Bezüglich des Erfüllungsgrades sind diese Ziele somit voneinander unabhängig.


1.2.3.1              Standardreporterstellung – Excelexport der Ergebnisse

Alle Standard Reports welche mit der MPV-Anwendung erstellt werden können, müssen auch nach Excel exportiert werden können.

Wird ein Standard Report verändert, muss entsprechend der Excel Export auch abgeändert werden. Der Excel-Export muss immer ein 1:1 Abbild des Standard Report Ergebnisses darstellen. Das heißt, dass der Excel-Export nur entsprechend geändert werden darf, wenn sich das Ergebnis des Standard Reports ändert.

Dies ist ein Komplementärziel, da sich der Excelreport immer auch ändert, wenn sich der Standardreport ändert.

 

1.2.3.2              Einhaltung Endetermin – Einhaltung des Projektbudgets

Die Einhaltung des Endetermins kann unter Umständen nur durch die Erhöhung des Projektbudgets gewährleistet werden.

Wird während der Projektlaufzeit der Projektumfang geändert oder wird festgestellt, dass gewisse Teile des Projektes mit zu geringem Aufwand geschätzt wurden, zieht dies entweder eine Verschiebung des Endetermins nach sich oder eine Erhöhung des Projektbudgets, um evtl. mit zusätzlichen Mitarbeitern den erhöhten Aufwand abzuleisten, um den Endetermin trotzdem halten zu können.
Der Termin hat hier im Projekt MPV-Tool die höhere Priorität. Dieser ist zwingen einzuhalten, auch wenn hierdurch die Projektkosten erhöht werden.

Dies ist ein Konkurrenzziel, da die Einhaltung des Terminziels der Einhaltung des Projektbudgets entgegen wirkt.

 

1.2.3.3              Zugang für alle Einkäufer – Generische Reports

Die generischen Reports sollen von den Einkäufern benutzt werden, um zu kontrollieren, wie sich der Materialpreis der Teile, die der jeweilige Einkäufer zu verantworten hat, verändert hat. Hierzu benötigt jeder Einkäufer Zugang zum System, um die Funktionalität der generischen Reports benutzen zu können, da die generischen Reports nur im System MPV erstellt werden können.

Wenn ein Einkäufer keinen Systemzugang hat, dann kann er auch die generischen Reports nicht benutzen und somit seinen „Erfolg“ nicht kontrollieren.

Dies ist ein Neutralziel, da es keinerlei Auswirkung auf die generischen Reports hat, wie viele Einkäufer Zugriff auf die Anwendung haben. Die generischen Reports bleiben in ihrer Funktionalität hiervon unberührt. Ebenso können die generischen Reports beliebig geändert werden, unabhängig von der Anzahl an Benutzerzugängen.

 

 

2             Projektumfeld, Stakeholder

2.1               Projektumfeld, Umfeldfaktoren

Das Projektumfeld ist die Umgebung in der das Projekt durchgeführt wird. Diese Umgebung beeinflusst das Projekt bzw. ist von dessen Auswirkungen betroffen.

2.1.1           Projektumfeldanalyse

Die Projektumfeldanalyse zeigt, wie sich das Umfeld des Projektes darstellt. Es werden alle Umfeldfaktoren aufgelistet und diese werden dann nach direkt/indirekt und sozial/sachlich kategorisiert. Danach werden die Umfeldfaktoren als Portfolio dargestellt, was einen sehr schnellen Überblick über das Projektumfeld bietet.

 

 

Abbildung 2: Projektumfeldanalyse Portfolio

 


2.1.2           Schnittstellenbeschreibung Projekt-Projektumfeld

Die Schnittstellenbeschreibung des Projektes spezifiziert das Projektumfeld bezüglich der Schnittstellen genauer. Die Umfeldfaktoren werden typisiert, die Beziehung zum Projekt wird festgehalten und die Schnittstelle an sich kurz beschrieben. Dies gibt einen groben Überblick über die vorhandenen Projektschnittstellen.

 

ID

Umfeldfaktor

D/I[5]

Typ

Beziehung zum Projekt

Schnittstelle zum Projekt

SU1

IT-Leitung

D

Sozial-ökonimisch

Stellt Projektmitarbeiter größtenteils bereit

Das Projekt wird hauptsächlich mit IT-Mitarbeitern durchgeführt

SU2

Einkauf

D

Ökonomisch

Auftraggeber

Der Einkauf hat das Produkt beauftragt

SU3

Einkäufer

D

Sozial

Sind Teil des Projektes und Nutzer des Produktes

Die Einkäufer werden die Nutzer des Produktes sein und liefern somit die Anforderungen hierfür

SU4

Einkaufsleitung

D

Ökonomisch

Hat großes Interesse am Produkt, da hierdurch genauere Zahlen reportet werden können.

Stellt das Projektbudget bereit

SU5

Geschäftsführung

I

Ökonomisch

Hat großes Interesse am Produkt, da hierdurch genauere Zahlen reportet werden können.

Die Geschäftsführung erhält aus dem MPV-Tool das Einkaufsergebnis und kann hierüber das Einkaufsziel überwachen

SU6

Entwickler

D

Technisch

Erstellen das Produkt

Sind Teil des Projektes

SU7

Betriebsrat

D

Sozial

Sind Berater

Beraten und überwachen Produkterstellung bezügl. Betriebsratsanforderungen

Tabelle 3: Schnittstellenbeschreibung Projekt-Projektumfeld

 

 

 

2.2               Stakeholder (Interested Parties)

Stakeholder sind Personen oder Personengruppen, die am Projekt beteiligt bzw. am Projekt interessiert oder von den Auswirkungen des Projektes betroffen sind. Dies sind sozusagen alle Personen die mit dem Projekt etwas zu tun haben.

2.2.1           Stakeholderbeschreibung

Die Stakeholderbeschreibung ist eine Übersicht über alle Stakeholder und deren Stellung zum Projekt. Die Stakeholder werden erst gelistet, und dann entsprechend den Kriterien Erwartungen/Befürchtungen, Konfliktpotenzial, Macht/Einfluss auf das Projekt und Einstellung bzw. Klima/Stimmung zum/gegenüber dem Projekt, bewertet.

 

ID

Stakeholder

E – Erwartungen /
B – Befürchtungen

Konflikt-potenzial[6]

Macht Einfluss[7]

Einstellung[8]

SH1

IT-Leitung

E – Projekt muss erfolgreich durchgeführt werden

E – Kunde Einkauf muss zufrieden gestellt werden

E – Statusberichte könnender IT-Leitung regelmäßig vorgelegt werden

E – Probleme werden frühzeitig an die IT-Leitung heran getragen

+/-

4

5

SH2

Einkaufsleitung

E – Schnelle, kostengünstige Durchführung des Projektes

E – Geringer Aufwand um qualitativ hochwertiges Reporting zu erstellen

E – Probleme werden rechtzeitig kommuniziert

+

4

4

SH3

Fachbereichsleiter

E – Schnelle, erfolgreiche und kostengünstige Durchführung des Projekts

E – Produkt muss schnellstens den Einkäufern zur Verfügung gestellt werden

E – Anforderungen an das Produkt müssen erfüllt sein

+

4

4

SH4

Mitarbeiter Fachbereich – Systems and Tools

E – Anforderungen müssen umgesetzt werden

B – Wird nicht genug informiert

B – Muss sehr viel Zeit aufwende für das Projekt

B – Kommunikation zwischen Fachbereich und IT funktioniert nicht

+

4

4

SH5

Chefentwickler

E – Projekt muss erfolgreich durchgeführt werden

B – Muss viele Überstunden leisten

B – Muss wegen der Projektarbeit Teile seiner Linientätigkeiten abgeben

+

4

3

SH6

Führungskraft
Entwickler

B – Projekt belegt die Entwickler-Ressourcen zu stark

B – Hat zu geringen Einfluss auf die eigenen Ressourcen bezügl. Einsatz

B – Wird zu wenig eingebunden in das Projekt

++

3

2

SH7

Geschäftsführung

E – Projekt muss erfolgreich mit minimalem Kosten- und Ressourceneinsatz durchgeführt werden

+/-

3

4

SH8

Führungskraft
Analyst

E – Projekt muss erfolgreich durchgeführt werden

E – Analyst muss trotzdem seinen Linientätigkeiten nachkommen

+/-

3

4

SH9

Analyst

B – Anforderungen werden ihm nur unvollständig mitgeteilt

B – Entwickler bauen Software aus technischen Gründen anderst als vorgegeben

B – Fachbereichsansprechpartner sind unkooperativ

B – Es gibt im Fachbereich keinen kompetenten Ansprechpartner

B – Ansprechpartner im Fachbereich hat kein Interesse am Projekterfolg

+/-

3

4

SH10

Einkäufer

E – Produkt soll schnellstens fertig sein

E – Produkt muss sehr einfach zu bedienen sein

E – Produkt muss sehr schnell, qualitativ sehr hochwertige Ergebnisse liefern

B – Es ist immer noch ein erheblicher manueller Aufwand erforderlich um die Reports den Anforderungen der Einkäufer entsprechende zu haben

+

3

3

SH11

Interne Entwickler

E – Projekt muss erfolgreich durchgeführt werden

B – Muss viele Überstunden leisten

B – Muss wegen der Projektarbeit Teile seiner Linientätigkeiten abgeben

+

2

4

SH12

Externe Entwickler

E – Projekt muss erfolgreich durchgeführt werden

B – Wird nicht integriert und entsprechend informiert

-

2

3

SH13

Firma der externen Entwickler

E – Projekt muss erfolgreich durchgeführt werden.

B – Externer Mitarbeiter wird schlecht integriert und nicht genügend informiert.

--

1

3

SH14

Personal-

abteilung

E – Weiterqualifizierung des Mitarbeiters

--

1

3

SH15

Betriebsrat

E – Es dürfen keine Daten gespeichert werden, aus welchen die Leistung eines Anwenders abgelesen werden kann.

E – Projektmitarbeiter müssen sich an die geregelten Arbeitszeiten halten.

-

1

3

Tabelle 4: Stakeholderbeschreibung

 

 

2.2.2           Stakeholderanalyse

Die Stakeholderanalyse wird in der Projektstart-Phase durchgeführt. Diese ist notwendig, um die unterschiedlichen Erwartungen bzw. Befürchtungen der Stakeholder an das Projekt herauszufinden. Die grafische Darstellung gibt eine schnelle Übersicht darüber, auf welche Stakeholder genau geachtet werden muss. Nämlich jene, die im 1. Quadranten in der Portfoliodarstellung gelistet sind. Jene Stakeholder haben ein hohes Konfliktpotenzial und zusätzlich hohen Einfluss auf das Projekt. Für diese müssen entsprechende Steuerungsmaßnahmen erarbeitet werden.

 

Abbildung 3: Stakeholderanalyse

2.2.3           Stakeholdersteuerung

In der Stakeholdersteuerung wird festgelegt, was zu tun ist, um die entsprechenden Stakeholder zu steuern. Hier wird besonderes Augenmerk auf die Stakeholder gelegt, welche in der Stakeholderanalyse im 1. Quadranten gelistet sind. Die Maßnahmen sind hauptsächlich Kommunikations-Maßnahmen.

 

ID

Stakeholder

Maßnahmen zur Steuerung der Stakeholder

S1

IT-Leiter

à regelmäßiger Statusbericht

à Status Meetings

S2

Einkaufsleiter

à regelmäßiger Statusbericht

à Status Meetings

S3

Fachbereichsleiter

à regelmäßiger Statusbericht

à Status Meetings

à informelle Treffen

S4

Mitarbeiter Fachbereich – Systems and Tools

à regelmäßiger Statusbericht

à Status Meetings

à informelle Treffen

à Vier-Augen-Gespräch

S5

Chefentwickler

à regelmäßiger Statusbericht

à Status Meetings

à informelle Treffen

à Vier-Augen-Gespräch

S6

Führungskraft Entwickler

à regelmäßiger Statusbericht

à informelle Treffen

S7

Geschäftsführung

à über Projektfortschritt informieren (Infoveranstaltung)

S8

Führungskraft Analyst

à regelmäßiger Statusbericht

à informelle Treffen

S9

Analyst

à regelmäßiger Statusbericht

à Status Meetings

à informelle Treffen

à Vier-Augen-Gespräch

à Kummerkasten

S10

Einkäufer

à über Projektfortschritt informieren (Infoveranstaltung)

S11

Interne Entwickler

à regelmäßiger Statusbericht

à Status Meetings

à informelle Treffen

à Vier-Augen-Gespräch

à Kummerkasten

S12

Externe Entwickler

à regelmäßiger Statusbericht

à Status Meetings

à Vier-Augen-Gespräch

à Kummerkasten

S13

Firma der externen Entwickler

à Feedback über Zufriedenheit mit externem Mitarbeiter

à regelmäßiger Status über Projektdauer

S14

Personalabteilung

à über Projekt informieren (Infoveranstaltung)

S15

Betriebsrat

à über Projekt informieren (Infoveranstaltung)

 

Tabelle 5: Stakeholdersteuerung

3             Risikoanalyse

In der Risikoanalyse werden die potenziellen Projektrisiken gelistet, entsprechend bewertet und die Maßnahmen zur Vorbeugung bzw. zur Korrektur erarbeitet. Dies ist notwendig, um die potenziellen Risiken zu erfassen, einschätzen zu können und bei bedarf sofort die entsprechenden Maßnahmen einzuleiten.

3.1               Erfassung, Klassifizierung und Beschreibung der Risiken

Die Risiken müssen als erstes erarbeitet werden, um zu wissen, welche potenziellen Risiken für das Projekt bestehen. Diese werden danach klassifiziert in terminlich, wirtschaftlich und Umfeld um einschätzen zu können, welches Risiko sich dahinter verbirgt. Anschließend werden die möglichen Ursachen der potenziellen Risiken erarbeitet. Dies ist nötig, um im nächsten Schritt die Eintrittswahrscheinlichkeit, die Schadenshöhe, den Risikowert und die entsprechenden Maßnahmen zu erarbeiten.

 

ID

Risiko

Klassi-fizierung

Ursache

R1

Kapazitätenwegfall

terminlich

wirtschaftlich

a) Interner Mitarbeiter wird aus dem Projekt abgezogen und nicht ersetzt

b) Externer Mitarbeiter verlässt das Projekt. Aus diesem Grund muss ein neuer Mitarbeiter eingearbeitet werden.

c) Interner Mitarbeiter erkrankt für längere Zeit und kann nicht ersetzt werden

R2

Budgetüberschreitung

wirtschaftlich

a) Zu knappe Kostenschätzung

b) Bei der Kostenschätzung wurden Teile vergessen zu schätzen

R3

Konflikte im Projektteam

Umfeld

Projektmitarbeiter verstehen sich nicht

R4

Nicht entsprechend qualifizierte Projektmitarbeiter

Umfeld

terminlich

wirtschaftlich

Es wurden für das Projekt Mitarbeiter bereit gestellt, welche nicht die passenden Qualifikationen besitzen.

R5

Datenimport ist nicht performant genug

technisch

Der Import der Daten von den Datenbanken der Werke in die Datenbank der MPV-Anwendung, kann nicht in einer Nacht durchgeführt werden

R6

Anwendung ist nicht performant genug

technisch

Aus der großen Menge an Daten, kann von der Anwendung nicht in einer, für den Anwender akzeptablen Zeit, ein Report erstellt werden. Dies würde die Akzeptanz der Anwendung sehr verschlechtern.

R7

Anwendung wird nicht akzeptiert

Umfeld

Die Anwendung erfüllt nicht die Anforderungen der Anwender.

R8

Terminverzug

terminlich

Benötigte Informationen werden vom Fachbereich wesentlich verspätet geliefert.

R9

Datenbankserver fällt aus

technisch

wirtschaftlich

a) Datenbankserver fällt durch Speicherfehler aus. Dadurch wird die Datenbank zerstört.

b) Datenbankserver ist irreparabel zerstört (Hardware).

R10

Anwendung entspricht nicht den Anforderungen

terminlich

wirtschaftlich

Es wurde eine Anwendung entwickelt, die teilweise nicht den geforderten Anforderungen entspricht

R11

Schnittstellenprobleme

technisch

Die Schnittstelle von den Werken zum MPV-DB-Server funktioniert nicht. Es kommen nicht alle benötigten Daten im MPV-DB-Server an.

R12

Anforderungsanalyse wird vom Fachbereich nicht ausreichend unterstützt

terminlich

Der Fachbereich sieht es als lästige Pflicht an, die Anforderungen für die Anwendung bereit zu stellen und nimmt diese Tätigkeit nur sehr rudimentär wahr.

R13

Abnahme des Produktes wird hinausgezögert

terminlich

Die Abnahme des Produktes wird vom Fachbereich hinausgezögert.

R14

Statusberichte werden nicht geliefert

terminlich

Es kann ein Zeitverzug zu spät erkannt werden, da der Status hierüber dem Projektleiter nicht bekannt ist.

R15

Es wird zu wenig und nur oberflächlich getestet

terminlich

wirtschaftlich

Es wird während der Testphase noch entwickelt und somit nur sehr ungenügend getestet.

 

Tabelle 6: Risikobeschreibung

 

 

 


3.2               Bewertung der Risiken und Maßnahmen zur Risikobegegnung

Die Risiken, welche in der Risikobeschreibung gefunden wurden, werden hier nun bewertet, bezüglich Eintrittswahrscheinlichkeit, Schadenshöhe und Risikowert und mögliche Maßnahmen erarbeitet. Weiterhin werden die Werte Kosten der Maßnahme, Eintrittswahrscheinlichkeit nach einleiten der Maßnahme, Schadenshöhe nach einleiten der Maßnahme und der Risikowert nach einleiten der Maßnahme erarbeitet. Schlussendlich wird dann entschieden, ob eine Maßnahme aufgrund der berechneten Werte eingeleitet würde oder nicht.

 

ID

Risiko-beschreibung

EW[9]
%

SH[10]
T€

RW[11]
T€

P – präventive /

K – kurative
Maßnahme

KM

T€[12]

EW-M

%[13]

SH-M

T€[14]

RW-M

T€[15]

M-û/ü[16]

RB1

R7

Anwendung wird nicht akzeptiert

20

100

20

P – Anwender immer wieder über den aktuellen Stand der Anwendung in Infoveranstaltungen informieren und deren Verbesserungsvorschläge einholen und wenn möglich einarbeiten

 

K – Heraus finden, warum die Anwendung nicht akzeptiert wird, und diese Probleme versuchen zu beheben

2

 

5

 

100

 

5

 

ü

 

RB2

R6

Anwendung ist nicht performant genug

30

20

6

P – Bei der Architektur schon auf die Performance ein großes Augenmerk legen.

P – Mit den einzelnen Komponenten ausreichende Lasttests durchführen

 

K – „Flaschenhälse“ ausfindig machen und diese Komponenten entsprechend abändern

0

 

 

 

 

 

 

2

 

 

 

 

 

 

 

5

 

 

 

 

 

 

2

 

 

 

 

 

 

 

20

 

 

 

 

 

 

20

 

 

 

 

 

 

 

1

 

 

 

 

 

 

0,4

 

 

 

 

 

 

 

ü

 

 

 

 

 

 

ü

 

 

 

 

 

 

 

RB3

R1b

Kapazitäten-wegfall

10

30

3

P – Verträge mit den externen Firmen entsprechend gestalten, dass von diesen der zusätzliche Einarbeitungsaufwand getragen werden muss.

 

K – Neuen externen Mitarbeiter finden und die Einarbeitung des neuen Mitarbeiters sehr hoch priorisieren

0

 

0

 

30

 

0

 

ü

 

RB4

R15

Es wird zu wenig und nur oberflächlich getestet

25

5

1,3

P – Alle Projektmitglieder müssen während der Testphase ausschließlich testen.

 

K – Neue Testphase starten, in welcher alle Projektmitglieder ausschließlich testen.

0

 

0

 

5

 

0

 

ü

 

RB5

R1a

Kapazitäten-wegfall

5

22

1,1

P – Von den verantwortlichen Führungskräften zusichern lassen, dass die Mitarbeiter für die gesamte Projektlaufzeit zur Verfügung stehen werden.

 

K – Versuchen den abgezogenen Mitarbeiter adäquat zu ersetzen.

0

 

 

 

 

 

 

 

 

 

2

 

 

 

 

 

 

 

 

 

22

 

 

 

 

 

 

 

 

 

0,4

 

ü

 

 

 

 

 

 

 

 

 

RB6

R1c

Kapazitäten-wegfall

5

22

1,1

P – für Balance zwischen Arbeit und Freizeit sorgen.

K – Versuchen den ausgefallenen Mitarbeiter adäquat zu ersetzen

0

5

22

1,1

û

RB7

R2a

Budgetüberschreitung

20

5

1

P – Genügend Puffer einplanen

 

K – Versuchen Budget vom Fachbereich nachzufordern.

0

 

 

 

5

 

 

5

 

0,3

 

ü

 

RB8

R3

Konflikte im Projektteam

10

10

1

P – Team bei der Bildung der sozialen Strukturen aktiv unterstützen

K – Durch gemeinsame Gespräche versuchen die Probleme aus der Welt zu schaffen

2

3

10

0,3

ü

 

RB9

R5

Datenimport ist nicht performant genug

20

3

0,6

P – Ausreichende Lasttest durchführen

 

K – Datenimport nachbessern

2

 

2

 

3

 

0,1

 

û

 

RB10

R12

Anforderungs-analyse wird vom Fachbereich nicht ausreichend unterstützt

20

3

0,6

P – Fachbereich von Anfang des Projektes an Einbinden

K – Problem an Fachbereichsleiter eskalieren

2

0,5

3

0

ü

 

RB11

R4

Nicht entsprechend qualifizierte Projektmitarbeiter

5

10

0,5

P - Einsatzmittelplan dem Linienvorgesetzen als Anforderung der benötigten Projektmitarbeiter vorlegen

K – Durch entsprechende Qualifizierungsmaßnahmen die Mitarbeiter für die Aufgaben qualifizieren bzw. ein Expertencoaching durchführen.

1

2

10

0

ü

 

RB12         RB12

R10

Anwendung entspricht nicht den Anforderungen

5

10

0,5

P – Während der Projektlaufzeit kontrollieren ob die Anforderungen entsprechend umgesetzt werden

 

K – Anwendung nachbessern

1

 

1

 

10

 

0,1

 

ü

 

RB13

R14

Statusberichte werden nicht geliefert

10

3

0,3

P – Fixe Termine festlegen, zu welchen die Statusbereichte abgegeben werden müssen

 

K – Statusberichte nachfordern und auf Regeln verweisen

0

1

3

0

ü

RB14

R2b

Budgetüberschreitung

5

5

0,3

P – Kostenschätzung von zwei Mitarbeitern erstellen lassen und diese dann konsolidieren

 

K – Versuchen Budget vom Fachbereich nachzufordern.

1

1

 

5

 

0,1