Training Migration. Verfasser: Christophe Grévent xxxx xxxx. Hartmut Eska xxxx xxxx

Transkript

1 Training Migration Verfasser: Christophe Grévent xxxx xxxx Hartmut Eska xxxx xxxx Diese Arbeit wurde nach folgenden Richtlinien verfasst: Anleitung zum Transfernachweis IPMA Level D (Dok.-Nr.: Z08 / Rev.: 09 / Datum: ) _Grevent-Christophe_Eska-Hartmut.pdf Seite 1 von 42

2 Inhaltsverzeichnis 1 Projekt / Projektziele Projektbeschreibung Zielbeschreibung / Zielhierarchie Projektumfeld, Stakeholder Projektumfeld, Umfeldfaktoren Stakeholder (Interested Parties) Risikoanalyse Erfassung, Klassifizierung und Beschreibung der Risiken Quantitative Bewertung der Risiken und Maßnahmen zur Risikobegegnung Projektorganisation Organisationsform des Projektes Kommunikation Phasenplanung Beschreibung der Projektphasen und der Meilensteine Veranschaulichung der Projektphasen Projektstrukturplan Darstellung und Codierung des PSP Arbeitspaketbeschreibung Ablauf- und Terminplanung Vorgangsliste Vernetzter Balkenplan oder berechneter Netzplan Einsatzmittel- / Kostenplanung Einsatzmittelbedarf / Einsatzmittelplan Projektkosten Verhaltenskompetenz Konflikte und Krisen Ergebnisorientierung Wahlelemente Projektstart, Projektende Anhang Abbildungsverzeichnis Tabellenverzeichnis _Grevent-Christophe_Eska-Hartmut.pdf Seite 2 von 42

3 1 Projekt / Projektziele Bei dem Projekt Training Migration handelt es sich um ein reales Projekt, welches im Rahmen einer Firmenzusammenlegung stattgefunden hat. Konkret wurde die IT des einen Unternehmen durch die IT des zweiten Unternehmens ersetzt, übrige Organisationseinheiten wurden geschlossen. Insgesamt gab es in diesem Programm 15 Projekte, wobei die meisten zum Ziel hatten, die vorhandenen Systeme beider Standorte zusammenzulegen. Die Projekte waren vor allem typische IT Projekte, die sich um die eigentliche Entwicklung der Systeme gekümmert haben, und waren nach Themen gegliedert (exemplarisch: Billing Themen, Point-of-sales / Kassensysteme, Customer Care, usw). Zusätzlich zu diesen Projekten wurden noch Querschnittsprojekte definiert, wie z.b. ein zentrales Testing oder ein gemeinsames Training. Das Projekt Training Migration hatte zum Ziel, bei den zukünftig verbleibenden Einheiten entsprechendes Wissen aufzubauen, damit die Zielsysteme beherrscht werden können, und die Ineffizienz der Mitarbeiter, die mit der Umstellung der gewohnten IT Umgebung einher geht, so gering wie möglich zu halten. Im Rahmen des Transfernachweises haben wir die Entscheidung getroffen, das Projekt aus der Perspektive danach zu betrachten, mit anderen Worten sind zu jedem Zeitpunkt hier alle Parameter bekannt. Standort B Standort A Billing Training Migration Gesamtprogramm Migration Order Entry Raum POS Mitarbeiter Abbildung 1: Projektumfeld _Grevent-Christophe_Eska-Hartmut.pdf Seite 3 von 42

4 1.1 Projektbeschreibung In der Projektbeschreibung werden vor allem grobe und allgemeine Ziele dargestellt, da diese im Allgemeinen sehr früh im Projekt erstellt wird. Der Projektleiter kann über diesen Weg sein Verständnis des Projektvorhabens wiedergeben und prüfen, in dem er diese Beschreibung dem Auftraggeber zur Verfügung stellt, ob er den Auftrag richtig verstanden hat. Formalisiert wird diese Projektbeschreibung in einem Projektsteckbrief. Dieser enthält sowohl eine erste Formulierung der Ziele, als auch eine erste Analyse dieser Ziele. Dabei werden auch Rahmenbedingungen wie Aufwand, Budget und Termine abgesteckt. Diese erste Analyse zeigt, ob aus einem Vorhaben auch wirklich ein Projekt entstehen kann. Training Migration Christophe Grévent Hartmut Eska Projektsteckbrief P-11 Projektbezeichnung: Training der Fachbereiche im Rahmen der Migration - auch Programm AB genannt. Ausgangssituation: Die Unternehmen A und B fusionieren. Die Standorte sind Stuttgart für die Organisation A und Hamburg für die Organisation B. Die IT in Hamburg übernimmt die kompletten Aufgaben für beide Standorte. Alle anderen Fachbereiche bleiben in Stuttgart. Alle doppelt belegten Aufgaben werden mittelfristig reduziert, was zur Kündigung der entsprechenden Belegschaft führen wird. Diese Migration bedeutet konkret, dass alte Systeme angepasst werden, aber auch, dass neue Systeme eingeführt werden. Die Projekte des Programms AB liefen bereits an, als im Rahmen der ersten Entwicklungsmonate erkannt wurde, dass die Schulungen nicht durch die einzelnen Projekte geleistet werden konnten. Zusätzlich wurde zum Startzeitpunkt des Projektes bekannt, dass ein drittes Unternehmen C die beiden Organisationen A und B übernehmen wird. In welcher Form und welche Auswirkungen dies haben würde, war noch nicht abschätzbar. Für dieses Projekt, wurden als Budget zur Verfügung gestellt _Grevent-Christophe_Eska-Hartmut.pdf Seite 4 von 42

5 Projektziele / -inhalt / -nutzen: Ziel: Durchführung von Schulungen für die Fachbereiche die Anzahl der Schulungen und die betroffenen Fachbereiche müssen in einer Bedarfsanalyse ermittelt werden Die Mitarbeiter von Standort A sollen die zukünftigen Systeme beherrschen, so dass eine reibungslose Migration ermöglicht wird Die Schulungsmaßnahmen sollen bis zum Migrationszeitpunkt am abgeschlossen sein Inhalt: Erstellung von Schulungshandbüchern, Handouts (Kurze Beschreibungen ohne Schulungen), sowie Durchführung von klassischen Schulungen mit Trainern und den Fachbereichsmitarbeitern Nutzen: Wissensaufbau in den Fachbereichen Reibungslose Migration Projektumfeld: Der Projektleiter ist fest angestellt, und stammt aus der Organisation A. Demzufolge sind ihm die Systeme am Anfang unbekannt. Die Softwareentwicklung (IT) sitzt in Hamburg und stammt aus der Organisation B Das Programmmanagement ist extern eingekauft worden und hat ein aus externen Personen zusammengeführtes Program Management Office eingesetzt, das Coaching Aufgaben wahrnehmen soll. Das Programmmanagement sitzt in Hamburg. Die Mitarbeiter der Fachbereiche kennen die zukünftigen Systeme nicht Die Trainer werden extern eingekauft _Grevent-Christophe_Eska-Hartmut.pdf Seite 5 von 42

6 Geplante Termine: Projektstart: Zwischentermine: Planung + 2M Erstellung der Schulungsdokumente + 6M Durchführung der Schulungen +9M Fertigstellungstermin / Projektende: Geschätzter Kapazitätsaufwand (in Personentagen): Intern: 20 * 9 (1 Projektleiter) = 180 PT davon Planungsaufwand: 20 * 2 = 40 PT Extern: 20 * 8 * 3 = 480 PT Projektvolumen / Budget (in Euro): Intern: Extern: Projektbeteiligte: Projektleiter: Christophe Grévent Senior Trainer: Hartmut Eska (Operativer PL) Auftraggeber: Programmmanager Programm AB, Herr Schulz Extern: Noch zu klären, typischerweise die Trainer. Lenkungsausschuss: Programmmanager sowie Fachbereichsleiter Machtpromotor: Programmmanager Fachpromotor: IT-Beauftragte aus den Fachbereichen Mögliche Behinderungen / Risiken / Störungen: Die ungewisse Situation für die verbleibenden Fachbereiche durch das Auftreten von Unternehmen C kann zu eingeschränkter Motivation der Mitarbeiter bei den Schulungen führen Der Umfang der Systemänderungen ist anfangs schlecht einzuschätzen, hierdurch Planungsschwierigkeiten Zusammenarbeit zwischen den Standorten noch frisch, und deshalb schwer einzuschätzen Sehr große zeitliche und inhaltliche Abhängigkeit zu den anderen Projekten Keine Erfahrungen bei den Mitarbeitern mit der Thematik Unternehmensweite Schulungen Freigaben: Bemerkungen: Tabelle 1: Projektsteckbrief _Grevent-Christophe_Eska-Hartmut.pdf Seite 6 von 42

7 Im Rahmen des Projektes Training Migration bestand die Schwierigkeit, dass der Auftrag sehr allgemein gehalten war, und dass die Stakeholder nur sehr wenig Erfahrungen mit der Thematik Unternehmensweites Training in einem Unternehmen von mehreren tausenden Mitarbeitern hatten, auch wenn die Wichtigkeit dieses Projektes klar gesehen wurde, wie das Budget es zeigt. Das Budget wurde vor dem Projektanfang durch Unternehmensberater geschätzt, die Projektleitung war zu diesem Punkt nicht involviert, weshalb diese Abschätzung nicht nachvollziehbar ist. Der Steckbrief erlaubte hier eine erste Analyse des Themas und der Schwierigkeiten. Dies führte sehr schnell zur Entscheidung, dass Trainer extern beschaffen werden mussten, was das üppige Budget problemlos zuließ. 1.2 Zielbeschreibung / Zielhierarchie Nach der formellen Freigabe des Projektes, ist es wichtig die Ziele zu sammeln, und zu strukturieren. Ziele dienen anfangs den Projektmitarbeitern als Orientierung wohin es gehen soll und auch während der Realisierung des Projekts ist diese Orientierung immer wieder wichtig. Außerdem haben sie eine Kontrollfunktionalität sowohl für das Vorgehen, als auch für das Ergebnis des Projekts. Hier wird der Erfolg eines Projekts am Ende u.a. auch am Zielerreichungsgrad gemessen. In einem zweiten Schritt werden Ziele priorisiert, um im Falle von Verschiebungen entsprechend der Priorität agieren zu können. Die Zufriedenheit des Auftraggebers soll so wenig wie möglich negativ beeinflusst werden. Exemplarisch sind hier die Ziele der Ebene 3 aufgeführt. Die Ziele der Unterebene 4 sind hier impliziert, da Ziele der Ebene 3 nur erreicht werden können, wenn alle Ziele der Unterebene erreicht sind. Ziel Messbarkeit Klassifizierung Priorität Bedarfsliste erstellen Schulungsmassnahmen durchgeführt Qualität sichergestellt Positive Projektabwicklung Schulungskatalog ist abgenommen Die Schulungsunterlagen wurden erstellt, die Schulungen wurde gehalten Die Erfolgskriterien werden anfangs festgelegt und nach Abschluss jeder Schulung geprüft. Das Reporting und die Dokumentation sind erstellt und stehen für das Programmmanagement in den entsprechenden Ordnern zur Ergebnisziel 1 Ergebnisziel 1 Ergebnisziel 1 Vorgehensziel _Grevent-Christophe_Eska-Hartmut.pdf Seite 7 von 42

8 Ziel Messbarkeit Klassifizierung Priorität Kosten eingehalten Zeitplan eingehalten Verfügung Tabelle 2: Priorisierung der Ziele Der Budgetrahmen wurde nicht überschritten Bedingt durch das Projekt gab es keine Verschiebung Vorgehensziel 2 Vorgehensziel 2 Abbildung 2: Zielhierarchie Die Besonderheit des Projektes Training Migration war, sowohl die Schulungen vorzubereiten (z.b. Dokumente zu erstellen), als auch die Schulungsmaßnahmen an sich zu organisieren und durchzuführen. Dieser letzte Punkt ist ein typisches Merkmal eines Organisationsprojekt. Weiterhin war am Anfang des Projektes der reale Umfang der Schulungsmaßnahmen sowohl von den Inhalten als auch von den Teilnehmern in einem sehr geringen Umfang bekannt. Deshalb musste in einem ersten Schritt der Bedarf ermittelt werden _Grevent-Christophe_Eska-Hartmut.pdf Seite 8 von 42

9 2 Projektumfeld, Stakeholder Ein Projekt kann nicht isoliert betrachtet werden. Es kann Auswirkungen auf sein Umfeld haben. Ebenso hat das Umfeld verschiedene Einflüsse auf das Projekt, welche unterschiedliche Auswirkungen auf den Projektverlauf und das -ergebnis haben können. Die Auswirkungen können sowohl positiv, als auch negativ sein. Diese Einflüsse gilt es im Vorfeld zu analysieren und einzuschätzen, wie sie sich auf das Projekt auswirken können. So bieten Faktoren, die sich positiv auf das Projekt auswirken können, Chancen für eine bessere Erreichung der Ziele. Bei negativen Faktoren sollten entsprechende Maßnahmen zur Vermeidung, bzw. Verminderung getroffen werden. 2.1 Projektumfeld, Umfeldfaktoren Die Projektumfeldanalyse erlaubt es dem Projektleiter zu analysieren, welche Einflussfaktoren in seinem Projekt auftreten können, auch wenn in einem ersten Schritt noch kein Risiko betrachtet und geschätzt wird. Hier wieder ist der wesentliche Aspekt dieser Analyse eine Vermeidung des Übersehens eines vielleicht späteren wichtigen Einflussfaktors. Eine genauere Analyse des Umfeldes ergibt die folgende Tabelle: _Grevent-Christophe_Eska-Hartmut.pdf Seite 9 von 42

10 Sachlich direkt Schulungslokalität Budget IT-Systeme der Ziellandschaft Anforderungsdokumentation für die Teilprojekte Sozial direkt Projektleiter Training Migration Schulungsteilnehmer Unternehmen A / Fachbereichsleiter Trainer IT-Ansprechpartner der Fachbereiche Programmleiter (vor kurzem ausgetauscht) IT Unternehmen B Fehlendes Knowhow der Beteiligten zur Ziellandschaft weitere Projektleiter aus dem Programm Kulturen in Standort A und Standort B grundsätzlich verschieden. Neue Systeme bringen neue Prozesse in den Fachbereichen Sachlich indirekt Sozial indirekt Strategie und Zielsetzung der Migration von Unternehmen A und B Weiteres Migrationsprojekt durch Unternehmen C mit noch nicht absehbaren Auswirkungen auf Migrationsprojekt Druckcenter (für Schulungsunterlagen) Trainer-Firma Facilitymanager IT Sekretärin Andere Trainingseinheiten des Unternehmens (Kundenbetreuung, Vertrieb,...) Tabelle 3: Projektumfeld Schnittstelle Projekt zu: Beschreibung Bewertung Schulungslokalität Budget IT Systeme der Ziellandschaft Anforderungsdokumentation für die neuen Projekte Das Projekt Training Migration ist nicht das einzige Projekt, dass Schulungsräume benutzt. Weiterhin ist es aufgrund der Umwälzungen im Unternehmen, dass dieser Raum gar nicht mehr zur Verfügung steht Das Budget wurde im Vorfeld definiert, und unabhängig vom Projektleiter definiert. Die Systeme der Ziellandschaft sind z.t. neue Systeme, oder ältere Systeme die an die aktuellen Anforderungen angepasst werden. Die Dokumentation dient als Kommunikation zwischen den Fachbereichen und den Projekten, die die Systeme umsetzen. Voraussichtlich nicht kritisch. Es kann als Chance betrachtet werden, denn nach einer ersten Analyse erscheint dieses Budget höher als der Bedarf. Hier existiert ein Risiko, denn die Arbeiten an diesen Systemen sind sehr umfangreich, was auf nicht ausgereifte Software hinaus gehen wird. Diese Dokumentation wurde unter extremem Zeitdruck realisiert, so dass die Information dort als sehr unzureichend beschrieben werden _Grevent-Christophe_Eska-Hartmut.pdf Seite 10 von 42

11 Schnittstelle Projekt zu: Beschreibung Bewertung Tabelle 4: Schnittstellen Projekt / sachliches Projektumfeld kann. Dieses kann als Risiko betrachtet werden, da es hierdurch wahrscheinlich ist, dass die Systeme den Erwartungen nicht entsprechen werden. Im Rahmen des Projektes Training Migration war von Anfang an klar (siehe hierzu den Projektsteckbrief), dass die politische Großwetterlage im Unternehmen einen wesentlichen Einfluss haben würde, und deshalb waren Punkte wie z.b. der Entwicklungsfortschritt der anderen Projekte oder die Strategie und Zielsetzung der Migration ohne Aufwand bzw. Analyse klar. Durch die Analyse stellte sich jedoch heraus, dass noch andere Faktoren eine Rolle spielen würden, beispielsweise die IT-Projektleiter, aber auch die IT Sekretärin, die anschließend bei der Organisation der Schulungen eine wesentliche Unterstützung leistete. 2.2 Stakeholder (Interested Parties) Stakeholder sind alle am Projekt beteiligten oder vom Projekt betroffenen Personen/Personengruppen. Bei der Stakeholderanalyse wurden die Ergebnisse der Umfeldanalyse zugrunde gelegt. Die Personen, bzw. Gruppen, die als soziale Faktoren (direkt, indirekt) identifiziert wurden, sind in der folgenden Tabelle mit ihrem Einfluss, der Verhaltensabschätzung, usw. aufgeführt. Stakeholder Regelmäßige Treffen vereinbaren, sowohl formell (Meeting) als informell (Kaffemaschine) Hochwertige Schulungsunterlagen Schulungsteilnehmer Interessen definieren IT-Ansprechpartner der Fachbereiche Reibungslose Schulungsorganisation Neue Systeme beherrschen Einfluß / Macht 2 direkt 1 direkt Einstellung zum Projekt Befürchtetes Verhalten ++ Wenig motiviert O Erwünschtes Verhalten Engagierte Teilnahme Strategie Maßnahme Mangelnde Kooperation Partizipation Motivierte Kooperation Integration _Grevent-Christophe_Eska-Hartmut.pdf Seite 11 von 42

12 Stakeholder Fachbereichsleiter Trainer Weitere Projektleiter aus dem Programm Trainer-Firma IT Sekretariat Interessen definieren Regelmäßige Abstimmungs- und Feedbacktermine Berichte Programmleiter Knowhow- Aufbau im Bereich Schulungen vorbereiten und durchführen Programmabschluß in Time, Quality, Budget Brauchbare Systeme entwickeln Auftrag bekommen Facilitymanager Schulungsräume vermitteln Reibungslose Schulungsorga- Andere Trainingseinheiten des Unternehmens (Kundenbetreuung, Vertrieb) nisation Wissenstransfer Einfluß / Macht 2 direkt 2 direkt 3 direkt 1 indir. 0 indir. 0 indir. 1 direkt 2 direkt Einstellung zum Projekt Befürchtetes Verhalten Erwünschtes Verhalten ++ Passivität Unterstützung Partizipation +++ Wenig motiviert Unterstützung Strategie Maßnahme +++ Fehlende Unterstützung Partizipation ++ Passivität Kooperation Integration O Kooperation Schlechte Zusammenarbeit Integration Legende: Einfluß/Macht 0 3 keinen Einfluss -starken Einfluss Einstellung zum Projekt: --- sehr negativ eingestellt o neutral +++ sehr positiv eingestellt Tabelle 5: Stakeholderanalyse Unterstützung + Fehlende Unterstützung Informieren Berichte Knowhow- Aufbau sicherstellen Partizipation O Blockade Kooperation Informieren - Regelmäßiger Austausch über Fortschritt der Entwicklung und der Schulungsmaßnahmen - Darstellung des Mehrwerts der Schulungen - Informelle Meetings mit den PLs Persönlicher Kontakt Persönlicher Kontakt Persönlicher Kontakt + Wenig motiviert Motivierte Kooperation Integration Regelmäßige Treffen vereinbaren _Grevent-Christophe_Eska-Hartmut.pdf Seite 12 von 42

13 Im Rahmen des Projektes Training Migration war die Stakeholderanalyse wesentlich, da es von Anfang an klar war, dass die Komplexität des Projektes bei der Vielzahl an Ansprechpartner lag. Durch diese Analyse konnte eine klare Politik definiert und durch eine klare Definition des Verhaltens die Komplexität verringert werden. Weiterhin kamen Änderungen wie z.b. der Zukauf der Unternehmen A und B durch das Unternehmen C ins Spiel, die auch Änderungen bei den Stakeholdern bewirkten: Die ursprünglich gesetzten Fachbereiche erfuhren, dass sie durch die Fachbereiche des Unternehmens C ersetzt wurden, was ihre Motivation zu einem Wissensaufbau auf Zeit deutlich verringerte. Dieser Punkt wurde im Rahmen des Projektes ganz besonders verfolgt. Um die Stakeholder besser verfolgen zu können, wurden drei Gruppen von Stakeholdern definiert: 1. Die Stakeholder, die direkt im Programm tätig waren (andere Projektleiter, Programmmanager, usw.) 2. Die Unterstützer, die nötig für einen reibungslosen Ablauf des Projektes nötig waren (Facility Manager, Sekretariat, usw.) 3. Die Kunden, die die Adressaten der Schulungen darstellten. Weiterhin wurde eine Philosophie verfolgt, die einen direkten Kontakt zu den Stakeholdern bevorzugte, wie z.b. informelle Besprechungen an der Kaffeemaschine, usw., um ein Gutwollen der Stakeholder zu bewirken. Dadurch waren auch öfters Reisen zwischen Standort A und B notwendig, um sich an die verschiedenen Unternehmenskulturen der Stakeholder anpassen zu können _Grevent-Christophe_Eska-Hartmut.pdf Seite 13 von 42

14 3 Risikoanalyse Die Risikoanalyse bietet dem Projektleiter die Chance, frühzeitig die absehbaren Risiken für sein Projekt zu identifizieren. Er sollte entsprechende Maßnahmen treffen, bzw einplanen, um diese Risiken zu vermeiden oder zumindest zu verringern. Werden Risiken missachtet kann dies schnell zu einem Ansteigen der Kosten oder Verschieben des Endtermins führen bisweilen kann dies auch zum Projektabbruch führen. Die Risikoanalyse kann der Projektleiter mit seinem Projektteam im Brainstorming- Verfahren in der Startphase angehen. Die Risiken werden anschließend nach ihrer Eintrittswahrscheinlichkeit und ihren Auswirkungen auf das Projekt bewertet. 3.1 Erfassung, Klassifizierung und Beschreibung der Risiken Für das Projekt Training Migration bestanden unterschiedliche Risiken durch die Rahmenbedingungen. Bei einem solchen Projekt mit vielen beteiligten Personen spielt die Motivation und das Engagement ebenfalls eine große Rolle. Die folgende Tabelle führt die identifizierten Risiken auf: Nr Risiko Klassifizierung 1 Projektabbruch durch Auftreten von Unternehmen C Technisch 2 Schlechte Mitarbeitermotivation durch ungewisse Perspektive Sozial 3 Verzug bei anderen Projekten (Point of Sale, Abrechnungssystem, ) des Migrationsprogramms Zeitlich 4 Planungsschwierigkeiten durch nicht bekannten Systemänderungsumfang Zeitlich 5 Trainer werden nicht akzeptiert Sozial 6 Trainer haben fehlende Kompetenz Qualität _Grevent-Christophe_Eska-Hartmut.pdf Seite 14 von 42

15 Nr Risiko Klassifizierung 7 Trainer kennen Systemlandschaft nicht und müssen sich einarbeiten Technisch 8 Fachbereiche verlangen zum Teil Prozessschulungen, bzw. Prozessdefinitionen während Systeme geschult werden sollten. Kompetenz 9 Hoher Einarbeitungsaufwand wegen fehlender Qualität der Spezifikationen in den Projekten (aus Zeitmangel). Technische Tabelle 6: Risikobeschreibung Das Brainstorming zur Erfassung brachte erwartungsgemäß deutlich mehr Risiken als im voraus gesehen. Unter anderem die Akzeptanz der Trainer erwies sich als interessantes Risiko, dass es zu betrachten galt. Aber auch der Unterschied zwischen Prozessschulungen und Systemschulungen zog sich lange Zeit durch das Projekt: Die Fachbereiche wünschten sich Schulungen, die so weit wie möglich den Mitarbeitern auch die entsprechenden Prozesse darstellten. Dieses hätte jedoch einen erheblichen Mehraufwand bedeutet, da die Prozesse zum großen Teil selber durch die Fachbereiche nicht bekannt bzw. nicht definiert waren. Konkret haben die Trainer jedoch manche Schulungen aus pädagogischem Denken anhand von Prozessen definiert, und Anpassungen erstellt, jedoch niemals mit dem Anspruch, die Prozesse zu schulen. 3.2 Quantitative Bewertung der Risiken und Maßnahmen zur Risikobegegnung Nachdem die Risiken aufgelistet wurden, werden diese bewertet, um von der qualitativen Ebene zur quantitativen Ebene zu gelangen, was unter anderem eine Priorisierung der Risiken ermöglicht. Weiterhin ist ein wesentlicher Bestandteil die Schätzung des Schadens, da diese eine Aussage erlaubt über das Risikobudget, also das Budget welches verwendet wird, um im Vorfeld dieses Risiko auszuschließen _Grevent-Christophe_Eska-Hartmut.pdf Seite 15 von 42

16 Risiko EW in % TW (1-100) RPZ (EW * TW) Schaden in Euro Maßnahmen Risikobud get K Abschluss früher 0 durchziehen P 4000 Schulungsunterlagen hochwertig gestalten K Trainer länger beschäftigen K Trainer länger beschäftigen K Trainer austauschen 5000 lassen K Trainer austauschen 5000 lassen P Entsprechende Zeit einplanen (15PT) P Projektauftrag früh 0 und klar kommunizieren P Entsprechende Zeit 0 einplanen, jedoch Summe schon bei Risiko 7 betrachtet Gesamt Tabelle 7: Risikoanalyse Die Risikoanalyse hat aus unserer Sicht zwei wesentliche Erkenntnisse gebracht: Die Risiken hatten meistens nur eine sehr geringe monetäre Auswirkung auf das Projekt, sondern eher auf die Leistung des Projektes, i.e., die Schulungen hätten in vielen Fällen nicht das nötige Know How geliefert. Die Summe des Risikobudgets war problemlos im üppigen Budget vorhanden, weshalb das Projekt aus dieser Sicht auch tragfähig war _Grevent-Christophe_Eska-Hartmut.pdf Seite 16 von 42

17 4 Projektorganisation Die Projektorganisation strukturiert die Rollen, Verantwortungen und Befugnisse in einem Projekt. Eine vernünftig aufgesetzte Projektorganisation ist die Voraussetzung für ein funktionierendes Projekt. Alle mittelbar und unmittelbar Beteiligte sollten die eigene Verantwortung und die der anderen kennen. Die Basis-Projektorganisationen sind die Einfluss-, die Autonome- und die Matrix- Projektorganisation. Jede Organisationsform hat ihre Vor- und Nachteile. Die Wahl der Projektorganisationsform hängt von vielen Parametern, wie z.b. der Projektgröße und -dauer, der Unternehmensstrategie und -organisation, ab. 4.1 Organisationsform des Projektes Aufgrund der Größe, der Wichtigkeit und der terminkritischen Vorgaben wurde für das Programm und auch für alle Projekte innerhalb des Programms die Matrix- Projektorganisationsform gewählt. D.h. es wurden Ressourcen aus der Linie eingesetzt, welche durch externe Spezialisten unterstützt wurden. Insofern blieb die disziplinarische Verantwortung beim jeweiligen Linienvorgesetzten, während die fachliche Verantwortung beim Projektleiter, bzw. Programmleiter lag. Die folgende Tabelle beschreibt die Besetzung und die Rollen in unserem Projekt. Rolle Person Beschreibung Programmleiter Projektleiter Senior Trainer (Stellv. Projektleiter) Trainer 1 Herr Thomas Schulz Herr Christophe Grévent Herr Hartmut Eska, Firma Trainingsberatung GmbH Frau Paula Müller, Firma Trainingsberatung GmbH Der Programmleiter des Migrationsprojekts ist disziplinarisch direkt unter dem IT-Leiter aufgehängt, auf einer Ebene mit dem Abteilungsleiter. Ihm sind alle Projektleiter des Programms unterstellt. Er verantwortet das Projekt Training Migration, ist im Rahmen des Projektes dem Programmleiter und disziplinarisch dem Abteilungsleiter unterstellt. Er koordiniert und steuert die Trainer und vertritt den Projektleiter. Er wird im Rahmen des Projektes eingekauft und ist disziplinarischer Vorgesetzter der anderen Trainer. Zusätzlich wird er durch seine langjährige Erfahrung in Trainingsprojekten auch Trainingsaufgaben übernehmen. Sie ist zuständig für die Vorbereitung der Trainingsunterlagen und führt selbst Trainings durch _Grevent-Christophe_Eska-Hartmut.pdf Seite 17 von 42

18 Rolle Person Beschreibung Trainer 2 Frau Michèle Dupont, Firma Trainingsberatung GmbH Sie ist zuständig für die Vorbereitung der Trainingsunterlagen und führt selbst Trainings durch Abteilungsleiter Herr Daniel Maier Linienverantwortlicher und Disziplinarischer Vorgesetzter des Projektleiters und des Senior Trainers. Sein disziplinarischer Vorgesetzter ist der IT Leiter. IT Leiter Herr Jeremy Pauli Ist der Leiter der IT und Mitglied des Unternehmensvorstandes. Er ist der offizielle Träger des Migrationsprogramms, und hat den Programmleiter bestellt. Tabelle 8: Rollenbeschreibung der Projektorganisation IT Leiter Abteilungsleiter Programmleiter Projektleiter Training Projektleiter P1 Senior Trainer (Stellv. Projektl.) Trainer 1 Trainer 2 Legende Linie Projekt Training Andere Projekte Abbildung 3: Projektorganisation / Organigramm In der Abbildung Projektorganisation / Organigramm ist dies nochmals grafisch dargestellt. Der Abteilungsleiter steht stellvertretend für die anderen Abteilungsleiter in den beiden _Grevent-Christophe_Eska-Hartmut.pdf Seite 18 von 42

19 Unternehmen. Ebenso steht der Projektleiter P1 stellvertretend für die anderen Projektleiter innerhalb des Programms. Im Rahmen des Projektes wurde entschieden, dass das Team zusätzlich zum Projektleiter durch ein Team von 3 externen Trainern unterstützt werden sollte. Die Hintergründe dieser Entscheidung waren, dass das fachliche Know How zum Thema Training sehr gering war, und weiterhin, dass ein eingearbeitetes Team mit einer starken Erfahrung eher in der Lage sein würde, durch schnelle Überwindung der anfänglichen Phasen à la Aufbau oder Storming, zu einer raschen Effizienz in der Arbeit zu gelangen, und projektinterne politische Spannungen zu vermeiden. Konkret war der Senior Trainer auch Linienvorgesetzter der 3 anderen Trainer bei dem entsprechenden Dienstleister. Diese Struktur erlaubte eine leichtere Handhabung der Situation, in der ein Trainer schwächer gearbeitet hätte und die Entscheidung gefällt wäre, ihn auszutauschen (Siehe Risiko 5, 6). Wir erwarteten auch wegen Risiko 7 bei der Einarbeitung eine hohe Effizienz, da die Trainer sich gegenseitig unterstützen konnten, was im Rahmen des Projektes auch erfolgt ist. 4.2 Kommunikation Auch wenn allgemein klar ist, dass Kommunikation zwischen den verschiedenen Stakeholdern eines Projektes ein wichtiger Aspekt für das Gelingen ist, so funktioniert dies in der Regel nicht von alleine. Es ist wesentlich, dass dies systematisch organisiert wird, um zu gewährleisten, dass jeder der Teilnehmer, entsprechend der definierten Strategie auch bedient wird. Letztendlich auch so bedient wird, dass er die notwendige Information bekommt, aber auch nicht mehr. Das Kommunikationskonzept regelt diese Informationsverteilung. Was Wer an Wen Wann Form Statusbericht PL Programmleiter Wöchentlich Bericht, schriftlich Fortschrittsinfo aller Projekte inkl. Projekt Training Migration oder Tagesbericht PL Programmleiter weitere Projektleiter Schulungskatalog PL Weitere Projektleiter Trainer IT-Ansprechpartner der Fachbereiche Täglich (daytoday) Besprechung / Telefonkonferenz In der zweiten Phase des Projektes nach einer wichtigen Erkenntnis oder als Ergebnis von Abstimmungsrunde n Report aus Trainingsdatenbank per _Grevent-Christophe_Eska-Hartmut.pdf Seite 19 von 42

20 Was Wer an Wen Wann Form Schulungskalender PL Schulungsteilnehmer Fachbereichsleiter Trainer weitere Projektleiter Nach Änderung Report aus Trainingsdatenbank per Statusbericht PL Steering Committee 14-tägig Bericht, schriftlich, nach vorgegebenem Muster Projektabstimmung PL Projektteam Wöchentlich Besprechung Abstimmung der Inhalte Trainer Tabelle 9: Kommunikationskonzept IT-Ansprechpartner der Fachbereiche Bei Bedarf je nach Fortschritt, zusätzlich täglich Besprechung Abbildung 4: Gestaltung der Kommunikation im Projekt Ein wichtiger Aspekt der Kommunikation war, dass das Projekt Training Migration eine Sonderrolle im Rahmen des Programms einnahm, da es einerseits auch auf die anderen Projekte angewiesen war, die physische Nähe zu den Fachbereichen hatte (gleicher Standort), jedoch ein Teil des Programms war: Interne Programminformation, wie z.b. Verspätungen bei den Systemen, durfte typischerweise nicht durch uns geliefert werden, _Grevent-Christophe_Eska-Hartmut.pdf Seite 20 von 42

21 hatte jedoch einen direkten Einfluss auf unsere Arbeit, und hiermit auf die Kommunikation zu den Fachbereichen. Weiterhin war im Allgemeinen die Kommunikation so geregelt, dass das Management im Unternehmen mit dem Projektleiter kommunizierte mit dem Ziel, die Trainer von politischen Gegebenheiten fernzuhalten, damit sie sich rein auf die fachliche Arbeit konzentrieren konnten. Eine Ausnahme trat jedoch ein, als die Trainer Informationen zu den Systemen brauchten. Nach einer ersten Terminfindung mit den anderen Projektleitern übergab der Projektleiter des Training Migration Projekts die Aufgabe an die Trainer, um die fachlichen Informationen zu sammeln _Grevent-Christophe_Eska-Hartmut.pdf Seite 21 von 42

22 5 Phasenplanung 5.1 Beschreibung der Projektphasen und der Meilensteine Die Unterteilung des Projektes in Phasen erlaubte es schnell, eine erste Übersicht zum Ablauf des Projektes zu erarbeiten. Gleichzeitig war dies auch eine erste Prüfung, ob die Rahmenbedingungen realistisch waren. Phasen Phase 1 Grobplanung Definition der neuen Systeme / der neuen Systemlandschaft Erhebung der Bedürfnisse aus den Fachbereichen an Schulungen Definition der nötigen zusätzlichen Ressourcen Beschaffung der nötigen Ressourcen Definition eines ersten Schulungskatalogs Phase 2 Detailplanung Einarbeitung der externen Trainer Vorbereitungen zur Erstellung der Unterlagen (Templates erstellen, usw...) Definition der nötigen Inhalte der einzelnen Schulungen in Absprache mit den Fachbereichen Phase 3 Erstellung der Schulungsunterlagen Erstellung der Schulungsunterlagen durch die Trainer Phase 4 Durchführung Organisation der Schulungen Durchführung der Schulungen Feinjustierungen an den Schulungen entsprechend der Änderungen der Systeme Phase 5 Abschluss Prüfung mit den Fachbereichen, ob der Bedarf gedeckt wurde Organisation und Halten von Nachschulungen Tabelle 10: Inhalt der Projektphasen Zeit 1 Mon 1 Mon 4 Mon 3 Mon 0,5 Mon Es gilt hier zu betrachten, dass die Zeiträume in der Phasenplanung grob sind und deshalb in der Einheit Monate betrachtet wurden. Im Detail wurden später im Rahmen _Grevent-Christophe_Eska-Hartmut.pdf Seite 22 von 42

23 der Planung die Zeiträume naturgemäß auf Tagesebene berechnet. Meilensteine Meilenstein 1: Beauftragung der Trainer erfolgt. Termin zum Eintritt entsprechend Anfang Phase 2 von beauftragter Firma schriftlich bestätigt. Schulungskatalog erstellt und von den Fachbereichen abgenommen. Meilenstein 2 Von den Fachbereichen abgenommener Schulungskatalog mit einzelnen Schulungszielen. Templates erstellt und durch die Programmleitung abgenommen. Meilenstein 3 Schulungsdokumente zu den einzelnen Schulungsmassnahmen elektronisch erstellt und durch die IT Verantwortlichen der Fachbereiche abgenommen. Meilenstein 4 Unterschrift aller vom Fachbereich gemeldeten Teilnehmer zur Teilnahme an den Schulungen Meilenstein 5 Unterschrift durch die Fachbereiche, dass kein Bedarf mehr nötig ist. Tabelle 11: Meilensteine Eine Besonderheit der Phasenplanung war, dass die Schulungstermine nicht zu weit weg von der Livesetzung der Systeme stattfinden sollten, weshalb wir den Plan vom Zieltermin aus rechneten, und die Länge der Phase 4 faktisch vorgegeben war. Die Idee war, dass bei Verschiebungen die Phase 3 z.t. auch verlängert werden konnte, um die Qualität der Unterlagen zu steigern. Die Trainer waren auch entsprechend auf dem laufenden, so dass sie die Trainingsunterlagen entsprechend erstellten (Erster Wurf, anschliessend folgen Verbesserungen in verschiedenen Zyklen) Beim tatsächlichen Verschieben des Livesetzungstermin waren wir hierdurch plantechnisch vorbereitet und konnten problemlos reagieren _Grevent-Christophe_Eska-Hartmut.pdf Seite 23 von 42

24 5.2 Veranschaulichung der Projektphasen Zur Veranschaulichung haben wir hier einen Ausschnitt aus dem Projektplan zur Darstellung ausgewählt. In der Regel wird jedoch diese Phasenplanung vor der eigentlichen Erstellung des Projektplans erstellt, da es eine grobe Richtung liefern sollte. Abbildung 6: Phasenplan Abbildung 5: Phasenplanung Diese graphische Veranschaulichung erlaubt eine leichtere erste Übersicht über das Projekt. Mit relativ wenigem Aufwand kann geprüft werden, ob die Zeiträume und Zeitziele auch realistisch sind _Grevent-Christophe_Eska-Hartmut.pdf Seite 24 von 42

25 6 Projektstrukturplan Der Projektstrukturplan unterteilt das Projekt in Teilprojekte, Teilaufgaben und Arbeitspakete. Somit werden beherrschbare und überschaubare Einheiten gebildet. Er ist das zentrale Ordnungsinstrument des Projekts und stellt die Basis für weitere Planungen, wie zum Beispiel die Ressourcenplanung oder die Kostenplanung, dar. Durch die Unterteilung in Teilprojekte, -aufgaben und Arbeitspakete kann die Verantwortung zur Realisierung der einzelne Teile weitergegeben werden. 6.1 Darstellung und Codierung des PSP Der PSP wird oft als grafischer Baum dargestellt. Wichtig ist eine durchgängige Codierung der einzelnen Vorgänge, auf die sich alle weiteren Planungen beziehen können. Für unser Projekt haben wir die numerische Codierung gewählt. Die Erstellung des PSP kann als Detailanalyse betrachtet werden, in der die einzelnen Tätigkeiten des Projektes ausfindig gemacht werden. Der PSP zu diesem Projekt wurde nach der Bottom-Up-Methode per Brainstorming (MindMap) vom Projektleiter und Senior Trainer erstellt. Die einzelnen Arbeitspakete wurden den entsprechenden Phasen zugeordnet. Aufgrund der besseren Übersicht wurde in der Abbildung des Projektstrukturplans nur die Phase 1: Grobplanung und Teile der Phase 4: Durchführung dargestellt _Grevent-Christophe_Eska-Hartmut.pdf Seite 25 von 42

26 Training Migration 1 Phase 1: Grobplanung 2 Phase 2: Detailplanung 3 Phase 3: Schulungsunterlagen 4 Phase 4: Durchführung 5 Phase 5: Abschluss 6. Stabsfunktionen 1.1 Bedarfsermittlung nach Fachbereich Ermittlung des Bedarfs an Schulungen vom Vertrieb Ermittlung des Bedarfs an Schulungen vom Produktmgnt Ermittlung des Bedarfs an Schulungen vom Rechnungswesen Ermittlung des Bedarfs an Schulungen vom Forderungsmgnt Ermittlung des Bedarfs an Schulungen von Logistik Ermittlung des Bedarfs an Schulungen der Kundenbetreuung 1.2 Definition der möglichen Schulungen Erstellung einer Systemliste Ermittlung der groben Funktionsweise der Systeme 4.1 Billing System Allgemein Vorbereitung Durchführung Nachbearbeitungen 4.2 Billing System Logistik Vorbereitung Durchführung Nachbearbeitungen Prüfung vorhandener Schulungsmittel (Raum, Ausstattung,...) 1... Abbildung 7: Auszug aus dem Projektstrukturplan Eine der Schwierigkeiten im Rahmen dieses PSPs war, dass es sehr viele einzelne Arbeitspakete gab, aufgrund der sehr vielen einzelnen Schulungen. Es wurde deshalb eine Aggregierung gewählt, die die Schulungen in einer Aufgabe zusammenfasste. Diese Entscheidung vereinfachte zwar die Erstellung des PSPs, und später die Erstellung des Projektplanes, jedoch erschwerte sie die Steuerung des Projektes, da die Tätigkeiten sehr lang wurden. 6.2 Arbeitspaketbeschreibung Die Arbeitspaketbeschreibung dient zur Detaillierung der Elemente aus dem PSP, mit dem Ziel, dass jeder Mitarbeiter anhand dieser Beschreibung das Arbeitspaket auch wirklich umsetzen kann. Projektname: Training Migration Projekt-Nr.: Datum: Arbeitspaket-Titel: Ermittlung des Bedarfs an PSP-Nr.: Schulungen von Vertrieb Arbeitspaketbeschreibung: Im Rahmen des Arbeitspakets soll der Bedarf an Schulungen innerhalb des Vertriebs ermittelt werden. Dazu werden mit dem verantwortlichen Ansprechpartner anhand der Prozesse im Vertrieb die zukünftig eingesetzten Systeme und die Schulungsteilnehmer bestimmt _Grevent-Christophe_Eska-Hartmut.pdf Seite 26 von 42

27 Ziele (Welche Leistungen sollen erbracht werden?): Bestimmung des Teilnehmerkreises Liste der zu schulenden Systeme Verantwortlich: Christophe Grévent Start: Ende: Ergebniserwartung: Nach der Abstimmungsrunde mit Vertrieb stehen die zu schulenden Systeme und der Teilnehmerkreis fest. Diese Ergebnisse fließen in die weitere Planung (Termine, Dauer der Schulungen) ein. Schnittstellen zu anderen Arbeitspaketen/Projekten/ Organisationseinheiten - Vertrieb Aktivitäten/Termine: Voraussetzungen für das Arbeitspaket: Liste der zukünftig eingesetzten Systeme Benennung eines Verantwortlichen des Vertriebs Aufwand: 1 PT Anlagen: Kosten: 500 EUR Sonstiges: Unterschrift Projektleitung: Unterschrift Arbeitspaketverantwortlicher: Tabelle 12: Arbeitspaket Ermittlung des Bedarfs an Schulungen von Vertrieb _Grevent-Christophe_Eska-Hartmut.pdf Seite 27 von 42

28 Projektname: Training Migration Arbeitspaket-Titel: Durchführung der Schulung POS Allgemein Projekt-Nr.: PSP-Nr.: Datum: Arbeitspaketbeschreibung: Durchführung der Schulung des System POS, in dem der Trainer ca Personen in einer Schulung im entsprechend organisiertem Schulungsraum schult. Ziele (Welche Leistungen sollen erbracht werden?): Wissenstransfer der Funktionalität des Systems Verantwortlich: Paula Müller Start: Ende: Ergebniserwartung: Die Schulung zu POS muss durchgeführt werden, die Schulungsteilnehmer müssen anschliessend ohne Einarbeitungsphase mit dem System arbeiten können. Die Messbarkeit des Erfolges wird mittels eines Tests abgeprüft. Dieser Test soll von den Teilnehmern bestanden werden. Positives Feedback bei Feedbackrunde Schnittstellen zu anderen Arbeitspaketen/Projekten/ Organisationseinheiten: POS Fachbereiche Aktivitäten/Termine: Voraussetzungen für das Arbeitspaket: Schulungsmittel stehen zur Verfügung (Raum, Präsentationsmittel) Aufwand: PT Anlagen: Kosten: EUR Sonstiges: Nachbearbeitungen sind in einem anderen Paket geplant. Unterschrift Projektleitung: Unterschrift Arbeitspaketverantwortlicher: Tabelle 13: Arbeitspaket Durchführung der Schulung POS Allgemein Aufgrund der gewählten Projektteilnehmer waren die Tätigkeiten eindeutig, da die Trainer schon mehrere ähnliche Projekte durchgeführt hatten, und z.t. dem Projektleiter auch die entsprechende Erfahrung übermittelten _Grevent-Christophe_Eska-Hartmut.pdf Seite 28 von 42

29 7 Ablauf- und Terminplanung 7.1 Vorgangsliste Nummer PSP Nummer Bezeichnung Vorgänger Dauer Erste Abstimmung des Schulungsbedarf für Vertrieb Erste Abstimmung des Schulungsbedarfs für Produktmanagement Erste Abstimmung des Schulungsbedarfs für Rechnungswesen Erste Abstimmung des Schulungsbedarfs für Logistik Erste Abstimmung Schulungsbedarfs für die Kundenbetreuung Erstellung einer Systemliste Ermittlung der groben Funktionsweise der Systeme Prüfung Schulungsmittel Definition Anzahl Berater 1; 2; 3; 4; 5; Definition der Beraterprofile 1; 2; 3; 4; 5; Beratungsunternehmen auswählen 9; Vertrag und Konditionen aushandeln Erstellung der Planung 1; 2; 3; 4; 5; 7; Tabelle 14: Auszug aus der Vorgangsliste _Grevent-Christophe_Eska-Hartmut.pdf Seite 29 von 42

30 7.2 Vernetzter Balkenplan oder berechneter Netzplan Abbildung 8: Balkenplan für die Phase 1 und Phase 2 Abbildung 9: Balkenplan Phase 3 Wie für den PSP schon beschrieben liegt eine der Besonderheiten der Planung in der Auswahl der ziemlich groben Darstellung für die Schulungen und die Erstellung der Schulungsunterlagen. In einer späteren Phase erwies es sich jedoch nicht als Problem, da bei der Schulungsdurchführung, ein genauer Terminkalender der Schulungen separat _Grevent-Christophe_Eska-Hartmut.pdf Seite 30 von 42

31 gepflegt wurde. Weitere Besonderheit ist, dass aufgrund der eingesetzten Tools, die Vorgänger nicht immer den Vorgängern aus der Vorgangsliste nachfolgten. In manchen Fällen wurde hier nur eine Abhängigkeit zu Teilprojekten erstellt, die eine einfachere Darstellung wiedergeben. Die Urlaubsplanung wurde auf Mitte September 2009 gesetzt, dies wurde mit den Beratern auch explizit so besprochen. Einzelne Urlaubstage, die hier nicht im Detail geplant wurden, waren jedoch im Rahmen der Phase 3 und der Phase 4 problemlos möglich, die hier dargestellte Phase 4 war im Projektplan eine Grobplanung, die einzelnen Termine wurden in anderen Tools festgehalten (Outlook / Notes). Die Dauer bzw. der Aufwand dieser Grobplanung wurde durch die Informationsdatenbank berechnet. Abbildung 10: Balkenplan Phase _Grevent-Christophe_Eska-Hartmut.pdf Seite 31 von 42

32 Abbildung 11: Balkenplan Phase 5 und Stabsfunktionen Da das Projekt Teil eines Programms war, wurde der Gesamtplan mit Abhängigkeiten zu den anderen Projekten erstellt, was der Programmleitung eine Übersicht des kompletten Programms ermöglichte. Diese Abhängigkeiten werden hier im Transfernachweis nicht betrachtet _Grevent-Christophe_Eska-Hartmut.pdf Seite 32 von 42

33 8 Einsatzmittel- / Kostenplanung Als weiteres wesentliches Merkmal des magischen Dreiecks der Projektleitung gilt das Budget, bzw. die Mittel die im Projekt zur Verfügung stehen. Dieses wird im folgenden Kapitel betrachtet. 8.1 Einsatzmittelbedarf / Einsatzmittelplan In einem ersten Schritt ist die Art der Kosten zu ermitteln. Art der Kosten Druckkosten Beraterkosten Reisekosten Interne Kosten Beschreibung Tabelle 15: Einsatzmittelbeschreibung Kosten für die Ausdrucke der Schulungsunterlagen, Handouts Personalkosten für die Trainer Flug, Taxi und Übernachtungskosten Interne Kosten für den Projektmanager Im Rahmen des Projektes Training Migration waren die Arten relativ einfach festzustellen _Grevent-Christophe_Eska-Hartmut.pdf Seite 33 von 42

34 PSP-Code Bezeichnung Dauer Start EMB Erste Abstimmung des Schulungsbedarfs Vertrieb 8 h ,18 MA Erste Abstimmung des Schulungsbedarfs Product Management 8 h ,18 MA Erste Abstimmung des Schulungsbedarfs Rechnungswesen 8 h ,18 MA Erste Abstimmung des Schulungsbedarfs Logistik 8 h ,18 MA Erste Abstimmung des Schulungsbedarfs Kundenbetreuung 8 h ,18 MA Erstellung einer Systemliste 8 h ,9 MA Ermittlung der groben Funktionsweise der Systeme 40 h ,9 MA 1.3 Prüfung Schulungsmittel 4 h ,9 MA 1.4 Definition der Anzahl an Beratern 4 h ,9 MA Definition der Beraterprofile 8 h ,9 MA Beratungsunternehmen auswählen 40 h ,9 MA Vertrag und Konditionen aushandeln 16 h ,9 MA 1.6 Erstellung der Planung 24 h ,9 MA... Tabelle 16: Auszug aus dem Einsatzmittel-Plan Die Aufwände wurden in der Regel mit den Beteiligten besprochen, und nicht alleine durch den Projektleiter definiert. 8.2 Projektkosten Die Projektkosten sind ein typische Darstellungsweise des Budgets in dem magischen Dreieck des Projektmanagements. Die Einschätzung im Vorfeld und das spätere Steuern des Projektes beruht auf diesen Größen. Interne kosten Externe BeraterReisekosten Druckkosten Summe kumuliert January February March April May June July August September Tabelle 17: Kostenanfall In unserem Projekt war die Berechnung ziemlich einfach, da die Berater Vollzeit eingekauft _Grevent-Christophe_Eska-Hartmut.pdf Seite 34 von 42

35 waren, und der Projektleiter auch Vollzeit abgestellt war für das Projekt. Ausserdem war das Budget üppig genug um noch mehrere Monate Verspätung zu verkraften Kostenganglinie Summe February 2009 April 2009 June 2009 August 2009 January 2009 March 2009 May 2009 July 2009 September 2009 Abbildung 12: Kostenganglinie In der Kostenganglinie sieht man einen leichten Anstieg der Kosten ab dem Anfang der Phase 4, in der die Schulungen gedruckt wurden. Dieser Anstieg fiel jedoch moderat aus, da der dominierende Anteil der Kosten die Personalkosten waren, trotz der Entscheidung die Ausdrucke hochwertig - also farblich - zu gestalten Kostensummenlinie kumuliert February 2009 April 2009 June 2009 August 2009 January 2009 March 2009 May 2009 July 2009 September 2009 Abbildung 13: Kostensummenlinie _Grevent-Christophe_Eska-Hartmut.pdf Seite 35 von 42

36 Im Rahmen dieser Planung war klar, dass gegenüber dem Budget von noch einiges an Puffer zur Verfügung stand, was dem ursprünglichen Gefühl des Projektleiters auch entsprach (Siehe Steckbrief). Der reale Budgetverbrauch verlief anschließend auch weitestgehend entsprechend der Kostensummenlinie, Abweichungen im Verlauf gab es nur wegen kurzfristigen Urlaubstagen oder Krankheitstagen _Grevent-Christophe_Eska-Hartmut.pdf Seite 36 von 42

37 9 Verhaltenskompetenz 9.1 Konflikte und Krisen Der Mensch ist ein Individuum mit eigenen Erfahrungen, Einstellungen und Vorgehensweisen. Bei der Zusammenarbeit zwischen Menschen kann es zu Krisen und Konflikten kommen. Für ein Projekt bedeuten Konflikte immer Verluste, sei es Zeit, Geld oder Arbeitskraft die verloren geht. Dies kann bis zum Scheitern eines Projekts führen. Ein erfahrener Projektleiter wird im Vorfeld aufgrund seiner Erfahrung Krisenprävention betreiben, indem er zum Beispiel die Mitglieder seines Projektteam entsprechend auswählt, auf ihre Bedürfnisse achtet und auch für realistische Rahmenbedingungen für das Projekt sorgt (z.b. realistische Terminierung des Projekts). Ganz vermeiden lassen sich Konflikte aber nie, deshalb gehört es zur Aufgabe eines Projektleiters diese früh zu erkennen und entsprechend zu reagieren. Werden Konflikte nicht beachtet, lösen sie sich in der Regel nicht von selbst. Sie können sich unter der Oberfläche immer stärker entwickeln und brechen irgendwann um so stärker hervor. Bei einer Unternehmenszusammenführung ist das Potential für Konflikte hoch. Einerseits ist die Anzahl der beteiligten Mitarbeiter sehr hoch, andererseits treffen unterschiedliche Unternehmenskulturen aufeinander. Die Motivation der Mitarbeiter, die vor einer Entlassung stehen, ist sehr gering, was sich auf die Mitarbeit und den Wissenstransfer niederschlägt. Für unser Projekt Training Migration mit den vielen Stakeholders war es wichtig, einen engen persönlichen Kontakt zu den Fachbereichen zu halten. Da die Fachbereiche in Stuttgart waren, konnten manche Themen auch beim gemeinsamen Mittagessen oder zwischen durch bei einem Kaffee besprochen werden. Dieser persönliche Kontakt war sehr wichtig, um Unstimmigkeiten früh entdecken und entsprechend reagieren zu können. Zusätzlich wurden nach jeder Schulung die Fragen und Anregungen der Teilnehmer aufgenommen und die Schulung entsprechend angepasst, was auch als jeweilige Maßnahme im Projektplan eingeplant wurde. So konnte die Qualität der Schulungen und die Zufriedenheit der Teilnehmer immer weiter gesteigert werden. Für den Informationsaustausch mit den Projektleitern des Programms war es notwendig, öfters nach Hamburg zu fliegen, um auch hier den persönlichen Kontakt (face to face) herzustellen und zu pflegen. Auf diese Weise ließen sich Stimmungen und Empfindungen besser einfangen und man konnte frühzeitig feststellen, ob sich Konflikte anbahnen. Vorort lässt sich mehr bewirken als per Telefon. Ein weiterer Aspekt hier war die Erfahrungen der Trainer, die auch so gewählt wurden, _Grevent-Christophe_Eska-Hartmut.pdf Seite 37 von 42

38 dass sie in solch einer Situation nicht überfordert sein würden, und weiterhin auch das nötige Fingerspitzengefühl entwickelt haben, um in diesem Umfeld zu arbeiten. Weiterhin war es wichtig, das die Projektleitung auch als Projektleitung erschien, und die Konflikte auf sich zog, um die Trainer unbefleckt zu lassen, und ihnen zu erlauben, sich nur auf die konkrete Trainingsaufgaben konzentrieren zu können. Am Ende war es überraschend, wie wenig Konflikte in den eigentlichen Schulungen aufkamen, was z.t. auf einer Gleichgültigkeit beruhte, aber sicherlich auch auf die entwickelte Nähe zwischen den Beratern und den Mitarbeitern vor den eigentlichen Schulungen. 9.2 Ergebnisorientierung Am Ende eines Projekts sollen die Projektziele erreicht sein. D.h. zu jedem Zeitpunkt im Projekts darf die Orientierung, wohin es gehen soll, nicht verloren gehen. Zu den Projektzielen, die zu Beginn definiert und festgehalten werden, gibt es Ziele der Kunden, Mitarbeiter und aller beteiligten Stakeholder, die nicht unbedingt genannt und schriftlich fixiert sind. Für den Projektleiter gilt es diese Ziele herauszufinden. Initial werden die Projektziele zu Beginn des Projekts definiert. Die Stakeholderanalyse hat u.a. den Zweck, die Ziele der interessierten Parteien zu erkennen. Im Laufe des Projekts soll der Projektleiter diese Ziele immer wieder überprüfen und ggfs. die Steuerung des Projekts darauf neu ausrichten. Dies ist ein laufender Prozess bei dem der Projektleiter immer wieder die IST-Situation prüft und entsprechende Maßnahmen bei Bedarf vornimmt. Damit stellt er sicher, dass die Umsetzung des Projekts ergebnisorientiert verläuft. Allerdings liegt dies nicht nur bei dem Projektleiter. Alle am Projekt Mitwirkende müssen ergebnisorientiert handeln, damit die Ziele erreicht werden. Der Projektleiter sollte deshalb die persönlichen Ziele der Beteiligten kennen, um ihnen optimale Bedingungen für die Arbeit im Projekt zu schaffen. Falls persönliche Ziele konträr zum Projekt stehen, sollte der Projektleiter entsprechende Maßnahmen ergreifen, um dies zu korrigieren oder zu eliminieren. Die Ergebnisorientierung ist auch ein Schutz des Projektes gegenüber laufenden Änderungen. Sie bietet dem Projektleiter einen Rahmen für die Umsetzung und Verfolgung der Ziele, für die Kommunikation und den Umgang mit dem Projektteam und der Kommunikation mit dem Auftraggeber. Der ursprüngliche Projektauftrag war leider von der Formulierung nur sehr einfach ( Training der Mitarbeiter auf die neuen Systeme ), so dass die Ausarbeitung der Ziele hier wesentlich wurde. Der Projektleiter entschied sich hier für eine Definition mit klaren Grenzen (z.b Schulung nur von Systemen, nicht von Prozessen), die eine erste Richtung erlaubten, und konfrontierte die Stakeholder mit dieser Definition des Projektes. Anschließend wurden die einzelnen Ziele der Schulungen durch den Senior Trainer definiert, in der Datenbank festgehalten, mit den beteiligten Fachbereichen abgestimmt, _Grevent-Christophe_Eska-Hartmut.pdf Seite 38 von 42