VORGEHENSWEISE BEI DER EINFÜHRUNG VON PROJEKTMANAGEMENT · Hier werden einige Ziele für die...

90
MASTER THESIS VORGEHENSWEISE BEI DER EINFÜHRUNG VON PROJEKTMANAGEMENT ausgeführt an der Hochschule Mittweida (FH) University of Applied Sciences Studiengang MSC in Industrial Management Seminargruppe ZM06sA1 von DI (FH) Richard Wurzinger Graz, 2009 Erstprüfer: Prof. Dr. Steffen Rößler Zweitprüfer: DI Arnold Berger, MBA

Transcript of VORGEHENSWEISE BEI DER EINFÜHRUNG VON PROJEKTMANAGEMENT · Hier werden einige Ziele für die...

MASTER THESIS

VORGEHENSWEISE BEI DER EINFÜHRUNG VON

PROJEKTMANAGEMENT

ausgeführt an der

Hochschule Mittweida (FH)

University of Applied Sciences

Studiengang

MSC in Industrial Management

Seminargruppe ZM06sA1

von

DI (FH) Richard Wurzinger

Graz, 2009

Erstprüfer: Prof. Dr. Steffen Rößler

Zweitprüfer: DI Arnold Berger, MBA

KURZBESCHREIBUNG

Durch die ständig wechselnden Anforderungen und der großen Vielfalt von Projekten in Unternehmen fehlt es oft an durchgängig gelebten Projektmanagementprozessen. Ausschlaggebend hierfür ist oft das Fehlen von praxisorientierten Methodeneinsätzen, unterschiedliches Projektmanagement Know-how, fehlendes Projektcoaching, Ressourcenengpässe, keine einheitlichen Ablagestrukturen und vieles mehr. Zurzeit stehen viele Firmen vor dem Problem, ein funktionierendes Projektmanagementsystem einzuführen. Am Markt bekommt man eine große Anzahl von Projektmanagementliteratur zu kaufen. Diese beschreiben aber hauptsächlich Projektmanagementmethoden und Tools. Einen durchgängigen Ansatz wie man Projektmanagement einführt wurde von mir nicht gefunden und hat mich bewegt, dies mit dieser Master Thesis zu beschreiben. Die Erstellung wurde am Beispiel eines Unternehmens im Bereich des Anlagenbaus durchgeführt (siehe Anhang) und kann grundsätzlich für jede Firma angewendet werden.

EHRENWÖRTLICHE ERKLÄRUNG

Ich erkläre ehrenwörtlich, dass ich die vorliegende Arbeit selbständig und ohne fremde

Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die benutzten

Quellen wörtlich zitiert sowie inhaltlich entnommene Stellen als solche kenntlich gemacht

habe.

.............................................……….…...

Unterschrift

Seite 1 von 87

Inhaltsverzeichnis: 1 Einleitung..................................................................................................................3

1.1 Kapitelübersicht .................................................................................................3 1.2 Aufgabenstellung ...............................................................................................5 1.3 Motivation...........................................................................................................5 1.4 Abgrenzung........................................................................................................5

2 Ziele für die Einführung von Projektmanagement ....................................................6 3 Analyse des Ist-Zustands .........................................................................................7

3.1 Abgrenzung Projekt / Auftrag.............................................................................7 3.2 Analyse und Dokumentation der bestehenden Abläufe.....................................9 3.3 Vorhandene Kompetenzen ..............................................................................12

3.3.1 Ermittlung vorhandener Kompetenzen......................................................12 4 Einführung eines Projektmanagement-Prozesses .................................................16

4.1 Aufbau und Ablauf der Projektmanagement-Prozesse....................................16 4.2 Aufgaben im Projekt.........................................................................................18

4.2.1 Soziale Teamverantwortung......................................................................19 4.2.2 Fehlerkultur – Umgang mit Abweichungen................................................19 4.2.3 Bringschuld und Holschuld........................................................................19 4.2.4 Vier-Augen-Prinzip ....................................................................................19

4.3 Definition notwendiger Rollen ..........................................................................20 4.3.1 Projektauftraggeber (PAG) ........................................................................20 4.3.2 Projektleiter (PL)........................................................................................22 4.3.3 Projektteammitglied...................................................................................23 4.3.4 Projektmitarbeiter ......................................................................................24

4.4 Prozessdokumentation ....................................................................................25 4.4.1 Beschreibung / Merkmale einer Swimlane ................................................26

4.5 Anpassen der Organisation .............................................................................29 4.6 Notwendige Kompetenzen und deren Entwicklung .........................................33

4.6.1 Begriffe, Definitionen .................................................................................33 4.6.2 Grundsätzlicher Ablauf ..............................................................................33 4.6.3 Durchführung und Überwachung...............................................................34 4.6.4 Neu eingestellte Mitarbeiter.......................................................................34 4.6.5 Kompetenzentwicklung..............................................................................34

5 Controlling und Kennzahlen ...................................................................................36 5.1 Entwicklung von Kennzahlen ...........................................................................36

5.1.1 Definition Kennzahl....................................................................................36 5.1.2 Aufbau eines Monitoring-Systems.............................................................36 5.1.3 Kennzahlen im Projektmanagement-Prozess ...........................................38

5.2 Projektcontrolling .............................................................................................39 5.3 Prozesscontrolling mittels Quality Gates .........................................................41

6 Multiprojektmanagement ........................................................................................43 6.1 Begriffsdefinition ..............................................................................................43 6.2 Kernpunkte im Multiprojektmanagement .........................................................45 6.3 Multiprojektmanager ........................................................................................46 6.4 Multiprojektcontrolling ......................................................................................47

Seite 2 von 87

6.4.1 Abgrenzung Einzelprojektcontrolling- Multiprojektcontrolling ....................48 7 Rechnergestütztes Projektmanagement ................................................................50

7.1 Ziele für die Einführung einer Projektmanagement-Software ..........................50 7.2 Anforderungen erfassen / Pflichtenhefterstellung ............................................51

7.2.1 Beispiel eines Use Cases: Projektmanagement und Controlling ..............51 7.2.2 Hoher Benutzerkomfort .............................................................................52

7.3 Evaluierung einer geeigneten Projektmanagement-Software..........................53 7.4 Rollout der PM Software ..................................................................................58 7.5 Schwierigkeiten bei der Einführung von Projektmanagement-Tools................60

8 Anreizsysteme / Bonifikationsmodelle ....................................................................62 8.1 Bonifikationsmodel für Projektleiter..................................................................62

9 Resümee ................................................................................................................64 10 Anhang ...................................................................................................................65

10.1 Literaturhinweise...........................................................................................65 10.2 Abbildungsverzeichnis ..................................................................................67 10.3 Kurzbeschreibung eines Unternehmens im Anlagenbau..............................68 10.4 Fragenkatalog zum Projektmanagement......................................................71 10.5 Prozess Ablaufdiagramm..............................................................................74 10.6 Beschreibung zum Prozessablauf mit Einbeziehung eines PM Tools..........76 10.7 Bewertungsmatrix .........................................................................................87

Seite 3 von 87

1 Einleitung

1.1 Kapitelübersicht

Kapitel 1: Einleitung Dieses Kapitel beinhaltet die Aufgabenstellung, die Motivation und Abgrenzung der Master Thesis.

Kapitel 2: Definition der Ziele für die Einführung von Projektmanagement Hier werden einige Ziele für die Einführung von Projektmanagement beispielhaft beschrieben.

Kapitel 3: Analyse des Ist-Zustands Schwerpunkt dieses Kapitels ist eine Beschreibung der Vorgehensweise wie der „Ist-Zustand“ in einem Unternehmen hinsichtlich bestehender Abläufe und Projektmanagement Know-how erfasst werden und wie die Ergebnisse zusammengefasst und ausgewertet werden können.

Kapitel 4: Einführung eines Projektmanagement-Prozesses In diesem Kapitel werden der Aufbau und die Dokumentation eines Projekt-managementprozesses beschrieben, die notwendigen Rollen definiert und ein Ausblick über die passende Organisationsform gegeben.

Kapitel 5: Controlling und Kennzahlen Die Erstellung von Kennzahlen, die Unterstreichung der Wichtigkeit von Projekt-controlling sowie ein Ansatz für Prozesscontrolling über Quality-Gates sind Inhalte dieses Kapitels.

Kapitel 6: Multiprojektmanagement Dieses Kapitel beschäftigt sich mit der Differenzierung Projektmanagement / Multiprojektmanagement, der notwendigen Rollen und dem Multiprojektcontrolling.

Kapitel 7: Rechnergestütztes Projektmanagement Hier wird die Vorgehensweise bei der Einführung eines unterstützenden Projektmanagement-Tools beschrieben. Dies beinhaltet sämtliche Schritte vom Anforderungskatalog über die Evaluierung, der Wirtschaftlichkeitsbetrachtung bis hin zur Ausrollung des Tools.

Kapitel 8: Anreizsysteme / Bonifikationsmodelle Dieses Kapitel zeigt Beispiele von Bonifikationsmodellen deren Nutzen und deren Probleme auf.

Seite 4 von 87

Kapitel 9: Resümee Inhalt dieses Kapitels sind die aus dieser Arbeit gewonnenen Erkenntnisse in einer kurzen Zusammenfassung.

Kapitel 10: Anhang Der Anhang beinhaltet das Literaturverzeichnis, das Abbildungsverzeichnis sowie einige Beispiele aus der Praxis. Darüber hinaus beinhaltet dieses Kapitel eine Kurzbeschreibung jenes Unternehmens, dass als Beispiel herangezogen wurde.

Seite 5 von 87

1.2 Aufgabenstellung

Unternehmen sind heutzutage einer großen Vielfalt von Projekten ausgesetzt und mit ständig wechselnden Anforderungen konfrontiert. Meist fehlt es an durchgängig gelebten Projektmanagementprozessen. Ausschlaggebend hierfür ist oft das Fehlen von praxisorientierten Methodeneinsätzen, unterschiedliches Projektmanagement Know-how, fehlendes Projektcoaching, Ressourcenengpässe, keine einheitlichen Ablagestrukturen und vieles mehr. Zurzeit stehen viele Firmen vor dem Problem ein funktionierendes Projekt-managementsystem einzuführen. Das Ziel dieser Master Thesis ist die Erstellung eines Leitfadens die es diesen Firmen ermöglicht Projektmanagement effizient einzuführen bzw. bestehende Systeme zu optimieren. Der Nutzen liegt im Ergebnis eines einheitlichen gruppenübergreifenden modernen und angepassten Projektmanagements. Durch die Verwendung gleicher Tools und gleicher Methoden kommt es zu einer wesentlichen Arbeitserleichterung und dadurch zu einer Unterstützung aller Projektmanager und Projektmitarbeiter eines Unternehmens.

1.3 Motivation

Am Markt bekommt man eine große Anzahl von Projektmanagementliteratur zu kaufen. Diese beschreiben aber hauptsächlich Projektmanagementmethoden und Tools. Darüber hinaus sind die Bücher fast für jede Branche (Bau, IT,…) verfügbar. Einen durchgängigen Ansatz wie man Projektmanagement einführt wurde von mir nicht gefunden und hat mich bewegt dies mit dieser Master Thesis zu beschreiben. Grundlage hierfür sind hauptsächlich meine gesammelten Erfahrungen der letzten Jahre in denen ich mich mit dieser Problemstellung beschäftigt habe und nach wie vor in diesem Bereich tätig bin.

1.4 Abgrenzung

Eine Beschreibung und Erklärung von Projektmanagementmethoden (z.B. Umweltanalyse, Projektstrukturplan,…) wird nicht vorgenommen. Die Umsetzung der theoretischen Abhandlung anhanden der beschriebenen Praxisbeispiele ist nicht Ziel dieser Master Thesis.

Seite 6 von 87

2 Ziele für die Einführung von Projektmanagement Die wichtigste Frage die man sich am Beginn einer Einführung von Projekt-management stellen sollte ist: „Was will ich mit der Einführung von Projektmanagement erreichen?“ Mögliche Ziele: Organisatorische Ziele:

Vereinheitlichung von Abläufen und Begriffsdefinitionen und mitarbeitergerechte Aufbereitung.

Differenzierung der Art der Projektabwicklung nach Komplexität, Größe und Risikosituation der Projekte.

Effektive und effiziente Projektdokumentation für Kundenbedarf (technisch / kaufmännisch / rechtlich) u. a. für Claimmanagement und Aufbau von Experten-wissen.

Einheitliche Struktur und Transparenz in den Projekten.

Mitarbeiterorientierte Ziele:

Bewusstseinsbildung über Frühwarnsysteme, Umfeldanalysen, Risiko-management, Claimmanagement, Kommunikationsverhalten intern und extern im Projekt, Informationspolitik (Bringschuld, Holschuld).

Erarbeitung eines effektiven Personalentwicklungskonzeptes für Projekt-management inklusive gezielten Wissensaufbau in der Kernkompetenz und leistungsorientierte, erfolgsabhängige Anreizsysteme.

Qualität und Sicherheit in Projekten

Etablierung und Sicherstellung eines einheitlichen, qualitativ hochwertigen, lebbaren Projektmanagementstandards im Unternehmen.

Sicherstellung einer einheitlichen Projektdokumentation (Basis für effizientes zeitnahes Multiprojektcontrolling)

Ganzheitliches und zeitnahes Projektcontrolling über Kosten, Termine, Leistung, Risiken etc.

Hohe Qualität im Multiprojektcontrolling um den Betriebserfolg sicherzustellen. Sicherstellung eines kontinuierlichen Verbesserungsprozesses (Wissens-

sicherung) im Projektmanagement durch Verwaltung und Nutzung von "Best Practice Vorlagen".

Die Ziele sind in Abhängigkeit der Firmenstrategie festzulegen und gegebenenfalls in die Firmenstrategie zu übernehmen.

Seite 7 von 87

3 Analyse des Ist-Zustands

3.1 Abgrenzung Projekt / Auftrag1

Projekte können unterschiedlich wahrgenommen werden, und zwar als

komplexe Aufgaben temporäre Organisationen soziale Systeme

Für das Unternehmen, welches Projekte durchführt, stellen diese komplexe Aufgaben dar, die daneben oft auch neuartig und riskant sein können. Die Zielfestsetzung erfolgt unter Konkretisierung des Leistungsumfangs, der Termine, der Ressourcen und der Kosten. Dies wird zwischen dem Projektauftraggeber und dem Projektleiter vereinbart. Daher werden Projekte auch als zieldeterminierte Aufgaben bezeichnet. Darüber hinaus werden Projekte teilweise als Organisationen wahrgenommen. Im Vergleich zu den meist permanenten Strukturen der Stammorganisation von Unternehmen (z.B. Bereiche, Geschäftsfelder, Abteilungen) stellen Projekte temporäre Organisationen dar. Projekte können auch als soziale Systeme wahrgenommen werden, die sich einerseits klar von ihren Umwelten abgrenzen und andererseits zu diesen Beziehungen haben. Als eigenständiges System hat ein Projekt einen spezifischen Sinn und eine eigene Struktur. Elemente der Projektstruktur sind z.B. projektspezifische Werte und Regeln, Projektrollen, projektspezifische Kommunikationsformen, Planungs- und Controlling-methoden. Projekte sind von Nicht-Projekten wie z.B. Routineaufgaben der Stammorganisation oder Programmen, zu unterscheiden. Die Differenzierung von Projekten in unterschiedliche Projektarten ermöglicht es, je Projektart spezifische Herausforderungen und Potentiale für das Projektmanagement zu analysieren. Projekte können nach Branche, Projektstandort oder Projektziel, Konkretisierungs- bzw. Wiederholungsgrad, Auftraggeberschaft, Projektdauer und Bezug zu Unternehmensprozessen differenziert werden.

1 Vgl. PMA, pm baseline Version 2.4, Mai 2007

Seite 8 von 87

Abbildung 1: Überblick über temporäre Aufgaben2

Im ersten Schritt ist zu prüfen ob es sich bei den „sogenannten“ Projekten wirklich um Projekte oder um Aufträge / Aufgaben handelt. Auf Basis des Leistungsspektrums eines Unternehmens können eine Vielzahl von Bewertungskriterien ermittelt werden um dies festzustellen. Die Ermittlung sollte gemeinsam mit ausgewählten Projektleitern, Projektauftraggebern sowie den Verantwortlichen Linienmanagern durchgeführt werden.

Folgende Parameter können Beispielsweise für die Bewertung der Komplexität von Projekten herangezogen werden:

Liefer- und Leistungsumfang Projektdauer Neuer Kunde / Markt Neue wesentliche Partner Neues Produkt Anzahl der internen und externen Organisationen strategische Bedeutung Risikopotential Auftragswert Vertragsdokumente Vertragssprache

Zur Vereinfachung der Kriterienfindung kann das Projektmanagement-Dreieck (siehe Abbildung 2) als Hilfestellung herangezogen werden.

2 Vgl. Sterrer, Winkler, Let your projects fly, 2006

Seite 9 von 87

Abbildung 2: Abhängigkeiten im Projektmanagement-Dreieck3

3.2 Analyse und Dokumentation der bestehenden Abläufe

In Unternehmen mit mehreren Organisationseinheiten ist herauszufinden wie in den einzelnen Einheiten Projekte abgewickelt werden. Als Instrument hierfür haben sich Projektaudits bzw. Projektmanagement-Assessments bewährt. In der Praxis kann hierfür das „Project Excellence“ Model4 herangezogen werden. In Anlehnung an das „Total Quality“ Model bewertet das „Project Excellence“ Model insgesamt neun Kriterien, die in zwei Bereiche – Projektmanagement und Projektergebnisse gegliedert sind.

Abbildung 3: Project Excellence Model

3 Vgl. Sterrer, Winkler, Let your projects fly, 2006 4 Vgl. PMA, pma Award 2008, Leitfaden für Bewerber Stand Jan. 2008

Seite 10 von 87

Kriterium 1: Zielorientierung Wie das Projekt seine Ziele aufgrund umfassender Informationen über die Anforderungen der relevanter Projektumwelten formuliert, entwickelt, überprüft und umsetzt. Kriterium 2: Führung Wie das Verhalten der Führungskräfte im Projekt „Project Excellence“ inspiriert, unterstützt und promotet. Kriterium 3: Mitarbeiterorientierung Wie die Projektteammitglieder und Projektmitarbeiter einbezogen und ihre Potentiale erkannt und genutzt werden. Kriterium 4: Management von Ressourcen Wie die vorhandenen Ressourcen wirksam und effizient eingesetzt werden. Kriterium 5: Management der Prozesse Wie im Projekt wertschöpfende Prozesse identifiziert, überprüft und gegebenenfalls verändert werden. Kriterium 6: Kundenzufriedenheit Was das Projekt im Hinblick auf die Erwartungen und Zufriedenheit seiner Kunden leistet. Kriterium 7: Mitarbeiterzufriedenheit Was das Projekt im Hinblick auf die Erwartungen und Zufriedenheit seiner Projektteam-mitglieder und -mitarbeiter leistet. Kriterium 8: Zufriedenheit bei sonstigen Interessengruppen Was das Projekt im Hinblick auf die Erwartungen und Zufriedenheit sonstiger relevanter Projektumwelten leistet. Kriterium 9: Projektergebnis Was das Projekt im Hinblick auf das geplante Projektziel leistet. Assessoren bewerten die Projekte nach diesen Kriterien und stellen demgemäß Fragen im Rahmen von Interviews und der Dokumentenanalyse. Beispiele für Fragen können dem von der PMA (Projektmanagement Austria) zur Verfügung gestellten Leitfaden5 entnommen werden.

5 Vgl. PMA, pma Award 2008, Leitfaden für Bewerber Stand Jan. 2008

Seite 11 von 87

Die Bewertung der Projekte erlaubt es Stärken und Verbesserungspotentiale zu erfassen und zu dokumentieren und lässt einen Vergleich zwischen unterschiedlichsten Projekttypen zu.

Scoring in %

52%46%

27%

49%

41%47%

39%43%

47%49%43%

37%30%

34%

56% 58%

13%

60%

41%

49%

34%

47%

26%

43%

33%

23%

35%

78%73%

51%

66%

49%

57%63%

42%

54%

65%

51%

29%

57%63% 65%

32%

47%

71%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Kriterium1

Kriterium2

Kriterium3

Kriterium4

Kriterium5

Kriterium6

Kriterium7

Kriterium8

Kriterium9

Projekt 1 Projekt 2 Projekt 3 Projekt 4 Projekt 5

Abbildung 4: Projektvergleich anhanden des "Project Excellence" Models

Bei den in Abbildung 4 dargestellten Projekten handelt es sich um sehr große „Turn Key“ Projekte (Auftragsvolumen > 100 Millionen €) bis hin zu Softwareupdates (Auftragsvolumen < 100.000 €). Darüber hinaus wurden diese in verschiedenen Ländern realisiert und über die jeweiligen Tochtergesellschaften abgewickelt. Die dokumentierten Ergebnisse der Assessments spiegeln den aktuellen Ist-Zustand der Unternehmensgruppe wieder. Um ein exaktes Bild über das Unternehmen zu bekommen sollte man zumindest von jeder Projektabwickelnden Organisationseinheit (Bereiche, Geschäftsfelder, Abteilungen, Tochtergesellschaften) 2-3 Projekte assessieren. Es empfiehlt sich Projekte, die sehr gut und jene die sehr schlecht gelaufen sind, auszuwählen.

Seite 12 von 87

3.3 Vorhandene Kompetenzen

In den meisten Unternehmen mangelt es nicht an bereits definierten Abläufen und Prozessen sondern…

diese nicht gelebt werden, diese nicht der Realität entsprechen, notwendiges Projektmanagement Know-how nicht vorhanden ist

Die ersten beiden Punkte können über die in Kapitel 3.2 beschriebene Methodik eruiert werden.

3.3.1 Ermittlung vorhandener Kompetenzen

In den meisten Unternehmen gibt es mittlerweile eine Vielzahl von Projektleitern bzw. Projektmanagern. Leider wird diese „Berufsbezeichnung“ oft fälschlicherweise benutzt. Hierfür wurden von mir mehrere Unternehmen in der Größenordnung von 250 bis zu 5000 Mitarbeitern untersucht. Meine Recherchen ergaben folgendes:

In kleineren Unternehmen wird der Begriff Projektleiter für Projektanten, Projektabwickler, Auftragsabwickler und „tatsächliche“ Projektleiter (Projekt-manager) verwendet.

In größeren Unternehmen führen auch Arbeitspaketverantwortliche sowie Teilprojektleiter die Berufsbezeichnung Projektleiter.

Darüber hinaus wurde in einem Unternehmen mittlerer Größe der Begriff Programmmanager anstelle von Projektleiter (Projektmanager) verwendet. Dies wurde damit begründet, dass es sich bei den Projekten um Teile eines externen Programms handelt.

Wie zu sehen ist, fängt das Problem bereits bei der Definition „Projektleiter“ an. Die Ermittlung des Know-hows wurde anhanden des in Kapitel 10.3 beschriebenen Unternehmens durchgeführt. Für die Ermittlung empfiehlt es sich ein Projektteam einzusetzen. Dieses Team sollte aus folgenden Personen / Rollen bestehen:

Erfahrene Projektleiter mit Projektmanagement-Zertifizierung (wenn keine internen Ressourcen mit der notwendigen Ausbildung zur Verfügung stehen empfiehlt es sich einen externen Konsulenten einzubeziehen)

Der Prozessverantwortliche wenn ein Projektmanagementprozess existiert Der Leiter der Projektleiter Mitarbeiter aus dem Bereich „Human Resources“ um Schulungs- und

Karrierepläne zu erarbeiten

Seite 13 von 87

Die Erfassung kann entweder in Form einer schriftlichen Prüfung oder in Form eines Interviews stattfinden. Hierfür ist ein Fragebogen (siehe Anhang Kapitel 10.4) basierend auf der PM Baseline6 zu erstellen. Dieses Grundlagenwerk ist Basis für die Projektmanagementzertifizierung in Österreich und kann unter www.p-m-a.at gratis bezogen werden. Über die fachliche Qualifikation hinaus sind auch die Soft Skills zu überprüfen. Die wichtigsten Punkte in diesem Bereich sind…

Mitarbeiterführung und Führungsverhalten7 Verhandlungsgeschick8 Selbstmanagement9 Krisen und Konfliktmanagement10 Kommunikation11 und Präsentation12

Das Interview bzw. die schriftliche Prüfung wurde an den verschiedenen Standorten durchgeführt (Dauer ca. 1 - 1,5 h). Die Auswertung der Interviews wurde in Form einer Tabelle dargestellt (siehe Abbildung 5) um maßgeschneiderte Trainingsprogramme für die unterschiedlichen Wissenslevel festzulegen. Die Umsetzung ist in Kapitel 4.6 beschrieben. Die Untersuchung im Kapitel 10.3 beschriebenen Unternehmen hat gezeigt, dass das Wissen bezüglich des Projektmanagements sehr unterschiedlich war. Es wurden ca. 30 „sogenannte“ Projektleiter bei dieser Untersuchung befragt. Nur etwa 35% bis 40% der Befragten waren mit den Methodiken des Projektmanagements vertraut. Die meisten konnten die Begriffe Projektumweltanalyse, Projektstrukturplan, Projektcontrolling, Claimmanagement, Aufgaben verschiedener Projektrollen,… nicht eindeutig erklären.

6 Vgl. PMA, pm baseline Version 2.4, Mai 2007 7 Vgl. Stroebe, Grundlagen der Führung, 11. Auflage 2002 8 Vgl. Fisher, Ury, Patton, Das Harvard Konzept, 1991 9 Vgl. Stehling, Ja zum Stress, 2000 10 Vgl. von Hertel, Professionelle Konfliktlösung, 2003 11 Vgl. Lay, Führen durch das Wort, 5. Auflage 2002; Braun, Die Macht der Rhetorik, 2001 12 Vgl. Forsyth, 30 Minuten bis zur überzeugenden Präsentation, 3. Auflage 2001

Seite 14 von 87

Abbildung 5: Auswertung der Befragung für einen Standort

Bei jenen Personen mit einer Projektmanagement-Zertifizierung war das Methoden-wissen sehr hoch. Überraschend war, dass auch lang gediente Projektleiter kaum über Methodenwissen verfügten. Diese haben rein aus eigenen Erfahrungen gehandelt und waren entsprechend gut in der Projektabwicklung.

Abbildung 6: Auswertung des Projektmanagement Know-how

Seite 15 von 87

Eines der Hauptprobleme ist, dass viele das Projektmanagement mit der Projektabwicklung verwechseln beziehungsweise keine Differenzierung vornehmen. In der Auswertung in Abbildung 6 kann man eindeutig erkennen, dass die Stärken in der Projektabwicklung liegen. Grund hierfür ist, dass sich vor allem Techniker viel stärker mit der inhaltlichen Projektarbeit identifizieren und die Aufgaben des Projekt-managements vernachlässigen. Eine weitere Schwachstelle in den meisten Unternehmen sind der Umstand, dass betriebswirtschaftliche Grundkenntnisse kaum vorhanden sind und das Projektcontrolling von vielen der befragten Projektleiter nur fürs Management durchgeführt wurde, ohne darin eine Notwendigkeit für die Steuerung der eigenen Projekte zu sehen. Zur Abwicklung von Projekten muss stets ein inhaltlicher Projektabwicklungsprozess und der Projektmanagement Prozess durchlaufen werden. Die Unterschiede sind in der nachfolgenden Abbildung sehr gut dargestellt.

Projekt-beauftragung

Projekt-start

Projekt-controlling

Projektkrise Projekt-abschluss

ProjektmanagementProzess

Projekt-evaluierung

Projektkoordination

Inhaltlicher Prozess

N

Vorprojekt-phase

Nachprojekt-phase

Projekt-auftrag

Projekt-abnahme

Projekt-beauftragung

Projekt-start

Projekt-controlling

Projektkrise Projekt-abschluss

ProjektmanagementProzess

Projekt-evaluierung

Projektkoordination

Inhaltlicher Prozess

N

Vorprojekt-phase

Nachprojekt-phase

Projekt-auftrag

Projekt-abnahme

Abbildung 7: Unterschied Projektmanagement / Projektabwicklung13

13 EVOLOSO Organisationssoftware & Consulting GmbH, Benutzerhandbuch PM-smart®

Seite 16 von 87

4 Einführung eines Projektmanagement-Prozesses Bei der Einführung von Prozessen sollte man anhanden der in Kapitel 2 beschriebenen Zielsetzungen vorgehen. Auf Basis der Analyse wurden bereits Abläufe festgestellt und sind nun so festzuhalten, dass diese mit den Zielen korrelieren. Wichtig ist es sich zu überlegen wie dies in die bestehende Prozesslandschaft zu integrieren ist. Bei kleineren und mittleren Unternehmen die bereits als Projekt- oder Matrixorganisation aufgestellt sind ist dies leichter zu bewerkstelligen als bei großen Unternehmen mit starren hierarchischen Strukturen.

Kun

de Kunde

P03 7 01 Projektvertrieb

PMHB / P04 7 01 Projektablauf

Projektmanagement / techn. und kaufm. Abwicklung

P05 7 01 Beschaffung/P05 702 Fremdleistung

P08 7 01 / P08 7 02 Service

P09 7 01 Handel

P10 7 01 Produktentwicklung

Materia l- /Re ssourcenbestellung Kre ditoren ve rwaltun g

La gerung/Ide ntitätsprü fung

Unterschriftenregelung,Produktbeschaffung

P06 7 01 FertigungVor-/

Na ch besprechun g

Lieferkon trolle Terminüberwachung

Fe rtigung

P06 7 02 MontageVor-/

Na ch besprechun gMonta ge-/

Überwachung

Aufmass Lieferkontro lle

Kundenorientierung/Marktbeobachtung Angebot

After Sales ServiceKundenverhandlung

P01 5 01 Oberste LeitungFührung Planung, Strategie, Ziele, internes Kontrollsystem

MarketingPersonalentwicklung

P02 4 01 QualitätsmanagementQM-System Lenkung d. Dokumente, Daten, Aufzeichnungen/Kennzeichnung Rückverfolgbarkeit

AuditVerbesserung / Messung

W arenanna hme

$ $$

Ein kauf

$$

BankenLieferanten/Zulieferer

Fertigung/MontageLa ger

Gesellschafter/Eigentümer

Einwirkungen von Außen(Umwelt)

Angebotserstellung Abwicklung

Kundenorientierung/Vertrieb Auftragsabwicklung

Langfristige WartungsverträgeLaufende Kundenbetreuung

Marktbeobachtung Ideenfindung

Überleitung ins NormalgeschäftRealisierung der neuen Produkte

Erke nntnisse

……..., ………. ,

……………...

P07 5 01 RechnungswesenEinga ngsrechnu ngen Ausgangsrech nugen

Be richtswesen /Con trolling

Bugeterstel lung

Behörden

P11 7 01 Techn. Planung CADSoftwareerstellun g CAD f. SAB

CAD f. ET

Abbildung 8: Beispiel einer Prozesslandkarte

4.1 Aufbau und Ablauf der Projektmanagement-Prozesse

Generelles Grundprinzip ist das unternehmerische Denken und Handeln in den Projekten, vom Vertrieb über die Planung bis zur endgültigen Übergabe an den Kunden. Das heißt Berücksichtigung der Kunden-, Eigentümer- und Mitarbeiterbedürfnisse. Bei der Erstellung der Prozesse hat sich eine TOP – DOWN Vorgehensweise bewährt. Die Beschreibung der obersten Ebene ist in den meisten Literaturquellen ähnlich und

Seite 17 von 87

sollte somit nicht neu erfunden werden. Das in Abbildung 9 abgebildete Prozessmodel zeigt die Umsetzung über ein Software Tool und entspricht dem IPMA Standard.

Abbildung 9: Projektmanagementprozesse

Es empfiehlt sich, ein Projektmanagementhandbuch als Leitfaden für die Projektleiter zu erstellen. Dieses Projektmanagementhandbuch ist Teil des Projektmanagement-prozesses und beschreibt die detaillierten Abläufe (das „WIE“). Abgeleitet daraus wird ein Projekthandbuch ab Beginn eines Projektes geführt bzw. ist dieses über die gesamte Projektlaufzeit (z.B. in einem Softwaretool PM-smart® siehe Abbildung 10) auf aktuellen Stand zu halten. Inhalt des Projekthandbuchs:

Projektauftrag Version 1 = Basisplan Vertragsanalyse technisch / kaufmännisch Projektumfeldanalyse Projektrisikoanalyse Projektstrategie Übersichtsterminplanung, Detailterminplanung und Meilensteine Ressourcenplan des Projektes, Bestätigungen der Ressourcenverantwortlichen Projektkostenplanung Erlösplan Projektorganisation (Team-Projektstruktur) Dokumente des Projektberichts- und Kommunikationswesen

Seite 18 von 87

Abbildung 10: Projektstartprozess in PM-smart®

4.2 Aufgaben im Projekt

Die Ermittlung der Kundenforderungen und die Überprüfung der Machbarkeit sind durchzuführen, um schon im Vorfeld die Voraussetzungen eines beiderseitig erfolgreichen Geschäftsverlaufes zu gewährleisten. Die Montage- und Inbetriebnahmeverfahren werden so geplant und festgelegt, dass eine Abweichung von geforderten Qualitätsmerkmalen im Projekt während der Planung, Montage und Inbetriebnahme möglichst früh festgestellt werden kann. Dadurch werden Fertigungs- und Montagestörungen, Fehler im Projekt, Ausfälle im Einsatz (Kundenreklamationen) usw., die durch mangelhafte Montage- und Inbetriebnahmequalität entstehen können, vermieden.

Seite 19 von 87

4.2.1 Soziale Teamverantwortung

Projektmanagement als Prozess heißt tägliche Arbeit mit Menschen der Kunden-, Partner-, Lieferanten- und eigenen Unternehmensorganisation. Dies stellt an den Projektleiter, Projektauftraggeber und das Projektteam eine hohe Herausforderung und Verantwortung an die Art und Weise der Kommunikation, Aufgabendelegation, Informationsweitergabe und generellen Wertschätzung dar. Eine entsprechend hohe Qualität in diesen „Aktivitäten“ ist unabdingbar für einen Projekterfolg.

4.2.2 Fehlerkultur – Umgang mit Abweichungen

Abweichungen (Fehler) sind unvermeidlich bei Projekten. Das Ziel des Projektmanagements und insbesondere des Qualitätsmanagements ist, Fehler in der Zukunft zu verhindern. Aus Sicht des Qualitätsmanagements stellt eine Abweichung eine "Nichtkonformität" dar, die unverzüglich behoben werden muss und deren Ursache abzustellen ist. Aus anderer Sicht stellt eine solche Abweichung hingegen auch eine Möglichkeit dar, neue Erkenntnisse zur Prozessoptimierung (Produktivitätssteigerung) zu gewinnen. Methodisch sind hierbei zwei Vorgehensweisen besonders hilfreich:

Das gelebte Risikomanagement – Vermeidung, Verhinderung von Abweichungen Umsetzung der Erkenntnisse aus "Lessons Learned" durch Führungskräfte und

Projektleiter

Wichtig ist, dass, wenn Fehler gemacht werden, nicht primär nach dem Verursacher zu suchen ist, sondern die Ursachen aufzuzeigen und zu analysieren und im Weiteren aus den Erkenntnissen wissenswertes für das gesamte Unternehmen herauszuarbeiten.

4.2.3 Bringschuld und Holschuld

Als Bringschuld ist die Verpflichtung zu verstehen, Informationen und / oder Unterlagen selbstständig und ohne Aufforderung weiterzugeben. Als Holschuld ist die Verpflichtung zu verstehen, sich Informationen und / oder Unterlagen zu verschaffen und sich nicht darauf zu verlassen, diese automatisch zu bekommen.

4.2.4 Vier-Augen-Prinzip

Im Sinne einer Qualitätssicherung und Risikovorsorge sind die wesentlichen Tätigkeiten (z.B. Vertragsanalyse) nach dem Vier-Augen-Prinzip aktiv durchzuführen.

Seite 20 von 87

4.3 Definition notwendiger Rollen14

In Projekten gibt es üblicherweise folgenden Rollen:

Projektauftraggeber Projektleiter Projektteammitglieder Projektmitarbeiter

Entsprechend der Komplexität des Projekts können weitere Rollen, wie ein Lenkungsausschuss, ein Projektoffice oder ein Projektcoach definiert werden. Ähnlich wie in der Stamm- oder Linienorganisation, in der Stellenbeschreibungen für die meisten Rollen (z.B. Abteilungsleiter) existieren, sollten auch bei temporären Organisationen Rollen beschrieben sein. Projektrollen werden grundsätzlich über Aufgaben (Verantwortlichkeiten) und Kompetenzen (Befugnisse) beschrieben. Es hat sich in der Praxis bewährt, Standard-Rollenbeschreibungen als Diskussionsgrundlage für die Rollenklärung in Projekten heranzuziehen. Dadurch fällt es leichter, definierte Aufgaben zu verteilen und erforderliche Kompetenzen sicherzustellen. Die wichtigsten Rollen sind in den nächsten Kapiteln beschrieben.

4.3.1 Projektauftraggeber (PAG)

Organisatorische Stellung

Steht projektbezogen für die Wahrnehmung der Unternehmensinteressen (meist Segmentleiter bzw. Leiter eines strategischen Geschäftsfelds)

Ist projektbezogen dem Projektleiter gegenüber weisungsbefugt und steuert gemeinsam mit diesem auf der strategischen Ebene.

Ist Teil des Lenkungsausschusses (falls vorhanden) Wird vom Projektsteuerkreis eingesetzt und ist mit dem Projektleiter für den

Projekterfolg mitverantwortlich Aufgaben

Auswahl des Projektleiters und Unterstützung bei der Besetzung des Projektteams

Formulierung und Unterzeichnung des Projektauftrags (gemeinsam mit Projekt-leiter)

Führung des Projektleiters Zielvereinbahrung mit dem Projektteam Beitrag zur Konfliktbewältigung und zum Projektmarketing

14 Vgl. Sterrer, Winkler, Let your projects fly, 2006

Seite 21 von 87

Durchführung von Projektauftraggebersitzungen Strategisches Projektcontrolling Treffen von anstehenden Projektendscheidungen Unterstützung bei Eskalationen auf Basis zugesagter, jedoch nicht verfügbarer

Projektressourcen oder Finanzmittel Beitrag zur Sicherung des Know-how Transfers in die Linienorganisation

Organisatorische Rechte

Auswahl des Projektleiters Auswahl des Projektteams gemeinsam mit dem Projektleiter Veränderung der Projektziele und Freigabe von Zieladaptionen Einkaufsentscheidung über €…. Entscheidung Projektabbruch Interne Projektabnahme und Entlastung des Projektleiters Freigabe von Termin-, Ressourcen- und Kostenänderungen

Abbildung 11: Darstellung einer relationalen Rollendefinition zwischen PAG und PL

Seite 22 von 87

4.3.2 Projektleiter (PL)

Organisatorische Stellung

Vertreter des Projekts gegenüber den projektspezifischen Umwelten Koordiniert die anderen Projektteammitglieder und -mitarbeiter und ist

projektbezogen diesen gegenüber weisungsbefugt Berichtet dem Projektauftraggeber und ist diesem gegenüber projektbezogen

weisungsgebunden Aufgaben

Bildung des Projektteams Formulierung und Unterzeichnung des Projektauftrags (gemeinsam mit dem

Projektauftraggeber) Gestaltung der Projektmanagement-Teilprozesse Projektstart, Projekt-

controlling, Projektkoordination, Projektabschluss gemeinsam mit dem Projektauftraggeber und dem Projektteam

Know-how Transfer aus der Vorprojektphase in das Projekt Validierung der Projektziele gemeinsam mit dem Projektteammitgliedern Erstellung adäquater Projektpläne gemeinsam mit den Projektteammitgliedern Planung von Maßnahmen zum Risikomanagement, zur Krisenvermeidung und -

vorsorge gemeinsam mit den Projektteammitgliedern Zyklische Feststellung des Projektstatus mit den Projektteammitgliedern Vereinbahrung bzw. Vornahme steuernder Maßnahmen gemeinsam mit dem

Projektteammitgliedern Erstellung von Fortschrittsberichten gemeinsam mit dem Projektteam-

mitgliedern Organisatorische Rechte

Einberufen von Projektauftraggebersitzungen und Projektteamsitzungen Einkaufsentscheidungen bis €…. Aufgabenverteilung auf Projektteammitglieder und Projektmitarbeiter Einfordern von projektrelevanten Informationen von den Projektteammitgliedern Ressourcen und Kostenverschiebungen innerhalb des Projekts Vergabe von Lese- und Schreibrechten für spezifische Arbeitspakete Freigabeberechtigung für Termin-, Ressourcen- und Kostenänderungen der

jeweiligen Arbeitspaket-Verantwortlichen

Seite 23 von 87

4.3.3 Projektteammitglied

Organisatorische Stellung

Berichtet dem Projektleiter und ist dem Projektleiter gegenüber projektspezifisch weisungsgebunden

Koordiniert Projektmitarbeiter in Subteams Aufgaben

Mitarbeit beim Know-how-Transfer aus der Vorprojektphase in das Projekt Überprüfen der Projektziele gemeinsam mit dem Projektleiter Mitarbeit bei der Erstellung adäquater Projektpläne Übernahme von Verantwortlichkeiten für definierte Arbeitspakete Spezifikation von übernommenen Arbeitspaketen Planung von Durchlaufzeiten, Aufwänden und Kosten für übernommene

Arbeitspakete Mitarbeit bei der Planung von Maßnahmen zum Risikomanagement, zur

Krisenvermeidung und –vorsorge Eigenverantwortliche Erfüllung von Arbeitspaketen Operative Kontrolle der vereinbarten Qualität der übernommenen Arbeitspakete Mitarbeit bei der Feststellung des Projektstatus Vereinbarung und Vornahmen steuernder Maßnahmen in Arbeitspaketen Inhaltliche Beiträge zur Krisenbewältigung und Schadenslimitierung

Organisatorische Rechte

Selbständige Abarbeitung der übernommenen Arbeitspakete mit Unterstützung definierter Projektmitarbeiter

Entscheidung über den fachlichen Einsatz entsprechender Methoden, Verfahren, Werkzeuge etc. unter Berücksichtigung der projektspezifischen Rahmenbedingungen

Koordination von Projektmitarbeitern im Subteam Erfassung und Freigabe von Ist-Aufwänden und Ist-Kosten für zugewiesene

Arbeitspakete

Seite 24 von 87

4.3.4 Projektmitarbeiter

Organisatorische Stellung

Berichtet dem zuständigen Projektteammitglied und ist diesem gegenüber projektspezifisch weisungsgebunden

Aufgaben

Unterstützung der Arbeitspaketverantwortlichen bei der Detailplanung der Arbeitspakete

Erfüllung von Arbeitspaketen, Durchführung vereinbarter Tätigkeiten innerhalb der Arbeitspakete

Berichtet dem Arbeitspaket-Verantwortlichen über den Leistungsfortschritt und von der Planung abweichenden Terminen, Aufwänden und Kosten

Organisatorische Rechte

Operative Entscheidung in Bezug auf die Erfüllung von Arbeitspaketen Erfassen von eigenen Ist-Aufwänden für spezifische Arbeitspakete

Seite 25 von 87

4.4 Prozessdokumentation

Prozesse können in mehreren Formen dokumentiert werden. Die in der Praxis hauptsächlich gefundenen Darstellungsarten sind Flussdiagramme (Beispiel siehe Anhang Kapitel 10.5) und Swimlanes15. Bei kleinen Unternehmen mit sehr einfachen Strukturen (projektorientierte Organisation) empfiehlt sich das Flussdiagram der Einfachheit halber. Bei großen Firmen, mit meist sehr komplexen Organisationen, (Matrixorganisation) reicht ein Flussdiagram nicht mehr aus. Hier wird in den meisten Fällen eine Swimlane verwendet. Um ein funktionierendes Prozessmanagement zu leben, ist es notwendig, eine einheitliche, für alle eindeutige und verständliche Dokumentationsmethode der Prozesse sicherzustellen. Eine Methode ist eine detaillierte und systematische Handlungsvorschrift, wie nach bestimmten Prinzipien ein vorgegebenes Ziel erreicht werden kann. In den Methoden zur Prozessmodellierung sind zwei wesentliche Elemente enthalten, welche folgenderweise definiert werden:

die Modellierungssprache bzw. Notation und

eine Vorgehensweise zur Erstellung

Eine Methode wird immer im Zusammenhang mit einem Werkzeug angewendet. Die verschiedenen Methoden können entweder grafisch ausgerichtet sein, auf mathematischen Modellen basieren oder auf objektorientierten Modellen (z.B. UML) aufsetzen. Die grafische Darstellung von Prozessabläufen kann man auch als Notation bezeichnen. Der Nachteil einer umfangreichen Notation ist, dass es schwer ist, das Verständnis der Mitarbeiter (Beteiligten, Berufsgruppen) dafür zu erhalten, da viele unterschiedliche Symbole nur für den Insider / Fachmann eine Hilfe darstellen. In der Regel reichen einige wenige, dafür aber klare und gut unterscheidbare Symbole für die Prozessvisualisierung völlig aus. Leitspruch zur transparenten Visualisierung eines Prozesses: » Die Visualisierung eines Prozesses ist nicht dann abgeschlossen, wenn man keine Informationen mehr abbilden kann, sondern wenn keine Informationen mehr weggelassen werden können. « 15 Vgl. http://www.swimlane.info/meth_allg.htm

Seite 26 von 87

Wenn man eine Prozessgrafik betrachtet, sind folgende Fragen wichtig:

Wo bin ich, bzw. ist meine Rolle, Abteilung oder mein Bereich?

Was sind meine Prozesse, Tätigkeiten, Entscheidungen?

In welcher Reihenfolge laufen die Prozesse ab?

Welche Input/Output-Informationen bzw. Schnittstellen betreffen mich?

Eine übersichtliche und für jedermann verständliche Antwort kann mit der Swimlane-

Methode dargestellt werden.

4.4.1 Beschreibung / Merkmale einer Swimlane16

Für die Darstellung von Geschäftsprozessen eignen sich die Swimlane-Grafiken, die eine Kombination von Zuständigkeitsdiagrammen und klassischen Flussdiagrammen darstellen, am besten, weil sie ihren Schwerpunkt in der Beschreibung von bereichsübergreifenden Prozessabfolgen mit den auftretenden Schnittstellen haben. In den Swimlane-Grafiken können Prozesse (Aktivitäten), Vorganger-/Nachfolger-beziehungen, externe Verbinder (Konnektoren, Schnittstellen und Zuständigkeiten) darstellt werden. Durch Verbindungen, die als Pfeile dargestellt werden, erfolgt die logische Verknüpfung von Aktivitäten. Gehen mehrere Verbindungen aus einer Aktivität hervor, werden diese in der Regel durch UND- bzw. ODER-Verknüpfungen unterschieden.

Abbildung 12: Beispiel einer Swimlane-Grafiken

16 Vgl. http://www.swimlane.info/meth_allg.htm

Seite 27 von 87

Diese Aktivitäten können in Bahnen, den so genannten "Swimlanes" oder "Lanes" angeordnet werden, um organisatorische Zuständigkeiten im erzeugten Modell abzubilden. Ein wesentliches Kennzeichen der Swimlane-Methode ist die Möglichkeit, schnell, leicht erfassbar und strukturiert Prozesse abzubilden. Hierbei haben sich im Wesentlichen drei Sichtweisen herauskristallisiert. Organisationssicht In dieser Sichtweise wird mit Objekten/Symbolen modelliert, die in den einzelnen Swimlane-Grafiken unterschiedlich benannt sind. In jedem Fall geht es hierbei um die Zuständigkeits- bzw. Verantwortungszuordnung. Zum Beispiel:

Organisation

Aktivitätsträger

Pool

Lane

Funktionsträger

Band

Bereich

Für alle Begrifflichkeiten gilt die Frage: Was verbirgt sich dahinter? Hier ist die Betrachtungsweise wiederum sehr identisch und hängt von der Aufgabenstellung, dem Detaillierungsgrad und den Möglichkeiten des Modellierungswerkzeuges ab. Die zentrale Frage lautet: Was kann eine Swimlane sein? Abteilung, gesellschaftliche Organisation, mit bestimmten Funktionen beauftragte Einzelperson, Organ, Datenverarbeitungssystem, Standort, Rolle, Firma, Funktion, Maschine, Gebäude, Person usw. Aktivitätssicht In dieser Sichtweise werden die Aktivitäten üblicherweise einer Swimlane zugeordnet, um die Verantwortlichkeit und Zuständigkeit für diese Aktivität zu definieren. Hier werden unterschiedliche Thematiken behandelt. Es gibt je nach Möglichkeiten keine großen Unterschiede zu "herkömmlichen traditionellen" Flussdiagrammen.

Seite 28 von 87

Begrifflichkeiten:

Aktivität

Tätigkeit

Teilprozess

Subprozess

Informationssicht

Das Wesentliche dieser Sicht ist die Abbildung der Kommunikationsbeziehungen von Prozessbeteiligten da dadurch Schnittstellen identifiziert werden und auch die Wechselwirkungen der Prozesse dargestellt werden. Einige Begrifflichkeiten für Schnittstellen:

Informationsfluss

Datenfluss

Dokument

Informationsträger

Daten

Seite 29 von 87

4.5 Anpassen der Organisation

Organisation17 als Tätigkeit kann als Summe aller auf bestimmte Zwecke ausgerichteten Regelungen verstanden werden, die sich auf die Gestaltung der Strukturen und Prozesse in Organisationen (als Institution) beziehen. Dabei steht die Analyse und Zuordnung von Aufgaben innerhalb einzelner Stellen, deren Zusammenfassung zu einer hierarchisch mehrstufigen Struktur sowie die Gestaltung der Beziehungen zwischen verschiedenen Stellen und Ebenen im Zentrum des Interesses.

Abbildung 13: Entwicklung der Organisationsformen18

Die von mir untersuchten Unternehmen waren hierarchisch organisiert. Die Projekte wurden in Form einer Matrixorganisation abgewickelt. Optimalerweise sieht dieser Ablauf, wie in Abbildung 14 dargestellt wird, aus. Ausprägung der Matrixorganisation: „Sie verlangt nicht nur eine Revision des traditionellen hierarchischen Autoritätsgefüges, sondern stellt auch lange geübte Verhaltens- und Denkweisen von Grund auf in Frage. Eine besondere Hürde, die sich bei Übernahme des Matrix-Konzeptes stellt, ist die Abkehr vom Prinzip der Einheit der Auftragserteilung...Theorie und Praxis haben sich jahrzehntelang gesperrt; immer mit dem Argument, der entstehenden Kompetenzwirrwarr wirke hochgradig kontraproduktiv.“19

17 Vgl. Härdler, Betriebswirtschaft für Ingenieure, 2. Auflage 2003 18 Vgl. Erich O.Dräger, Grundlagen des Prozessmanagements, Vorlesung Graz November 2006 19 Vgl. Schreyögg, Grundlagen moderner Organisationsgestaltung, 4. Auflage 2003

Seite 30 von 87

Abbildung 14: Idealer Prozessablauf20

Leider sieht es in der Praxis meist wie in Abbildung 15 dargestellt wird aus. Dies verursacht viele Schnittstellen und hat zusätzlich das Problem, dass der Projektleiter kaum Einfluss auf die Projektmitarbeiter hat. Dies tritt bei streng hierarchisch agierenden Unternehmen auf wo die Linienmanager das „Sagen“ haben.

Abbildung 15: "Realer Ablauf"

Bei sehr großen Projekten wurden zum Teil eigene Projektorganisationen aus der Stammorganisation herausgelöst. Dies war bei diesen Projekten notwendig da eine Abwicklung über die Stammorganisation auf Grund der hohen Komplexität und des daraus entstehenden Risikos für das Unternehmen nicht möglich gewesen wäre. Dies ging soweit, dass ein eigenes Gebäude als Projektbüro angemietet wurde, in dem alle Projektmitglieder vereint waren.

20 Vgl. Erich O.Dräger, Grundlagen des Prozessmanagements, Vorlesung Graz November 2006

Seite 31 von 87

Ausprägung der Projektorganisation: „Die Projektorganisation ist eine einer bestehenden Organisation auf Zeit übergelagerte Organisationsstruktur, die allein schon dadurch zu einer für die Projektorganisation spezifischen Komplexitätsproblematik im Innenverhältnis der Gesamtorganisation und für deren Beziehungen zu ihren verschiedenen Umwelten führt.“21 Da wir uns in den meisten Unternehmen mit einer „Art“ Matrixorganisation zu tun haben, gibt es gewisse Regeln die einzuhalten sind, um Schnittstellenprobleme zu vermeiden.

1. Während des Projekts hat der Projektleiter sämtliche Kompetenzen hinsichtlich der ihm zur Verfügung gestellten Ressourcen.

2. Klare Festlegung (Unterschriftenregelung) inwieweit der Projektleiter über Finanzen verfügen darf.

3. Die Fachabteilungen sind für die Ausbildung der Ressourcen verantwortlich und stellen diese den Projekten zur Verfügung. Die Anforderung muss rechtzeitig vom Projektleiter erfolgen.

4. Die notwendigen Projektrollen (siehe Kapitel 4.3) sind in Jobbeschreibungen festzuhalten und entsprechende Schulungsmaßnahmen abzuleiten.

5. Lessons learned aus den Projekten müssen in die Organisation zurückgeführt werden.

Abbildung 16: Schnittstellenproblematik22

Die optimale Organisationsform ist eine Prozessorganisation. Grund dafür ist die Überwindung der Trennung von Aufbau- und Ablauf- Organisation und dass es sich bei 21 Vgl. Schwan, Organisationsgestaltung, 2003 22 Vgl. Wunderer, Integriertes Management, Bern 1985

Seite 32 von 87

den Prozessen um dynamische Anpassungen und Entwicklungen handelt. Die Berücksichtigung solcher Aspekte entspricht dem Verständnis über die „Neue Organisation, welches verstärkt ein Denken in Prozessen statt nur in Strukturen verlangt.“23 Wenn der Wandel betriebliche Normalität ist, Leistungsvollzüge wesentliche komplexer werden und häufige unter zunehmenden Zeitdruck zu leisten sind, werden prozessuale Flexibilität und Offenheit, Wege der Selbstorganisation und die Nutzung von inner- und außerbetrieblichen Netzwerken wichtiger. Nicht organisatorische Paläste sind erforderlich, sondern rasch auf- und abbaubare „leichte Zelte“24. Die finanziellen Auswirkungen für das Unternehmen kann man erst nach ca. 1 bis 2 Jahren beurteilen, wenn alle Projektleiter nach den neu eingeführten Prozessen arbeiten und die erlernten Methoden durchgängig anwendet werden. Dies kann anhanden der Deckungsbeiträge der Projekte ermittelt werden. Die Erwartungshaltung ist von der Unternehmensführung festzulegen (z.B. Steigerung der Deckungsbeiträge um 5% über alle Projekte hinweg).

23 Vgl. Schwan, Organisationsgestaltung, 2003

24 Vgl. Krummenacher, Flexibles Management statt Bürokratie, 1985

Seite 33 von 87

4.6 Notwendige Kompetenzen und deren Entwicklung

Um die Ziele des Unternehmens zu erreichen und die gestellten Aufgaben zufriedenstellend lösen zu können, ist eine gezielte Aus- und Weiterbildung aller Mitarbeiter auf allen Unternehmensebenen unerlässlich. Diese Ziele umfassen einerseits die Bedürfnisse des Unternehmens für gut ausgebildete, qualifizierte Mitarbeiter sowie andererseits für die Motivation und Selbstverwirklichung (soziale Anerkennung) der Mitarbeiter selbst.

4.6.1 Begriffe, Definitionen

Grundausbildung Anerkannte, abgeschlossene und nachgewiesene Ausbildung (Schulabschluss, Lehre, Meister, Ingenieur, Studium etc.) Zusatzausbildung Ausbildungsmaßnahme, die zur Erfüllung der Anforderungen eines Arbeitsplatzes, zusätzlich zur Grundausbildung, erforderlich ist.

4.6.2 Grundsätzlicher Ablauf

Der mittelfristige Schulungsbedarf des unterstellten Personals ist von den Führungskräften jährlich neu zu ermitteln, die Schulungsmaßnahme festzulegen und im Zuge der Budgetierung zu beantragen. Die freigegebenen und anfallenden Kosten werden im Jahresbudget, nach erfolgter Genehmigung durch die Geschäftsführung, aufgenommen. Ein allfälliger unterjährige, somit kurzfristiger Schulungsbedarf, hervorgerufen durch job rotation, Neuaufnahmen oder notwendige Korrekturmaßnahmen ist bei Bedarf jederzeit zu beantragen. Sollten die dafür anfallenden Kosten nicht im Budget genehmigten Kostenrahmen Deckung finden, ist eine solche Schulung durch die Geschäftsführung genehmigen zu lassen (abhängig von der Unterschriftenregelung des Unternehmens). Der gesamte Schulungsbedarf bzw. erfolgte Durchführungen werden in einer zentralen Übersicht („Schulungsplan“) erfasst und dokumentiert. Daraus wird von der Personalabteilung der Jahresschulungsplan abgeleitet. Konkret bedeutet dies, dass:

Führungskräfte und Mitarbeiter, nach Maßgabe Ihres Aufgabengebietes, gründlich und sorgfältig geschult werden;

neue Mitarbeiter für ihr Aufgabengebiet eingeschult und motiviert werden;

Seite 34 von 87

alle Mitarbeiter, außer dem fachlichen und beruflichem Wissen, auch in Verbindung mit ihrer Eigenverantwortung für Qualität weitergebildet werden.

4.6.3 Durchführung und Überwachung

Für die Durchführung / Organisation von internen Schulungen ist unmittelbar derjenige verantwortlich, der einen unterjährigen Bedarf feststellt (dies ist in der Regel der Geschäftsfeld- oder Bereichs- bzw. Abteilungsleiter). Bei einer unterjährigen externen Schulung wird die Verantwortlichkeit der Durchführung im Rahmen der Genehmigung durch die Geschäftsführung festgelegt, ansonst gilt die Zuordnung lt. dem gültigen Budget. Qualifikationsnachweise von Mitarbeitern werden im Personalakt abgelegt, und die getätigte Schulung im Personalstammsatz bzw. Schulungsplan vermerkt.

4.6.4 Neu eingestellte Mitarbeiter

Jeder neue Mitarbeiter wird anhand eines Einführungsprogramms in seine Aufgaben in das Unternehmen eingeführt. Die Erstellung des spezifischen Einführungsprogramms ist Aufgabe des unmittelbaren Vorgesetzten. Die Erstellung eines allfälligen allgemeinen Einführungsprogramms obliegt dem Leiter des Personalwesens und hat jedenfalls die qualitätsrelevanten Belange zu beinhalten. Wichtig sind hier neben den Sicherheits- und Brandschutzverordnungen auch Prozessschulungen des jeweiligen Tätigkeitsumfelds. Bei größeren Firmen ist es durchaus die Regel, dass sämtliche neue Mitarbeiter durch ein „Welcome Newcomer“ Programm geschleust werden. Die Dauer dieser Einführungsphase richtet sich nach der zu übernehmenden Tätigkeit bzw. entsprechend der Vorbildung oder der Berufserfahrung des neuen Mitarbeiters.

4.6.5 Kompetenzentwicklung

Es ist wichtig, dass alle Mitarbeiter entsprechend den Erfordernissen eingeschult werden um ihre Aufgaben im Projekt – sei es als Projektleiter oder als Projektmitarbeiter – effektiv und effizient durchführen zu können. Wie bereits im Kapitel 3.3 festgestellt wurde, ist das Projektmanagementwissen in Unternehmen weit gestreut. Vor der Durchführung von Projektmanagement-Toolschulungen sollte man sicherstellen, dass das notwendige Methodenwissen vor einer Schulung einer Projektmanagement-Software bereits vorhanden ist. Darüber hinaus ist auch festzulegen, ob rollenspezifische Schulungen durchgeführt werden sollen oder nicht. Beim im Kapitel 10.3 beschriebenen Unternehmen wurden die Toolschulungen im großen Rahmen begonnen (Schulungen mit 20 und mehr Personen mit unterschiedlichstem Projektmanagement-Know-how). Bereits nach der ersten

Seite 35 von 87

Schulung wurden alle weiteren Schulungen abgesagt da die geschulten Personen mit den Inhalten überfordert waren. Aus meiner Erfahrung hat es sich bewährt, Schulungen in mehreren Levels durchzuführen.

Level 1: kein Projektmanagement-Know-how vorhanden Projektassistenten, Einkäufer, Controller, uvm.

Level 2: Projektmanagement-Know-how vorhanden Junior-Projektleiter, Projektteammitglieder, Projektmitarbeiter, usw.

Level 3: überdurchschnittliches Projektmanagement-Know-how vorhanden Projektmanager (zertifiziert nach IPMA), Programmmanager, Projekt-auftraggeber,…

Nach Differenzierung der Gruppen in die verschiedenen Levels wurden diese in Gruppen von 8 bis max. 12 Personen aufgeteilt. Die Einteilung in die Gruppen erfolgte über ein Eingangsinterview mit den für die Schulung vorgesehenen Personen. Hierfür wurden dieselben Fragebögen, wie in Kapitel 3.3.1 beschrieben wurde, verwendet. Als Ziele für die Schulungen wurde definiert:

Die Projektmanagement Grundlagen / Methoden können angewendet werden. Die Teilnehmer der Schulung sind in der Lage Projekte mit dem Projekt-

management -Tool aufzusetzen und abzuwickeln. Abschluss der Ausbildung mit einer Prüfung, die jener der IPMA Richtlinien

entspricht um den Erfolg der Ausbildung sicherzustellen. Ein Kernpunkt für den Erfolg der Schulungen war der Ablauf:

Theoretische Grundlagenvermittlung (Methodenschulung) Beispiele aus der Praxis Durchführung von Übungsbeispielen mit dem Projektmanagement-Tool Diskussion über Inhalte

Bei den meisten Toolschulungen wird nur die Funktion des Tools geschult und führt somit nicht zum gewünschten Lehrziel.

Seite 36 von 87

5 Controlling und Kennzahlen

5.1 Entwicklung von Kennzahlen

5.1.1 Definition Kennzahl25

Kennzahl ist grundsätzlich eine Kombination von Zahlen, zwischen denen Beziehungen bestehen oder in einer Weise hergestellt werden können, dass eine neue Größe gebildet wird, die im Vergleich zu den Ausgangsgrößen einen zusätzlichen Erkenntniswert besitzt. Kennzahlen sind Verhältniszahlen mit betriebswirtschaftlich relevanter Aussage über betriebliche Fakten, Vorgänge, Entwicklungstendenzen, Ziele, Ergebnisse. Weit verbreitete Synonyme sind die Begriffe Kennziffern, Performance Measures, Key Performance Indicators und Benchmarks.

5.1.2 Aufbau eines Monitoring-Systems

Strategieeinbindung Zur Ausrichtung der Geschäftsstrategie einer Unternehmung ist eine fundierte und abgesicherte Informationsbasis nötig. Diese dient zur Bewertung gegenwärtiger und zukünftiger Geschäftsfelder, der strategischen Ausrichtung der Unternehmung und der Umsetzung der Strategie. Kennzahlen aus der Strategie und die Ableitung von Zielvorgaben für Abteilungen, Teams und Mitarbeiter erlauben die Integration der Strategie in das Tagesgeschäft. Dies geschieht über die Identifikation von Interdependenzen und Abhängigkeiten der Strategie mit den Geschäftsprozessen durch eine Ursache-Wirkungsbetrachtung26. Ein Monitoring-System kann so eine schnelle und nachprüfbare Umsetzung von Zielvorgaben in den operativen Bereichen ermöglichen. Kennzahlen kombinieren Erforderlich ist die Kombination finanzwirtschaftlicher, nicht-finanzieller und zukunfts-orientierter Kennzahlen. Rein finanzwirtschaftliche Kennzahlen oder wertmäßige Steuerungsgrößen geben keinen ausreichenden Überblick über die Erfolgstreiber einer Unternehmung. Diese stehen oftmals zu spät zur Verfügung und sind aufgrund der hohen Aggregation erklärungsbedürftig. Durch die Berücksichtigung von kurz- und langfristigen Zieldimensionen, monetären und nichtmonetären sowie externen und internen Indikatoren ergibt sich ein ausgewogenes Bild über Unternehmensstrategie und Zielerreichung.27

25 Vgl. Aichele, Intelligentes Projektmanagement, 2006 26 Vgl. Horváth, P.: Controlling. 8. Auflage. München: Valen Verlag, 2001.

27 Vgl. Bernhard, M.G. / Hofschröer, S. (Hrsg.): Report Balanced Scorecard: Strategien umsetzen, Prozesse steuern, Kennzahlensysteme entwickeln, 2. Aufl. Düsseldorf: Symposium Publikation, 2001.

Seite 37 von 87

Zusammenhänge erarbeiten Ein Monitoring-System muss Ursache-Wirkungszusammenhänge zwischen den finanzwirtschaftlichen, nicht-finanziellen und zukunftsorientierten Kennzahlen über alle Unternehmenshierarchiestufen hinweg abbilden. Diese lassen sich durch Beziehungsketten darstellen, bei denen die vorauslaufenden Indikatoren nachlaufende Indikatoren mit einer gewissen Zeitverzögerung beeinflussen28. Dadurch können die Ursachen von sich verschlechternden Hauptkennzahlen durch die schlüssige Nachverfolgung der Kennzahlen bis auf die Ebene der Geschäftsprozesse identifiziert werden. Die Beziehungen der Kennzahlen untereinander sind transparent und plausibel zu gestalten, damit sich die Aussagen der Indikatoren auf unterschiedlichen Hierarchiestufen nicht widersprechen. Informationsbedürfnisse berücksichtigen Unterschiedliche Führungsebenen erfordern spezifisch angepasste Kennzahlen, die in einer Managementsicht auf einige wenige Kennzahlen aggregiert werden. Auf der Ebene der Geschäftseinheiten stehen neben finanzwirtschaftlichen Kennzahlen Indikatoren der Markt-Sicht im Vordergrund. Innerhalb der Geschäftseinheiten liegt der Schwerpunkt auf Themen wie Kundenzufriedenheit, Flexibilität/Innovation und Produktivität. Auf der Mitarbeiterebene sind Kennzahlen zur Messung von Zeit, Qualität und Kosten der Geschäftsprozesse zu implementieren. Die abstrakte und globale Unternehmensstrategie wird so auf den Bereich des Mitarbeiters „heruntergebrochen", den dieser beeinflussen kann. Eine hierarchieübergreifende Konzeption, eine funktions- und bereichsübergreifende Gestaltung sowie die Aspekte Transparenz und Einfachheit der Kennzahlen sind wichtige Bestandteile des Monitoring-Systems.

Abbildung 17: Monitoring-System29

28 Vgl. Küng, P.; Wettstein, T.: Ganzheitliches Performance-Measurement mittels Informationstechnologie. Bern/ Stuttgart: Paul Haupt Verlag, 2003. 29 Vgl. Schierenbeck, H.; Lister, M: Value Controlling: Grundlagen Wertorientierter Unternehmensführung. 2. Aufl. München: Oldenburg Verlag, 2001.

Seite 38 von 87

5.1.3 Kennzahlen im Projektmanagement-Prozess

Um Prozesse messbar zu machen benötigt man Prozesskennzahlen. Diese sind von den Stakeholdern der Prozesse zu definieren. Für den Projektmanagementprozess könnten diese wie folgt aussehen:

Übergabe Vertrieb an Projektleiter (qualitativ 0-3) Abnahmekriterien im Vertrag definiert (qualitativ 0-3) Plan- / Ist- Budget (Abweichung absolut und in %) Plan- / Ist- Termin (Abweichung absolut und in %) Projektfinanzierung Ziel-Deckungsbeitrag (Abweichung absolut und in %) Übergabe Projektleiter an Service (qualitativ 0-3) Kundenzufriedenheit

Über die Kennzahlen des Einzelprojektmanagements hinaus sind Kennzahlen für das Multiprojektmanagement notwendig um die Projektportfolios steuern zu können. Nachfolgend sind hier die beiden wichtigsten angeführt.

Abbildung 18: Auftragsstand / Ressourcenauslastung

Auftragsstand Der Auftragsstand wird monatlich im Zuge der Projektauftraggebersitzungen erörtert bzw. aktualisiert. Die Daten werden in einer Liste (Multiprojektmanagementtool) geführt. Beim Auftragsstand dürfen sogenannte „Hot-Projekte“ (sind noch kein Auftrag, Auftragswahrscheinlichkeit > 80%) nicht außer Acht gelassen werden. Auslastung Die Auslastung des Eigenpersonals sollte mit Hilfe der Ressourcenplanung 14-tätig im Zuge der Projektbesprechungen erörtert bzw. aktualisiert werden. Eine Ressourcen-

Seite 39 von 87

planung erfolgt in einem Tool oder auf EXCEL- Vorlagen (siehe Abbildung 18). Verantwortlich ist der Zuständige für die zu planende Ressourcengruppe. Über diese Kennzahlen hinaus kann man auch Quality Gates (siehe Kapitel 5.3) in das Kennzahlensystem integrieren.

5.2 Projektcontrolling30

Der Projektcontrollingprozess ist ein zyklischer Prozess. Die Häufigkeit richtet sich nach den Bedürfnissen des Projekts. Es empfiehlt sich dies zumindest 1-mal pro Monat durchzuführen um rechtzeitig auf Abweichungen reagieren zu können. Die Häufigkeit sollte anhanden definierter Kriterien (siehe Kapitel 3.1) im Projektstartprozess festgelegt werden. In der Regel ist der Controllingzyklus vom Unternehmen vorgegeben.

Abbildung 19: Projektcontrolling als zyklischer Prozess

Das Projektcontrolling durchläuft folgende Schritte:

Erfassen des Iststandes Vergleich des Iststandes mit den Planwerten und Identifikation von

Abweichungen Planung von steuernden Maßnahmen Aktualisierung der Projektmanagement-Pläne und des Projektmanagement-

handbuchs

30 Vgl. Sterrer, Winkler, Let your projects fly, 2006 S. 164ff

Seite 40 von 87

Abbildung 20: Kommunikationsstrukturen im Controllingprozess

Wesentlich im Projektcontrolling ist, das Controlling nicht als alleinige Aufgabe des Projektleiters, sondern auch als Aufgabe des Projektteams sowie des Projektauftraggebers anzusehen. Daraus resultiert, dass Projektcontrolling nur im Rahmen eines gemeinsamen Workshops bzw. einer Besprechung durchgeführt werden kann. Dadurch kann sichergestellt werden, dass ein gemeinsames Projektcontrolling wieder zu einer gemeinsamen Sicht über den Status im Projekt sowie den Bedarf von notwendigen steuernden Handlungen führt.

Abbildung 21: Darstellung des Projektcontrollingprozess

Seite 41 von 87

5.3 Prozesscontrolling mittels Quality Gates

Quality Gates stellen eine Vorgehensweise für das Prozess- und Projektmanagement dar, mit deren Hilfe Zeit- und Kosteneinsparungen erzielt werden können. Die Quality Gates repräsentieren Messpunkte in der Prozesskette, an denen die Ergebnisse gemessen, ihre Reife bewertet und der Prozessfortschritt synchronisiert wird. Beim Einsatz von Quality Gates ist es von größter Wichtigkeit, diese an den kritischen Informationsschnittstellen der Prozesskette zu integrieren. Erst die Platzierung der Quality Gates an neuralgischen Informations- und Synchronisationspunkten sorgt für einen optimal abgesicherten Prozessverlauf.

Abbildung 22: Quality Gates im Prozess

Zielsetzung: Frühzeitiges Erkennen von Risiken & Abweichungen im Projekt (auch Entwicklungsprojekt). Methodik31: • Ein Q-Gate ist ein Meilenstein, der ggf. zum Haltepunkt wird • Synchronisation von parallel laufenden Einzelprozessen. Die Interessen der

Einzelprozesse werden durch die Pflichtteilnehmer vertreten • Objektive Messung des Reifegrades bzw. der Zielerreichung

an definierten Nahtstellen mit einer Kriterienliste über die gesamte Wertschöpfung Ableiten von Maßnahmen und deren Verfolgung Dokumentation der Zielerreichung und Visualisierung über Ampelfarben

• Objektivität durch Interessenskonflikt der Pflichtteilnehmer 31 Vgl. Schmidt, Vortrag: Organisation Qualitätsmanagement

Seite 42 von 87

Der Produktentstehungsprozess wird durch Quality Gates in aufeinanderfolgende Prozessphasen unterteilt. In jeder Phase sind von den einzelnen Teilprojekten definierte Aufgaben zu erfüllen, die sich in den Arbeitspaketen widerspiegeln und für das folgende Quality Gate Exit-Kriterien darstellen. Die Erfüllung der Exit-Kriterien wird in Previews und Reviews zur Quality Gate-bezogenen Projektsteuerung überprüft und im Rahmen des Quality Gate-Reportings den Entscheidungsgremien berichtet.

Abbildung 23: Quality Gate32

Unterschied zwischen Meilensteinen und Quality Gates33:

Meilensteine sind festgelegte Zeitpunkte, zu denen Ergebnisse fertig gestellt sein müssen. Meilensteine können „überfahren“ werden.

Quality Gates sind inhaltlich festgelegte und synchronisierte Messpunkte, an

denen alle Leistungen (Messgrößen) einer Prozessphase erfüllt sein müssen. Quality Gates können nicht „überfahren“ werden.

32 Vgl. Vortrag: Produktlebenszyklus-Management, Sigemund, 2007 33 Vgl. Vortrag: Entwicklungsqualität mit System, Dr.-Ing. Prefi, Nov. 2004

Seite 43 von 87

6 Multiprojektmanagement

6.1 Begriffsdefinition

Nach DIN 69901 ist unter dem Begriff Multiprojektmanagement die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die gleichzeitige Abwicklung mehrer Projekte zu verstehen. Diese instrumentelle Definition basiert eher auf einem erweiterten Projektmanagement-konzept, berücksichtigt jedoch die ablauforganisatorische Sicht zu wenig explizit. Die folgenden Definitionen erweitern und vereinen diese Komponenten:34 „Das Multi-Projekt-Management ist eine gegenwarts- und zukunftsorientierte Managementfunktion in der projektorientierten Organisation. Das Multi-Projekt-Management ist die Planung, Steuerung und Kontrolle von Leistungen, Terminen, Kosten, Ressourcen, Risken, organisatorischer Aspekte (z.B. Kommunikation) sowie der Kontext aller Projekte und Programme, wobei insbesondere deren Zusammenhänge und Abhängigkeiten betrachtet werden.“35 Multiprojektmanagement bedeutet die gleichzeitige Koordination und Steuerung mehrerer Projekte. Insbesondere werden dabei Ziele von Projekten aufeinander abgestimmt, Synergien analysiert und genutzt und notwendige Ressourcen projektübergreifend eingeplant. Außerdem sollen Erfahrungen und Projekt-Know-how zusammengeführt und genutzt werden.

Abbildung 24: Multiprojektmanagement -Betrachtungswinkel bzw. -Abgrenzung36

34 Vgl. Gerold Patzak / Günter Rattay, Projektmanagement, 3. Auflage, 1998, Roland Gareis: Happy Projects!, 2. Auflage, Manz Verlag, Wien 2004.

35 Vgl. Haring, Analyse von Multi-Projektmanagement-Software, Wien 2001 36 Vgl. Süß / Ehrl-Gruber, Projektmanagement, Ergebnisorientierte und termingerechte Projektabwicklung in der Industrie, 1998

Seite 44 von 87

Multiprojektmanagement bewegt sich dabei im Spannungsfeld zwischen operativen und strategischen Entscheidungen. Zum einen erfolgt auf der strategischen Ebene die Bildung einer Unternehmensstrategie. Projektportfolios müssen zusammengestellt und die „richtigen“ Schwerpunkte gesetzt werden. Zum anderen sind auf der operativen Ebene die Unternehmenszielsetzungen in konkrete Projekte umzusetzen. Auf dieser operativen Ebene entstehen alle Basisdaten der einzelnen Projekte und dienen so als Grundlage für das Multiprojektmanagement. Abbildung 24 visualisiert diese Abgrenzung. Die Unterschiede bezüglich den Gestaltungsobjekten, den Zielen, den Funktionen und den Zielgruppen stellt die nachfolgende Abbildung 25 dar. Sie beinhaltet verschiedene Betrachtungselemente im Projektmanagement und im Multiprojektmanagement. Hier ist darauf hinzuweisen, dass dies nicht als Gegenüberstellung gesehen werden soll, sondern vielmehr als Ergänzung des Projektmanagementkonzepts, welches durch die Anforderungen im Multiprojektmanagement -Konzept erweitert werden kann.

Abbildung 25: Projekt- versus Multiprojektmanagement

Seite 45 von 87

6.2 Kernpunkte im Multiprojektmanagement

Um die Aufgaben zu bewältigen, benötigen Unternehmen ein professionelles Multiprojektmanagement. Dabei kommt es auf die folgenden Kernpunkte an:37 • Planung der Projektlandschaft:

Mit Hilfe des Multiprojektmanagements soll erreicht werden, dass die richtigen Projekte mit der notwendigen Priorität in das Projektportfolio ausgewählt werden.38 Ein Projektportfolio ist eine zeitpunktbezogene Darstellung aller vorhandenen und eventuell auch geplanten Projekte einer Organisation.

• Steuerung von Projektlandschaften den permanenten Status der Projekt-

landschaft ermitteln und kommunizieren:

Der Multiprojektmanager muss die Situation der einzelnen Projekte hinsichtlich der Inhalte, der Zeit, der Kapazitäten und der Budgetentwicklung ermitteln und die daraus resultierenden Auswirkungen auf die Projektlandschaft analysieren und transparent machen.

• Die Infrastruktur für professionelles Projektmanagement entwickeln:

Der Multiprojektmanager hat die Aufgabe, Projektmanagement als Führungs-, Organisations- und Arbeitsform zu etablieren, er ist verantwortlich für den Projektmanagementprozess.

• Das Multiprojektmanagement hat einen Pool von erfahrenen Projektleitern

und Projektberatern:

In manchen Unternehmen findet man im Multiprojektmanagement einen Pool an erfahrenen Projektleitern und Projektberatern, die für einen gewissen Zeitraum den Projekten zur Verfügung gestellt werden können.

• Die Strategierelevanz und –ausrichtung der einzelnen Projekte im Sinne des

gesamten Unternehmens gewährleisten :

Der Multiprojektmanager ist dafür verantwortlich, dass sich die einzelnen Projekte an den Unternehmenszielen und –strategien orientieren und diese verstärken.

37 Vgl. Lomnitz, Multiprojektmanagement, Projekte erfolgreich planen, vernetzen und steuern, ebook, 2004

38 Vgl. Gareis, Happy Projects, 2. Auflage 2004

Seite 46 von 87

6.3 Multiprojektmanager

Die Bezeichnungen für Multiprojektmanager sind vielfältig. In der Literatur oft vertreten sind: Programm-Manager39, Großprojektmanager40, Projektkoordinator41 oder Projektauftraggeber42. Der Verantwortungsbereich des Multiprojektmanagers wird in den unterschiedlichen Unternehmen nicht immer gleich definiert. Jedoch können die wesentlichen Hauptaufgaben abgegrenzt werden, die ein Multiprojektmanager erfüllen muss:43

• Dem Multiprojektmanager obliegt die gesamte Verantwortung der

Projektlandschaft des Unternehmens.

Dieser Verantwortungsbereich umfasst den gesamten Planungs- und Priorisierungsprozess, sowie auch die gesamte Koordination der zugewiesenen, oder auch aller Projekte. Durch diese Aufgabenzuordnung wird gewährleistet, dass Synergieeffekte und eine realistische Ressourcenplanung realisiert und umgesetzt werden.

• Kenntnisse und spezielle Fähigkeiten

Multiprojektmanager haben die Aufgabe, die Handlungs- und Verhaltensmuster der Umwelt zu erkennen. Daneben setzen sie Planungs-, Kalkulations-, Organisations- und Controllingmethoden ein. Allgemein müssen sie ein generelles Verständnis zu unterschiedlichen Themen haben, da Multiprojektmanager einerseits „ihre“ Techniker verstehen müssen, andererseits Aufgaben und Ziele strukturieren, kalkulieren, planen, finanzieren und betriebswirtschaftliche Ergebnisse analysieren müssen.

• Multiprojektmanager sind nur für strategisch relevante Projekte zuständig.

Multiprojektmanager verzichten auf die Koordination von mittleren und kleineren Projekten, um sich gezielt auf strategisch wichtige Projekte zu konzentrieren. Jedoch ist dabei nicht außer Acht zu lassen, dass viele kleine Projekte Auswirkungen auf große Projekte haben können, da auch kleine Projekte personelle Ressourcen binden. Aus diesem Grund müssen Projekte individuell geclustert werden, wie im folgenden Punkt beschrieben.

• Multiprojektmanager planen und steuern Projekte einer Projektart.

Unternehmen mit einer sehr komplexen Projektlandschaft sind für Multiprojektmanager kaum noch überschaubar. Aus diesem Grund ist es von

39 Vgl. Lomnitz, Multiprojektmanagement, Projekte erfolgreich planen, vernetzen und steuern, ebook, 2004 40 Vgl. Zöllner, Praxisbuch Projektmanagement, 2003 41 Vgl. Keßler / Winkelhofer, Projektmanagement, Leitfaden zur Steuer und Führung von Projekten, 2. Auflage 1999

42 Vgl. Reschke, Handbuch Projektmanagement, 1989 43 Vgl. Kessler / Winkelhofer, Projektmanagement, Leitfaden zur Steuer und Führung von Projekten, 2. Auflage 1999

Seite 47 von 87

Vorteil, Projekte nach ihrer Art zu gliedern und einem Multiprojektmanager als Verantwortungsbereich zuzuordnen. Beispielsweise können Projektarten wie folgt unterteilt werden: 44

Externe Projekte (externer Kunde, externer Auftraggeber, Besteller) Interne Projekte (interner Kunde, interner Auftraggeber, Nutzer) Forschungsprojekte Investitionsprojekte (Bau, Anlagenbau etc.)

Ein Multiprojektmanager ist vom Aufgabenbereich eines Projektmanagers zu trennen. Ein Multiprojektmanager wird beispielsweise dem Projektleiter nicht die Arbeit abnehmen, sein Team zusammenzustellen und Fachkräfte zu gewinnen. Sie haben keine Ressourcenverantwortung und keine Kompetenz, Mitarbeiter zuzuteilen. Somit ist der Multiprojektmanager kein Entscheider, der die Priorität der internen Projekte bestimmt. Zusammenfassend hat der Multiprojektmanager die Aufgabe, die Übersicht über das Projektportfolio zu wahren, die Vernetzung der einzelnen Projekte unter anderem in punkto Ressourcen zu prüfen, sowie zeitliche Abhängigkeiten und Inhalte zu kontrollieren. Er ist auch zuständig für PM-Guidelines, für klare Prozessbeschreibungen und für optimale Tools.

6.4 Multiprojektcontrolling

Multiprojektcontrolling (MPC) stellt eine ergebnisorientierte Planung, Steuerung und Kontrolle einer Vielzahl von Projekten im Hinblick auf die Inanspruchnahme von Projektbereichs- und Funktionsbereichsressourcen sowie sonstiger bestehender Interdependenzen dar.45 Nach dieser Abgrenzung umfasst ein Multiprojektcontrolling diejenigen Aufgaben, die sich auf die Gesamtheit der Projekte beziehen: „Organisatorisch treten damit terminbezogene Koordinations- und Kapazitäts-abstimmungsprobleme in den Vordergrund, wirtschaftlich verlagert sich der Blick auf die periodenbezogene Darstellung von Kosten, Leistungen und Ergebnissen sowie Finanzwirkung der Einzelprojekte.“46 Das Multiprojektcontrolling in einer MULTIPROJEKTMANAGER -Umgebung wird immer öfter als erweitertes Projektcontrollingkonzept eingeführt und hat damit einen immer wichtigeren Stellenwert in der Projektlandschaft. Krüger erweitert dieses Konzept durch die Konkurrenz der benötigten Finanz-, Sach- und Humanressourcen,

44 Vgl. Patzak / Rattay, Projektmanagement, 3. Auflage, 1998 45 Vgl. Steinle, Bruch, Controlling: Kompendium für Controllerinnen und ihre Ausbildung, 2. Auflage 1999 46 Vgl. Lachnit Controllingkonzeption für Unternehmen mit Projektleistungstätigkeit, 1994

Seite 48 von 87

die einerseits für Linienaufgaben benötigt werden, und andererseits Ressourcen in Projekten darstellen.47 Krüger zeigt damit sehr treffend, dass die Koordination zwischen den interdependenten Projekten und Linienaufgaben einer Unternehmung den Aufgabenschwerpunkt bildet. Dessen ungeachtet müssen allerdings zu den Multiprojektcontrolling-Definitionen wesentliche Herausforderungen ergänzt werden:48

Zurechnung der Projektleistungen auf die Abrechnungsperiode des

Unternehmens. Koordination der Ressourcen: Die verfügbaren Ressourcen, die spezifischen

Fähigkeiten und der Auslastungsgrad müssen bekannt sein, damit im Rahmen des Multiprojektcontrollings ein projektübergreifender Ausgleich erfolgen kann.

Verdichtung der Ergebnis-, Finanz- und Risikoinformationen der Einzelprojekte zur Projektgesamtheit.

Für diese Herausforderungen sind aber eine gemeinsame Planungsmethodik und eine ausgereifte einheitliche DV-Unterstützung notwendig.

6.4.1 Abgrenzung Einzelprojektcontrolling- Multiprojektcontrolling

Das Einzelprojektcontrolling ist auf ein einzelnes Projekt fokussiert und hilft, die Projektentwicklung technisch, organisatorisch und wirtschaftlich zu erfassen, zu beurteilen und zu lenken. Das Multiprojektcontrolling hat hingegen als Betrachtungsgegenstand mehrere Projekte mit unterschiedlichen Start- und Endterminen. Aus dem organisatorischen Blickwinkel treten damit terminbezogene Koordinations- und Kapazitätsabstimmungsprobleme in den Vordergrund, wirtschaftlich jedoch verlagert sich der Blick auf die periodenbezogene Darstellung von Kosten, Leistungen und Ergebnisse sowie Finanzwirkung der Einzelprojekte. Die folgende Abbildung soll diesen Unterschied anhand der Bausteine verdeutlichen.

47 Vgl. Küpper, Wagenhofer, Handwörterbuch Unternehmensrechnung und Controlling, 4. Auflage 2002 48 Vgl. Fiedler, Controlling von Projekten, 2003

Seite 49 von 87

Abbildung 26: Bausteine des Multiprojektcontrollings49

Ziel ist es, bei etwaigen Abweichungen eine revidierende Ressourcenplanung durchzuführen, um die gesetzten Ziele doch noch zu erreichen. Folgende Maßnahmen sind zu treffen:

Prioritätenentscheidungen Lösung von auftretenden Ressourcenkonflikten Projektabbruchsentscheidungen Entscheidungen über Projektneustarts Entscheidungen über projektübergreifende Aktivitäten, von denen mehrere

Projekte profitieren.

49 Vgl. Fiedler, Controlling von Projekten, 2003

Seite 50 von 87

7 Rechnergestütztes Projektmanagement Projektmanagement ist kein Selbstzweck, es dient dazu ein gewünschtes Ergebnis innerhalb einer vorgegebenen Zeit mit begrenzten Mitteln zu erreichen. Eine Projektmanagement-Software wird eingesetzt, um die Projektbeteiligten dabei zu unterstützen.

7.1 Ziele für die Einführung einer Projektmanagement-Software

Bevor man eine Projektmanagement-Software anschafft sollte man sich überlegen welche Ziele damit verfolgt werden sollen. Mögliche Ziele:

Steigerung der Effizienz und Produktivität

Hohe Zeit- und Kostenersparnis durch Beseitigung der Medienbrüche beim Erstellen der Projektmanagement-Dokumentation.

Beispiele für Medienbrüche:

• In Word der Projektauftrag • In Visio die Projektumfeldanalyse, Projektstrukturplanung und

Projektorganisation • In Excel der Kostenplan, Personaleinsatzplan, etc. • In MS-Projekt der Balkenplan und Personalressourcenplan • In Word oder Excel die Risikoanalyse • In Word die Projektmanagementdokumentation

(Projektmanagementhandbuch) • In Excel die Kosten, Leistungscontrollingberichte • In Excel eine oder mehrere ToDo-Listen • Am Filesystem oder DMS die Projekt-Dokumentenverwaltung • In Excel die Auswertung für Multiprojektcontrolling mit langwierigen,

fehleranfälligen Datenerfassungsprozessen. • In Word das Projektmanagementhandbuch, Einladungen, Protokolle,

etc.

Beseitigung von Doppelt- und Mehrfacherfassungen von Projektdaten und den damit verbundenen Fehlerkosten.

Erstellung einer einheitlichen, zielgruppenorientierten (z.B. Intern / Kunde) Projektmanagementdokumentation „auf Knopfdruck“

Multiprojektcontrollingauswertungen „auf Knopfdruck“

Seite 51 von 87

Wichtig ist, dass nur Daten erhoben werden die tatsächlich verwendet werden. Datenerfassung ohne direkten Nutzen reduzieren die Motivation des Anwenders. Überprüfen Sie deshalb die Liste der erfassten Daten kritisch anhanden der beiden Fragen:50

1. Werden diese Daten ausgewertet? 2. Wer benötigt die Ergebnisse dieser Auswertungen für seine Arbeit?

7.2 Anforderungen erfassen / Pflichtenhefterstellung

Bei der Erstellung von Pflichtenheften im Bereich der Software hat sich das Use Case Model51 in der Praxis bewährt. Hierbei wird jede Anwendung Schritt für Schritt beschrieben. Dies ist dann eine hervorragende Basis für die Evaluierung der Projektmanagementsoftware.

7.2.1 Beispiel eines Use Cases: Projektmanagement und Controlling

Kurzbeschreibung Über das Projektmanagement-Tool soll die Möglichkeit bestehen eine Projekt-fortschrittskontrolle anhanden der eingelangten Artefakte durchzuführen. Eingelangte Ergebnisse müssen überprüfbar sein und durch ein Statusflag den aktuellen Status anzeigen können. Dieses Statusflag wird für das Projektcontrolling herangezogen. Vorbedingungen Artefakte werden erstellt und in das Projektmanagement-Tool eingecheckt. Ablauf

1. Projektmitarbeiter checkt das fertig gestellte Artefakt in das Projektmanagement-Tool ein.

2. Der Projektmitarbeiter muss nun das Flag des Artefakts von „in work“ auf „to be checked“ umstellen. Mit diesem Statuswechsel wird der verantwortliche Projektleiter informiert, dass das Artefakt seitens des Projektmitarbeiters fertig gestellt wurde und das Artefakt zur Freigabe bereitgestellt wurde.

3. Überprüfung des Artefakts durch den verantwortlichen Projektleiter gemeinsam mit dem Projektmitarbeiter.

4. Ist das Artefakt abgenommen wird das Statusflag von „to be checked“ auf „released“ umgestellt.

5. Der Projektleiter aktiviert eine Projektauswertung. 6. Das Projektmanagement-Tool erstellt einen Bericht, der den Status sämtlicher

Artefakte für das ausgewählte Projekt enthält.

50 Vgl. Artikel: Akzeptanz von PM-Software, Frischmuth, PM Magazin 10/2008 51 Vgl: Rational Unified Process, 9. Version, 2006

Seite 52 von 87

Alternative Abläufe Alternativer Ablauf: Keine Freigabe erteilt 4 a. Erfolgt keine Freigabe wird der Status von „to be checked“ auf „in work“ zurückgesetzt. 4 b. Der Projektmitarbeiter lässt die Änderungen einfliesen und der Prozess wird mit Punkt 2 des Ablaufs fortgesetzt.

Endbedingungen Aktueller Projektfortschrittsbericht liegt vor. Spezielle Anforderungen Über das Projektmanagement-Tool soll die Möglichkeit bestehen eine Projekt-fortschrittskontrolle anhanden der eingelangten Artefakte durchzuführen. Zusätzlich soll auch ein prozentueller Fortschritt in Verbindung mit dem Status „in work“ eingegeben werden können (z.B. 25%, 50% und 75%). Eingelangte Ergebnisse müssen überprüfbar sein und durch ein Freigabeflag gekennzeichnet werden können. Diese Freigabe wird durch den Projektleiter durchgeführt und ist die Basis für die Rechnungslegung (intern und extern). Mögliche Stati für Artefakte:

Not started in work to be checked released

7.2.2 Hoher Benutzerkomfort

Über die Funktionalität hinaus ist ein hoher Benutzerkomfort der Schlüssel für die Benutzung der Projektmanagementsoftware.

Intuitiv bedienbar Geringer Schulungsaufwand Vorhandene Dokumente und Vorlagen können einfach auf das eigene

Corporate Design angepasst werden Hohe Userakzeptanz durch bekannte Microsoft Technologie Mehrsprachfähig Es können Daten und Dokumente der Projekte aus der zentralen

Projektdatenbank auf den Client (PC / Laptop) repliziert und synchronisiert werden. Diese Funktionalität ermöglicht es auch die Kommunikation zwischen Niederlassungen effizient zu gestalten

Für die Praxis entwickelt und in der Praxis erprobt (in Anlehnung der IPMA Richtlinien)

Seite 53 von 87

7.3 Evaluierung einer geeigneten Projektmanagement-Software

Als Basis für die Evaluierung der PM Software ist das Pflichtenheft heranzuziehen. Zur Erstauswahl empfiehlt es sich in Fachzeitschriften, Internetforen, Projektmanagement-vereinigungen (z.B. PMA, IPMA, GPM,…) über am Markt erhältliche Tools zu informieren. Hierfür empfiehlt es sich eine Checkliste der wichtigsten Funktionen zu erstellen um die Tools miteinander zu vergleichen.

Erfüllt Anforderung Beschreibung

Zentrale Ablage • Gefordert ist eine zentrale Datenablage auf die jeder Projektmitarbeiter Zugriffsrechte (Rollen basierende) besitzt.

Versionsmanagement • Versionsverwaltung aller im Projektmanagement-Tool hinterlegten Daten mit Änderungsmanagement.

• Versionsverwaltung (lt. Vorschriften Norm ISO 9000)

• Automatisches Zufügen der Versions-nummer in den Artefaktname (optional).

Datensicherung • Sicherung der Daten auf externen Datenträgern(Band, ...)

• Archivierung der Daten

• Nach Abschluss des Projektes: - Schreibschutz - nach Ablauf der Gewährleistung wegsichern

• Rücksicherung von Daten muss artefakteinzeln möglich sein

• Die Datenstände der Projekte müssen täglich gesichert werden.

• Bei Absturz des Programms dürfen die Artefakte weder zerstört werden noch verschwinden.

Projektmanagement und Controlling

• Über das Projektmanagement-Tool soll die Möglichkeit bestehen eine Projektfortschritts-kontrolle anhanden der eingelangten Artefakte durchzuführen.

• ToDo Liste mit Terminüberwachung Projektmonitoring (Abhaken von erledigten

Seite 54 von 87

Ergebnissen durch Projektleiter oder andere berechtigte Mitarbeiter)

• Alarmfunktionen (E-Mail, für das Projektmonitoring)

• Eingelangte Ergebnisse müssen überprüfbar sein und durch ein Flag gekennzeichnet werden können. Diese Freigabe wird durch den Projektleiter durchgeführt.

x Projektstruktur • Eigenen Workflow (Ordnerstruktur) erstellen können (Projektstruktur, Allgemeine Ordner) zum Ablegen jeglicher Artefakte.

• Beim Projektanlegen sollte die Grundstruktur incl. aller lt. QM freigegeben Dokumente und der letztgültigen Templates automatisch angelegt werden.

Performancedaten • Datenzugriff wie über Explorer 3 sec pro MB

• Datenzugriff extern sollte gleich schnell im Projektmanagement-Tool erfolgen wie z. B. über Windows Explorer

x Windows Konformität • Windows- System tauglich (z.B. XP, Vista,…)

• Unterstützung aller Windowsfunktionen(Drag & Drop,......)

• Suchfunktion(wie in Windows Explorer)

Allgemeine Anforderungen

• Leichte Bedienbarkeit – einfache Einführung muss möglich sein

Mit Hilfe dieser Checkliste reduziert man die Liste der Hersteller auf 5 bis max. 7 die man in die engere Auswahl nehmen möchte. Diese Tools werden einer genaueren Evaluierung unterzogen. Hier gibt es 2 Möglichkeiten:

Hersteller führt das Tool vor Eine Testversion der Software von ausgewählten Mitarbeitern testen lassen

Beide Varianten haben Vor- und Nachteile. Bei einer Vorführung durch den Hersteller bekommt man nur einen kurzen Eindruck der Funktionalität und kann nur schwer feststellen ob diese Software für den „Laien“ einfach zu bedienen ist oder nicht. Klarer Vorteil ist die kurze Zeit die benötigt wird um einen groben Eindruck zu bekommen. Die Variante mit der Teststellung ermöglicht einen ausführlichen Test der Software, birgt

Seite 55 von 87

aber das Risiko, dass die Testpersonen auf Grund der Komplexität des Tools, dieses nicht bedienen können und somit wie in Kapitel 7.5 beschrieben, keinen Mehrwert erkennen. Darüber hinaus benötigt man sehr viel Zeit um alle Tools zu testen. Die optimale Vorgehensweise ist eine Kombination aus beiden Varianten. Als weitere Reduzierung der möglichen Tools auf max. 3 empfiehlt es sich die Tools vom Hersteller vorführen zu lassen. In diesem Zuge kann man zusätzlich bereits über Lieferumfänge, mögliche Teststellungen und Kosten diskutieren. Vor der Präsentation sollte man das erstellte Pflichtenheft an die Hersteller übermitteln damit diese sich auf die Präsentation vorbereiten können.

Abbildung 27: Tool Auswahlliste

Nach Abschluss der Herstellerpräsentationen folgt eine Auswahl der Tools die man genauer testen möchte (siehe Abbildung 27: Tool Auswahlliste). Die Kosten haben zwar nicht die höchste Priorität sollten aber nicht außer Acht gelassen werden da bei Anschaffung von sehr teuren Tools der Return on Invest (ROI) sehr spät stattfindet und bei kleineren Firmen im schlimmsten Fall keine Amortisation stattfindet. Die Tests sollten anhanden des Pflichtenhefts von mindestens 2-3 Personen unabhängig voneinander durchgeführt und bewertet werden. Nach Abschluss der Tests entstehen ein Testbericht, eine Bewertungsmatrix und eine Wirtschaftlichkeits-berechnung als Entscheidungsgrundlage für das Management.

Seite 56 von 87

Auszug eines Testberichts Beispiel: Instep (Micro Tool) Die Firma Micro Tool erfüllt mit dem Produkt Instep das Pflichtenheft teilweise. Das Programm ist übersichtlich aufgebaut und in deutscher Sprache verfügbar. Die Oberfläche kann komplett an die Bedürfnisse der User angepasst werden. Stärken

Deckt das Pflichtenheft teilweise ab Die Ansprechpartner wirken sehr bemüht, hier eine vernünftige Lösung zu

schaffen Über eine Programierschnittstelle ist das Programm erweiterbar bzw. an unsere

Bedürfnisse anpassbar Sehr günstige Lizenzierungsart für Firmenlizenzen Termin – und Ressourcenplanung ist enthalten (auch Projektübergreifend) Export der Zeitpläne nach Microsoft Projekt ist einfach möglich

Schwächen

Kein Österreichsupport Vorort – die Ansprechpartner sind in Berlin Jeder Instep-Server ist extra zu lizenzieren. Anbindung an ERP System nicht vorhanden Zur Zeit keine „handelsübliche“ Datenbank verwendet Bedienung ist nicht intuitiv Keine Sprachumschaltung möglich

Allgemeines/Diverses Es sind noch einige Details anzupassen, welche aber nach einer Administrator-schulung selbst gemacht werden können. Mit diesem Tool würde sich durch eine Kooperation zusätzliche Einnahmequelle ergeben, da wir bei jeder über uns verkaufte Lizenz mitverdienen würden. Erstellen einer Bewertungsmatrix Die Bewertungsmatrix ist ähnlich jener in Abbildung 27, beinhaltet aber sämtliche zu überprüfende Punkte laut Pflichtenheft. Diese werden bewertet und in einer Sitzung aller Tester abgestimmt und dem Testbericht hinzugefügt. Im Anhang (Kapitel 10.7) finden Sie ein Beispiel einer solchen Bewertungsmatrix. Diese Matrix ist ausschlaggebend für die Endauswahl des Projektmanagement-Tools.

Seite 57 von 87

Wirtschaftlichkeitsbetrachtung In die Wirtschaftlichkeitsberechnung der Tools sind folgende Parameter eingeflossen:

Anzahl der Benutzer Arbeitszeit in % die jeder Benutzer für Tätigkeiten benötigt die dieses Tool

unterstützt in der Praxis wird ein Wert von mindestens 10% angenommen. Ersparnis der Arbeitszeit durch das Tool in % Durchschnittliches Benutzerjahreseinkommen in € Lizenzkosten für Tool Wartungskosten für Tool Schulungs- und Consultingkosten

Die Einsparungskosten errechnen sich wie folgt52: Ersparnis / Mitarbeiter pro Jahr = (durchschnittliche Stundenanzahl / Monat mit bestehendem System - Ersparnis der Arbeitszeit in %)*Stundensatz (errechnet aus durchschnittliches Benutzerjahreseinkommen)*12 Monate

Abbildung 28: Berechnungsmodel

52 Berechnungsmodell der Fa. Merant

Seite 58 von 87

Abbildung 29: Berechnung der Amortisationsdauer

7.4 Rollout der PM Software

Am Anfang eines Rollouts ist zu überlegen wie und wo man beginnt. Im beschriebenen Unternehmen (siehe Kapitel 10.3) mit mehreren Standorten wurde das Rollout zuerst an einem Standort in einer „Pilotabteilung“ durchgeführt. Diese Pilotphase dauerte ca. 2 Monate. Danach hat man die Software am kompletten Standort ausgerollt. Nachdem der erste Standort abgeschlossen war folgten die weiteren Standorte Schritt für Schritt. Dies stellte auch sehr große Anforderungen an die Infrastruktur eines Unternehmens. Folgende Dinge sind hier zu beachten:

Aufbau und Ort der Datenablage Zugriffsregeln auf die Server Datensicherung Worst-Case-Scenarien und Eskalationsprozeduren, Simulation der Stillstands-

zeiten für das Projekt (die Projekte) bei Serverausfall

Seite 59 von 87

Darüber hinaus ist zu beachten, dass verantwortliche Ansprechpartner zur Verfügung stehen. Gerade für Problemsituationen muss jeder im Projektteam die Informationen haben, wer für die Infrastruktur und für den Workflow verantwortlich ist.

Ansprechpartner Erreichbarkeit des Ansprechpartners Stellvertreterregelung

Bei der Planung ist darauf zu achten, dass die für die einzelnen Aufgaben geplanten Zeiträume ausreichend lang sind und zu den definierten Terminen die benötigten Ressourcen (Administratoren, Hardware, Räume,...) zur Verfügung stehen. Die folgenden Schritte sind bei einem Rollout zu berücksichtigen:

1. Aufbau und Inbetriebnahme der Serversysteme 2. Anlegen der Datenstrukturen / Datenbanken 3. Test von Datensicherung und Maßnahmen für den Worst-Case 4. Customizing des PM Tools im Hinblick auf die im PM Prozess festgelegten

Prozessschritte 5. Test der Schnittstellen zu anderen EDV Anwendungen (z.B. SAP, Navision,…) 6. Aufbau und Inbetriebnahme von Testclients 7. Prüfung des Workflows und eventuelles Finetuning 8. Planung des Rollout für alle Anwender 9. Installation und Test der Arbeitsplätze 10. Datenmigration 11. Training der Anwender (Tool, Umgebung, Workflow, Namenskonventionen,...)

Hauptprobleme bei einem Rollout in dieser Dimension ist die Infrastruktur. Je nach Tool gibt es die Möglichkeit eines zentralen Datenbankservers oder dezentrale Server an jedem Standort die in zyklischen Abständen am zentralen Datenbankserver gespiegelt werden. Auch die Performance der / des Tools kann erst nach dem Ausrollen ausführlich getestet werden. Dies führt in der Praxis meistens dazu, dass die Anwender am Beginn der Einführung bis zu dem Zeitpunkt, wo die Schwachstellen beseitigt wurden, unzufrieden sind. Das Thema Akzeptanz bei den Mitarbeitern wird im Kapitel 7.5 ausführlich beschrieben.

Seite 60 von 87

7.5 Schwierigkeiten bei der Einführung von Projektmanagement-Tools

In der Praxis stoßen wir bei jeder Änderung von Prozessen oder Einführung von neuen Tools auf Widerstand. In den von mir betrachteten Unternehmen haben sich hier immer dieselben Ursachen ergeben.

1. Hohe Erwartungshaltung zu Beginn der Einführung (das Tool löst alle Probleme).

2. Widerstand von Mitarbeitern (Stimmungsmachern) die schon lange im Unternehmen, sind nach dem Motto „Das haben wir schon immer so gemacht“.

3. Überforderung der Mitarbeiter mit den Tools. Methodiken des Projektmanagement sind nicht klar und somit kann der Mitarbeiter mit diesen vom Tool unterstützten Methoden nichts anfangen.

4. Der von den Tools unterstützte Workflow (Prozess) wird als Zusatzaufwand ohne zusätzlichen Nutzen angesehen.

Im Artikel „Akzeptanz von Projektmanagement-Software“ werden diese Probleme betrachtet und wie folgt beschrieben. Das Geheimnis der „gefühlten Unterstützung“ 53 Durch ein Werkzeug fühlen wir uns nur dann unterstützt, wenn wir mit seiner Hilfe ein bestimmtes Ziel oder Ergebnis leichter erreichen. Damit steigert es letztendlich unsere Leistungsfähigkeit. Die Leistungsfähigkeit wird häufig als Produkt der drei Größen „Wollen“, „Können“ und „Dürfen“ definiert. Tendiert eine der 3 Größen gegen Null, nähert sich die Leistungsfähigkeit als Produkt dieser 3 Größen ebenfalls dem Wert Null.

Abbildung 30: Leistungsfähigkeit als Produkt aus Dürfen, Können und Wollen.

Wollen wir diese Formel auf den Einsatz von Projektmanagement-Software anwenden, muss als erstes sichergestellt werden, dass die Mitarbeiter das Produkt verwenden dürfen. Ist das „Wollen“ vorhanden, ein bestimmtes Ziel zu erreichen, entsteht durch diesen Wunsch die Bereitschaft etwas zu unternehmen. Unsere Fähigkeiten, also

53 Vgl. Artikel: Akzeptanz von PM-Software, Frischmuth, PM Magazin 10/2008

Seite 61 von 87

unser „Können“ setzt diesem Wunsch hingegen Grenzen. Können beeinflusst maßgeblich, wie viel Zeit und Aufwand notwendig ist, um unser Ziel zu erreichen.

Abbildung 31: magisches Dreieck

Besteht allerdings ein Ungleichgewicht zwischen unserem Wunsch und den Faktoren „Zeiteinsatz und „Aufwand“ (sind diese also unverhältnismäßig hoch), sinkt die Bereitschaft (das „Wollen“) und wir verlieren das Interesse am Ziel. Bezogen auf Projektmanagement-Software bedeutet das: Erhalten wir ein Werkzeug, mit dem wir unser Ziel nur unter hohem Aufwand erreichen, empfinden wir das Werkzeug als Hindernis und legen es einfach aus der Hand. Erweitert das Werkzeug hingegen unsere Fähigkeiten, setzen wir es gerne ein und fühlen uns unterstützt. Anpassung des PM Prozess Um die optimale Synergie zwischen dem Projektmanagement-Tool und dem Projektmanagement-Prozess zu generieren empfiehlt es sich, die Prozesse auf das Tool abzustimmen. In der Toollandschaft bilden viele Tools bereits die IPMA Standard ab und können somit optimal in die bestehenden Prozesse eingebunden werden. Im Anhang unter Kapitel 10.6 ist ein Beispiel einer Prozessbeschreibung mit Einbeziehung der Projektmanagementsoftware PM-smart® dargestellt.

Seite 62 von 87

8 Anreizsysteme / Bonifikationsmodelle

8.1 Bonifikationsmodel für Projektleiter

Ziel der Projektleiterbonifikation ist es, die Identifikation des zuständigen Projektleiters mit seinem/n Projekt/en zu verstärken und die Prioritäten der erfolgsorientierten Auftragsbearbeitung auch entsprechend in der persönlichen Entlohnung wirksam zu machen. Sie ist ein wichtiger Bestandteil des erfolgs- und zielorientierten Gehaltssystems und ein Instrument, das dem Projektleiter hilft, die zentralen Inhalte und Erfolge des Projektmanagements in einen persönlichen, finanziellen Vorteil umzuwandeln. Darüber hinaus sollen Kalkulationsabweichungen bzw. –fehler oder sonstige Projekt-risiken möglichst frühzeitig erkannt werden, um entsprechende Maßnahmen einleiten zu können. Aufgrund einer weiteren Verknüpfung mit dem Abrechnungsstand der laufenden Projekte, soll der Cashflow nachhaltig verbessert werden. Als Hauptkriterium für die Beurteilung und die Berechnungsgrundlage empfehlen sich die Deckungsbeitragsveränderung, der Abrechnungsstand und die Einhaltung definierter Prozesse bei den jeweiligen Projekten. Die Projekte werden innerhalb eines Zeitraumes von einem Geschäftsjahr kumuliert betrachtet, also zusammengerechnet. Hierbei gehen sowohl Projektverbesserungen, als auch Verschlechterungen in die Berechnungsbasis ein.

Abbildung 32: Beispiel einer Projektleiter Bonifikationstabelle

Seite 63 von 87

Die Auszahlung und Berechnung kann quartalsweise oder zum Ende des Geschäftsjahres erfolgen. Die Bonifikation kann sich nur als Mehreinkommen für den jeweiligen Projektleiter auswirken, Gehaltsabzüge sind ausgeschlossen, wobei die Projekte eines Geschäftsjahres kumuliert betrachtet werden und sich in Einzelfällen eine Auszahlungsreduktion ergeben könnte. Bei Bonifikationsmodellen ist darauf zu achten, dass es zu keinen konkurrierenden Zielen kommt. Zum Beispiel wird im oben angegebenen System der Zieldeckungsbeitrag gemeinsam vom Geschäftsführer / Profitcenterleiter / Projekt-auftraggeber gemeinsam mit dem Projektleiter festgelegt. Diese Vorgaben sind in den meisten Fällen nur sehr schwer erreichbar. Hierbei kommt das Problem zu Tage, dass der Geschäftsführer / Profitcenterleiter / Projektauftraggeber in seinen Ziel-vereinbarungen nach Betriebsergebnis entlohnt wird und somit die Ausgaben (auch Prämienauszahlungen) des Bereichs minimieren will / muss.

Seite 64 von 87

9 Resümee

„Was sind die größten Hürden und wo liegen die Probleme bei der Einführung von Projektmanagement?“ Mit dieser Frage bin ich gestartet und war überrascht, dass die Problemed bereits bei der Definition von Projekten und der Rolle des Projektleiters begonnen haben. Das fehlende Methodenwissen hatte ich erwartet, dachte aber nicht, dass Begrifflichkeiten wie Umfeldanalyse, Projektstrukturplan, Meilensteintrendanalyse, Claimmanagement, uvm. bei den meisten befragten Projektleitern nicht bekannt waren. Auch wurde mir schnell klar, dass viele Führungskräfte mit der Einführung von Projektmanagement die Erwartungshaltung hatten, alle Ihre Probleme gelöst zu bekommen. Dies ging hin bis zur Aussage „Führen wir mal schnell eine Projektmanagementsoftware ein um unsere Probleme in den Griff zu bekommen“. Ich denke, dass es mir gelungen ist einen Leitfaden für die Einführung von Projektmanagement zu gestallten, dass dieser in der Praxis leicht anwendbar ist und die wichtigsten Punkte, die zu berücksichtigen sind, aufgezeigt wurden. Dies war auch die Zielsetzung meiner Master Thesis. Darüber hinaus wurden Methoden vorgestellt (Project Excellence Model, Quality Gates) die es einem ermöglichen den aktuellen Status der Prozesse zu erfassen um Verbesserungen daraus abzuleiten. Um auch den Betriebserfolg von Unternehmen zu gewährleisten wurden Themen wie Organisation, Prozessdarstellungen, Multiprojektmanagement und Kennzahlen angesprochen. Dieser Mix ist notwendig um ein Unternehmen erfolgreich zu steuern. Auch wurde beschrieben wie man bei der Einführung eines Softwaretools vorgehen kann und welche Punkte zu beachten sind. Mit dieser Vorgehensweise wurden von mir in den letzten Jahren mehrere Softwarepakete im beschriebenen Unternehmen eingeführt und in meiner aktuellen Firma wird diese für Erweiterungen der bestehenden Projektmanagementtoollandschaft angewendet. Zu guter letzt wollte ich eine Methode ansprechen mit der es ermöglicht wird Projektleiter enger an ihre Projekte zu binden. Bonifikationsmodelle sind hierfür ein bewährtes Mittel trotz aller Gefahren die diese mit sich bringen. Abschließend soll noch angemerkt werden, dass der beschriebene Ansatz als Beratungsansatz für einen Projektmanagementtoolhersteller Verwendung finden soll. Aus diesem Grund darf dieses Konzept einem stetigen Optimierungs- und Erweiterungsprozess unterworfen werden, was langfristig den Erfolg des anwendenden Unternehmens sichern kann.

Seite 65 von 87

10 Anhang

10.1 Literaturhinweise

[1] PMA, pm baseline Version 2.4, Mai 2007

[2] Sterrer, Winkler, Let your Projects fly, 2006

[3] PMA, pma Award 2008 Leitfaden für Bewerber, Jan. 2008

[4] Stroebe, Grundlagen der Führung, 11. Auflage 2002

[5] Fisher, Ury, Patton, Das Harvard Konzept, 1991

[6] Stehling, Ja zum Stress, 2000

[7] von Hertel, Professionelle Konfliktlösung, 2003

[8] Lay, Führen durch das Wort, 5. Auflage 2002

[9] Braun, Die Macht der Rhetorik, 2001

[10] Forsyth, 30 Minuten bis zur überzeugenden Präsentation, 3. Auflage 2001

[11] EVOLOSO Organisationssoftware & Consulting GmbH, Benutzerhandbuch PM-smart®

[12] http://www.swimlane.info/meth_allg.htm

[13] Härdler, Betriebswirtschaft für Ingenieure, 2. Auflage 2003

[14] Dräger, Grundlagen des Prozessmanagements, Vorlesung Graz November 2006

[15] Schreyögg, Grundlagen moderner Organisationsgestaltung, 4. Auflage 2003

[16] Schwan, Organisationsgestaltung, 2003

[17] Wunderer, Integriertes Management, 1985

[18] Krummenacher, Flexibles Management statt Bürokratie, 1985

[19] Aichele, Intelligentes Projektmanagement, 2006

[20] Horváth, Controlling, 8. Auflage 2001

[21] Bernhard, Hofschröer, Report Balanced Scorecard: Strategien umsetzen, Prozesse steuern, Kennzahlensysteme entwickeln, 2. Auflage 2001

[22] Küng, Wettstein, Ganzheitliches Performance-Measurement mittels Informations-technologie, 2003

Seite 66 von 87

[23] Schierenbeck, Lister, Value Controlling: Grundlagen Wertorientierter Unternehmensführung. 2. Auflage 2001

[24] Patzak, Rattay, Projektmanagement, 3.Auflage 1998

[25] Gareis, Happy Projects, 2. Auflage 2004

[26] Haring, Diplomarbeit: Analyse von Multi-Projektmanagement-Software, Wien 2001

[27] Süß, Ehrl- Gruber, Projektmanagement, Ergebnisorientierte und termingerechte Projektabwicklung in der Industrie, 1998

[28] Lomitz, Multiprojektmanagement, Projekte erfolgreich planen, vernetzen und steuern, ebook, 2004

[29] Zöllner Uwe: Praxisbuch Projektmanagement - Das neue, umfassende Handbuch für Führungskräfte und Projektmitarbeiter, 2003

[30] Keßler, Winkelhofer, Projektmanagement, Leitfaden zur Steuer und Führung von Projekten, 2. Auflage 1999

[31] Reschke, Handbuch Projektmanagement, 1989

[32] Steinle, Bruch, Controlling: Kompendium für Controllerinnen und ihre Ausbildung, 2. Auflage 1999

[33] Lachnit, Controllingkonzeption für Unternehmen mit Projektleistungstätigkeit, 1994

[34] Küpper, Wagenhofer, Handwörterbuch Unternehmensrechnung und Controlling, 4. Auflage 2002

[35] Fiedler, Controlling von Projekten, 2003

[36] Schmidt, Vortrag: Organisation Qualitätsmanagement

[37] Sigemund, Vortrag: Produktlebenszyklus-Management, 2007

[38] Prefi, Vortrag: Entwicklungsqualität mit System, 2004

[39] Frischmuth, PM Magazin 10/2008, Artikel: Akzeptanz von PM-Software

[40] IBM, Rational Unified Process, 9. Version, 2006

[41] Fa. Merant, Berechnungsmodel zur Verfügung gestellt im Mai 2004

Seite 67 von 87

10.2 Abbildungsverzeichnis

Abbildung 1: Überblick über temporäre Aufgaben ..........................................................8 Abbildung 2: Abhängigkeiten im Projektmanagement-Dreieck .......................................9 Abbildung 3: Project Excellence Model...........................................................................9 Abbildung 4: Projektvergleich anhanden des "Project Excellence" Models ..................11 Abbildung 5: Auswertung der Befragung für einen Standort.........................................14 Abbildung 6: Auswertung des Projektmanagement Know-how ....................................14 Abbildung 7: Unterschied Projektmanagement / Projektabwicklung.............................15 Abbildung 8: Beispiel einer Prozesslandkarte...............................................................16 Abbildung 9: Projektmanagementprozesse ..................................................................17 Abbildung 10: Projektstartprozess in PM-smart® .........................................................18 Abbildung 11: Darstellung einer relationalen Rollendefinition zwischen PAG und PL ..21 Abbildung 12: Beispiel einer Swimlane-Grafiken ..........................................................26 Abbildung 13: Entwicklung der Organisationsformen ...................................................29 Abbildung 14: Idealer Prozessablauf ............................................................................30 Abbildung 15: "Realer Ablauf".......................................................................................30 Abbildung 16: Schnittstellenproblematik .......................................................................31 Abbildung 17: Monitoring-System .................................................................................37 Abbildung 18: Auftragsstand / Ressourcenauslastung .................................................38 Abbildung 19: Projektcontrolling als zyklischer Prozess ...............................................39 Abbildung 20: Kommunikationsstrukturen im Controllingprozess .................................40 Abbildung 21: Darstellung des Projektcontrollingprozess .............................................40 Abbildung 22: Quality Gates im Prozess.......................................................................41 Abbildung 23: Quality Gate ...........................................................................................42 Abbildung 24: Multiprojektmanagement -Betrachtungswinkel bzw. -Abgrenzung ........43 Abbildung 25: Projekt- versus Multiprojektmanagement...............................................44 Abbildung 26: Bausteine des Multiprojektcontrollings...................................................49 Abbildung 27: Tool Auswahlliste ...................................................................................55 Abbildung 28: Berechnungsmodel ................................................................................57 Abbildung 29: Berechnung der Amortisationsdauer......................................................58 Abbildung 30: Leistungsfähigkeit als Produkt aus Dürfen, Können und Wollen. ..........60 Abbildung 31: magisches Dreieck.................................................................................61 Abbildung 32: Beispiel einer Projektleiter Bonifikationstabelle......................................62 Abbildung 33: Leistungsspektrum.................................................................................68 Abbildung 34: Niederlassungen ....................................................................................68 Abbildung 35: Geschäftsfelder ......................................................................................69

Seite 68 von 87

10.3 Kurzbeschreibung eines Unternehmens im Anlagenbau

Mit Hilfe des hier beschriebenen Unternehmens wird versucht ein Bezug zur Praxis für die weiteren Kapitel herzustellen. Das Unternehmen Die Kernkompetenzen des angeführten Unternehmens sind das Messen, Steuern und Regeln komplexer Abläufe in Industrie- und Umwelttechnik, Tunneltechnik und in der Automation von Versorgungsnetzen. Der Nutzen für den Kunden ist die Lieferung von Gesamtsystemen durch einen Generalunternehmer. Von der Projektierung über die Inbetriebnahme bis zum After-sale-Service kommt alles aus einer Hand.

Abbildung 33: Leistungsspektrum

Das Unternehmen ist heute weltweiter Anbieter im Bereich der Automation. Bis 1990 wurden internationale Märkte ausschließlich von den österreichischen Standorten aus bedient. Seitdem wurden zahlreiche Standorte und internationale Netzwerke aufgebaut. Neben mehreren Standorten in Österreich gibt es weitere Niederlassungen in Europa und Asien.

Abbildung 34: Niederlassungen

Seite 69 von 87

Umfassendes Qualitätsmanagement stellt bei diesem Unternehmen ein wesentliches Instrument zur Erhaltung und Steigerung der Wettbewerbsfähigkeit da. Zertifizierungen werden eingesetzt, um Produkt- und Dienstleistungsqualität im Sinne des Kunden ständig zu verbessern. Strategische Geschäftsfelder

Abbildung 35: Geschäftsfelder

Industrieautomation: Maßgeschneiderte Automationskonzepte für Industrie (Produktion, Verfahrenstechnik, Ver- und Entsorgung, Fördertechnik und Sondermaschinenbau). Netzautomation: Netzleit- und Automatisierungstechnik der Bereiche Strom-, Gas-, Wasser- und Fernwärme. Umweltautomation: Komplettlösungen für kommunale und betriebliche Umwelttechnik wie Wasserversorgungs- oder Abwasserreinigungsanlagen, Kläranlagen oder Müllverwertungsanlagen, Bioenergieanlagen und Umweltmessnetze. Tunnelautomation: Tunnelautomation mit dem Schwerpunkt Tunnelleittechnik, Leitsysteme für Tunnelwarten, Beleuchtungs- und Lüftungssteuerungen, Verkehrszählungen.

Seite 70 von 87

Elektrotechnik: Elektrotechnische Komplettausstattungen für komplexe Gewerbe- und Industrieanlagen, Sicherheitstechnik. Schaltanlagenbau: Steuerungsverteiler für Anlagen- , Prozess- , Maschinen- und Gebäudeautomation.

Seite 71 von 87

10.4 Fragenkatalog zum Projektmanagement

Fragenkatalog zum Projektmanagement Standort: _____________________________

Pkt. 1 generelle Fragen zu PM Optimale

Kenntnisse Gute

Kenntnisse Kaum

Kenntnisse Keine

Kenntnisse

1.1 Was verstehen Sie unter dem Begriff PM?

A:

* Übergeordnete Prozesse (Tools) zur organisierten, effektiven, effizienten Abwicklung eines Auftrages (Aufgabe) meist in Teams.

1.2 Was sind aus Ihrer Sicht die Zieles des PM?

A:

Effektive und effiziente zielgerichtete Abwicklung eines Auftrages innerhalb der Organisationseinheit

1.3

Wurden Sie zum Thema PM geschult? - wenn ja intern oder extern und Schulungstage (ca.)

A: * keine Schulung - keine Kenntnisse * mehr als 10 Schulungstage = Optimal

1.4 Hat ihr Vorgesetzter sie zum Thema PM gezielt instruiert?

optimal ja kaum nein

1.5 Finden sie in ihrem QM-System Informationen über PM die sie umsetzen?

A: *Nein/Wenn ja, welche sehr viel viele wenig keine

1.6 Welche Informationsquellen fürs PM kennen u. benutzen Sie? (Toolbox)

A: *Nein/Wenn ja, welche sehr viel viele wenig keine

1.7 Bringt sie eine gezielte Ausbildung zum Thema PM in eine bessere Position die geforderten Ergebnisse zu erreichen?

A: * Frage nach der Erkennung der Bedeutung PM ja sicher ja öfters kaum nein

1.8 Sind ihre Kollegen mit der Systematik eher besser oder schlechter vertraut?

A: * Frage nach Durchdringung ja manche eher nicht sicher nicht

1.9 Wie sehen sie die Rolle des PL im Unternehmen?

A: Frage nach der Bedeutung des PL in der Organisation sehr wichtig wichtig

manch. Wichtig unwichting

Pkt. 2 Fragen zum Prozess des PM Optimale

Kenntnisse Gute

Kenntnisse Kaum

Kenntnisse Keine

Kenntnisse

2.1

Können sie die wesentlichen Projektphasen (Prozessschritte) innerhalb des PM nennen?

A: * Vorprojektphase (Offert) * Projektstartphase

* Projektdurchführung, Steuerung, Controlling

* Projektabschluss

Seite 72 von 87

2.2 In welcher Projektphase entscheidet sich oft ob es ein Erfolg bzw. Misserfolg gibt?

A: * (Offertphase) * Projektstartphase

2.3 Welche Aktivitäten würden sie zum Start eines Projektes setzen?

A: * Abklärung der Kundendokumenten auf Vollständigkeit und Eindeutigkeit!

* Aktualisierung Kalkulation * Setzen von Meilensteinen und Terminplan * Aufteilung der Arbeit im Projektteam! * Kick-Off-Meeting/Projektstartgespräch

* Kommunikations- und Informationsorganisation!

* Durchführung Umfeldanalyse! * Riskoanalyse! * Überlegungen zu Claimmanagement! * Projektstrukturierung * Ressourcenplanung

* Projektstrategie erarbeiten/Projektteilziele festlegen

2.4

Was unterscheidet prinz. ein Projekt mit bekannten Kunden zu einem Projekt mit neuem unbek. Kunden!

A:

Quantität und vor allem Qualität der Information d. Werthaltung und Gepflogenheiten d. Mitarbeiter des Kunden!

2.5 Welche Arten von Abweichungen können im Projekt auftreten?

A: * Kosten * Termin * Produktqualität (Hard- und Software)

2.6 Welche Aktivitäten setzen Sie bei Erkennen von größeren, eingetretenen Abweichungen zB Kosten?

A: * Trendanalyse

* Finanzielle Bewertung hochgerechnet auf Projektende und Information an Führungskräfte

* Maßnahmen um Folgeabweichungen zu vermeiden

* Kommunikation im Team * Ursachenanalyse (Ev. Claimpotential)

2.7 Welche Aktivitäten setzen Sie wenn größere Abweichungen drohen?

A: * Maßnahmen für Gegensteuerung * Finanzielle Bewertung * Vorinformation an Führungskräfte * Kommunikation im Team

2.8 Bearbeiten sie Aktiv mögliche Risikosituationen in den Projekten?

Wenn ja, wie? (Laufende Risikoanalyse auf Basis von Informationen aus dem Projektteam bzw. von externen)

A: Frage nach Frühwarnsystemen und vorrausschauende Projektleitung

2.9

Wie kommen Sie zu einer Prioritätenreihung bei Gleichzeitigkeit von drohenden Abweichungen!

A:

Über Vergleich der finanziellen Bewertungen inkl. Betrachtung der Termin- und Qualitätsauswirkungen

2.10 Was müssen sie beim Setzen von Maßnahmen generell definieren!

A: Was, Wann, Wer, ev. mit Unterstützung von

Seite 73 von 87

wem

2.11 Was verstehen sie unter den Begriff Projektcontrolling?

A:

Steuerungsinstrument (Informationsquelle) zu Unterstützung des PL gleichzeitig Informationsquelle über Projektstatus für Führungskräfte

2.12 Werden Sie alle Abweichungen selbst erkennen!

A:

Nein, Prinzipiell werden viele Abweichungen nur durch Ausführende erkannt (CAD-Engin., Monteur, Disponent, …)

2.13 Können Sie den Begriff Claimmanagement erklären?

A:

Berechtigte Forderung im Vergleich zu Vertrag an oder vom Kunden auf Basis eines Ereignisses das entweder bei AG oder AN zu Mehrkosten führt!

2.14 Welche zwei Arten von Claim gibt es?

A: Aktiv/Passiv

2.15 Welche Aktivitäten sind beim Claim besonders wichtig?

A: * Dokumentation * Rechtzeitigkeit * Beweisbarkeit * Verbindung zu Vertrag

* Abgleich Chance Claims zu setzen - vs: Generelle Projektstrategie

2.16 Wie geht ihre Organisationseinheit im Fehlern um?

A:

Schuldsuche oder Chance zum lernen, Kritisch wenn der gleiche Fehler mehrmals passiert!

Pkt. 3 Projektabschluss

3.1 Wann ist aus ihrersicht ein Projekt abgeschlossen?

A: * Hard- und Software übergeben inkl. Kundendokumentation

* Mängelliste abgearbeitet * offene Forderungen eingetrieben * Projektabschlussbericht erstellt

* Know-How Transfer für nachfolgende Projekte initiiert

A: Beispielantworten (zur leichteren Bewertung)

Seite 74 von 87

10.5 Prozess Ablaufdiagramm

Start

1. Projekt anlegen, PL ernennenProjekt kategorisieren

2. Übergabe VPL an PL

3. Erstellung Projektauftrag (mitStruktur, Vergabe Konzept, Strategie UA,

RA, Kalkulation)

Freigabe zur Bearbeitunglt. Projektauftrag

4. Detailanalyse/PrüfungVertragsdokumente

(Einholung, Abstimmung, weitereKunden Unterlagen)

freigegebene vollständigeKundenunterlagen

4. Kick off "Team"

5. techn. Ausführungsplanung - Übergabe CAD, AUT,BL (AV)

6. Beschaffungsplanung - Übergabe MA aus EK

7. Terminplanung

8. Ressourcenplanung (CAD, AUT, Monteur, SAB)

9. Detail Kostenplanung

10. Erlös / Zahlungsplanung

11. Erstellung Projekthandbuch

nein

ja

nein

ja

X

22. Nachträgeeinplanen

Seite 75 von 87

12. Detail techn.BearbeitungCAD, AUT

16. Kundenkom-munikation,Koordinationintern/extern

19. Maßnahmensetzen

13. Material-Ressourcen-

Systembestellungenexterne Fertigung

14. Fertigung intern

15. Montage

18. laufendes Controlling(Steuern)

Vertragserfüllung QTermineKosten

StrategieeinhaltungRisikomanagement

Umfeld Beobachtung

17. Berichtswesen

Abweichung zuPlanwerte intern

20. Claim-management

Nachträge,techn. Änderungen

Kunde

nein

ja

nein

22. Inbetriebnahme

X

Mängel

23. Kaufm. Abschlußarbeiten:Fertigstellungsmeldung

Enddokumentation abliefernTeilrechnung /Schlußrechnung

Klärung Rg. mit Kunden

24. NachkalkulationProjektnachbesprechung

MängellisteGarantie-arbeiten

FeedbackWürdigung

Zieler-reichung

LessonsLearned(KVP)

19. Maßnahmensetzen

ja

22. Nachträgeeinplanen

Mel

dung

von

Abw

eich

unge

n

ja

nein

11.

ÜbergabeService

Seite 76 von 87

10.6 Beschreibung zum Prozessablauf mit Einbeziehung eines PM Tools

Nr. Aktivität Verant-wortung

Beschreibung

1

Projekt anlegen

Anlegen des Projektes im ERP System Anbotsnr.=Proj.Nr.; / Anlegen d. Projektes im PM-SMART MPM /Projektordner (Vorlage s. A Ordnerstruktur) wird im Hintergrund erstellt

Ernennung PL / Kategorisierung Proj. Komplex – Standard (Wahl des Vorlagenprojektes aus QM- Laufwerk)

PAG

Arbeitsanw.

Ablagestruktur

(Projektordner-struktur)

A04_5_01

2

Projektübergabe PAG an PL:

Basierend auf die entsprechende Checkliste im PM-SMART Multiauftrag ist innerhalb von 6 Werktagen ab Auftragseingang ein Projektübergabegespräch durchzuführen und zu dokumentieren. Alle relevanten Unterlagen sind dem Projektleiter zur Verfügung zu stellen u. kurz zu erklären.

Das Projektbudget ist detailliert zu besprechen

PAG

3

Erstellung und Freigabe Projektauftrag:

Auf Basis Projektauftrag im PM-SMART Multiauftrag /Grob PSP mit Beachtung Eigenleistung zu Fremdvergaben, Abklärung welche PMA (Projektmitarbeiter) nominiert werden.

Zusätzlich Bearbeitung bei komplexen Projekten von UA (Umfeldanalyse), RA (Risikoanalyse), Projektstrategien, Vergabekonzepten

Freigabe durch PAG auf Basis PAG-PL Meeting inkl. Zielfestsetzungen

PL

PAG

Arbeitsanw.

Umfeldanalyse,A04_7_01

Risikomanagement A04_7_02

PAG-Meeting

A04_7_09

4

Detailanalyse (Überprüfung) Vertragsdoku: Der PL muss stets über sein Projekt und dessen technische und kaufmännische Inhalte Bescheid wissen. Besonders heikle

PL

Seite 77 von 87

Punkte sind bereits im Vorfeld zu eruieren und durch Sicherstellung entsprechender Maßnahmen vorzubeugen.

Als Hilfe dienen die Checklisten Techn. bzw Kaufm. Vertragsanalyse PM-SMART Multiauftrag

Einholen und urgieren (beizustellender, fehlender, unklarer) Unterlagen: Für die Auftragsabwicklung beizustellende Unterlagen von Kunden, Partnern, externer Lieferanten sind umgehend anzufordern. Bei Lieferverzug sind entsprechende Maßnahmen zu setzen und Claims vorzubereiten

Weitergabe Infos, Aufgaben komprimiert an Team- Kick off Meeting – Durchzuführen bei TEAMS größer 3-4 Personen o. SGF-übergreifend

5

Technische Ausführungsplanung:

Weitergabe Aufgaben, Detailinfos an CAD, AUT, BAUL - Verwendung der Übergabechecklisten PM-SMART und der relevanten Formulare (CAD- Planung,…über PM-SMART verfügbar).

Prüfung interner und externer Unterlagen. Die technische Prüfung erfolgt in Zusammenarbeit PL mit der jeweiligen Fachabteilung.

PL, PMA CAD, AUT, BAUL

6

Beschaffungsplanung:

Vorabstimmung(-info) mit zuständigen MA aus Einkauf über wesentliche, werthaltige Kaufteile Material, Systeme o. Leistungen.

PL, MA aus EK

Arbeitsanweisung Projekteinkauf

A04_7_04

7

Terminplanung:

Der PL hat die Aufgabe einen realistischen Terminplan gemeinsam mit den Fachabteilungen zu erstellen und diese mit dem Kunden abzustimmen. Terminabstimmung mit wesentlichen Lieferanten (mit EK) und internen

PL, PMA, MA aus EK

Seite 78 von 87

Abteilungen werden vom PL durchgeführt und im Terminplan im PM-SMART eingepflegt. Der zum Projektbeginn erstellte Terminplan ist dem Kunden zur Freigabe (wenn vereinbart) vorzulegen.

Besonderes Augenmerk ist auf das Setzen von entsprechenden Milestones zu legen.

8

Ressourcenplanung:

Erfolgt über Ressourcenanfrage an Ressourcen- Verantwortlichen – gilt auch für die „Ressource“ PL. Die Ressourcenanfragen erfolgen über PM-Smart.

Wichtig ist eine eindeutige Bestätigung des Verantwortlichen aus der Fachabteilung.

PL, Ressourcen- Verantw.

CAD,

AUT,

MONT

9

Detaillierte Kostenplanung:

Diese ist abgeleitet aus den bisherigen Erkenntnissen zum Projekt im PM-SMART auf PSP- Ebene zu hinterlegen / eine mögliche relevante Abweichung zum Zielwert DB ist mit dem PAG umgehend zu besprechen.

PL Arbeitsanw. Projektkosten- controlling A04_7_07

10

Erlös-, Zahlungsplanung

Diese ist im PM-SMART Projektplanung so früh wie möglich zu hinterlegen / Angaben o. UST und mit Abzug des maximalen Skontos. Das Ziel hierbei ist eine positive Projektfinanzierung über die gesamte Projektlaufzeit zu haben.

PL, PMK Arbeitsanw. Projektkosten- controlling A04_7_07

11

Erstellung Projektmanagementhandbuch

Zusammenfassung der Planungsunterlagen für PL, PAG und zum Teil PMA.

PL

12

Detaillierte Bearbeitung AUT, CAD:

Bearbeitung auf Basis der aktuellen, freigegebenen Dokumente und Formulare

ÄNDERUNGEN ausgelöst d. Kunden, Lieferanten o. eigene FA sind unverzüglich an PMA’s weiterzuleiten.

PL, PMA

Seite 79 von 87

Die Kommunikation mit Kunden und externen Planern führt der PL mit Unterstützung der PMA CAD, AUT.

Der PMA hat (mögliche, eingetretene) relevante Abweichungen zu den Zielvorgaben aus Kundenvertrag, Termin , Kosten über Formular „Meldung einer Abweichung“ frühzeitig an den PL zu melden

13

Material-/Ressourcen- /Systembestellungen/Fremdfertigung

Bestellungen siehe Prozess Beschaffung Besonders bei technisch anspruchsvollen und komplexen Bestellungen hat der PL die Unterstützungsfunktion des MA von EK in Sinne eines erfolgsorientierten PM wahrzunehmen. Besondere Vertragsbedingungen des Kunden sind in Form von projektspez. Einkaufsbedingungen vom PL zusammenzustellen und an den MA –EK zeitgerecht weiterzuleiten.

Vergabe von Leistungen (Outsourcing) ist vom SGFL freizugeben

ÄNDERUNGEN ausgelöst d. Kunden, andere Lieferanten o. eigene FA sind unverzüglich an MA-EK weiterzuleiten

Der MA-EK hat (mögliche, eingetretene) relevante Abweichungen zu den Zielvorgaben aus Kundenvertrag, Termin , Kosten über Formular „Meldung einer Abweichung“ frühzeitig an den PL zu melden

PL, zuständiger aus EK

Arbeitsanw.

Projekteinkauf,

Prozess Beschaffung P05_7_01

14

Fertigung:

Es gelten die def. Prozesse, Arbeitsanweisung.

Die def. Formulare zur Weitergabe der rel. Technischen Dokumente, Termine und Stundenbudgets hinterlegt im PM-SMART sind zu verwenden.

ÄNDERUNGEN ausgelöst d. Kunden,

PL, FV Prozess Fertigung P06_7_01

Seite 80 von 87

Lieferanten o. eigene FA sind unverzüglich an Fertigungsverantwortlichen (FV)weiterzuleiten

Der FV hat (mögliche, eingetretene) relevante Abweichungen zu den Zielvorgaben aus Kundenvertrag, Termin , Kosten über Formular „Meldung einer Abweichung“ frühzeitig an den PL zu melden

15

Montage

Es gelten die def. Prozesse, Arbeitsanweisungen

Die def. Formulare zur Weitergabe der rel. Technischen Dokumente, Termine und Stundenbudgets hinterlegt im PM-SMART sind zu verwenden.

ÄNDERUNGEN ausgelöst d. Kunden, Lieferanten o. eigene FA sind unverzüglich an BAUL (AV) weiterzuleiten

Der BAUL (AV) hat (mögliche, eingetretene) relevante Abweichungen zu den Zielvorgaben aus Kundenvertrag (Claims), Termin, Kosten sowie internen Richtlinien über Formular „Meldung einer Abweichung“frühzeitig an den PL zu melden.

PL, BAUL

Prozess Montage

P06_7_02

16

Projektkoordination, Kundenkommunikation

Einholen und Urgenz von Kundenfreigaben: Die von den jeweiligen internen und externen Lieferanten, erstellten vertragsrelevanten Unterlagen (Ausführungspläne, Pflichtenheft, Terminplan,...) sind vom Kunden schriftlich dokumentiert freigeben zu lassen. Bei verspäteten Freigaben sind entsprechende Maßnahmen zu setzen und Claims vorzubereiten.

Teilnahme an Baubesprechungen und Verhandlungen:

PL

Beachtung der allgemeinen Kommunikationsregelungen

Im Projektmanagementhandbuch

(PMHB)

Seite 81 von 87

An vertragsrelevanten Verhandlungen und Besprechungen hat der PL teilzunehmen. Sollte dies aus terminlichen Gründen nicht möglich sein, hat PL dafür zu sorgen, dass ein kompetenter Vertreter zur Verfügung steht. Über sämtliche vertragsrelevante Besprechungen und Verhandlungen sind Protokolle zu erstellen, die an alle Teilnehmer zum Zeichen des Einverständnisses verteilt werden.

Der PL ist verantwortlich für die Abhaltung von Teammeetings (nach definierten Regeln der Projektteams)

17

Berichtswesen (Fortschrittberichte)

Der PL ist für die ordnungsgemäße Führung (Dokumentation) des Projektes im PM-SMART verantwortlich. PMA und PAG nutzen die Information aus dem PM-SMART.

Der PL hat die im Rahmen der Projektbeauftragung definierten Regeln über Bericht an den PAG strikt einzuhalten

PAG-Meetings nach definierten Zeitabständen

Bericht über wesentliche drohende, eingetretene Abweichungen frühzeitig bei Erkennen

PL

Verwendung der Vorlagen PM-SMART

Arbeitsaneisung PAG-Meeting

A04_7_09

18

Laufendes Controlling (Steuern)

Kosten- und Stundencontrolling: Vergleich kalkulierte und festgelegte Stunden- und Kostenbudget ist über PM-SMART (PSP) durchzuführen und wie vereinbart zu berichten.

Der PL hat die Aufgabe nach den kostenoptimalen Grundsätzen sein Projekt zu steuern. Der PAG hat ihn dabei bei Bedarf zu unterstützen.

Details Arbeitsanweisung Projektkostencontrolling

PL

PL

Arbeitsanw.

Projektkosten- controlling, Umfeldanalyse,

Risikoanalyse,

Strategieformular

Seite 82 von 87

Termincontrolling

TPL im PM-SMART - Anpassung ereignisabhängig, dem Projektverlauf entsprechend zu aktualisieren. Geänderte Termine sind umgehend mit den betroffenen Abteilungen und Personen abzustimmen. Sollten Vertragstermine nicht gehalten werden können ist umgehend mit dem Kunden Einvernehmen herzustellen und dies zu dokumentieren. Ist dies nicht möglich, sind entsprechende Forcierungsmaßnahmen einzuleiten. Für die Einhaltung der internen Termine für die Teilprojekte ist die jeweilige FA verantwortlich. Bei Erkennen von Terminverlusten ist umgehend der PL zu informieren. Koordination der internen und externen Lieferanten: Der PL hat dafür zu sorgen, dass die Schnittstellen zwischen den verschiedenen Abteilungen und Lieferanten geklärt sind und die Teilprojektverantwortung der jeweiligen Abteilung wahrgenommen werden kann.

Leistungscontrolling:

Der Leistungsfortschritt ist zumindest vor jedem Projektcontrolling zu aktualisieren. Bearbeitung anhand der Arbeitspakete im PSP von PM-SMART

Strategieänderungen, Umfeldänderungen, Risikobeurteilungen:

Diese sind bei komplexen Projekten zumindest bei den PAG-Meetings aktiv anzusprechen und wenn notwendig durch Definitionen von Maßnahmen zu bearbeiten

19

Maßnahmen setzen:

Für die Bearbeitung von Maßnahmen aus einer „größeren“ Problem/Risikosituation ist zur besseren Übersicht ein Problemfeld im PM-SMART Risikomanagement anzulegen

PL

Arbeitsanw.

Umgang mit Abweichungen zum Plan

A04_7_05

Seite 83 von 87

und dort die Todo’s zu definieren.

20

Claimmanagement:

Claimmanagement: Je nach Auftragsfall hat ein aktives und vorbeugendes Claimmanagement zu erfolgen. Besonders bei Neukunden, GU-Kunden, „kalkulatorischen Negativprojekten“ oder schwierigen Vertragsbedingungen ist generell ein intensives Claimmanagement anzuwenden. Claims sind unter anderem vorzubereiten und durchzusetzen bei:

• Produkt- oder Ausführungsänderungen

• relevanten Massenänderungen

• Mehraufwände, Stehzeiten, Regien

• Bauzeitverkürzung oder -verlängerung

• Claims von Lieferanten oder Kunden

• Fehlende oder zu späte Vorleistungen

Bei der Formulierung und Durchsetzung der Claims hat der PAG unterstützende/entscheidende Funktion.

Abwicklung im PM-SMART Claimmanagement

ANMERKUNG:

„unklare“ Nachträge –noch keine kaufmännisch relevante Bestellung vor notwendigem Arbeitsbeginn da – sind vorab wie ein „Claim“ im System zu behandeln.

PL, PMA Arbeitsanw.

Claimmanagement A04_7_06

21

Umgang mit Nachträgen: Im Falle von zusätzlichen oder geänderten Leistungen oder Lieferungen ist zeitgerecht, vorzugsweise noch vor Beginn der betreffenden Arbeiten ein Nachtragsoffert zu erstellen vom Kunden freigeben zu

PL, VPL, PMA

Seite 84 von 87

lassen. Bei der Erstellung sollte ev. der VPL, bei der Durchsetzung des Angebotes der jeweilige AL unterstützend mitwirken.

Es gelten sinngemäß die Richtlinien aus dem Vertriebsprozess.

Die Nachträge sind – wenn sie den ursprünglichen Auftragswert signifikant ändern

Als „neue Projektauftragsversion“ im PM-SMART anzulegen und sinngemäß sind die Abläufe der Einplanung im PM-SMART einzuhalten (PSP- Leistung, Kosten, Erlös, Termine, Mitteilung an PMA…

22

Inbetriebnahme:

Vorarbeiten: Bestandsdokumentation 1-fach Die jeweilige Fachabteilung, bzw. der jeweilige Lieferant erstellt 1 Exemplar der Bestandsdokumentation als Basisunterlagen für die Inbetriebnahme. Der Projektleiter fasst diese Dokumente zusammen und leitet diese an das Inbetriebsetzungsteam weiter Das jeweilige Montageteam (PMA) wickelt vertragsgemäß die Inbetriebnahme der Anlage ab. Dabei sind alle Tätigkeiten, besondere Vorfälle, Stillstandzeiten oder Regiearbeiten in Form von Tagesberichten zu dokumentieren. Nach Beendigung der Inbetriebnahme meldet der PL die Anlage fertig zur Abnahme beim Kunden an.

Abnahme/Übergabe erfolgt schriftlich mittels Übernahme/Übergabeprotokoll

oder durch unterschriebene Lieferscheine.

Erstellung von Attesten, Überprüfungsprotokoll, Messprotokollen, CE- Kennzeichnung, Prüfbücher lt. Erfordernis

Sind Mängel vorhanden die eine Übernahme verhindern so sind weiterführende Maßnahmen in einem

PL, PMA,BAUL

Seite 85 von 87

Problemfeld zu definieren

23

Kaufmännische Abschlussarbeiten:

Aufbereitung bzw. Erstellung von Rechnungs- Konzepten: Der PL ist für die laufende und frühzeitige Projektabrechnung verantwortlich. Zur Aufbereitung der Detailunterlagen kann er sich der jeweiligen Fachabteilung bedienen:

- Aufmasslisten MONT, BAUL

- Stücklisten CAD, SAB

- Einkaufslisten EK

Sind Leerformulare erforderlich, hat diese der PL zur Verfügung zu stellen. Die Zusammenführung und Auswertung zu einem Rechnungskonzept und schlussendlich zu einer Schlussrechnung die zu RW weitergeleitet wird, erfolgt in Verantwortung des PL durch die(den) PMK

Fertigstellungsmeldung/“Ansuchen um Abnahme“: Ist die Anlage fertig gestellt, die Anlagenbeschriftung erfolgt und die Enddokumentation erstellt, erstellt der PL die Fertigstellungsmeldung und leitet diese an den Kunden weiter

ANMERKUNG:

Forcieren von Teilabnahmen: Vorwiegend aus Gewährleistungs-, jedoch auch aus Bilanztechnischen Gründen, sind Teilabnahmen mit anteiliger Teilschlussrechnung und anteiligem Haftungsübergang an den Kunden zu forcieren. Besonders wenn das Projekt mehrere Bauetappen oder Baustufen enthält, bzw. Teile der Anlage bereits während der Bauphase frühzeitig in Betrieb genommen werden sollen ist diese Vorgangsweise umzusetzen

Bearbeitung Mängelliste:

Diese ist im PM-SMART zu verwalten und terminlich/Kostenmäßig zu berücksichtigen

PL, PMK Richtlinien Rechnungsleg.

P07_5_01

Seite 86 von 87

24

Nachkalkulation, Projektnachbesprechung:

Bei Fertigstellung der Anlage hat der Projektleiter die aktuelle Kalkulation des Projekts im PM-SMART (ERP) auszuwerten. Entsprechende Abweichungen zu den geplanten (erwarteten) Zielen sind im Zuge der Projektnachbesprechung zu analysieren und bei Bedarf entsprechende, nachhaltige Maßnahmen umzusetzen (verantwortlich SGFL)

Ein umfassendes Abschlussteammeeting mit PAG erfolgt bei Projekten ü. 100.000€ o. bei Abwicklung als komplexes Projekt unter Verwendung der Vorlagen im PM-Smart Projektabschluß.

Das Projekt wird nach Freigabe d. PAG sowohl im PM-SMART u. im ERP abgeschlossen.

Abstimmung eventueller Garantien: Ist eine Haftrücklassgarantie vorgesehen, bzw, ist eine vorher gelegte Erfüllungs- oder Anzahlungsgarantie noch offen, so sind diese mit dem Kunden über Höhe, Laufzeit, Begünstigten, etc. abzustimmen und entsprechend anzufordern. Werkhaftbriefe (Konzernhaftbriefe) sind aus Kostengründen zu forcieren

Übergabe an Bereich Service:

Übermittlung der Projektdaten (Doku) an Service BL

PL

Arbeitsanw.

Abschluss- arbeiten

A04_7_08

F04_7_04

Seite 87 von 87

10.7 Bewertungsmatrix