Projektmanagement fur Unternehmensberatungen: Mit Beispielen aus dem Inhouse Consulting von Deutsche Post World Net

Christoph Wegmann/Holger Winklbauer Projektmanagement für Unternehmensberatungen Christoph Wegmann/Holger Winklbauer ...

Author: Christoph Wegmann | Holger Winklbauer

129 downloads 752 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Christoph Wegmann/Holger Winklbauer Projektmanagement für Unternehmensberatungen

Christoph Wegmann/Holger Winklbauer

Projektmanagement für Unternehmensberatungen Mit Beispielen aus dem Inhouse Consulting von Deutsche Post World Net

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

1. Auflage September 2006 Alle Rechte vorbehalten © Betriebswirtschaftlicher Verlag Dr. Th. Gabler | GWV Fachverlage GmbH, Wiesbaden 2006 Lektorat: Ulrike M. Vetter Der Gabler Verlag ist ein Unternehmen von Springer Science+Business Media. www.gabler.de Das Werk einschließlich aller seiner T Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: Nina Faber de.sign, Wiesbaden Druck und buchbinderische Verarbeitung: Wilhelm & Adam, Heusenstamm Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN-10 3-8349-0295-0 ISBN-13 978-3-8349-0295-5

Vorwort

5

Vorwort

Das vorliegende Buch hat zum Ziel, praktische, fundierte und systematische Hilfestellungen für das Projektmanagement von Managementberatungen zu geben. Dabei konnte ich auf zwei Hauptquellen meiner persönlichen Erfahrung zurückgreifen. Zum einen ist dies das Konzept meiner Lehrveranstaltung „Projektmanagement“ an der Hochschule für Angewandte Wissenschaften in Hamburg. Zum anderen basiert das Buch auf dem in der Praxis vielfach erprobten Projektmanagementkonzept des Inhouse Consultings von Deutsche Post World Net, bei der ich als Projektleiter einige Jahre tätig war. Durch diese Kombination aus Praxis und Hochschule sollen Fundierung, Branchen- und Praxisorientierung sichergestellt werden. Entsprechend richtet sich das Buch auch an zwei Zielgruppen. Zum einen sind dies Studierende, die sich im Rahmen des Studiums mit Projektmanagement oder Managementberatungen auseinander setzen. Zu den Techniken des Projektmanagements, aber auch zur reinen Information über das Berufsfeld Managementberatung kann dieses Buch meines Erachtens einen Beitrag leisten, denn es zeigt einige Facetten der Arbeit in einem Beratungsunternehmen auf. Die zweite Zielgruppe sind Projektleiter und Projektmitarbeiter, die sich über das Projektmanagement von Managementberatungen „weiterbilden“ möchten. Durch die Beispiele aus der Beraterpraxis können auch diese Praktiker dem Buch hoffentlich einige neue Anregungen entnehmen. Der Dank gilt dem Inhouse Consulting für die Erlaubnis, den Common Consulting Approach in diese Publikation einfließen zu lassen. Gedankt sei aber auch den Studenten der Hochschule für Angewandte Wissenschaften, die durch kritisches Hinterfragen in der Lehrveranstaltung wichtige Impulse für dieses Buch gegeben haben. Zudem möchte ich Herrn Prof. Dr. Germanus Wegmann für die kritische Durchsicht des Manuskriptes danken. Ein Hinweis sei noch zu den Formulierungen in männlicher Form gemacht. Es wurde darauf verzichtet, jeweils die männliche und weibliche Form aufzuführen. „Die Managementberater und die Managementberaterinnen“ schien mir den Lesefluss doch zu sehr einzuschränken, weshalb wir uns auf die umgangssprachlich männliche Form beschränkt haben. Die Leserinnen mögen mir diese fälschliche Vereinfachung hoffentlich nachsehen.

Reinbek im Juli 2006

Christoph Wegmann

6

Vorwort

Vorwort

7

Vorwort

Die Fähigkeit zu gutem Projektmanagement ist für Managementberatungen eine der Kernqualifikationen. Schließlich besteht das Hauptprodukt von Beratungsunternehmen in der erfolgreichen Durchführung von Projekten. Um einen hohen Standard hierfür zu gewährleisten, hat das Inhouse Consulting von Deutsche Post World Net einen eigenen Projektmanagementansatz, den Common Consulting Approach, entwickelt. Das Inhouse Consulting ist die interne Managementberatung der Deutschen Post und hat seit 1999 eine Vielzahl von strategischen Projekten im In- und Ausland für die Deutsche Post durchgeführt. Inzwischen arbeiten, aus 3 Büros heraus, über 110 Berater im Inhouse Consulting – mit weiter steigender Tendenz. Aufgrund des Wachstums und der Internationalisierung der Beratung ist eine effiziente Projektsteuerung für den Erfolg des Inhouse Consultings wesentlich. Der Common Consulting Approach ist hierbei das zentrale Instrument, um eine gleichmäßig hohe Qualität im Projektmanagement zu gewährleisten. Im Rahmen eines viertägigen Trainingsblocks werden die Berater des Inhouse Consultings in der Anwendung geschult. Wir freuen uns, mit diesem Buch einige Elemente des Common Consulting Approaches der Öffentlichkeit zugänglich zu machen. Eine durchgängige Darstellung des Gesamtansatzes würde den Rahmen eines Buches sprengen. Insofern freuen wir uns, dass es in die Darstellung des Projektmanagements für Managementberatungen aufgenommen wurde. Auf diese Weise ist eine allgemein verständliche und mit Hintergrundinformationen versehene Darstellung entstanden. Gedankt sei den vielen Beratern des Inhouse Consultings, die über „Beratergenerationen“ hinweg den Common Consulting Approach entwickelt und über die Anwendung getestet haben. Zusätzlich möchte ich mich auch bei dem Support-Team des Inhouse Consultings für ihre engagierte Unterstützung bei der Finalisierung des Buches bedanken.

Bonn im Juli 2006

Holger Winklbauer, Geschäftsführer Deutsche Post World Net Business Consulting GmbH

8

Vorwort

Inhaltsverzeichnis

9

Inhaltsverzeichnis

Abbildungsverzeichnis ........................................................................................................... 13 Verzeichnis der Praxisboxen................................................................................................... 17 Abkürzungsverzeichnis .......................................................................................................... 19

1 Managementberatungen und Projekte ..................................... 21 1.1 Managementberatungen................................................................................................. 21 1.2 Interne Managementberatungen .................................................................................... 27 1.3 Was ist ein Projekt? ....................................................................................................... 29 1.4 Projektmanagement ....................................................................................................... 35 1.5 Besonderheiten bei Projekten in Managementberatungen ............................................. 40 1.6 Welche Projektphasen gibt es? ...................................................................................... 44

2 Akquisephase........................................................................... 51 2.1 Grundlagen der Projektakquisition in Managementberatungen..................................... 51 2.2 Vorbereitung der Projektakquisition .............................................................................. 52 2.3 Ablauf der Akquise........................................................................................................ 55 2.4 Projektangebot und Vertragsgestaltung.......................................................................... 56 2.4.1 Inhalte eines Angebots ....................................................................................... 56 2.4.2 Vertragsgrundlage .............................................................................................. 60

10

Inhaltsverzeichnis

3 Projektplanung..........................................................................73 3.1 Zielfindung.....................................................................................................................75 3.2 Projektstruktur (Work Breakdown Structure).................................................................81 3.3 Zeitplanung mit Netzplänen ...........................................................................................90 3.3.1 Grundlagen zu Netzplänen .................................................................................91 3.3.2 Netzplanerstellung und -analyse ........................................................................94 3.3.3 Zeitpläne kommunizieren.................................................................................105 3.4 Ressourcenplanung ......................................................................................................108 3.4.1 Bedeutung der Ressourcenplanung ..................................................................108 3.4.2 Planung der Personalressourcen ....................................................................... 110 3.5 Kostenplanung .............................................................................................................121 3.5.1 Sichtweisen auf Projektkosten in der Managementberatung ............................121 3.5.2 Entwicklung eines Projektbudgets ...................................................................125 3.6 Risikomanagement.......................................................................................................129

4 Projektorganisation .................................................................137 4.1 Aufbauorganisation im Projekt ....................................................................................137 4.1.1 Lenkungsausschuss ..........................................................................................143 4.1.2 Steuerkreis........................................................................................................146 4.1.3 Kernteam (Projektgruppen)..............................................................................148 4.1.4 Projektleiter......................................................................................................150 4.1.5 Projektbüro bzw. Programmbüro .....................................................................153 4.2 Projektorganisation bei Einsatz von Beratern ..............................................................155 4.3 Eingliederung des Projektes in die Unternehmensorganisation ...................................158 4.4 Stakeholder ..................................................................................................................166

5 Projektcontrolling ....................................................................175 5.1 Einhaltung des Kosten-Budgets ...................................................................................182 5.2 Einhaltung des Personaleinsatz-Plans ..........................................................................186

Inhaltsverzeichnis

11

5.3 Einhaltung des Zeitplans ............................................................................................. 189 5.4 Erreichung des Ergebnisses (Qualitätskontrolle) ......................................................... 192

6 Mitarbeiterführung im Projekt ................................................. 195 6.1 Personalbeurteilung ..................................................................................................... 196 6.2 Kommunikation........................................................................................................... 207 6.2.1 Informelle Kommunikation ............................................................................. 209 6.2.2 Formelle Kommunikation................................................................................ 211 6.3 Personalmotivation ...................................................................................................... 219 6.4 Zusammenarbeit im Projekt......................................................................................... 222 6.4.1 Konflikte bei Beratungsprojekten .................................................................... 223 6.4.2 Konfliktmanagement ....................................................................................... 228 6.4.3 Transaktionsanalyse zur Erkennung und Lösung von Konflikten.................... 233 6.4.4 Teambildung in der Managementberatung....................................................... 240

7 Projektabschluss .................................................................... 245 Literaturverzeichnis.............................................................................................................. 255 Die Autoren .......................................................................................................................... 261

12

Inhaltsverzeichnis

Abbildungsverzeichnis

13


Abbildung 1:

Rollen von Managementberatern .............................................................. 23

Abbildung 2:

Das „magische“ Dreieck des Projektmanagements................................... 32

Abbildung 3:

Typologisierung für Managementberaterprojekte ..................................... 34

Abbildung 4:

Internationaler Vergleich der Effektivität des FuE-Projektmanagements am Beispiel der Automobilindustrie.......................................................... 37

Abbildung 5:

Gründe für den Projekterfolg/-misserfolg ................................................. 38

Abbildung 6:

Charakteristika von Projekten in der Managementberatung ..................... 41

Abbildung 7:

Idealtypischer Phasenablauf eines Projektes............................................. 44

Abbildung 8:

Der Common Consulting Approach.......................................................... 48

Abbildung 9:

Project Success Factors (Projekt-Erfolgsfaktoren).................................... 49

Abbildung 10:

Standardanschreiben zum Angebot des Inhouse Consultings ................... 63

Abbildung 11:

Titelblatt Angebotsmaster ......................................................................... 64

Abbildung 12:

Struktur Angebotsmaster........................................................................... 65

Abbildung 13:

Ausgangssituation und Projektziel im Angebotsmaster ............................ 66

Abbildung 14:

Beschreibung von Aufgaben und Vorgehensweise im Angebotsmaster .... 67

Abbildung 15:

Zeitplan im Aufgabenmaster..................................................................... 68

Abbildung 16:

Projektorganisation im Angebotsmaster.................................................... 69

Abbildung 17:

Beschreibung von Projektrisiken im Angebotsmaster............................... 70

Abbildung 18:

Motivationschart Change Request ............................................................ 71

Abbildung 19:

Change Request Template (Teil 1) ............................................................ 72

Abbildung 20:

Change Request Template (Teil 2) ............................................................ 72

Abbildung 21:

Planungsschritte im CCA.......................................................................... 74

Abbildung 22:

SMART-Prinzip ........................................................................................ 77

Abbildung 23:

Gut und schlecht operationalisierte Ziele.................................................. 77

14


Abbildung 24:

Strukturbeispiel für eine Zielhierarchie .....................................................78

Abbildung 25:

Zielhierarchie am Beispiel Kundenservice................................................79

Abbildung 26:

Context Model...........................................................................................81

Abbildung 27:

Schrittweises Vorgehen bei der Aufstellung eines Strukturplans...............83

Abbildung 28:

Projektstruktur-Darstellung als Organigramm...........................................86

Abbildung 29:

Projektstruktur-Darstellung als Liste/Gliederung ......................................87

Abbildung 30:

Projektstruktur als Cluster-Darstellung .....................................................87

Abbildung 31:

Hypothesis Approach ................................................................................89

Abbildung 32:

Beispiel Hypothesis Approach ..................................................................90

Abbildung 33:

Beispiel für die Symbolik eines Vorgangspfeil-Netzplans.........................93

Abbildung 34:

Symbolik von Vorgangsknoten-Netzplänen ..............................................94

Abbildung 35:

Beispiel für einen Vorgangsknoten-Netzplan ............................................96

Abbildung 36:

Projektstruktur als Cluster-Darstellung .....................................................97

Abbildung 37:

Rangfolge der Arbeitspakete einer Projektstruktur....................................98

Abbildung 38:

Beispiel eines Vorgangsknoten-Netzplans.................................................98

Abbildung 39:

Früheste Anfangs- und Endzeitpunkte.......................................................99

Abbildung 40:

Späteste Anfangs- und Endzeitpunkte .....................................................100

Abbildung 41:

Berechnung Pufferzeiten .........................................................................101

Abbildung 42:

Ein Vorgang in der Präzendenzdarstellung ..............................................102

Abbildung 43:

Beispielnetzplan in Präzedenzdarstellung ...............................................103

Abbildung 44:

Schlüsselereignis-Bericht ........................................................................106

Abbildung 45:

Beispiel für einen Vorgangsbericht..........................................................107

Abbildung 46:

Beispiel für ein Gantt-Diagramm ............................................................108

Abbildung 47:

Beispiel für eine Stellenbeschreibung .....................................................113

Abbildung 48:

Project Resource Requirements...............................................................115

Abbildung 49:

Graphic Resource Plan ............................................................................116

Abbildung 50:

Beispiel für ein Gantt-Diagramm ............................................................117

Abbildung 51:

Personenspezifisches Gantt-Diagramm für Wegmann ............................117

Abbildung 52:

Personenspezifisches Gantt-Diagramm für Müller..................................118


15

Abbildung 53:

Personenbezogenes Gantt-Diagramm zur Kapazitätsüberwachung (Ist-Daten)............................................................................................... 120

Abbildung 54:

Beispiel für ein Arbeitslastdiagramm eines Mitarbeiters ........................ 120

Abbildung 55:

Sichtweisen auf Projektkosten und deren Bedeutung für klassische Beratungsprojekte ................................................................................... 125

Abbildung 56:

Vorgehen zur Erstellung eines Projektbudgets ........................................ 127

Abbildung 57:

Spannungsfeld bei Einrichtung einer Projektkostenstelle ....................... 128

Abbildung 58:

Risiko-Matrix mit Risikoklassen ............................................................ 132

Abbildung 59:

Risikomanagement-Plan zur Risikobeherrschung................................... 136

Abbildung 60:

Zusammenhang von Unternehmens-, Projekt- und Managementberatungsorganisation......................................................... 138

Abbildung 61:

IBZED-Schema zur Regelung von Aufgaben in der Organisation.......... 140

Abbildung 62:

IBZED-Schema zur Regelung von Aufgaben in der Organisation.......... 141

Abbildung 63:

Beispiel für eine einfache IBZED-Tabelle .............................................. 142

Abbildung 64:

Beispiel für eine Projektorganisation ...................................................... 143

Abbildung 65:

Anforderungsprofil an einen Projektmanager (idealtypisch) .................. 152

Abbildung 66:

Karrierestufen im Inhouse Consulting .................................................... 157

Abbildung 67:

Beispielhafte Darstellung einer Matrix-Projektorganisation ................... 162

Abbildung 68:

Grobe Kompetenzabgrenzung in der Matrix-Projektorganisation .......... 163

Abbildung 69:

Beispiel für einen Wechsel der Projektorganisation während des Projektablaufs ......................................................................................... 165

Abbildung 70:

Stakeholder-Map für Projekte ................................................................. 169

Abbildung 71:

Stakeholder-Rollen auf der Stakeholder-Map ......................................... 170

Abbildung 72:

Tabelle zur Stakeholder-Map (Beispiel).................................................. 171

Abbildung 73:

Basisklassifikation im Stakeholdermanagement ..................................... 172

Abbildung 74:

Stakeholdermanagement-Tabelle ............................................................ 174

Abbildung 75:

Beispiel Projektstatusbericht................................................................... 180

Abbildung 76:

Einfacher Plan-Ist-Vergleich ................................................................... 183

Abbildung 77:

Plan-Ist-Vergleich mit Forecast............................................................... 184

Abbildung 78:

Beispiel für einen grafischen Plan-Ist-Vergleich mit Forecast ................ 186

16


Abbildung 79:

Arbeitsbelastungsdiagramm mit Überlastung..........................................187

Abbildung 80:

Arbeitsbelastungsdiagramm Plan-Ist-Vergleich ......................................187

Abbildung 81:

Beispiel für eine Übersicht zum Projektstatus.........................................190

Abbildung 82:

Ist-Plan-Gegenüberstellung .....................................................................191

Abbildung 83:

Beispiel Meilenstein-Trendanalyse .........................................................192

Abbildung 84:

Mitarbeiter, die bei Projekten beurteilt werden können...........................200

Abbildung 85:

Personalbeurteilungs- und Feedbacksystem des Inhouse Consultings von Deutsche Post World Net..................................................................205

Abbildung 86:

Kommunikationsarten im Projektmanagement .......................................209

Abbildung 87:

Beispiel für eine Übersicht zur Projekt-Kommunikationsstruktur ..........217

Abbildung 88:

Ziele und Teilnehmer eines Kick-off-Meetings .......................................218

Abbildung 89:

Ziele und Teilnehmer eines Kick-off-Meetings .......................................219

Abbildung 90:

Beziehungs- und Sachebene von Konflikten ...........................................224

Abbildung 91:

Konfliktpotenzial aufgrund der Beratungssituation.................................226

Abbildung 92:

Konfliktreduktion in Beratungsprojekten ................................................227

Abbildung 93:

Strategien der Konfliktbewältigung.........................................................231

Abbildung 94:

Die drei Ich-Zustände der Transaktionsanalyse.......................................234

Abbildung 95:

Beispiele für Aussagen, die den Ich-Zuständen entsprechen...................235

Abbildung 96:

Konfliktfreie Kommunikation .................................................................236

Abbildung 97:

Konfliktfreie Kommunikation zwischen Eltern- und Kind-Ich ...............236

Abbildung 98:

Konflikte in der Kommunikation ............................................................237

Abbildung 99:

Kundenbefragung (Auszug) ....................................................................249

Abbildung 100:

Ziele des Wissensmanagements ..............................................................251

Abbildung 101:

Projektordner-Struktur.............................................................................253

Verzeichnis der Praxisboxen

17


Praxisbox 1:

Beispiel für ein Programm: STAR von Deutsche Post World Net ............ 33

Praxisbox 2:

Anforderungen an Projekte ....................................................................... 38

Praxisbox 3:

Der Common Consulting Approach.......................................................... 47

Praxisbox 4:

Buying-Center........................................................................................... 54

Praxisbox 5:

Angebotsmaster (Auszug)......................................................................... 62

Praxisbox 6:

Change Request ........................................................................................ 71

Praxisbox 7:

Planungsschritte ........................................................................................ 74

Praxisbox 8:

Das SMART-Prinzip ................................................................................. 76

Praxisbox 9:

Context Model .......................................................................................... 80

Praxisbox 10:

Hypothesis Approach ................................................................................ 88

Praxisbox 11:

Stellenbeschreibung für fachseitigen Projektmitarbeiter......................... 112

Praxisbox 12:

Personalkapazitätsplanung ...................................................................... 115

Praxisbox 13:

Personenbezogene Kapazitätserfassung.................................................. 119

Praxisbox 14:

Risikomanagement-Plan ......................................................................... 135

Praxisbox 15:

Der IBZED-Code zur Aufgabenbeschreibung in Organisationen ........... 140

Praxisbox 16:

Programmorganisation bei STAR ........................................................... 154

Praxisbox 17:

Die Organisation von Managementberatungen ....................................... 157

Praxisbox 18:

Stakeholdermanagement ......................................................................... 172

Praxisbox 19:

Projektstatusbericht................................................................................. 177

Praxisbox 20:

Reporting des Projektfortschritts ............................................................ 189

Praxisbox 21:

Plan-Ist-Vergleich ................................................................................... 190

Praxisbox 22:

Personalbeurteilungs- und Feedbacksystem............................................ 203

Praxisbox 23:

Assessment Center als Sonderform der Personalbeurteilung .................. 206

18


Praxisbox 24:

Förderung informeller Kommunikation ..................................................210

Praxisbox 25:

Kick-off-Meeting.....................................................................................217

Praxisbox 26:

Teambildung............................................................................................243

Praxisbox 27:

Kundenbefragung ....................................................................................248

Praxisbox 28:

Wissensmanagement ...............................................................................253

Abkürzungsverzeichnis

Abkürzungsverzeichnis

AsPac

Region Asia/Pacific

CCA

Common Consulting Approach

DPWN

Deutsche Post World Net

FAZ

früheste Anfangszeit

FEZ

früheste Endzeit

FTE

Full Time Equivalents

IC

Inhouse Consulting

MBA

Master of Business and Administration

PDA

Personal Digital Assistant

PL

Projektleiter

PM

Projektmanager

PMIS

Projektmanagement-Informationssystem

PT

Personentage

RWP

Rolling Wave Planning

SAZ

späteste Anfangszeit

SEZ

späteste Endzeit

WBS

Work Breakdown Structure

WIP

Work in Progress

19

Managementberatungen

21

1 Managementberatungen und Projekte

1.1


Heutzutage gibt es kaum ein Unternehmen, das ohne die Hilfe von Managementberatungen auskommt. Neben den Industrieunternehmen, die schon lange als Auftraggeber für Managementberatungen bekannt sind, lassen sich heute auch die Non-Profit-Unternehmen, wie die Bundeswehr oder die katholische Kirche, beraten (Mester/Zamponi 2004). Allein der Managementberatungsmarktführer McKinsey berät 45 der deutschen Top-100-Unternehmen (o. V. 2004a). Die großen Namen der Beratungsbrache sind inzwischen wohl bekannt: McKinsey, Boston Consulting Group, Roland Berger, Droege & Company, A.T. Kearney, Arthur D. Little, Booz Allen Hamilton, Bain & Company, Accenture und Mercer, um nur die bekanntesten zu nennen (Höselbarth 2005). Das Beratungsgeschäft hat hierbei ein beträchtliches Ausmaß erreicht. Allein in Deutschland beschäftigen McKinsey beispielsweise über 1.700 und Roland Berger über 1.600 Mitarbeiter (Lündendonk 2005). Die Umsätze der großen Beratungsunternehmen liegen im dreistelligen Millionen-Euro-Bereich. Insgesamt hat die Branche nach Angaben des Bundes Deutscher Unternehmensberater 2005 einen Umsatz von über 13 Mrd. Euro in Deutschland getätigt (BDU 2006). Und trotz aller geäußerter Kritik an den Leistungen der Beratungen sind 98 % der Unternehmen der Meinung, ohne Unternehmensberatungen nicht auskommen zu können (Fink 2004). Das Projektmanagement der Managementberatungen ist dabei kein nationales Geschäft mehr. Marktführend sind internationale Beratungsunternehmen, und selbst das deutsche Unternehmen Roland Berger unterhält inzwischen ein internationales Netzwerk mit 34 Büros in 24 Ländern (o. V. 2004b). Auch gilt die erfolgreiche Arbeit in einer der großen Unternehmensberatung für Berufseinsteiger als ein Sprungbrett zu Leitungsfunktionen und ist von daher sehr attraktiv. Die Mitarbeiter der Beratungen werden in verschiedenen Funktionen eingesetzt und lernen so schnell unterschiedliche Sichtweisen und Aufgaben kennen (Nöcker 2005). Da die Beratungen den Auftraggebern einen Mehrwert liefern müssen, besteht zudem ein sehr kompetitives Umfeld, welches für die Berater ebenfalls als „gute Schule“ angesehen wird. Und nicht zuletzt sind die hohen Anforderungen bekannt, die die großen Managementberatungen an ihre Mitarbeiter

22

Managementberatungen und Projekte

stellen. Ein Bewerber, der durch das Auswahlverfahren einer Beratung gekommen ist, genießt von daher zunächst einmal oft einen Ansehensbonus. Was aber genau sind Managementberatungen? In der Praxis und Literatur gibt es eine Reihe von Begriffen, die nebeneinander gebraucht werden. Oft geben diese gleich den Inhalt der Beratungsleistung in ihrem Namen an, etwa wie bei IT-Beratungen, Personalberatungen etc. Bei den allgemeineren Begriffen finden in der Hauptsache zwei Worte Verwendung: Unternehmensberatung Managementberatung In der Literatur gibt es viele divergierende Versuche, den Begriff „Unternehmensberatung“ zu definieren (Elfgen/Klaile 1987, S. 21). Elfgen/Klein definieren: „Unternehmensberatung ist die von externen Personen bereitgestellte, individuell gestaltete Hilfe bei der Identifizierung und Lösung von betriebswirtschaftlichen Problemen des Unternehmensgeschehens (…), die auf einer ganzheitlichen Problemsicht beruht und durch Eigenverantwortlichkeit gekennzeichnet ist. Die Erarbeitung der Problemlösung erfolgt im Rahmen eines interaktiven Prozesses.“ Unternehmensberatung erfolgt durch Unternehmensberater, die eigenständig (aber in Kooperation) Probleme für Unternehmen lösen. Laut Lexikon ist ein Unternehmensberater entsprechend ein Dienstleister, der u. a. dem Management als Experte für Problemlösungen in speziellen Aufgabenbereichen zur Seite steht (o. V. 2004c). Der Begriff „Managementberatung“ spezifiziert dies weiter. Hier bezieht sich die Beratung ausschließlich auf das Management, d. h. auf die Leitungsfunktion eines Unternehmens. Dies können dann Beratungsaufgaben sein, die die Unternehmenskultur, Strategie, Organisation, Verfahren und Methoden des Unternehmens des Auftraggebers betreffen. In diesem Rahmen können Problemlösungen erarbeitet, geplant und realisiert werden (Niedereichholz 1996, S. 1). Inhaltlich geht es bei der Managementberatung entsprechend um Unterstützung als Experte bei konkreten Managementaufgaben. Beispiele sind: Aufstellung von Business Plänen Ausarbeitung von Strategien Ermittlung von Marktchancen Ermittlung von Kostensenkungspotenzialen Entwicklung von Organisationsstrukturen Unterstützung bei Reorganisationsprozessen Einführung neuer Controlling-Systeme Aufbau von neuen Unternehmensbereichen Planung und Steuerung von Projekten


23

Turnaround Management bei Verlustsituation Merger Integration/Change Management Schlanke Organisationen sind in der Regel auf das andauernde Tagesgeschäft ausgerichtet. Einzelne Sonderaufgaben, die singulär auftreten und Spezialwissen erfordern, lassen sich so häufig nicht abbilden. Die Gründe für den Einsatz von Managementberatungen sind dabei vielfältig. Diese gehen von fehlendem Fachwissen beim Auftraggeber, fehlendem Projektmanagement-Know-how, mangelnden eigenen Ressourcen für die selbständige Durchführung der Aufgabe bis hin zu Gutachterfunktion oder im negativen Falle sogar Alibi-Funktion. In der Regel führen Berater dabei Aufgaben durch, die außerhalb der Regelaufgaben des Managements liegen und für die ein bestimmtes Know-how und ein bestimmter Zeitaufwand notwendig sind. Nicht immer werden hierbei vollkommen neue Gedanken und Ideen entwickelt, sondern zum Teil wird nur bestätigt und geprüft, was an Veränderungsideen bereits bestand. In diesem Falle kommt einer Beratung dann insbesondere die Aufgabe zu, eine Art Katalysator für den Wandel zu sein. Abbildung 1 fasst die sich aus diesen Aufgaben ergebenden Beraterrollen zusammen.

Berater als neutraler Gutachter

Berater als Fachexperte

Berater als Projektmanager

Rollen von Managementberatern

Berater zur Kapazitätserweiterung Abbildung 1:

Berater als Verantwortlicher

Berater als Katalysator des Wandels

Rollen von Managementberatern

Der Berater als Fachexperte ist hierbei derjenige, der aufgrund seines Fachwissens (oder der Fähigkeit, sich dies schnell aneignen zu können oder darauf innerhalb der Beratung zurückgreifen zu können) engagiert wird. Er entwickelt eigenständig oder in Zusammenarbeit mit Mitarbeitern des Auftraggebers neue Problemlösungen, für die sein Spezialwissen notwendig ist. Ein Beispiel hierfür ist die Entwicklung von Markteintrittsstrategien für bisher nicht bearbeitete Märkte oder die Entwicklung eines Controllingsystems. Hierfür ist dann bisher nicht

24


im beratenen Unternehmen vorhandenes Fachwissen über die Märkte oder Controllingkennzahlen (Key performance indicators) oder die notwendigen IT-Systeme notwendig. Der Berater als Projektmanager ist streng genommen auch ein Fachexperte – sein Fachgebiet ist hierbei das Projektmanagement. Da dies eine der klassischen Kernkompetenzen aller Beratungen sein sollte, ist dies hier als eigene Rolle aufgeführt. Ein Berater in dieser Rolle initiiert, plant und steuert große und komplexe Projekte für das Klientenunternehmen. Projektmitarbeiter können hierbei sowohl Mitarbeiter des beratenen wie auch des beratenden Unternehmens sein. Die Aufgabe des Beraters besteht in erster Linie darin, durch gutes Projektmanagement die erfolgreiche Durchführung des Projektes sicherzustellen. Hierbei kann es sich um sämtliche Arten von Projekten handeln. Dies müssen nicht immer reine Managementprojekte sein, sondern es kann sich auch um Implementierungsprojekte handeln. Der Berater in der Rolle der personellen Kapazitätserweiterung übernimmt Aufgaben für den Auftraggeber, die dieser aufgrund der in Regelaufgaben gebundenen Personal- und sonstigen Ressourcen nicht mehr durchführen kann. Zwar wäre der Auftraggeber fachlich in der Lage, die Aufgaben selbst durchführen zu können, aber seine Mitarbeiter haben einfach keine Zeit hierfür. Die Berater in dieser Rolle sind insofern kritisch zu beurteilen, da sie keine Projekte, sondern Regelaufgaben des Unternehmens durchführen. Ihr spezifisches Know-how für Beratungsprojekte wird nicht benötigt, und die Berater werden faktisch aus der Beratungsorganisation herausgelöst und in das beratene Unternehmen eingegliedert, was für diese natürlich kritisch ist. Der Berater in der Rolle als neutraler Gutachter wird dann beauftragt, wenn ein Auftraggeber eine unabhängige Meinung zu möglichen Lösungen von Problemen benötigt. Die möglichen Problemlösungen liegen in diesem Fall schon vor und müssen bewertet werden. D. h., die Hauptaufgabe des Beraters liegt darin, eine begründete Expertenempfehlung abzugeben, wobei der Fokus hier auf der Unabhängigkeit des Beraters bei der Empfehlung liegt. Ähnlich ist die Rolle des Beraters als Verantwortlicher gelagert. Hier wird der Berater letztendlich als „Überbringer einer schlechten Nachricht“ engagiert. Dies hört sich zunächst einmal etwas merkwürdig an, da das Management, das den Berater beauftragt, sich ja quasi hinter dem Berater versteckt. Könnte das Management die Rolle auch selbst übernehmen, ist es in der Tat fraglich, ob ein Beratereinsatz lohnt. In manchen Fällen ist es aber dennoch sinnvoll, einen Berater in dieser Rolle einzusetzen. Dies ist dann der Fall, wenn die Akzeptanz eines notwendigen Einschnittes größer ist, wenn dieser durch einen neutralen Außenstehenden vertreten wird. Zudem kann es nach Beendung des Beratereinsatzes unter Umständen leichter sein, im Unternehmen weiterhin konstruktiv zusammenzuarbeiten, da der für die negativen Entscheidungen Verantwortliche ja nicht mehr da ist. Auf diese Weise könne die anderen Beteiligten im Unternehmen entlastet werden. Dennoch sollte man mit einem Beratereinsatz aus dieser Motivation heraus sehr vorsichtig sein und diese Rolle sollte nie die einzige des Beraters sein. In gewisser Weise nimmt ein Berater schon die Rolle eines „Katalysators des Wandels“ ein. In reiner Ausprägung dieser Rolle hat der Berater die Aufgabe, den Wandel in einem Unternehmen zu unterstützen. Dies kann durch Aufzeigen der Notwendigkeit des Wandels, des


25

Weges zur Umsetzung des Wandels und auch insbesondere durch praktische Unterstützung hierbei erfolgen. In dieser Rolle sind auch insbesondere persönliche und soziale/emotionale Fähigkeiten eines Beraters notwendig. In klassischen „Change-Management-Projekten“ nimmt ein Berater diese Rolle ein. In den verschiedenen Rollen des Beraters sind unterschiedliche Anforderungen an seine Arbeit gestellt. Durch die Unterschiedlichkeit der sich ergebenden Projekte resultiert dies auch in unterschiedlichen Anforderungen an das Projektmanagement und ist – egal welche Rolle ein Berater einnimmt – eine wesentliche Unterstützung seiner Arbeit. Durch die Beratung kann bei der Fachseite eine Abhängigkeit von den eingesetzten Beratern entstehen. Um diese Abhängigkeit zu reduzieren, begrenzen einige Unternehmen den Beratereinsatz auf einen definierten Zeitraum. Zuletzt sei hier noch darauf hingewiesen, dass Managementberatung eine klassische Dienstleistung ist. Es bietet sich daher an, einen besonderen Bezug auf die recht umfangreiche Literatur und Forschung aus dem Bereich des Dienstleistungsmanagement zu nehmen. Eine Dienstleistung ist nach allgemeiner Auffassung durch die konstitutiven Merkmale Intangibilität und Integration des externen Faktors gekennzeichnet (Biermann 1999, S. 22; Übersicht bei Meffert/Bruhn 1997, S. 23 ff.). Intangibilität bedeutet, dass man das Ergebnis oder Produkt der Beratung nicht greifen kann. Zum einen bezieht sich dies auf die physischen Eigenschaften des Ergebnisses. Eine Beratung, d. h. in der Managementberatung oft eine Empfehlung, kann man nicht anfassen. Anders als bei einer Sachleistung, die man in die Hand nehmen kann und deren Eigenschaften mess- und überprüfbar sind. Natürlich kann man einen schriftlichen Endbericht eines Beratungsprojektes in die Hand nehmen, die eigentliche Leistung jedoch besteht aus Informationen, Analysen und Empfehlungen, die nur intellektuell „greibar“ sind. Hentschel (1992, S. 25) weist darauf hin, dass die Intangibilität nicht nur die physische Greifbarkeit des Ergebnisses beschreibt, sondern auch die intellektuelle Greibarkeit. Viele Dienstleistungen sind komplex und für den Nachfrager schwer zu verstehen. Zu nennen sind beispielsweise Finanzdienstleistungen an der Börse, die hoch abstrakt sind. Die Gefahr, dass auch Beratungsprojekte zumindest teilweise intellektuell intangibel sind, ist nicht von der Hand zu weisen. Jedoch besteht die Aufgabe des Beraters darin, das Projekt und dessen Ergebnis für den Kunden so verständlich darzustellen, dass keine „intellektuelle Intangibilität“ der Beratungsleistung eintritt. Der „externe Faktor“ ist der Kunde. Bei der Dienstleistungsproduktion – d. h. in unserem Falle bei der Durchführung eines Beratungsprojekts – muss dieser mit in das Projekt einbezogen werden. Ohne die Mitarbeit des betroffenen Unternehmensteils kann es keine Managementberatung geben. So muss das Unternehmen, das beraten wird, Informationen über Kunden, Produkte, Organisation, Prozesse oder Probleme zur Verfügung stellen, es muss sich zur Umsetzbarkeit von Vorhaben oder Aktivitäten der Vergangenheit äußern etc.

26


Die Intangibilität einer Dienstleistung und Integration des externen Faktors bei der Dienstleistungsproduktion haben Folgen für die Kunden und Anbieter. Unsicherheiten bei den Kunden, die Qualität der Beraterleistung im Vorfeld zu beurteilen. Dies ist bei Managementberatungsprojekten in starkem Maße gegeben, da es in der Regel darum geht, neue Lösungen für Probleme zu finden. Inwieweit dies dann tatsächlich gelingen wird, ist nicht sicher vorherzusagen. Auch wenn später in einem Projekt eine Empfehlung für das Management abgegeben wird, so ist schwer zu beurteilen, inwieweit das Befolgen dieser Empfehlung durch das Management tatsächlich zu den gewünschten Ergebnissen führt. Dies führt zu der großen Herausforderung für das Projektmanagement, die Leistung im Vorfeld für den Kunden so transparent wie möglich zu gestalten und die Qualität des Ergebnisses (der Empfehlung) so weit wie möglich zu sichern. Der Angebotsgestaltung kommt somit bei Beratungsprojekten eine besondere Bedeutung zu. Unmöglichkeit der Vorratsproduktion. Beratungsleistung kann nicht „auf Halde“ produziert werden, sondern muss immer individuell für den Kunden und dessen Situation „angefertigt“ werden. D. h., die Beratungsteams müssen zur Verfügung stehen, wenn das Unternehmen die Problemlösung benötigt und nicht erst ein halbes Jahr später. Dies erfordert eine hohe Flexibilität der Managementberatungen, da Beratungsbedarf zum Teil erst kurzfristig erkannt wird. Eine flexible Personaleinsatzplanung ist notwendig. Managementberatungsprojekte werden meist vor Ort durch die Berater durchgeführt, um Zugriff auf das Unternehmen und die Mitarbeiter zu haben, die beraten werden. Projekte aus der Distanz heraus erschweren diesen Zugriff und gefährden so den Projekterfolg. Berater müssen entsprechend flexibel sein, was den Ort ihrer Projektarbeit angeht. Die notwendige Flexibilität korreliert mit der regionalen Verteilung der Kunden. Die Integration des externen Faktors erfordert auch, dass Projekte oft in gemischten Teams durch Berater und Mitarbeiter des Unternehmens, welches beraten wird, durchgeführt werden. Während die Berater disziplinarisch in die Beratung eingebunden sind, verbleiben die Mitarbeiter des Unternehmens in der Regel in der Linienorganisation des Unternehmens. Eine Projektorganisation muss entsprechend so aufgebaut sein, dass es die Berater und die Mitarbeiter des Unternehmens in einer gemeinsamen Organisation „verbindet“. Die gemeinsame Arbeit am Projektziel muss gewährleistet werden. Weiterhin kann das Beratungsunternehmen nicht genau beeinflussen, in welchem Maße sich das beratene Unternehmen selbst in den Beratungsprozess einbringt. Dies stellt besondere Anforderungen an ein Qualitätsmanagement, das den Fortschritt und die Zusammenarbeit von Beratung und Unternehmen überwachen muss. Außerdem sind in der Definitions- und Planungsphase die Leistungen von Auftraggeber-Unternehmung und Beratungsunternehmen genau festzulegen.

Interne Managementberatungen

1.2

27

Interne Managementberatungen

Dieses Buch stellt das Projektmanagement für Managementberatungen unter Verwendung von vielen Beispielen aus dem Inhouse Consulting von Deutsche Post World Net (Inhouse Consulting) dar. Inhouse Consulting ist eine interne Beratungseinheit. Dies bedeutet, dass die Beratung ausschließlich Projekte im gleichen Unternehmen (oder in Unternehmen, die zur gleichen Unternehmensgruppe gehören) durchführt. Anders als bei externen Beratungen haben letztendlich Berater und Auftraggeber den gleichen Arbeitgeber. Viele große Konzerne etablieren solche interne Beratungen, um ihren Beratungsbedarf nicht ausschließlich durch externe Unternehmensberatungen decken zu müssen. Beispiele sind ABB, Airbus, BMW, Otto-Versand, Volkswagen, Siemens, DaimlerChrysler, Credit Suisse, Michelin oder Deutsche Post World Net. Das Inhouse Consulting von Deutsche Post World Net wurde 1999 gegründet und bestand zu dieser Zeit zunächst aus drei Mitarbeitern, die den Auftrag hatten, Projekte innerhalb des Konzerns Deutsche Post World Net durchzuführen und gleichzeitig eine professionell arbeitende Beratungsorganisation aufzubauen. Heute umfasst das Inhouse Consulting 125 Mitarbeiter, davon 110 Berater (80 Consultants und Senior Consultants, 17 Projektmanager und 13 Partner sowie Associate Partner) sowie 15 Personen im Support-Team. Das Inhouse Consulting ist hierbei weiterhin auf Wachstum ausgerichtet. Projekte wurden und werden aus allen Managementbereichen durchgeführt. Beispiele sind: Einführung eines Corporate Intranets für den Konzern Entwicklung und Durchführung eines Benchmarking-Konzeptes für interne Dienstleister im Konzern Analyse von Marktchancen und Entwicklung von Marketingkonzeptionen für die Internationalisierung des Konzerns Ermittlung und Realisierung von Kostensenkungspotenzialen Integrationsplanung und Change Management bei Unternehmensakquisitionen Entwicklung und Einführung eines Procurement-Systems Die Ziele der Etablierung dieser internen Beratungseinheit waren vielfältig und entsprechen den Zielen, die auch andere Unternehmen mit der Etablierung interner Beratungseinheiten verfolgen: Halten und sammeln von Projekt-Know-how im Konzern, das bei Einsatz von externen Beratern verloren geht, sobald diese das Unternehmen nach Beendigung eines Beratungsprojektes wieder verlassen. Die Abhängigkeit von externen Beratungsfirmen wird durch

28


den Einsatz interner Berater gesenkt und man ist in der Lage, Projekte eigenständig durchzuführen. Wenn nötig, wird nur noch gezielt externe Expertise hinzugekauft. Aufbau eines Wissenspools. Indem immer innerhalb des Konzerns Deutsche Post World Net beraten wird, besteht die Möglichkeit, zentral Wissen über den Konzern zu sammeln. Dies umfasst Wissen über den Aufbau des Konzerns, geeignete Projektvorgehensweisen innerhalb des Konzerns, Absatzmärkte, Produkte, Wettbewerber etc. Durch Rückgriff auf dieses Wissen sollen Projekte schneller gestartet und bessere Ergebnisse erzielt werden können. Es soll sichergestellt werden, dass in Projekten immer die beste Lösung für den Gesamtkonzern gesucht wird – unabhängig von Partikularinteressen einzelner interner Auftraggeber. Dieses aus Sicht des Gesamtkonzerns sinnvolle Ziel kann allerdings für den einzelnen Auftraggeber bedeuten, dass ihm aufgezeigt wird, dass seine Interessen mit denen des Gesamtkonzerns nicht vollständig harmonieren. Der Einsatz in der internen Beratung ist ein idealer Einstieg für besonders qualifizierte Mitarbeiter (High-Potentials) in den Konzern. Der Arbeitsplatz ist abwechselungsreich und fordernd, da im Bereich der Managementberatung häufig strategische Fragestellungen für das Top Management bearbeitet werden. Für Einsteiger kann er daher sehr interessant sein. Bei erfolgreicher Arbeit in der internen Beratung besteht mittelfristig die Möglichkeit, eine Managementposition im Konzern zu erlangen. Insofern dient die interne Beratung als auch Personalakquiseinstrument. Letztendlich erlaubt der Einsatz interner Beratungen die Senkung der mit der Beratung verbundenen Kosten. Die Kosten interner Berater liegen in der Regel unter denen externer Beratungsunternehmen. Selbst wenn interne Beratungen als Profitcenter arbeiten und marktübliche Beratungssätze verrechnet werden, verbleibt der Gewinn im Konzern, so dass ein entsprechender positiver Kosteneffekt insgesamt vorhanden ist. Die beschriebenen Vorteile lassen sich natürlich nur realisieren, wenn eine entsprechende Auslastung der internen Beratung vorliegt, d. h. wenn entsprechender Projektbedarf im Unternehmen vorhanden ist. Anderenfalls besteht die Gefahr, dass eine interne Beratung Projekte um der Projekte willen durchführt, was inhaltlich wie von der Kostenseite her kontraproduktiv ist. Von daher ist es für die interne wie für die externe Beratung wichtig, an wiederholenden Themenkomplexen zu arbeiten, um Synergien zu heben. Die ausschließliche Projektdurchführung durch eine interne Beratung birgt zwei Gefahren. Erstens, dass externe Impulse z. B. von Wettbewerbern oder anderen Branchen fehlen. Zweitens, dass die interne Beratung auf Projekte angesetzt wird, die von der Bedeutung her eine Bearbeitung durch Berater nicht rechtfertigen und eher durch Linienmitarbeiter durchgeführt werden sollten. Es kann ggf. für die Fachseite verlockend sein, interne Berater einzusetzen, anstatt weitere fachseitige Mitarbeiter einzustellen. Diese Probleme können umgangen werden, indem es den internen Auftraggebern freigestellt wird, ob sie ein Projekt selbst oder mit Unterstützung einer externen internen Beratung durch-

Was ist ein Projekt?

29

führen. Immer, wenn dem Auftraggeber externes Know-how wichtig erscheint, kann er hierauf im Rahmen seines Budgets zurückgreifen. Es sollte also keinen Kontrahierungszwang geben; d. h. keine Konzernvorgabe, den internen Serviceprovider für die Leistungserbringung zu beauftragen. So ist sichergestellt, dass externe Beratungen herangezogen werden, wenn dies sinnvoll ist. Und die interne Beratung steht unter dem Zwang, gute Projektarbeit zu leisten, professionelle Strukturen aufzubauen sowie nur sehr gute Mitarbeiter einzustellen und diese qualifiziert zu schulen. Die Leistungsverrechnung der Zusammenarbeit zwischen Fachseite und internen Beratern kann dabei auftragsbezogen oder durch allgemeine Konzernumlage erfolgen. Für eine interne Unternehmensberatung ist es vorteilhaft, die Kosten zu verrechnen. Eine Fachabteilung, die auf die interne Beratung zugreift, muss diese genau wie eine externe Beratung aus ihrem Budget leistungsorientiert bezahlen. Nur so kann sichergestellt werden, dass die Berater ressourceneffizient eingesetzt werden. Das Inhouse Consulting von Deutschen Post World Net ist diesen Gedanken folgend als Tochterunternehmen ausgegliedert und wird als Profit Center geführt. Einen Kontrahierungszwang gibt es nicht, das Inhouse Consulting muss als Beratung genau wie externe Beratungen im Konzern Projekte akquirieren und stellt einen marktüblichen Beratungssatz in Rechnung. Nachfolgend soll ausschließlich auf das Projektmanagement von Managementberatungen (interne und externe) eingegangen werden. Diese Beschränkung erlaubt es, genauer auf die Spezifika der Projekte dieser Beratungen einzugehen.

1.3


Projekte sind keine moderne Erfindung, es gibt sie schon immer. Man denke nur an den Bau der Chinesischen Mauer oder von Stonehenge (vgl. Madauss 1984, S. 10). All diese Projekte waren im Endergebnis ein großer Erfolg. Aber gerade in den letzten Jahren findet Projektmanagement in der Betriebswirtschaftslehre wieder starke Aufmerksamkeit und ist ein aktuelles Thema. Die angebotene Literatur hierzu ist außerordentlich umfangreich. Eine Recherche bei www.amanzon.de ergibt als Ergebnis über 800 Bücher, die sich mit Projektmanagement befassen. In Unternehmen werden die meisten Manager früher oder später auf ein Projektmanagement-Seminar geschickt. Die Zahl der Anbieter für Projektmanagement-Seminare ist entsprechend umfangreich. Die Popularität von Projektmanagement lässt sich dadurch erklären, dass die Anforderungen an Projekte gestiegen sind. Die Erwartungen sind durch den ökonomischen Druck, unter dem Firmen heutzutage stehen, gestiegen. Projekte müssen im geplanten Budget bleiben und die geplanten Zeitrahmen einhalten. Hierbei sind viele Projekte aufgrund der verschachtelten

30


Managementstrukturen und der Größe der Vorhaben sehr komplex. Man denke dabei zum Beispiel an Projekte, wie den Bau des neuen Super-Airbus A380-800 mit tausenden beteiligen Ingenieuren und einer Vielzahl beteiligter Unternehmen. Unternehmen führen Projekte durch, um in vorgegebenen Zeiträumen mit den ihnen zur Verfügung stehenden Ressourcen bestimmte Ergebnisse zu erzielen. So werden in Unternehmen inzwischen fast alle großen Aufgaben im Rahmen von Projekten erledigt. Die Bearbeitung erfolgskritischer Managementthemen wie Innovationsmanagement, IT-Infrastruktur, Markterweiterung, strategische Allianzen, Kostensenkung etc. sind in Großunternehmen so vielgestaltig, dass sie in Form von Projekten abgewickelt werden. Insofern ist das Beherrschen eines guten Projektmanagements eine erfolgskritische Ressource von Unternehmen. Nicht nur ausgebildete und spezialisierte Projektmanager werden mit der Leitung von Projekten betraut, sondern auch „normale“ Abteilungsleiter und Angestellte. Daher ist die Fähigkeit zum Projektmanagement heutzutage eine erforderliche Qualifikation für viele Mitarbeiter in einem Unternehmen. In besonderem Maße gilt dies natürlich für Angestellte in Managementberatungen, da diese fast ausschließlich Projektarbeit durchführen. Für dieses Buch sollen unter Projekten Vorhaben verstanden werden, die folgende Merkmale besitzen (für viele: Litke/Kunow 2002, S. 8-13; Rinza 1998, S. 3; Kerber-Kunow 2000, S. 3): Ein vorher festgelegtes Ergebnis Ein im Vorfeld festgelegter Anfang und ein festgelegtes Ende (konkrete Daten) Ein festgelegtes Budget (Personen, Kosten, Ressourcen [dies sind Produktionsmittel, Ausrüstung, Information etc.]) Einmaligkeit, zumindest aber keine Regeltätigkeit bei gewisser Komplexität der Aufgabe Notwendigkeit des Einsatzes eines Teams zur Lösung der Aufgabenstellung Erfordernis einer Projektleitung Zum Teil (etwa Wolf/Mlekusch 1997) findet man in der Literatur auch weitere Definitionen, die etwa auf die Komplexität oder die Bearbeitung durch ein Team verzichten. Grundsätzlich ist dies natürlich möglich – jedoch besteht dann die Gefahr, alle Tätigkeiten als Projekt definieren zu können. Der spezielle Einsatz eines Projektmanagements ist jedoch nur sinnvoll, wenn die oben genannten Kriterien erfüllt sind. Und auch gerade in Managementberatungen werden Projekte in der Regel durch die genannten Kriterien gut beschrieben. In Deutschland gibt es auch für Projekte eine DIN-Norm. Die DIN-Norm 69901 beschreibt Projekte als Vorhaben, das „im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B. Zielvorgabe, zeitliche finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Organisation“ (Litke/Kunow 2002, S. 9).


31

Diese Norm beinhaltet ebenfalls die oben aufgeführten Merkmale eines Projektes. Im Folgenden wird kurz auf die genannten konstitutiven Merkmale eines Projektes eingegangen: Ein vorher festgelegtes Ergebnis. Ein Projekt muss ein klares Projektziel haben. Die Tätigkeiten sind notwendig, um dieses Ziel zu erreichen. Das Projekt ist bei Erreichen des Ziels zu Ende. Mögliche Ziele sind: Erzielung von Kostensenkungen in einer Abteilung, Entwicklung eines neuen Produktes, Markteinführung eines neuen Produktes usw. Vorher festgelegter Anfang und Ende. Kontinuierliche Arbeiten an einem Thema, ohne Vorgehensplan sind keine Projekte. Ein Projekt startet offiziell (die Teilnehmer kennen dann die Aufgabe) und endet bei Zielerreichung oder Ablauf der definierten Zeit. Ein festgelegtes Budget. Hierbei kann sich der Begriff Budget auf Personen (Personalbudget), Kosten (Kostenbudget, oder kurz Budget), sonstiger Aufwand (Produktionsmittel, Ausrüstung, Informationen etc.) beziehen. Für Projekte werden in der Planungsphase diese Ressourcen festgelegt. Das heißt, einem Projekt sind gesonderte, nicht in der Regeltätigkeit enthaltene, Ressourcen zugeteilt. Einmaligkeit und eine gewisse Komplexität der Aufgabe: Projekte sind keine dauerhaften oder sich ständig wiederholenden Aufgaben. Diese Regeltätigkeiten benötigen eine andere Organisation und stellen andere Anforderungen an das Management. Eine gewisse Komplexität der Aufgabe heißt hier, dass zu kleine Aufgaben nicht als Projekte definiert werden. Der Einsatz eines Teams ist meist zur Lösung der Aufgabenstellung notwendig. Projekte arbeiten überwiegend interdisziplinär, d. h., Mitarbeiter aus verschiedenen Abteilungen arbeiten zusammen an der Lösung des Problems. Erfordernis einer Projektleitung. Es soll im Folgenden nur von Projekten gesprochen werden, wenn die Planungs- und Koordinationsaufgabe eine solche Komplexität aufweist, dass eine zentrale Koordination und Planung notwendig ist. Aufgaben, die in Selbstkoordination durchgeführt werden, sollen hier nicht als Projekte bezeichnet werden. Es stellt sich die Frage, welche Parameter in einem Projekt zentral geplant und kontrolliert werden müssen. In den oben genannten Merkmalen eines Projektes sind die Parameter Qualität des Ergebnisses, Kosten/Aufwand (Budget) und Dauer (Zeit) enthalten. Diese beeinflussen sich gegenseitig und bilden das so genannte „magische“ Dreieck der Projektorganisation (siehe Abbildung 2). Die Planung dieser Parameter muss in einem Projekt immer gemeinsam erfolgen, da eine Veränderung an einem Parameter Einfluss auf andere hat. Je enger der Termin, desto geringer die Qualität des Ergebnisses (bei gleicher Produktivität), je geringer der Ressourceneinsatz (weniger Aufwand und Kosten), desto geringer die Qualität des Ergebnisses (bei gleicher Effektivität) und je enger die Termine, desto höher die Kosten (da die Kapazität erhöht werden muss). Nur eine sorgfältige und abgestimmte Planung ermöglicht es, den Ausgleich aller Parameter zu gewährleisten.

32


tä

Pr od uk

ivi kt fe Ef

tiv itä t

Ergebnis/ Qualität

t

Projekt Termine/ Dauer

Kosten/ Aufwand Kapazität

Quelle: Wischnewski 2001, S. 26 (für viele) Abbildung 2: Das „magische“ Dreieck des Projektmanagements Neben Projekt gibt es noch zwei weitere Begriffe, die oft im selben oder ähnlichen Zusammenhang genannt werden. Dies sind Prozess und Programm (Mayrshofer/Kröger 1999, S. 25). Ein Prozess ist eine Abfolge einzelner Schritte, in denen eine bestimmte Routine abgearbeitet wird, wie beispielsweise der Einkaufsvorgang. Ein Prozess kann wiederholt durchlaufen werden und immer werden dabei die gleichen Schritte durchgeführt. Ein Prozess ist die Festlegung eines bestimmten Ablaufes zur Erledigung einer Aufgabe. Ein Projekt besteht abstrakt gesehen aus einem Prozess, aber nicht jeder Prozess ist ein Projekt. Ein Projekt ist zwingend einmalig, ein Prozess nicht. Ein Programm ist die Zusammenfassung von Arbeiten, die geleistet werden müssen, um ein langfristiges Ziel zu erreichen. Es besteht aus mehreren Elementen, die zur Zielerreichung notwendig sind. So können beispielsweise mehrere Projekte zur Kostensenkung zu einem langfristigen Programm zusammengefasst werden. Ein Programm hat lediglich ein Oberziel und kann so durch stets neue Projekte ergänzt werden, die dem Oberziel des Programms dienen. Mehrere Projekte in einem Programm können auch über so genanntes Multi-Projektmanagement koordiniert werden (Litke 1995, S. 85), auf das in diesem Buch lediglich kurz eingegangen werden soll.


33

Praxisbox 1: Beispiel für ein Programm: STAR von Deutsche Post World Net STAR ist ein Programm von Deutsche Post World Net mit dem Oberziel, den Unternehmenswert des Gesamtkonzerns zu steigern. Dies soll durch Nutzung von Synergiepotenzialen, Kostenersparnis und Prozessoptimierungen erreicht werden. Das Programm wurde offiziell Ende Oktober 2002 nach dem Börsengang von Deutsche Post gestartet und ist vom Ziel her etwa mit entsprechenden Programmen von Siemens oder dem Otto-Versand vergleichbar. Die geplante Laufzeit betrug etwa drei Jahre. Zum Start von STAR gab es zunächst eine strategische Vorgabe, welche zusätzlichen Umsatz- und Kostensenkungspotenziale die einzelnen strategischen Geschäftsfelder (BRIEF, EXPRESS & LOGISTICS, FINANCE) zu erreichen haben. Zudem wurden innerhalb der Geschäftsfelder und geschäftsfeldübergreifend einige in STAR enthaltene Kernprojekte definiert. Das Vorgehen wurde nach der Programmdefinition auf die strategischen Geschäftseinheiten verlagert. Diese haben einzelne Projekte definiert und so konkrete und operationalisierte Ziele für STAR abgeleitet. Um den Erfolg des Gesamtprogramms verfolgen zu können, wurde zudem eine zentrale Programmsteuerung durch ein Programmoffice installiert, die den Fortschritt in den einzelnen Projekten überwacht und verhindert, dass widersprüchliche Teilziele verfolgt werden. Siehe hierzu auch Praxisbox 16: Programmorganisation bei STAR auf Seite 154.

Projekte sind – wie dargelegt wurde – einmalig. Folglich ist Projekt nicht gleich Projekt. Projekte unterscheiden sich voneinander, und man wird kaum zwei Projekte in der Praxis finden, die genau gleich sind. Selbst wenn es um inhaltlich gleiche Themen geht, so stellen sich in der Projektarbeit in jeder Situation doch unterschiedliche Herausforderungen. Im Folgenden soll daher der Versuch unternommen werden, eine Typologisierung von Projekten vorzunehmen (zur Typologisierung siehe Knoblich 1972, S. 143). Je nach Einsatzgebiet lassen sich zunächst Projekte in Hoch- und Tiefbau, Fertigungsprojekte, Forschungsprojekte und Managementberatungsprojekte unterscheiden (Lock 1997, S. 18). Diese Unterteilung zeigt schon auf, in welch unterschiedlichen Feldern Projektmanagement eingesetzt wird. Die Projekte lassen sich aber auch nach inhaltlicher und externer Komplexität unterscheiden und typologisieren (zur Komplexität von Projekten siehe auch Maylor 1999, S. 18-19): Inhaltliche Komplexität beschreibt die fachlich mit der Erarbeitung der Ergebnisse verbundene Schwierigkeit. Sie repräsentiert entsprechend das zur Projektdurchführung notwendige Fach- oder Expertenwissen.

34


Mit der strukturellen Komplexität1 ist die Komplexität gemeint, die bei der Projektdurchführung durch eine Vielzahl von Teilprojekten, Mitarbeitern, Ansprechpartnern, unterschiedlichen Erwartungen, Anforderungen oder Meinungen entsteht. Es handelt sich also um eine Herausforderung in puncto Information, Koordination, Integration und Durchsetzung. Sie wird hier strukturelle Komplexität genannt, weil sie nicht aus der Aufgabe selbst (inhaltliche Komplexität), sondern durch die Strukturen und Rahmenbedingungen entsteht, innerhalb derer sich das Projekt befindet. Die strukturelle Komplexität determiniert das erforderliche Projektmanagement-Know-how. Unter Berücksichtigung dieser beiden Aspekte lässt sich eine Projektarten-Matrix entwickeln:

erforderliches Fachwissen niedrig

inhaltliche Komplexität

hoch

strukturelle Komplexität

erforderliches Projektmanagement-Know-how

niedrig

hoch

Abbildung 3:

einfache Projekte • eigene Durchführung • Berater zur Kapazitätserweiterung

KoordinationsProjekte • Berater als Projektleiter oder Change Agent

AdviceProjekte • Berater als Experte

TopProjekte • Berater als Manager (Facilitator und Experte)

Typologisierung für Managementberaterprojekte

Einfache Projekte können aufgrund der niedrigen Anforderungen an spezielles Fachwissen und Projektmanagement-Know-how meist durch die Auftraggeber (bzw. die betroffene Fachseite) selbst durchgeführt werden. Beratereinsatz ist nur dann notwendig, wenn die Fachseite zeitliche oder personelle Ressourcenengpässe hat. Der Berater füllt dann diese Lücke – mit der Beratung werden letztendlich Personalressourcen eingekauft. Advice-Projekte sind dadurch gekennzeichnet, dass die Managementberater für eine erfolgreiche Durchführung über ein tiefes Fachwissen verfügen sollten. Der Berater löst ein fach-

1

Herrn Philipp ter Haar sei für den Vorschlag zum Namen „strukturelle Komplexität“ gedankt.

Projektmanagement

35

liches Problem und gibt eine Empfehlung für den Auftraggeber ab. Seine Hauptleistung besteht darin, eine unabhängige und fundierte Analyse zu erstellen und auf deren Basis eine fundierte Empfehlung zu geben. Dies können beispielsweise Empfehlungen zu strategischen Entscheidungen wie der Übernahme eines Wettbewerbers sein. Zur erfolgreichen Durchführung von Advice-Projekten ist ein guter Methodenbaukasten (Tool-Box) hilfreich, mit dessen Hilfe sich der Berater schnell neue Methoden zur inhaltlichen Projektdurchführung aneignen kann. Koordinationsprojekte zeichnen sich dadurch aus, dass die Hauptaufgabe in der Koordination der Vorgehensweise sowie der beteiligten Personen und Stakeholder liegt. Die fachlichen Aufgaben sind nicht die entscheidenden Herausforderungen. Ein gutes Projektmanagement und entsprechende soziale Kompetenzen des Projektleiters sind zur erfolgreichen Durchführung von Koordinationsprojekten notwendig. Top-Projekte stellen hohe inhaltliche Anforderungen und erfordern ein gutes Projektmanagement-Know-how zur Abwicklung. Die Berater müssen dabei die fachliche und soziale Qualifikation mitbringen. Diese Projekte stellen so die höchsten Anforderungen an die beteiligten Personen. Ein Beispiel für ein Top-Projekt ist ein Innovationsprojekt, das fachlich neue Wege beschreitet und bereichsübergreifende Auswirkungen hat.

1.4

Projektmanagement

Nachdem behandelt wurde, was ein Projekt ist, betrachten wir nun den zweiten Teil des Wortes Projektmanagement: Management. Allgemein wird unter Management die Leitung von Systemen von Menschen und Technik (etwa Unternehmen oder Abteilungen) in personenund sachbezogener Hinsicht mit Hilfe von professionellen Methoden verstanden. Das Management bewältigt hierbei Aufgaben, die sich aus den Zielen des Systems/Unternehmens ergeben, und ist dabei auf den richtigen Umgang mit den Personen angewiesen, die in Kooperation die Aufgaben erfüllen (vgl. Litke 1995, S. 18; Keßler/Winkelhofer 1999, S. 10). Management hat dabei verschiedene Funktionen, die meist mit Planung, Organisation, Durchführung und Kontrolle beschrieben werden (Litke 1995, S. 18). Die Funktion der Durchführung wird zum Teil nicht in den Management-Begriff eingebunden und Management als reine Leitungsfunktion verstanden. Entsprechend soll auch hier bei Projektmanagement von einer Leitungsaufgabe ausgegangen werden. Projektmanagement umfasst daher die Planung, Organisation und Kontrolle von Projekten. Die Aufgabe der Durchführung der eigentlichen Projektarbeit ergibt sich aus den verschiedenen Inhalten eines Projektes und kann daher von Projekt zu Projekt extrem unterschiedlich sein. Sie umfasst alle möglichen Aufgabenstellungen innerhalb der Betriebswirt-

36


schaftslehre. Eine Abbildung dieser Vielfalt ist nicht Fokus dieses Buches. Im engeren Sinne braucht ein Projektmanager also im Detail kein Fachwissen über die im Projekt behandelten inhaltlichen Fragestellungen, da die Erarbeitung der Inhalte nicht zu seinen Aufgaben gehört. In der Praxis sind die Projektmanagement- und Projektdurchführungsfunktionen jedoch häufig verbunden. Der Projektmanager übernimmt dann auch eine inhaltliche Entwicklungs- und Durchführungsfunktion für das Projekt. In vielen – gerade in größeren Projekten – ist jedoch auch der reine Typus des oben beschriebenen Projektmanagers anzutreffen. Welche Aufgaben sind nun aber grundsätzlich beim Projektmanagement angesiedelt? Im Einzelnen sind dies (Portny 2001, S. 28): Planung, d. h. Definition der Ergebnisse, Festlegung des Zeitrahmens, Abschätzung der notwendigen Ressourcen anhand eines Vorgehensplans Organisation, d. h. Gremien, Rollen, Zuständig- und Verantwortungsbereiche festlegen, Sicherstellung des Informationsaustauschs Kontrolle, d. h. Überwachung des Projektfortschritts und der Ergebnisse, Überwachung der Planeinhaltung bzgl. Ressourcen- und Zeitinanspruchnahme, Erkennen und Lösen von Problemen Projektmanagement hat demnach Leitungs- und Organisationsfunktionen (Litke 1995, S. 21), es ist ein umfassendes Führungskonzept, welches für die begrenzte Zeit des Projektes zur Erreichung der Projektziele Gültigkeit hat. Hierbei greift das Projektmanagement auf manche Projektmitarbeiter voll zu, auf andere nur teilweise (Kerber-Kunow 2000, S. 4). Den Einfluss, den Projektmanagement auf die Leistungsfähigkeit von Unternehmen haben kann, kann man anhand eines inzwischen etwas älteren Beispiels sehr gut sehen (siehe Abbildung 4). Dargestellt ist ein Projekt zur Entwicklung eines neuen Automobils. Bei gleichem Ergebnis (Auto ist entwickelt) unterscheiden sich die notwendigen Arbeitseinsätze in Arbeitsstunden, die notwenige Projektdauer und die im Projekt gebundene Personenzahl erheblich. Die japanischen Automobilhersteller schafften es tatsächlich, mit dem fast halben Einsatz an Arbeitsstunden zum gleichen Ergebnis zu gelangen. Sie hatten kürzere Entwicklungszyklen für ihre Pkws, was ihnen einen Vorteil auf den Märkten verschaffte, denn sie konnten aktuellere Modelle anbieten. Der Grund für diesen Vorteil ist in einem besseren Management der Entwicklungsprojekte zu sehen.

Projektmanagement

37

Arbeitsaufwand

Dauer

3,5

70

3

60

Anzahl Beschäftigte im Projektteam 1.000 900 800

2,5

50

2

40

1,5

30

1

20

700 600 500 400 Japan 300 200

10

0,5

100

0

0 Mio. Stunden

E uropa

U SA

0

Monate

Anz ahl Personen

Quelle: Litke 1995, S. 22 Abbildung 4: Internationaler Vergleich der Effektivität des FuE-Projektmanagements am Beispiel der Automobilindustrie Welches sind aber nun die Faktoren, die dafür sorgen, wie erfolgreich das Projektmanagement ist? In einer großen Umfrage ist ermittelt worden, welche Gründe für Erfolg oder Misserfolg ausschlaggebend sind. Diese Übersicht zeigt sehr deutlich die bedeutsamen Elemente im Projektmanagement:

38


Gründe für Mißerfolg in %

Gründe für Erfolg in %

Sonstige

Sonstige

Ressourcen

Projektumfang

Planung/ Monitoring

Routine/ Kontrolle

Ziele

Ziele

Organisation/ Management

pers. Beziehungen 0%

10%

20%

30%

40%

0%

20%

40%

60%

Quelle: Selin & Selin, zitiert nach McKinsey (2000) Abbildung 5: Gründe für den Projekterfolg/-misserfolg

Praxisbox 2: Anforderungen an Projekte Das Inhouse Consulting hat ein Auswahlsystem entwickelt, das Anforderungen an Projekte beschreibt, die gegeben sein müssen, damit ein Projekt bearbeitet werden kann. Anhand der Erfüllung der Anforderungen kann beurteilt werden, inwieweit die Durchführung eines Projektes Erfolg versprechend ist. Dies sichert dem Auftraggeber und natürlich auch Inhouse Consulting, dass keine Projekte gestartet werden, die sich später als problematisch herausstellen. Die zugrunde gelegten Kriterien sind: Ist ein Nutzen für den Konzern erkennbar? Generiert das Projekt aus Sicht des Gesamtkonzerns einen hinreichenden Nutzen? Ist das Projekt monetär oder sonst lohnend für den Gesamtkonzern oder ist es nur aus partieller Sicht des Auftraggebers sinnvoll? Widerspricht es ggf. anderen berechtigten Interessen im Konzern oder der Konzernstrategie? Für das Inhouse Consulting ist dies wichtig, da es als Teil des Konzerns den Interessen des Gesamtkonzerns verpflichtet ist. Stehen die wichtigen Entscheider hinter dem Projekt? Hierbei ist wichtig, ob das Projekt eine so genannte Top-Management-Attention besitzt und unterstützt/gewollt wird. Zudem ist zu prüfen, ob weitere Anspruchsgruppen, die einen Einfluss auf das Projekt haben, dieses unterstützen, oder ob sie es ablehnen. Ist gleich zu Beginn eine Ablehnung

Projektmanagement

39

des Projektes durch die relevanten Entscheider und Einflussnehmer zu erkennen, so muss hier zunächst versucht werden, die Zustimmung zu erlangen. Wichtig ist auch, dass der Auftraggeber die notwenige Unterstützung in Form von Sach- und Personalressourcen für das Projekt zur Verfügung stellt. Ist der Arbeitsumfang des Projektes realistisch eingeschätzt und leistbar? Basis ist ein gemeinsames Verständnis des Umfangs der Aufgabe bei Auftraggeber und Inhouse Consulting. Hierbei ist zu prüfen, ob die abzuliefernden Ergebnisse erreichbar sind. Dies erfordert eine gute inhaltliche Abgrenzung der Projektarbeit und eine klare Rollenzuordnung. Sind außerordentliche Risiken vorhanden? Können potenzielle Risiken des Projektes ermittelt und bewertet werden? Sollten Risiken gefunden werden, dann müssen Maßnahmen getroffen werden, um diese nicht zu einer Gefährdung für das Projekt werden zu lassen. Kann ein leistungsfähiges Team eingesetzt werden? Um ein Projekt erfolgreich durchzuführen, benötigt man ein gutes Team von Projektmitarbeitern. Dies setzt zum Ersten die Verfügbarkeit der notwendigen Personen mit den richtigen Qualifikationen und Fähigkeiten voraus. Sind die notwendigen Ressourcen nicht zu beschaffen, kann das Projekt nicht durchgeführt werden. Zum Zweiten müssen die Rahmenbedingungen vorhanden sein, um als Team zusammenarbeiten zu können. Diese Rahmenbedingungen umfassen auch infrastrukturelle Punkte wie Arbeitsplätze und -mittel. Dritter Punkt unter dem Stichpunkt Team ist, ob die Aufgabe den Einsatz eines Teams von mindestens zwei Beratern erfordert. Bei Einsatz nur eines Beraters auf einem Projekt besteht kaum eine Kontrolle über die Arbeit des Beraters, was die Gefahr birgt, lediglich im Sinne eines „Body-Leasings“ Personal abzutreten, ohne dass Beratungsbedarf besteht. Zudem kann der Vorteil eines Teams mit gegenseitiger Unterstützung und Weiterentwicklung der Mitarbeiter nicht realisiert werden. Ist ein Nutzen für das Inhouse Consulting erkennbar? Hierbei geht es darum, ob das Projekt der Reputation des Inhouse Consultings dienlich ist und/oder ob im Projekt Wissen über Methoden, Vorgehensweisen, Unternehmensteile, Branchen etc. erlangt wird, das Inhouse Consulting für weitere Projekte nutzen kann. Projekte, die eine negative Reputation nach sich ziehen, sind sehr kritisch zu betrachten, da die Gefahr besteht, in der Akquisition neuer Projekte Probleme zu bekommen. Hat das Projekt eine angemessene Dauer? Bei einer Dauer unter 6 Wochen ist der Beratereinsatz in der Regel aufgrund der Einarbeitungszeiten sowie des Aufwandes für ein Proposal und ein Angebot nicht sehr sinnvoll. Ist wesentliche Einflussmöglichkeit auf die Projektvorgehensweise vorhanden? Ist dies nicht der Fall, so besteht die Gefahr, bei Erkennen von Problemen nicht reagieren zu können.

40


In der Projektakquisition kann die erste Prüfung, inwieweit ein Projekt die Kriterien erfüllt, nach einer Reihe von Vorgesprächen mit einem potenziellen Auftraggeber, dem Team, dem zuständigen Projektpartner, ggf. Vertretern aus dem Konzern etc. erfolgen. Hiernach muss der verantwortliche Projektmanager eine Bewertung des potenziellen Projektes durchführen und in einem Project Fact Sheet dokumentieren. Dies dient der Entscheidungsfindung, dem Wissensmanagement und erlaubt eine spätere Erfolgsmessung. Die Entscheidung des Inhouse Consultings, ob ein potenzielles Projekt weiterverfolgt wird, fällt die Partnerrunde nach eingehender Diskussion. Nur nach positiver Bewertung durch dieses Gremium wird ein Projekt weiter verfolgt und es wird versucht, den Projektauftrag zu erhalten. Im Falle der Entscheidung gegen ein Projekt muss der zuständige Projektmanager oder Partner dem potenziellen Auftraggeber die Entscheidung erläutern. So kann gemeinsam diskutiert werden, ob das Projekt sinnvoll durchzuführen ist. Wird ein Projekt durchgeführt, so ist es die fortlaufende Aufgabe eines Projektleiters sicherzustellen, dass die Kriterien und weitere definierte Anforderungen für die einzelnen Projektphasen erfüllt bleiben. Ursprünglich gab es sogar eine Excel-gestützte Projektbewertung, die im Sinne eines Punktwertverfahrens gearbeitet hat.2 Diese Lösung hat sich jedoch als sehr starr und wenig praktikabel erwiesen.

1.5

Besonderheiten bei Projekten in Managementberatungen

Managementprojekte sind Projekte unmittelbar für das Management. Diese haben aus der Natur der Sache heraus besonders große Aufmerksamkeit und Wichtigkeit für das Unternehmen. Sie sind von strategischer Bedeutung, oft sehr speziell und müssen individuell geplant und durchgeführt werden. Eine solche individuelle Betrachtung eines Projektes ist zwingend, wenn man den jeweiligen Aufgaben bestmöglich gerecht werden möchte. Trotz aller Unterschiede weisen die Projekte in der Regel dennoch einige Gemeinsamkeiten auf, die es erlauben, die individuelle Vorgehensweise an einem Raster zu entwickeln. Diese Gemeinsamkeiten werden im Folgenden vorgestellt, und es wird abgeleitet, welche Auswirkungen sie auf die Projektarbeit haben.

2

Ein Beispiel hierfür findet sich auch in Kerber-Kunow 2000, S. 16.


Top-ManagementAttention

41

Komplexität

Projektspezifika Bedeutung (Impact)

Abbildung 6:

„externe“ Durchführung

Charakteristika von Projekten in der Managementberatung

Top-Management-Attention: Dies heißt, dass das Top-Management (in der Regel die erste und zweite Führungsebene) eines Unternehmens sehr genau den Projektverlauf und die Projektergebnisse verfolgt. Die Auftraggeber einer Managementberatung sind entsprechend in der Regel Personen dieser Leitungsebene im Unternehmen. Der Einsatz von externen Managementberatern ist meist recht kostspielig. So ist ein Beratungssatz für einen Berater von 1.500 Euro und für einen Projektmanager von bis zu 3.000 Euro je Tag bei den großen Managementberatungen nicht unüblich (siehe Mester/Zamponi 2004). Nimmt man nun ein „kleines“ Projekt von drei Personen (zwei Berater, ein Projektmanager) für drei Wochen (15 Arbeitstage), so ergeben sich schon Kosten in Höhe von bis zu 85.000 Euro. Ein Projekt wird aufgrund dieser hohen Kosten nur gestartet werden, wenn der Auftraggeber davon überzeugt ist, dass die Ersparnisse oder Mehrerlöse durch das Projektergebnis den Aufwand übertreffen. Bei den genannten Summen ist es nahe liegend, dass es sich um Projektziele handelt, die das Top-Management nachhält. Für das Projektmanagement heißt dies nun, dass dieser Beachtung und Beteiligung des TopManagements an dem Projekt durch adressatengerechte Kommunikation Rechnung getragen werden muss. Bedeutung (Impact): Unter dem vorherigen Punkt wurde schon erläutert, dass Managementberatungs-Projekte große finanzielle Auswirkungen mit sich bringen werden. Diese beruhen häufig darauf, dass die Projektergebnisse eine Relevanz für die Mitarbeiter des Unternehmens haben. Sei es, weil Arbeitsplätze betroffen sind oder weil Empfehlungen mit sehr langfristigen und strategisch bedeutsamen Auswirkungen für das Unternehmen abgegeben werden, die nicht ohne weiteres rückgängig gemacht werden können. Deshalb müssen Projektanalysen und Empfehlungen besonders kritisch hinterfragt und Analysen und Kalkulationen besonders sorgfältig ausgearbeitet werden. Eine lückenlose Dokumentation ist notwendig, damit ggf. die Richtigkeit der Quellen und Aussagen nachgewiesen werden kann.

42


Außerdem kann sich ergeben, dass Ergebnisse vertraulich behandelt werden müssen. Nur ein bestimmter Personenkreis darf Kenntnis erhalten. Dies wirkt sich dann auf das Vorgehen bei der Projektarbeit, der Zusammensetzung von Abstimmungsgremien und auf den Verteiler für Dokumente aus. Umgekehrt kann es aber auch gerade wichtig sein, möglichst viele Personen einzubeziehen, um einen allgemeinen Konsens für die Ergebnisse zu erzielen. In diesem Fall ist es dann notwendig, die Vorgehensweise, Zwischen- und Endergebnisse mit allen Beteiligten und Betroffenen sorgfältig abzustimmen. Vor allem ist das dann sinnvoll, wenn es um Abstimmungen mit Arbeitnehmervertretern geht (Mester/Zamponi 2004). Komplexität: Je nachdem, ob inhaltliche oder externe Komplexität (oder sogar beide) im Vordergrund stehen, ergeben sich unterschiedliche Anforderungen an das Projektmanagement (vgl. Kapitel 1.3, Abbildung 3 auf S. 34). Einfache Projekte werden in der Regel in der Managementberatung nicht durchgeführt. Für Managementberatungsprojekte ist es daher wichtig, ein sauber strukturiertes Projektmanagement zu besitzen und Zugriff auf das Wissen über erfolgreich einsetzbare Methoden. Externe Durchführung: Managementberatung bedarf einer gewissen Unabhängigkeit, um aus der Menge der Möglichkeiten die richtige Empfehlung geben zu können, insbesondere wenn es unbequemer Aussagen bedarf. Dies wird am ehesten durch eine organisatorische Trennung zwischen dem Berater und dem Beratenem gewährleistet. Bei externen Beratern besteht nur ein Werk- oder Dienstleistungsvertrag. Bei internen Beratungen besteht darüber hinaus noch eine weitere Bindung. Die interne Beratung ist i. d. R. Teil der jeweiligen Muttergesellschaft. Sie ist oftmals in eine Tochtergesellschaft ausgegliedert oder in einen Dienstleistungsbereich, separiert von der beratenen Fachseite, aufgehangen. Selbst bei internen Unternehmensberatungen ist dies so, da diese Einheiten oft als Tochterunternehmen fungieren oder zumindest die Berater anderen Abteilungen oder Bereichen angehören als die Fachseite. In der Regel gibt es mindestens zwei beteiligte Partner bei Managementberatungsprojekten: Das Unternehmen, das beraten wird (auch Klientenunternehmen oder Auftragsunternehmen genannt) und die Managementberatung Innerhalb des Klientenunternehmens kann man noch den Auftraggeber des Projektes (z. B. den Vorstand) und die Fachseite unterscheiden. Die Fachseite ist die Fachabteilung oder der Fachbereich, der inhaltlich für das Themengebiet verantwortlich ist, zu dem die Beratung erfolgt bzw. die maßgeblich durch das Projekt oder die Projektergebnisse betroffen ist. Teilweise wird für die Mitarbeiter der Fachseite auch der Begriff Linienmitarbeiter verwandt, da diese Mitarbeiter in die Linienorganisation des Klientenunternehmens eingebunden sind. Die Fachseite ist deshalb in der Regel aktiv in die Projektarbeit eingebunden. Es wird also meist in Teams gearbeitet, die aus Mitarbeitern der Managementberatung und der Fachseite (meist nicht zu 100 % der Arbeitszeit) bestehen und gemeinsam die Projektaufgabe bearbeiten. Diese Konstellation stellt besondere Anforderungen an die Kommunikation (vom Berater, zum Unternehmensmitarbeiter), den Wissenstransfer bzw. die Know-how-Sicherung (Metho-


43

den der Berater, Fachwissen der Fachseite, Projektergebnisse etc.) und die Mitarbeiterführung (disziplinarische und fachliche Weisungen sind verteilt). Auch impliziert die externe Durchführung, dass die Akquisition von Projekten notwendig ist. Der Auftrag zur Durchführung eines Projekts muss gewonnen werden. Hier stehen die Beratungen meist im Wettbewerb untereinander, und es ist Aufgabe eines guten Projektmanagements, auch die erfolgreiche Akquisition schon zu planen. Diese Besonderheiten werden im Folgenden bei der Darstellung des Projektmanagements in den Vordergrund gestellt und bilden eine konzeptionelle Basis dieses Buches. In einem Projekt lassen sich verschiedene Qualitätsdimensionen unterscheiden, die im Projektmanagement berücksichtigt werden müssen. Betrachtet man Qualität als die Gesamtheit der subjektiv wahrgenommenen Eignung der unterschiedlichen Aspekte eines Projektes zur Erfüllung der damit verbundenen Ziele (in Analogie zu Haller 1998, S. 10), dann ergeben sich entsprechend zwei Sichtweisen auf die Qualität eines Projektes: die des Auftraggebers und die der Managementberatung. Formal werden als Projektziele natürlich die Ziele des Auftraggebers festgelegt, so dass diese auch für das Beratungsunternehmen relevant sind.3 Auch führt eine vom Auftragnehmer wahrgenommene hohe Projektqualität dazu, dass der Auftraggeber eher zufrieden sein wird und sich positiv über das Projekt äußert (positive Mundwerbung) und die Wahrscheinlichkeit eines neuen Auftrags steigt (Zeithaml/Bitner 2002, S. 127). Die Qualität kann durch den Auftraggeber anhand von drei Sichtweisen beurteilt werden (Haller 1998, S. 76): Potenzialqualität, Prozessqualität und Ergebnisqualität. Die Potenzialqualität ist die wahrgenommene Eignung der Berater und des Beratungsunternehmens zur Durchführung des Projektes. Neben den fachlichen und persönlichen Fähigkeiten der Berater spielen hier – da dies schneller zu bewerten ist – auch das Auftreten, die technische Ausstattung oder die Geschäftsräume eine nicht zu unterschätzende Rolle. Die Prozessqualität beschreibt den Ablauf des Projektes, d. h. die wahrgenommene Qualität der Projektdurchführung, des Ablaufs und der Zusammenarbeit. Wichtig ist hierbei die Projektplanung, da diese den Ablauf bestimmt, die Zusammenarbeit von Beratern und Linienmitarbeitern, die Information über den Projektablauf, um Unsicherheiten hierüber zu vermeiden, das Auftreten der Berater und ihre Fähigkeit, auf Wünsche des Auftraggebers einzugehen, und eine Vielzahl von weiteren Punkten, die vom Auftraggeber während des Projektes wahrgenommen werden. Die Ergebnisqualität stellt die Wahrnehmung des Auftraggebers dar, inwieweit tatsächlich die Projektziele am Ende des Projektes erreicht wurden.

3

Aus Sicht der Beratung werden natürlich auch andere Ziele mit einem Projekt verbunden, wie z. B. die Dauerhaftigkeit der Zusammenarbeit (siehe hierzu auch Praxisbox 2 auf S. 38).

44


Die Anforderung an ein Projektmanagement bei Beratungsprojekten ist es nun sicherzustellen, dass die Projektarbeit in allen Qualitätsdimensionen positiv vom Auftraggeber wahrgenommen wird. Eine reine Orientierung an der formalen Erreichung der Projektziele ist hierzu nicht ausreichend. Eine Managementberatung hat eigene Kriterien, ist zumeist kritischer als die Fachseite und stärker auf den Gesamtkontext des Konzerns ausgerichtet.

1.6

Welche Projektphasen gibt es?

Projekte unterscheiden sich in ihren Zielen und Inhalten, von ihrem Umfang und ihrer Dauer. Jedes Projekt ist einzigartig und erfordert eine individuelle Vorgehensweise, um zum Projektergebnis zu gelangen. Ein Patentrezept, das immer für alle Projekte gilt, gibt es nicht. Dennoch gibt es – neben den eingangs geschilderten konstitutiven Merkmalen von Projekten – eine weitere Gemeinsamkeit für alle Projekte: ihren Ablauf. Dies trifft natürlich nicht immer zu, jedoch meist. Je nach Quelle unterscheiden sich die für ein Projekt genannten idealtypischerweise durchlaufenen Projektphasen. Dies sind jedoch meist nur Unterschiede in der Darstellung. Grundsätzlich läuft ein Projekt in der Managementberatung wie folgt ab:

Akquise

Definition

Planung

Start

Durchführung

Abschluss

Vgl. Kerber-Kunow 2000 Abbildung 7: Idealtypischer Phasenablauf eines Projektes Akquisephase. Ausgangspunkt eines Projektes ist immer der Wunsch, die bisherige Situation aktiv zu ändern, d. h., es gibt einen Bedarf für das Projekt. Zum Beispiel kann ein Geschäftsführer eine Idee für ein Projekt haben und er möchte, dass diese Idee geprüft wird, eine Neuprodukteinführung geplant werden, eine Kostensenkung notwendig oder gewünscht sein oder die Notwendigkeit bestehen, ein Produkt technisch weiterzuentwickeln.


45

Der potenzielle Auftraggeber eines Projektes hat in der Regel ein Problem, für das er eine Lösung benötigt. Oft hat er dabei schon eine Idee, was er möchte. Diese Idee möchte er auf ihre Relevanz prüfen lassen – oder falls noch keine Ideen vorhanden sind, möchte er eine Lösung für sein Problem bekommen. Erste Aufgabe einer Managementberatung in der Akquisephase ist es nun, mit dem potenziellen Klienten in Kontakt zu treten und seinen Beratungsbedarf bzw. das zugrunde liegende Problem zu verstehen. Daraufhin ist eine erste Idee zu entwickeln, wie das Problem gelöst werden könnte bzw. wie die Vorgehensweise zur Lösung des Problems aussehen könnte. Dies ist mit dem Auftraggeber zu diskutieren. So kann sichergestellt werden, dass die vorgeschlagene Vorgehensweise geeignet ist, das dem Beratungsbedarf zugrunde liegende Problem zu lösen. Zudem sollte sich das Beratungsunternehmen als kompetenter Partner darstellen, der die Projektumsetzung begleiten kann. Für die Nachhaltigkeit des Erfolges einer Beratung ist es hierbei sehr wichtig, dass tatsächlich nur Projekte akquiriert werden, deren Durchführung sinnvoll ist bzw. bei denen die Beratung tatsächlich der richtige Partner ist. Werden andere Projekte durchgeführt, wird dies zwangsläufig zur Unzufriedenheit des Kunden führen. Das Ergebnis der Akquisephase ist der Projektauftrag an die Managementberatung und die Entscheidung, das Projekt durchzuführen. Definitionsphase. Dies ist die zweite Phase. Hier wird das Projektziel abgegrenzt und genau definiert. Wenn nötig, kann eine Kosten-Nutzen-Analyse angewandt werden. Die grundsätzliche Vorgehensweise zur Zielerreichung wird festgelegt. In der Definitionsphase sollte im ersten Schritt die Frage „Was ist los?“ beantwortet werden (Litke 1995, S. 29). Hierzu ist eine genauere Situationsbeschreibung sinnvoll, in der die systematische Darstellung der vom Auftraggeber als problematisch empfundenen Gegebenheit oder Situation erfolgt (Litke 1995, S. 30). Es sollen Transparenz und ein gemeinsames Verständnis von Auftraggeber und Beratungsunternehmen über die Ausgangslage geschaffen werden. Eine Situationsanalyse ist weitergehender als eine reine Ist-Aufnahme, da sie auch eine Projektion in die Zukunft und die Einbeziehung von Wechselwirkungen des zugrunde liegenden Problems mit anderen Unternehmensaspekten enthält. Sie ist die Basis für die weitere Arbeit. In bezahlten Beratungsprojekten wird die Situationsanalyse manchmal in mehreren Schritten durchgeführt. Eine erste grobe Analyse erfolgt unbezahlt im Vorfeld der Angebotserstellung, sie fällt also in die Akquisephase. Eine weitere, ausführliche, findet im Rahmen der Definitionsphase statt. Im weiteren Projektablauf können dann je nach Bedarf auch noch zusätzliche Analysen erstellt werden. Auf Basis der Situationsbeschreibung ist (ggf. zusammen mit dem Auftraggeber) noch einmal zu hinterfragen, ob das vom Auftraggeber als Idee vorhandene Projektziel geeignet und sinnvoll ist. Wichtig ist es, hierbei zu klären, ob das Projektziel auch den Unternehmenszielen dient. Wenn ja, kann die Planung des Projektes erfolgen. Ansonsten muss ggf. noch einmal darüber nachgedacht werden, wie das Projektziel revidiert werden kann.

46


Planungsphase. In dieser Phase wird die Vorgehensweise im Projekt gedanklich vorstrukturiert. Es wird detailliert vorausgeplant, wie vorgegangen wird, um das Projektziel zu erreichen. Dazu wird das Ziel im Detail definiert, ein genauer Zeitrahmen entwickelt, werden die einzelnen notwendigen Tätigkeiten geplant, die erforderlichen personellen, finanziellen und sonstigen Ressourcen ermittelt. Zudem wird festgelegt, wer für was zuständig ist und welche Kompetenzen er hierfür hat. Startphase. Die tatsächliche Projektarbeit beginnt dann in der Startphase. Hier werden die Mitglieder insbesondere fachseitig gewonnen und instruiert, die geplanten Aufgaben verteilt, die Überwachungsinstrumente für die Projektarbeit werden installiert, und es erfolgt die allgemeine Bekanntmachung des Projektes im Unternehmen. Hierzu dient oft ein so genanntes „Kick-off-Meeting“. Durchführungsphase. Die Aufgaben werden dann in der fünften Phase, der Durchführungsphase, abgearbeitet. Es erfolgt im Rahmen des Projektmanagements dann ein Projektcontrolling. Hier wird kontrolliert, ob die Zielerreichung im Plan ist und ob die bis zum jeweiligen Zeitpunkt eingeplanten Ressourcen sich im festgelegten Rahmen bewegen. Es findet also eine Projektsteuerung statt (Litke/Kunow 2002, S. 17). Zudem ist es in der Durchführungsphase wichtig, im Rahmen eines Personalmanagements die Mitarbeiter kontinuierlich zu motivieren und ihre Leistungsfähigkeit sicherzustellen. Gute und offene Kommunikation sind hier die Hauptinstrumente, die erfolgskritisch sind. Abschlussphase. Zunächst wird hier das Projektziel erreicht und die Arbeit wird eingestellt. Erfolgreiche Projektmanager beachten aber darüber hinaus folgende Aufgaben: Das Projekt muss formell durch den Auftraggeber beendet und der Projektmanager auf Basis der Endprodukte entlastet werden. Die Projektorganisation (inkl. Kostenstellen etc.) muss aufgelöst werden und allen Mitarbeitern müssen neue (bzw. ihre alten) Aufgaben zugewiesen werden. Die Projektergebnisse müssen vollständig dokumentiert sein und an den Auftraggeber übergeben werden. Eine beratungsinterne Projektbewertung (Zielerreichung, Probleme etc.) beurteilt das Projekt auch aus Sicht der Durchführenden und des Projektmanagers (nicht nur aus Sicht des Auftraggebers). Ein Knowledge-Management sichert das Wissen (etwa über Informationen oder Verfahren) für zukünftige Projekte. Je nach Größe des Projektes können die vorgestellten Projektphasen in der Praxis in wenigen Tagen oder vielen Monaten durchlaufen werden. Sie laufen zudem häufig nicht in einer stringenten chronologischen Reihenfolge ab, sondern werden zum Teil parallel angegangen. Wenn z. B. von Anfang an klar ist, dass eine bestimmte sehr zeitaufwändige Analyse notwendig sein wird, dann kann diese vorgezogen werden. Oder wenn sich in der Planungsphase heraus-


47

stellt, dass eine spezielle Situationsanalyse nötig ist, so wird dieser Teil der Definitionsphase wieder aufgegriffen werden. Ein häufiger Fehler ist es, aufgrund von Zeit- und Ergebnisdruck die verschiedenen Phasen nicht sauber zu durchlaufen und vorzeitig abzubrechen und zur nächsten Phase überzugehen. Insbesondere eine mangelnde Prüfung und Konkretisierung des Projektziels können hier im Laufe des Projektes fatale Folgen haben. Späte Änderungen am Ziel können die gesamte bisherige Vorgehensweise in Frage stellen und einen Neustart erforderlich machen. Ein mangelnder Konsens zu Beginn kann während des Projektes zu Reibungsverlusten führen, die nur mit sehr viel Aufwand wieder aus der Welt geschafft werden können. Ein unsauber oder widersprüchlich definiertes Ziel kann nach Abschluss des Projektes dazu führen, dass der Auftraggeber unzufrieden ist, obwohl das Projektteam der Meinung war/ist, gute Arbeit geleistet zu haben. Wichtig beim Umgang mit Planungen ist eine offene und stetige Kommunikation zwischen Auftraggeber und Beratungsunternehmen. Bei Projekten mit hohem Innovationscharakter kann häufig erst während der Durchführung erkannt werden, dass eine Vorgehensweise ungeeignet ist, mehr Zeit benötigt oder dass etwas anderes geändert werden muss. Die Managementberatung muss ständig den Projektfortschritt und die Rahmenbedingungen kontrollieren und beraten, um ggf. die Notwendigkeit einer Planänderung zu erkennen. Zu jedem Zeitpunkt muss daher die Offenheit bestehen, hierüber zu sprechen und die Vorgehensweise anzupassen.

Praxisbox 3: Der Common Consulting Approach Das Inhouse Consulting hat ein eigenes Vorgehensmodell zur Durchführung von Projekten entwickelt. Ähnlich wie andere Vorgehensmodelle (etwa Prince II oder PMI)4, basiert es auf definierten Projektphasen und ermittelten Erfolgsfaktoren für diese Phasen. Hieraus wurde ein Baukastensatz mit Hilfsmitteln für erfolgreiches Projektmanagement zusammengestellt, der die spezifischen Belange von Managementberatungsprojekten berücksichtigt. Die Einführung des Common Consulting Approaches (CCA) verfolgte dabei drei Hauptziele: Bereitstellung von erprobten Projektvorgehensweisen und Projekthilfsmitteln, um das Projektteam zu entlasten, damit Kapazitäten frei werden, um sich auf die Projektbesonderheiten zu konzentrieren. Garantie der Qualität von Projektarbeit und -ergebnissen. Zudem gelingt es so sicherzustellen, dass der Projektleiter die zum Teil sehr arbeitsintensiven Schritte zum Controlling des Projektes oder zum Aufbau einer Wissensbasis im Inhouse Consulting mit genormter, hoher Qualität vornimmt.

4

Siehe zu Prince II etwa Köhler (2006) und zu PMI Gartner/Wuttke (2000).

48


Schaffung personenunabhängigen Know-hows zur Vereinfachung des Personalaustausches in Projekten (Flexibilisierung). Zur Strukturierung dient hierbei ein Phasenmodell, das folgende Projektphasen unterscheidet:

Project Phases and Examples for Tools Deliverables belong to IC

Deliverables belong to client

Qualification/ Proposal

Phases

Definition

Typical Tools and Tem- plates

Project proposal template Project fact sheet

Planning

Execution

Closure

IC Methods

Selling Preparation of project proposal with regard to client and IC expectations

Deliverables belong to IC

What to do?

How to do?

Definition of purpose and main deliverables of project

Determination of project organization, roles, tasks and responsibilities

Project assignment Work breakdown structure Stakeholder Management Change request

Project Planning Risk Management Status reporting

Doing Implementation of defined project based on plan

Analysis techniques Interviewing Persuasion Selfmanagement Chart design

Debriefing Identification and documentation of knowledge and lessons learned

Knowledge management (e. g. project documentation, IC-Methods IC-Methods, fact books) Customer satisfaction survey

Source: Inhouse Consulting

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 8: Der Common Consulting Approach Die Phasen ähneln den bisher im Buch vorgestellten Phasen. Sie sind im Projektablauf stärker zusammengefasst, so dass das Inhouse Consulting nur fünf Phasen unterscheidet. So wurde auf die gesonderte Aufführung der Startphase verzichtet und sie wurde in die Durchführung integriert. Abbildung 8 zeigt in verschiedenen Zeilen die einzelnen Phasen und liefert Informationen zu diesen. Über den Phasen ist in einer Zeile zugeordnet, für wen die Ergebnisse der Projektarbeit bestimmt sind. Dies ist wichtig, da das Inhouse Consulting als unabhängige Beratung und Profit Center agiert. Zudem wissen die Consultants so, für wen die jeweiligen Projektphasen durchgeführt werden. Unter den Phasen ist in einer Zeile kurz aufgeführt, was die Hauptaufgabe der jeweiligen Phase ist, d. h. welche Fragen dort bearbeitet werden. Unter der Linie sind dann die im Rahmen des Common Consulting Approaches zur Verfügung stehenden Vorgehensweisen (Tools) und Vorlagen (Templates) aufgeführt, die in der Projektphase jeweils eingesetzt werden. Weiterhin wurden einzelne Erfolgsfaktoren entwickelt, die gegeben sein müssen, um ein Projekt erfolgreich durchzuführen. In den einzelnen Phasen sind bestimmte Erfolgsfaktoren jeweils besonders wichtig, so dass die Tools und Templates auch an der laufenden Sicher-


49

stellung des Vorliegens der Erfolgfaktoren ausgerichtet sind. Soweit sie im Vorfeld schon prüfbar sind, sind sie in den Kriterien zur ersten Projektbeurteilung (siehe Praxisbox 2 ab Seite 38) enthalten. Abbildung 9 gibt einen Überblick über diese Erfolgsfaktoren, die anschließend kurz beschrieben werden.

Committed stakeholders

Wellmanaged work and schedule

High performing team

Realistic and manageable scope

Realized DPWN business impact

Mitigated risks

Realized IC benefits

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 9: Project Success Factors (Projekt-Erfolgsfaktoren) Realized DPWN business impact – Wurde/wird ein Nutzen für den Konzern erzielt? Committed stakeholders – Stehen die Stakeholder hinter dem Projekt? Realistic and manageable scope – Ist der Arbeitsumfang des Projektes realistisch eingeschätzt und machbar? Well-managed work and schedule – Gibt es eine hinreichend geplante Vorgehensweise und einen realistischen Zeitplan? Mitigated risks – Wurden die vorhandenen Risiken entschärft? High performing team – Ist ein leistungsfähiges Team am Werk? Realized IC benefits – Wurde ein Nutzen für das Inhouse Consulting erzielt? Jedes Projekt durchläuft die aufgeführten Projektphasen. Mit Hilfe des Common Consulting Approaches wird für jede Phase ein Set von Tools zur Verfügung gestellt, das die Vorgehensweise unterstützt und strukturieren hilft. Der Projektleiter muss im Projektverlauf einige Tool und Templates zwingend nutzen (etwa den Projektsteckbrief), andere stehen ihm

50


bei Bedarf zur Unterstützung zur Verfügung (etwa eine Risk Database). Mit der Vorgabe wurde versucht, die im Projekt notwendige inhaltliche Kreativität zu fördern und auch inhaltlich neue Lösungen zuzulassen.

Grundlagen der Projektakquisition in Managementberatungen

51

2 Akquisephase

2.1

Grundlagen der Projektakquisition in Managementberatungen

Ohne Auftrag kein Projekt! Daher ist die Akquisephase von existenzieller Bedeutung für jede Managementberatungsgesellschaft. Sie muss Kunden für ihr Produkt, die Durchführung von Projekten, gewinnen. Ziel der Akquisephase ist es dabei, solche Projekte zu gewinnen, die für den Auftraggeber und die Managementberatung einen Nutzen bringen. Die Durchführung eines Projektes ohne Nutzen für den Auftraggeber ist aus Sicht der Beratung auch dann wenig sinnvoll, wenn der Auftraggeber die Beratungshonorare bezahlt, da sich nach Projektabschluss kaum Zufriedenheit beim Auftraggeber einstellen wird. Diese Unzufriedenheit des Auftraggebers mit dem Projektergebnis wird sich auf die Wahl der Beratung bei möglichen neuen Projekten auswirken und sie wird zu negativer Mund-zu-Mund-Propaganda führen.5 Kundenbindung und Weiterempfehlung werden nicht erreicht. Nicht nur aus Sicht des Klienten, auch aus Sicht der Beratung können die Projekte mehr oder weniger sinnvoll sein. In Praxisbox 2 waren schon einige Kriterien für die Projekteignung aus Sicht des Inhouse Consulting von Deutsche Post World Net aufgeführt. Die folgenden Kriterien geben Hinweise darauf, ob ein Projekt erfolgreich durchgeführt werden kann, ob unkalkulierbare Risiken von dem Projekt ausgehen und ob es über das Projekt hinausreichende Vorteile gibt: Lässt sich das Projekt im Rahmen der Personaleinsatzplanung der Beratung mit den notwendigen Ressourcen ausstatten? Besitzt die Beratung die notwendigen Fähigkeiten (Skills), um das Projekt durchzuführen? Ist das Projekt überhaupt erfolgreich durchzuführen?

5

Der grundsätzliche Zusammenhang zwischen Weiterempfehlung und Kundenzufriedenheit wird jährlich im Kundenmonitor Deutschland für verschiedene Branchen dargestellt (siehe z. B. Meyer/Dornach 2000). Es zeigt sich, dass unzufriedene Kunden diese Unzufriedenheit vielen Menschen mitteilen. Dieser Effekt überwiegt sogar noch die positive Kommunikation im Falle von Zufriedenheit.

52

Akquisephase

Kann das Methodenwissen aus dem Projekt auch in anderen Projekten Verwendung finden? Behandelt das Projekt ein Thema, das zu den aktuellen oder geplanten Kernkompetenzen der Beratung zählt? Ist der Kunde ein strategischer Zielkunde? Grundsätzlich unterscheidet sich die Akquisephase von externen und internen Beratungen nicht, wenn es für den Einsatz von internen Beratern im Unternehmen keinen Kontrahierungszwang und eine zwingende Kostenverrechung gibt. Interne Beratungen besitzen jedoch in der Praxis einige Vorteile: Dadurch, dass das Beratungshonorar (Consulting Fee) im Unternehmen bleibt, sinkt die Hemmschwelle für die Inanspruchnahme der internen Berater. In der Regel sind die von internen Beratungen verrechneten Beratungshonorare im Vergleich zu den im Beratungsmarkt üblichen Sätzen günstig. Interne Beratungen kennen das zu beratende Unternehmen, die Produkte, die Mitarbeiter etc., so dass die notwendige Analysephase kürzer ausfallen kann. Dies verkürzt die Projektlaufzeit, was zu schnelleren Ergebnissen führt und die Kosten senkt. Es kann fast immer wieder auf Berater zurückgegriffen werden, die bereits erfolgreiche Projektarbeit im Untenehmen geleistet haben. Das schafft Sicherheit für den Nachfrager, da er im eigenen Unternehmen Referenzen einholen kann. Interne Beratungsunternehmen sind im Unternehmen bekannt. Aus politischen Gründen kann unter Umständen der Einsatz interner Berater gewünscht sein, etwa bei Themen, die sehr vertraulich sind oder die eine hohe Akzeptanz bei den Mitarbeitern im Unternehmen benötigen. Wenn die Empfehlungen quasi von den „eigenen Leuten“ kommen, kann dies zu höherer Akzeptanz führen.

2.2

Vorbereitung der Projektakquisition

Als erste Voraussetzung für die Projektakquisition muss zunächst einmal das Managementberatungsunternehmen dem Unternehmen mit Beratungsbedarf bekannt sein. Dies ist zunächst unabhängig von einem konkreten Projekt, und die Instrumente zur Schaffung eines hohen Bekanntheitsgrades sind eher von dauerhafter Natur. Daher erfolgt dieses allgemeine Marketing auch vornehmlich außerhalb des Projektmanagements. An dieser Stelle wird deshalb nur kurz auf das Marketing eines Managementberatungsunternehmens eingegangen.

Vorbereitung der Projektakquisition

53

Methoden der Kontaktaufnahme sind (Niedereichholz 1996, S. 36 ff. und Schade 1998, S. 1835-1836): Indirekte Kontaktaufnahme Aufbau eines Kompetenz-Images Vorträge/Messebesuche Fachbücher/Artikel in Fachzeitschriften Zusammenarbeit mit Medien (etwa Massenmedien oder unternehmensinterne Medien wie Mitarbeiterzeitschriften) Mitgliedschaft in Verbänden Seminare, Workshops, Kamingespräche, sogar Honorarprofessuren Aufbau eines Netzwerkes befreundeter Unternehmen (gestützt durch die o. g. Maßnahmen) Direkte Kontaktaufnahme durch Ansprache des Kunden. Diese kann spezifisch oder unspezifisch erfolgen. Spezifisch heißt, dass auf ein potenzielles Projekt Bezug genommen wird, unspezifisch heißt ohne direkten Projektbezug. Wichtigstes Instrument bei der Kontaktaufnahme kann eine Präsentation zur Darstellung der Leistungsfähigkeit sein. Diese direkte Ansprache der Kunden hat jedoch den Nachteil, dass sie von den Kunden aufgrund der mangelnden Sachkenntnis der spezifischen Aufgaben eines Klienten oft als nicht seriös und kompetent wahrgenommen wird und zu „marktschreierisch“ wirkt (Schade 1998, S. 1836). Wichtig ist hierbei, dass Parallelansprachen vermieden werden (Niedereichholz 1996, S. 58) und dass im Sinne eines Buying-Center-Ansatzes bekannt ist, wer bei der Vergabe von Beratungsaufträgen im Unternehmen welche Rolle spielt (Meffert 2000, S. 139). Typische Rollen im Buying-Center in Bezug auf Managementberatung sind (in Analogie zu Backhaus 1999): Betroffene, d. h. diejenigen im Unternehmen, die vom Management her den Bereich mit Beratungsbedarf verantworten, z. B. Abteilungsleiter einer Abteilung, in der Kosten gesenkt werden sollen; Produktmanager für ein Produkt, für das neue Absatzmärkte gesucht werden; Prozessverantwortliche für Prozesse, die verändert werden sollen etc. Fachleute, d. h. die Personen, die im späteren Projektverlauf den „externen Faktor“ darstellen, der integriert werden muss. Dies können z. B. Mitarbeiter sein, die Informationen im Projektverlauf beisteuern oder die Teilmodule inhaltlich übernehmen müssen. Einkäufer, d. h. Personen, die Verträge mit Managementberatungen abschließen dürfen und deren Aufgabe es ist, Rahmenverträge auszuhandeln und Beratungen für bestimmte Projekte auszuwählen.

54

Akquisephase

Entscheidungsträger, d. h. Personen, die aufgrund ihrer Managementstellung die Entscheidung über den Beratereinsatz treffen dürfen. Einflussagenten, d. h. die Personen, die durch gezielte Informationspolitik die Entscheidung für eine Beratung beeinflussen können. Sie haben ein eigenes Interesse an der Entscheidung und besitzen informellen Einfluss. Gatekeeper, dies sind die Personen, die den Informationsfluss innerhalb des Unternehmens bestimmen, oft sind dies die Einkäufer oder Betroffenen, die Kontakt mit der Beratung haben und die anderen Beteiligten im Unternehmen mit Informationen versorgen. Sind diese Personen und ihre Rollen bekannt, so kann sich das Beratungsunternehmen darauf einstellen und im Sinne eines zielgruppenorientierten Marketings allen Personen gegenüber die angemessene Kommunikation betreiben.

Praxisbox 4: Buying-Center Je nach Unternehmensbereich sind unterschiedliche Personen an der Entscheidung über den Beratereinsatz involviert. Grundsätzlich lassen sich die Rollen im Buying-Center aber wie folgt zuordnen: Betroffener – dies kann jede Fachseite sein. Fachleute – dies sind in der Regel Mitarbeiter oder Referenten bzw. Abteilungsleiter in den betroffenen Bereichen. Einkäufer – die Abteilung Dienstleistungseinkauf macht Ausschreibungen und vergleicht Angebote auf Basis von Leistungsbeschreibungen. Entscheidungsträger – dies sind die Bereichsvorstände, die die Beratungsbudgets verantworten, zum Teil sind dies auch Abteilungsleiter. Ein weiterer Stakeholder ist die Abteilung Konzernstrategie, die jeden Beratereinsatz, der von den Fachabteilungen angemeldet wird, freigeben muss. Durch diese übergreifende Koordination wird sichergestellt, dass nicht parallel an Themen gearbeitet wird und dass jeweils die Beratung eingesetzt wird, die für das jeweilige Thema das meiste Know-how hat. Einflussagenten – dies sind je nach Projekt unterschiedliche Mitarbeiter. In der Regel sind dies die mittelbar betroffenen Abteilungsleiter, die über Bereichsvorstandsrunden ihren Einfluss geltend machen können. Gatekeeper – dies können z. B. Mitarbeiter des Einkaufs oder der Fachseite sein.

Ablauf der Akquise

2.3

55

Ablauf der Akquise

Die Projektakquisition läuft üblicherweise so ab, dass das Unternehmen mit Beratungsbedarf eine oder mehrere Beratungen anspricht, die ihm für das zu lösende Problem geeignet erscheinen. Nur in Ausnahmefällen „generieren“ Beratungen ihre Projekte selbst. Dies ist dann der Fall, wenn sie bei einem ihnen bekannten Unternehmen ein Verbesserungspotenzial bemerken und einen Projektvorschlag unterbreiten, wie dieses Potenzial realisiert werden könnte. In dem ersten Gespräch zwischen Unternehmen und Beratung erläutert das Unternehmen den Beratungsbedarf für ein Problemfeld und erste Projektideen. Diese Projektideen sind in der Regel vorhanden, da das Unternehmen die Beratung ja angesprochen hat. Das Problem und die Projektidee werden diskutiert. In der Regel erhält die Beratung dann eine bis zwei Wochen Zeit, um ein Proposal für ein Projekt zu schreiben. Dieses Proposal beschreibt das Projektziel, das Vorgehen, die einzusetzenden Methoden und die notwendigen Ressourcen in einer ersten Fassung. Wenn es für das Verfassen des Proposals notwendig sein sollte, kurze Recherchen durchzuführen, so erfolgen sie in der Regel durch die Beratung ohne Vergütung. Ob die erste Recherche und Analyse tatsächlich zu Lasten der Beratung geht, hängt von der Bedeutung des Projektes ab, für das das Proposal geschrieben wird – und natürlich vom Umfang der notwendigen Recherchen. Das Proposal kann verschiedene Formen haben, ist aber in der Regel nicht sehr umfangreich. Häufig wird das Proposal in Form einer Präsentation erstellt, die dem potenziellen Kunden vorgestellt wird und auf die dann weitere Diskussionen und Veränderungen folgen. Wird das Vorhaben nach dem Proposal abgebrochen, so ist dies zusammen mit dem Grund, warum das Projekt nicht weiter verfolgt wurde, bei der Beratung entsprechend im Wissensmanagement zu dokumentieren. Ziel ist es dann, aus der Ablehnung für weitere Proposals zu lernen. Wird das Proposal akzeptiert, so wird auf dieser Basis ein ausführliches formales Angebot erstellt, dessen Annahme durch den Klienten den Abschluss der Akquisephase bildet. Das Angebot greift hierbei schon viele Aspekte der Projektplanung (siehe Kapitel 3) und der Projektorganisation (siehe Kapitel 4) auf. Auf das Projektangebot und die formale Gestaltung als Vertrag wird im folgenden Abschnitt eingegangen.

56

2.4

Akquisephase

Projektangebot und Vertragsgestaltung

Ein Projektangebot wird von externen Beratungsunternehmen unterbreitet, die ein Projekt für ein fremdes Unternehmen durchführen. Auch bei internen Unternehmensberatungen wird dies in der Regel so gehandhabt, wenn diese in der Projektabwicklung ähnlich externen Beratungsfirmen arbeiten. Selbst bei rein intern durchgeführten Projekten sollte es einen verbindlichen Auftrag für das Projekt geben (vgl. Wolf/Mlekusch 1997, S. 25-27). Das Angebot dient dazu, den beteiligten Parteien Sicherheit zu geben. Das beauftragende Unternehmen oder die beauftragende Stelle erhält Sicherheit über die mit dem Beratungsprojekt verbundenen Kosten und über die Leistung der Unternehmensberatung. Die Leistung wird in Form von Projektverlauf, -inhalt und -ergebnis definiert. Das Beratungsunternehmen seinerseits erhält Planungssicherheit, wie viele Mitarbeiter und Ressourcen für welchen Zeitraum für das Projekt benötigt werden und welche Leistung in welcher Zeit erbracht werden muss. Angebotsbestandteil sollte aber auch sein, welchen Beitrag das Unternehmen, das den Auftrag vergibt, selbst erbringt. Da dieser Beitrag erfolgskritisch ist, sollte auch er schriftlich und verbindlich fixiert werden. In der Regel unterbreitet die Beratung ein Angebot, das unterschriftsreif vorgelegt wird. Durch Unterschrift von Auftraggeber und Beratung wird aus einem Angebot ein rechtsgültiger Vertrag über die Leistung, Pflichten und Kosten im Projekt. Zum Teil existieren in Klientenunternehmen aber auch Standardverträge mit einheitlichen Klauseln in Bezug auf Rechte an den Ergebnissen, Verschwiegenheit, Kontrolle der Arbeitszeiten, Gefahrenübergang etc, die Verwendung finden.

2.4.1

Inhalte eines Angebots

Ein Angebot einer Unternehmensberatung ist üblicherweise immer nach einer bestimmten Struktur aufgebaut. Um sicherzustellen, dass die beabsichtigte Wirkung, die Unsicherheit für beide Vertragsparteien zu reduzieren, erfüllt wird, sollten die folgenden Gliederungspunkte in einem Angebot enthalten sein (vgl. auch Kessler/Winkelhofer 1999, S. 100, 125-126): Darstellung der Ausgangssituation. Dies ist im Rahmen eines Angebots wichtig, da es die Basis für das spätere Handeln ist. Besteht zwischen Auftraggeber und Managementberatung eine abweichende Sicht der Ausgangssituation, wird das fast immer zu Problemen im Projekt führen. Dies liegt daran, dass die weiteren Maßnahmen auf Basis der ersten Analyse der Ist-Situation geplant sind. Bei anderem Verständnis der Ausgangssituation bieten sich meist auch andere Maßnahmen an. Ist die Ausgangssituation zum Zeitpunkt des Ver-


57

tragsabschlusses noch unsicher, so ist dies entsprechend zu vermerken und die Klärung der Ausgangssituation mit als Projektaufgabe aufzunehmen. Projektbegründung. Es muss deutlich herausgestellt werden, welcher in der Ausgangssituation beschriebene Umstand dazu führt, dass das Projekt initiiert wurde. Es wird also beschrieben, warum das Projekt benötigt wird. In der Regel ist dies eine Problem- oder Potenzialbeschreibung. Projektbeschreibung. Diese baut auf der Projektbegründung auf und definiert möglichst genau, wie das geplante Projekt aussehen soll. Dies umfasst die Unterpunkte: Projektgegenstand. D. h. die Frage, auf welchen organisatorischen und funktionellen Bereich sich das Projekt bezieht. Projektziel. D. h. die möglichst präzise Definition dessen, was durch das Projekt erreicht werden soll. Projektabgrenzung. D. h., es erfolgt eine Abgrenzung, was Gegenstand der Projektarbeit ist und was nicht Gegenstand des Projektes ist. Projektstruktur und Meilensteine. D. h. die inhaltliche Vorgehensweise im Projekt und sich ergebende Teilprojekte sowie die verbindlichen Zwischenergebnisse, die erreicht und freigegeben werden sollen. Um eine Projektsteuerung mit Hilfe von Meilensteinen vornehmen zu können, sollten Meilensteine sorgfältig definiert werden. Die als Meilensteine bezeichneten Zwischenergebnisse sollten dabei für das Projekt eine wesentliche Rolle spielen, die Erreichung sollte überprüfbar sein, sie sollten so eindeutig festgelegt sein, dass es exakt feststellbar ist, ob sie erreicht wurden. Idealerweise ist ein Meilenstein so beschrieben, dass die Verantwortung der Erreichung einer Person übertragen werden kann, so dass es eindeutige Zuständigkeiten gibt. Oft werden Meilensteine in der Praxis auch verwandt, um bei Erreichen Teilzahlungen für die Managementberatung vorzunehmen, d. h., es wird sukzessive bei Erreichen der Meilensteine bezahlt (Wolf/Mlekusch 1997, S. 35). Projektablauf (Timings, Laufzeit). D. h. eine möglichst genaue Zuordnung des Ablaufs auf die Zeit. Projektergebnis. D. h. eine Beschreibung, was genau von der Managementberatung (etwa an Dokumenten oder Unterlagen) produziert und dem Auftraggeber bei Abschluss des Projektes übergeben wird. Hierbei handelt es sich um die quasi physische Ausprägung der Erreichung des Projektziels. Beispiele wären ein Endbericht, eine Darstellung aller Prozesse mit Hilfe des Softwareprogramms „Visio“ etc. (vgl. hierzu Berichtswesen, Projektdokumentation) Mögliche Risiken und deren Bewertung. Projektorganisation und notwendige Ressourcen. D. h. in welcher organisatorischen Struktur das Projekt durchgeführt wird, wie die organisatorische Anbindung des Auftraggebers ist und welche Personen zu welchem Umfang mitarbeiten werden. Messgrößen für den Projekterfolgs. D. h. welche Kennziffern über Erfolg oder Misserfolg entscheiden und wer diese wann und wie misst.

58

Akquisephase

Berichtswesen, Projektdokumentation. D. h., wann während der Projektdauer welche Berichte durch wen erstellt werden und an wen sie verteilt werden. Außerdem sollte geregelt werden, wie die finale Dokumentation des Projektes aussieht (vgl. hierzu Projektergebnisse). Kosten und Konditionen. D. h., was das Projekt kosten wird, an welche Kriterien die Auszahlung gebunden ist und wie die Zahlungsbedingungen sind. Geheimhaltungsverpflichtung. D. h. die Regelung der Frage, ob Informationen durch die Managementberatung weitergegeben werden dürfen, bzw. welche Informationen ggf. an wen weitergegeben werden dürfen. Ebenfalls geregelt werden sollte, welche Informationen nach Projektende bei der Beratung verbleiben dürfen. Leistungsort. D. h. an welchen geografischen Ort die Berater arbeiten werden. Dies bezieht sich in der Regel auf die Frage, ob sie vor Ort beim Klienten arbeiten und dort ein Büro mit entsprechender Ausstattung (Telefon, Fax; Netzwerkanschluss etc.) erhalten, oder ob sie in ihrem so genannten Homeoffice im Bürogebäude der Managementberatung sitzen. Dies kann sich bei internationalen Projekten auch darauf beziehen, wo (in welchem Land) Meetings stattfinden. In der Regel ist es aufgrund der notwendigen Mitarbeit des Auftraggebers und aufgrund von Fragen der Akzeptanz der Berater in der Klientenorganisation sinnvoll, dass die Berater vor Ort beim Klienten arbeiten. Dies vereinfacht die Schnittstelle zum Klienten erheblich. Gültigkeitsvorbehalt. D. h. bis wann und unter welchen Voraussetzungen das Angebot gilt. Haftungsregelungen. D. h. die Klärung der Frage, wer für Schäden, die aus dem Projekt entstehen, und den Projekterfolg haftet. Für Managementberatungen im Strategiebereich ist die Haftung in der Regel ausgeschlossen. Das unternehmerische Risiko bei der Durchführung verbleibt beim Auftraggeber (der ja auch der letztendliche Entscheider ist). Anders ist dies etwa bei IT-lastigen Projekten, die ein konkretes Ziel zur Erstellung eines Werkes haben (siehe hierzu die Ausführungen zu Werk- und Dienstverträgen auf Seite 60). Projektmitarbeiter der Managementberatung. Zum Teil werden diese einzeln aufgeführt. Dies hat jedoch den Nachteil für die Beratung, dass man bezüglich des Personaleinsatzes weniger flexibel ist, da man sich auf die jeweiligen Personen festgelegt hat. Für den Auftraggeber bietet sich eine solche Festlegung an, wenn der Projekterfolg an speziell qualifizierte, nicht ersetzbare Mitarbeiter der Managementberatung gebunden ist. In der Angebotsphase werden bei umfangreicheren Projekten zusätzlich zu dem oben geschilderten Angebot noch weitere Dokumente erstellt. Auf diese kann im Vertrag entsprechend Bezug genommen werden (Keßler/Winkelhofer 1999, S. 130; Wolf/Mlekusch 1997, S. 3233). Diese Dokumente beschreiben meist inhaltliche Aspekte detailliert, die so auch Vertragsbestandteil werden: Lastenheft. Dies ist die Spezifizierung des Projektauftrags mit präzisen und verbindlichen Zielen, einem Kostenlimit, genauen Qualitätsanforderungen und Terminen. Es handelt sich


59

also um die Zusammenstellung aller Anforderungen des Auftraggebers (Was ist wofür zu erstellen?). Pflichtenheft. Das Pflichtenheft enthält die Detailspezifizierung von Teilaufträgen und Arbeitspaketen, Vorgehensweisen, konkrete Termine für Teilleistungen, Funktionsbeschreibungen und Qualitätsdefinitionen für Ergebnisse (im Detail). Hiernach kann man sich bei der Projektdurchführung richten und konkrete Entwicklungen vornehmen. Es ist spezifischer als das Lastenheft und beschreibt die unterste Detaillierungsebene der geforderten Projektergebnisse. Es beantwortet also schon die Frage, wie etwas realisiert werden soll. Leistungsspezifikation/endgültige Leistungsbeschreibung. Dies ist dann die entsprechende juristische Vereinbarung für die Projektdurchführung und regelt die mit den Leistungen verbundenen Bezahlungsverpflichtungen, Schadenersatzregelungen, Garantieverpflichtungen etc. Die Attraktivität eines Angebots kann auch dadurch erhöht werden, dass ein allgemeiner Teil mit dem Angebot übergeben wird, der Referenzen, Beispiele bisheriger Projekte, eine Darstellung der Qualifikationen der Beratung und des Personals etc. enthält. Hierbei handelt es sich dann eher um ein Marketinginstrument und nicht um einen Vertragsbestandteil im juristischen Sinne. Inhaltlich unterscheiden sich die Angebote je nach Größe und Komplexität des Projektes. Der Detaillierungsgrad in der Kostenaufschlüsselung variiert stark – so werden die Gesamtkosten bei größeren Entwicklungs-, Software- oder Bauprojekten auf Tätigkeiten heruntergebrochen und detailliert dargestellt. In jedem Fall sind in einem Angebot die Kosten der Beratung selbst und die Kosten für Arbeiten Dritter getrennt aufgeführt. So schwankt die Länge eines Angebots. Für ein Beratungsprojekt sind Angebote von 10-20 Seiten üblich, bei sehr detaillierter Beschreibung des Ergebnisses oder etwa von Teilprojekten können Angebote durchaus auch länger sein. Bei sehr kurzen Projekten mit begrenztem Personalaufwand und Risiko wird man auf ein entsprechend umfangreiches Angebot verzichten und lediglich ein Briefangebot oder ein Bestätigungsschreiben verwenden (siehe auch Niedereichholz 1996, S. 125). Dies sind Kurzfassungen des oben geschilderten Vertrages. Um im Vertrag Lücken oder Fehler zu vermeiden, werden Angebote oft mit Hilfe von Checklisten auf Vollständigkeit geprüft. Diese werden sowohl von Unternehmensberatung als auch vom Auftraggeber genutzt. Die Checklisten liegen oft unternehmensintern vor (etwa in der Einkaufs- oder Rechtsabteilung). Eine Reihe von Checklisten kann man auch im Internet einsehen (Beispielsweise über den Bund der Unternehmensberater in Bonn) oder in Projektmanagement-Büchern (etwa Wolf/Mlekusch 1997 auf der beiliegenden CD-ROM). Aus Sicht des Beratungsunternehmens ist bei der Überprüfung des Angebots auf Vollständigkeit zwischen eventuell nicht bezahlter Vorarbeit (bei Ablehnung des Projektes durch den Auftraggeber) und steigendem Risiko bei mangelnder Definition des Vorhabens abzuwägen. Bei komplexen Projekten ist es daher ratsam, eine bezahlte Vorstudie vorzuschalten, die die Definition des Projektes als Ziel hat. Dies wird insbesondere bei Beratungsprojekten dann

60

Akquisephase

gemacht, wenn ein umfangreiches Pflichten- oder Lastenheft zu erstellen ist. Eine solche Arbeit kann ohne weiteres schon mehrere Monate in Anspruch nehmen und es ist daher für die Managementberatungen unzumutbar, diese unentgeltlich zu erstellen. Reicht die Zeit bei Projektinitiierung nicht aus, rechtzeitig ein Angebot zu schreiben und zu unterzeichnen, kann zur Überbrückung mit einem Letter of Intent (LOI) gearbeitet werden (Heche 2004, S. 36). Dieser dokumentiert die Absicht des Auftraggebers und der Managementberatung, das Projekt zusammen durchzuführen, ohne jedoch das Projekt wie in einem Angebot üblich genau zu definieren. Er sichert der Managementberatung in jedem Fall die Erstattung des bereits für das Projekt angefallenen Aufwands. Für den Auftraggeber hingegen ergibt sich der Vorteil, dass die Projektarbeit zügig beginnen kann.

2.4.2

Vertragsgrundlage

Juristisch wird bei Annahme eines Angebots ein Vertrag geschlossen. Hierbei gibt es zwei mögliche Rechtsgrundlagen, die zum Tragen kommen können: §§ 611 ff. BGB (Dienstvertrag) §§ 631 ff. BGB (Werkvertrag) Beim Dienstvertrag wird der Managementberater zur Leistung des versprochenen Dienstes und der Auftraggeber zur Leistung der vereinbarten Vergütung verpflichtet. Der Berater haftet im Rahmen dieses Vertrages grundsätzlich nicht für den aus seiner Arbeit erwarteten Erfolg, sondern er verpflichtet sich, entsprechend der Vereinbarung für das Projekt zu arbeiten. Das Risiko zur Erreichung des Ziels liegt beim Auftraggeber. Beim Werkvertrag verpflichtet sich der Berater zur Herstellung des versprochenen Werkes, der Auftraggeber verpflichtet sich zur Entrichtung der vereinbarten Vergütung. Der Berater haftet so für den Erfolg seiner Arbeit. Bei einem Werkvertrag wird der Vertrag also über das Ergebnis abgeschlossen. Das Risiko für die Erreichung des Ziels liegt beim Berater. Welche Vertragsart ist nun für Managementberatungsprojekte angemessen? Bei Managementberatungsprojekten ist es aufgrund der in im Punkt 1.5 ab Seite 40 beschriebenen Charakteristika der Projekte von Managementberatungen (hohe Komplexität mit großer finanzieller Bedeutung, Intangibilität des Ergebnisses, Integration des externen Faktors) in der Regel nicht möglich, ein Ergebnis genau zu definieren. Eine wichtige Voraussetzung für einen Werkvertrag – die präzise Beschreibung und Nachprüfbarkeit eines Ergebnisses – fehlt. Dies ist nicht bei allen Projekten so. Bei IT-Projekten kann beispielsweise im Vorfeld über eine Leistungsbeschreibung in einem Pflichtenheft genau festgelegt werden, welche Funktionalitäten ein IT-System aufweisen soll (Wischnewski 2001, S. 180 ff.). Nach Abschluss des


61

Projektes kann festgestellt werden, ob die Funktionalitäten auch erfüllt werden, also die Ergebnisse des Projektes erreicht wurden. In diesem Fall ist ein Werkvertrag möglich. Klassische Managementberatungsprojekte unterscheiden sich wesentlich von diesen IT-Projekten. Zwar kann festgelegt werden, welche Analysen und Empfehlungen zu entwickeln sind, hierbei kann auch festgelegt werden, was Analysefelder sind – eine genaue Spezifizierung der Qualität ist aber in der Regel nicht möglich. Insbesondere der unternehmerische Erfolg bei Befolgung der durch die Managementberatung entwickelten Ratschläge kann schwer garantiert werden. So kann man beispielsweise festlegen, dass eine Markteintrittsstrategie für die Länder Spanien, Frankreich und die Niederlande entwickelt werden soll; man kann auch festlegen, dass hierzu Analysen bestimmter Märkte erfolgen sollen – und auch dass diese Analysen Profile der größten Wettbewerber enthalten sollen. Kaum möglich ist es jedoch, etwas über die Güte dieser Analysen auszusagen und noch schwerer ist es, etwas über die Güte von Empfehlungen zu sagen. Ein Werkvertrag ist daher in der klassischen Managementberatung nicht oder nur begrenzt sinnvoll und möglich. Auch ist die Frage der Haftung für eine Unternehmensberatung bei einem Werkvertrag kritisch zu sehen, würde sie doch bei unternehmerischen Entscheidungen auf Basis ihrer Empfehlungen das unternehmerische Risiko mittragen. Zudem ist die Bewertung des Erfolgs oder Misserfolgs einer Entscheidung aufgrund vielfältiger Einflussfaktoren nur schwer möglich. So kann eine richtige Strategie durchaus aufgrund unvorhersehbarer interner Probleme dennoch im Unternehmen zu Verlusten führen (Niedereichholz 1996, S. 260 ff.). Ein Dienstvertrag ist die angemessene juristische Form für ein klassisches Managementberatungsprojekt. Möchte der Auftraggeber aber nicht darauf verzichten, die Ergebnisse des Projektes in dem Vertrag mit aufzuführen, so bietet sich das folgende Vorgehen an: Es wird ein Dienstvertrag formuliert, in dem die Endprodukte der Tätigkeit aufgeführt und beschrieben sind. Zudem ist ein Passus aufzunehmen, der regelt, was passiert, wenn das Ergebnis nicht im Rahmen des Dienstvertrages erstellt werden konnte. Wer hierbei mögliche entstehende Kosten trägt, ist Ergebnis eines Aushandlungsprozesses und hängt auch vom Risiko und denkbaren Gründen einer Abweichung vom Plan ab. Diese Vorgehensweise bietet sich bei klassischen Managementberatungsprojekten vor allem dann an, wenn die Ergebnisse gut beschrieben werden können. Dies ist zum Beispiel gegeben, wenn in einem Managementberatungsprojekt ein Vertragsabschluss erfolgen oder Schulungen durchgeführt werden sollen. Somit liegt in der Praxis eine Kombination der beiden Vertragsarten vor (Heche 2004, S. 57). Bei klassischer Managementberatung zur Erstellung einer Handlungsempfehlung für das Management sollte eine Haftung jedoch keinesfalls auf den unternehmerischen Erfolg bei Befolgung der Empfehlung bezogen sein. Dies widerspricht der unternehmerischen Verantwortung des Managements, ist wirtschaftlich für die Beratung meist nicht vertretbar und trägt nicht dem Umstand Rechnung, dass der Unternehmenserfolg in der Regel von vielen Faktoren beeinflusst ist.

62

Akquisephase

Eng verbunden mit der Frage der Vertragsart ist auch die Frage des Abrechnungsmodus für die Projektarbeit. Diese kann nach Aufwand berechnet werden oder nach einem Festpreis (Heche 2004, S. 35). Entsprechend verteilt sich auch hier das Risiko für die plangerechte Zielerreichung auf die Parteien. Wenn wie beschrieben ein Angebot mit einer Projektplanung vorliegt, ist es für Managementberatungen üblich, den Preis für das Projekt auf Basis der geplanten Tage mit einem Tagessatz zu berechnen und so zu einem Gesamtpreis zu kommen. Dieser ist auch Teil des Angebots. D. h., das Risiko für die richtige Planung liegt auf Seiten der Managementberatung. Für den Fall der nicht vorhersehbaren oder beeinflussbaren Abweichung vom Plan können im Vertrag entsprechende Klauseln vorgesehen werden, die eine Vertragsergänzung bzw. -verlängerung oder -verkürzung ermöglichen. So ergeben sich verschiedene Varianten von Festpreisverträgen (Schlüter, o. J.): Der firm fixed-price contract, der keine Änderung des Preises zulässt, der excalating fixed-prices contract, der eine stufenweise Anpassung auf Basis vorher festgelegter Eventualitäten beinhaltet (etwa allgemeine Preissteigerung), der incentive fixed-price contract, der Anpassungsklauseln zur Belohnung von Effizienz auf Seiten der Beratung enthält – etwa eine Gutschrift bei Unterschreitung eines Höchstpreises, der performance fixed-price contract, der Sonderentschädigungen für bestimmte Leistungen enthält, etwa für Sonderarbeiten an Wochenenden, sowie der fixed-fee-plus expenses contract, der bestimmte Spesen oder Ausgaben auf Seiten der Beratung zusätzlich erstattet. Ist aufgrund des Neuigkeitsgrades eine genaue Planung nicht möglich, können die angefallenen Beratungstage mit einem Tagessatz berechnet werden (daily rate contracts), wobei man sich vorher auf einen Kostenrahmen einigt. Zusätzlich können Spesen und weitere Kosten berechnet werden (Schlüter o. J.).

Praxisbox 5: Angebotsmaster (Auszug) Um einen einheitlichen Qualitätsstandard bei der Erstellung von Angeboten gewährleisten zu können, hat das Inhouse Consulting von Deutsche Post World Net einen Angebotsmaster erstellt. Dieser „Master“ dient als Vorlage für die Erstellung aller Angebote, so dass diese eine einheitliche Struktur und vergleichbare Inhalte besitzen. Zudem gibt es Verfahrensrichtlinien bezüglich des Ablaufs bis zur Erstellung eines Angebots und eine Unterschriftenregelung, wer Angebote abgeben darf. Auch die Dokumentation der Angebote (und der evtl. folgenden Änderungen) ist geregelt. Jedes Angebot wird in schriftlicher Form und bereits vom Inhouse Consulting unterschrieben in zwei Ausführungen mit einem Anschreiben an den potenziellen Auftraggeber geschickt. Die Annahme des Angebots erfolgt durch Unterschrift durch den Auftraggeber. Die


63

Zweitschrift des so geschlossenen Vertrages geht zur Dokumentation zurück an das Inhouse Consulting, die Erstschrift verbleibt beim Auftraggeber. Abbildung 10 gibt das Anschreiben wieder. Deutsche Post World Net Business Consulting GmbH, Inhouse Consulting, Tulpenfeld 1, 53113 Bonn

Abteilung Name Auftraggeber Position Funktion xxxxx Ort

Bonn, xx.xx.20xx

Angebot über Beratungsleistungen im Projekt xxx Sehr geehrte(r) Herr/Frau Prof. Dr. Name, ausgehend von unserem Gespräch am xx.xx.20xx (mit Ihnen sowie den begleitenden Gesprächen mit Herrn xy) erlauben wir uns, Ihnen unser Angebot über Beratungsleistungen im Projekt xxx zukommen zu lassen. Inhaltlich spiegelt es den Stand unserer Abstimmungen (mit Ihnen sowie Herrn xy) wider. Eine Veränderung der Zusammenarbeit, zum Beispiel in Bezug auf Inhalte oder die Intensität, ist selbstverständlich nach gemeinsamer Vereinbarung möglich. Wir bitten Sie, eines der beiden beiliegenden Angebote umgehend unterschrieben an uns zurückzusenden, damit wir mit den Projektvorbereitungen beginnen können. Für Rückfragen und Erläuterungen stehen wir Ihnen gern zur Verfügung. Wir bedanken uns für Ihr Vertrauen und verbleiben mit freundlichen Grüßen

Unterschrift

Unterschrift

Partner Inhouse Consulting

Associate Partner/Projektmanager Inhouse Consulting

Copyright: Inhouse Consulting Deutsche Post World Net Abbildung 10: Standardanschreiben zum Angebot des Inhouse Consultings

64

Akquisephase

Das Angebot selbst hat eine feste Struktur. Zur Erstellung der Inhalte steht ein erläuternder Text zur Verfügung (hier im Folgenden gekürzt wiedergegeben). Die bearbeitenden Berater haben Zugriff auf einen Mastertext und alte Angebote. Auf diese Art und Weise werden neue Berater kurzfristig in die Lage versetzt, spezifische Angebote zu verfassen. Die letztendliche Verantwortung liegt beim zuständigen Partner der Beratung, der die Angebote korrigiert und freigibt. Die Abbildungen 11 bis 17 geben die Struktur eines solchen Angebots wieder.

Angebot Angebot-Nr. xxx über eine Beratungsdienstleistung des Inhouse Consulting von Deutsche Post World Net

„Bezeichnung Angebot“ (Falls notwendig:) Dieses Angebot ersetzt das Vorgängerangebot Nr. xxx.

DRAFT Version 1.0 vom xx.xx.20xx

Für: Abteilung Auftraggeber Position Standort

Bearbeitet von: Inhouse Consulting Deutsche Post World Net Business Consulting GmbH Name Bonn, xx.xx.20xx

Copyright: Inhouse Consulting Deutsche Post World Net Abbildung 11: Titelblatt Angebotsmaster


65

Inhaltsverzeichnis Seite I.

Ausgangssituation

2

II.

Leitungsbeschreibung A. Projektziel B. Aufgaben des Inhouse Consultings

3 4 4

III.

Generelle Vorgehensweise

5

IV.

Zeitplan

8

V.

Projektorganisation

9

VI.

Projektvoraussetzungen und -risiken A. Voraussetzungen B. Risiken

11 11 12

VII.

Kosten und Konditionen A. Vorbemerkungen zur Angebotslegung B. Mitwirkungspflichten des Auftraggebers C. Projektstandort D. Change Request E. Projektkosten F. Zahlungskonditionen

13 13 13 13 14 14 15

VIII.

Vertraulichkeit

15

IX.

Fristen A. Gültigkeit des Angebots B. Verlängerung des Projektauftrages C. Kündigungsfristen

16 16 16 16

Beraterprofile

Copyright: Inhouse Consulting Deutsche Post World Net Abbildung 12: Struktur Angebotsmaster

18

66

Akquisephase

Angebot Nr. xxx Bonn, xx.xx.20xx

Erläuterung zu ausgewählten Punkten: I.

Ausgangssituation

Inhalt: Beschreibung der aktuellen Situation des Geschäftsbereiches bei Projektbeginn. Informationen über das Geschäftsfeld und die gegenwärtige Marktsituation des betrachteten Bereiches. Beschreibung des Problems, welches Grundlage des Beratungsprojekts ist. Checkfragen: x

Ist die Situation für den Kunden verständlich dargestellt?

x

Besteht zwischen Projektziel und Ausgangssituation ein Zusammenhang?

Sollte Inhouse Consulting in einem größeren Programm ein (Teil-) Projekt übernehmen, so kann hier auch schon die übergeordnete Projektorganisation dargestellt werden, da dies die Ausgangssituation bildet. Gegebenenfalls kann dann schon hier die Projektorganisation insgesamt aufgeführt werden.

II.

Leistungsbeschreibung

A.

Projektziel

Inhalt: Beschreibung der Projektziele. Nennung von einem Gesamt- sowie von Teilzielen des Projekts. Dabei soll sowohl auf strategischen als auch monetären Impact des Projekts eingegangen werden. Als Hilfestellung: Zieldefinition nach der SMART-Formel: Spezifisch: Die Anforderungen sollen eindeutig beschrieben und definiert sein. Messbar: Es muss eine Methode geben, um die Zielerreichung zu messen. Akzeptiert: Das Ziel muss von den Beteiligten akzeptiert werden. Realistisch: Die Ergebnisse sollten mit dem vorhandenen Wissen ohne große Risiken und Unwägbarkeiten erreicht werden können. Termingerecht: Das Projekt ist eingegrenzt durch einen Zeitrahmen, der auf realen und bekannten Anforderungen basiert. Checkfragen: x

Ist der Impact des Projekts genau beschrieben?

x

Wird der Kosten-Nutzen-Aspekt herausgearbeitet?

x

Ist das Ziel präzisiert?

Copyright: Inhouse Consulting Deutsche Post World Net Abbildung 13: Ausgangssituation und Projektziel im Angebotsmaster


67


B.

Aufgaben des Inhouse Consulting

Inhalt: Beschreibung der konkreten Aufgaben, die vom IC im Rahmen des Projekts übernommen werden. Darüber hinaus kann deutlich gemacht werden, welche Projektaufgaben nicht zum Tätigkeitsspektrum des IC gehören (optional, projektabhängig). Checkfragen: x

Sind die Aufgaben vollständig?

x

Passen die Aufgaben zu den Endprodukten?

x

Sind die Aufgaben konkret genug?

I.

Generelle Vorgehensweise

Inhalt: Beschreibung der Projektphasen und Beschreibung der angestrebten Endprodukte der jeweiligen Aufgabe, damit der Kunde den Projektverlauf verfolgen kann. Checkfragen: x

Bauen die Phasen logisch aufeinander auf?

x

Sind die Phasen vollständig?

x

Ist die Vorgehensweise mit den geplanten Ressourcen realistisch?

x

Sind Endprodukte definiert? Passen die Endprodukte zu den Aufgaben?

Beispielabbildung für das Angebot: Phasen Tätigkeit

Ergebnis

xxx

xxx

xxx

xxx

xxx

xxx

xxx

xxx

xxx

xxx

xxx

xxx

Copyright: Inhouse Consulting Deutsche Post World Net Abbildung 14: Beschreibung von Aufgaben und Vorgehensweise im Angebotsmaster

68

Akquisephase


IV.

Zeitplan

Inhalt: Darstellung der Zeitplanung des Projekts. Hier wird der Zeitplan dargestellt, der alle für den Kunden relevanten Aktivitäten beinhaltet. Zusätzlich ist in einem internen Zeitplan noch das Wissensmanagement mit zu berücksichtigen. Checkfragen: x

Ist der Zeitplan kompatibel zum Ablauf?

x

Ist der Zeitplan realistisch unter Berücksichtigung des Staffings?

x

Sind alle notwendigen Schritte enthalten?

x

Ist zu keinem Zeitpunkt eine zu hohe parallele Belastung eingebaut?

Beispielabbildung für das Angebot: Monat

KW

01

Monat 02

03

04

Monat 05

06

07

08

09

Monat 10

11

Vorbereitung Kick-off-Meeting, Workshop, etc. xxx xxx xxx

Teilergebnis-Präsentation xxx xxx xxx xxx xxx Abschluss-Präsentation

Copyright: Inhouse Consulting Deutsche Post World Net Abbildung 15: Zeitplan im Aufgabenmaster

12

13

14


69


IV.

Projektorganisation

Inhalt: Darstellung der Projektorganisation. Möglicher Zusatz: Reportingstruktur („wer berichtet an wen“) und Timingfrequenz („wie oft trifft sich der Lenkungsausschuss, wie oft der Steuerkreis“). Alternativ: Falls die Projektstruktur bei Übernahme von Teilmodulen in größeren Programmen schon vorgestellt wurde, hier nur Nennung des Projektteams von Seiten Inhouse Consulting. Checkfragen: x

Sind alle relevanten Stakeholder mit einer Rolle versehen?

x

Ist der Auftraggeber entsprechend platziert?

x

Ist der im Mastertext angegebene Projektstandort Bonn richtig? Falls nicht, bitte den entsprechenden Projektstandort angeben. Hier ist es notwendig, die anfallenden zusätzlichen Kosten (Hotel, Mietwagen etc.) zu überschlagen und mit dem Partner zu klären, ob diese noch durch das Beraterhonorar abgedeckt sind. Falls nicht, so sind die Projektkosten (Punkt VII.C.) entsprechend anzupassen.

x

Sind die Organisations- und Reportingstrukturen klar definiert?

x

Sind die Rollen des Inhouse Consultings dargestellt (Projektpartner, Projektleiter, Team)?

Beispieldarstellung:

Lenkungsausschuss (Vorsitzender, Teilnehmer) 3-4 Treffen im gesamten Projektverlauf Verabschiedung der Ergebnisse

Steuerkreis (Vorsitzender, Teilnehmer) Treffen ca. alle vier Wochen Kontrolle Projektfortschritt

Projektleitung

Projektleitung

Projektleitung

Fachseite

IC

Fachseite

IC

Kernteam Fachseite (Name, Abteilung, Beteiligung in %)

Kernteam

Kernteam Fachseite (Name, Abteilung, Beteiligung in %)

Kernteam

IC

Copyright: Inhouse Consulting Deutsche Post World Net Abbildung 16: Projektorganisation im Angebotsmaster

Projektleitung

IC

70

Akquisephase


VI.

Projektvoraussetzungen und -risiken

A.

Voraussetzungen

Inhalt: Darstellung der Rahmenbedingungen, die die Fachseite erfüllen muss, damit das Projekt von Seiten Inhouse Consulting erfolgreich bearbeitet werden kann. Checkfragen: x

B.

Sind außer den unten genannten noch weitere projektspezifische Voraussetzungen zu erwähnen (Zugriff auf spezielle Datenbanken etc.)? Risiken

Inhalt: Spezifische Projektrisiken, die sich aus der Situation bei Projektstart geben. Hier sind nur außergewöhnliche Risiken zu nennen, nicht die allgemeinen Risiken, die jedes Beratungsprojekt mit sich bringt. Ist das Projekttiming etwa von externen Entscheidungen abhängig, so ist auf diese Abhängigkeit zu verweisen. x

Sind die genannten Risiken außergewöhnlich und projektspezifisch?

x

Sind die möglichen Auswirkungen spezifizierbar?

Copyright: Inhouse Consulting Deutsche Post World Net Abbildung 17: Beschreibung von Projektrisiken im Angebotsmaster Das Beispiel aus der Praxisbox 5 macht deutlich, dass bei formalem Abschluss der Akquisephase durch ein unterschriebenes Projektangebot schon weite Teile einer Projektdefinition und -planung erstellt sein müssen. Nach Auftragserteilung erfolgt dann in der Regel noch eine detaillierte Planung (etwa auf Aufgabenebene für Teilprojekte). Insofern handelt es sich bei den Projektphasen um überlappende und iterative Abläufe. Ein wichtiger Punkt im Rahmen eines Angebotes ist noch, wie mit notwendigen oder gewünschten Änderungen des Projektumfangs oder -ziels nach Projektstart umgegangen wird. Solche Änderungen können die Vereinbarungen eines Angebots hinfällig werden lassen, so dass eine Änderung der Vereinbarung notwendig wird. Tatsächlich kommt es häufig vor, dass sich die Rahmenbedingungen während eines Projektes so ändern, dass eine Neuausrichtung notwendig wird. Auch kann es sein, dass erste Projektergebnisse eine Neuformulierung des Ziels sinnvoll erscheinen lassen. Einen solchen Änderungswunsch seitens des Auftraggebers nennt man Change Request. Üblich ist, eine ergänzende Vereinbarung zu schließen, die das neue Projektziel oder Vorgehen dokumentiert und damit das Angebot ergänzt (Wolf/Mlekusch 1997, S. 195). Ohne ein solches neues Dokument läuft das Beratungsunternehmen Gefahr, keine verbindliche Basis für den Einsatz mehr zu haben, so dass Abrechnung und Erfolgsbe-


71

urteilung nicht mehr auf gesicherter Basis erfolgen können. Eine formale Dokumentation eines Change Requests ist daher unbedingt vorzunehmen. Die folgende Praxisbox 6 zeigt ein Beispiel für die Dokumentation eines Change Requests.

Praxisbox 6: Change Request Im Inhouse Consulting ist ein Standardprozess etabliert, wie mit sich ändernden Rahmenbedingungen, Projektzielen etc. umzugehen ist. Dabei ist es zunächst einmal wichtig, die Berater dafür zu sensibilisieren, dass es trotz sorgfältiger Planung sinnvoll sein kann, Projektziel, Vorgehensweise oder Ressourceneinsatz zu ändern. Die folgende Abbildung 18, die in Schulungen für Projektleiter eingesetzt wird und Teil der Projektmanagementunterlagen im Inhouse Consulting ist, verdeutlicht dies und dient dazu, dass die Projektleiter offen mit Änderungen umgehen.

Change Request Management However well you prepared your proposal and planned your project:

THINGS CHANGE!

Abbildung 18: Motivationschart Change Request Der definierte Prozess bei Notwendigkeit einer Änderung und damit eines Change Requests ist recht einfach gehalten, damit er auch tatsächlich angewendet wird. Er umfasst die folgenden Schritte: Dokumentation der notwendigen oder vom Klienten gewünschten Änderungen in einem Standard-Formular (kurze Übersichtstabelle) Abschätzung der Auswirkungen der Änderungen auf das Projekt Aufstellung der Handlungsoptionen und Bewertung der Optionen Diskussion der Optionen mit dem zuständigen Projektpartner und dem Auftraggeber. Aushandlung der weiteren Vorgehensweise

72

Akquisephase

Dokumentation der vereinbarten weiteren Vorgehensweise und Gegenzeichnung durch den Auftraggeber Das Template (Formular), das für den letzten Schritt eingesetzt wird, ist in den nächsten beiden Abbildungen 19 und 20 dargestellt. Bei umfangreicheren Änderungen kann auch ein neues Angebot Basis der weiteren Vorgehensweise werden. #:

Project:

Assignment Mgr:

Client:

Change-subject:

Date: Change #:

• < Describe the proposed change > Description of proposed change

• < What are the reasons for the proposed change? > Reasons for Change

Impact of not implementing the change

Priority

• < List risks and resulting impact on project in case not implementing the proposed change>

High

Medium

Low

< Explain reasons for prioritization>

Abbildung 19: Change Request Template (Teil 1) #:

Project:

Assignment Mgr:

Client:

Change-subject:

Date: Change #:

Impact on Scope

• < Describe the proposed change >

Impact on Cost

• < What are the reasons for the proposed change? >

Impact on Schedule

• < List risks and resulting impact on project in case not implementing the proposed change> • < Describe risks associated with implementing the change >

Risks

Approval

Yes No

Abbildung 20: Change Request Template (Teil 2)


73

3 Projektplanung

Planung und Projekterfolg stehen in direktem Zusammenhang. Ohne eine gewissenhafte Projektplanung ist die Wahrscheinlichkeit höher, dass es zu Verzögerungen kommen wird, Qualitätsmängel auftreten oder Budgets überzogen werden (Litke 1995, S. 89). Für Managementberatungen ist es wichtig, das Projektziel und die Planung der Vorgehensweise mit dem Auftraggeber genau abzustimmen. Nur so kann sichergestellt werden, dass das Projekt im Sinne des Auftraggebers durchgeführt wird. Die für Beratungsunternehmen und Auftraggeber ungünstige Situation, nach Abschluss des Projektes festzustellen, dass der Auftraggeber eigentlich andere Vorstellungen von Projektziel und -vorgehen hatte, kann nur durch eine gute und abgestimmte Planung vermieden werden. Diese sorgt für die notwendige Transparenz auf beiden Seiten. Formal erfolgt diese Abstimmung durch das Angebot (siehe vorheriges Kapitel). Zudem bilden die Zielformulierung und die Projektplanung die grundlegende Basis für eine Projektkontrolle. Denn ohne Vorgabe des Zieles kann auch nicht ermittelt werden, ob das Projekt noch auf dem richtigen Weg ist. Die Projektplanung sollte entsprechend Soll-Werte für alle relevanten Aspekte eines Projekts ermitteln. Im Rahmen der Projektplanung werden daher nachfolgend die für den Projekterfolg wohl wichtigsten Punkte behandelt:6 Zielfindung Projektstruktur Zeitplanung, Ressourcenplanung, Wirtschaftlichkeitsanalyse Risikomanagement

6

Zum Teil wird in der Literatur die Zielfindung in die Projektplanung integriert. Natürlich müssen Ziele auch geplant werden, da man sich bei Ziel- und Projektdurchführungsplanung jedoch unterschiedlicher Methoden bedient, wurde dies hier getrennt betrachtet.

74

Projektplanung

Praxisbox 7: Planungsschritte Im Common Consulting Approach (CCA) ist ein Stufenplan vorgegeben, nach dem die Projekte des Inhouse Consultings geplant werden. Dieser ist in der folgenden Abbildung 21 dargestellt. Im ersten Schritt der Planung sind die Ziele festzulegen (Agree on objectives). Danach sind im zweiten Schritt die abzuliefernden Ergebnisse zu definieren, die notwendig sind, um die Ziele zu erreichen (Agree on deliverables). Der dritte Schritt befasst sich dann mit der Ermittlung von Abhängigkeiten innerhalb des Zielsystems und zwischen den einzelnen zu erstellenden Ergebnissen (Determine interdependencies). Sind diese Abhängigkeiten ermittelt, so kann im vierten Schritt die Planung der Arbeitspakete bzw. Aktivitäten erfolgen (Plan activities). Diesen werden dann im fünften Schritt Verantwortlichkeiten zugeordnet (Personen oder Teilprojekte) (Assign responsibilities) und dann werden die personellen, sachlichen und monetären Ressourcen zur Abarbeitung der Arbeitspakete in einer detaillierteren Planung bestimmt (Plan resources). Integrated Project Plan

6 5 4 3 2 1

Plan resources

Assign responsibilities Plan activities

Determine interdependencies Define deliverables Agree on objectives

Abbildung 21: Planungsschritte im CCA Für jede Stufe in diesem Planungsablauf gibt es für die Consultants eine detaillierte Beschreibung der Vorgehensweise und Hinweise, auf welche Punkte besonders zu achten ist. Zudem gibt es eine Reihe von Vorlagen (die so genannten Templates), die bei der Durchführung verwendet werden und diese so erleichtern.

Zielfindung

3.1

75

Zielfindung

In der Akquisephase wurde zwischen Auftraggeber und Managementberatung grundsätzlich geklärt, ob Projekt und Projektziel sinnvoll sind. Nun geht es darum, das Projekt durchzuplanen, d. h. gedanklich das Ergebnis und den Ablauf vorwegzunehmen. Hierzu muss man sich noch einmal mit dem Projektziel auseinander setzen. Es ist detaillierter zu beschreiben als in der Akquisephase und es ist vor allem zu operationalisieren, d. h. zu beschreiben, wie die Zielerreichung objektiv festgestellt werden kann. Das Projektziel wird hierzu schriftlich definiert. Dies bedeutet, dass Zielinhalt (Was soll erreicht werden?), Zielausmaß (Wie viel soll erreicht werden?) und Zielzeit (Bis wann soll dies erreicht werden?) festgelegt werden (Boy/Dudek/Kuschel 1997, S. 45). Die Verantwortung für die Zielformulierung liegt beim Auftraggeber und beim Projektmanager der Managementberatung. Der Auftraggeber muss verbindlich festlegen, was er will, und der Projektmanager muss den Auftrag bestätigen und erklären, dass er das Ziel auf Basis der geplanten Vorgehensweise erreichen kann (siehe hierzu auch den Abschnitt Akquisephase, 2.4.1). Maßgeblich am Projekt beteiligte Personen sollten zusätzlich bereits in dieser Phase einbezogen werden. Zum einen können diese die mögliche Zielerreichung bereits am Anfang realistisch beurteilen, zum anderen wird so Akzeptanz für die Ziele geschaffen. Ein Ziel, an dessen Formulierung man beteiligt war, wird in der Regel von Menschen besser akzeptiert als extern vorgegebene Ziele. In Projekten, die eine völlig neue, bisher nicht da gewesene Aufgabenstellung beinhalten, kann ein angestrebter und handlungsleitender Konkretisierungsgrad des Zieles nur unvollkommen erreicht werden. Es herrscht Unsicherheit. Dennoch sollte auch in diesem Fall alles soweit wie möglich definiert und festgelegt werden, damit gerade in einer solchen Situation die Unsicherheit soweit möglich beseitigt wird. Ggf. muss man in den ersten Projektphasen das Ziel dann weiter konkretisieren. Dies muss entsprechend in die Projektplanung aufgenommen werden (Litke 1995, S. 31). Eine Möglichkeit, solche im Vorhinein mit Unsicherheit behafteten Projekte durchzuführen, ist das Rolling Wave Planning (RWP). Zu Beginn des Projektes wird nur ein grober Rahmen für das Ziel und die Vorgehensweise festgelegt. Während der Projektdurchführung werden dann in festgelegten Phasen Ziel und Vorgehensweise unter Berücksichtigung der bis jetzt gemachten Erfahrungen überdacht und evtl. Ziele und Vorgehensweise neu und detaillierter beschrieben. Der Weg und das Ziel werden so „quasi beim Gehen“ stets genau festgelegt. Diese Art der Planung sollte nur für Projekte mit hohem Innovationsgrad gewählt werden. Sie stellt hohe Anforderungen an das Projektmanagement. Zudem vermittelt sie dem Auftraggeber im

76

Projektplanung

Vorfeld kein klares Bild von Vorgehen und Ergebnis des Projektes. Auftraggeber möchten dies jedoch in der Regel, um ihre Unsicherheit zu reduzieren. Um eindeutige Ziele zu erreichen, an denen sich ein Projekt orientieren kann, ist es in der Praxis hilfreich, bei der Zielformulierung gewisse Grundsätze zu beachten (vgl. auch Litke/ Kunow 2002, S. 32; Litke 1995, S. 32): Die Zielformulierung sollte keine möglichen Lösungen enthalten und sich nur auf den Ergebniszustand beziehen. Die Freiheit zur Wahl eines Weges zur Zielerreichung sollte im Projekt möglichst gegeben sein. Ziele müssen so formuliert sein, dass alle Beteiligten das gleiche Verständnis von den Zielen haben. D. h., unterschiedliche Interpretationen müssen durch präzise Formulierungen ausgeschlossen werden, um Missverständnisse zu vermeiden. Ziele sollten eindeutig messbar sein, so dass die Zielerreichung klar festgestellt werden kann. Dies erlaubt dann auch die Steuerung im Projekt anhand des Zielerreichungsgrades und erlaubt am Projektende auch die Beurteilung des Erfolgs. Ziele sollten vollständig sein, d. h., sie sollten alle Aspekte enthalten, die für die Auswahl eines Lösungswegs relevant sind. Dabei können Ziele neben einem gewünschten Zustand auch nicht gewünschte Zustände ausschließen. Ziele sollen widerspruchsfrei sein. Ziele müssen schriftlich dokumentiert werden. In der Regel geschieht dies bereits im Angebot. Hierbei kann zwischen Muss-Zielen und Wunsch-Zielen unterschieden werden. Muss-Ziele müssen zwingend bei Projektende erreicht werden und sind daher besonders präzise zu formulieren. Ziele sollen zugleich anspruchsvoll und erreichbar sein. Sind sie nicht anspruchsvoll, so besteht die Gefahr, dass sie nicht ernst genommen werden. Sind sie nicht erreichbar, so können sie nicht handlungsleitend sein und wirken zudem noch demotivierend auf die Mitarbeiter.

Praxisbox 8: Das SMART-Prinzip Eine Kurzversion der Operationalisierung und der Grundsätze für die Zielformulierung ist das bekannte SMART-Prinzip. Dies findet auch im Inhouse Consulting im Angebotsmaster Anwendung (siehe Abbildung 13 auf S. 66). Die im Angebot formulierten Ziele sind anhand des SMART-Prinzips zu prüfen. Die Anfangsbuchstaben der Kriterien bilden das Wort SMART (siehe auch für viele: The Goal Setting Site 2004 oder Palmer 2000):

Zielfindung

77

Spezifisch

Terminiert Ziel

Messbar

Realistisch

Akzeptiert Abbildung 22: SMART-Prinzip Spezifisch heißt, dass ein Ziel sich direkt auf die Projektarbeit beziehen und klar abgegrenzt von anderen Dingen sein muss. Terminiert bedeutet, dass präzise festgelegt sein muss, wann das Ziel erreicht sein soll. Dabei muss es realistisch sein, denn unrealistische Ziele werden nicht ernst genommen und verlieren so ihre steuernde Wirkung. Akzeptiert heißt, dass die Menschen im Projekt die Ziele auch erreichen wollen und nicht heimlich andere Ziele verfolgen. Zuletzt muss jedes Ziel möglichst objektiv messbar sein, damit der Zielerreichungsgrad objektiv festgestellt werden kann. Das folgende Beispiel zeigt gut und schlecht operationalisierte Ziele. Die „guten“ Ziele entsprechen dem SMART-Prinzip, die „schlechten“ nicht.

schlecht

gut Reduzierung der Zeit zwischen Anforderung und Lieferung von Büromaterialien der DPAG um 30 % bis Oktober 2004 (Messgröße ist die Standard-Messmethode der Abteilung Performance Management).

Erhöhung der Effizienz im Beschaffungsprozess.

gut

schlecht Reduktion der Logistikkosten.

Empfehlung für Verbesserungsmaßnahmen zur Reduktion der internatio-nalen Bodentransportkosten von 3.5 Mrd. Euro auf 3.0 Mrd. Euro bis zum Jahresende 2005.

Abbildung 23: Gut und schlecht operationalisierte Ziele

78

Projektplanung

Bei umfangreicheren Aufgaben kann zur Erreichung der Operationalisierung von Zielen mit einer Zielhierarchie gearbeitet werden. Diese erlaubt die Gruppierung von Zielen und die Bezugnahme von Zielen auf konkrete Sachverhalte. Es gibt hierbei grundsätzlich zwei Vorgehensweisen, wie die hierarchische Anordnung von Zielen vorgenommen werden kann: Top-down: Ein Gesamtziel (oder auch Globalziel) wird in Teilziele, die so genannten Zielklassen, heruntergebrochen (detailliert). Diese Zielklassen können dann wiederum in operationale Detailziele zerlegt werden usw. Bottom-up: Zusammenfassung von operationalen Detailzielen zu übergeordneten Zielklassen (Teilzielen) und diese wiederum zu einem Gesamtziel. Managementberatungsprojekte starten in der Regel aus der Top-down-Sichtweise heraus. Der Auftraggeber hat ein Problem, woraus sich ein übergeordnetes Ziel ergibt. Die Systematik der Zielhierarchie erlaubt es, verschiedene Aspekte bei der Operationalisierung zu berücksichtigen, und eignet sich daher gerade in einer übersichtlichen grafischen Darstellung dazu, ein Globalziel vollständig auf mehrere konkrete operationale Teilziele herunterzubrechen. Andererseits erlaubt sie – ausgehend von operationalen Detailzielen – die Prüfung, ob alle formulierten Detailziele auch der Erreichung des angestrebten Gesamtziels dienen. Abbildung 24 zeigt die Struktur einer Zielhierarchie:

Gesamtziel

operationales Detailziel

Zielklasse

Zielklasse



Zielklasse

Quelle: Litke (1995) S. 34 (mit Änderungen) Abbildung 24: Strukturbeispiel für eine Zielhierarchie Für das Projekt eines Expressdienstleisters zur Professionalisierung des Kundenservices kann dies beispielhaft wie folgt aussehen:

Operationalisierung: Kosten der telefonischen Serviceannahme zwei Jahre lang je Jahr um 15 % senken, Kosten für Vor-OrtServicetechniker zur Bearbeitung von Softwareproblemen ab nächstem Jahr um 25 % senken.

operatives Detailziel: Kosten des Kundenservices senken.

Zielklasse: Finanzziele operatives Detailziel: Art der erbrachten Serviceleistungen erweitern. Operationalisierung: Computergestützter Remoteservice bei Softwareproblemen für Großkunden wird ab Projektstart innerhalb von zwei Jahren implementiert.

operatives Detailziel: Einnahmen für Serviceleistungen erhöhen.

Operationalisierung: Einnahmen je erbrachter Serviceleistung ab nächstem Jahr um 5 % p. a. erhöhen.

Zielklasse: Leistungsziele operatives Detailziel: Kundenzufriedenheit erhöhen.

Operationalisierung: Beschwerdezufriedenheit innerhalb von zwei Jahren auf 5er-Skala gemessen um einen Punkt verbessern.

operatives Detailziel: Service jeweils verbessern.

Operationalisierung: Vor-Ort-Service auf alle Kundengruppen ausweiten.

Operationalisierung: Anzahl der telefonisch eingehenden Beschwerden auf 90 % gemessen an allen Beschwerden bis in zwei Jahren erhöhen.

operatives Detailziel: Kundenkontakte gezielter steuern.

Zielklasse: kundenorientierte Ziele

Gesamtziel: Professionalisierung des Kundenservices für Businesskunden innerhalb von zwei Jahren. Hierbei soll ein mit den jeweils besten Wettbewerbern konkurrenzfähiger Kundenservice erreicht werden.

Zielfindung 79

Abbildung 25: Zielhierarchie am Beispiel Kundenservice

80

Projektplanung

Bei der Zielformulierung ist zu überlegen, inwieweit es interne bzw. externe Einflüsse und Einflussgruppen gibt, die ein Interesse an der Zielerreichung haben, oder ob sie evtl. sogar Nachteile durch die Zielerreichung befürchten müssen. Diese Interessen sind entsprechend in die Zielformulierung mit einzubeziehen. Das Expertenwissen der Betroffenen sollte genutzt werden, um mögliche Gefahren und Wechselbeziehungen zu erkennen. Werden die relevanten Einflussgruppen nicht einbezogen, so besteht die Gefahr, dass nach Projektstart durch diese Personen eine erneute Zieldiskussion gestartet wird. Dies ist natürlich zu vermeiden, da es den Projektablauf stört, Mitarbeiter verunsichert und im schlimmsten Fall zur Folge hat, dass die Projektziele geändert werden müssen. Nur in Ausnahmefällen sollten Ziele nicht von Anfang an offen diskutiert werden. Dies kann unter Umständen sinnvoll sein, wenn schon von Beginn an Widerstände erwartet werden müssen, die den Projekterfolg gefährden. Ein Beispiel hierfür sind Projekte zum Personalabbau durch IT-Lösungen, wenn im Falle von mangelnder Kooperation der Mitarbeiter die Arbeitsfähigkeit im Projekt nicht gegeben ist. Und natürlich gibt es Projekte, die aufgrund ihrer strategischen Bedeutung der Geheimhaltung unterliegen. Dies wären beispielsweise Projekte zu einer Internationalisierungsstrategie, bei der die Informationen nicht an den Wettbewerber gelangen dürfen und der Kreis der involvierten Personen daher absichtlich sehr klein gehalten wird. Ein anderes Beispiel wären Projekte zu Firmenübernahmen, bei denen ein Bekannt werden des Vorhabens den möglichen Kaufpreis nach oben treiben würde. Je nach Komplexitätsgrad des Ziels reichen einige Zeilen zur Formulierung des Ziels aus, oder es muss – wie etwa in EDV-Projekten – ein sehr umfangreiches Pflichtenheft erstellt werden, das auf bis zu mehreren hundert Seiten genau spezifiziert, was Ziel des Projektes ist. Während des gesamten Projektablaufs dienen die nach den genannten Grundsätzen entwickelten Ziele als leitender Handlungsmaßstab. Sie erlauben die Prüfung der Sinnhaftigkeit des Vorgehens und der einzelnen im Projekt enthaltenen Schritte. Die weitere Projektplanung muss sich an den Zielen ausrichten.

Praxisbox 9: Context Model In einem ersten Schritt bei der Zieldefinition wird im Inhouse Consulting ein Kontextmodell eingesetzt, das dazu dient, Gesamtziele eines Projektes in ihrer Auswirkung innerhalb des Unternehmens zu beurteilen und dann zu operationalisieren. Hierzu wird ein Template eingesetzt, das in der folgenden Abbildung 26 zu sehen ist. Das Kontextmodell (oder Context Model) dient dabei dazu, sich zu verdeutlichen, ob die geplanten Ergebnisse des Projektes (Deliverables/Output) den strategischen Zielen entsprechen (Strategic goals) und im Rahmen des gegebenen Inputs und der Rahmenbedingungen (Environment/Limitations) erreichbar sind. Zudem sollen Aktivitäten abgeleitet werden, die zur Zielerreichung notwendig sind.

Projektstruktur (Work Breakdown Structure)

81

Das Template wird noch vor der eigentlichen Planungsphase eingesetzt, um ein Verständnis für das Projekt, dessen Rahmenbedingungen und Ziele zu erlangen. In späteren Planungsschritten wird das Projekt natürlich sehr viel detaillierter heruntergebrochen – um aber den Blick für das Ganze nicht zu verlieren, wird das Projekt zunächst im Context Model generell eingeordnet.

Context Model #:

Project:

Assignment Mgr:

Client:

Environm./Limitations What constraints do we face? What is given? What cannot be changed?

Input What potentially useful resources, data, information do we already have?

Project assignment What are we up to?

Activities

Date:

Strategic goals To what strategic benefits is the project contributing? What does the project customer want to achieve?

Deliverables/Output What should be the outputs of our project? What exactly is to be different after implementation of the project? How do we know that we have reached our objectives? What is outside the scope of our project?

What steps do we need to take to complete the project as planned?

Quelle: Inhouse Consulting Deutsche Post World Net in Anlehnung an Mayrshofer/Kröger (1999, S. 127) Abbildung 26: Context Model

3.2


Vor Abgabe eines Angebots war es in der Akquisephase schon erforderlich, die Projektstruktur grob zu planen, damit der notwendige Aufwand an Ressourcen und Zeit geschätzt werden konnte. An diese Planung wird jetzt, nach Erhalt des Beratungsauftrags, wieder angeknüpft. Nun ist eine detaillierte Projektstrukturplanung erforderlich, die sehr aufwändig sein kann. Wurde in der Akquisephase – was wünschenswert ist – schon detailliert die Vorgehensweise für eine eventuelle spätere Durchführung erarbeitet, so sind die Voraussetzungen für die weitere Planung günstig. Bei sehr umfangreichen Projekten, die später bei der Durchfüh-

82

Projektplanung

rung den Einsatz vieler spezialisierter Berater erfordern, wird man die Planung zu Beginn sinnvollerweise nicht zu weit führen. Die bei der Durchführung involvierten Mitarbeiter werden dann selbst den letzten erforderlichen Detaillierungsgrad auf Basis von Rahmenvorgaben planen. Auch hier zeigt sich dann, dass, wie bereits gesagt, die Phasen des Projektablaufes kein starres System sind, sondern nach Anforderung des Projektes unterschiedlich durchlaufen werden können. Was aber ist nun ein Projektstrukturplan? Ein Projektstrukturplan ist die Zerlegung der Gesamtaufgaben in enthaltene Teilaufgaben. Das gesamte Projekt wird hierfür in seine Elemente gegliedert. Diese Aufgliederung ist die Basis der später folgenden Planung der Vorgehensweise und sollte daher detailliert erfolgen. Nur so kann man in der folgenden Planung den Aufwand realistisch abschätzen und vermeidet den Fehler, die einzelnen Aufgaben zu unterschätzen. Griffig formuliert kann man auch sagen: „Teile und herrsche!“ (Portny 2001, S. 69). Die Strukturierung mit einem Projektstrukturplan bietet folgende Möglichkeiten (Litke 1995, S. 96, 102; Portny 2001, S. 69): Einen Überblick über das Projekt erleichtern, indem Teilaufgaben und Zusammenhänge aufgezeigt werden. Die Vollständigkeit in der Vorgehensweise gewährleisten und kein Detail vergessen. Die Ressourcen und die nötige Zeit für die Teilaufgaben planen. Dies für ein umfangreiches Gesamtprojekt zu tun ist in der Regel aufgrund fehlender Übersichtlichkeit nicht möglich. Teilprojekte bilden, die entsprechend in der Projektorganisation verankert werden können. Interdependenzen aufzeigen, auf die dann gezielt durch Schnittstellenmanagement und in der Kommunikation eingegangen werden kann. Für den Projekterfolg sind oft einzelne Aspekte wichtig, die nicht vergessen werden dürfen. Auf den ersten Blick erscheinen diese eher einfach zu lösen und bekommen daher nicht die notwendige Aufmerksamkeit, sie können aber das gesamte Projekt gefährden (Wolf/Mlekusch 1997, S. 111). So ist z. B. die Inbetriebnahme eines Call Centers erst möglich, wenn der Innenausbau der Immobilie mit allen Einzelheiten wie etwa dem Bodenbelag und den sanitären Einrichtungen abgeschlossen ist. Die Call-Center-Mitarbeiter müssen nicht nur geschult sein, sondern auch ein Passwort für die Computer besitzen, und es muss geklärt sein, wie sie auch für die Spätschicht in das Gebäude gelangen können. Jedes dieser Elemente kann die Einhaltung des Starttermins der Inbetriebnahme – und damit den Projekterfolg – beeinflussen und darf daher nicht vergessen werden. Eine Projektabwicklung ohne Projektstrukturplan führt nicht nur zu schlechterer Planung, sonders erzeugt bei den Beteiligten oft auch ein Gefühl der Unsicherheit, welches die Leistung negativ beeinflusst und unangenehm ist. In Folgenden soll eine mögliche Vorgehensweise zur Erstellung eines Projektstrukturplans beschrieben werden. Diese Darstellung ist sehr ausführlich und beschreibt ein ideales Vorge-


83

hen zur Erstellung eines Projektstrukturplans. In der Praxis wird die Erstellung in der Regel schnell gehen müssen. Die einzelnen Schritte werden daher zusammengefasst. Die Darstellung bietet jedoch den Vorteil, dass sie zeigt, worauf bei der Erstellung des Projektstrukturplans zu achten ist, um Fehler zu vermeiden, die im gesamten Projektablauf zu spüren sind.

Aufgabenbeschreibung anhand der Zieldefinition Auswahl der Strukturierungsmethode

induktiv deduktiv

Sammlung aller Aufgabenelemente (Aufgaben, Arbeitspakete, Oberpunkte etc.) mit Metaplan o. Ä. Auswahl Strukturierungselemente

Entwurf erster Projektstrukturplan

objektbezogen funktionsbezogen A

C D

E

D

E

A B C D D 3 3 3 C 3 z B 3

Kompatibilitätsprüfung

Endgültiger Projektstrukturplan

B

organisationsbezogen geografisch

A

B

Cneu

In Anlehnung an Litke 1995, S. 97 Abbildung 27: Schrittweises Vorgehen bei der Aufstellung eines Strukturplans Vor der Erstellung ist zunächst festzulegen, ob die Strukturierungsaufgabe als Einzel- oder Gruppenarbeit durchgeführt werden soll. In der Regel werden Gruppenarbeiten gewählt, wenn die Aufgabe komplexer ist. Es gilt der einfache Grundsatz, dass mehrere Personen eine höhere Vollständigkeit bei der Sammlung und Zusammenstellung der Aufgaben erreichen werden. Auch sichert die Beteiligung der Betroffenen hier die spätere Akzeptanz. Basis der Erstellung eines Projektstrukturplans ist das Ziel des Projektes, d. h., eine gestellte Aufgabe ist zu erfüllen. Die Aufgabe des Projektes muss möglichst genau beschrieben werden. Diese könnte beispielsweise heißen: „Planung und Inbetriebnahme einer zentralen Kun-

84

Projektplanung

denhotline zur Beantwortung aller Anfragen allgemeiner Art.“ Diese Projektaufgabe muss in operationalisierten Detailzielen konkretisiert werden. Wie wird die Projektaufgabe in Teilziele gegliedert? Zunächst ist die grundsätzliche Strukturierungsmethode zu wählen. Hierbei unterscheidet man induktives und deduktives Vorgehen. Induktiv (Bottom-up) heißt vom Einzelnen zum Allgemeinen zu kommen. Diese Vorgehensweise wählt man, wenn ein Gesamtüberblick über eine komplexe Aufgabe noch nicht besteht, aber viele Teilaufgaben schon bekannt sind. Hat man bereits einen guten Überblick über die Aufgabe, dann kann man daraus Teilaufgaben ableiten bzw. ermitteln (deduktiv, Top-down). Der Vorteil ist, dass die Strukturierungsaufgabe deduktiv in der Regel schneller durchzuführen ist, wenn man sich an einer bekannten Struktur orientieren kann. Die ausschließliche Verwendung einer Methode (induktiv oder deduktiv) ist dabei nicht dogmatisch zu sehen. Oft wird man gemischt vorgehen. In Bereichen, wo zum Teil schon Teilelemente der Aufgabe bekannt sind, induktiv – in anderen Bereichen, in denen noch Unsicherheit herrscht, deduktiv. Wichtig ist, dass im Ergebnis die Gesamtaufgabe in ihre Teilaufgaben zerlegt ist. Portny (2001, S. 70) sagt folgerichtig: „Das Zauberwort bei der Aufgabenbeschreibung ist Unterteilung.“ Hierzu kann man Techniken wie Brainstorming oder die Metaplantechnik einsetzen. Letztere hat sich besonders zur Strukturierung bewährt. Geht man induktiv bei der Metaplantechnik vor, dann schreiben die an der Strukturierung beteiligten Mitarbeiter die Teilaufgaben, die sie für das Projekt für wichtig und notwendig halten, auf Pappkärtchen (Metaplankarten). Diese werden durch einen Moderator gesammelt und auf einer Pinnwand für alle sichtbar zu einem Strukturplan zusammengeführt. Durch das getrennte Notieren der Teilaufgaben wird sichergestellt, dass jeder Teilnehmer seine Punkte (Teilaufgaben) unbeeinflusst aufschreiben kann und durch die moderierte und für alle sichtbare Zusammenführung ein Strukturplan als Gesamtergebnis erreicht wird. Auch bei der deduktiven Vorgehensweise arbeitet man sinnvollerweise mit Metaplantechnik. Hier ist es dann erforderlich, dass der Moderator die Struktur vorgibt. Die Teilnehmer geben die Teilaufgaben an, die gemeinsam in die vorgegebene Struktur eingeordnet werden. So entsteht wiederum ein Strukturplan. Um die einzelnen gesammelten Punkte (Teilaufgaben) bei der induktiven Vorgehensweise zu strukturieren, bedarf es Strukturierungselementen, d. h. Kriterien, nach denen die Teilaufgaben zusammengefasst werden sollen. Die Zusammenfassung (Gruppierung) kann auch in mehreren Stufen geschehen, wie etwa bei den Zielen auch (siehe hierzu Abbildung 27). Grundsätzlich kann man bei der Entscheidung zur Gruppenbildung objektbezogen, funktionsbezogen, organisationsbezogen oder nach geografischen Kriterien vorgehen (zur Zusammenfassung von Aufgaben siehe Wegmann 1986, S. 199 ff.). Portny schlägt vor, bei einem Prinzip zu bleiben und nicht zu mischen, Litke empfiehlt explizit die Verwendung der Mischform (1995, S. 98). Die gemischte Vorgehensweise hat den Vorteil, dass sie flexibel ist und für


85

besondere Aufgabenstellungen individuelle Lösungen zulässt. In der Praxis findet man daher fast durchweg gemischte Darstellungen – es ist aber sinnvoll, bei der Entwicklung eines Projektstrukturplanes zunächst einmal nur einem Kriterium zu folgen – dies sichert am ehesten die Vollständigkeit des Plans. Einen so erstellten Projektstrukturplan geht man dann noch einmal durch und prüft, ob alle Objekte (etwa Produkte), alle Funktionen (d. h. alle zur Durchführung notwendigen Arbeitsschritte), alle Organisationseinheiten (etwa alle betroffenen Abteilungen) und alle geografischen Bereiche (d. h. etwa alle Vertriebsregionen) berücksichtigt wurden. Unter Anwendung dieser Strukturierungsmöglichkeiten kommt man zu einem ersten Entwurf des Strukturplans. Er enthält sämtliche Aufgaben und bringt diese in eine hierarchische Ordnung, fasst gleichartige, zusammengehörige Aufgaben zusammen und unterscheidet verschiedenartige Aufgaben und Themen. Bei der Darstellung der Aufgaben in einem Projektstrukturplan ist zu beachten, dass eine Unterteilung nur so weit erfolgen sollte, bis die unterste Einheit als Arbeitspaket vergeben werden kann (Litke 1995, S. 97). Weitere Untergliederungen sind dann nicht mehr sinnvoll. Ein Arbeitspaket hat folgende Eigenschaften: Jedes Arbeitspaket hat ein eigenes Ergebnis. Es muss eindeutig vom Arbeitsaufwand und vom Ergebnis her zuzuordnen sein. Das heißt auch, dass es genau beschreibbar und der Aufwand abschätzbar ist. Es darf keine Lücken und keine Überschneidungen zwischen Arbeitspaketen geben (Portny 2001, S. 71). Wenn der erste Entwurf des Projektstrukturplans erstellt ist, dann sollte noch die systematische Prüfung der Arbeitspakete auf Kompatibilität erfolgen, d. h., es ist zu kontrollieren, ob alle Aktivitäten auf ein gleiches Ziel hinarbeiten. Dies ist sehr wichtig, um Reibungsverluste von Anfang an zu minimieren. Während dieser Prüfung können Arbeitspakete ergänzt oder die Inhalte von Arbeitspaketen verändert werden. Wenn Arbeitspakete nicht genau definiert werden können, weil Vorarbeiten noch fehlen, kann man Annahmen treffen – diese müssen sehr genau dokumentiert werden und später anhand der realen Ergebnisse überprüft werden. Anschließend, bei der Durchführung, ist eine regelmäßige Prüfung des Plans wichtig, denn Aufgaben können überflüssig geworden sein oder sich geändert haben. Der endgültige Strukturplan enthält die Gesamtaufgabe, die Teilaufgaben bis hin zu allen Arbeitspaketen. An dieser Stelle bleibt festzuhalten, dass der Strukturplan zwar alle auszuführenden Arbeiten (Arbeitspakete) aufführt, aber nicht festlegt, in welcher Reihenfolge die Arbeiten zu erledigen sind. Zwar sind der Zeitaufwand und der Einsatz der notwendigen Ressourcen für jedes Arbeitspaket bekannt, da aber die Abfolge der Arbeiten noch nicht festliegt, kann über die Projektdauer noch keine Aussage getroffen werden. Für die graphische Darstellung des Projektstrukturplans gibt es unterschiedliche Möglichkeiten. Diese besitzen Vor- und Nachteile, stellen aber letztendlich immer dieselbe Projektstruk-

86

Projektplanung

tur dar. Möglich ist die Darstellung als Organigramm, Liste oder Cluster (Portny 2001, S. 8485). An der Spitze von Organigramm und Liste steht in jedem Fall die Gesamtaufgabe, darunter folgen die Teilaufgaben und die Arbeitspakete. In der Listendarstellung können sehr umfangreiche Projektstrukturpläne mit vielen Elementen übersichtlich dargestellt werden. Allerdings hat sie durch die fehlende grafische Aufbereitung nicht die Ad-hoc Verständlichkeit einer Organigramm-Darstellung. Diese hat dafür bei sehr umfangreichen Projektstrukturen den Nachteil, sehr groß zu werden, was dazu führt, dass die Darstellung schwer überschaubar und kommunizierbar wird, wenn sie nicht auf ein DIN-A4-Blatt passt. Bei der Cluster-Darstellung symbolisiert ein Kreis in der Mitte die gesamte Projektaufgabe. Hiervon gehen Linien ab, die zu weiteren Kreisen führen. Diese stellen die einzelnen Teilaufgaben dar. Von diesen führen wiederum Linien zu Arbeitspaketen. Für eine Vermittlung des Strukturplans an andere Projektbeteiligte ist die Cluster-Darstellung nicht so gut geeignet, da sie die Hierarchien grafisch nicht deutlich zeigt. Sie ist aber aufgrund ihrer Flexibilität gut zur Entwicklung eines Projektstrukturplans geeignet. So kann sie etwa Verwendung finden, wenn der Projektstrukturplan von den am Projekt beteiligten Personen mit der Metaplantechnik entwickelt wird. Später kann der Strukturplan dann in ein Organigramm oder eine Liste überführt werden. Die drei folgenden Abbildungen 28 bis 30 verdeutlichen die drei genannten Darstellungsformen.

Telefonhotline einrichten

Standort einrichten

Immobilie anmieten

Nummer einrichten

Ausbau Immobile

Inneneinrichtung

Telefonnummer anmelden

Information der Kunden

Mitarbeiterakquise

Auswahl

Technik

Quelle: Eigene Darstellung in Anlehnung an Portny (2001), S. 76 und 84 Abbildung 28: Projektstruktur-Darstellung als Organigramm

Schulung


87

Telefonhotline einrichten 1. Standort einrichten 1.1 Immobilie anmieten 1.2 Immobilie ausbauen 1.2.1 Inneneinrichtung 1.2.2 Technik 2. Nummer einrichten 2.1 Telefonnummer anmelden 2.2 Information der Kunden 3. Mitarbeiterakquise 3.1 Auswahl 3.2 Schulung

Quelle: Eigene Darstellung in Anlehnung an Portny 2001, S. 84 Abbildung 29: Projektstruktur-Darstellung als Liste/Gliederung

Immobilie anmieten Inneneinrichtung

Immobilie ausbauen

Standort einrichten

Auswahl


Technik

Nummer anmelden

Mitarbeiterakquise Schulung

Nummer einrichten


Quelle: Eigene Darstellung in Anlehnung an Portny (2001, S. 85) Abbildung 30: Projektstruktur als Cluster-Darstellung Für verschiedene Projekte und Aufgaben gibt es so genannte Standard-Strukturpläne zu kaufen. Heute sind sie meist im Rahmen von Software enthalten. Diese allgemein vorgefertigten Strukturpläne können eine Erleichterung und Hilfe sein, ersetzen jedoch keinesfalls das eige-

88

Projektplanung

ne Nachdenken über das konkrete Projekt. In jedem Fall ist der Rückgriff auf Pläne vergleichbarer Projekte aus dem eigenen Unternehmen hilfreich, die schon eher die Spezifika des Unternehmens berücksichtigen als die allgemeinen Projektstrukturpläne. Wird ein Projekt in einem Unternehmen mehrfach durchgeführt, so bietet sich die Erstellung einer Vorlage an. Ein Beispiel hierfür ist die jährliche Budgetierung, die immer auf Basis eines bestehenden Projektstrukturplans „Budget erstellen“ erfolgen kann, der jedes Jahr an die jeweilige Situation angepasst wird. In einem weiteren Schritt kann der Projektstrukturplan durch ein Glossar detailliert und erläutert werden. Dieses Glossar enthält dann viele Informationen, die in der weiteren Planung wichtig werden (vgl. Portny 2001, S. 89): Tätigkeitsbeschreibung: Detaillierte Beschreibung der Arbeitsprozesse und Abläufe, die notwendig sind, um ein Arbeitspaket abzuarbeiten. Vorarbeiten: Arbeitsergebnisse aus anderen Arbeitspaketen des Projektes oder sonstigen Tätigkeiten außerhalb des Projektes, die als Voraussetzung zur Durchführung eines Vorgangs notwendig sind. Ergebnisse: Resultate der Arbeitspakete. Notwendige Ressourcen: Personal, Geld, Anlagen, Betriebsmittel, Rohstoffe, Informationen etc., die zur Durchführung notwendig sind. Insbesondere kann hier schon auf bestimmte Personen verwiesen werden, die benötigtes Know-how besitzen. Dauer: Zeit, die für ein Arbeitspaket benötigt wird (in Abhängigkeit von den bereitgestellten Ressourcen). In der Regel wird die Dauer bei Managementberatungen in Mitarbeitertagen angegeben, d. h. in Arbeitstagen eines Beraters. Diese können dann auf Kalendertage oder Wochen umgerechnet werden.

Praxisbox 10: Hypothesis Approach Einen vergleichbaren Ansatz zur Ableitung von Arbeitspaketen verwendet das Inhouse Consulting mit dem Hypothesis Approaches. Dies ist ein hypothesengetriebener Ansatz zur Strukturierung von Aufgaben. Die Grundidee ist hierbei, dass sich aus dem Ziel eines Projektes Arbeitshypothesen ableiten lassen, die dann Basis weiterer Überlegungen sein können. Die Strukturierung der Arbeit ergibt sich durch das Herunterbrechen von Hypothesen (Hypothesis) in Teilhypothesen (Subhypothesis), für die jeweils Begründungen bzw. Beweise (Arguments) gesammelt werden können. Für die Erarbeitung der Begründungen kann dann ein Arbeitsplan (Work plan) aufgestellt werden. Hierfür wird festgelegt, welche Informationen zur Prüfung benötigt werden (Data needed), woher diese stammen (Source), wie dies dargestellt wird (Presentation layout), wer verantwortlich ist (Responsible) und bis wann der Schritt abgearbeitet sein sollte (Due date).


89

Die folgende Abbildung 31 zeigt die Vorgehensweise in der Übersicht: Work Plan Data need

Hypothesis

Subhypothesis 1

Subhypothesis 2

Source

Present. layout

Responsible Due date

Argument

…

…

…

…

…

Argument

…

…

…

…

…

Argument

…

…

…

…

…

Argument

…

…

…

…

…

Argument

…

…

…

…

…

Argument

…

…

…

…

…

Argument

…

…

…

…

…

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 31: Hypothesis Approach Das Vorgehen soll kurz an einem Beispiel erläutert werden (siehe Abbildung 32). Wenn das Ziel eines Projektes ist, Synergiepotenziale innerhalb der Logistik- und Transportbereiche der Deutsche Post World Net zu untersuchen, dann ist eine mögliche Hypothese, dass die Transportkosten der einzelnen Konzerngesellschaften durch systematische Zusammenarbeit gesenkt werden können. Damit dies tatsächlich möglich ist, müsste zumindest eine von zwei Teilhypothesen zutreffen. Die erste Teilhypothese wäre, dass die Gesellschaften (hier MAIL und DHL) bei eigener Durchführung der Transporte die gleichen oder ähnliche Routen bedienen, so dass eine gemeinsame Durchführung möglich ist. Und die zweite Teilhypothese wäre, dass sich bei Fremdvergabe der Transportleistungen durch gemeinsamen Einkauf der Gesellschaften Preisreduktionen erzielen lassen. Diese Teilhypothesen haben wiederum Voraussetzungen, die dann jeweils einzeln geprüft werden müssen. Zu diesen lassen sich dann konkrete Arbeitspakete der Prüfung definieren.

90

Projektplanung

What synergy potentials can be created as part of the integration of Deutsche Post World Net Operations?

The trucks are not fully loaded Some routes that DHL and MAIL operate independently of each other can be combined

The time window for the transports are identical DHL and MAIL serve identical routes

Costs can be significantly reduced for truck transport within DPWN

Larger quantities allow the negotiation of lower prices Purchase costs can be reduced through the common purchase of transport service

Coordinated purchase of trips there and back save costs of 10 % compared to purchasing two separate individual routes

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 32: Beispiel Hypothesis Approach Zu beachten ist, dass ein Projektstrukturplan noch nicht die Projektorganisation und -planung festlegt, sondern lediglich eine logische Gliederung der Aufgabe aufzeigt. Die konkrete Planung, wer wann was macht, muss weiteren Anforderungen (etwa Ressourcenverfügbarkeit, Effizienz) genügen und erfolgt erst in den folgenden Schritten.

3.3

Zeitplanung mit Netzplänen

Wie bereits dargestellt wurde, kann nach der Entwicklung eines Projektstrukturplans noch keine Aussage über die Projektdauer getroffen werden, da die Abfolge der einzelnen Arbeitspakete noch nicht festgelegt wurde. Die zur Durchführung des Projektes benötigte Zeit ist jedoch ein wesentlicher Faktor im Projektmanagement, und die Managementberatung muss dem Auftraggeber gegenüber Aussagen treffen, welche Zeit das Projekt in Anspruch nehmen wird. Projekte werden oft unter Zeitdruck durchgeführt, da das Management des Klientenunternehmens die gewünschten Ergebnisse schnell erreichen will oder muss. Um die Ergebnisse möglichst termingerecht zu erreichen, ist eine entsprechend gute Zeitplanung unabdingbar. Diese dient nicht nur dazu, dem Auftraggeber gegenüber eine Aussage treffen zu können, sondern


91

natürlich auch der Zeitplanung der Managementberatung. Für die Personalplanung ist es wichtig zu wissen, wie lange ein Team mit dem Projekt beschäftigt sein wird. Um zeitliche Aussagen über den Ablauf des Projektes treffen zu können, ist auf Basis des vorliegenden Projektstrukturplans die zeitliche Abfolge der einzelnen Arbeitspakete festzulegen. Dabei sind der Zeit- und Ressourcenaufwand, der für die Arbeitspakete bereits ermittelt wurde, und die logischen Abhängigkeiten der Arbeitspakete untereinander zu berücksichtigen. Logischerweise muss zum Beispiel das Arbeitspaket „Schulung der Mitarbeiter“ dem Arbeitspaket „Auswahl und Einstellung der Mitarbeiter“ zeitlich folgen. Die Berücksichtigung des Zeit- und Ressourcenaufwandes beinhaltet, dass personelle und andere Ressourcen zum gewünschten Zeitpunkt auch verfügbar sind. Es ist beispielsweise nicht ausreichend, irgendwann im Projektverlauf die Trainer für Schulungen zur Verfügung zu haben, sondern sie müssen dann bereitstehen, wenn auch die zu schulenden Mitarbeiter Zeit haben und die Räumlichkeiten zur Schulung verfügbar sind. Eine gute Zeitplanung für Start, Dauer und resultierendes Ende der einzelnen Arbeitspakete ist daher erfolgskritisch für das Projektmanagement.

Beispiel Wenn im Rahmen eines Projektes zehn Schulungstage für unterschiedliche Mitarbeiter durchzuführen sind, dann ist es zunächst einmal unklar, wie lange dies dauern wird. Steht nur ein Trainer zur Verfügung, so werden die Schulungen zehn Arbeitstage (also 14 Kalendertage) dauern. Vorausgesetzt, es ist möglich, die Mitarbeiter entsprechend zu gewinnen. Stehen zehn Trainer zur Verfügung oder können die Schulungen für die Mitarbeiter zusammengefasst werden, so kann die gleiche Aufgabe an einem Tag erledigt werden. Bauen jedoch die Schulungen in zwei Teilen aufeinander auf, so müssen die Schulungen zumindest an zwei Tagen erfolgen. Dieses Beispiel verdeutlicht, dass die reine Beschreibung der Arbeitspakete (wie im Projektstrukturplan erfolgt) für eine Zeitplanung noch nicht ausreicht. Vielmehr müssen Abhängigkeiten (Reihenfolgen) und Kapazitäten berücksichtigt werden.

Eine Analysemethode, die die notwendige Zeitplanung erlaubt und sich noch um weitere Aspekte erweitern lässt, ist die Netzplantechnik.

3.3.1

Grundlagen zu Netzplänen

Die Netzplantechnik dient der Analyse und Steuerung von Arbeitsabläufen (Übersicht bei Zielasek 1995, S. 145). Ein Netzplan selbst ist eine Grafik, mit der man die Reihenfolge visualisiert, in der Projekttätigkeiten (Arbeitspakete) durchgeführt werden. Man kann mit einem Netzplan ein Projekt in verschiedenen Varianten der Reihenfolge bei der Durchführung durchspielen und die Effekte der Verschiebung oder Verlängerung eines Arbeitspaketes auf das Gesamtprojekt abschätzen. Der Netzplan erlaubt so die zeitliche Gesamtplanung aller

92

Projektplanung

Arbeitspakete eines Projektes (wann muss wer was machen, um das Projekt insgesamt pünktlich zu beenden?) und darüber hinaus Aussagen über die Auswirkung von Verzögerungen oder schnellerer Durchführung bei einzelnen Arbeitspaketen (wird das Gesamtprojekt durch die Verzögerung/Beschleunigung eines Arbeitspaktes langsamer/schneller beendet?). Netzpläne sind von der Grundstruktur her sehr einfach. Sie enthalten lediglich drei Elemente (Portny 2001, S. 94, Kerber-Kunow 2000, S. 31): Ereignisse: Ein Ereignis ist erreicht, wenn ein Vorgang oder mehrere Vorgänge abgeschlossen sind und deren Ergebnis nun vorliegt. Es ist ein wichtiger Schritt auf dem Weg zum Gesamtergebnis. Sie haben – da es sich ja um das Ergebnis handelt – selbst keine Dauer. Beispiele sind: „Telefonnummer ist freigeschaltet“ oder „Arbeitsplätze sind eingerichtet“. Das Ereignis selbst verbraucht keine Ressourcen, sie sind jedoch notwendig, um das Ergebnis zu erreichen. Vorgänge: Ein Vorgang (oder auch Aktivität) ist der Weg zum Ereignis. Es handelt sich um die Arbeitsschritte, die notwendig sind, um ein Ereignis zu erzielen. In der Regel sind dies die Arbeitspakete des Projektstrukturplans. Vorgänge benötigen eine Dauer zur Durchführung und verbrauchen dabei Ressourcen. Vorgangsdauer: Zeit, die für die Durchführung eines Vorgangs notwendig ist. Dies ist der Zeitabstand von Beginn des Vorgangs bis zum Abschluss mit Eintritt des Ereignisses. Die Dauer ist natürlich abhängig vom Einsatz von Ressourcen. So lassen sich manche Vorgänge dadurch beschleunigen, dass mehrere Berater daran arbeiten (etwa bei der Aufnahme und Dokumentation von Prozessen), bessere Ressourcen zum Einsatz kommen (etwa schnellere Computer bei Simulationen) oder die tatsächlich verfügbare Arbeitszeit der Ressourcen erhöht wird (etwa durch Verlängerung der täglich verfügbaren Arbeitszeit von Beratern durch Überstunden). Für die Darstellung dieser Elemente in Netzplänen gibt es zwei grundlegende Formen (Übersicht bei Lock 1997, S. 150): Vorgangspfeil-Netzpläne (oder auch Critical Path Method [CPM], Arrow Diagrams Method [ADM], Programme Evaluation and Review Technique [PERT]) Vorgangsknoten-Netzplan (oder auch Vorgangsnetzplan, Präzedenzdiagramme (PDM), Roy-Methode, Methods of Potentials [MPM]) Im Folgenden werden diese Darstellungsformen kurz erläutert.


93

Vorgangspfeil-Netzplan Ein Vorgangspfeilnetzplan stellt – wie der Name schon nahe legt – einen Vorgang als Pfeil (o) dar. Ein Ereignis wird durch einen Kreis ({) symbolisiert und die Dauer wird mit dem Buchstaben t an den Pfeil geschrieben (etwa t = 5 Wochen). Die folgende Abbildung 33 zeigt dies bezüglich des Beispiels der Schulungstage:

Vorgang – Arbeitsaufwand, der nötig ist, um von einem Ereignis zum nächsten zu gelangen:

V1 = Mitarbeiter schulen

A

B t1 = 2 Wochen

Ereignis/ Meilenstein, (etwa: Schulung begonnen)

Ereignis/ Meilenstein, (etwa: Schulung der Mitarbeiter durchgeführt) Abstandszeit – Dauer des Vorgangs

Für viele: Kerber-Kunow 2000, S. 32; Maylor 1999, S. 81 Abbildung 33: Beispiel für die Symbolik eines Vorgangspfeil-Netzplans

Vorgangsknoten-Netzplan Bei dieser Darstellungsvariante gibt es nur zwei Symbole. Ein Rechteck stellt sowohl ein Ereignis als auch einen Vorgang dar. Ein Rechteck ohne Dauer ist ein Ereignis, ein Rechteck mit Dauer ist ein Vorgang. Rechtecke, die Ereignisse darstellen, werden meist noch besonders markiert, etwa durch Fettdruck oder doppelten Rand. Die Dauer wird wie bei den Vorgangspfeil-Netzplänen durch den Buchstaben t ausgedrückt. Die Abbildung 34 zeigt hierfür ein einfaches Beispiel (welches inhaltlich dem der vorherigen Abbildung 33 entspricht).

94

Projektplanung

Vorgang (etwa: Schulung der Mitarbeiter)

A

1

B

tA = 0

t1 = 2 Wochen

tB = 0

Ereignis/ Meilenstein (etwa: Schulung begonnen)

Ereignis/ Meilenstein (etwa: Schulung abgeschlossen)

In Anlehnung an Portny 2001, S. 97 Abbildung 34: Symbolik von Vorgangsknoten-Netzplänen Beide Methoden können grundsätzlich die gleichen Sachverhalte darstellen. Es stellt sich daher die Frage, welche Methode verwendet werden soll. Bei Vorgangsknoten-Netzplänen können auch Vorgänge direkt aufeinander folgen. Dies macht sie etwas einfacher in der Konstruktion, da nicht für jeden Vorgang ein Ereignis definiert werden muss. Sie gleichen in der Optik daher nicht so sehr technischen Flussdiagrammen und sind so anschaulicher (siehe Beispiele bei Kotler/Bliemel 1995, S. 228). Vorgangsknoten-Netzpläne sind weiter verbreitet, insbesondere auch bei Projektmanagement-Software. Da es nicht unbedingt notwendig ist, Ereignisse zu definieren, bergen sie entsprechend auch die Gefahr, dass man vergisst, Ereignisse zu definieren. Hierdurch kann die Darstellung in bestimmten Fällen sehr komplex werden. In die Vorgangsknoten-Netzpläne kann man für die Analyse der Netzpläne noch Berechnungen in die Knoten (Rechtecke) einzeichnen, was eine sehr übersichtliche Darstellung ermöglicht. Aus diesen Gründen soll im Folgenden für die Darstellung lediglich auf Vorgangsknoten-Netzpläne Bezug genommen werden (siehe zu den Darstellungsmöglichkeiten Lock 1997, S. 150-151; Maylor 1999, S. 89).

3.3.2

Netzplanerstellung und -analyse

Erstellung eines Netzplans Wie eine Wanderung auf einer Karte nachvollzogen werden kann, so ermöglicht ein Netzplan, den Projektablauf im Vorhinein zu planen und dann nachzuvollziehen. In dieser Analo-


95

gie sind die Vorgangsknoten die Wege, die zurückgelegt werden. Die Ereignisknoten sind Wegmarken oder Orte, die man passiert (daher werden sie auch Meilensteine genannt). Und der Gesamtweg wird durch einen Pfad beschrieben, dem man durch die Landschaft folgt – und der durch die Wegstrecken und Orte definiert wird. Die Konstruktion eines Netzplans gleicht daher gewissermaßen der Einzeichnung eines Routenplans in eine Karte. Wie geht man aber nun vor, wenn man einen Netzplan konstruieren möchte? Grundsätzlich startet ein Netzplan links mit dem Projektanfang und endet rechts mit dem Projektende. Anfang und Ende sind Ereignisse. Es ist grundsätzlich möglich, vom Anfang zum Ende oder vom Ende zum Anfang zu planen. Für die Planung muss man die im Rahmen des Projektstrukturplans ermittelten Arbeitspakete in die richtige logische Reihenfolge bringen, d. h. aufzeigen, welche Arbeitspakete erst in Abhängigkeit der Vollendung eines anderen bearbeitet werden können (Lock 1996, S. 152). Hierbei ist es wichtig, nur solche Abhängigkeiten im Ablauf zu berücksichtigen, die tatsächlich zwingend sind. Denn mit Hilfe eines Netzplans soll ja der optimale Ablauf eines Projektes geplant werden. Wenn bei der Reihenfolge schon Vorgaben gemacht werden, die gar nicht notwendig sind, so schränkt dies nur die Flexibilität der folgenden Planung unnötig ein. Zwingende Beziehungen können etwa rechtliche Anforderungen, firmeninterne Anforderungen oder ablaufbedingte Voraussetzungen sein (vgl. Portny 2001, S. 105). Beispiele für rechtliche Anforderungen sind Zustimmung des Betriebsrats vor Einführung von Software, die Daten der Mitarbeiter speichert, oder die Prüfung eines Jahresabschlusses durch einen Wirtschaftsprüfer. Firmeninterne Anforderungen sind Regeln, denen man sich im Unternehmen unterwerfen muss. Dies kann beispielsweise die notwendige vorherige Freigabe von Geldern für Firmenübernahmen in bestimmten Gremien sein, die zwingende Erstellung bestimmter Unterlagen im Rahmen der Projektplanung etc. Ablaufbedingte Voraussetzungen ergeben sich aus einer sachlichen Notwendigkeit. Ein Beispiel ist der notwendige Entwurf und Druck eines Fragebogens vor Durchführung einer Befragung. Hier könnte man beispielsweise auch festlegen, bestimmte besonders kritische Punkte zu Beginn zu erledigen, um diese dann für den weiteren Projektverlauf bereits geklärt zu haben. Eine solche Einschränkung sollte aber nur vorgenommen werden, wenn sie aus Fragen der Risikoabschätzung oder aus Gründen der Akzeptanz zwingend erscheinen. Beginnend von einer Seite (Anfang oder Ende), sind die Arbeitspakete nun graphisch in den Netzplan in der richtigen Reihenfolge zu integrieren. Hierbei gibt es zwei Regeln, die immer eingehalten werden müssen (Portny 2001, S. 99): Regel 1: Wenn ein Vorgang beendet ist, kann man entsprechend dem Pfeil zum nächsten Vorgang übergehen. Regel 2: Um einen Vorgang zu beginnen, müssen alle vorgeschalteten Vorgänge und Ereignisse beendet sein (dies sind die Vorgänge/Ereignisse, deren Pfeile zu dem betreffenden Vorgang führen).

96

Projektplanung

Die beiden Regeln sollen kurz an einem Beispiel dargestellt werden:

A tA = 2 Wochen

START

C

ENDE

tS = 0

tC = 2 Wochen

tE = 0

B tB = 1 Woche

Abbildung 35: Beispiel für einen Vorgangsknoten-Netzplan Regel 1 besagt, dass erst nach dem Ereignis „START“ mit Vorgang A und/oder Vorgang B begonnen werden kann. Also darf etwa erst nach formalem Projektstart durch den Vorstand mit den entsprechenden Projektarbeiten begonnen werden. Regel 2 besagt, dass mit Vorgang C erst angefangen werden kann, wenn die Vorgänge A und B beendet sind. Unter Berücksichtigung dieser Regeln werden die Arbeitspakete dann in der richtigen Reihenfolge in den Netzplan eingezeichnet. Weitere zu beachtende Punkte gibt es nicht. Bei umfangreicheren Projekten würde die Erstellung eines Netzplans nicht von Hand vorgenommen werden, sondern mit Hilfe von entsprechenden Computerprogrammen. Hierzu gibt es eine Vielzahl von Standardlösungen, wie etwa fx-project, Projecta, PQM, A-Plan, KULSA, Sciforma Project Scheduler, GENIUS Enterprise Project, SAP&R3 Modul PS, Microsoft Project etc. (Silicon 2004), die vom Leistungsumfang her sehr unterschiedlich sind. Bei der Planung mit Hilfe von solchen Software-Systemen ist es wichtig, dass man die Vorgänge in ihrer Reihenfolge nicht danach plant, welche Ressourcen zur Verfügung stehen. Die Verfügbarkeit der Ressourcen und die logische Reihenfolge der Abarbeitung der Arbeitspakete werden dem Computer vorgegeben. Dieser nimmt dann automatisch die optimale Verteilung der Vorgänge auf die Ressourcen und Planung des Projektablaufs vor. Diese ressourcenbasierte Planung ist einer der Vorteile bei der Verwendung von ProjektmanagementSoftware. Anhand eines Beispiels soll gezeigt werden, wie der zeitliche Projektablauf mit einem Netzplan analysiert werden kann. Vorausgehend wurden in einer Projektstrukturanalyse Arbeitspakete identifiziert. Die Abbildung 36 gibt hierzu ein Beispiel in der Cluster-Darstellung wieder (diese entspricht der Abbildung 30 auf Seite 87, ist hier jedoch zur besseren Übersicht nochmals aufgeführt):


97

Immobilie anmieten Inneneinrichtung

Immobilie ausbauen

Standort einrichten

Auswahl


Technik

Nummer anmelden

Mitarbeiterakquise Schulung

Nummer einrichten


Quelle: Eigene Darstellung in Anlehnung an Portny (2001, S. 85) Abbildung 36: Projektstruktur als Cluster-Darstellung Zuerst werden für diesen Projektstrukturplan die Abhängigkeiten und notwendigen Zeiten bestimmt. Dies geschieht in der Regel durch den Projektleiter unter Mithilfe der beteiligten Experten, die fachlich auch später für die Arbeitspakete die Verantwortung tragen sollen. Das Ergebnis wird in einer Tabelle (siehe Abbildung 37 auf S. 98) zusammengefasst. Als Basis dieser Tabelle dient hier die Listendarstellung der Projektstruktur aus Abbildung 29 (S. 87). Jedes Element der Projektstruktur ist in der Tabelle aufgeführt (hier = Listenelement). Für jedes Listenelement wird festgehalten, ob es sich um ein Strukturelement (X) oder um ein Arbeitspaket (A-G) handelt. Ein Strukturelement wird durch Arbeitspakte beschrieben. Strukturelemente haben als reine Sammelpunkte keine eigene Dauer, da die Planung komplett auf der Ebene der Arbeitspakete erfolgt. Arbeitspakete sind in der dritten Spalte mit einer Kennung (A-G) versehen. Im Netzplan kann daher einfach nur der Kennbuchstaben aufgeführt werden. Die Dauer der Arbeitspakete ist in der vierten Spalte zugeordnet. Sie ergibt sich aus einer Expertenschätzung auf Basis der notwendigen Ressourcen, die zunächst einmal als gegeben vorausgesetzt werden. Auch die letzte Spalte „notwendiger Vorgänger“ ergibt sich aus Angaben von Experten, die festhalten, ob bestimmte Arbeitspakete vorher abgeschlossen sein müssen, bevor mit dem nächsten Arbeitspaket begonnen werden kann. In diesem Beispiel wird von folgenden Abhängigkeiten ausgegangen: Die Technik kann erst installiert werden, wenn die Inneneinrichtung fertig ist. Die Kunden können erst über die neue Telefonhotline informiert werden, wenn die Nummer feststeht, und die Mitarbeiter können erst geschult werden, wenn sie ausgewählt worden sind und die Technik installiert ist (weil für diese geschult werden soll).

98

Projektplanung

Strukturelement

Listenelement 1. Standort einrichten

Arbeitspaket

Dauer in Wochen

X

1.1 Immobilie anmieten

A

1.2 Immobilie ausbauen

X

notwendiger Vorgänger

./.

./.

8

-

./.

./.

1.2.1 Inneneinrichtung ausbauen

B

6

A

1.2.2 Technik installieren

C

4

A, B

./.

./.

2. Nummer einrichten

X

2.1 Telefonnummer anmelden

D

2

-

2.2 Information der Kunden

E

1

D

./.

./.

3. Mitarbeiterakquise

X

3.1 Auswahl Mitarbeiter

F

4

-

3.2 Schulung Mitarbeiter

G

3

C, F

Abbildung 37: Rangfolge der Arbeitspakete einer Projektstruktur Anhand dieser Angaben kann nun ein Netzplan erstellt werden. Hierbei beginnt man links in der Abbildung mit dem Start des Projektes und ordnet die weiteren Arbeitspakte in der richtigen Reihenfolge nach rechts fortschreitend an. Die Abbildung 38 zeigt den Netzplan des CallCenter-Beispiels in der Vorgangsknoten-Darstellung:

Vorgang A tA = 8

Start t=0

Vorgang B tB = 6

Vorgang C tC = 4

Vorgang F tF = 4

Vorgang D tD = 2

Vorgang G tG = 3

Vorgang E tE = 1

Abbildung 38: Beispiel eines Vorgangsknoten-Netzplans

Ende t=0


99

Analyse eines Netzplans Die Analyse des Netzplans zur Bestimmung der Durchlaufzeit und der enthaltenen Pufferzeiten erfolgt in zwei Schritten. Im ersten Schritt beginnt man am Startpunkt und durchläuft die Arbeitspakete zum Ende hin. Dies ist die so genannte Vorwärtsrechnung. Hierdurch werden der früheste Anfangszeitpunkt und der früheste Endzeitpunkt für jedes Arbeitspaket ermittelt: Vorgang

Frühester Anfangszeitpunkt am Anfang von Woche

Frühester Endzeitpunkt am Ende von Woche

A

1

8

B

9

14

C

15

18

D

1

2

E

3

3

F

1

4

G

19

21

Quelle: In Anlehnung an Lock (1997), S. 164 Abbildung 39: Früheste Anfangs- und Endzeitpunkte Der früheste Anfangszeitpunkt eines Vorgangs (Arbeitspakets) wird durch den spätesten Endzeitpunkt aller Vorgänge bestimmt, die zu seinem Start beendet sein müssen. Im Beispiel in Abbildung 39 ist zuerkennen, dass die Einrichtung des Call Centers insgesamt 21 Wochen benötigt. Die letzten zu erledigenden Vorgänge für den Projektabschluss sind E und G. Während E bereits zum Ende der dritten Woche beendet sein könnte, kann mit G erst in Woche 19 begonnen werden. Der früheste Startzeitpunkt für Vorgang G ergibt sich daraus, dass Vorgang C und Vorgang F beendet sein müssen, bis die Arbeiten an G beginnen können. Vorgang F wird nach drei Wochen, Vorgang C nach 18 Wochen beendet. Die Vorwärtsanalyse ergibt also die schnellstmögliche Durchlaufzeit durch den Netzplan und hiermit die minimal benötigte Projektdauer. Im zweiten Analyseschritt wird der Netzplan vom Ende her durchlaufen. Entsprechend wird dies Rückwärtsrechnung genannt. Das Ziel dieses Analyseschrittes ist zu ermitteln, wann spätestens mit einem Arbeitspaket begonnen werden muss, um das Projekt in der im ersten Analyseschritt ermittelten minimal notwendigen Projektlaufzeit zu beenden. Hierzu werden die spätesten Anfangs- und Endzeitpunkte berechnet. Der späteste Anfangszeitpunkt eines Vorgangs wird durch den frühesten Anfangszeitpunkt der ihm direkt nachfolgenden Vorgänge abzüglich seiner Vorgangszeit bestimmt. Dies sei für das Beispiel kurz gezeigt:

100

Projektplanung

Vorgang E und G müssen spätestens Ende der 21. Woche beendet sein. Da Vorgang G drei Wochen dauert, muss spätestens Anfang Woche 19 mit den Arbeiten begonnen werden, damit er Ende Woche 21 abgeschlossen ist. Entsprechend muss Anfang der 21. Woche mit Vorgang E begonnen werden, da dieser eine Woche benötigt. Der Abschluss von Vorgang C ist die Voraussetzung für den Start mit G. Also muss Vorgang C spätestens Ende Woche 18 abgeschlossen sein (da ja G spätestens Woche 19 starten muss). Um Ende Woche 18 abgeschlossen zu sein, muss Vorgang C Anfang Woche 15 beginnen. Entsprechend muss Vorgang B als Vorgänger von C Ende Woche 14 spätestens enden – wofür er Anfang Woche 9 starten muss. A ist der Vorgänger von B, muss also Ende Woche 8 fertig sein. Dafür muss A zu Beginn der ersten Woche starten. Vorgang F ist ein Vorgänger von Vorgang G. Vorgang G muss spätestens Anfang Woche 19 starten. Also muss Vorgang F spätestens Ende Woche 18 abschließen und entsprechend Anfang Woche 15 beginnen. Vorgang D ist vor Vorgang E geschaltet, Vorgang E muss Anfang Woche 21 beginnen, also muss D Ende Woche 20 beendet sein. Hierfür muss Vorgang D Anfang der 19. Woche spätestens starten. In einer Tabelle zusammengefasst ergibt sich folgendes Bild: Vorgang

Spätester Anfangszeitpunkt am Anfang von Woche

Spätester Endzeitpunkt am Ende von Woche

A

1

8

B

9

14

C

15

18

D

19

20

E

21

21

F

15

18

G

19

21

Quelle: Lock 1997, S. 164 Abbildung 40: Späteste Anfangs- und Endzeitpunkte Betrachtet man nun beide Tabellen (Vorwärts- und Rückwärtsrechnung), so zeigt sich, dass bei einigen Vorgängen der frühestmögliche Start vor dem Anfangszeitpunkt liegt, der notwendig ist, um das Projekt insgesamt noch in 21 Wochen zu beenden (in der Tabelle der spätestmögliche Anfangszeitpunkt). So würde es beispielsweise reichen, mit Vorgang D erst in Woche 19 zu beginnen, ohne das Gesamtprojekt zeitlich zu verzögern. Man könnte mit dem Vorgang aber bereits in der Woche 1 beginnen. Dieser Vorgang ist also nicht besonders zeitkritisch. Er beinhaltet einen zeitlichen Spielraum, die so genannte Pufferzeit.


101

Diese Pufferzeit ist die Zeit, um die ein Vorgang verzögert werden kann, ohne die Gesamtlaufzeit des Projektes hierdurch zu verlängern. Die Berechnung der Pufferzeiten erfolgt dementsprechend durch Subtraktion des frühestmöglichen Anfangszeitpunkts vom spätestmöglichen Anfangszeitpunkt. Alternativ kann auch der frühestmögliche Endzeitpunkt vom spätestmöglichen Endzeitpunkt abgezogen werden. Beide Rechnungen führen immer zum selben Ergebnis, da sich frühester Anfangs- und Endzeitpunkt sowie spätester Anfangs- und Endzeitpunkt jeweils nur durch die Dauer eines Vorgangs unterscheiden. Es ist zu beachten, dass die berechnete Pufferzeit die gesamte Pufferzeit bis zu diesem Vorgang darstellt. Wenn diese durch einen vorherigen Vorgang aufgebraucht wird, dann steht sie für folgende Vorgänge nicht mehr zur Verfügung. In unserem Beispiel ergeben sich folgende Pufferzeiten: Vorgang

Spätester Anfangszeitpunkt am Anfang von Woche

Frühester Anfangszeitpunkt am Anfang von Woche

Pufferzeit (= zeitlicher Spielraum)

A

1

1

0

B

9

9

0

C

15

15

0

D

19

1

18

E

21

3

18

F

15

1

14

G

19

19

0

Quelle: In Anlehnung an Lock 1997, S. 164 Abbildung 41: Berechnung Pufferzeiten So kann in unserem Beispiel der Puffer von 18 Wochen nur von Vorgang D oder von Vorgang E aufgebraucht werden, bzw. sie müssen sich ggf. die Pufferzeit teilen. Wenn man sich den Netzplan aus unserem Beispiel (Abbildung 38) vor Augen führt, sieht man, dass der Puffer von Vorgang F von den Puffern von D und E unabhängig ist. Alle Vorgänge, die eine Pufferzeit von Null aufweisen, liegen auf dem so genannten kritischen Pfad. Eine Verzögerung von Vorgängen auf dem kritischen Pfad führt zwangsläufig zu einer Verzögerung im Gesamtprojekt. Daher sind diese im Projektmanagement besonders sorgfältig zu planen und zu überwachen. Die Berechnung der Werte zu den Vorgängen wird leichter, wenn man jeden Vorgang bereits in der Abbildung des Netzplans mit den Anfangs- und Endzeiten versieht. Hierzu kann man sich der Präzedenzdiagramme bedienen, die eine weitere, später entwickelte Variante der Vorgangsknoten-Netzplan-Methode sind (Lock 1997, S. 150). Hierbei werden die einzelnen

102

Projektplanung

Rechtecke mit den entsprechenden Zeiten versehen. Die Darstellungsweise ist in Abbildung 42 aufgeführt. Hierbei werden folgende Abkürzungen verwandt: FAZ

=

früheste Anfangszeit

FEZ

=

früheste Endzeit

SAZ

=

späteste Anfangszeit

SEZ

=

späteste Endzeit

FAZ

Dauer

FEZ

Nummer: Beschreibung: SAZ Puffer

SEZ

Quelle: Lock 1997, S. 157, Maylor 1999, S. 88 Abbildung 42: Ein Vorgang in der Präzendenzdarstellung Diese Kästchen kann man nun mit den Werten aus unseren drei Tabellen versehen und entsprechend in den Netzplan einsetzen. Gerade, wenn man komplexere Strukturen doch einmal von Hand (und nicht im Computer) plant, erleichtert dies die Erstellung. Allerdings können die entstehenden Netzpläne dann rein vom benötigten Papier recht groß werden. Die dargestellte Analyse des Netzplans ergibt so einen ersten Zeitplan für das Projekt. Ist man der vorgeschlagenen Vorgehensweise bei der Erstellung gefolgt, so ist er seriös auf Basis der notwendigen Arbeiten geplant. Er zeigt fachlich begründet, wann welche Schritte durchgeführt werden müssen und wie lange das gesamte Projekt dauern wird. Hierdurch lässt sich eine Aussage treffen, inwieweit ggf. vorhandene Ziele des Auftraggebers einhaltbar sind. In der Praxis zeigt sich jedoch häufig, dass die Projektergebnisse schneller benötigt werden, als dies laut Netzplan möglich ist. Der Auftraggeber wünscht eine schnellere Projektdurchführung. Wurde der Plan realistisch erstellt, gibt es ohne Veränderungen in den Prämissen zunächst durch Umorganisation keine Möglichkeit der Beschleunigung. Gemäß der Überlegungen, die dem magischen Dreieck des Projektmanagements (siehe Abbildung 2 auf Seite 32) zugrunde liegen, muss entweder der Ressourceneinsatz erhöht oder die Projektziele (Qualität des Ergebnisses) müssen gesenkt werden.

Start t=0

Abbildung 43: Beispielnetzplan in Präzedenzdarstellung SEZ: E20

Puffer: 18 SEZ: E21

SAZ: A21

Puffer: 18

SAZ: A19

SEZ: E18

FAZ Dauer: FEZ A3 2 E3 Kennung: E Beschreibung: Info

Puffer: 14

SEZ: E14

FAZ Dauer: FEZ A1 2 E2 Kennung: D Beschreibung: Anmelden

SAZ: A15

FAZ Dauer: FEZ A1 4 E4 Kennung: F Beschreibung: Auswahl

Puffer: 0

SAZ: A9

SEZ: E8

SAZ: A1 Puffer: 0

FAZ Dauer: FEZ A9 6 E14 Kennung: B Beschreibung: Einrichten

FAZ Dauer: FEZ A1 8 E8 Kennung: A Beschreibung: Anmieten SAZ: A15

Puffer: 0 SEZ: E18

FAZ Dauer: FEZ 4 A15 E18 Kennung: C Beschreibung: Technik

SAZ: A19

Puffer: 0

SEZ: E21

FAZ Dauer: FEZ A19 3 E21 Kennung: G Beschreibung: Schulen

Ende t=0

Zeitplanung mit Netzplänen 103

104

Projektplanung

Nun macht es bei Kenntnis des kritischen Pfades Sinn, gezielt Arbeitspakete zu beschleunigen, die auf dem kritischen Pfad liegen. Ihre Beschleunigung (zeitliche Verkürzung) hat eine Auswirkung auf die Gesamtprojektlaufzeit. Für diese Arbeitspakete ist eine Überprüfung sinnvoll, wie sie zeitlich schneller abgewickelt werden können (vgl. hierzu auch Lock 1997, S. 165f und 182; Portny 2001, S. 114): Zunächst einmal sollte nochmals der gesamte Plan, auch unter Hinzuziehung neuer Experten, die etwa neue Verfahren und Vorgehensweisen zur Beschleunigung des Projektes einbringen können, überprüft werden. Auch sollte noch einmal geprüft werden, ob die berücksichtigten Abhängigkeiten der Vorgänge tatsächlich zwingend sind. Eine solche Prüfung kann selbst auch wieder zeitaufwändig sein und macht daher nur Sinn, wenn tatsächlich noch inhaltliche Unsicherheit besteht. Die personellen Ressourcen für die Vorgänge auf dem kritischen Pfad können erhöht werden, wenn dies die Vorgangsdauer verkürzt oder ein paralleles Abarbeiten von Vorgängen auf dem kritischen Pfad erlaubt (so genanntes fast tracking). Dies kann heißen, dass mehr Teammitglieder einen Vorgang bearbeiten, die Arbeitszeiten der bestehenden Teammitglieder ausgedehnt oder besser qualifizierte Teammitglieder eingesetzt werden. Diese Ressourcen können zusätzlich in das Projekt eingeplant werden (was die Kosten erhöht) oder von Vorgängen abgezogen werden, die einen Puffer besitzen. Eine Sonderform zur Ressourcenerhöhung ist das Outsourcing von Aufgaben/Vorgängen aus dem eigentlichen Projektteam. Die Managementberatung kann so als „Generalunternehmer“ arbeiten und externe Experten (etwa Marktforschungsinstitute oder andere Beratungsunternehmen) oder andere Arbeitskräfte (etwa von der Zeitarbeit) hinzuziehen. Auch kann bei Beratungsprojekten der Grad der Einbeziehung des externen Faktors (Mitarbeiter und Ressourcen des Auftraggebers) geprüft werden. Es kann also quasi ein Insourcing erfolgen, indem der Auftraggeber einige Teilaufgaben selbst übernimmt. Durch Internalisierung der Leistung wird der Auftraggeber wieder stärker zum Co-Produzenten (Meffert/Bruhn 1997, S. 303). Ebenso wie die personellen Ressourcen können auch – wenn vorhanden – die maschinellen Ressourcen erhöht werden. In der Managementberatung ist dies jedoch meist nicht der Engpass, da es sich bei einer Beratungsleistung um eine sehr personalintensive und individuelle Leistung handelt. So ist uns aus unserer Projekterfahrung in der Managementberatung kein einziger Fall bekannt, in der der verstärkte Einsatz einer Maschine die tatsächliche Projektlaufzeit beeinflusst hätte. Es sollte geprüft werden, ob es möglich ist, Arbeitspakete doch noch weiter zu unterteilen und dann zeitgleich an den Teilen zu arbeiten. So kann es bei unserem Beispiel etwa möglich sein, die Schulung in einen allgemeinen Teil und einen Technikteil zu unterteilen. Mit der Schulung des allgemeinen Teils könnte dann schon begonnen werden, während die Technik noch installiert wird. Wenn so etwa zwei Wochen allgemeine Schulungen schon durchgeführt werden können, während das eigentliche Call-Center noch nicht fertig ist, würde dies die Gesamtprojektlaufzeit um zwei Wochen verringern. Grundsätzlich gilt, dass mit Verkürzung der Pufferzeit auch das Risiko der Nichteinhaltung des Endtermins steigt. Puffer sind meist sinnvoll, weil im Projektverlauf häufig unvorherge-


105

sehene oder unvorhersehbare Probleme auftauchen. Ein Plan ohne Puffer ist daher sehr anfällig für Terminüberschreitungen. Dies gilt natürlich insbesondere, wenn es mehrere parallel liegende kritische Pfade gibt. Eine Projektdurchführung dem Auftraggeber in der minimalen Zeit des kritischen Pfades zu versprechen ist nicht ratsam, da jede Verzögerung auf dem kritischen Pfad automatisch zu einer Terminüberschreitung führen wird. In der Praxis würde dies sehr wahrscheinlich geschehen. Wenn abzusehen ist, dass der Auftraggeber reine Reservezeit zusätzlich zu der im Netzplan aufgezeigten Zeit nicht akzeptieren wird, sollten kleine mögliche Verzögerungen schon in den Vorgängen berücksichtigt werden. Hierbei darf es nicht darum gehen, eine längere Projektlaufzeit als nötig zu „verkaufen“. Dies ist vor dem Hintergrund des Zieles einer langfristigen Zusammenarbeit mit dem Auftraggeber strikt zu vermeiden. Es muss vielmehr versucht werden, eine für den Auftraggeber möglichst realistische Schätzung abzugeben. Wichtig ist es, die zeitlichen Alternativen im Projektplan mit Kosten und Risiken aufzuzeigen und den Auftraggeber letztendlich entscheiden zu lassen. In keinem Fall aber sollte ein zu knapper Zeitplan akzeptiert werden, der durch einen seriösen Netzplan nicht dargestellt werden kann (also keine wirkliche Alternative ist). Auch wenn dies zu Projektbeginn oft der Wunsch des Auftraggebers ist, wird es im weiteren Projektverlauf und am Projektende zu Verärgerung auf Seiten des Auftraggebers führen und ein negatives Licht auf die Beratung werfen. Ist über den Zeitplan keine Einigung zu erlangen, sollte das Projekt daher nicht durchgeführt werden.

3.3.3

Zeitpläne kommunizieren

Ist ein Projekt geplant oder besteht ein erster Entwurf für die Planung, der der Abstimmung bedarf, dann muss dies entsprechend kommuniziert werden. Dies geschieht in der Praxis sinnvollerweise zusammen mit der Veröffentlichung der Zuständigkeiten, denn dann können die für bestimmte Arbeitspakte zuständigen Personen eine Prüfung des Plans vornehmen bzw. die Arbeiten schon einplanen. Es lassen sich drei Arten, wie ein solcher Plan kommuniziert werden kann, unterscheiden (in Anlehnung an Portny 2001, S. 123) Meilensteinbericht Vorgangsbericht Gantt-Diagramm Ein Meilensteinbericht (Key-Event-Bericht) ist eine Tabelle, in der Meilensteine mit Termin aufgeführt sind. Dies ist einfach und schnell anhand des Netzplanes zu erstellen. Wann die zuständigen Personen mit der Arbeit beginnen müssen, um rechtzeitig fertig zu werden, gibt dieser Bericht nicht wieder. Die Verantwortlichen planen dies selbst und müssen prüfen, ob das plangerechte Erreichen der Ergebnisse mit den ihnen zur Verfügung stehenden Res-

106

Projektplanung

sourcen möglich ist. Die im Netzplan vorhandene Information über Vorgänge fehlt hier. Die Verantwortlichen haben so eine höhere Verantwortung und Gestaltungsfreiheit. Allerdings schränken sich für das Projektmanagement hierbei auch die Kontrollmöglichkeiten ein, da der Start einer Tätigkeit mangels zentraler Planvorgabe nicht kontrolliert werden kann. Für Managementberatungsprojekte mit hoher Bedeutung und engem Zeitplan ist diese Art, einen Zeitplan vorzugeben, daher nur bedingt sinnvoll. Er sollte nur bei überschaubaren Projekten eingesetzt werden. Die Abbildung 44 zeigt ein einfaches Beispiel für einen SchlüsselereignisBericht anhand des Call-Center-Projektes aus Abbildung 43 auf Seite 103: Meilenstein (Key Event)

Verantwortlich

spätester Endzeitpunkt

Immobilie ist angemietet

Immobilien-Abteilung, Herr Müller

KW 8

Mitarbeiter ausgewählt

Personalabteilung, Herr Schulze

KW 18

Rufnummer angemeldet

Marketingabteilung, Herr Meier

KW 20

Einrichtung Call Center erfolgt


KW 14

Information über Rufnummer kommuniziert


KW 21

Technik installiert und betriebsbereit

IT-Abteilung, Frau Braun

KW 18

Schulungen durchgeführt


KW 21

Abbildung 44: Schlüsselereignis-Bericht Vorgangs-Bericht. Ein Vorgangsbericht ist eine Tabelle, in der alle Vorgänge und deren Anfangs- und Endtermine aufgeführt sind. Hiermit wird jedem Verantwortlichen mitgeteilt, wann er welche Arbeit erbringen soll. Diese Art der Kommunikation von Zeitplänen lässt keine Freiheit bezüglich des Starts der Arbeiten und geht so von einer zentraleren Planung des Projektes und aller Arbeitspakete aus. Die Arbeit mit Vorgangsberichten erlaubt die Kontrolle, ob bereits mit den Arbeiten an den einzelnen Arbeitspaketen begonnen wurde. Die Abbildung 45 zeigt ein Beispiel für einen Vorgangsbericht anhand des auch der vorherigen Abbildung 44 zugrunde liegenden Call-Center-Projektes. Mit der Kommunikation von Pufferzeiten sollte man hierbei vorsichtig sein, da die Tendenz besteht, dass diese ausgenutzt werden, sobald sie bekannt werden. Für einen echten Puffer für unvermeidbare Verzögerungen stehen sie dann nicht mehr zur Verfügung.


Vorgang

Verantwortlich

Anmieten der Immobilie

107

Starttermin

Endtermin

Anmerkung


KW 1

KW 8

kein Puffer

Auswahl der Mitarbeiter


KW 1

KW 4

Puffer vorhanden bis KW 18

Anmelden der Rufnummer


KW 1

KW 20


Einrichten des Call Centers


KW 9

KW 14

kein Puffer

Informieren über Rufnummer


KW 3

KW 21


Technik installieren


KW 15

KW 18

kein Puffer

Schulungen durchführen


KW 19

KW 21

kein Puffer

Abbildung 45: Beispiel für einen Vorgangsbericht Gantt-Diagramm. Eine Mischung zwischen Vorgangs- und Schlüsselereignis-Bericht ist das Gantt-Diagramm, das nach seinem Erfinder Henry L. Gantt (1861-1919) benannt ist (o. V. 2005). Ursprünglich enthielt es nur Vorgänge, in der Praxis wird es heutzutage jedoch fast immer um Meilensteine ergänzt, so dass es die beiden oben dargestellten Formen kombiniert. Das Gantt-Diagramm ist die wohl gebräuchlichste Form zur Kommunikation eines Zeitplans. Es handelt sich hierbei um eine Tabelle, in der in der ersten Spalte zeilenweise sämtliche geplanten Vorgänge und Meilensteine aufgeführt sind. Dahinter folgt ein Kalender, in den die Zeiten für diese Vorgänge und Meilensteine durch Balken eingezeichnet sind. Die Abbildung 46 zeigt das obige Beispiel als Gantt-Diagramm. Auf die genaue Bezeichnung der Meilensteine wurde in der Abbildung verzichtet, da diese immer genau den Abschluss des jeweiligen Arbeitspaketes beschreiben. Sollten andere Meilensteine definiert sein, so sollten diese mit eigenem Namen versehen sein. Wichtig ist es, die Meilensteine mit verbindlichen Terminen zu versehen, d. h. sie genauen Tagen und keinen Zeiträumen zuzuordnen. Aus diesem Grund werden für die Darstellung von Meilensteinen in der Regel Rauten verwendet. Die Spitzen der Rauten geben dabei den genauen Tag des Erreichens des Meilensteins im Plan an.

108

Projektplanung

Vorgang

Zuständig

Anmieten der Immobilie


Auswahl der Mitarbeiter


Anmelden der Rufnummer


Einrichten des Call Centers


1

Informieren über Rufnummer Marketingabteilung, Herr Meier Technik installieren


Schulungen durchführen


2

3

4

5

6

7

8

Kalenderwoche 9 10 11 12 13 14 15 16 17 18 19 20 21

= nicht kritischer Vorgang = Vorgang auf kritischem Pfad

= Meilenstein (Abschluss des Vorgangs) Abbildung 46: Beispiel für ein Gantt-Diagramm

3.4

3.4.1

Ressourcenplanung

Bedeutung der Ressourcenplanung

Ein Zeitplan beinhaltet schon einen Ressourcenplan, da Termine und Aufwand eng miteinander verbunden sind (hierauf wurde im vorherigen Abschnitt 3.3.3 zu Zeitplänen schon hingewiesen). Da eine simultane Planung von Ressourcen und Zeit sehr komplex ist, widmen wir uns erst jetzt ausführlich den Ressourcen. In der realen Planung eines Managementberatungsprojektes muss man letztendlich beide Aspekte – Zeit und Ressourcen – gleichzeitig im Auge behalten. Welches sind aber nun die wichtigsten Ressourcen in der Managementberatung? Auch wenn dies natürlich von Projekt zu Projekt differiert, so zeichnet sich doch ab, dass folgende drei Ressourcenarten besonders wichtig sind: Personalressourcen Informationen

Ressourcenplanung

109

Geld Für Managementberatungen ist das Personal dabei die wichtigste Ressource. Dies ergibt sich aus der Individualität und Integration der zu erstellenden Dienstleistung (siehe Abschnitt 1.5). Ein individuelles Ergebnis kann nicht automatisiert erstellt werden, die Interaktion mit den zu beratenden Unternehmen erfordert persönlichen Einsatz und soziale Fähigkeiten. Die Dienstleistung „Managementberatung“ ist sehr personalintensiv. Die meiste Arbeit wird individuell durch Menschen erbracht: Diese durchleuchten Kostenstrukturen, beurteilen die Effektivität von Organisationen oder entwickeln innovative strategische Konzepte. Diese Personalressourcen stammen aus dem Beratungsunternehmen, dem Unternehmen des Auftraggebers oder aus dritten Unternehmen, die als weiterer Dienstleister beauftragt werden. In Beratungsunternehmen geht man beim Personaleinsatz standardmäßig davon aus, dass das Personal mit einer üblichen Ausstattung an Geräten versorgt ist, die den räumlich mobilen Einsatz ohne lange Rüstkosten erlauben. Diese Ausstattung umfasst einen Laptop, einen Organizer [PDA] (zur elektronischen Terminabstimmung) und ein Mobiltelefon. Ziel der folgenden Planung der Personalressourcen ist, dass die richtigen Personen zum richtigen Zeitpunkt mit der notwendigen Arbeitszeit zur Verfügung stehen. Die zweite sehr wichtige Ressource für Beratungsunternehmen sind Informationen. Auch dies ergibt sich aus der Art der erstellten Leistung in der Managementberatung. Die von den Personen entwickelten Konzepte beruhen auf Informationen aus dem Unternehmen, welches beraten wird, bzw. auf Referenzinformationen, die die Managementberatung zur Verfügung stellt. Wichtig ist also, genau zu definieren, welche Informationen notwendig sind, um den entsprechenden Zugriff im Projekt dann zu gewährleisten. Dieser Zugriff auf unternehmensinterne Informationen sollte möglichst schon im Angebot geregelt werden. Die Informationen, auf die das Beratungsunternehmen zugreifen kann, ergeben sich aus durchgeführten Studien, Erfahrungen aus bisherigen Projekten, dem Know-how der Berater usw. Diese sind für den Projekterfolg sehr wichtig und die Managementberatung wird dieses Wissen bei der Angebotserstellung berücksichtigen. In der folgenden Ressourcenplanung werden – da der Zugriff auf Informationen vor Projektstart gesondert geregelt wird – die Informationen nicht weiter dargestellt. Der dritte wichtige Punkt für Beratungsunternehmen sind die finanziellen Ressourcen. Hierbei sind verschiedene Aspekte relevant. Zunächst einmal ist für den Auftraggeber wichtig, den mit dem Projekt verbundenen Gesamtaufwand zu kennen. Durch den Vergleich von Aufwand und geplantem Ergebnis kann er entscheiden, ob das Projekt tatsächlich durchgeführt werden soll. Neben diesem Gesamtaufwand ist es wichtig, das Projektbudget zu kennen. Dies ist der Betrag, der dem Auftraggeber tatsächlich belastet wird. Dieser Betrag kann vom Gesamtaufwand abweichen, da manche Kosten nicht gesondert für das Projekt ausgewiesen werden, wie das z. B. häufig für Mitarbeiter des Auftraggebers geschieht, die für das Projekt

110

Projektplanung

eingesetzt werden. Der ausgewiesene Betrag, der dem Auftraggeber tatsächlich belastet wird, ist für dessen Finanzplanung wichtig. Außerdem ist anzugeben, wofür die Kosten anfallen, um eine gewisse Transparenz über den Aufwand zu haben. Die Planung der finanziellen Ressourcen muss diesen Anforderungen genügen und somit recht differenziert erfolgen. Neben dem Zeitdruck kommt es in der Praxis immer wieder vor, dass die Auftraggeber nur geringe Personal- und Finanzressourcen zur Verfügung stellen wollen. Daher ist eine gewissenhafte Planung notwendig, denn nur so kann man als Projektleiter sicher vertreten, welche Ressourcen man zur Einhaltung des Zeitplans benötigt. Im Zusammenhang mit der Ressourcenplanung wird in diesem Kapitel auch das Risikomanagement behandelt. Über das Risikomanagement soll sichergestellt werden, dass das Projektziel auch dann noch erreicht werden kann, wenn unvorhergesehene Ereignisse Ressourcen in Anspruch nehmen, ihren gezielten Einsatz verhindern oder wenn das Projektergebnis inhaltlich nicht mehr erreicht werden kann. Eine gute Ressourcenplanung berücksichtigt daher auch die Risiken.

3.4.2

Planung der Personalressourcen

Eine genaue Planung ist nicht nur notwendig, um vom Auftraggeber die entsprechenden Ressourcen zur Verfügung gestellt zu bekommen, sondern auch, um den Mitarbeitern zu vermitteln, was von ihnen zeitlich und inhaltlich erwartet wird. Die Personalplanung ist Aufgabe des Projektmanagers, wobei dieser wiederum die im Projekt später Beteiligten so früh und so tief wie möglich einbeziehen sollte. Hier gilt das Gleiche wie bei der Zeitplanung: Nur über Einbeziehung der Betroffenen ist deren Akzeptanz zu erzielen. Zudem ist es auch hier sinnvoll, das Fachwissen der potenziellen Projektmitglieder schon in der Planungsphase zu nutzen. Besonders hilfreich sind Mitarbeiter, die bestimmte Tätigkeiten schon einmal in einem vergleichbaren Projekt durchgeführt haben. Erfahrungswerte sind gerade in der Managementberatung mit komplexer Aufgabenstellung oft viel hilfreicher als analytische Überlegungen zur Vorgangsdauer. Die Bedeutung der richtig ausgewählten Projektteilnehmer für den Projekterfolg kann man nicht hoch genug einschätzen, leider wird sie aber häufig unterschätzt. Letztendlich sind es Menschen, die das Projekt tragen. Daher sind sie die wichtigste Ressource. Eine der Hauptaufgaben eines Projektleiters liegt in der richtigen Zusammenstellung seines Projektteams und später in dessen Führung. Daher sollte der Projektleiter maßgeblichen Einfluss auf die Personalplanung haben oder – noch besser – diese selbst durchführen. Wurde dieser Einfluss nicht gewährt, sollte man als Projektleiter nicht genügend qualifiziert zusammengestellte oder zu kleine Teams nicht akzeptieren. Die Planung der Personalressourcen muss in qualitativer und quantitativer Hinsicht erfolgen. So muss die richtige Anzahl von Personen mit den notwendigen Qualifikationen zum laut

Ressourcenplanung

111

Netzplan notwendigen Zeitpunkt zur Verfügung stehen. Zuerst wollen wir uns hier den qualitativen Aspekt anschauen, d. h. die Gewinnung der „richtigen“ Mitarbeiter. Das Instrument zur Beschreibung, welche Fähigkeiten und Qualifikationen die Projektmitarbeiter besitzen müssen, ist die Stellenbeschreibung. In Stellenbeschreibungen für die Projekte definieren die Projektleiter ihren Personalbedarf und beschreiben diesen quantitativ und qualitativ. Die Stellenbeschreibung fasst die Aufgabe, die von einer Person wahrgenommen werden soll, schriftlich zusammen und führt die zur Durchführung notwendigen persönlichen und fachlichen Qualifikationen auf. Die wichtigsten Elemente einer Stellenbeschreibung sind (vgl. Wischnewski 2001, S. 55): Projektbezeichnung und Projektnummer Name des Mitarbeiters (wenn Stelle bereits besetzt ist) Zuordnung zur Linienorganisation und zur Projektorganisation Funktion im Projekt Zeitraum der Projektzuordnung, ggf. Dauer der Stelle Übergeordneter Mitarbeiter (disziplinarischer Vorgesetzter) Untergeordnete Mitarbeiter und Art der Zuordnung (fachlich, disziplinarisch) Vertreter bei Abwesenheit Vollmachten (Vertretungsvollmacht für das Unternehmen) Verantwortlichkeiten und Kontrollpflichten Aufgaben Notwendige Qualifikationen/Fähigkeiten zur Wahrnehmung der Stelle (fachlich, persönlich, notwendige Erfahrungen) Unterschriften der Vorgesetzten und der Personalabteilung, um der Stellenbeschreibung formale Wirksamkeit zu verleihen Für jede zu besetzende Projektstelle wird eine solche Stellenbeschreibung erstellt, die sich aus einer Zuordnung der Arbeitspakete zu (zu diesem Zeitpunkt noch hypothetischen) Personen ergibt. Die Zuordnung erfolgt so, dass gleiche Aufgaben zu einer Stelle gebündelt werden. Die Frostigkeit (Dauer) der Aufgabe und der Umfang (ganze Stelle, halbe Stelle, viertel Stelle) ergeben sich aus dem Projekt, wie es im Netzplan geplant ist. Der Ablauf kann dabei – unter Berücksichtigung des kritischen Pfades – ggf. noch geändert werden, damit Personen nicht überlastet werden. Die Zuordnung der Aufgaben zu Stellen(-beschreibungen) muss so erfolgen, dass zu jedem Zeitpunkt im Projekt die richtigen Personalkapazitäten zur Verfügung stehen. Dies kann geprüft werden, indem man für jede Woche anhand des Netzplans ermittelt, wie viele Personen mit welchen Qualifikationen benötigt werden, und prüft, ob dies durch die geplanten Stellen abgedeckt ist.

112

Projektplanung

Bei dieser zeitlichen Zuordnung ist zu beachten, dass der Zeitbedarf für die Aufgabenerfüllung stark von der Erfahrung des Mitarbeiters abhängt. So zeigt sich bei vielen Projekten bei einem Wechsel der Zuständigkeiten, dass der Zeitbedarf für einzelne Aufgaben je nach Mitarbeiter extrem schwankt (siehe hierzu auch die Praxisbox 11). Das notwendige Erfahrungspotenzial ist daher in der Stellenbeschreibung definiert, so dass gleich ein Mitarbeiter mit der entsprechenden Erfahrung gesucht werden kann. Sollte ein geeigneter Mitarbeiter nicht gefunden werden, so muss ggf. der Plan angepasst werden. Mit den Mitarbeitern, die für die Aufgabe vorgesehen sind, muss vor Beginn des Projektes ein Gespräch über die Stellenbeschreibung geführt werden. Hierbei werden Aufgabe, Erwartungen und Kompetenzen erläutert und dem Mitarbeiter die Möglichkeit gegeben, sich dazu zu äußern und ggf. auch eine Änderung der Stellenbeschreibung zu bewirken. Ebenso kann eine Stellenbeschreibung auch der Ausgangspunkt für eine Ausschreibung der Stelle sein, auf die sich dann interessierte Mitarbeiter oder externe Personen bewerben können. Stellenbeschreibungen im Rahmen eines Projektes wird man nur für solche Mitarbeiter erstellen, die zu einem überwiegenden Teil ihrer Arbeitszeit und für einen längeren Zeitraum (also etwa länger als drei Monate) für das Projekt arbeiten. Für Mitarbeiter, die nicht in diesem Umfang in das Projekt eingebunden sind, sollte der Einfachheit halber die Projektaufgabe anhand einer Aufgabenbeschreibung, die aus dem Projektstrukturplan abgeleitet ist, erläutert werden. Praxisbox 11 zeigt ein Praxisbeispiel einer solchen Stellenbeschreibung.

Praxisbox 11: Stellenbeschreibung für fachseitigen Projektmitarbeiter Eine Stellenbeschreibung wird für Projekte im Inhouse Consulting dann erstellt werden, wenn für die Fachseite ein Projektmitarbeiter gesucht wird. Falls es sich um eine befristete Projektstelle handelt, werden zudem noch die Einbindung in die Projektorganisation und die Befristung aufgeführt. Bei der Stellenbeschreibung in der Abbildung 47 handelt es sich um eine Minimalversion, die im Einzelfall noch ergänzt wird. Bei gleicher Stellenbeschreibung kann je nach tatsächlichem Vorwissen und Erfahrung des Stelleninhabers die tatsächlich zur Aufgabenerfüllung notwendige Zeit stark differieren. So ergaben sich in einem Projekt des Inhouse Consultings Varianzen von einem Personentag bis zu vier Personentage zur Erfüllung der gleichen Aufgabe. Hierbei hat es sich um die Programmierung von komplexeren Excel-Tabellen zur Leistungsnormierung gehandelt, die mit dem entsprechenden Fachwissen über Excel und Leistungsnormierung an einem Tag zu erstellen waren. Mussten die Mitarbeiter sich dieses Wissen erst noch aneignen, dann vervierfachte sich die benötigte Zeit. Auch zeigt die Erfahrung, dass die Dringlichkeit, die eine Aufgabe für einen Mitarbeiter besitzt, die Schnelligkeit der Aufgabenerfüllung stark beeinflusst. Nachteilig wirkt sich in der

Ressourcenplanung

113

Regel aus, wenn Mitarbeiter nur lose in die Projektorganisation eingebunden sind (etwa nur fachlich) und von ihrem Linienvorgesetzten vom Projekt abweichende Prioritäten vorgegeben bekommen. In diesem Fall wird die Erledigung der Projektaufgaben oft zurückgestellt werden und die Bearbeitungszeit verlängert sich.

Stellenbeschreibung Projekt und Projektnummer

ISI Call Center, 009/18539-A

Organisationseinheit/ Abteilung

SNL KT (Serviceniederlassung Kundentelefon), 82393

Stellenbezeichnung

Consultant

direkt vorgesetzte Stelle(n)

Leiter der Serviceniederlassung

direkt unterstellte Stelle(n)

keine

Stellenzweck/Arbeitsziele x Projektdurchführung. Stelleninhalt/Arbeitsaufgabe verantwortlich für ...

x

Die Aufgabe der Bedienung umfasst: x Zusammenstellung der Controllingdaten der SNL KT, dies umfasst sowohl das Finanzcontrolling als auch Call-Center-spezifische Daten x Analyse der Daten x Konzeption eines neuen Controlling-Systems zur aufwandsgesteuerten Budgetierung x Erstellung eines Pflichtenheftes für das o. g. System x Abstimmung des Pflichtenheftes mit dem EDV-Dienstleister, der mit der Umsetzung beauftragt wird x Präsentation der Ergebnisse x Überwachung der Umsetzung x Einführung von Service Level Agreements

Weisungsbefugnisse Welche: fachliche, disziplinarische? Wem gegenüber? (Stellenbezeichnung)

Fachliche Führung der Controlling- und Call-Center-Mitarbeiter im Rahmen der Projektaufgabe (nicht Regeltätigkeit) – keine disziplinarischen Befugnisse Budgetverantwortung keine externe Vollmachten/Befugnisse keine

Anforderungsprofil der Stelle fachlich

persönlich

In Anlehnung an Inhouse Consulting Deutsche Post World Net Abbildung 47: Beispiel für eine Stellenbeschreibung

114

Projektplanung

Der quantitative Aspekt der Planung der Personalressourcen befasst sich mit der Frage, wie viele Personen für das Projekt notwendig sind. Die Planungsgröße ist in Managementberatungen hierbei üblicherweise Personentage (PT). Wenn eine Person einen Tag ausschließlich an einer Aufgabe arbeitet, so benötigt diese Aufgaben einen Personentag.7 Benötigt man also zur Abarbeitung eines Arbeitspaketes fünf Personentage, so könnte dieses Arbeitpaket in einer Arbeitswoche mit fünf Arbeittagen erledigt werden. Es ist jedoch zu beachten, dass die Personentage leider nicht realen Tagen entsprechen – nicht einmal den Arbeitstagen. Jeder Mitarbeiter benötigt immer auch Zeit, die nicht produktiv im Sinne der Personentage ist. Dies sind zum Beispiel Urlaubstage, Krankheitstage, Schulungstage, Tätigkeiten, die außerhalb der eigentlichen Projektaufgabe liegen, wie etwa Reisezeiten, Reisekostenabrechnungen, Teamgespräche, Büroorganisation etc. Eine Tätigkeit, die fünf Personentage in Anspruch nimmt, wird so in der Regel länger als eine Woche dauern. Zur Planung der benötigten Arbeitszeit je Arbeitspaket ist es sinnvoll, Personentage zugrunde zu legen. Zur Planung der benötigten Personen muss allerdings dann ein Wert angesetzt werden, der berücksichtigt, dass eine Person nicht fünf Personentage je Woche ausschließlich für das Projekt arbeiten kann. Eine praktische Lösung hierfür ist in Abbildung 48 dargestellt.

7

Früher war hierzu die Bezeichnung Manntag üblich. Diese findet sich auch noch in älteren Publikationen oder Vorlagen. Personentage sind auch häufig die Basis für eine Rechnungsstellung der Managementberatung. Die Personentage werden dann mit einem vereinbarten Tagessatz multipliziert. Eine synonyme Bezeichnung für Personentage sind Menschtage.

Ressourcenplanung

115

Praxisbox 12: Personalkapazitätsplanung Wenn im Rahmen der Projektplanung die Personalressourcen geplant werden, erfolgt dies zunächst durch eine Übersichtsdarstellung der benötigten Beraterressourcen anhand eines Project Resource Requirements-Templates (einer Vorlage zur Personalbedarfsermittlung), welches im ersten Project Fact Sheet (Projektkurzbeschreibung) enthalten sein muss. Die Abbildung 48 zeigt dieses Template zur Personalbedarfsermittlung. Project:

Assignment Manager:

Client:

Date:

Year Type of required resource

Required skills/ experiences

1 <Partner, Ass. Partner, Project Manager, Senior Consultant, Consultant, Researcher>

mm.yy – mm.yy

Remarks Partner

Month

Duration 2

3 4 5 6 Required time

7 8

9 10 11 …

Available time

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 48: Project Resource Requirements Im Project Resource Requirements-Template sind die notwendigen Personen nach Hierarchiestufe (erste Spalte), erforderlichen Fähigkeiten (zweite Spalte) und Dauer des Einsatzes (dritte Spalte) aufgeführt. Mit dieser Information kann im Rahmen der ersten Beurteilung entschieden werden, ob die für das Projekt erforderlichen Personalressourcen auf Seiten der Beratung zur Verfügung stehen würden. Um eine bessere Übersicht zu erlangen, wird bei umfangreicheren Projekten die Planung visualisiert. In der Abbildung 49 ist dies beispielhaft dargestellt. Die Arbeitspakete (Activities) sind hier durch die Buchstaben A bis G gekennzeichnet. Ihnen sind die notwendigen Ressourcen zugeordnet. Die Berechnung erfolgt in FTE (Full Time Equivalents), was Vollzeitmitarbeitern entspricht. So ergeben beispielsweise zwei Personen, die halbtags arbeiten, rechnerisch einen FTE. Es zeigt sich bei Vergleich mit der gestrichelt eingezeichneten Linie der verfügbaren Ressourcen in Woche drei und dann wieder ab Woche fünf eine Personalunterdeckung.

116

Projektplanung

Required capacity in FTE Activities D

Demand exceeds capacity

15

? E

10

A

F

C

5 B

G 0 I

II

III

IV

V

VI

VII

VIII

IX

Time in weeks

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 49: Graphic Resource Plan Bei der Kapazitätsberechnung wird von vier Arbeitstagen je Woche für das Projekt je Mitarbeiter gerechnet, um genügend Zeit für die sonst auch noch notwendigen Arbeiten (insbesondere interne Aufgaben der Berater zur Weiterentwicklung der Beratung und interne Abstimmungen) zu haben. Durch diese Planung sollen mögliche Konflikte vermieden werden. Diese Vorgehensweise wird im Angebot für den Auftraggeber deutlich sichtbar aufgeführt und bei der Berechnung der Anzahl der notwendigen Berater berücksichtigt. Urlaubs-, Krankheits- und Schulungsvertretungen werden gesondert im Projekt geplant. Das Inhouse Consulting verpflichtet sich dem Auftraggeber gegenüber, stets für die Bereitstellung der lt. Projektplan notwendigen Personalressourcen zu sorgen.

In der qualitativen Betrachtung wurden den Arbeitspaketen Stellen zugeordnet. Nun sollte kontrolliert werden, wie stark die einzelnen Stellen belastet sind. Hierzu geht man den Netzplan noch mal durch und ordnet zeitlich die sich aus den Arbeitspaketen ergebende Arbeitsbelastung in Personentagen den Stellen zu. Diese Zuordnung kann in einem Gantt-Diagramm8 wiedergegeben werden. Sind den Stellen schon Personen zugeordnet, so kann man natürlich gleich diese anstatt der Stellen eintragen. Die folgende Abbildung 50 auf S. 117 zeigt ein solches Gantt-Diagramm für ein Projekt zur Kostenoptimierung eines Fuhrparkmanagements. Wie in der Managementberatung häufig zu finden, wird hier auf Wochenbasis (mit Kalenderwochen) und Personentagen geplant. Die Personentage sind als Ziffer in der Kalenderwo-

8

Benannt nach deren Erfinder mit dem Namen Gantt.

Ressourcenplanung

117

chenspalte eingetragen. Im internationalen Umfeld sollte man mit der Verwendung von Kalenderwochen übrigens vorsichtig sein, da diese dort häufig unbekannt sind. Bei umfangreicheren Projekten wird man die Gantt-Diagramme durch eine Projektmanagementsoftware erstellen lassen, die auch schon bei der Erstellung des zugrunde liegenden Netzplanes zum Einsatz kommt (vgl. hierzu Seite 96).

Projekt Kostenoptimierung Fuhrparkmanagement Aufgabe Ist-Kosten erfassen Kostenstrukturanalyse durchführen Planung Benchmarking Ansprache Benchmarkingpartner Datenerhebung Benchmarking Aufbereitung Daten Benchmarking Kennzahlenvergleich Benchmark Abstimmung mit Fachbereich Präsentation erstellen Abstimmung mit Auftraggeber Workshop Optimierungsmaßnahmen Abstimmung Maßnahmenpaket Akquise neuer Projekte

zuständig Müller Wegmann Müller Müller Müller Müller Müller Wegmann Müller Wegmann Wegmann Wegmann Wegmann

Kalenderwoche 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 3 3 3 3 3 2 2 2 2 2 2 5 5 5 5 5 5 1 2 2 2 2 2 1 1 1 1 1 1 2 2 2 5 5 5 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2

Abbildung 50: Beispiel für ein Gantt-Diagramm Man kann nun die Gesamtsumme der je Woche und die insgesamt anfallenden Personentage einfach berechnen und diese mit der verfügbaren Kapazität an Personentagen abgleichen. Um die Über- oder Unterlastungen einzelner Personen (Projektstellen) besser zu erkennen, kann man für die Personen jeweils ein Gantt-Diagramm aufstellen, das ihre Arbeitsbelastung in der Planung aufzeigt.

Projekt Kostenoptimierung Fuhrparkmanagement Aufgabe Kostenstrukturanalyse durchführen Abstimmung mit Fachbereich Abstimmung mit Auftraggeber Workshop Optimierungsmaßnahmen Abstimmung Maßnahmenpaket Akquise neuer Projekte Summe maximale Kapazität Unter-/Überdeckung

zuständig Wegmann Wegmann Wegmann Wegmann Wegmann Wegmann

Kalenderwoche 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 2 2 2 2 2 1 1 1 2 2 2 5 5 5 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 0 0 0 0 0 2 2 3 5 5 7 7 7 4 2 2 2 2 2 2 2 2 2 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 2 2 1 -1 -1 -3 -3 -3 0 2 2 2 2 2 2 2 2 2

Abbildung 51: Personenspezifisches Gantt-Diagramm für Wegmann

118

Projektplanung

Projekt Kostenoptimierung Fuhrparkmanagement Aufgabe Ist-Kosten erfassen Planung Benchmarking Ansprache Benchmarkingpartner Datenerhebung Benchmarking Aufbereitung Daten Benchmarking Kennzahlenvergleich Benchmark Präsentation erstellen Summe maximale Kapazität Unter-/Überdeckung

zuständig Müller Müller Müller Müller Müller Müller Müller

Kalenderwoche 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 3 3 3 3 3 2 5 5 5 5 5 5 1 2 2 2 2 2 1 1 1 3 3 5 8 8 5 5 5 8 2 2 3 3 1 0 0 0 0 0 0 0 0 0 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 1 1 -1 -4 -4 -1 -1 -1 -4 2 2 1 1 3 4 4 4 4 4 4 4 4 4

Abbildung 52: Personenspezifisches Gantt-Diagramm für Müller In Abbildung 51 und Abbildung 52 sind jetzt jeweils in der Zeile „Summe“ die laut Plan anfallenden Personentage in jeder Kalenderwoche aufgeführt. Die Zeile darunter zeigt die maximale Kapazität, die maximale Arbeitsleistung des Mitarbeiters für das Projekt je Kalenderwoche. Diese ist im Beispiel vier Personentage. Die restliche Arbeitszeit der Person wird mit weiteren Tätigkeiten ausgefüllt und steht hier zur Planung des Projektes nicht zur Verfügung. Die letzte Zeile („Über-/Unterdeckung“) zeigt seine Auslastung. Hier wird berechnet, um wie viele Personentage der Mitarbeiter über- oder unterlastet ist. Steht in dieser Zeile ein positiver Wert, so ist noch Kapazität vorhanden, steht dort ein negativer Wert, so ist der Mitarbeiter im Plan über seine tatsächliche Kapazität hinaus verplant. In diesem Fall müssen der Plan oder die Personenzuordnung geändert werden. Hierbei sind folgende Möglichkeiten zu prüfen (vgl. Kerber-Kunow 2000, S. 17; Lock 1997, S. 182): Ist eine Verschiebung der Tätigkeiten möglich, so dass Aufgaben aus Zeiten mit Überlastung in Wochen mit freien Kapazitäten geschoben werden? Dies kann unter Ausnutzung von Pufferzeiten geschehen, d. h., Arbeiten, die nicht auf dem kritischen Pfad sind, werden verschoben. Zudem kann die Netzplanlogik noch einmal überprüft werden, um festzustellen, ob vielleicht doch einige Abhängigkeiten aufgelöst werden können. Ist eine Verlagerung auf andere Personen im Projekt möglich? In unserem Beispiel sieht man etwa, dass in den Woche 32 bis 37 Wegmann noch Aufgaben im Umfang der Unterdeckung von Müller übernehmen kann. Bis auf Woche 38 lässt sich so schon der Engpass bei Müller beseitigen. Der Engpass in Woche 38 ließe sich dann durch eine Verschiebung beseitigen, wenn nämlich mit dem Benchmarking eine Woche vorher begonnen wird. Dann bestünde sogar noch für Woche 38 die Möglichkeit, für Wegmann einzuspringen. Und in Woche 39 könnte Müller für Wegmann Aufgaben übernehmen. Ist eine Verlagerung von Tätigkeiten auf Personen außerhalb des Projektes oder externe Dienstleister möglich? Dies wäre dann für unser Beispiel etwa noch eine Option für Woche 40 bis 42, wo Wegmann einen Engpass hat. Es wäre etwa denkbar, dass jemand bei der Abstimmung mit der Fachseite unterstützt. Die personenbezogene Kapazitätsdarstellung kann auch der Überwachung des Arbeitseinsatzes und der Produktivität dienen. Durch die Erfassung der je Aufgabe geleisteten Per-

Ressourcenplanung

119

sonentage kann die Einhaltung der Planung leicht überwacht werden. So wird auch frühzeitig erkannt, wenn die vereinbarten Ressourcen nicht zur Verfügung stehen oder durch Krankheit ausfallen.

Praxisbox 13: Personenbezogene Kapazitätserfassung Im Inhouse Consulting werden den Gantt-Diagrammen angelehnte Kapazitätstabellen für die Projektüberwachung sowie das Controlling der gesamten Managementberatung eingesetzt. Monatlich muss jeder Mitarbeiter eine Übersicht über seine Zeitverwendung lt. Plan und Ist erfassen und an das Controlling des Inhouse Consultings weiterleiten. Abbildung 53 zeigt exemplarisch, wie diese Tabellen strukturiert sind. Der Zeiteinsatz jedes Mitarbeiters wird in einer EDV-Anwendung erfasst, die es erlaubt, Unternehmens- und projektübergreifende Betrachtungen anzustellen. So dient diese Zeiterfassung auch der Erstellung von Projektrechnungen, soweit diese nach geleisteten Personentagen abgerechnet werden. Es wird kontrolliert, ob die dem Projekt laut Projektplan zur Verfügung stehen Kapazitäten auch tatsächlich eingesetzt werden. Zudem können wichtige Kennzahlen für die Managementberatung insgesamt gewonnen werden, z. B. das „Verhältnis von Produktivzeit zur Gesamtzeit“ oder das „Verhältnis der mit den Auftraggebern anrechenbaren Zeit (chargeable time) zur Gesamtarbeitszeit“. Außerdem erlaubt diese personenbezogene Art der Kapazitätsbetrachtung eine Multi-Projektsicht, wie sie gerade für Projektmanager wichtig ist, die mehrere Projekte leiten und ihre Zeit entsprechend einteilen müssen (siehe hierzu die drei Zeilen unter „chargeable time“ in der Tabelle). Seit einiger Zeit wird zudem Einsatzplanung anhand entsprechender Tabellen durchgeführt. So wird nicht nur rückwärts die Auslastung kontrolliert, sondern es wird eine personenbezogene Multi-Projekt-Planung vorgenommen.

120

Projektplanung

Kapazitätsbetrachtung Projektpartner in Tagen Kalenderwoche

non-chargeable Time

chargeable time

Aufgabe Projekt Fuhrparkmanagement Projekt Call Center Projekt Strategie Krankheit Urlaub Schulung interne Aufgaben Recruiting Projektakquise Sonstiges Feiertage

Summe maximale Kapazität Unter-/Überdeckung Summe chargeable Time Summe non-chargeable Time

Summe

36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 1 1 1 1 1 1 2 1 1 0 0 1 0,5 1 1 0 0 1 3 1 1 1 1 1 1 1 0 0 1 0,5 1 1 1 1 0 0 0 0 1 1 1 1 1 0 0 1 0,5 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 5 4 0 0 0 0 0 2 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 1 1 0,5 1 1 0 0 1 0,5 1 1 1 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 2 0 0 0,5 1 0 0 0 1 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0,5 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 1 0 0 2 1 5,0 5,0 5,0 6,0 5,0 5,0 5,0 5,0 5,0 5,0 5,0 5,0 5,5 5,0 5,0 5,0 5,0 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 0 0 0 1 0 0 0 0 0 0 0 0 0,5 0 0 0 0 2 4 2 2 3 3 4 3 3 0 0 3 1,5 3 3 1 2 3 1 3 4 2 2 1 2 2 5 5 2 4 2 2 4 3

Anteil in % an Gesamt

13,5 16,5 9,5 1 12 4 11 4 6,5 2,5 6 86,5 85

16 % 19 % 11 % 1% 14 % 5% 13 % 5% 8% 3% 7% 100 %

39,5 47

46 % 54 %

Exemplarische Darstellung in Anlehnung an das Erfassungssystem von Inhouse Consulting, Deutsche Post World Net Abbildung 53: Personenbezogenes Gantt-Diagramm zur Kapazitätsüberwachung (Ist-Daten) Eine andere Darstellung des gleichen Sachverhaltes wie in den personenbezogenen GanttDiagrammen erfolgt in einem so genannten Arbeitslastdiagramm (siehe Abbildung 54). Diese Darstellung hat den Vorteil, dass die darin enthaltene Information optisch schnell aufgenommen werden kann. Zur raschen Kommunikation ist dies recht hilfreich. Die Balken, die die horizontale Linie schneiden, übersteigen die hierdurch gekennzeichnete maximale Kapazität des Mitarbeiters für das Projekt. Der Abbildung ist der Einsatzplan von Wegmann aus Abbildung 51 auf S. 117 zugrunde gelegt. Für die tatsächliche Planung ist diese Darstellung aber weniger geeignet, da man die konkreten Werte nicht so gut ablesen kann.

8 Akquise neuer Projekte 7 Abstimmung Maßnahmenpaket Workshop Optimierungsmaßnahmen Abstimmung mit Auftraggeber Abstimmung mit Fachbereich

6 5 4 3 2

Kostenstrukturanalyse durchführen

1

52

50

46

48

44

42

38

40

36

34

32

30

0

Für viele: Blazek/Zillmer (2001), S. 114 Abbildung 54: Beispiel für ein Arbeitslastdiagramm eines Mitarbeiters

Kostenplanung

121

Sollten neben dem Personal auch noch Sachressourcen zu planen sein (etwa Rechenzeit bei Simulationen), dann kann dies mit den gleichen Planungsmethoden geschehen, wie sie zur quantitativen Personalplanung dargelegt wurden. Hier unterscheiden sich Sachmittel und Personal nicht.

3.5

3.5.1

Kostenplanung

Sichtweisen auf Projektkosten in der Managementberatung

Was kostet es, ein Projekt durchzuführen? An der Beantwortung dieser Frage sind verschiedene am Projekt beteiligte Parteien interessiert. In erster Linie ist der Auftraggeber für das Projekt verantwortlich. Er muss entscheiden, ob es sich für ihn lohnt, das Projekt zu starten. D. h., er muss abwägen, ob die zu erwartenden Projektergebnisse die Projektdurchführung und -kosten rechtfertigen. Für die an ein Projekt zur Entwicklung von Empfehlungen anschließende Entscheidung über die Umsetzung der Empfehlungen, d. h. die Implementierung der Projektergebnisse, muss er auch die Kosten kennen, die mit der Implementierung der im Projekt durch die Managementberatung entwickelten Vorschläge verbunden sind. An der Beantwortung der Frage, was kostet ein Projekt, ist das Beratungsunternehmen ebenfalls aus seiner eigenen Sichtweise interessiert. Es muss dem potenziellen Auftraggeber ein Angebot machen, zu welchen Konditionen (Preis) es das Projekt durchführen will. Das Beratungsunternehmen muss kalkulieren, welche Kosten ihm für die Projektdurchführung entstehen und welche Preisuntergrenze aus Kostensicht nicht unterschritten werden sollte. Die Kalkulation der Kosten eines Managementberatungsprojektes muss also auch aus Sicht der Managementberatung erfolgen. Insgesamt lassen sich also folgende Sichtweisen auf die Kosten eines Beratungsprojektes unterscheiden: Projektkosten aus Sicht des Auftraggebers, Projektkosten aus Sicht der Managementberatung und Implementierungskosten zur Umsetzung der Projektergebnisse.

122

Projektplanung

Bei dieser Unterscheidung wird davon ausgegangen, dass das Ziel eines Managementberatungsprojektes zunächst die Entwicklung einer Empfehlung (eben eine Beratung) ist. Die Projektkosten beziehen sich also auf diese Entwicklung des Ratschlages – die Umsetzung des Ratschlages findet dann in der so genannten Implementierung statt. Dies kann in einem Folgeprojekt oder durch das Unternehmen selbst erfolgen. Bei reinen Implementierungsprojekten (die ja auch zum Teil von Managementberatungen durchgeführt werden) ist die hier vorgenommene Trennung in Projektkosten und Implementierungskosten schwierig, da Projektdurchführung und Implementierung identisch sind. Es fallen keine oder nur verhältnismäßig geringe Kosten zur Entwicklung von Vorschlägen an. Die oben aufgeführten Ansätze für die Kostenkalkulation werden im Folgenden näher untersucht.

Projektkosten aus Sicht des Auftraggebers Alle Kosten, die für den Auftraggeber anfallen, bis er die Empfehlung des beauftragten Beratungsunternehmens erhalten hat, zählen zu seinen Projektkosten. Im Einzelnen zählen zu den Projektkosten aus Sicht des Auftraggebers: Alle Rechnungen, die der Auftraggeber an die Managementberatung zu zahlen hat Alle Kosten, die im eigenen Unternehmen entstanden sind und unmittelbar auf das Projekt zugerechnet werden können, wie etwa Personalkosten von Mitarbeitern, die für das Projekt arbeiten, Kosten für Marktstudien, Reisekosten für Expertengespräche, weitere größere Sachkosten, wie z. B. Softwareanschaffung etc. Alle Kosten, die mittelbar durch das Projekt verursacht werden, wie Nutzung vorhandener eigener Räume durch die Mitarbeiter des Beratungsunternehmens oder eigene Projektmitarbeiter, Dienstwagen, Sozialleistungen etc. Die Projektkosten können als Projektgesamtkosten oder als Projekteinzelkosten dargestellt werden. Projektgesamtkosten beinhalten sämtliche mit dem Projekt verbundenen oben aufgeführten Kosten (Rechnungen, unmittelbare und mittelbare Kosten). Diese sind dann für den Auftraggeber (unterstützt durch den Projektleiter) wichtig, wenn er abschätzen möchte, ob der für das Projekt getriebene Aufwand durch den Nutzen des zu erwartenden Ergebnisses (Nutzen der Empfehlung) für das Unternehmen gerechtfertigt ist. Da die Kosten der Implementierung und der sich ergebende Ertrag hierdurch vor Projektbeginn meist noch unbekannt sind, dienen die Projektgesamtkosten einer ersten Plausibilisierung, ob der Projektaufwand noch vertretbar ist. Projekteinzelkosten aus Sicht des Auftraggebers umfassen das Projektbudget im engeren Sinne, also sämtliche Kosten, die extra nur für das Projekt geplant werden und als Geldmittel

Kostenplanung

123

für das Projekt zur Verfügung stehen. Dies sind die direkten Rechnungen und die unmittelbar zurechenbaren Kosten. In der Regel sind die Personalkosten der Vollzeit-Projektmitarbeiter, Beraterkosten, Reisekosten, Sachkosten (etwa für Studien, Subunternehmer etc.) enthalten, nicht aber Raumkosten, Personalkosten für Mitarbeiter, die nur einen geringen Anteil ihrer Arbeitszeit für das Projekt aufbringen, oder Sachkosten für Büromaterial etc. Die Abgrenzung von Projektgesamtkosten und Projekteinzelkosten ist von Unternehmen zu Unternehmen unterschiedlich und hängt vom Kostenrechnungssystem der jeweiligen Firma ab. Die Planung der Projekteinzelkosten ist wichtig, weil diese in der Regel den Geldbetrag wiedergeben, der für die Projektdurchführung notwendig ist und nicht über sonst im Unternehmen anfallende Kosten abgedeckt wird. Zweckmäßig ist es, für die Projekteinzelkosten eine Projektkostenstelle einzurichten, über die diese Kosten abgedeckt werden können (Erläuterung hierzu siehe im nächsten Abschnitt). Der Projektkostenstelle wird ein Projektbudget, d. h. ein Geldbetrag, zur Verfügung gestellt. Die Höhe des Budgets wird auf Basis der Projektpläne ermittelt und mit zunehmender Konkretisierung der Pläne ebenfalls präzisiert.

Projektkosten aus Sicht des Managementberatungsunternehmens Die Kosten, die das Projekt aus Sicht der Managementberatung verursacht, sind für die interne Kalkulation innerhalb des Beratungsunternehmens wichtig und sie sind ein wichtiger Faktor bei der Preisgestaltung im Rahmen des Angebots. Diese Kosten sind aber nicht mit dem Rechnungsbetrag (Preis) des Beratungsangebots zu verwechseln. Der Preis kann sich nach weiteren Faktoren ausrichten, wie Angebot und Nachfrage oder politischen Entscheidungen (etwa günstigere Beratungssätze für interne Beratungen), und wird Gemeinkostenzuschläge, Umsatzsteuer (wenn keine umsatzsteuerliche Gemeinschaft vorliegt, wie es bei internen Beratungen oft der Fall ist), Risikoauf- oder -abschläge und einen Gewinn enthalten. Kosten, die in einer Managementberatung anfallen, umfassen die Personalkosten der Berater und des Support-Personals (das im Rechnungswesen, bei der Charterstellung oder etwa bei der Reisebuchung arbeitet), Reisekosten, Bürokosten, Fortbildungen, Teamevents etc. Bei der Kalkulation der Kosten für ein Projekt kann man hierbei natürlich wieder die direkt (ummittelbar) durch einen Projekteinsatz entstehenden Kosten (Projekteinzelkosten) und die Summer aller Kosten inkl. mittelbarer Projektkosten (Projektgesamtkosten) unterscheiden – diesmal natürlich auch aus Sicht des Managementberatungsunternehmens. Die Projekteinzelkosten der Managementberatung sind die Personalkosten der auf dem Projekt eingesetzten Berater und Projektmanager, direkt zurechenbare Reisekosten und ggf. Kosten für Studien etc., die für ein Projekt angeschafft werden. Die Projektgesamtkosten beinhalten darüber hinaus einen Anteil zur Deckung sämtlicher Kosten, die nicht direkt für das Projekt anfallen (Gemeinkosten), wie Kosten für ein Support-Team (bei allgemeinen Aufgaben), die Unternehmensleitung, Raumkosten, Dienstwagen etc. Die Projekteinzelkosten sollten in jedem Fall durch den Projekterlös gedeckt werden und stellen eine Preisuntergrenze für ein Projektangebot dar. Einen Beitrag zur Deckung der Ge-

124

Projektplanung

meinkosten steuern solche Preise allerdings nicht bei. Aus firmenpolitischen Gründen kann einmal eine solche Preisstellung mit Unterdeckung der Gesamtkosten für einzelne Projekte angeraten sein. Dies kann etwa zur Gewinnung neuer Kunden, zum Einstieg in eine neue Branche oder ein neues Beratungsfeld oder zur Auslastung freier Kapazitäten sinnvoll sein. Langfristig und über alle Projekte gesehen müssen die Gemeinkosten aber erwirtschaftet werden (vgl. Fritz/Oelsnitz 2001, S. 149).

Implementierungskosten Hierbei handelt es sich um die Kosten, die entstehen, wenn die Empfehlung eines Beratungsprojektes umgesetzt wird. Die Planung und Bewertung dieser Kosten erfolgt nach den Vorgaben für die Aktivitäten, die im Beratungsprojekt vorgeschlagen werden. Gemeinkosten, die zwar in einem Zusammenhang mit der Implementierung stehen, aber nicht losgelöst von anderen Aufgaben anfallen, sind bei den Implementierungskosten meist nicht berücksichtigt. Dies sind Mietkosten (wenn das Team im Unternehmen selbst untergebracht ist und nicht in einem eigenen Gebäude oder Büro sitzt), Büromaterial, Sozialleistungen oder Gehälter von Mitarbeitern, die nur zu einem geringen Teil an der Implementierung beteiligt sind (etwa die Controller, die Daten zuliefern). Die Schätzung von Implementierungskosten sollte gemeinsam von Beratungsunternehmen und Auftraggeber vorgenommen werden. Ausschlaggebend ist dabei die Sicht des Auftraggebers, der das Unternehmen vertritt und letztlich entscheiden muss, ob die vom Berater empfohlenen Maßnahmen in seinem Unternehmen umgesetzt werden sollen. Daher sollte die Managementberatung bei der Planung dieser Kosten bereits sehr eng mit dem Auftraggeber zusammenarbeiten. Für die Entscheidung der Umsetzung ist eine Gegenüberstellung der erwarteten materiellen und immateriellen Erträge zu den notwendigen Investitionen (Implementierungskosten) vorzunehmen. In Managementberatungsprojekten ist die Frage der Erträge je nach Projekt unterschiedlich gut beurteilbar – dies kann von sehr leicht bis zu unmöglich reichen. Handelt es sich beispielsweise um ein Kostensenkungsprojekt für einen abgegrenzten Bereich, so lassen sich die Einsparungen recht präzise beurteilen. Ein Projekt zur Einführung eines Corporate Intranets in einem dezentralen Konzern hingegen ist vom Ertrag her nicht seriös zu bewerten. Effekte einer solchen Maßnahme sind eine verbesserte internationale Zusammenarbeit, einfachere Schnittstellen, ein besseres Wissensmanagement, schnellere Integration neuer Anwendungen etc. Zwar bietet die Literatur zum Dienstleistungsmanagement zur Bewertung solcher Maßnahmen einige konzeptionelle Ansätze (etwa Bruhn 1998, 2000), diese basieren jedoch auf vielen Annahmen und Prämissen und sind sehr aufwändig. Für die Managementberatungspraxis sind sie daher kaum zu verwenden. Auch wenn es oft kaum möglich ist, Erträge monetär zu bewerten, so hilft eine schriftliche Gegenüberstellung von Erträgen und Kosten doch bei der Entscheidungsfindung.

Kostenplanung

125

Die Abbildung 55 zeigt die beschriebenen Sichtweisen auf die Kosten eines Beratungsprojektes noch einmal in der Übersicht:

Sichtweise Auftraggeber Fokus: Projektdurchführung

Projektkosten

Gesamtkosten (zur Beurteilung der Sinnhaftigkeit des Projektes) Einzelkosten (zur Bestimmung des Projektbudgets)

Fokus: Implementierung der Projektergebnisse

Sichtweise Managementberatung Kosten der Managementberatung Gesamtkosten (zur langfristigen Kostendeckung) Einzelkosten (Kalkulation Preisstellung)

Implementierungskosten (zur Beurteilung der Sinnhaftigkeit der Umsetzung)

Abbildung 55: Sichtweisen auf Projektkosten und deren Bedeutung für klassische Beratungsprojekte

3.5.2

Entwicklung eines Projektbudgets

Wie bestimmt man die Höhe des Projektbudgets? Es gibt zwei grundsätzliche Möglichkeiten: Die erste Möglichkeit ist, dass das Projektbudget von oben vorgegeben wird („Top-downVorgabe“). Der Auftraggeber gibt aus übergeordneter Sicht vor, wie viel Geld für die Projektaufgabe insgesamt bereitgestellt wird, ohne die einzelnen Aufgaben im Detail kalkuliert zu haben. Beruht diese Vorgabe auf Erfahrungswerten vergleichbarer Projekte, so führt diese Methode durchaus zu angemessenen Ergebnissen. Stehen nur knappe Mittel zur Verfügung, so zwingt die Vorgabe die Managementberatung so zu planen, dass das Ziel möglichst mit diesen Mitteln erreicht wird. D. h., die Rahmenbedingung des begrenzten Personal- und Ressourceneinsatzes kann von Beginn an in der Planung berücksichtigt werden. Zudem kann sich die Obergrenze für ein Budget daraus ergeben, was der Auftraggeber nach erster Schätzung des Nutzens des Projektes insgesamt an Kosten noch für sinnvoll hält.

126

Projektplanung

Die zweite Möglichkeit ist, das Projektbudget von den durchzuführenden Aufgaben her (den Arbeitspaketen) zu entwickeln („Bottom-up-Analyse“). Für jedes einzelne Arbeitspaket, das aus dem Projektstrukturplan abgeleitet wurde, werden die Kosten ermittelt. Die Summe der Kosten aller Arbeitspakete ergibt das benötigte Projektbudget. Diese Methode sollte maßgeblich für die Ermittlung des Projektbudgets sein, da nur sie sicherstellt, dass die geplanten Tätigkeiten mit dem Budget auch tatsächlich durchgeführt werden können. Ein weiteres Argument spricht noch für die Bottom-up-Planung der Projektkosten anhand der Arbeitspakete im Netzplan. Sie erlaubt eine spätere Kontrolle der Einhaltung des Kostenbudgets. Im laufenden Projekt kann dann kontrolliert werden, ob der Fortschritt mit der Abarbeitung der Arbeitspakete der Inanspruchnahme des Budgets entspricht. Eine vorausgehende, pauschale Planung für das gesamte Projekt ist für die Entscheidung, ob das Projekt gestartet werden soll, wichtig, erlaubt jedoch nicht eine Kontrolle und Steuerung im laufenden Projekt. Die detaillierte Aufwandsschätzung durch Auflistung aller Kosten aller Arbeitspakete ist jedoch sehr aufwändig (zweite Methode). Deshalb erfolgt meist zunächst eine grobe Rahmenschätzung. Diese wird mit einer Top-down-Vorgabe der Kosten und den aus den Projektergebnissen generierbaren Nutzen verglichen, um so zu entscheiden, ob das Projekt auf die angedachte Art und Weise überhaupt anzugehen ist. Entscheidet man sich nach diesem Vergleich, auf der vorgedachten Basis weiterzuplanen, so erfolgt die detaillierte Aufwandsschätzung nach der Bottom-up-Analyse. Liegt das detailliert ermittelte Budget noch innerhalb der Vorstellungen des Auftraggebers, so wird es vom ihm genehmigt werden. Bei größeren Summen erfolgt die Genehmigung durch Unternehmensausschüsse, wie etwa einen Investitionsausschuss. Das so genehmigte Projektbudget mit der Aufschlüsselung aller Kosten beruht auf dem Projektplan. Es ist auf die o. g. Kostenarten verteilt und den Projektphasen zugeordnet. Einer anderen Verwendung als im Projektplan vorgesehen darf das Geld ohne erneute Genehmigung nicht zugeführt werden. In Abbildung 56 (S. 127) ist die parallel top-down und bottom-up durchgeführte Budgetaufstellung grafisch dargestellt. Inhaltlich ergibt sich in Managementberatungsprojekten das Gros der Projektkosten meist aus den Kosten für die Berater. Diese Personalkosten des Beratungsunternehmens werden in der Regel auf Basis von Tages- oder Stundensätzen geplant, die in einer Preisliste ausgewiesen werden. Die Kostensätze für die Mitarbeiter des Klientenunternehmens erhält man für die Planung aus der Personalabteilung. Hier wird meist nicht mit den tatsächlichen Gehältern der einzelnen Mitarbeiter, sondern mit Durchschnittswerten gerechnet. Anfallende Sachkosten werden entweder auch über Stundensätze (etwa bei Benutzung eines Großrechners) ermittelt – oder im Fall des Zukaufs von Dienstleistungen oder anderer Fremdkosten (etwa Druckkosten o. Ä.) auf Basis von Kostenvoranschlägen.

Kostenplanung

127

top-down (Auftraggeber)

Abstimmung

Vorgabe eines Rahmens zur Projektskalierung und Absicherung gegen überhöhte Projektkosten Freigegebenes Projektbudget für Projektkostenstelle und Beratung Detailplanung anhand des Netzplans

Grobe Rahmenschätzung anhand vergleichbarer Projekte

bottom-up (Beratung) Abbildung 56: Vorgehen zur Erstellung eines Projektbudgets Müssen auch indirekte Kosten (Gemeinkosten) verrechnet werden (d. h. wenn eine Gesamtkostenplanung erstellt werden soll), so erfolgt dies meist in Form eines prozentualen Gemeinkostenzuschlags, der im Controlling berechnet wird. In der Praxis liegt dieser Zuschlag zwischen 15 % und 50 % der Projekteinzelkosten, kann aber je nach Abgrenzung von direkten und indirekten Kosten stark abweichen. Wie wird nun ein Projektbudget zur Verfügung gestellt? Zunächst sollte hierfür eine Kostenstelle für das Projekt eingerichtet werden (Projektkostenstelle). Dieser Kostenstelle sollte dann das Projektbudget zugewiesen werden, so dass damit die Arbeitspakete bezahlt werden können, d. h., der Betrag kann zur Durchführung der geplanten Arbeitspakete abgerufen werden. Der Gesamtbedarf für die Projektkostenstelle muss auf einzelne Kostenarten aufgeschlüsselt werden. Was ist nun unter einer Kostenstelle zu verstehen? Eine Kostenstelle ist ein Teilbereich eines Unternehmens, für den separat Kosten erfasst werden (Gabler 1995, S. 171). Eine Kostenstelle kann so beispielsweise für eine Abteilung, aber auch ein Projekt oder ein besonderes Vorhaben eingerichtet werden. Im Rahmen der Kostenrechnung eines Unternehmens werden sämtliche Kosten auf Kostenstellen zugeordnet. Ohne eine Kostenstelle kann ein Projekt nicht über eigene Finanzmittel verfügen. Es wäre darauf angewiesen, dass die Leiter anderer Kostenstellen Geld zur Verfügung stellen. In der Praxis gibt es teilweise Widerstände auf Seiten der Auftraggeber gegen die Einrichtung einer Projektkostenstelle. Durch die Kostenstelle wird die Entscheidungsgewalt über das Projektbudget auf den Zuständigen für die Kostenstelle verlagert. Die Macht über die Finanzmittel wird abgegeben. Verantwortlich für die Kostenstelle ist in der Regel daher der fachseitige Projektleiter, d. h. ein Mitarbeiter des Klientenunternehmens. Vorbehalte, einem externen

128

Projektplanung

Projektmanager aus einer Managementberatung Verfügungsgewalt über größere Mittel zu geben, sind aus Kontrollgesichtspunkten verständlich. Aber auch fachseitigen Projektleitern wird oft keine Projektkostenstelle zugestanden, da auch dies die Budgethoheit des Auftraggebers beschneidet. Da es für die erfolgreiche Durchführung des Projektes jedoch vorteilhaft ist, über eigene Projektmittel zu verfügen, sollte die Managementberatung darauf einwirken, dass eine Projektkostenstelle eingerichtet wird. Das Spannungsfeld für/gegen die Einrichtung einer Projektkostenstelle ist in Abbildung 57 nochmals dargestellt:

Auftraggeber Verantwortet das Projekt und

trägt die Kosten Durch das Einrichten einer

Kostenstelle gibt er einen Teil seines Budgets fest für das Projekt ab Dies bedeutet den Verlust von Einfluss Zudem muss er sich über diesen Betrag verbindlich festlegen Die Einrichtung einer neuen Kostenstelle ist administrativ oft aufwändig

Projektleiter Widerstände bei Einrichtung einer Projektkostenstelle vs.

Einrichtung einer Projektkostenstelle vorteilhaft

Verantwortet die

Durchführung des Projektes Kann über eine

Projektkostenstelle dessen Finanzierung sicherstellen Gewinnt die Möglichkeit zu selbständigem und flexiblem Handeln Kann im Innen- und Außenverhältnis souverän auftreten Ständige Freigabe von Budgetposten beim Auftraggeber entfällt

Abbildung 57: Spannungsfeld bei Einrichtung einer Projektkostenstelle Kostenstellen können auch hierarchisch angeordnet sein. So ist es für ein Projekt beispielsweise denkbar, eine Hauptkostenstelle einzurichten, während für Teilprojekte untergeordnete Nebenkostenstellen vorgesehen werden. Auf der Projektkostenstelle müssen die Kosten nach Kostenarten geplant werden, d. h. nach dem Inhalt der geplanten Geldverwendung zugeordnet werden. Übliche Kontenarten in Managementprojekten sind Personalkosten (Gehalt, Prämien), Sachkosten (Reisen, Schulung, Büromaterial, IT-Fremdleistungen, IT-Instandhaltung, Kraftfahrzeuge, Kommunikation, Gebäude). Kapitalkosten werden in der Regel nicht geplant. Bei der Planung der Kostenarten richtet man sich in der Regel nach den Kostenarten, die in der Kostenrechnung des Unternehmens Verwendung finden.

Risikomanagement

3.6

129

Risikomanagement

Jedes Vorhaben ist naturgemäß mit Risiken verbunden, da es erfahrungsgemäß nichts Sicheres auf dieser Welt gibt. Dies gilt besonders bei Projekten, die stets einen hohen Innovationscharakter aufweisen und bei denen viele unterschiedliche Menschen zusammenarbeiten. Vieles kann hier schief gehen. Hinzu kommt, dass Managementberatungen in der Regel an strategisch bedeutsamen Aufgaben arbeiten, bei denen Fehler oder Verzögerungen entsprechend gravierende negative Auswirkungen haben können. Da Managementberatungen die Projekte gegen Bezahlung für andere Unternehmen (Auftraggeber) durchführen, erwarten die Auftraggeber von der Managementberatung eine Leistungserstellung und natürlich auch, dass die Managementberatung den Erfolg dieser Leistungserbringung möglichst sicherstellt. In dieser grundsätzlichen Situation erscheint es daher notwendig, dass die Managementberatung die Risiken, die mit dem Projekt verbunden sind, dem Auftraggeber aufzeigt und auch bereits Maßnahmen ergreift, um die Risiken gering zu halten. Diese Vorgehensweise dient nicht nur dazu, eine bessere Entscheidungsgrundlage über das weitere Vorgehen für den Auftraggeber zu erlangen, sondern sichert die Managementberatung für den Fall ab, dass wirklich einmal etwas misslingt. Dieses „Kümmern“ um die Risiken erfolgt im Rahmen des Risikomanagements. Zunächst einmal sollen hierfür die grundlegenden Begriffe geklärt werden: Ein Risiko ist die Wahrscheinlichkeit des Eintritts eines nicht gewünschten Ereignisses, die mit dem Schaden bewertet wird, der im Eintrittfall zu erwarten ist (Patzak/Rattay 1998, S. 38). D. h., ein Risiko kann in Euro bewertet werden. Das Risikomanagement für Projekte befasst sich mit den Risiken für das Projekt. Risikomanagement für Projekte ist ein Prozess, in dessen Verlauf Risiken für den Projekterfolg aufgezeigt werden, die Auswirkungen auf das Projekt ermittelt und Maßnahmen zur Verhinderung bzw. Verminderung geplant und durchgeführt werden (Portny 2001, S. 338). Risikomanagement in Projekten war ein lange Zeit vernachlässigtes Thema. Erst seit 1998 das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) verabschiedet wurde, reagierten die Unternehmen und haben sich dem Thema stärker als bisher gewidmet (Blazek/Zillmer 2001, S. 178). Dies liegt darin begründet, dass sich die Unternehmen laut Gesetz um eine die Unternehmenszukunft betreffende Risikobewertung kümmern müssen. Da Projekte die Zukunft ja gerade gestalten, müssen sie auch die Unwägbarkeiten hierbei berücksichtigen. Managementberatungen sind also angehalten, die Risiken, die mit ihren Vorschlägen verbunden sind, zu finden und zu bewerten. Gerade zu Beginn des Projektes ist ein Risikomanagement wichtig, um die im Verlauf auftretenden Risiken von Anfang an beurteilen und ggf. rechtzeitig Vorsorge treffen zu können. Der Umgang mit diesen Risiken muss geplant werden, und die Risiken sollten auch im Pro-

130

Projektplanung

jektangebot der Managementberatung enthalten sein (siehe Abschnitt 2.4.1). Daher sollte für jedes Managementberatungsprojekt ein Risikomanagement erfolgen. Die grundlegenden Schritte des Risikomanagements sind sehr einfach, es wird versucht, diese im Folgenden zu erklären (Blazek/Zillmer 2001, S. 281; Heche 2004, S. 109-115). Sie bestehen aus: Risikofindung Risikobewertung Risikobeherrschung Zunächst müssen die Risiken identifiziert werden, sonst kann ein Risikomanagement nicht greifen. Bei der Risikofindung geht es darum, vorhandene Risiken aufzuspüren und zu erkennen. Hierbei kann zwischen den Risiken selbst und Risikofaktoren unterschieden werden. Risikofaktoren sind Umstände, die den Eintritt des nicht gewünschten Ereignisses wahrscheinlicher machen. Risikofaktoren stellen noch nicht das Risiko dar – sie erhöhen das Risiko aber und sollten daher bekannt sein (Portny 2001, S. 281). So kann es beispielsweise ein Risikofaktor sein, wenn es nur eine Person im Projektteam gibt, die eine bestimmte Tätigkeit, die auf dem kritischen Pfad liegt, durchführen kann. Dies kommt beispielsweise bei ITProjekten oder -Arbeitspaketen häufiger vor, wenn nur bestimmte Personen die speziell benötigten Kenntnisse eines Systems haben. Dieser personelle Engpass (Risikofaktor) erhöht die Wahrscheinlichkeit des Eintritts des Risikos der Verzögerung der Projektdurchführung durch Ausfall der Person, sei es durch Krankheit oder einfach dadurch, dass diese Person von der Projektaufgabe abgezogen wird. Zur Risikofindung sollte das Projektteam (d. h. Vertreter der Beratung inkl. Projektmanager und auch Mitarbeiter des Unternehmens unter Einbeziehung des Auftraggebers) mögliche Risikofaktoren für das Projekt ermitteln. Für diese wird dann beschrieben, welche Auswirkung der Eintritt der Risiken auf das Projekt haben könnte. Hierbei sollten konkrete und relevante Risiken für das Projekt beschrieben werden, nicht allgemeine, die für sämtliche Bereiche des Unternehmens gelten. Sollten Managementberatung und Unternehmen noch keine oder nur begrenzte Erfahrung mit einem Projektthema haben, so ist es bei großen Projekten ratsam, Experten zur Identifizierung von Projektrisiken hinzuzuziehen. Eine mögliche und geeignete Vorgehensweise zur Ermittlung von Projektrisiken sind Workshops. Um den Aufwand zu reduzieren, kann die Risikofindung in einen Planungsworkshop integriert werden, so dass kein gesonderter Termin hierfür angesetzt werden muss. Um sich in einer Diskussion über Projektrisiken nicht zu verzetteln, sollte strukturiert vorgegangen werden. Folgt man einer klaren Struktur, so kann dies auch die Vollständigkeit der Ergebnisse sicherstellen, die sonst nicht unbedingt gewährleistet ist. Für einen Risikomanagementworkshop ist wiederum die Metaplantechnik sehr gut einsetzbar. Die Moderation des Workshops sollte durch den Projektmanager des Beratungsunternehmens erfolgen. Dieser sollte als Projektmanager die persönlichen Fähigkeiten zur Moderation besitzen und muss als Projektleiter einen Gesamtüberblick über das Projekt haben.

Risikomanagement

131

Zur Strukturierung bietet es sich an, nach mehreren logischen Ebenen vorzugehen, die nacheinander durchgegangen werden. Die folgende Struktur, die die Aspekte der Projektplanung aufgreift (vgl. Heche 2004, S. 110), kann hierzu hilfreich sein: Projektphasen: Welche Risikofaktoren und Risiken treten in welchen Projektphasen auf? Stakeholder: Mit welcher Person oder Gruppe sind welche Projektrisikofaktoren und Risiken verbunden (vgl. hierzu Abschnitt 4.4)? Wer kann negativen Einfluss auf Projektablauf oder Zielerreichung nehmen? Was passiert, wenn einer der Fürsprecher des Projektes ausfällt? Endergebnis: Was gefährdet die Qualität des Endergebnisses des Projektes bzw. dessen Umsetzung? Zeitplan: Welche Risikofaktoren beeinflussen die termingerechte Erreichung des Endergebnisses, welche Faktoren erhöhen die Wahrscheinlichkeit einer Verzögerung? Ressourceneinsatz: Welche Risikofaktoren nehmen Einfluss darauf, dass die geplanten Ressourcen (in puncto Zeit, Budget, Material, Personalqualifikation, Personaleinsatz etc.) auch tatsächlich zur Verfügung stehen werden? Besonders wichtig ist hier natürlich die Verfügbarkeit des Personals, da dies erfahrungsgemäß ein Engpass ist. Erfahrungen: Dies sind die Erkenntnisse aus bereits durchgeführten Projekten. D. h., welche Projektrisikofaktoren wurden bei Projekten in der Vergangenheit identifiziert, welche Projektrisiken sind eingetreten? Die Suche nach Projektrisiken und Risikofaktoren anhand dieser Struktur ist natürlich nicht überschneidungsfrei, hilft aber, kein Risiko zu vergessen. Zusätzlich zu dieser Vorgehensweise können Projektrisikofaktor-Listen aus der Fachliteratur entnommen werden. Diese bringen vielleicht noch weitere Ideen hervor, ersetzen jedoch keinesfalls eigene Überlegungen, da sie nicht situationsspezifisch sein können. Deshalb sind sie eher kritisch zu betrachten. An dieser Stelle wird deshalb auch auf ihre Wiedergabe verzichtet. Ein Beispiel liefert etwa Portny (2001, S. 282 ff.). Die Risikobewertung baut auf der Risikofindung auf. Hierbei werden die gefundenen Risiken qualitativ und quantitativ bewertet (Blazek/Zillmer 2001, S. 180). Die Bewertung dient dazu, die Auswirkungen des Risikoeintritts abzuschätzen und für die verschiedenen Risiken vergleichbar zu machen. Dies kann anhand einer Risiko-Matrix mit Gefahrenzonen erfolgen. Eine solche Matrix sollte im Anschluss an die Risikofindung im selben Workshop erstellt werden. Sie bietet den Vorteil, leicht verständlich und damit gut kommunizierbar zu sein. Abbildung 58 zeigt eine solche Risiko-Matrix:

132

Projektplanung

I-IV = Risikoklassen

100

I

höchste Priorität

75

Eintrittswahrscheinlichkeit in %

II 50

III 25

IV 0 unwichtig

mittel

katastrophal

Quelle: Blazek/Zillmer 2001, S. 181; allgemein siehe auch Stauss/Seidel 1998, S. 220 oder Heche 2004, S. 112 ff., der allerdings andere Quadranten unterscheidet Abbildung 58: Risiko-Matrix mit Risikoklassen Zu jedem Risiko wird anhand der Risikofaktoren überlegt, wie wahrscheinlich der Eintritt ist. Dies geschieht auf einer Skala, die die Eintrittswahrscheinlichkeiten in Prozent angibt. Diese Wahrscheinlichkeit wird im Rahmen des Workshops von den Teilnehmern geschätzt. Wenn man sich diesbezüglich sehr unsicher ist, können noch Experten für die einzelnen Risiken im Unternehmen oder der Beratung befragt werden. Ebenso wird bestimmt, wie weit reichend die Auswirkungen des Risikoeintritts auf das Projekt wären. Hier bietet sich eine Skala an, die zunächst einmal nur ordinal ist, z. B. unwichtig – mittel – katastrophal. Folgewirkungen des Risikoeintritts müssen selbstverständlich mit berücksichtigt werden. Hier hilft der Projektplan, beispielsweise, wenn es um Verzögerungen geht. Eine Bewertung der Risiken mit einem Geldbetrag ist für viele Risiken im Bereich der Managementberatung schwierig, und daher ließen sich auf einer solchen Achse nicht alle Risiken bewerten und damit vergleichen. Deshalb wird die hier aufgeführte ordinale Skala vorgeschlagen. Wenn die Risiken durch diese Methode bewertet sind, werden sie in Risikoklassen eingeteilt. Risiken mit katastrophalen Auswirkungen und hoher Eintrittswahrscheinlichkeit haben die höchste Risikoklasse, Risiken mit geringen Auswirkungen und geringer Eintrittswahrscheinlichkeit die geringste Risikoklasse. In der Abbildung 58 sind die Risikoklassen mit den Nummer I bis IV gekennzeichnet. I ist die höchste Risikoklasse, deren Risiken die höchste Aufmerksamkeit bekommen sollten, VI die niedrigste Risikoklasse mit entsprechend geringster Priorität im weiteren Risikomanagement.

Risikomanagement

133

Alternativ zu dieser Einteilung in Klassen kann auch der so genannte Risikowert berechnet werden. Dieser ergibt sich aus einer Multiplikation der Skalenwerte für Wahrscheinlichkeit des Risikoeintritts und der Auswirkung. Hierzu muss man der Auswirkung des Risikoeintritts auch einen Skalenwert zuweisen, etwa den Wert 1 für geringe Auswirkung, 2 für mittlere und 3 für katastrophale. Diese Risikowerte kann man nun vergleichen und in eine Rangfolge bringen. Diese Vorgehensweise ist jedoch nur bedingt zu empfehlen, da sie eine Scheingenauigkeit erzeugt, die bei weiterer Betrachtung und Kommunikation hinderlich sein kann. Die Ergebnisse sind zwar als Zahlenwerte gut vergleichbar, hängen aber dennoch von der subjektiven Einschätzung der Bewertenden ab. Auch beeinflusst die Wahl der jeweiligen Skala schon maßgeblich das Ergebnis. Dies ist jedoch, anders als in der graphischen Darstellung, dem berechneten Risikowert nicht mehr anzusehen. Die Empfehlung ist daher das Aufstellen einer Risiko-Matrix. Für die identifizierten und priorisierten (hohen) Risiken folgt nun die Aufgabe der Risikobeherrschung. Diese umfasst folgende Aspekte: Risikovorsorge Risikovermeidung Die Risikovorsorge ist die Vorsorge für den Zeitpunkt, wenn ein Risiko eingetreten ist. Es ist Aufgabe des Projektteams, schon vor Eintritt eines Risiko-Ereignisses zu überlegen, wie darauf reagiert werden kann. Es handelt sich also um eine Art Notfallplan, d. h. um eine korrektive Maßnahme. Ein möglicher Notfallplan für den Risikofaktor „Ausfall des ITExperten“ wäre es, für diesen Fall eine externe Softwarefirma mit der notwendigen Aufgabe zu betreuen oder einen anderen Mitarbeiter dann soweit zu schulen, dass er die Aufgabe wahrnehmen kann. Ein anderes Element der Risikovorsorge ist die Einstellung eines Vorsorgebetrags, um die monetären Konsequenzen des Risikos abzufangen. Dies könnte im oben aufgeführten Beispiel etwa die Summe sein, die die externe Softwarefirma für die Durchführung der Arbeiten verlangt. Der Vorsorgebetrag ergibt sich aus der Multiplikation der Eintrittswahrscheinlichkeit eines Risikos mit den geschätzten Kosten bei Eintritt (Blazek/Zillmer 2001, S. 182):

Vorsorgebetrag

Eintrittswahrscheinlichkeit u geschätzte Kosten bei Eintritt

Im Rahme der Risikobeherrschung sollte dieser Vorsorgebetrag zumindest für die Risikoklasse 1 als eine Art Versicherung oder Reserve in das Projektbudget eingestellt sein. Bei tatsächlichem Eintritt des Risikos wird der für ein Risiko bereitgestellte Vorsorgebetrag dann allerdings nicht ausreichen, um die entstandenen Kosten zu decken. Dies liegt daran, dass der Vorsorgebetrag mit der Eintrittswahrscheinlichkeit gewichtet wurde. Wurde jedoch für mehrere Risiken jeweils ein Vorsorgebetrag zurückgestellt, so kann – ähnlich wie bei einer Versicherung – das tatsächlich eingetretene Risiko aus sämtlichen Vorsorgebeträgen bedient wer-

134

Projektplanung

den. Problematisch wird dies erst, wenn so viele Risiken tatsächlich eintreten, dass der Vorsorgebetrag nicht ausreicht. Möchte man ganz auf Nummer sicher gehen, so ist nicht ein Vorsorgebetrag zurückzustellen, sondern der gesamte Risikobetrag, d. h. die Summe, die notwendig ist, wenn das Risiko eintritt und dieses gesamt abdeckt. Da dies in der Regel aufgrund finanzieller Beschränkungen für alle Risiken nicht möglich oder sinnvoll ist, wird oft nur der Vorsorgebetrag zurückgestellt. Durch den entsprechenden Ausweis dieser Mittel für den Risikofall ist sicherzustellen, dass dieses Risikobudget nicht schon im Rahmen der normalen Projekttätigkeit ausgegeben wird. Die Risikovermeidung beschreibt zum einen das Management der Risikofaktoren, um die Wahrscheinlichkeit des Risikoeintritts zu reduzieren. Zum anderen können es Maßnahmen sein, die die Auswirkung bei Risikoeintritt mindern. Dies ähnelt dann schon der Risikovorsorge, mit dem Unterschied, dass die Vorsorge reaktiv bei Risikoeintritt ist, die Vermeidung aber schon im Vorfeld die Auswirkungen im Falle eines Risikoeintritts reduziert. Risikovermeidung ist also präventiv und sollte für alle Risiken geschehen, mit Priorität auf den Risiken mit hoher Risikoklasse. Hierbei sind Wirtschaftlichkeitsbetrachtungen zu berücksichtigen. In unserem Beispiel des IT-Mitarbeiters, der nicht ersetzbar ist, wäre eine Maßnahme der Risikovermeidung das Einstellen einer weiteren Person mit den notwendigen Kenntnissen in seinem Bereich oder die präventive Ausbildung einer weiteren Person. Dies reduziert den Risikofaktor der mangelnden Ressourcen im Krankheitsfalle oder bei nicht erfolgter Freistellung einer Person für das Projekt. Die Wahrscheinlichkeit, dass es zu einer Unterbesetzung kommt, wird gesenkt. Weiterhin kann die Auswirkung einer Unterbesetzung schon im Vorfeld reduziert werden, indem man in den Projektplänen für die kritischen Arbeiten schon einen zeitlichen Puffer vorsieht. Selbst wenn es jetzt aufgrund des Ausfalls des IT-Mitarbeiters zu Verzögerungen kommt, wirkt sich dies nicht sofort auf das Gesamtprojekt aus, solange der zeitliche Puffer nicht aufgebraucht ist. Im Rahmen eines Risikomanagements ist auch zu entscheiden, ob das Risiko überhaupt eingegangen werden muss oder ob es eine gangbare Option gibt, die Aufgaben so zu verändern, dass das Risiko wegfällt. Wenn die Risikobeherrschung letztendlich nicht möglich ist, muss eventuell sogar entschieden werden, ob das Projekt überhaupt weiterverfolgt werden soll. Dies ist sicherlich die extremste Form der Risikovermeidung. Projektrisiken sollten – wie bereits gesagt – auf jeden Fall in einem Projektangebot erläutert werden, und im Rahmen des Risikomanagements sollten in der Planungsphase Maßnahmen zur Risikovorsorge und -vermeidung ergriffen werden. Dies reicht aber natürlich nicht aus. Das Risikomanagement muss während des gesamten Projekts die Risiken im Auge behalten, neue Risiken aufspüren und bewerten. Hierzu müssen die Risiken laufend kommuniziert werden. Zudem benötigt man einen Risikomanager, der sich mit der Nachverfolgung (dem Tracking) der Risiken befasst. In kleineren Projekten wird sich der Projektleiter um die Aufgaben des Risikomanagements kümmern, in größeren kann diese Aufgabe dem Projektbüro übertragen werden (siehe zum Projektbüro Abschnitt 4.1), in sehr großen wird eine eigene Person mit dem Risikomanagement beauftragt.

Risikomanagement

135

Ein einfaches Instrument zur Unterstützung der Durchführung des Risikomanagements ist ein Risikomanagement-Plan. Dieser kann z. B. tabellarisch dargestellt werden, wie in der folgenden Praxisbox zu sehen ist:

Praxisbox 14: Risikomanagement-Plan Das Risikomanagement im Inhouse Consulting erfolgt grundsätzlich nach dem gleichen Prinzip, wie auch oben im Text erläutert. Nach der Risikofindung durch Expertenworkshops erfolgt eine Risikobewertung mit einer Risiko-Matrix: Risiken mit geringer Wahrscheinlichkeit und geringer Auswirkung werden lediglich beobachtet. Für Risiken, die relativ wahrscheinlich sind, deren Auswirkungen aber eher gering sind, werden präventive Maßnahmen entwickelt, Für unwahrscheinliche Risiken mit großer Auswirkung werden Notfallpläne erstellt. Für wahrscheinliche Risiken mit großer Auswirkung werden Maßnahmen geplant, um diese Risiken aktiv zu bearbeiten und zu entschärfen. Diese Maßnahmen für die letzte Form der Risiken werden in einem RisikomanagementPlan festgehalten. Dieser folgt in der Struktur dem Grundprinzip des Risikomanagements (Risikofindung, Risikobewertung, Maßnahmenplanung) und führt die Risiken und die geplanten Maßnahmen auf. Wichtig bei den Maßnahmen ist, dass festgelegt wird, ob es einen Auslöser für den Einsatz der Maßnahmen gibt (Trigger), was Inhalt der Maßnahme ist (Action), bis wann diese Maßnahme erfolgen soll und wer verantwortlich ist. Durch die Festlegung von Zeiten und Verantwortlichkeiten wird vermieden, dass die Maßnahmen für die Beobachtung der Risikoanzeichen sowie der Risikobekämpfung vergessen werden können.

136

Projektplanung

Risk identification

Risk analysis

Risk response planning

Impact (high/low)

Trigger (high/low)

Action

Due date

Responsible

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

Risk

Impact on

…

…

…

Probability

Quelle: Inhouse Consulting Deutsche Post World Net, vergleiche auch Wolf/Mlekusch 1997, S. 290 Abbildung 59: Risikomanagement-Plan zur Risikobeherrschung

Die bisherige Sichtweise auf Risiken war die aus Sicht des Projektes, d. h., die Betrachtung bezog sich bisher darauf, welche Risiken für den Projekterfolg und die -durchführung bestehen – d. h., es sind Risiken, die den Auftraggeber als denjenigen, der am Projekt maßgebliches Interesse hat, interessieren. In der Managementberatung gibt es aber noch eine zusätzliche Sichtweise auf die Risiken, nämlich die aus Sicht des Beratungsunternehmens. Hierbei führt die Managementberatung eine interne Bewertung durch, welche Risiken es für sie gibt. Dies kann dann Punkte betreffen, die für das Projekt nicht sehr wichtig sind, jedoch für das Beratungsunternehmen. Beispiele wären der unkontrollierte Abfluss von Wissen, Abwerbung von Beratern aus dem Projekt, Nichtzahlung der vereinbarten Summe, Gefährdung der Reputation der Beratung bei Misserfolg etc. Die Bewertung dieser Risiken muss vor Abgabe eines Angebots intern in der Managementberatung erfolgen. Und zur Kontrolle der Risiken muss auch hier ein Risikomanagement erfolgen. Vorsorgebeträge können dann beispielsweise in Form von Preisaufschlägen gebildet werden und Maßnahmen zur Risikoreduktion (wie Abwerbeverbote) können ergriffen werden. Das Management dieser Managementberatungsrisiken ist Aufgabe der für ein Projekt zuständigen Projektmanager, aber auch der Partner der Managementberatung.

Aufbauorganisation im Projekt

137

4 Projektorganisation

4.1


Motivierte Menschen tragen den Erfolg eines Projektes. Motivation und eine gute Zusammenarbeit erfordern jedoch Rahmenbedingungen, damit sie sich entsprechend entwickeln können. Solche Rahmenbedingungen werden in Unternehmen über die Organisationsstruktur geschaffen. Diese weist Aufgaben und Verantwortlichkeiten zu. Die „normale“ Organisationsstruktur eines Unternehmens, wie sie dem Organigramm entnommen werden kann, ist speziell auf die Wahrnehmung der Regelaufgaben im Unternehmen hin ausgelegt (Litke 1995, S. 69). Dafür gibt es Aufgabenbeschreibungen und ein hierarchisches System, das festlegt, welcher Vorgesetzte einem Mitarbeiter fachliche Anweisungen geben kann und wer disziplinarischer Vorgesetzter ist. Disziplinarische Vorgesetzte sind für die Gehaltshöhe, Beförderungen, Urlaub, Entlassung etc. zuständig. Die fachliche und disziplinarische Verantwortung müssen nicht unbedingt in einer gemeinsamen vorgesetzten Stelle gebündelt sein. Oft ist es so, dass es zwei oder mehrere fachliche Vorgesetzte gibt, aber nur ein Vorgesetzter disziplinarisch zuständig ist. Dies ist beispielsweise denkbar, wenn ein Mitarbeiter Aufgaben übernimmt, die in die Zuständigkeit mehrerer Abteilungen fallen. Er hat je nach Aufgabe also andere Fachvorgesetzte, der Eindeutigkeit halber jedoch nur einen Disziplinarvorgesetzten. Projekte sind jedoch – wie zu Beginn dieses Buches festgestellt – besondere und einmalige Aufgaben. Entsprechend ist die normale Unternehmensorganisation nicht für die Wahrnehmung von Projektaufgaben ausgelegt, sondern beschränkt sich auf die Regelaufgaben. Zur Projektdurchführung wird daher in der Regel eine eigene Organisationsstruktur geschaffen, die dann Projektorganisation heißt. Eine der wichtigsten Rahmenbedingungen für hohe Motivation und gute Zusammenarbeit in einem Projekt ist eine klare und geeignete Projektorganisation. Die Projektorganisation weist die (neuen) Projektaufgaben einzelnen Personen zu und bestimmt Verantwortlichkeiten. Sie schafft hierdurch klare Schnittstellen der Zusammenarbeit und vermeidet Reibungsverluste, die bei unklaren Kompetenzverteilungen entstehen würden. Eine klare Projektorganisation erlaubt so letztendlich, dass Menschen sich für ihre Aufgaben im Projekt verantwortlich fühlen. Bei dieser Aufgabenzuweisung im Projekt wird zum Teil auch von interner Projektor-

138

Projektorganisation

ganisation gesprochen (Lehner 2001a, S. 51), die sich von der aus Sicht des Projektes „externen“ Organisation des Unternehmens abgrenzt. Im Falle der Projektbearbeitung durch eine Managementberatung besitzen wir insgesamt drei relevante Organisationsstrukturen, die meist parallel nebeneinander bestehen und deren Schnittstellen geregelt werden müssen. Dies sind die Projektorganisation, die Unternehmensorganisation des beratenen Unternehmens und die Unternehmensorganisation der Managementberatung.

Der Zusammenhang zwischen den drei Organisationen mit den erwähnten Schnittstellen ist in Abbildung 60 dargestellt. Auch sind die unterschiedlichen Zielsetzungen, an denen sich die Organisationsstrukturen ausrichten, in der Abbildung aufgeführt. Die Organisationsstruktur innerhalb der Managementberatung (rechts im Bild zu sehen) ist darauf abgestimmt, die Einsatzfähigkeit der Managementberater für die Projektarbeit sicherzustellen. Zusätzlich gibt es natürlich noch Anforderungen des Funktionierens der internen Zusammenarbeit in der Beratung, die in puncto Projektmanagement jedoch nur eine untergeordnete Rolle spielen. Das Ziel bei der Gestaltung der Organisationsstruktur beim beratenen Klientenunternehmen (links in der Abbildung) ist der reibungslose und effiziente Ablauf der normalen Geschäftstätigkeit. Dies ist insofern von Bedeutung, weil sich ein Projekt im Unternehmen diesem in der Regel unterzuordnen hat bzw. hierauf Bezug nimmt.

Unternehmensorganisation

Organisation der Managementberatung

Projektorganisation Personalübergang

Personalübergang Schnittstelle

Ziel: reibungslosen und effizienten Ablauf der Regeltätigkeiten normaler Geschäftstätigkeit sicherstellen

Schnittstelle

Ziel: reibungslosen und effizienten Ablauf der Projektarbeit sicherstellen

Ziel: Leistungsfähigkeit und Einsatzbereitschaft der Managementberatung sicherstellen

Abbildung 60: Zusammenhang von Unternehmens-, Projekt- und Managementberatungsorganisation


139

Je nach Organisation des Projektes kommt es zwischen den Organisationen auch zu Personalabtretungen. Zwischen Unternehmens- und Projektorganisation können diese temporär, d. h. auf einen bestimmten Zeitraum bezogen, sein und/oder auf Teilzeitbasis, was eine parallele Einbindung der Mitarbeiter in Projekt- und Unternehmensorganisation bedeutet. In Bezug auf die Organisationsstruktur der Managementberatung ist es dann natürlich so, dass die Mitarbeiter temporär in den Projekten im Klientenunternehmen arbeiten. In der Regel sind sie dabei in Vollzeit eingesetzt, in selteneren Fällen kann es auch Teilzeit sein. Dies wäre beispielsweise der Fall, wenn ein Projektmanager Projekte in verschiedenen Unternehmen parallel leitet. Auf diese Art der Einbindung der Projektorganisation in die Unternehmensorganisation wird in Abschnitt 4.3 noch näher eingegangen. Wir werden uns in diesem Buch insbesondere auf die Projektorganisation und kurz auf die Organisation in der Managementberatung beziehen. Für Fragen der Unternehmensorganisation sei auf die zahlreiche hierzu vorhandene Literatur verwiesen (etwa Olfert/Steinbruch 2003 oder Schreyögg 2003). Die Projektorganisation wird zielgerichtet gestaltet, um Rahmenbedingungen und Strukturen zu schaffen, die die Durchführung des Projektes möglichst gut unterstützen. Hierbei sind einige Aspekte zu beachten, die dies fördern. Es wird eine Struktur geschaffen, die die geeignete Arbeitsteilung und zielgerichtete Zusammenarbeit der mit dem Projekt befassten Personen, den reibungslosen Ablauf der Projektarbeit, die Integration des Projektes in das Gesamtunternehmen, die Einbindung der Managementberatung in das Projekt und die Motivation des Einzelnen und des Teams

ermöglicht bzw. sicherstellt (vgl. auch Litke 1995, S. 69, mit Ergänzungen). Ein Grundprinzip jeder Organisation – und auch fast jeder Projektorganisation – ist, dass Zuständigkeiten, Verantwortungen und Kompetenzen klar und verbindlich festgelegt werden. D. h., es wird geregelt, wer was macht (Zuständigkeiten), wer für die Umsetzung verantwortlich ist und diese entsprechend überwacht und plant und wer die letztendliche Entscheidungskompetenz besitzt. Hier wird also für fachliche Fragen verbindlich festgelegt, wer welche Aufgaben, Pflichten und Rechte hat. Verbindliche Festlegung bedeutet, dass diese Festlegung für jeden ersichtlich ist und man sich auf ihre Umsetzung verlassen kann, wobei ein Grundmaß an Flexibilität (etwa die Möglichkeit der Anpassung der Projektorganisation an geänderte Rahmenbedingungen) immer gegeben sein sollte. Flexibilität bedeutet hier aber nur, dass per zentraler Vorgabe eine offizielle Änderung der Projektorganisation möglich sein sollte. Bei aller Verbindlichkeit der Regelungen ist eine Überorganisation zu vermeiden, die die Projektteilnehmer stärker einschränkt, als dies sinnvoll ist, und so aktives Handeln verhindert.

140

Projektorganisation

Eine Möglichkeit, diese aufgabenbezogenen Zuständigkeiten zu regeln, ist der so genannte IBZED-Code, wie er auch bei der Deutschen Post angewendet wird, der in Praxisbox 15 dargestellt ist.

Praxisbox 15: Der IBZED-Code zur Aufgabenbeschreibung in Organisationen Das IBZED-Schema erlaubt es sehr präzise, für einzelne Aufgaben zu bestimmen, wer was „machen“ darf. Eine solche Festlegung erfolgt in der Regel für erfolgskritische Tätigkeiten oder Aufgabenstellungen. Eine solche oder vergleichbare Definition der Aufgaben erfolgt beispielsweise auch im Rahmen einer Zertifizierung, wenn genau dokumentiert wird, wer in einem Prozess welche Aufgabe hat. Im Rahmen des Projektmanagements kann das IBZED-Schema auch für die Beschreibung der Projektaufgaben Anwendung finden. Der Aufwand, ein solches Schema für die „normalen“ Projektaufgaben zu erstellen, wäre sehr hoch, daher beschränkt man sich bei der Regelung mit IBZED auf wichtige Aufgaben wie etwa die Meilensteinfreigabe, Budgetfragen oder andere Entscheidungen mit großer Tragweite. IBZED steht hierbei für die ersten Buchstaben der Regelungsbereiche:

I B Z E D

Informationsrecht Beratungsrecht Zustimmungspflicht Entscheidungsrecht Durchführungspflicht

Abbildung 61: IBZED-Schema zur Regelung von Aufgaben in der Organisation Das Informationsrecht ist das Recht, über Entscheidungen, die zu einer bestimmten Aufgabe oder für einen bestimmten Bereich getroffen wurden, informiert zu werden. So kann beispielsweise festgelegt werden, dass die IT-Abteilung über Entscheidungen zu IT-Systemen im Projekt informiert wird. Das Beratungsrecht legt fest, dass man das Recht hat (und meist ist es so geregelt, dass man auch die Pflicht dazu hat), zu einem bestimmten Aufgabengebiet zu beraten, bevor die Entscheidung getroffen wird. So könnte man festlegen, dass die IT-Abteilung in einem Untenehmen das Recht hat, vor einer IT-Systementscheidung in einem Projekt hierzu zu beraten.


141

Das Zustimmungsrecht ist ein Vetorecht. D. h., eine Entscheidung zu einem bestimmten Bereich bedarf der Zustimmung der Person mit dem Zustimmungsrecht, damit sie gültig ist. So könnte festgelegt werden, dass die IT-Systementscheidung im Rahmen eines Projektes der Zustimmung der IT-Abteilung des Unternehmens bedarf. Verweigert die Abteilung die Zustimmung, dann kann die Systementscheidung entsprechend im Projekt so nicht getroffen werden. Das Entscheidungsrecht legt fest, wer eine Entscheidung überhaupt treffen darf. Ein Zustimmungsrecht ist hiervon unbenommen und gilt natürlich einschränkend für das Entscheidungsrecht. So kann etwa festgelegt werden, dass der Projektmanager eines Projektes IT-Entscheidungen bis zu einer Summe von 10.000 Euro selbst treffen darf. Die Durchführungspflicht (und diese beinhaltet natürlich das Durchführungsrecht) legt fest, wer eine bestimmte Aufgabe ausführen muss. So kann zum Beispiel festgelegt werden, dass der Projektmanager (bzw. der Stab) eine IT-Bestellung selbst abwickeln muss und diese nicht durch die IT-Abteilung erfolgt. Es ergibt sich also ein bestimmter Ablauf bei Entscheidungen, wie er in Abbildung 62 dargestellt ist:

Zustimmung

Beratung

Entscheidung

Information

Durchführung

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 62: IBZED-Schema zur Regelung von Aufgaben in der Organisation Die Definition der oben beschriebenen Rechte erlaubt es, für eine Entscheidung und Durchführung einer Aufgabe klare Festlegungen zu treffen, so dass es keine Streitigkeiten

142

Projektorganisation

geben dürfte. Die Darstellung erfolgt oft in einer Tabelle, bei der auf der X-Achse die zuständigen Stellen und auf der Y-Achse die Aufgaben abgetragen sind. In der Tabelle selbst ist dann mit der entsprechenden Abkürzung (I, B, Z, E oder D) vermerkt, welches Recht die Stelle hat. Abbildung 63 zeigt hierfür ein vereinfachtes Beispiel.

Landesgesellschaft Headquarter USA, UK, AsPac Central Europe Accounting

Controlling

Markkommunikation

Produktmanagement

IT-Strategie

Operations

Europäische Vertriebsgesellschaften Operative Auslandgesellschaften

E, D

D

B

E, D

D

I

Standards

E, D

(E), (D)

Standards

E,D, B

E, D

Umsetzung

B, E, D

E, D

Datenaggregation

I

I

International

E, D

Lokal

E, D E, D

I, B

Umsetzung

B, Z, (D)

E, D

Standards

E

I, D

B, Z

E, D

Definition

Operatives Geschäft

In Anlehnung an Deutsche Post World Net. Abbildung 63: Beispiel für eine einfache IBZED-Tabelle

Eine Ausnahme, bei der die oben auf Seite 139 beschriebenen organisatorischen Festlegungen keine Anwendung finden, sind extrem kreative und damit fluide Strukturen. Bei diesen sind Weisungsrechte nicht dauerhaft und ändern sich laufend aus sich heraus. Solche Strukturen können für spezielle Projektaufgaben etabliert werden, die ein Höchstmaß an Kreativität und flexiblem Teamwork erfordern. Als Beispiel seien Entwicklungsprojekte im kreativen Bereich (etwa Werbeagenturen oder Modegestaltung) genannt. In der so genannten New Economy (meist Internetfirmen) haben sich fluide Strukturen aber meist als nicht dauerhaft tragfähig erwiesen. Für die Managementberatung ist aufgrund der Notwendigkeit der Einbindung des Projektteams in das beratene Unternehmen und der Bedeutung der Aufgaben von solchen offenen Strukturen abzuraten. Die Gefahr, dass die Ergebnisse nicht erreicht werden, ist durch die fehlende Steuerung zu groß. Die Struktur einer Projektorganisation in der Managementberatung kann grundsätzlich je nach Projektaufgabe frei gewählt werden. Es haben sich jedoch bestimmte Gremien und


143

Aufgabenträger herauskristallisiert, die sehr häufig anzutreffen sind. Sie haben sich in der Praxis von Managementberatungen bewährt und sorgen für Verbindlichkeit innerhalb des Projektes sowie eine gute Anbindung des Projektes an das Unternehmen. Dies sind (vgl. Litke 1995, S. 71 ff. oder Maylor 1999, S. 146 ff.): Lenkungsausschuss Steuerkreis Kernteam (Projektgruppen) mit Projektleiter Programmoffice bzw. Projektoffice

Alle Gremien sind temporär und projektbegleitend. Mit Projektende werden sie wieder aufgelöst. Abbildung 64 zeigt ein Beispiel für eine Projektorganisation im Zusammenspiel der genannten Gremien:

z. B. monatlich

z. B. wöchentlich oder vierzehntäglich

Lenkungsausschuss LA

zuständige Vorstände oder Bereichsleiter

Steuerkreis

zuständige Abteilungsleiter

Projektleiter

Projekt-/ Programmoffice

Teilprojekt 1

Teilprojekt 2

Teilprojekt 3

Experten

Experten

Projektteam laufend bzw. wöchentlich

Experten

Abbildung 64: Beispiel für eine Projektorganisation

Diese Gremien der Projektorganisation werden im Folgenden erläutert.

4.1.1

Lenkungsausschuss

Der Lenkungsausschuss ist das Gremium, welches das Projekt initiiert und in Auftrag gibt. In der Regel ist es mit Managern der ersten oder in Großunternehmen auch der zweiten Führungsebene besetzt. Neben dem Auftraggeber besteht es aus den Führungskräften, deren

144

Projektorganisation

Bereiche unmittelbar oder mittelbar durch das Projekt betroffen sind, d. h. in deren Bereiche sich Änderungen ergeben. Gibt es im Unternehmen weitere Gremien, durch die das Projektergebnis abgesegnet werden muss (etwa Investitionsausschuss, EDV-Ausschuss (IT-Board) oder andere Fachausschüsse), dann ist es sinnvoll, die wesentlichen Entscheider dieser Gremien in den Lenkungsausschuss zu integrieren. Sinnvoll ist in jedem Fall die Integration der Führungskräfte in den Lenkungsausschuss, aus deren Bereichen Mitarbeiter wesentlich an der Projektarbeit beteiligt oder betroffen sind. Diese Mitarbeiter müssen durch ihren Linienvorgesetzten (hier dann Mitglied des Lenkungsausschusses) von der Regeltätigkeit für das Projekt freigestellt werden oder ihre Projektunterstützung muss wenn notwendig anders sichergestellt werden. Dies fällt natürlich umso einfacher, je besser die Führungskraft in das Projekt integriert ist. Die Aufgaben des Lenkungsausschusses sind grundlegender Natur für das Projekt. Zu nennen sind (vgl. Litke 1995, S. 71, Kerber-Kunow 2000, S. 44): Offizieller Projektstart: Nur der Lenkungsausschuss kann ein abteilungsübergreifendes Projekt offiziell starten. Solche übergreifenden Projekte bedürfen der Zustimmung der jeweiligen in der Unternehmensorganisation verantwortlichen Führungskräfte. Ohne den offiziellen Projektstart durch den entsprechenden disziplinarisch Vorgesetzten sind die Mitarbeiter noch nicht für das Projekt freigestellt. Bereichsinterne Projekte, die nur die Zuständigkeit einer Führungskraft betreffen, können auch ohne Lenkungsausschuss direkt durch diese Führungskraft gesteuert werden. Definition Projektziel: Das Ziel muss bei bereichsübergreifenden Projekten von sämtlichen Führungskräften, die daran beteiligt oder davon direkt betroffen sind, getragen werden, insofern obliegt dem Lenkungssausschuss auch diese Festlegung. Definition Projektorganisation: Dies betrifft die Festlegung der in diesem Kapitel behandelten Strukturen. D. h., es wird definiert, wer Mitglied des Projektes in welcher Rolle ist, welche Gremien gebildet werden und wie die Berichtspflichten (Reportinglinien) sind etc. Freigabe Projektressourcen und Projektbudget: Irgendwoher müssen das Geld und die weiteren Ressourcen für das Projekt kommen. In der Regel bestreiten die im Lenkungsausschuss organisierten Führungskräfte diesen Aufwand aus ihren Budgets. Je nach Projektinteresse und -kosten kann es aber auch sein, dass nur ein Mitglied des Lenkungsausschusses diese trägt. Entsprechend der Herkunft der Budgets und Ressourcen können die Führungskräfte auch über deren Verwendung entscheiden und diese dem Projekt zuordnen oder auch wieder abziehen. Freigabe Projektplan: Dies betrifft die Planung (wie in Kapitel 3 dieses Buches dargestellt), also Timing, Meilensteine, Vorgehensweise etc. Entlastung des Projektmanagers bei Projektende: Am Projektende stellt der Lenkungsausschuss fest, ob das Projektziel wie geplant erreicht wurde und ob die Ressourcen sinnvoll eingesetzt wurden. Ist dies der Fall, dann wird der Projektmanager entlastet und kann sich anderen Aufgaben widmen. Ist dies nicht der Fall, so wird auch dies festgestellt und


145

ggf. muss der Projektleiter nacharbeiten. Insofern entspricht diese Funktion in etwa der Entlastung eines Vorstandes durch den Aufsichtsrat. Kontrolle bzw. Freigabe wesentlicher Meilensteine: Während das Projekt läuft, hat der Lenkungsausschuss meist weniger zu tun. Ihm wird über wesentliche Meilensteine berichtet und er gibt diese wichtigen Zwischenergebnisse frei und entscheidet, ob auf dieser Basis weitergearbeitet wird. Hierbei geht es nicht um eine laufende Kontrolle, sondern um die Kontrolle der wichtigsten Zwischenergebnisse. Erkennt der Lenkungsausschuss bei der Kontrolle der Meilensteine, dass das Gesamtprojekt etwa zu teuer wird oder die Erreichung des geplanten Projektziels nicht mehr realistisch ist, dann kann er das Projekt ändern oder sogar abbrechen. Freigabe von Budgets und Treffen von Entscheidungen, die die Kompetenzen des Projektmanagers überschreiten: Ein Projektmanager kann Entscheidungen bis zu einer gewissen Summe treffen – darüber hinaus muss er den Lenkungsausschuss oder den Steuerkreis um eine entsprechende Entscheidung bitten. Diese Regelung ist meist so getroffen, um Transparenz und Kontrolle zu gewährleisten. Bestimmung Projektende: Nur der Lenkungsausschuss hat die Kompetenz zu entscheiden, das Projekt zu beenden. Der Projektmanager kann dies dem Lenkungsausschuss lediglich empfehlen. Diese Regelung spiegelt das Recht, das Projekt zu starten. Unterstützung Projektteam und Projektleiter: Diese letzte hier aufgeführte Funktion ist eine ganz wesentliche, auch wenn sie manchmal in den Hintergrund tritt und formal nicht festgelegt wird. Die Führungskräfte im Lenkungsausschuss haben die Macht, viele Probleme für den Projektmanager aus dem Wege zu räumen. Probleme in Projekten resultieren oft aus divergierenden Zielsetzungen im Unternehmen. Diese haben oft in unterschiedlichen Bereichsinteressen ihren Ursprung und sind so auf der Arbeitsebene schwer aufzulösen. Die Aufgabe für den Lenkungsausschuss ist es nun, solche Hindernisse durch Klärung auf höchster Führungsebene aus dem Weg zu räumen. Zudem kann der Lenkungsausschuss bei der Klärung praktischer Probleme helfen, etwa wenn nicht die notwendigen Ressourcen zur Verfügung stehen. Als budgetverantwortliche Manager können sie hier die notwendigen Entscheidungen treffen und als disziplinarisch Vorgesetzte können sie entsprechende Anweisungen geben. In der Praxis zeigt sich häufig, dass diese Funktion sehr wichtig ist.

Üblich ist, dass der Lenkungsausschuss zum Projektstart, bei den wesentlichen Meilensteinen und zum Projektende zusammentritt. Die vorherige Terminplanung für diese Sitzungen ist hierbei ein praktisches Problem, das oft unterschätzt wird. Die beteiligten Führungskräfte zusammenzubringen, ist aufgrund der engen Terminpläne des Managements nicht einfach – oft ist es aber wichtig, dass alle Mitglieder des Lenkungsausschusses an den Sitzungen teilnehmen. Einstimmigkeit ist ein wichtiges Prinzip im Lenkungsausschuss, da die Akzeptanz und Umsetzung der Projektergebnisse im Unternehmen sonst nicht sichergestellt ist. Daher sollten alle Termine bereits zum Projektbeginn koordiniert und ggf. Vertreterregelungen getroffen werden. Hilfreich sind auch regelmäßige monatliche Treffen.

146

Projektorganisation

Bei strittigen Themen ist es ratsam, dass der Projektmanager diese im Vorfeld einer Lenkungsausschusssitzung einzeln mit den Mitgliedern durchspricht. So kann geklärt werden, ob eine Einstimmigkeit zu erwarten ist und wie auf Einwände reagiert werden kann. Die Vorbereitung einer Lenkungsausschusssitzung ist daher von großer Bedeutung für den Projektmanager und erfolgskritisch für das gesamte Projekt. Es ist üblich – wenn auch nicht zwingend – dass der Projektmanager im Lenkungsausschuss berichtet. In Analogie zu den Gremien einer Aktiengesellschaft könnte man den Lenkungsausschuss am ehesten mit dem Aufsichtsrat vergleichen – auch wenn dieser Vergleich aufgrund der Doppelfunktion der Lenkungsausschussmitglieder in Projekt- und Unternehmensorganisation etwas hinkt.

4.1.2

Steuerkreis

Der Steuerkreis, oder auch Fachausschuss, ist mit Führungskräften der Ebene unterhalb des Lenkungsausschusses besetzt. In der Regel sind dies Abteilungsleiter. Sie repräsentieren in diesem Gremium ihre Zuständigkeitsbereiche und vertreten dort ihre Interessen. Zusätzlich ist der Projektleiter (siehe hierzu Seite 150) in der Regel Mitglied im Steuerkreis. Die Aufgaben des Steuerkreises sind: Fachliche Beratung: Im Steuerkreis wird über fachliche Probleme beraten, die abteilungsübergreifend und auf der operativen Ebene nicht lösbar sind (etwa, weil ein Konsens hergestellt werden muss). Das Fachwissen der entsprechenden Abteilungsleiter kann hier eingebracht werden und zudem erlaubt das Gremium gemeinsame Entscheidungen. Inhaltliche Freigabe der Projektarbeit: Der Steuerkreis berät nicht nur, er darf auch Vorgehensweisen inhaltlich freigeben. Damit sind sie dann für das Projekt verbindlich und von den entsprechenden beteiligten Abteilungen und Bereichen akzeptiert. Dies können beispielsweise Berechnungsmodalitäten bei der Bestimmung von Kosten sein, Methoden der IT-Anbindung von Bereichen etc. Laufende Kontrolle des Projekts: Der Steuerkreis überwacht den Projektfortschritt inhaltlich und auch vom Ressourcen- und Budgetverbrauch her. Dies erfordert detailliertere Einsicht in die Projektarbeit als beim Lenkungsausschuss und auch eine regelmäßigere Kontrolle. Überprüfung auf Risiken: Grundsätzlich muss natürlich jede am Projekt beteiligte Person Risiken aufdecken und überwachen. Da aber der Steuerkreis eine abteilungsübergreifende Sichtweise besitzt und mit erfahrenen Führungskräften besetzt ist, eignet sich dieses Gremium hierzu besonders. Insbesondere kann der Steuerkreis beurteilen, ob eine ggf. später geplante Implementierung der Projektergebnisse in den Abteilungen möglich ist.


147

Unterstützung der Projektleitung: Entsprechend dem Lenkungsausschuss ist natürlich auch der Steuerkreis dafür da, eventuelle Hindernisse für das Projekt aus dem Weg zu räumen. Entscheidungen treffen, die ihre Fachbereiche oder Abteilungen betreffen und oberhalb der Kompetenzen des Projektleiters und unterhalb der Zuständigkeit der Mitglieder des Lenkungsausschusses liegen. Je nach Budgethoheit muss der Steuerkreis beispielsweise Budgetentscheidungen, Entscheidungen über den Personaleinsatz oder wichtige inhaltliche Entscheidungen treffen. Information des Lenkungsausschusses: Der Steuerkreis berichtet an den Lenkungsausschuss. Dieser ist für das Projekt fachlicher Vorgesetzter und besteht in der Regel aus den disziplinarischen Vorgesetzten der Mitglieder des Steuerkreises. Entsprechend ist es Aufgabe des Steuerkreises, den Lenkungsausschuss gemäß den in der Projektplanung definierten Anforderungen zu informieren. Der Steuerkreis kann diese Aufgaben an den Projektleiter delegieren. Schnittstelle in die Fachbereiche zu sein: Die Mitglieder des Steuerkreises sind nicht nur die Vorgesetzten der am Projekt beteiligten Bereiche und damit vieler im Projekt eingebundener Mitarbeiter, sie sind auch für viele weitere Personen Führungskräfte. Für den Erfolg eines Projektes ist dessen Verankerung im Unternehmen meist sehr wichtig – hierfür müssen auch die Mitarbeiter, die nicht direkt in die Projektorganisation eingebunden sind, über das Projekt informiert werden. Diese Aufgabe nehmen oft die Mitglieder des Steuerkreises wahr, da sie als Vorgesetzte ohnehin für die Versorgung ihrer Mitarbeiter mit Informationen verantwortlich sind. Ggf. muss der Projektleiter dann die Aufgabe übernehmen, weitere Personen zu informieren, die nicht durch den Steuerkreis abgedeckt sind.

Der Steuerkreis ist somit viel tiefer als der Lenkungsausschuss in die inhaltliche Projektarbeit involviert. Die Mitglieder sind in der Regel die Linienvorgesetzten der Projektmitarbeiter. Auch im Steuerkreis herrscht das Einstimmigkeitsprinzip. In der Regel trifft sich ein Steuerkreis einmal in der Woche oder vierzehntäglich. Neben dem Projektmanager berichten die inhaltlich am Projekt arbeitenden Mitarbeiter im Steuerkreis über Fortschritte und Inhalte. Wenn man auch hier den Vergleich zu den Gremien einer Aktiengesellschaft ziehen möchte, so ist der Steuerkreis am ehesten mit dem Vorstand zu vergleichen, der die Geschäfte führt.

148

Projektorganisation

4.1.3

Kernteam (Projektgruppen)

Das Kernteam bilden die Mitarbeiter, die tatsächlich inhaltlich am Projekt arbeiten9 und die Arbeitspakete abarbeiten. Diese Aufgabe richtet sich in ihrem Inhalt vollkommen nach dem Projektplan und -ziel. Wichtig ist hierbei, dass auch jedes einzelne Projektmitglied eine Gesamtsicht auf das Projekt hat, seinen Beitrag erkennt und die inhaltlich notwendigen Schritte der Abstimmung mit den anderen Projektteilnehmern im Sinne des Gesamtprojektes ergreift. Spezielle Aufgaben im Projektmanagement haben die Projektmitglieder kaum – diese beziehen sich in der Hauptsache auf die Teilnahme an Abstimmungsrunden sowie das Reporting des Projektfortschrittes, so dass zentral eine aktuelle Übersicht hierüber erstellt werden kann. Bei umfangreicheren Aufgabenstellungen bzw. Projekten ist das Kernteam in verschiedene Teilprojektgruppen unterteilt, die jeweils an unterschiedlichen Themen arbeiten. Hierbei gibt es verschiedene Prinzipien, wie man zu Projektgruppen oder Teilprojekten gelangen kann. Diese entsprechen den verschiedenen Strukturierungsmöglichkeiten im Projektstrukturplan (vgl. Kapitel 3.2 ab Seite 81). Objektbezogene Gliederung: Dies ist die Zusammenfassung von Tätigkeiten, die sich auf das gleiche Objekt beziehen. Das Objekt ist hierbei meist ein Produkt des Unternehmens. So könnte bei einem Automobilhersteller die Teilprojektgliederung eines Optimierungsprojektes nach Kleinwagen, Mittelklasse Pkw, Oberklasse Pkw und Transportern erfolgen. Funktionale Gliederung: Hierbei erfolgt die Zusammenfassung gleichartiger Tätigkeiten zu einem Teilprojektteam. Ein Beispiel wäre hierfür folgende Teilprojektbildung für ein Optimierungsprojekt: Teilprojekt Kosten-Controlling, Teilprojekt Benchmarking und Teilprojekt Leistungserfassung. Organisationsbezogene Gliederung: Dies ist die Zusammenfassung von Teilprojekten nach Organisationsstrukturen. Das Beispiel wäre also: Teilprojekt Controllingabteilung, Teilprojekt Produktionsabteilung, Teilprojekt Personalabteilung. Da Abteilungen oder Unternehmensbereiche oft (aber nicht immer!) nach Funktionen gegliedert sind, sieht eine solche Teilprojektbildung auf den ersten Blick nach einer funktionalen Gliederung aus. Es gibt aber einen ganz wesentlichen Unterschied. Bei der funktionalen Gliederung könnten und sollten auch Projektmitglieder, die in der Unternehmensorganisation nicht der entsprechenden Abteilung zugeordnet sind, dem Teilprojekt angehören. Dies ist für Projekte sehr wichtig, zumal diese ja gerade bereichsübergreifende Aufgabestellungen lösen und sich von der Abteilungssicht lösen sollen. In der Regel ist daher die organisationsbezogene Gliederung als Grundprinzip der Teilprojektbildung für Managementprojekte abzulehnen. Geografische Gliederung: Hierbei erfolgt die Zusammenfassung regional zusammengehöriger Tätigkeiten zu Teilprojekten. Beispielsweise könnte dies so aussehen: Teilpro9

Natürlich arbeiten Lenkungsausschuss- und Steuerkreismitglieder auch inhaltlich am Projekt, jedoch nehmen diese dabei eher eine Managementfunktion (im Sinne einer Leitungsfunktion) wahr.


149

jektteam UK, Teilprojektteam Continental Europe, Teilprojektteam America und Teilprojektteam AsPac. Die Entscheidung, wie man ein Projekt in Teilprojekte gliedert, sollte so erfolgen, dass sich innerhalb der gebildeten Teilprojekte möglichst gut abzuarbeitende Aufgabenpakete ergeben. Dies ist dann der Fall, wenn innerhalb der Teilprojekte große Synergien resultieren – dies sollte in der Regel dann der Fall sein, wenn Aufgaben zusammengefasst werden, die fachlich die größten Anforderungen stellen. Ist es zum Beispiel für das Kosten-Controlling relativ egal, ob Daten für Europa oder die USA beschafft werden müssen, so bietet sich eine Gliederung nach Funktionen an, da hierdurch Skaleneffekte realisiert werden können. Ist es aber so, dass die regionalen Ansprechpartner jeweils sehr spezifische Daten in Europa und den USA haben, die die Teams viel leichter pro Region vor Ort beschaffen können, dann ist eine geografische Gliederung sinnvoll. Natürlich sind auch Mischformen denkbar. Eine Rolle spielt auch die vorliegende Unternehmensorganisation – je nachdem, wie dort die Regelaufgaben organisatorisch gegliedert sind, ist es einfacher oder schwieriger für das Projekt, eine geeignete Projektorganisation in diese vorhandene Organisation einzubeziehen. Die Projektgruppen arbeiten in der Regel laufend zusammen und informieren sich so fortwährend über den Projektfortschritt. In den meistern (und meist bei größeren) Projekten gibt es darüber hinaus noch wöchentliche Teammeetings, in denen der Status ausgetauscht wird und der Projektleiter Entscheidungen zum weiteren Vorgehen trifft und neue Arbeitspakete zuordnet. Die Teilnehmer im Kernteam können bei Managementberatungsprojekten zum einen natürlich die Berater sein. Oft gibt es auch gemischte Teams, in denen Berater und Mitarbeiter des Klientenunternehmens zusammenarbeiten. Im Sinne einer Arbeitsteilung ist dies häufig sinnvoll, um die unterschiedlichen Stärken zusammenzubringen, um den Informationsfluss aus dem Unternehmen in das Projekt sicherzustellen und um das Projekt frühzeitig in das beratene Unternehmen einzugliedern und die Akzeptanz und Umsetzbarkeit der Ergebnisse zu gewährleisten. Anzumerken ist an dieser Stelle noch, dass es für den Projekterfolg maßgeblich ist, die richtigen Mitarbeiter zu einem Team zusammenzustellen. Dies betrifft zum einen natürlich die Qualifikation der Mitarbeiter (siehe hierzu Abschnitt 3.4.2 auf S. 110 ff.), zum anderen müssen die Mitarbeiter als ein gemeinsames Team arbeiten. Die richtige Teamzusammensetzung fördert auch die Motivation der Teammitglieder und ist so von grundlegender Bedeutung für die weitere Projektarbeit. (siehe hierzu Abschnitt 6.4.4 ab S. 240).

150

4.1.4

Projektorganisation

Projektleiter

Der Projektleiter oder auch Projektmanager steht dem Kernteam vor. Im Folgenden verwenden wir hier die Bezeichnung Projektleiter, da Projektmanager in Managementberatungen oft auch für eine Hierarchiestufe steht, ab der man dann in der Regel auch Projektleitertätigkeiten übernimmt. Man kann aber auch Projektmanager sein, ohne gerade ein Projekt zu leiten. Er ist der fachliche Vorgesetzte aller Projektmitarbeiter, manchmal ist er auch disziplinarischer Vorgesetzter. Obwohl er im Projekt eine herausragende Stellung hat, ist der Projektleiter von den Entscheidungen des Steuerkreises und Lenkungsausschusses abhängig. Seine Aufgaben umfassen (siehe hierzu Rinza 1998, S. 138 ff.; Kerber-Kunow 2000, S. 45): Prüfung des Projektziels. Der Projektleiter muss sich kritisch mit Vorgaben des Auftraggebers auseinander setzen. Er überprüft das Ziel des Auftraggebers und dessen Operationalisierung auf Erreichbarkeit und Sinnhaftigkeit. Sollte er das Ziel nicht für sinnvoll halten, so ist es seine Aufgabe, dies mit dem Auftraggeber zu diskutieren. In extremen Fällen, beispielsweise wenn ein Projektziel dem Unternehmensziel konträr gegenübersteht und der Auftraggeber das Projekt dennoch durchführen möchte, sollte der Projektleiter die Projektleitung ablehnen. Verantwortlichkeit für den Projektplan. Die Aufstellung des Projektplans sicherzustellen ist eine weitere Aufgabe des Projektleiters. Entweder stellt er den Projektplan selbst auf oder er koordiniert und überwacht die Erstellung. Der Projektleiter trägt die Verantwortung dafür, dass für das Projekt ein geeigneter Projektplan erstellt und angewendet wird. Die Freigabe des Projektplans erfolgt letztendlich allerdings dann durch den Lenkungsausschuss. Erstellung der Projektorganisation. Im Idealfall erstellt der Projektleiter einen Vorschlag für eine Projektorganisation. Dies betrifft die Art und Besetzung der Gremien und die Teilprojektbildung sowie die Teams, d. h. Vorschläge dafür, welche Mitarbeiter im Projekt arbeiten. Dieser Vorschlag muss dann mit dem Auftraggeber sowie im Steuerkreis und Lenkungsausschuss abgestimmt werden. Da das Personal die wichtigste Ressource in der Managementberatung ist (neben Informationen), liegt es stark im Interesse des verantwortlichen Projektmanagers, auch hierauf Einfluss zu nehmen. In der Praxis ist es jedoch auch immer wieder möglich, dass Teammitglieder und Projektmanager gleichzeitig durch den Auftraggeber bestimmt werden, so dass der faktische Einfluss des Projektleiters sehr gering sein kann. Aufstellung des Projektbudgets. Hier gilt sinngemäß dasselbe wie in den vorangegangenen Punkten. Der Projektmanager verantwortet einen Vorschlag, der durch den Lenkungsausschuss letztendlich bewilligt wird. Aber auch hier kommt es durchaus vor, dass der Projektleiter vor vollendete Tatsachen gestellt wird. Ist dies der Fall, so bleibt dem Projektleiter auch hier maximal die Reaktionsmöglichkeit, die Projektleitung abzulehnen.


151

Mitarbeiterführung. Im laufenden Projektgeschäft ist der Projektleiter fachlicher Vorgesetzter der Projektmitarbeiter. Zwar muss er grundlegende Entscheidungen über die Gremien Steuerkreis und Lenkungsausschuss bestätigen lassen, faktisch hat der Projektleiter jedoch weitgehende Einflussmöglichkeiten. Teilweise sind Projektleiter den Projektmitarbeitern sogar disziplinarisch vorgesetzt und haben dann weiterführende Personalentwicklungsaufgaben. Dies wäre in einer reinen Projektorganisation der Fall (siehe Kapitel 4.3) Motivation des Projektteams. Ohne Motivation des Projektteams wird ein Projektergebnis nur schwer erreichbar sein. Die Motivation der Mitarbeiter, gerade in einem Umfeld, das in der Managementberatung durch einen hohen Neuigkeitscharakter geprägt ist, ist der Schlüssel zum erfolgreichen Projektmanagement. Die beste Projektplanung und -organisation „verpufft“, wenn die Mitarbeiter dieses nicht umsetzen. Die Aufgabe des Projektleiters ist es, Rahmenbedingungen zu schaffen, innerhalb derer die Mitarbeiter motiviert auf das Projektziel hinarbeiten, bzw. diese Motivation direkt zu fördern. Konfliktlösung. Leider ist es in der Regel so, dass nicht alles im Projekt immer glatt laufen wird. Konflikte gehören zu jedem Managementberatungsprojekt dazu, denn dieses soll ja Neues schaffen oder Veränderungen vornehmen. Der Projektleiter muss die Konflikte frühzeitig erkennen (etwa anhand unterschiedlicher Zielsetzungen von Beteiligten) und rasch gegensteuern. Gelingt ihm dies nicht ausreichend, so liegt es in seiner Verantwortung, den Konflikt unter Einschaltung von Steuerkreis oder Lenkungsausschuss zu klären. Präsentation der Projektergebnisse und Berichterstattung vor den Gremien. In der Regel obliegt es dem Projektleiter, das Projekt nach innen und außen zu vertreten. Hierzu gehört auch die Präsentation der Ergebnisse vor den Gremien, insbesondere die Statusberichterstattung. Entsprechend muss der Projektleiter sicherstellen, jederzeit über den Projektstatus der einzelnen Teilprojekte informiert zu sein. Er ist für Steuerkreis und Lenkungsausschuss der zentrale Ansprechpartner. Ergebnisse, die von bestimmten Personen oder Teilprojektgruppen erarbeitet wurden, sollten allerdings auch von diesen präsentiert werden, wenn es im Rahmen der Gremien möglich ist. Dies fördert die Motivation und es ist sichergestellt, dass die Experten für die jeweiligen Fragestellungen diese auch vortragen. Qualitätssicherung und Ergebnisverantwortung. In einem Projekt werden in verschiedenen Arbeitspaketen Teil- und Zwischenergebnisse erarbeitet. Für den Erfolg des Projektes ist es nun wichtig, dass die einzelnen Teilergebnisse jeweils die für das Gesamtprojekt erforderliche Qualität aufweisen bzw. als Basis für die weitere Arbeit geeignet sind. Der Projektleiter hat diese Eignung sicherzustellen – er ist für die Ergebnisse verantwortlich, auch wenn er sie nicht selbst erstellt.

Der Projektleiter in Managementberatungen hat vielfältige Aufgaben und entsprechend stellt die Tätigkeit hohe Anforderungen an die Kenntnisse und Fähigkeiten der Person. Einen Berufsanfänger gleich mit einer solchen Tätigkeit zu betrauen, erscheint daher wenig sinnvoll. Die Tabelle in Abbildung 65 liefert ein kurzes Anforderungsprofil an die Person des Projektleiters. Hervorzuheben ist, dass ein guter Projektleiter persönliche und fachliche Fähigkeiten gleichermaßen besitzen muss wie auch einen starken Einsatzwillen (vgl. auch Maylor 1999,

152

Projektorganisation

S. 23-24). Die vorgenommene Einteilung ist natürlich nicht überschneidungsfrei, gibt aber jeweils die wichtigsten Fähigkeiten und Kenntnisse wieder.

Projektplanung

Aufgabe

persönliche und soziale Fähigkeiten

Kenntnisse/ Erfahrungen

Prüfung Projektziel

analytisches Denk-

Methoden des

Verantwortlichkeit

vermögen Formulierungsfähigkeit Strukturierungsfähigkeit

Projektmanage-

Organisationsfähigkeit

hilfreich:

Kundenorientierung

fachliche Kenntnisse

Projektplan Aufstellung Projektorganisation Aufstellen Projektbudget

mentsoftware

zur Projektaufgabe Kenntnis des zu

beratenden Unternehmens Mitarbeiterführung

Bereitschaft, Verant-

Instrumente des

Motivation

wortung zu übernehmen Handlungsorientierung statt Problemvermeidung Zeitmanagement, Fähigkeit, Prioritäten zu setzen Zielorientierung

Personalmanagements hilfreich:

Personalführung im Projekt

Konfliktlösung

Ergebnisvorstellung und -sicherung

Projektmanagements

fachliche Kenntnisse Personalführungs-

erfahrung

Einsatzbereitschaft und

Belastbarkeit Flexibilität Kommunikationsfähigkeit Teamfähigkeit emotionale Intelligenz Präsentation

sicheres Auftreten

Qualitätssicherung

Präsentationsfähigkeit

Präsentations-

techniken

analytische Fähigkeiten

Chartgestaltung

sicherer Umgang mit

Präsentations-

Sprache Verbindlichkeit

software [PowerPoint]

Abbildung 65: Anforderungsprofil an einen Projektmanager (idealtypisch)

In Managementberatungsunternehmen wird daher gezielt und mit hohem Aufwand nach Personen gesucht, die ein solches Potenzial mitbringen. Und das entsprechend qualifizierte


153

Personal ist entsprechend das Potenzial einer Managementberatung und einer der Hauptgründe, der die Beratungssätze rechtfertigt.

4.1.5

Projektbüro bzw. Programmbüro

In größeren Projekten wird oft ein Projektbüro als zentrale Einrichtung eingerichtet, das die Aufgabe der Koordination des Projektes hat. Zum Teil wird auch die Bezeichnung Programm- oder Projektoffice gewählt. In der Regel arbeiten ein bis drei Mitarbeiter in einem Projektbüro, das durch den Projektmanager geleitet wird. Die Aufgaben des Projektbüros können sehr vielfältig sein und von reiner administrativer Unterstürzung bis zur Programmkoordination reichen. Zu nennen sind (Wischnewski 2001, S. 59 ff.; Wolf/Mlekusch 1997, S. 211-213): Allgemeine Projektkoordination. Dies umfasst die Erstellung, Pflege und Bereitstellung von Adressen- und Kontaktlisten von Projektansprechpartnern und Projektteilnehmern, die Koordination der Lenkungsausschuss-, Steuerkreis- und Kernteam-Meetings (Termin- und Raumkoordination, Einladung, Raumvorbereitung etc.), die zentrale Verwaltung der Projektdokumente (entweder physisch oder elektronisch), verschiedenste Sekretariatsarbeiten, Unterstützung der Projektteilnehmer in administrativen Fragen wie Reisebuchungen etc. Dies kann auch die Kommunikation umfassen, die in komplexeren Projekten oder Programmen über das Projektoffice als Knotenpunkt laufen kann. Anfragen können an das Projektoffice gestellt werden, das die Frage dann an die zuständige Person weiterleitet oder die direkte Kommunikation durch Herausfinden des Ansprechpartners ermöglicht. Berichterstattung. Die Berichte der im Projekt oder Programm vertretenen Teilprojekte können durch das Projektoffice gesammelt und aufbereitet werden. Das Projektoffice stellt dann die Vollständigkeit sicher und kontrolliert die Plausibilität. Zentrales Projektcontrolling. Dies ist eine auch inhaltlich teilweise schon gestalterische Aufgabe. Sie beginnt in der einfachsten Stufe mit der zentralen Verwaltung der Projektpläne und geht dann bis zur aktiven Kontrolle der Budgets, des Erreichens von Meilensteinen oder sonstigen inhaltlichen Ergebnissen etc. Eine aktive Kontrolle erfordert dabei bereits ein inhaltliches Nachvollziehen der jeweiligen Projektarbeit. Geht die Kontrolle über das Prüfen hinaus, und sollen auch schon Vorschläge im Sinne einer Steuerung gemacht werden, dann ist ein tiefes Verständnis für die Inhalte der Projektarbeit notwendig. Risikomanagement. Die Aufgabe des Risikomanagements erfordert gerade bei komplexeren Programmen, die aus mehreren Teilprojekten bestehen, eine übergeordnete Sicht, die die einzelnen Risiken übergreifend für alle Teilprojekte bewertet. Und dies muss nicht nur einmal, wenn das Programm aufgesetzt wird, geschehen, sondern erfordert eine laufende Aktualisierung. Diese Aufgabe kann vom Projektoffice übernommen werden, welches dann auch in dieser Hinsicht die Teilprojekte oder Projekte koordiniert. Da das Risikoma-

154

Projektorganisation

nagement eine sehr wichtige Aufgabe ist, erfordert dies eine starke Stellung des Projektbüros bzw. die direkte Leitung des Projektbüros durch den Projektmanager. Agendamanagement. Unter Agendamanagement versteht man die inhaltliche Koordination von Themen für die Projektgremien. D. h., es wird festgelegt, welches Projekt oder Teilprojekt wann was in den Gremien vorstellt. Dies geschieht natürlich auf Basis der Projektpläne und Anforderungen der Projektteilnehmer. Vor den jeweiligen Terminen stellt das Projektoffice sicher, dass die notwendigen Unterlagen vorliegen, und übernimmt eine Funktion der Qualitätssicherung. Zugleich kann geprüft werden, ob es inhaltliche Überschneidungen, Lücken oder Widersprüche gibt und auf diese im Vorfeld der Gremientagungen hinweisen. Hierdurch kann die Gremienarbeit eine wesentliche Effizienzsteigerung erfahren, da im Vorfeld zu klärende Abstimmungsprobleme schneller evident werden und so mehr Zeit für notwendige Anpassungen der Teilprojekte zur Verfügung steht. Initiierung notwendiger Folgeprojekte. Soweit sich Folgeaufgaben direkt aus einzelnen Projekten ergeben, ist es Aufgabe der einzelnen Projektgruppen und -leiter, auf deren Notwendigkeit hinzuweisen. Wenn sich jedoch übergreifende Themenstellungen ergeben oder es für ein Folgeprojekt beispielsweise sinnvoll ist, Themen verschiedener Projekte zu bündeln, dann kann dies aus der Perspektive eines Projektes nicht immer gesehen werden. Daher macht es Sinn, die Initiierung von Folgeprojekten innerhalb eines Programms auch zentral zu planen. Hierzu bietet sich – zumindest für die Grobplanung – das Projektoffice an, das die bisherigen Projektpläne ja auch schon koordiniert hat.

Praxisbox 16: Programmorganisation bei STAR Im Rahmen des Programms STAR (siehe Praxisbox 1 ab Seite 33) wurden im Laufe der Zeit über 100 Projekte gestartet, die jeweils sehr unterschiedliche Unternehmensbereiche betreffen, unterschiedlich lange Laufzeiten haben, verschiedenen Inhalte aufweisen und sehr unterschiedlich mit Personal und Ressourcen ausgestattet sind. Um diese Projekte steuern zu können, wurde entschieden, eine übergeordnete Programmstruktur zu etablieren und die erzielten Umsatzpotenziale und Effizienzgewinne zentral zu melden und zu kontrollieren. Jedes in STAR enthaltene Projekt hat seine eigene Projektorganisation mit Projektleiter, Kernteam und Steuerkreis. Zusätzlich ist das Projekt in die Programmstruktur von STAR eingebunden: Ein STAR-Steering-Committee auf der Ebene der Vorstände koordiniert die Projekte bereichsübergreifend und international und trifft als Gremium übergreifende Entscheidungen. Die Projekte berichten an dieses Komitee, das die erste Koordinationsstufe in den Bereichen des Konzerns wahrnimmt. Das STAR-Board auf Vorstandsebene kontrolliert das gesamte Programm und überwacht insbesondere die Einhaltung des geplanten Ziels der Steigerung des Unterneh-

Projektorganisation bei Einsatz von Beratern

155

menswerts. Die Steering-Committees berichten an dieses Board über die Projekte in ihren Bereichen. Auf dieser Ebene werden die strategischen Entscheidungen getroffen, die im Rahmen des Programms notwendig sind. STAR ist in der direkten Vorstandsverantwortung – über das Board hinaus hat ein Vorstandsmitglied als Programmleiter direkte Verantwortung. Ein Programmoffice koordiniert die vielen internationalen Projekte und übernimmt die operative Projektfortschritts- und Kostenkontrolle. Zudem ist das Office für das Agendasetting zuständig und prüft, inwieweit weitere übergreifende Maßnahmen notwendig sind. In dem Office sind je nach Projektverlauf bis zu sieben Personen beschäftigt. Durch diese übergreifende Struktur konnte die Gefahr vermieden werden, dass die einzelnen Projekte widersprüchliche Ziele verfolgen und insgesamt das Programm aufgrund der Vielzahl der Themen nicht mehr steuerbar bleibt. Die saubere Programmstruktur hat dazu beigetragen, dass STAR ein großer Erfolg geworden ist, der den Konzernwert schon im hohen neunstelligen Euro-Bereich steigern konnte.

4.2


Das vorherige Kapitel 4.1 hat sich mit der Projektorganisation befasst, also mit der Frage der inneren Organisationsstruktur in Projekten. Die entsprechenden Gremien eines Projektes und deren Aufgaben wurden vorgestellt. Noch nicht geklärt wurde das Zusammenspiel von Mitarbeitern der Managementberatung und des Klientenunternehmens innerhalb dieser Projektorganisation. Hierauf wird in diesem Abschnitt eingegangen. Zuerst soll der Fall behandelt werden, dass das Projekt ausschließlich mit Beratern besetzt ist. Innerhalb des Kernteams gibt es dann entsprechend keine Überschneidungen der Organisationsstrukturen und das Projekt arbeitet autonom – wenn man von den immer notwendigen Schnittstellen zur Informationsgewinnung einmal absieht. Ein solches rein durch Berater besetztes Kernteam ist zu wählen, wenn: es sich um eine klar definierte Aufgabe handelt, die ohne tiefe Eingliederung in die Unternehmensorganisation autonom erstellt werden kann. Dies könnte beispielsweise die Aufstellung eines neuen Grundkonzeptes zur Steuerung von Unternehmensbereichen sein, wo auf der ersten konzeptionellen Ebene der Überlegungen Interviews mit einzelnen Mitarbeitern im Unternehmen ausreichen. Implementierungsprojekte – etwa die Einführung eines neuen Produktes – erfordern in der Regel eine höhere Integration in das Unternehmen und würden durch gemischte Teams bearbeitet.

156

Projektorganisation

die Projektergebnisse streng vertraulich sind und den Mitarbeitern nicht kommuniziert werden können. Dies wäre etwa der Fall bei Projekten mit starken Auswirkungen auf die Arbeitsplätze der Mitarbeiter (etwa bei Prüfungen von Betriebsschließungen).

Ein solches ausschließlich durch Berater besetztes Projekt wird in der Regel durch einen Projektleiter aus der Managementberatung geleitet. Dieser berichtet an den Auftraggeber, welcher dann über die Inhalte entscheidet. Wenn noch keine Implementierung betroffen ist und es sich um ein reines Advice-Projekt oder ein einfaches Projekt handelt (siehe hierzu Abbildung 3 auf S. 34), wird oft auf die Projektgremien Steuerkreis und Lenkungsausschuss verzichtet, und der Auftraggeber platziert die Projektinhalte und -ergebnisse wenn nötig in den vorhandenen Unternehmensgremien. Der Regelfall sind jedoch Projekte, bei denen Berater und Mitarbeiter des Unternehmens gemeinsam im Kernteam arbeiten. In diesem Fall wird dann häufig eine Doppelspitze bei der Projektleitung gewählt. Ein Mitarbeiter des Unternehmens übernimmt die so genannte fachseitige Projektleitung und ein Mitarbeiter der Managementberatung die beratungsseitige Projektleitung. Die Aufgaben sind dabei wie folgt verteilt: Die fachseitige Projektleitung hat sicherzustellen, dass der Informationsfluss in das Unternehmen und vom Unternehmen in das Projekt gewährleistet ist. Sie hat sicherzustellen, dass die laut Projektplan vereinbarten Ressourcen auch tatsächlich zur Verfügung gestellt werden. Die fachseitige Projektleitung berichtet direkt an den Auftraggeber und ist dafür verantwortlich, dass die erarbeiteten Projektergebnisse im Sinne des Auftraggebers sind. Zudem steht sie den fachseitigen Mitarbeitern im Kernteam vor (wenn es VollzeitProjektmitarbeiter sind). In der Regel vertritt die fachseitige Projektleitung das Projekt in den Gremien, wenn dort eine besondere Akzeptanz notwendig ist. Dadurch, dass ein Unternehmensvertreter das Projekt vertritt, wird in der Regel eine höhere Akzeptanz erreicht. Die beratungsseitige Projektleitung ist für die Durchführung der Projektplanung (Zeit, Meilensteine, Arbeitspakete, Ressourcen etc.), den Beratereinsatz und das Projektcontrolling verantwortlich. Sie treibt die inhaltliche Arbeit voran und stellt sicher, dass die Projektergebnisse plangerecht erarbeitet werden. Die beratungsseitige Projektleitung ist für den im Angebot versprochenen Projekterfolg verantwortlich. Auch sie berichtet an den Auftraggeber. Die beraterseitige Projektleitung vertritt das Projekt in der Regel dann in den Gremien, wenn die Inhalte stark auf den Entwicklungen der Beratung fundieren.

Diese Doppelspitze hat den Vorteil, dass das Projekt besser an das Unternehmen angebunden ist. Wird ein mit internen Mitarbeitern eines Unternehmens besetztes Projekt nur durch die Managementberatung geleitet, so sind Akzeptanzprobleme bei der Führung der fachseitigen Mitarbeiter denkbar. Außerdem kann die Anwendbarkeit und Übertragbarkeit der Ergebnisse nicht laufend vom Unternehmen überwacht werden. Trotz dieser meist vorgenommenen Aufgabenabgrenzung gibt es eine breite Grauzone in der Abgrenzung der Zuständigkeiten der beiden Projektleiter. Um Kompetenzgerangel zu vermeiden ist es also notwendig, dass beide Projektleiter dieselben Ziele verfolgen und dass sie sich sehr eng abstimmen. Gelingt es, dass beide im Team als Doppelspitze arbeiten, so ist


157

diese Art der Führung sehr gut, da sie die Stärken beider Organisationen in der Projektarbeit nutzt. Da es keinen gemeinsamen Vorgesetzten aller in einem Kernteam vertretenen Mitarbeiter gibt, setzt die getrennte Doppelspitze eine gute Teamarbeit im Kernteam voraus. Auch hierfür müssen die Projektleiter gemeinsam sorgen. Ein Projekt wird nur dann erfolgreich sein, wenn die Ressourcen von Managementberatung und Fachseite nicht gegeneinander, sondern miteinander eingesetzt werden. Dies setzt wiederum die enge fachliche Abstimmung von fachseitiger und beratungsseitiger Projektleitung voraus. Die Gremien Steuerkreis und Lenkungsausschuss sind bei dieser Form der Projektarbeit in der Regel wie beschrieben implementiert.

Praxisbox 17: Die Organisation von Managementberatungen Managementberatungen bilden in ihren internen Hierarchiestufen schon den Einsatz in Projektorganisationen in etwa ab. Üblich sind eine Vielzahl von Stufen, die sich etwa den gängigen Ebenen Berater (Consultant), Projektmanager und Partner zuordnen lassen. Abbildung 66 zeigt die Karriereschritte und Arbeitsweise des Inhouse Consultings von Deutsche Post World Net:

Projektarbeitsstruktur

Director

1/5 Projektpartner

Partner Associate Partner 1 Projektleiter Project Manager Senior Consultant Consultant

2 - 4 Berater

Junior Consultant

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 66: Karrierestufen im Inhouse Consulting Ein Partner betreut 5 Projekte gleichzeitig. Ein Projektmanager und 2 - 4 Berater bilden das Team. Partner sind auf der Ebene des Lenkungsausschusses in Projekte eingebunden, Associate Partner und Project Manager auf der des Steuerkreises und übernehmen die Funktion von

158

Projektorganisation

Projektleitern. Consultants sind im Kernteam eingebunden. Geleitet werden Beratungen also häufig gemeinsam von mehreren Partnern. Außerhalb einer Projektstruktur haben die Stufen insofern keine Bedeutung, als dass sie keine disziplinarischen Verantwortungen abbilden. Die fachliche Verantwortung liegt in der Regel auf der Ebene der Partner, die disziplinarische auf Ebene so genannter Personalentwickler (d. h. Partner und Associate Partner). Die Ebene des Partners bedeutet bei unabhängig agierenden Beratungen, dass diese Personen mit Kapital an der Beratung beteiligt sind. In internen Beratungen wird diese Bezeichnung gerne übernommen, da sie bekannt ist. Aufgrund der Einbindung der internen Beratung in die Organisation des Mutterhauses entfällt jedoch in der Regel die Beteiligung am Kapital. Zusätzlich zu der dargestellten Hierarchiestruktur der Berater gibt es noch eine Administrations- und Unterstützungseinheit. So besitzt beispielsweise das Inhouse Consulting des Konzerns Deutsche Post World Net ein Support-Team, welches die Berater bei der Erstellung von Präsentationen unterstützt. Das Support-Team besteht aus speziell auf die Präsentationserstellung geschulten Mitarbeitern. Außerdem werden die Berater noch in administrativen und organisatorischen Fragen unterstützt, um sich überwiegend auf die Projektarbeit konzentrieren zu können. Dies umfasst etwa die Buchung von Reisen, Raumbuchung etc.

4.3

Eingliederung des Projektes in die Unternehmensorganisation

Die Angliederung eines Projektes in die Linienorganisation des Klientenunternehmens ist sehr wichtig für den Projekterfolg. Häufig werden in den Fachabteilungen eines Unternehmens eigene, vom Projekt unabhängige Ziele verfolgt und sie stellen unwillig ihre Ressourcen bereit. Das Projekt ist aber auf die Ressourcen der Linienfunktionen angewiesen, um das Projekt durchzuführen. Über eine gute Anbindung der Organisationsstrukturen von Unternehmen und Projekt können die Zieldifferenzen vermindert und die Steuerbarkeit des Projektes gewährleistet werden. Die grundlegenden Alternativen bei der Integration eines Projektes in die Unternehmensorganisation sind (vgl. Kerber-Kunow 2000, S. 41 ff.; Rinza 1998, S. 123; Litke 1995, S. 75, Wolf/Mlekusch 1997, S. 39 ff.): Reine Projektorganisation;


159

Projektkoordination (oder auch Stabs-Projektorganisation, Einfluss-Projektorganisation) und Matrix-Projektorganisation.

Die verschiedenen Möglichkeiten sollen im Folgenden kurz erläutert werden:

Reine Projektorganisation Eine reine Projektorganisation agiert unabhängig von einer Linienorganisation. Sie wird eigenständig durch den Projektleiter geleitet. Dieser hat die volle Verantwortung für das Projekt und die Organisation. D. h., die Mitarbeiter im Projekt sind für die Laufzeit des Projektes ausschließlich für das Projekt tätig. Zu beachten ist hierbei, dass eine Projektorganisation zeitlich befristet ist. Bei Managementberatungsprojekten können die Projektmitglieder entweder aus dem Beratungsunternehmen stammen oder aus dem Klientenunternehmen. Projekte, die rein aus Mitgliedern der Managementberatung rekrutiert werden, sind in puncto Projektorganisation relativ unkritisch, da die Berater nicht in die Unternehmensorganisation eingebunden sind. Sie stehen dem Projekt also meist zu 100 % zur Verfügung. Sind aber auch Mitarbeiter aus dem Klientenunternehmen beteiligt, müssen diese von vorher übernommenen Regeltätigkeiten im Unternehmen komplett freigestellt werden. Die Loslösung von den bisherigen Tätigkeiten ist dann eine wichtige Voraussetzung für die erfolgreiche Arbeit im Projekt. Ein Beispiel ist das Projekt STAR der Deutschen Post AG (siehe Praxisbox 1 auf Seite 33 und Praxisbox 14 auf Seite 135). Hierzu werden viele Mitarbeiter aus dem Unternehmen zu 100 % freigestellt oder sogar neu eingestellt. Während der Arbeit an STAR sind sie in keine andere Organisation im Unternehmen einbezogen. Um gute Mitarbeiter hierfür gewinnen zu können, erhalten die Mitarbeiter jedoch in der Regel die Garantie, eine Anschlusstätigkeit im Unternehmen nach Beendigung des Projektes zu erhalten. Bei STAR wurde diese Organisationsform gewählt, um sich voll und ganz auf die Projektziele konzentrieren zu können. Dies bedeutet hierbei nicht nur den vollen zeitlichen Einsatz, sondern auch die Loslösung von Bereichszielen, die dem Ziel der Kostensenkung in STAR eventuell entgegenstehen. Auch kann auf diese Art und Weise eine straffe Führung gewährleistet werden, da die disziplinarische Zuordnung der Mitarbeiter zu den Projektleitern gegeben ist. Der Vollständigkeit halber sei darauf hingewiesen, dass aufgrund des Umfangs des Programms STAR zusätzlich noch eine große Anzahl von „Teilzeitprojektmitarbeitern“ aus den Fachabteilungen in die Projektarbeit eingebunden ist. Eine ernst zu nehmende Aufgabe ist die Wiedereingliederung der Mitarbeiter in Linientätigkeiten. Für die Mitarbeiter aus dem Unternehmen ist dies eine Frage von sehr hoher Bedeutung, da sie das berufliche Fortkommen betrifft. Insbesondere in kleineren Unternehmen ist dies jedoch problematisch, da kein größerer permanenter Mitarbeiterbedarf besteht. Gerade für Spezialfunktionen, die nach Projektende nicht mehr benötigt werden, kann dies dann kritisch werden. Die Wiedereingliederung der Mitarbeiter sollte rechtzeitig thematisiert

160

Projektorganisation

und gelöst werden, da sonst die Gefahr besteht, dass das Projektende verschleppt wird, da die Mitarbeiter nicht wissen, welche Aufgaben sie nach dem Projekt übernehmen sollen. Ein Beratereinsatz kann aus dieser Überlegung heraus auch vorteilhaft sein, denn die Problematik der Wiedereingliederung in das Klientenunternehmen entfällt dann natürlich entsprechend. Eine reine Projektorganisation sollte gewählt werden, wenn ein Projekt volle Konzentration auf das Thema erfordert. Dies kann u. a. der Fall sein, wenn das Projekt sehr umfangreich ist, die Projektziele evtl. Bereichszielen entgegenstehen und dieser Widerspruch anders nicht aufgelöst werden kann (was vorzuziehen wäre) oder wenn es um Themen mit großem Innovationscharakter geht.

Bei einer reinen Projektorganisation muss die Projektgruppe sehr selbständig arbeiten. Die Schnittstellen in die Linientätigkeiten sind begrenzt. Die reine Projektorganisation arbeitet autark mit den unter Kapitel 4.1 dargestellten Gremien und Strukturen. Zur Sicherstellung der disziplinarischen Führung wird in diesem Fall dann häufig mit der beschriebenen fachseitigen und beratungsseitigen Doppelspitze in der Projektleitung gearbeitet, und die Gremien dienen dann als Schnittstellen in das Unternehmen hinein.

Projektkoordination Die Projektkoordination ist das Gegenteil der reinen Projektorganisation. Hierbei gibt es „nur“ einen Projektleiter, der als Stabsfunktion organisatorisch an den Auftraggeber angebunden sein kann (Rinza 1998, S. 126; Litke 1995, S. 76-77). Der Projektleiter hat keinen disziplinarischen Durchgriff auf die Mitarbeiter im Projekt, auch fachlich hat er in der Regel kein Weisungsrecht. Die Stabsfunktion sichert den Zugriff des Projektleiters auf den Auftraggeber, der sonst evtl. schwer erreichbar wäre. Die Aufgabe des Projektleiters beschränkt sich darauf, alle am Projekt beteiligten Personen über Stand und Fortschritt zu informieren, die Einhaltung der Projektpläne und Projektbudgets zu kontrollieren sowie die Projektergebnisse inhaltlich zu prüfen. Die eigentliche Projektverantwortung (Budgethoheit, Zielverantwortung, Mitarbeiterführung etc.) liegt weiterhin in den Fachabteilungen. Der Projektleiter hat lediglich eine informierende und koordinierende Funktion im Rahmen eines fachabteilungsübergreifenden Projektes. Er hat so eine Motivations-, Kontroll- und Koordinationsfunktion und seine Aufgabe liegt darin, ohne Weisungsrecht die Fachabteilungen zur Projektarbeit zu bewegen. Eine solche Projektkoordination ist zum Beispiel dann gegeben, wenn ein Projektmanager aus der Managementberatung mit der Projektleitung eines Implementierungsprojektes beauftragt wird, ohne ihm eine fachseitige Projektleitung zur Seite zu stellen und ohne ihn mit formalen Rechten innerhalb der Klientenorganisation auszustatten. Er kann dann lediglich „versuchen“, die Projektmitarbeiter aus dem Unternehmen für die Mitarbeit zu begeistern. Wenn er sich disziplinarisch durchsetzen will oder muss, dann bleibt nur der Weg über den Auftraggeber.


161

Eine Projektkoordination ist daher nur geeignet, wenn das Projektziel von den Fachabteilungen von starkem Eigeninteresse ist, wenn es fachlich sehr nahe an den Regelaufgaben liegt und vom Arbeitsaufwand neben den Regeltätigkeiten zu beherrschen ist. Eine Projektkoordination stellt hohe Anforderungen an den Projektmanager, der neben der fachlichen Qualifikation eine hohe persönliche Führungseignung aufweisen muss. Der Vorteil der Projektkoordination liegt auf der Hand. Der administrative Überbau ist relativ gering, das Personal ist flexibel einsetzbar, die Organisation ist sehr schnell einzurichten. So kann ein Managementberater schnell und unkompliziert mit der Umsetzung eines Themas beauftragt werden. Im Gegenzug besteht die Gefahr, dass die Projekte nicht mit dem entsprechenden Nachdruck verfolgt werden, da Verantwortung, Zuständigkeit und Weisungsrechte im Unternehmen auf verschiedene Personen verteilt sind. Die Gefahr, dass sich ein Managementberater nicht durchsetzen kann, ist relativ hoch. Für erfolgskritische Projekte ist diese Organisationsform daher nicht geeignet. Aus Sicht der Managementberatung ist diese Form der Einbindung eines Projektes sehr kritisch zu beurteilen, weil sie die notwendige „Integration des externen Faktors“ in die Projektarbeit nicht sicherstellt (vgl. hierzu S. 25 ff.). Dies bedeutet, dass die für das Projekt meist erfolgskritische Mitarbeit des Unternehmens in Umfang und Qualität nicht gewährleistet ist. Der Einfluss der Managementberatung auf den Erfolg des Projektes ist also wesentlich begrenzt. Da die Managementberatung jedoch am Erfolg des Projektes gemessen werden wird, stellt dies ein hohes Risiko dar, das nicht ignoriert werden darf. Entschließt sich eine Managementberatung trotz dieses Risikos dennoch zur Projektdurchführung in Form einer Projektkoordination, dann sollte im Rahmen des Angebots deutlich (und in jedem Fall schriftlich) hierauf hingewiesen werden. Zudem ist darauf zu achten, dass zumindest die Gremien der Projektorganisation (Steuerkreis/Lenkungsausschuss) eingerichtet werden, um auf diese Weise die Einbindung in das Unternehmen zu verbessern. Wird bei der Projektarbeit festgestellt, dass es zu Problemen bei der Einbeziehung der Mitarbeiter des Klientenunternehmens kommt, so muss der Projektleiter dies unverzüglich (und am besten auch schriftlich) dem Auftraggeber mitteilen, damit dieser im Rahmen seiner disziplinarischen Zuständigkeit eingreifen kann.

Matrix-Projektorganisation Die Matrix-Projektorganisation ist die Mischform der beiden oben beschriebenen Formen der Zuordnung der Projektmitglieder zum Projekt. Hierbei wird davon ausgegangen, dass ein Projekt fach- und abteilungsübergreifend ist. Die Unternehmensstruktur in Abteilungen bleibt unverändert bestehen und die Projekt-Mitarbeiter sind nach wie vor in die Linienorganisation eingebunden. Sie werden aber nun gleichzeitig einer Projektorganisation zugeordnet und unterstehen für die Projekttätigkeit dem Projektleiter bzw. den Projektleitern. Der beratungsseitige Projektleiter ist der Gesamtkoordinator für das Projekt und koordiniert den Personaleinsatz (in Absprache mit dem Linienvorgesetzten oder dem fachseitigen Projektleiter [falls vorhanden]), den Projektplan, das Budget etc. Es ist

162

Projektorganisation

sogar denkbar, dass ein Mitarbeiter neben der Linienfunktion in mehreren Projektorganisationen vertreten ist (Litke 1995, S. 78). Dies kommt in der Praxis sehr häufig vor. Insofern ähnelt dieser Ansatz dem Produktmanagement im Marketing. Hier hat der Produktmanager sozusagen die Rolle eines Projektmanagers für sein Produkt. Er koordiniert die Arbeit der anderen Fachabteilungen (etwa Produktentwicklung, Vertrieb, Produktion etc.), ohne einen disziplinarischen Zugriff zu besitzen. Die fachliche Hoheit für die einzelnen Tätigkeiten liegt in der Fachabteilung, das Produktmanagement kann jedoch Tätigkeiten initiieren (vgl. auch Rinza 1998, S. 79). Der Unterschied zwischen Projektkoordination und Matrix-Projektorganisation liegt in der festen Zuordnung von Ressourcen und der projektbezogenen Weisungsbefugnis des Projektmanagers gegenüber den Projektmitarbeitern. Dieser kann bestimmen, welche Aufgaben wann erledigt werden. In Absprache mit dem Abteilungsleiter oder der fachseitigen Projektleitung wird entschieden, wer die Aufgaben erledigt. Die inhaltlich/fachliche Steuerung, d. h. wie eine Aufgabe erledigt wird, liegt in der Fachabteilung, die auch das entsprechende Fachwissen besitzt. Disziplinarisch sind die Mitarbeiter dem Linienvorgesetzten unterstellt (Litke 1995, S. 79). Die folgende Abbildung gibt die Grundstruktur einer Matrix-Projektorganisation anschaulich wieder. Dunkel eingezeichnet ist hierbei die Projektorganisation, hell die Linienorganisation.

Geschäftsleitung

Abteilung A

Abteilung B

Abteilung C

Projektbezogene Anweisungen

Projektleiter 1

Projektleiter 2 Disziplinarische Zuordnung, funktionsbezogene Anweisungen

Quelle: Litke 1995, S. 78, mit geringen Änderungen Abbildung 67: Beispielhafte Darstellung einer Matrix-Projektorganisation

Die Aufgabenteilung von beratungsseitiger Projektleitung und Klientenunternehmen ist in der Tabelle in Abbildung 68 nochmals aufgeführt. Hierbei handelt es sich um eine grobe Kompetenzabgrenzung, die im Einzelfall entsprechend mit Leben gefüllt werden muss.


Verantwortung

beratungsseitige Projektleitung

fachseitige Projektleitung

Aufgabenteilung erfolgt je nach Projekt individuell

163

Abteilungsleitung (Linienverantwortung)

Was

Verantwortung und Kompetenz

Mitsprache

Wann

Verantwortung und Kompetenz

Mitsprache

Durch wen

Vereinbarung im Rahmen der Projektplanung

Vereinbarung im Rahmen der Projektplanung

Wie

Mitsprache

Bestimmung

In Anlehnung an Rinza (1998), S. 79 Abbildung 68: Grobe Kompetenzabgrenzung in der Matrix-Projektorganisation

Die Matrix-Projektorganisation ist sehr verbreitet. Der Vorteil liegt darin, dass die Mitarbeiter weiterhin ihren Regeltätigkeiten nachgehen können. Eine vertraglich problematische neue Zuordnung von Mitarbeitern ist nicht notwendig, auch ist nach Projektende klar, wo die Mitarbeiter arbeiten werden. Die Fachabteilungen mit ihren Kenntnissen bleiben bestehen und der Personaleinsatz kann flexibel gehandhabt werden. Durch die parallele Arbeit an Projekt und Regelaufgabe können Ressourcen gespart werden, und die Akzeptanz für das Projektergebnis wird in den Fachabteilungen durch die aktive Mitarbeit gestärkt. Im Projekt eingesetzt werden von der Fachseite her also Teilzeit-Projektmitglieder. Dies sind Mitarbeiter, die zu einem bestimmten Prozentsatz ihrer Arbeitszeit am Projekt mitarbeiten und den Rest ihrer Arbeitszeit ihrer Regelaufgabe nachgehen. Üblich ist hierbei ein Projekteinsatz von 20 bis 70 %. Bei diesen Mitarbeitern taucht die Problematik auf, dass falsche Kapazitätsplanung auf Seiten des Projektes oder der Regeltätigkeit dazu führen kann, dass die zeitliche Fähigkeit zur Mitarbeit eingeschränkt ist. Von daher ist beim Projektbeginn genau zu definieren, zu wie viel Prozent der Mitarbeiter zur Verfügung steht – und idealerweise ist schon zu definieren, zu welchen Zeiten er für das Projekt arbeitet. Es ist in der Praxis leider nicht unüblich, die Mitarbeiter zu „überbuchen“, d. h. zu mehr als 100 % mit Aufgaben zu versehen. Dies wird dadurch gefördert, dass der Linienvorgesetzte oft die Belastung im Projekt nicht kennt und umgekehrt. Zudem wird die Bedeutung der Projektarbeit oft unterschätzt, und es werden willkürliche Kürzungen der einsetzbaren Arbeitskraft vorgenommen. Durch die Besetzung des Steuerkreises mit den Linienvorgesetzten der Projektmitarbeiter kann dieses Problem reduziert werden. Nachteilig bei einer Matrix-Projektorganisation ist die Komplexität, die durch Einführen einer parallelen Organisation entsteht. Dies ist für die einzelnen Mitarbeiter schwierig und auch für die Vorgesetzten. Der Mitarbeiter erhält fachliche Weisungen für die Regeltätigkeit vom Linienvorgesetzten und projektbezogene Weisungen vom Projektleiter. Für die Vorge-

164

Projektorganisation

setzten ist es wiederum problematisch, dass sie sich nicht sicher sein können, welche Arbeitsbelastung der Mitarbeiter gerade hat. Dies kann zu Konflikten führen, die die Arbeit erschweren. Beispielsweise mussten wir bei einigen Projekten, die eine IT-Umsetzung beinhalteten, feststellen, dass die Ziele der beteiligten IT-Mitarbeiter und deren Management von den Zielen des Projektes abwichen. Die aus Sicht der IT-Abteilung erstrebenswerte Endsituation war durch den gerechtfertigen Wunsch nach einheitlichen Systemen und einfachen Lösungen geprägt, während die das Projekt initiierenden Fachabteilungen (wie etwa der Vertrieb), komplexe und individuelle Lösungen forderten, die den ebenfalls berechtigten Wünschen nach kundenindividuellen Lösungen Rechnung tragen sollten. Nur wenn Projektmanagement und Leitung der Linienfunktion harmonisch zusammenarbeiten, kann ein solcher Widerspruch frühzeitig aufgelöst werden. Dies stellt jedoch Anforderungen an beide Leitungsfunktionen. Der Linienmanager muss Macht abgeben und der Projektmanager muss akzeptieren, dass er in der Projektleitung nicht unabhängig vom Linienmanager ist. Durch eindeutig formulierte Ziele und insbesondere durch klare, einheitliche Anweisungen der jeweiligen Vorgesetzten der Führungskräfte können diese Konflikte vermieden werden. Leider ist es jedoch häufig so, dass die Konflikte auf den oberen Ebenen nicht ausgetragen werden und so zu Problemen für die Mitarbeiter führen, die verschiedene Zielvorgaben aus Linien- und Projektorganisation erhalten, die sie dann lösen müssen. Eine Matrix-Projektorganisation ist für fast alle Projekte geeignet. Lediglich Projekte, die aufgrund ihrer Aufgaben Vollzeit-Mitarbeiter benötigen, können in einer Matrix-Organisation nicht abgewickelt werden. Inhaltlich ist einzuschränken, dass Projekte, die radikale Änderungen oder sogar Einschnitte in den Fachabteilungen nach sich ziehen, schwer mit Mitarbeitern aus diesen Bereichen durchzuführen sind. Hierbei sollte dann auf eine reine Projektorganisation zurückgegriffen werden. Die dargestellten Formen der organisatorischen Einbindung der Projektmitarbeiter (reine Projektorganisation, Projektkoordination und Matrix-Projektorganisation) besitzen Vor- und Nachteile, die sie mal mehr, mal weniger geeignet erscheinen lassen. Sie stehen sich jedoch nicht als sich ausschließende Alternativen gegenüber, sondern können in unterschiedlichen Projektphasen nacheinander gebildet werden. So ist es möglich, die Projektorganisationsform im Laufe eines Projektes zu wechseln. Dies kann notwendig sein, wenn sich die Projektcharakteristika während des Projektverlaufs ändern (vgl. Abschnitt 1.6 ab S. 44). Die folgende Abbildung 69 gibt hierfür ein Beispiel:


165

Phase

Form der Projektorganisation

Begründung

Akquise

Projektkoordination (kleines Akquiseteam der Managementberatung; Fachseite nur als Informationslieferant)

Einsatz eines festen, großen Teams aufgrund der Unsicherheit der Projektdurchführung auf Seiten der Managementberatung nicht sinnvoll. Kreativität und Ideenfindung sind wichtig, daher Einbindung möglichst vieler Experten.

Definition

Projektkoordination (Projektteam der Managementberatung mit Diskussion und Abstimmung mit dem Klientenunternehmen)

Die Durchführung des Projekts ist relativ sicher, es muss aber noch genau definiert werden. Daher kann das Projektteam der Managementberatung eingesetzt werden. Da die eigentliche Projektdurchführung noch nicht gestartet ist, erfolgt keine festere Einbindung der Fachseite.

Planung

Projektkoordination (Projektteam der Managementberatung mit Experten aus dem Klientenunternehmen)

Eine hohe interdisziplinäre Zusammenarbeit ist notwendig, jedoch ist die Projektdurchführung noch nicht gestartet. Es werden Experten der Fachseite benötigt, die Planung selbst liegt jedoch bei der Managementberatung.

Start

Matrix-Projektorganisation

Die Aufgaben müssen nun fest zugewiesen werden, da im Projektstart eine Verbindlichkeit erzielt werden muss, wer was macht.

Durchführung

Reine Projektorganisation

Wenn in der Durchführung eine volle Konzentration auf einzelne Aufgaben notwendig ist (wegen Bedeutung, Komplexität oder Widerständen), dann kann zu einer reinen Projektorganisation übergegangen werden.

Abschluss

Reine Projektorganisation und Übergang zur Linienorganisation

Projektdokumentation und Abschluss sollten durch das Projektteam der Projektdurchführung erfolgen. Die Erprobung über den Wirkbetrieb findet in der Linienorganisation statt. Ggf. ist hierbei eine lose Zuordnung von Projektteilnehmern über eine Projektkoordination sinnvoll, um die Erfahrung der Projektteilnehmer weiter nutzen zu können.

Ggf. kann bei einer Erprobung eine Projektkoordination weitergeführt werden

In Anlehnung an Litke (1995, S. 83) Abbildung 69: Beispiel für einen Wechsel der Projektorganisation während des Projektablaufs

166

Projektorganisation

Wichtig in jeder Projektorganisation ist, dass das Top-Management namentlich hinter dem Projekt steht. Dieses sorgt dafür, dass Widerstände schneller beseitigt werden können und eine Konfliktlösungsinstanz besteht.

4.4

Stakeholder

Der nächste Abschnitt dieses Buches befasst sich mit einer Gruppe von Personen, die formal nicht in die Projektorganisation eingebunden sein müssen, die jedoch faktisch eine hohe Bedeutung für das Projekt besitzen. Dies sind die so genannten Stakeholder. Stakeholder sind Personen, die einen Einfluss auf den Projekterfolg und ein Interesse am Projektverlauf und -ergebnis besitzen (vgl. Maylor 1999, S. 11). Dies ist nicht auf die Projektteilnehmer beschränkt, sondern kann darüber hinaus viele Personen im und außerhalb des Unternehmens betreffen. Ignoriert man diese Personen im Projekt, so besteht die Gefahr, dass sie sich gegen das Projekt stellen und ihren Einfluss gegen das Projektergebnis geltend machen. Beispielsweise kann dies der Vertrieb sein, wenn Call-Center-Kosten durch eine Prozessoptimierung gesenkt werden sollen. Auch wenn der Vertrieb nicht für den Betrieb der Call Center zuständig ist, hat er doch ein großes Interesse am Funktionieren dieser Einheiten, über die ein Teil der Kundenkommunikation an das Unternehmen herangeführt wird. Es ist also zu erwarten, dass der Vertrieb darauf achten wird, dass eine Lösung gefunden wird, die auch seinen Anforderungen Rechnung trägt. Ein Stakeholder kann aber beispielsweise auch eine ehemalige Führungskraft eines Bereiches sein, die inzwischen an einer anderen Stelle im Unternehmen arbeitet. Aufgrund der früheren Tätigkeit ist es möglich, dass die Person sich für Veränderungen im ehemaligen Bereich interessiert. Trotz fehlender formaler Zuständigkeit kann diese Person aufgrund der guten Kontakte im bisherigen Bereich Einfluss auf dort laufende Projekte nehmen. Stakeholder-Management beschreibt den geplanten und zielgerichteten Umgang mit diesen Personen (den Stakeholdern), um sie im Sinne des Projekterfolges zu beeinflussen.

Stakeholder sind in einem weit gefassten Sinne Kunden des Projekts. Zwar zahlen sie nicht unbedingt für die Projektdurchführung (auch das ist direkt oder indirekt natürlich möglich), sie werden aber mit dem Projektergebnis und -verlauf konfrontiert und dies hat einen Einfluss auf sie. Ziel des Projektes sollte es also grundsätzlich sein, die Stakeholder zufrieden zu stellen (Maylor 1999, S. 48). Die Stakeholder-Zufriedenheit soll entsprechend zu einer Unterstützung des Projektes durch die Stakeholder führen. Oft ist es zu beobachten, dass Stakehol-

Stakeholder

167

der unzufrieden sind, weil sie nicht gefragt und einbezogen wurden, und nicht, weil das Projektergebnis nicht in ihrem Sinne ist. Ihr Interesse am Projektergebnis oder -verlauf wird nicht befriedigt und allein dies kann zu Unzufriedenheit führen. In einem Projekt kann man daher in der Regel nicht zu viel kommunizieren. Im Zweifel ist es besser, zu viele als zu wenige Personen zu informieren. Grundsätzlich gilt darüber hinaus als „Daumenregel“: Stakeholder, deren aktive Mitarbeit für den Projekterfolg notwendig ist, sollten in der Projektorganisation verankert sein. Sie müssen von Anfang an über das Projekt informiert sein und die geplante Vorgehensweise mitgestalten. Stakeholder, die durch das Ergebnis mittelbar oder direkt beeinflusst werden (etwa durch neu eingeführte Systeme, Kostensenkungen in anderen Bereichen), müssen frühzeitig informiert werden und ihre Akzeptanz für die Vorgehensweise muss sichergestellt werden.

Eine Methode, um keinen Stakeholder zu vergessen, kann die Anfertigung einer StakeholderMap sein (vgl. MCSG 2001). Zur Erstellung einer Stakeholder-Map geht man wie folgt vor: a)

Erstellung einer Liste aller möglicher Stakeholder (hierzu muss das Projektziel klar feststehen, vorher ist dies natürlich nicht möglich).

b)

Klärung der Frage, welche Reaktion von den Stakeholdern jeweils wahrscheinlich zu erwarten ist: Behinderung des Projektes oder sogar Verhinderung? Förderung?

Die mögliche Art der Einflussnahme des Stakeholders auf das Projekt sollte diskutiert und dokumentiert werden. Ebenso die (vermutete) Anforderung des Stakeholders an das Projekt. Es ist wichtig zu verstehen, ob der Stakeholder hierbei eigene Ziele (Individualziele) verfolgt oder ob Unternehmensziele im Vordergrund stehen. Im Marketing verwendet man auf Kunden bezogen den Satz „What’s in it for me?“. Dies gilt ebenso für Stakeholder. Es muss für jeden Stakeholder bekannt sein, welche Anforderungen dieser an das Projekt aus seiner individuellen Situation heraus hat. Dies können sowohl rein inhaltlich sachliche Anforderungen sein, die sich aus seiner Aufgabe im Unternehmen ergeben, es können jedoch auch persönliche oder emotionale Anforderungen sein. Hierbei ist die Kenntnis des Unternehmens von großer Bedeutung, denn zu erwartende Reaktionen ergeben sich oft aus der Historie oder aus informellen Beziehungen heraus. Aus Sicht der Managementberatung ist hier die Einbeziehung eines (vertrauenswürdigen) „Insiders“ sehr wichtig. Dies kann beispielsweise die fachseitige Projektleitung sein oder auch der Auftraggeber selbst. c)

Formulierung der möglichen Methoden, um den Stakeholder zufrieden zu stellen. Es ist also für jeden Stakeholder aufgrund seiner Anforderungen zu überlegen, was man machen kann, um diesen für das Projekt zu gewinnen. Dies umfasst die Dimensionen:

168

Projektorganisation

Inhaltliche Anforderungen an das Ergebnis. Also die Frage, wie evtl. das geplante Projektergebnis abgeändert werden kann, um den Anforderungen des Stakeholders entgegenzukommen. Inhaltliche Anforderungen an das Vorgehen. Dies ist die Frage, wie der Weg zur Erreichung des Ergebnisses abgeändert werden kann, um den Stakeholder für die Projektunterstützung zu gewinnen. Überzeugung des Stakeholders. Vielleicht ist es sogar möglich, den Stakeholder von den Vorteilen des Projektes zu überzeugen. In diesem Falle bietet es sich an, einen gesonderten Termin mit diesem Stakeholder zu vereinbaren und ihn in das Projekt „einzuweihen“ und die Vorzüge der Planung zu erläutern. Organisatorische Anforderungen. Mangelnde Information und Möglichkeit der Einflussnahme erzeugt Unsicherheit, die wiederum zur Ablehnung des Projektes führen kann. Zudem kann es ein Anreiz sein, in der Projektorganisation vertreten zu sein, um seinen gewünschten oder tatsächlichen Status zu stützen. Partizipation am Projekt bzw. Integration in das Projekt bzw. die Projektgremien wären in diesem Falle die geeigneten Maßnahmen zur Erlangung von Stakeholder-Zufriedenheit. Anforderungen an die Kommunikation. Eine schwächere Variante des oben genannten Punktes zum Abbau von Unsicherheit ist die Information des Stakeholders. Die Information versetzt den Stakeholder in die Lage, bei Bedarf in das Projektgeschehen eingreifen zu können.

d)

Zuletzt erfolgen die Bewertung der Alternativen und Auswahl der Vorgehensweise je Stakeholder und Zuordnung einer Verantwortlichkeit für den Stakeholder im Projekt. Bei der Bewertung ist abzuwägen zwischen Aufwand, Kosten bzw. Einschränkung der Zielerreichung im Rahmen des Stakeholder-Managements im Verhältnis zu dem hierdurch erwarteten Nutzen. Bei Managementberatungsprojekten wird es aufgrund der Bedeutung des Projektes kaum möglich sein, immer alle Stakeholder zufrieden zu stellen. Das Stakeholder-Management hilft jedoch bei der Entscheidung, wo man sinnvollerweise auf die Stakeholder eingeht, um das Projektziel insgesamt besser zu erreichen, und wo ein Eingehen auf die Stakeholder dem Projektziel so weit entgegensteht, dass es kontraproduktiv ist.

Punkt a) der oben aufgeführten Vorgehensweise (Erstellung einer Liste aller Stakeholder) kann man auch graphisch umsetzen, wie in Abbildung 70 dargestellt. Hierbei kann man anhand der Ergebnisse aus b) (Klärung der Frage, welche Reaktion zu erwarten ist) auch eine Priorisierung vornehmen.

Stakeholder

169

Betriebsrat Presse

ProjektMitarbeiter

Vorstand

Auftraggeber

Projektziel

Controlling ITAbteilung

Darstellungsmöglichkeiten: Gruppierung von Stakeholdern mit ähnlichen Anforderungen Stakeholder mit großem Einfluss näher an das Projekt einzeichnen Stakeholder mit großem Interesse größer darstellen

In Anlehnung an MZSG (2001) Abbildung 70: Stakeholder-Map für Projekte

Portny (2001, S. 172 f.) schlägt vor, beim Aufstellen der Stakeholder-Liste nach Personengruppen vorzugehen, um so niemanden zu vergessen. Er verwendet hierbei folgende Struktur: Intern (im Unternehmen)

Vorstand/Geschäftsführung Auftraggeber Projektmanager Teammitglieder Regelmäßig an Projekten beteiligte Mitarbeiter im Unternehmen (meist in Querschnittsbereichen wie Personal, Finanzen, Controlling, Vertrieb etc.). Diese können als Supporter oft aktiv am Projekterfolg mitarbeiten. Personen, die für das Projekt benötigt werden Extern (außerhalb des Unternehmens)

Kunden und Klienten (Anwender) Kooperationspartner Zulieferer, Verkäufer und Auftragnehmer Behörden Fachverbände Öffentlichkeit

Eine solche Liste kann zur Strukturierung sinnvoll sein, darf und kann jedoch das eigene Nachdenken nicht ersetzen.

170

Projektorganisation

In größeren Projekten kann es auch sinnvoll sein, für die einzelnen in der Projektorganisation aufgeführten Personen eine Stakeholder-Map zu erstellen, beispielsweise getrennt für Projektmanager, Auftraggeber etc. Dies kann – da die Personen unterschiedliche Stakeholder haben – einen Informationsgewinn bedeuten. Hilfreich kann es auch sein, die verschiedenen Rollen, die Stakeholder einnehmen können, grafisch zu trennen:

Neutrale

Unterstützer

Projekt

Ablehner

In Anlehnung an MZSG (2001) Abbildung 71: Stakeholder-Rollen auf der Stakeholder-Map

Es sein nochmals erwähnt, dass beim Aufstellen der Liste bzw. bei der grafischen Darstellung zu beachten ist, dass nicht nur formelle Beziehungen und formeller Einfluss wichtig sind, sondern insbesondere auch informelle Beziehungen und Macht. In einem Projekt haben wir beispielsweise einmal eine Führungskraft mit in den Lenkungsausschuss aufgenommen, die formal gesehen für das Thema nicht zuständig war. Da wir aber wussten, dass das Thema ein Steckenpferd dieser Person war und dass sie mit dem Vorstandsvorsitzenden hierüber ab und zu spricht, erschien es uns ratsam, sie in der Projektorganisation zu verankern. Dies war vermutlich auch richtig, denn sie hätte ein Projektergebnis, das ohne sie zustande gekommen wäre, sicherlich eher negativ bewertet – und aufgrund ihres Einflusses hätte dies das gesamte Projekt gefährdet. Die weiteren Schritte können der Übersichtlichkeit halber in tabellarischer Form dargestellt werden. Dies ist für ein hypothetisches Beispiel zum Bau eines Rechenzentrums in der folgenden Tabelle geschehen (siehe Abbildung 72). Hierbei sind verworfene Alternativen mit (–) gekennzeichnet, angenommene mit (+). Der Übersichtlichkeit halber sollten in einer endgültigen Version lediglich die Aktionen aufgeführt sein, die tatsächlich verfolgt werden. Diese

Stakeholder

171

müssen dann mit Verantwortlichkeiten und Zuständigkeiten versehen werden. Hierbei handelt es sich natürlich um eine streng vertrauliche Übersicht, die den enthaltenen Stakeholdern keinesfalls zugänglich gemacht werden darf.

Betriebsrat

Presse

Einfluss

kann Umsetzung durch Blockierung im EDV-Ausschuss komplett verhindern, ggf. verzögern

negative Berichterstattung möglich

Anforderung

Status quo wahren bzgl. Arbeitszeiten und Gehalt

ständige Information, um berichten zu können

Inhaltliche

keine neuenTarifmodelle (–) keine personenbezogene

keine

Anforderung an Projektziel

Datenspeicherung (+) Weiterbeschäftigung der

bisherigen Mitarbeiter (+) Inhaltliche

Anforderung an Projektverlauf

Notwendige

Überzeugung

keine Überstunden (–) ständige Information des

Information

Betriebsrats, damit dieser den Mitarbeitern Auskunft geben kann (+) Klarstellen der Notwendigkeit

der Änderungen (+) Alternativen transparent

machen (+) Organisatorische

Anforderungen (Partizipation/Integration) Anforderungen an

die Kommunikation (Information)

Assoziiertes Mitglied im

keine

Steuerkreis (+) Assoziiertes Mitglied im Lenkungsausschuss (–) auf den Verteiler für Projekt-

wöchentliche Statusberichte

gruppen-Statusberichte aufnehmen (+) auf Verteiler der Lenkungsausschuss-Unterlagen setzen (–)

monatliche Statusberichte (+) Pressemappen (+) Spezielle Internetseite mit

(–)

Downloads für Journalisten (+)

Abbildung 72: Tabelle zur Stakeholder-Map (Beispiel)

Es ist Aufgabe des Projektmanagers, die Stakeholder-Map zu erstellen. Allerdings kann er diese nicht allein aufstellen, sondern im Team mit seinen Projektmitarbeitern, ausgewählten Vertretern der Fachseite und ggf. auch mit bereits identifizierten Stakeholdern, wenn diese zu

172

Projektorganisation

den Unterstützern des Projektes gehören. Auch kann der Projektplan hilfreich sein, Stakeholder in späteren Projektphasen zu identifizieren. Eine solch formale Stakeholder-Map würde bei kritischeren Projekten aufgestellt werden, in kleineren Projekten würde man evtl. nur die Liste der Stakeholder erstellen und dann in einer Kreativrunde überlegen, wie man mit diesen Personen umgeht.

Praxisbox 18: Stakeholdermanagement Stakeholdermanagement im Inhouse Consulting beginnt mit einer Analyse möglicher Stakeholder. Bereits bei dieser ersten Analyse (in der Planungsphase des Projektes) werden die Stakeholder selektiert, die in der weiteren Projektplanung berücksichtigt werden. Wie diese berücksichtigt werden, wird aufgrund einer Basisklassifikation entschieden. Diese Basisklassifikation erfolgt anhand von zwei Kriterien. Darunter fallen die Macht, die ein Stakeholder innerhalb der Organisation besitzt, und der vermutete Willen des Stakeholders, diese Macht einzusetzen: high Champion

Coach

Manage

Watch Terrorist

Power within organization

top priority

Terminator Follower

Silent

Ignore Nuisance

Utilize Timewaster

low low

high Willingness to engage in project

Pro Project

Legend Contra Project

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 73: Basisklassifikation im Stakeholdermanagement Durch die Klassifikation ergeben sich vier Handlungsfelder: Manage (aktives Management des Stakeholders). Dies erfolgt bei Stakeholdern mit der höchsten Priorität, d. h. solchen, die über eine große Macht verfügen und von denen vermutet wird, dass sie ihren Einfluss auf das Projekt auch ausüben werden. Dies sind die so genannten „Champions“ für das Projekt, ohne die das Projekt nicht erfolgreich sein wird. Stellen sie sich jedoch gegen das Projekt, dann können sie dies auch beenden („Terminator“). Manage bedeutet dabei, dass die Ziele, die diese Stakeholder verfolgen, genauer analysiert werden. Darauf aufbauend wird ein Erwartungsmanagement

Stakeholder

173

in Bezug auf das Projekt durchgeführt. Die Projektziele und das Vorgehen werden den Stakeholdern genau erläutert. Ihre Stellung zum Projekt (Ablehnung, Zustimmung, ggf. einzelne Vorbehalte oder Anforderungen) wird ermittelt, und es wird – auch unter Anpassung von Projektziel und -vorgehensweise – versucht, die Zustimmung dieser Stakeholder zu gewinnen. Idealerweise gelingt es auch, über die Macht dieser Stakeholder weitere Zustimmung im Unternehmen für das Projekt zu generieren. Watch (Verständnis). Bei Stakeholdern, die über eine hohe Macht verfügen, von denen jedoch nicht ausgegangen wird, dass sie diese in Bezug auf das Projekt ausüben, wird eine aktive Aufklärungspolitik betrieben. Diesen Stakeholdern wird das Projekt erläutert und es wird so Erwartungsmanagement betrieben. Auch hier wird natürlich versucht, mögliche Vorbehalte des Stakeholders zu verstehen. Wenn es nötig erscheint, weil man ggf. Gefahr läuft, dass der Stakeholder seine Macht doch einsetzt, um seinen Vorbehalten Gehör zu verschaffen, wird das Projekt abgeändert. Im weiteren Projektverlauf wird auf diese Stakeholder besonders geachtet (watch), da sie sich vom wohlwollenden Mentor eines Projektes („Coach“) zu so genannten „Terrorists“ entwickeln können, wenn sie ihren Einfluss in Gremien vereinzelt gezielt gegen das Projekt einsetzen. Über ihre Macht können sie so ein Projekt gefährden. Die Akzeptanz dieser Personen ist daher ebenfalls sehr wichtig und es muss versucht werden, auf die Bedürfnisse dieser Personen einzugehen. Utilize (Nutzen). Personen mit begrenztem Einfluss, die diesen im Sinne des Projektes einsetzten wollen, sollten genutzt werden. Sie sind daher zu informieren und in das Projekt einzubinden. Wenn dies gut gelingt, können sie als „Follower“ sehr nützlich für das Projekt sein. Stellen sie sich gegen das Projekt, werden sie dies aufgrund ihres begrenzten Einflusses zwar nicht gesamt gefährden können, sorgen aber für Verzögerungen („Time waster“). Im Umgang mit diesem Stakeholderkreis ist es insbesondere wichtig, diese durch Einbeziehung, Information und Kommunikation auf die Ziele des Projektes auszurichten, damit es nicht zu Reibungsverlusten kommt. Ignore (Ignorieren). Personen ohne Einfluss und Interesse am Projekt müssen nicht im Rahmen des Stakeholdermanagements beachtet werden. Entweder spielen sie keine Rolle („Silent“) oder sie können schlechtestenfalls zu harmlosen Ärgerern („Nuisance“) werden. In der Projektplanung wird nun für die einzelnen Stakeholder festgelegt, welche Maßnahmen für die einzelnen Stakeholder notwendig sind. D. h., es werden mit allen Stakeholdern, die unter „Manage“ und „Watch“ fallen, Gespräche geführt und für die anderen wird festgelegt, wie diese einbezogen und informiert werden. Um diese Aktivitäten geplant durchführen und kontrollieren zu können, erfolgt die Dokumentation in einer ersten Planungstabelle. Sind die Informations- und Abstimmungsgespräche mit allen Stakeholdern geführt, dann wird eine Übersicht erstellt, welche Probleme bezüglich des Projektzieles und -vorgehens die einzelnen Stakeholder angemeldet haben. Diese werden erneut in einer Tabelle zusammengefasst, um so besser eine Übersicht zu erlangen und Wechselwirkungen erkennen zu können (siehe Abbildung 74).

174

Projektorganisation

Issue

Stakeholder Priority

Disagreement on project Head of Steering A Committee priorities and time plan – would rather like to see faster results with a reduced geographic scope

Proposed Activity Re-discuss priorities

Status WIP

Due Date 1.4.

Responsible Hermann Müller

What issue do we have with whom at what priority?

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 74: Stakeholdermanagement-Tabelle Anhand dieser Übersicht wird nun geplant, welche Maßnahmen („proposed activities“) jetzt noch notwendig sind, damit das Projekt von den wichtigen Stakeholdern unterstützt wird. Durch diese Vorgehensweise stellt das Inhouse Consulting sicher, dass ein Projekt nicht ohne Unterstützung der relevanten Stakeholder startet, bzw. man weiß zumindest, welche Stakeholder noch welche Probleme mit dem Projekt haben.

Stakeholder

175

5 Projektcontrolling

Der Begriff Projektcontrolling ist nicht leicht zu definieren. Dies liegt daran, dass der Begriff Controlling selbst viele verschiedene Auslegungen hat und sich seine Bedeutung im Laufe der Zeit zudem ständig verändert (Weber 1992, S. 169). In der aktuellen Sichtweise des planungs- und kontrollorientierten Controllings befasst sich dies hauptsächlich mit der Planung und Kontrolle sowie dem zugehörigen Informationssystem im Unternehmen (Küpper 1995, S. 12). Modernes Controlling ist also nicht nur Kontrolle, sondern geht weit darüber hinaus. Es ist ein Führungsinstrument, welches den unternehmerischen Entscheidungs- und Steuerungsprozess durch zielgerichtete Informationserarbeitung und -verarbeitung unterstützt (Stolorz 1997, S. 3). Diese Sichtweise impliziert, dass die bereits in diesem Buch angesprochenen Planungsinstrumente des Projektmanagements Teil eines Controllings sind. Konsequenterweise werden diese deshalb in einigen Publikationen auch dem Controlling von Projekten zugeordnet (etwa bei Blazek/Zillmer 2001). Für unsere Zwecke soll hier jedoch der etwas traditionellere Controlling-Begriff verwendet werden, der sich auf die Kontrolle im Sinne einer Überwachung der Planung bezieht. Dies ermöglicht eine eindeutige Trennung von den Aufgaben des klassischen Projektmanagements. Enge Definition des Projektcontrollings: Projektcontrolling ist die Ermittlung und Aufbereitung von Informationen zur Kontrolle der Einhaltung der Projektplanung, der Steuerung des Projektverlaufs gemäß der Planung. Synonym kann man auch von Projektkontrolle sprechen.

In der Hauptsache lässt sich der Erfolg des Projektfortschritts anhand von vier Aspekten kontrollieren: Einhaltung des Kosten-Budgets Einhaltung des Personaleinsatz-Plans Einhaltung des Zeitplans (Termine) Erreichung des Ergebnisses (Qualitätskontrolle)

Die Kontrolle eines Projektes ist wichtig, da die Praxis leider immer wieder zeigt, dass Projektpläne zu optimistisch sind und den Herausforderungen der Realität nicht standhalten. Häufiger Fehler ist hierbei, dass kein Puffer für unvorhergesehene Ereignisse geplant wurde oder dass der Auftraggeber und Finanzier eine zu knappe Zeitvorgabe gegeben hat. Promi-

176

Projektcontrolling

nentes Beispiel für Letzteres ist der Fall „Toll Collect“, bei dem Experten im Vorhinein schon vor den Risiken gewarnt haben. Die Firmen, die nicht den Zuschlag erhalten haben, hatten wesentlich längere Entwicklungszeiträume geplant. Eine Überwachung der Planeinhaltung ist daher dringend geboten. Nur dann kann man wirkungsvoll steuernd in die Projektabwicklung eingreifen, wenn im Falle von Verzögerungen oder Budgetüberschreitungen schon rechtzeitig Informationen vorliegen. Allgemein wichtige Aspekte des Projekt-Controllings sind (vgl. Portny 2001, S. 225 ff.): Laufende zyklische Kontrolle der Planeinhaltung. Zu festen oder festgelegten Zeitpunkten trifft sich der Projektleiter mit den für die Projektdurchführung Verantwortlichen und spricht den Status durch. Auf Basis einer Statusbewertung des Projektes wird entschieden, ob Korrekturen am weiteren geplanten Verlauf des Projektes notwendig sind. Wenn ja, wird ein neuer Projektplan erstellt, der dann Gültigkeit hat. Eine solche zyklische Kontrolle sollte von Anfang an vereinbart werden und für alle gelten, damit die betroffenen Personen dies nicht als Misstrauen gegen ihre Leistungsfähigkeit empfinden.

Ein wirksames Instrument zur Institutionalisierung einer zyklischen Kontrolle ist die Verpflichtung für ausgewählte Mitarbeiter des Projektes, in regelmäßigen Zeitabständen oder zu bestimmten Anlässen Projekt-Statusreports abzugeben. In der Praxisbox 19 ist hierfür ein Beispiel aufgeführt. Wichtig ist es, einen Statusbericht kurz zu halten (eine Seite reicht in der Regel, das Beispiel des Inhouse Consulting ist sicherlich schon eine sehr umfangreiche Variante, die jedoch aufgrund ihrer hohen Strukturiertheit noch schnell auszufüllen ist). Ein kurzer Bericht hat zwei Vorteile: Zum einen erhöht dies maßgeblich die Akzeptanz eines Berichts, zum anderen spart es Zeit beim Verfassen und zwingt die Autoren dazu, die wesentlichen Punkte zu extrahieren und darzustellen. Schnelles Einleiten korrigierender Maßnahmen bei Abweichungen der Ist-Situation vom Plan bzw. dem Bericht oder der Erwartung von Schwierigkeiten. Ständige Information aller Verantwortlichen über den Stand des Projektes. Diese Information beinhaltet mindestens Berichte über folgende Aspekte:

Ergebnisse, Zwischenergebnisse Zeitplan, Einhaltung und weitere Prognose Ressourcenplan Probleme

Ressourcenplanung und Ressourcenverwendung sollten formalisiert werden. In größeren Projekten bietet es sich an, Änderungen in der Ressourcen- und Budgetplanung an die Freigabe durch den Projektleiter – oder bei größeren Änderungen sogar durch den Lenkungsausschuss – zu binden. Ohne Bestätigung der Ressourcenplanung darf kein Ressourceneinsatz erfolgen. Zur Kontrolle der Ressourcenverwendung sollten entsprechende Messsysteme eingerichtet werden. Dies sind etwa Zeiterfassungssysteme oder Kostenstellen, auf denen die entstandenen Projektkosten erfasst und gebucht werden. Einkaufende

Projektcontrolling Stakeholder

177

Stellen (Einkaufsabteilung) sollten über die zur Verfügung stehenden Budgets informiert werden, damit eine Überschreitung der Summen nicht möglich ist.

Praxisbox 19: Projektstatusbericht Im Inhouse Consulting berichtet jedes Projekt wöchentlich den Status an den für das Projekt zuständigen Partner. Dieser Status beinhaltet eine formale und eine inhaltliche Komponente. Die formale wird durch den Statusreport abgebildet. Es handelt sich also um eine beratungsinterne Reportinglinie, die unabhängig von den zusätzlich im Projekt vorhandenen Reportingstrukturen gegenüber Auftraggeber, Steuerkreis oder Lenkungsausschuss ist. Verantwortlich für den Bericht zeichnet der beratungsseitige Projektleiter, der die Erstellung zwar an Consultants übertragen kann, jedoch die inhaltliche Verantwortung hierfür trägt. Die Abbildung 75 auf den folgenden drei Seiten zeigt das Template (die Vorlage) für diesen Bericht. Der Bericht wird in einem internen Statusmeeting mit dem Projektteam und dem zuständigen Projektpartner diskutiert und die nächsten Schritte werden besprochen. Muss dieses Abstimmungsmeeting aufgrund von räumlicher Trennung oder von Terminproblemen ausfallen, so erhält der Partner den Bericht per E-Mail und die Abstimmung erfolgt telefonisch. Das Template hat verschiedene Vorteile: Mithilfe des schriftlichen Berichts wird eine Verbindlichkeit des Reportings hergestellt. Die inhaltliche Komponente besteht aus der Vorstellung und Diskussion der Analyse, Hypothesen, Lösungskonzepte, Schlussfolgerung und Konsequenzen für die Fachseite. Dabei werden u. a. die Methode geprüft, die Ergebnisse hinterfragt, weitere Ideen entwickelt, Umsetzungsmöglichkeiten angedacht und Einsparungspotenziale nachgerechnet. Als Format werden hierfür meist Teamsitzungen gewählt. Die feste Struktur und die Verwendung der Ampeln erlauben es, die darin enthaltenen Informationen schnell aufzunehmen und die wichtigen Punkte rasch zu erkennen. Der Bericht ist so aufgebaut, dass nicht nur der Status berichtet wird, sondern es immer gleich notwendig ist, Maßnahmen bei Planabweichung zu entwickeln und vorzuschlagen bzw. einzuleiten. Diese werden idealerweise gleich mit Zuständigkeiten und Timing versehen.

178

Projektcontrolling


179

180

Projektcontrolling

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 75: Beispiel Projektstatusbericht


181

Die Struktur dieses Berichts soll im Folgenden kurz erläutert werden: Im Kopf des Berichts stehen die Bezugsdaten (Projekt, Phase, Datum, Autor etc.). Unter Punkt 1. gibt es einen Überblick über den Gesamtstatus nach dem im Projektmanagement verbreiteten Ampel-Prinzip. Grünes Licht bedeutet, dass das Projekt insgesamt grundsätzlich im Plan liegt, gelbes Licht bedeutet, dass es einige Verzögerungen, Kostenüberschreitungen oder negative Ergebnisabweichungen gibt, und rotes Licht bedeutet, dass das Projekt insgesamt gefährdet ist. Hierbei ist als Hilfe zum Ausfüllen eine Prozentskala beigefügt. Unter Punkt 2. wird das Erreichen der im Projektplan aufgeführten Milestones eingetragen. Unter Punkt 3. werden Probleme aufgeführt. Eine Grundregel des Projektmanagements ist es, dass Probleme nicht verdrängt oder verschleiert werden dürfen, sondern schnell offen angesprochen werden müssen. Nur so kann eine geeignete Lösung für die Probleme gefunden werden. Entsprechend werden in der Tabelle auch die vom Projektteam vorgeschlagenen Maßnahmen vermerkt bzw. auch, welche Entscheidungen aufgrund des Problems nun notwendig sind. Das Nicht-Anzeigen von Problemen mit großen Risiken für das Projekt oder die Organisation durch einen Projektleiter ist eine schwerwiegende Unterlassung. Es gilt der Grundsatz, dass Fehler gemacht werden können, jedoch muss man offen dazu stehen. Unter Punkt 4. werden die einzelnen vom Inhouse Consulting definierten „Project Success Factors“ berichtet. Dies sind Erfolgsfaktoren, deren Vorliegen die Voraussetzung für erfolgreiche Projektdurchführung ist. Durch die einzelne Prüfung dieser Faktoren wird gesehen, ob es ein Risiko für das Projekt gibt (zu den Projekterfolgsfaktoren siehe ausführlicher Abschnitt 1.4). Auch hier werden wie unter Punkt 3 nicht nur mögliche Probleme aufgeführt, sondern mit einer Begründung und den notwendigen Maßnahmen versehen. Unter Punkt 5. werden notwendige „Change Requests“ aufgeführt, d. h. notwendige Änderungen im so genannten Scope, dem Ergebnisumfang, die mit dem Auftraggeber vereinbart werden müssen (siehe hierzu Abschnitt 2.4). Diese sind wichtig, da sie Auswirkungen auf den weitern Projektverlauf haben und so auch die Kosten und den notwendigen Personaleinsatz auf Seiten der Beratung beeinflussen. Die Change Requests werden dann durch den zuständigen Partner mit dem Auftraggeber besprochen. Unter Punkt 6. werden die nächsten Schritte aufgeführt, damit der Partner weiß, was als nächstes im Projekt erledigt wird und er ggf. hier noch eingreifen kann bzw. informiert ist. Dies ist getrennt aufgeführt nach den noch offenen Milestones (unter Punkt 6.1) und den konkret anstehenden nächsten größeren Meetings (unter Punkt 6.2).

Für größere Projekte wird zudem teilweise die Einrichtung eines Projektmanagement-Informationssystems (PMIS) empfohlen. Ein Projektmanagement-Informationssystem dient der

182

Projektcontrolling

Erfassung, Analyse und Veröffentlichung von Informationen zum Projektstatus. Die Datenerfassung kann in großen Projekten dezentral geschehen, etwa an Projektstandorten in den USA, in Asien und Europa. Die Daten werden automatisch zusammengeführt und können zentral analysiert werden. Es ist nicht nur ein reines EDV-System (wie Microsoft Project in der Serverversion), sondern beinhaltet auch Regeln und Prozesse zur Datenerhebung, -pflege und -verwendung und kann von daher bei komplexen Koordinations- oder Top-Projekten (siehe Abbildung 3 auf S. 34) hilfreich sein.

5.1

Einhaltung des Kosten-Budgets

Die Kontrolle der Einhaltung des Kosten-Budgets kann auf Basis eines Plan-Ist-Vergleichs erfolgen (siehe zu diesem Abschnitt Blazek/Zillmer 2001, S. 136). Im einfachsten Fall werden die Ist-Daten mit den ursprünglichen Plan-Daten verglichen. Die Durchführung eines Plan-Ist-Vergleiches basiert grundsätzlich natürlich auf den jeweiligen Zahlen, die die Verantwortlichen erhoben haben und die ggf. im Projektmanagement-Informationssystem erfasst sind. Hier gilt der Grundsatz, dass die Analysen nur so gut wie die Daten sein können. Eine „saubere“ Datenerfassung sollte daher durch organisatorische Maßnahmen und feste Verantwortlichkeiten sichergestellt werden. Dargestellt werden kann ein solcher Vergleich tabellarisch oder in einer Abbildung. Die einfachste Möglichkeit ist die tabellarische Gegenüberstellung von Ursprungsplan und Ist-Situation. Dies erlaubt noch keine weitere Steuerung anhand der Daten, sondern beschränkt sich auf reines Reporting. Abbildung 76 gibt ein solches Reporting für ein Arbeitspaket wieder. Diese Form des Reportings berücksichtigt noch keinen Ausblick auf den weiteren Projektverlauf und ist daher nur bedingt tauglich, um tatsächlich steuernd einzugreifen. Um dies zu ermöglichen, wird in der Regel nicht nur ein Vergleich des Ist-Zustandes mit dem Ursprungsplan vorgenommen, sondern auch ein Vergleich des Plans mit einem Ausblick. Es gibt also zwei Vergleichsmaßstäbe: Der Ursprungsplan zu Projektbeginn wird quasi fixiert und nicht wieder angepasst. Er ist der Plan, gegen den die Ist-Daten verglichen werden. Der Forecast ist der Ausblick bis zum Projektende. Wenn im Laufe des Projektes die Planeinhaltung nicht mehr realistisch erscheint und es eine aktualisierte Erwartung gibt, die nicht mehr dem Plan entsprechen muss, so wird dieser Ausblick Forecast genannt. Er ist eine Prognose der Kosten aus heutiger Sicht bis zum Projektende. Der Forecast basiert auf den bisher angefallenen Ist-Werten und wird laufend oder periodisch fortgeschrieben. Er zeigt so, wie sich die laufenden Entscheidungen auf den Projektverlauf auswirken.


183

Projektnummer: Projektname: Stand (Datum): Kostenarten Personalkosten Sekretariat Teilprojekt 1 Teilprojekt 2 Teilprojekt 3 … Zwischensumme Sachkosten IT Telekommunikation Büromaterial PKW … Zwischensumme Sonstige Kosten Patentkosten …

Zwischensumme Summe

Arbeitspaket:

Plan

Abweichung Abweichung absolut in %

Ist 50.000 75.000 75.000 210.000

45.000 75.000 100.000 210500

-5.000 0 25.000 500

-10% 0% 33% 0%

410.000

430.500

20.500

5%

25.000 1000 500 20.000

35.000 1100 1000 10.000

10.000 100 500 -10.000

40% 10% 100% -50%

46.500

47.100

600

1%

1.200

1.200

0

0%

1.200 457.700

1.200 478.800

0 21.100

0% 5%

In Anlehnung an Blazek/Zillmer (2001), S. 137 Abbildung 76: Einfacher Plan-Ist-Vergleich

Ein Forecast ist sehr wichtig, da die reine Gegenüberstellung der Ist-Daten zu den Plan-Daten eines Zeitpunktes zeitliche Verschiebungen nur ungenügend abbilden kann. So kann es sein, dass sich zwar die Kosten bis zu einem Zeitpunkt noch im Rahmen des Plans für diesen Zeitpunkt bewegen, die Ergebnisse jedoch nicht erreicht wurden, so dass weitere und zusätzliche Kosten anfallen werden. Ein Forecast würde dies deutlich machen, der reine Plan-Ist-Vergleich nicht. Dieses allgemeine aus der Budgetierung und Budgetkontrolle von Unternehmen und Kostenstellen bekannte Vorgehen der Aufstellung eines Forecasts wird im Projektcontrolling entsprechend nicht nur auf die Kosten-Budgets angewandt, sondern findet auch für die weiteren Pläne (Zeit, Personal, Ergebnisse) Anwendung. Ein Beispiel mit Forecast wird in der Abbildung 77 dargestellt. Dieses Beispiel berücksichtigt nicht nur ein Arbeitspaket, sondern zeigt eine zusammengefasste Sicht aus der Perspektive des Gesamtprojektes.

184

Abbildung 77: Plan-Ist-Vergleich mit Forecast

Projektcontrolling


185

Die Gegenüberstellung erfolgt hierbei auf drei Ebenen: für den bisherigen Projektverlauf, für den zukünftig zu erwartenden Projektverlauf und für die Gesamtprojektzeit. Dies erlaubt eine klare Beurteilung des bisherigen Verlaufs und eine Prognose, wie unter Einbeziehung aller getroffenen Entscheidungen und eingeleiteten Maßnahmen der Projektverlauf (in puncto Kosten) aussehen wird sowie zu welchen Gesamtkosten dies führen wird. Eine solche Kontrolle setzt jedoch voraus, dass die Kosten der einzelnen Arbeitspakete geplant wurden. Ohne eine solche detaillierte Planung mit zeitlicher Zuordnung der Arbeitspakete lässt sich für einen Zeitpunkt im Projekt nicht sagen, wie der aktuelle Status ist, da ja sonst nur ein Gesamtplan existieren würde. Wichtiger Aspekt bei der Kontrolle ist, dass korrigierende Maßnahmen schnell geplant und auch dokumentiert werden. Dies hat Vorrang vor der Ursachenforschung, da diese in die Vergangenheit gerichtet ist und nicht wie die Maßnahmen in die Zukunft (Blazek/Zillmer 2001, S. 140). Zwar mag die Ursachenforschung zur Planung von Maßnahmen bedeutsam sein, sie sollte jedoch nur dann erfolgen, wenn es für die Zukunft sinnvoll ist. Zudem sollte die Energie in einem Projekt nicht auf Schuldzuweisungen verschwendet werden, sondern auf Problemlösungen. Bei länger laufenden Projekten macht es Sinn, die Kosten über einen Zeitstrahl zu verteilen. Basis wären dann Wochen oder Monate. Dies ist für die Liquiditätsplanung im Unternehmen wichtig. Eine solche Planung lässt sich dann auch entsprechend grafisch darstellen, wie in Abbildung 78 dargestellt. Diese Darstellung ist zwar auf den ersten Blick schnell zu verstehen, hat aber den Nachteil, dass sie in dieser Form keine Kostenstrukturen etwa nach Arbeitspaketen oder Kostenarten zeigt. Werden die Arbeitspakte beispielsweise in einer anderen zeitlichen Reihenfolge als geplant bearbeitet, ergeben sich Probleme in der Darstellung. Einen Ansatz für Erklärungen von Abweichungen kann sie also nicht geben und ist daher nur für einen schnellen ersten Überblick über die Gesamtsituation geeignet. Durch die leichte Verständlichkeit ist sie gut in Präsentationen einsetzbar. Ein Forecast ist in Abbildung 78 durch die gestrichelte Linie integriert. Für den weiteren Projektverlauf lassen sich aus diese Weise Abweichungen gut aufzeigen. Interessant für die Interpretation der Kostenabweichungen ist natürlich eine Analyse der Gründe, die hierfür ausschlaggebend sind. In der Produktion sind einfache Erklärungen für Kostenabweichungen Änderungen der Produktionsmenge oder Veränderungen in den Faktorkosten. Leider lassen sich Kostenabweichungen bei Managementberatungsprojekten in der Regel nicht so leicht erklären, da die erstellte Leistung im Projekt sehr individuell ist (die Menge also eher keine Rolle spielt) und die Faktorkosten (Kosten je Beratertag) oft vertraglich festgelegt sind. Eine Analyse muss daher individuell erfolgen und kann nicht einem hier vorgegebenen Schema folgen.

186

Projektcontrolling

160.000 140.000

Kosten in €

120.000 Plan

100.000

Ist

80.000

Forecast

60.000 40.000 20.000 0 1 2 3

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Woche

Quelle: Blazek/Zillmer 2001, S. 142, siehe auch Wolf/Mlekusch 1997, S. 173 Abbildung 78: Beispiel für einen grafischen Plan-Ist-Vergleich mit Forecast

5.2

Einhaltung des Personaleinsatz-Plans

Grundsätzlich gilt hier das Gleiche wie bei den Kosten. Der Plan wird dem Ist gegenübergestellt, dies kann tabellarisch und grafisch erfolgen (siehe hierzu Blazek/Hillmer 2001, S. 144ff.). Die tabellarische Darstellung erfolgt analog der Kostendarstellung – nur werden hier Personentage aufgeführt. Bei der grafischen Darstellung kann auf Arbeitslastdiagramme zurückgegriffen werden (vgl. Abschnitt 3.4.2 ab S. 110). Hierbei kann die mögliche Gesamtbelastung, die mögliche Auslastung sowie eine sich ergebende Überbelastung je Tag oder Woche ausgewiesen werden. Ein Beispiel hierzu ist in Abbildung 79 dargestellt. Die dunklen Balken geben hierbei an, dass der Mitarbeiter laut Plan zu 100% ausgelastet ist, die über die 100% hinausgehenden helleren Balken zeigen, dass der Projektplan schon eine Überlastung des Mitarbeiters vorsieht.

Einhaltung des Personaleinsatz-Plans

D

F

S

S

6. Okt '03 M

187

D

M

D

F

200%

100%

100%

100%

S

S

13. Okt '03 M

D

M

200%

100%

D

F

S

200%

180%

160%

140%

120%

100%

80%

60%

40%

20%

Benötigte Ressourceneinheiten:

Wegmann

Überlastet:

200%

Zugeteilt:

Quelle: Eigene Darstellung unter Verwendung von Microsoft Project Abbildung 79: Arbeitsbelastungsdiagramm mit Überlastung

Tage

8 7

Summe (Plan)

6

IST

5

Kapazität

4 3 2 1 0 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 Woche

In Anlehnung an Blazek/Zillmer (2001), S. 147 Abbildung 80: Arbeitsbelastungsdiagramm Plan-Ist-Vergleich

Interessant ist hierbei die mögliche Gegenüberstellung von Plan-Belastung und Ist-Belastung mit der tatsächlichen Verfügbarkeit des Mitarbeiters, wie sie in Abbildung 80 zu sehen ist. Auf diese Weise kann man feststellen, ob die Ressourcen gut genutzt wurden (in der Abbildung dadurch zu erkennen, ob die Balken, die die Plan-Belastung im Projekt angeben, die Kapazitätslinie erreichen). So kann man beispielsweise sehen, ob ein verfügbarer Mitarbeiter nicht für das Projekt eingesetzt wurde oder ob andererseits ein Projektmitarbeiter in der Planung vom Zeiteinsatz schon über seine Kapazität eingeplant wurde (wie in der Abbildung

188

Projektcontrolling

etwa in Kalenderwochen 38 und 39 zu sehen). Allerdings ist zu beachten, dass diese Darstellung keine Aussage über die tatsächliche Erledigung der Aufgaben macht, sondern nur angibt, wie viel Zeit für Tätigkeiten aufgewendet wurde. Inwieweit die Ressourcen gut genutzt wurden, kann auch durch die Berechnung einiger Kennzahlen nachgehalten werden. Dies sind: Bereitstellungsquote: Diese Kennzahl gibt an, wie viele Ressourcen (deren Einsatz dem Plan zugrunde lag) tatsächlich im Unternehmen bereitgestellt wurden.

geplante Ressourcen in PT u 100 Bereitstellungsquote bereitgestellte Ressourcen in PT Wurde der Plan etwa auf der Basis von 100 Personentagen (PT) erstellt, es wurden jedoch nur 75 Personentage zur Verfügung gestellt, so gibt die Bereitstellungsquote von 75 % an, dass nur 75 % der vereinbarten Ressourcen zur Verfügung standen. Diese Kennzahl ist wichtig um zu sehen, ob die Prämissen der Planung eingehalten wurden. Bereitgestellte Ressourcen zu eingesetzten Ressourcen = Einsatzquote. Diese Kennzahl gibt an, wie effizient der Ressourceneinsatz im Projekt erfolgte:

bereitgestellte Ressourcen in PT u 100 Einsatzquote eingesetzte Ressourcen in PT Wurden beispielsweise 100 Personentage bereitgestellt (d. h., die entsprechenden Mitarbeiter hätten eingesetzt werden können) und davon wurden real über die Zeiterfassung jedoch nur 90 auf das Projekt verbucht, so gibt die Einsatzquote von 90 % an, dass nur 90 % der vorhandenen Ressourcen auf das Projekt eingesetzt wurden, d. h. 10 % entweder nicht benötigt oder „verschenkt“ wurden. Bei Verzögerungen oder schlechter Personaleinsatzplanung kommt dies häufiger vor. Obwohl der notwendige Gesamtpersonaleinsatz unverändert hoch ist, können die bereitgestellten Ressourcen nicht eingesetzt werden, da die für ihre Tätigkeit notwendigen Vorarbeiten noch nicht abgeschlossen wurden oder ihnen schlichtweg nicht erklärt wird, was zu tun ist. Abweichungsgrad. Auch für das Controlling des Personaleinsatzes ist es natürlich möglich, einen Forecast zu integrieren, der den Gesamtpersonalbedarf bis zum Projektende hochrechnet. Als Kennzahl kann man nun berechnen, um wie viel Prozent der Forecast von der ursprünglichen Personalplanung abweicht:

Forecast Personaleinsatz in PT bis Projektende u 100 Plan Personaleinsatz in PT bis Projektende

Abweichungsgrad

Einfacher ist es natürlich, die absolute Abweichung in Personentagen zu berechnen, also anzugeben, welcher Mehreinsatz bisher (Ist versus Plan) nötig war, welcher Mehreinsatz noch notwendig sein wird (Plan versus Forecast für die noch kommende Zeit) bzw. insgesamt notwendig ist (Plan versus Forecast für das Gesamtprojekt).

Einhaltung des Zeitplans

5.3

189


Grundsätzlich kann auch die Prüfung der Einhaltung des Zeitplans (man spricht hier auch von Termincontrolling) nach der gleichen Logik erfolgen, nach der in den beiden vorherigen Kapiteln geprüft wurde, inwieweit das Kosten- und Zeitbudget eingehalten wurden. Es können also Vergleiche angestellt werden zwischen: Ist-Fortschritt im Projekt versus Plan Restlaufzeit lt. Plan versus Forecast Forecast für die Projektlaufzeit versus Plan

Diese Aufstellungen müssen anhand des Projektzeitplans, der als Netzplan mit den einzelnen Arbeitspaketen aufgestellt worden ist, erfolgen. Ein Forecast muss entsprechend eingetretene Verzögerungen anhand der Abhängigkeiten im Netzplan berücksichtigen sowie die Auswirkungen von geänderten Rahmenbedingungen oder neue Erkenntnisse über die Arbeitsgeschwindigkeit, die beispielsweise aus den Erfahrungen der bisherigen Projektarbeit resultieren können. Für die Darstellung des Projektzeitstatus dem Steuerkreis oder Lenkungsausschuss gegenüber eignen sich grafische Darstellungen, von denen es eine ganze Reihe gibt. In der folgenden Praxisbox 20 ist ein Beispiel hierfür aufgeführt.

Praxisbox 20: Reporting des Projektfortschritts In Abbildung 81 auf S. 190 sind die verschiedenen Arbeitspakete aufgeführt. Diese hatten sich hier aus einer Kombination von organisationaler und funktionaler Arbeitsstrukturierung ergeben (vgl. hierzu Abschnitt 3.2 ab S. 81). Die Zeilen geben in der Darstellung hierbei die Organisationseinheiten wieder und die Spalten die einzelnen Aufgaben, die dort zu erledigen sind. Die einzelnen Arbeitspakete stehen nun in der Tabelle und sind jeweils mit einem Kreis gekennzeichnet. Dieser gibt an, wie weit der Fortschritt bei der Durchführung der Tätigkeiten ist (siehe Legende in der Abbildung unten). Zusätzlich sind in der letzten Zeile der Tabelle noch übergreifende Tätigkeiten aufgeführt, die keiner Organisationseinheit zuzuordnen sind. Diese Darstellung ist zwar sehr übersichtlich, hat aber den gravierenden Nachteil, dass man nicht sieht, wie sich dieser Projektstatus im Verhältnis zum Plan darstellt. Um ggf. Maßnahmen zu ergreifen, um das Projekt zu beschleunigen, ist aber gerade dieser Vergleich notwendig. Eine Möglichkeit, den Ist-Stand dem Plan gegenüberzustellen, zeigt die Praxisbox 21.

190

Projektcontrolling

Leistungsbeschreibung

Unternehmen 2

Mengen

Qualität

Vollkostenermittlung

Stückkostenermittlung

Zielkostenermittlung

Leistungsvereinbarung SLA Vorgabe

SLA Abschluss

Business Line Card Service Direct Service

Unternehmen 1

Yellow Line Key Accounts Info Line Backoffice Customer Line übergreifende Prozesse

= noch nicht begonnen

Benchmarking

Aktivität = aufgenommen

SLA-Richtlinie

Aktivität = halb abgeschlossen

Steuerungssystem

Aktivität fast = abgeschlossen

Aktivität = abgeschlossen

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 81: Beispiel für eine Übersicht zum Projektstatus

Praxisbox 21: Plan-Ist-Vergleich Eine einfache Darstellung des Vergleichs von Planung und Ist-Zustand ist in der unten folgenden Abbildung 82 dargestellt. Basis ist der ursprüngliche Projektplan (ähnlich einer Darstellung als Gantt-Diagramm). Der Status ist als Linie (unterhalb von „heute“) eingezeichnet und zeigt, welche Teile des Plans schon erledigt sind und welche nicht. Arbeitspakete links der „heute“-Linie sind abgeschlossen, die rechts liegenden noch nicht. Wird ein Arbeitspaket durch die Linie geteilt, so gibt das Verhältnis der Teilung den Grad der Erledigung des Arbeitspakets an. Und liegt die „heute“-Linie links vom Ist-Punkt auf der X-Achse (siehe Dreieck in der Abbildung), dann ist eine Verzögerung eingetreten, liegt sie auf dem Ist-Punkt, dann ist das Projekt im Plan und wenn sie rechts liegt, dann hat man den Plan überholt.


191

heute Projektmonat 07/04 08/04 09/04 10/04 11/04 12/04 01/05 02/05 03/05 04/05 05/05 06/05

Konzernweites Intranet Publishinginstrument Suchmaschine

Roll-Out Migration

Analyse / Spez. Produktauswahl

Implementierung

Roll-Out

Implementierung

Implementierung 1

Test

Bereitstellung

Bereitstellung

Implementierung 2

Test

Auswahl

Spez.

Document Management System Workflow E-Formular Infrastruktur

Test

Auswahl

Dezentrales Intranet Virtual Teamroom

Implementierung

Spez.

Portal

Analyse / Spez. Produktauswahl

Bereitstellung

... Noch zu beantragende Piloten Definition der Anforderungen

Anschaffung der Komponenten-Server

In Anlehnung an Inhouse Consulting Deutsche Post World Net Abbildung 82: Ist-Plan-Gegenüberstellung

Die gleichzeitige Darstellung des Forecasts in dieser Art der Abbildung erscheint nicht so sinnvoll, da die Grafik dann sehr unübersichtlich wird. Allenfalls kann man die jeweiligen neuen Endtermine laut Forecast durch Punkte (Ɣ) in der Abbildung darstellen (hier nicht enthalten). Eine andere Form der Darstellung des Plan-Ist-Vergleichs mit Forecast ist die MeilensteinTrendanalyse (siehe hierzu Blazek/Zillmer 2001, S. 149 ff). In dieser Form der Darstellung wird nur die Erreichung der Meilensteine aufgeführt, was zumindest für den Bericht im Lenkungsausschuss in der Regel ausreichend ist. Die Meilenstein-Trendanalyse erfolgt durch grafische Darstellung in einem Gitter, dessen Achsen Kalenderdaten sind. An der Y-Achse werden die im Projektplan festgelegten Meilensteine in zeitlich aufsteigender Folge eingetragen (vgl. hierzu Abbildung 83 – die Meilensteine sind dort als weiß gefüllte Rauten eingezeichnet). Die X-Achse sollte von links nach rechts in zeitlich aufsteigender Reihenfolge im gleichen Maßstab wie die Y-Achse dargestellt sein. Dort werden die in der Kommunikationsplanung vereinbarten Berichtstermine eingetragen. In der Abbildung sind diese durch kleine auf dem Kopf stehende schwarze Dreiecke gekennzeichnet. Bei Erreichen der jeweiligen Berichtstermine wird die Abbildung weiter vervollständigt. Es wird jeweils in den Spalten zu den jeweiligen Berichtsterminen eingetragen, wie der aktuelle Forecast für das Erreichen der Meilensteine ist. Die jeweiligen Meilensteine laut Forecast werden über die einzelnen Berichtszeitpunkte hinweg mit einer Linie verbunden. Entspricht der Forecast noch dem Plan, so ist diese Linie waagerecht. Bei Eintritt einer Verzögerung im Forecast verschiebt sich die Linie nach oben. So ist grafisch auf den ersten Blick zu erkennen, ob der Forecast vom Plan

192

Projektcontrolling

01.09.05

01.08.05

01.07.05

01.06.05

01.05.05

01.04.05

01.03.05

01.02.05

01.01.05

abweicht. Im Extremfall kann eine der schwarzen Forecast-Meilensteinlinien die Abbildung auch nach oben hin verlassen, wenn die Verzögerung über den ursprünglich geplanten Projektzeitraum hinaus erfolgt.

01.09.05

01.08.05

Plan Meilensteine

01.07.05

01.06.05

01.05.05

01.04.05 = Berichtszeitpunkt 01.03.05

= Meilenstein

01.02.05 01.01.05

Forecast Meilensteine

Quelle: Wolf/Mlenkusch (1997), S. 174 und Blazek/Zillmer (2001), S. 152 Abbildung 83: Beispiel Meilenstein-Trendanalyse

5.4

Erreichung des Ergebnisses (Qualitätskontrolle)

Ein reines „Abhaken“ des Zeitplans und Budgets im Rahmen der Kontrolle ist noch überhaupt nicht aussagekräftig dafür, ob die mit dem Projekt verbundenen Ziele erreicht wurden. Die Kontrolle der plangemäßen Erreichung der Projektergebnisse ist eine inhaltliche Aufgabe, die sich aus dem Projektziel und geplanten Ergebnissen ergibt. Insofern ist dies sehr projektspezifisch zu prüfen.


193

Die Prüfung der Projektergebnisse sollte natürlich laufend durch die inhaltlich zuständigen Personen erfolgen. In der Regel sind dies die Teilprojektleiter und natürlich auch der Projektmanager. Da aufgrund des Umfangs der Arbeiten oft eine kontinuierliche Prüfung nicht möglich ist – bzw. eine Prüfung von Zwischenständen inhaltlich sehr schwer ist – bietet es sich an, zu den definierten Meilensteinen auch eine inhaltliche Prüfung der Ergebnisse vorzunehmen. Gut formulierte Meilensteine erfordern zum Erreichen auch jeweils ein bestimmtes Qualitätsniveau der bis dato erfolgten Projektarbeit. Der Projektmanager ist für diese Prüfung zuständig und muss ggf. fachliche Experten hinzuziehen. Geprüft werden sollte mindestens die Einhaltung der im Auftrag oder Pflichten- bzw. Leistungsbeschreibung festgelegten Spezifikationen (siehe Abschnitt 2.4.1 ab S. 56).


195

6 Mitarbeiterführung im Projekt

Bisher wurde in diesem Buch Projektmanagement sehr konzeptionell und methodenorientiert behandelt. Es wurden Vorgehensweisen und kleine Tools vorgestellt, mit deren Hilfe die Strukturierung, Planung und Steuerung eines Projektes unterstützt werden können. Dies sind hoffentlich hilfreiche Methoden, um dem Projekt eine gute „äußere“ Form zu geben, an alle Gesichtspunkte zu denken und durchzuplanen. Für die Projektdurchführung sind dies unerlässliche Aspekte, ohne die ein Projekt nicht durchgeführt werden kann. Für den Projekterfolg ist dies jedoch bei weitem nicht ausreichend. Es darf nicht der Fehler gemacht werden zu glauben, dass ein Projekt durch eine gute Projektdefinition, -planung und -überwachung der Arbeitspakte allein erfolgreich durchzuführen ist. Projekte werden durch Menschen realisiert und daher ist es für den Erfolg eines Projektes essenziell, dass die daran beteiligten Menschen richtig eingesetzt werden, informiert und motiviert sind und dass Konflikte gelöst werden. Zudem werden Projekte im Team von mehreren Personen mit verschiedenen persönlichen und fachlichen Hintergründen durchgeführt und genau dieses oft heterogene Team muss reibungslos zusammenarbeiten. Ich habe schon Projekte erlebt, die perfekt definiert und geplant sowie mit hervorragenden Mitarbeitern besetzt waren, die aber dennoch fast gescheitert wären. Das lag daran, dass die Projektmitarbeiter sich gegen den Projektleiter gestellt haben. Die Projektmitarbeiter konnten sich mit ihren Ideen nicht im Projekt wiederfinden und haben als Reaktion hierauf entgegen der durch den Projektleiter vorgegebenen Vorgehensweise gehandelt. So verfolgten letztendlich Projektleiter und Mitarbeiter unterschiedliche Ziele, was in enormen Reibungsverlusten bei der Vorgehensweise resultierte und schließlich in einem offen ausgetragenen Streit endete. Dieser konnte erst mit Hilfe eines erfahrenen Projektpartners gelöst werden und erst hiernach stellte sich der Projekterfolg ein. Diese hierbei nötigen eher „weichen“ Faktoren des Projektmanagements lassen sich nicht so eindeutig wie die Projektplanung durch Tools und Templates darstellen und vermitteln. Es sind Faktoren, die soziale und emotionale Fähigkeiten erfordern. Im Rahmen des Managements sind sie im Personalmanagement und dort in der Personalführung angesiedelt. Sie entziehen sich teilweise der im Projektgeschäft von Managementberatungen manchmal vorherrschenden planerisch/strukturellen Sichtweise und laufen so Gefahr, trotz ihrer hohen Bedeutung nicht angemessen berücksichtigt zu werden. Zuweilen kann man auch den Eindruck haben, dass die persönlichen Fähigkeiten bei Projektmanagern entweder auf der planerisch/strukturellen oder der sozialen/emotionalen Seite besonders stark ausgeprägt sind und dass Projektmanager, die beide Seiten sehr gut abdecken, rar gesät sind.

196

Mitarbeiterführung im Projekt

In diesem Kapitel des Buches soll kein „Rundumschlag“ zum Thema Personalmanagement erfolgen, sondern es soll versucht werden, sich auf die in einem Managementberatungsprojekt wesentlichen Punkte gezielt zu beziehen.10 Die hier in den nächsten Abschnitten behandelten Punkte sollen den Projektleiter in die Lage versetzen, seine Mitarbeiter optimal arbeiten zu lassen – und dies erreicht man dadurch, dass die Mitarbeiter entsprechend ihrer Fähigkeiten eingesetzt werden, motiviert und mit Spaß am Projekt arbeiten, gut über alle für sie relevanten Punkte informiert sind, gut und effizient im Team arbeiten und dass Konflikte als Chance verstanden und gelöst werden. Entsprechend sind die nächsten Seiten aufgebaut: Personalbeurteilung Kommunikation Motivation/Teambildung und Konfliktmanagement

6.1

Personalbeurteilung

Warum ist die Personalbeurteilung im Projektmanagement besonders wichtig? Hier gilt das gleiche Grundprinzip wie beim Projektcontrolling. Nur wenn gemessen wird, kann auch gesteuert werden. Wenn also der Einsatz und die Arbeit der einzelnen Mitarbeiter für den Projekterfolg eine wesentliche Voraussetzung ist, so müssen dieser Einsatz und die Arbeit auch gemessen und beurteilt werden. Nur über eine Personalbeurteilung kann festgestellt werden, ob die wichtigste Ressource im Projekt – die Menschen – gut eingesetzt wird, oder ob es zu Problemen und Unzufriedenheiten gekommen ist. Ohne eine solche Messung ist auch keine Steuerung möglich. Die Personalbeurteilungen haben also den Zweck, die Voraussetzung dafür zu schaffen, bei negativen Abweichungen etwa über Mitarbeitergespräche steuernd eingreifen zu können, den Mitarbeitern Sicherheit zu geben, wie ihre Leistung beurteilt wird, und über diese Transparenz einen Leistungsanreiz zu geben, den Mitarbeitern Feedback zur Motivation bzw. zur Verhaltensänderung zu geben, zur Motivation finanzielle Prämien für gute Leistungen zu geben,

10

Zum Personalmanagement sei auf die einschlägige Literatur hierzu verwiesen, bspw. Schmidt (1996), Becker (2002) oder Olfert (2003).

Personalbeurteilung

197

Gehaltsanpassungen oder Beförderungen gerecht und auf fundierter Basis vornehmen zu können, Schulungsbedarf zu klären bzw. ggf. auch Aufgabenwechsel (Job Rotation) vorzunehmen und den gezielten Einsatz geeigneter Personen in Projekte planen zu können (vgl. Olfert 2003, S. 293-294).

Die Begriffe Mitarbeiterbeurteilung und Personalbeurteilung sollen hier synonym verwendet werden. Allgemein gilt, dass eine solche Beurteilung der Mitarbeiter ein Soll-Ist-Vergleich ist (siehe Drumm 2005, S. 114). In jedem Fall muss dem Mitarbeiter also transparent gemacht werden, was die Anforderung an seine Tätigkeit im Projekt ist. Dies sollte über die Stellenbeschreibung (siehe Abbildung 47 auf S. 113), ein Anforderungsprofil (siehe Abbildung 65 auf S. 152) und eine gesondert jeweils für ein Jahr zwischen Mitarbeiter und Vorgesetztem abgeschlossene Zielvereinbarung erfolgen. Im Rahmen der Mitarbeiterbeurteilung erfolgt dann ein Vergleich zwischen diesen Anforderungen und der tatsächlichen Leistung. Für die Durchführung von Personalbeurteilungen in Projekten gibt es einige Grundsätze, deren Einhaltung die Zielerreichung gewährleisten soll. Zu nennen sind: Die Bewertung soll messbar sein. Hierfür sollten daher Skalen verwandt werden, auf denen die Leistung des Mitarbeiters bewertet wird (zu den Skalen siehe Bröckermann 2001, S. 181ff. Drumm 2005, S. 119). Die Verwendung von Skalen führt dazu, dass ein fester Satz von Kriterien zur Beurteilung herangezogen wird. Dies erleichtert die Arbeit des Beurteilenden wesentlich, da er gezielt auf die Leistung des Beurteilten in Bezug auf diese Kriterien achten kann. Für den Beurteilten ergibt sich eine erhöhte Transparenz bezüglich der Anforderungen, wenn ihm die Kriterien – was dringend zu raten ist – bekannt sind. Neben den festen Kriterien erfordert die Verwendung von Skalen noch feste Beurteilungsmaßstäbe. D. h., es muss bekannt sein, für welche Leistung welcher Skalenwert vergeben wird. In der Praxis bedeutet dies, dass für jede Art der Tätigkeit im Projekt ein Anforderungsprofil bestehen muss, welches schriftlich fixiert ist. Zu diesem Anforderungsprofil gehört ein Bewertungsraster, das verschiedene Kriterien enthält. Übliche Kriterien beziehen sich auf die Oberpunkte Arbeitsverhalten (inkl. von Fachkenntnissen und Problemlösungsverhalten), das Verhalten gegenüber Kollegen und Vorgesetzten, das Führungsverhalten, geistige Anlagen und persönliches Auftreten (vgl. Olfert 2003, S. 300 f.). Zu diesen Oberpunkten muss es ausformulierte einzelne konkrete Anforderungen geben, denen eine Skala zugeordnet ist. Skalen können verbal oder nonverbal, numerisch, graphisch etc. sein. Jeder Skalenausprägung ist nun genau zuzuordnen, bei welchem Verhalten dieser Skalenwert zutrifft. Dies ist ebenfalls schriftlich auszuformulieren. Die Aufstellung eines solchen Systems der Mitarbeiterbeurteilung erfordert eingangs einen hohen Aufwand, da es für jede Art der Tätigkeit (üblicherweise für jede Hierarchiestufe) erstellt werden muss. In der Praxis der Personalbeurteilung spart es jedoch viel Aufwand und insbesondere ergeben sich so weniger subjektiv gefärbte Ergebnisse, was auch nachträgliche Unzufriedenheit bei den Beurteilten reduziert.

198


Die Bewertung soll anhand von Zielen erfolgen. Für die weitere berufliche Entwicklung ist die Bewertung eines Mitarbeiters meist sehr wichtig. Oft – und in Managementberatungen meist – sind mit den Bewertungen auch Prämienzahlungen verbunden. Daher sollte individuell für jeden Mitarbeiter vereinbart werden, welche Ziele er in einem Bewertungszeitraum erreichen soll. In der Praxis werden schriftliche Zielvereinbarungen geschlossen, die meist für ein halbes oder ein ganzes Jahr abgeschlossen werden. Diese bilden sozusagen den Soll-Wert auf der Skala, der dem Ist-Wert, der auf der Skala erreicht wurde (siehe vorherigen Punkt) gegenübergestellt wird. Die Entscheidung über Beförderung, Prämienzahlungen, Schulungsbedarf etc. ergibt sich aus einem Soll-Ist-Vergleich. Eine vorherige Zielvereinbarung ist daher unerlässlich. Die Bewertung soll konkret sein. Die Begründung für die Wahl einer Beurteilung auf der Skala sollte anhand von konkreten Beispielen aus dem Verhalten des Beurteilten erfolgen. Kann eine Bewertung nicht anhand von konkreten Beispielen begründet werden, so besteht die Gefahr, dass sie subjektiv und mit einem Bias (also einer Verzerrung) versehen ist. Zudem erhöht die Verwendung von Beispielen wieder die Akzeptanz des Beurteilten für die Bewertung und bietet auch konkrete Ansatzpunkte für Verhaltensänderungen (falls notwendig). Die Verwendung von Beispielen stellt zudem sicher, dass sich die Bewertung auf den aktuellen Zeitraum bezieht und nicht eine bloße Fortschreibung aus der Vergangenheit ist. Die Bewertung sollte auf regelmäßigen Beobachtungen beruhen. Um eine faire und angemessene Personalbeurteilung durchführen zu können, ist es wichtig, sich als Beurteiler nicht nur auf ein einzelnes Ereignis zur Beurteilung einer längeren Zeitspanne zu beziehen, sondern kontinuierlich während des Beurteilungszeitraums Beobachtungen gemäß der vereinbarten Kriterien zu machen. Hierzu kann für den Beurteilenden sinnvoll sein, regelmäßig schriftliche Aufzeichnungen zu machen, da eine rein gedächtnisbasierte Beurteilung eines weiter zurück liegenden Zeitraums lückenbehaftet sein kann bzw. sich Verfälschungen der Beobachtungen einschleichen können. Damit die Beurteilung auf regelmäßigen Beobachtungen beruhen und auch noch eine steuernde Wirkung auf das Mitarbeiterverhalten besitzen kann, muss sie in regelmäßigen Abständen erfolgen. Im Projektmanagement heißt dies, dass immer bei Projektende eine Mitarbeiterbeurteilung stattfinden sollte. Bei länger laufenden Projekten sollte zudem mindestens alle sechs Monate eine Bewertung stattfinden. Längere Intervalle sind nicht zweckmäßig, da die Arbeit nicht mehr anhand konkreter Punkte aus dem gesamten Zeitraum bewertet werden kann. Wichtige Punkte sollten sofort angesprochen werden. Der Beurteilte sollte laufend über die Wahrnehmung in wichtigen Punkten informiert sein. Dies sind etwa Punkte, die einen wesentlichen Einfluss auf die Beurteilung haben werden. Zum einen dient dies der Motivation, zum anderen gibt es die Möglichkeit, schon innerhalb eines Beurteilungszeitraums zu reagieren, beispielsweise das Verhalten zu ändern. Der Beurteilende hat also die Aufgabe, bei Bedarf mit dem Beurteilten zu sprechen, so dass es bei einer Beurteilung nicht zu der Aussage kommen kann „Hätte ich dies schon früher gewusst …“. Verhält sich ein Projektleiter aus Sicht des Partners seinem Team gegenüber falsch, etwa weil er zu autoritär führt,

Personalbeurteilung

199

so sollte der Partner ihn schnell darauf hinweisen und nicht bis zum nächsten Beurteilungsgespräch warten. Die Bewertung sollte schriftlich erfolgen und in einem persönlichen Gespräch erläutert werden. Die Forderung nach der Schriftform ergibt sich aus der Bedeutung der Bewertung für den Bewerteten. Ist die Bewertung nicht schriftlich festgelegt, kann der Bewertete nicht sicher sein, dass sie den anderen Führungskräften und der Personalabteilung richtig kommuniziert wurde. Weitere Interpretationen wären möglich, und sollte der Beurteilende aus dem Unternehmen ausscheiden, gäbe es keine Aufzeichnungen mehr, auf die zurückgegriffen werden könnte. Die persönliche Erläuterung ist notwendig, damit über Beobachtungen gesprochen werden kann. Der Beurteiler kann Punkte erklären und es kann nachgefragt werden. Zudem ist es aus menschlicher Sicht selbstverständlich, eine Beurteilung persönlich zu geben. Enge Terminkalender dürfen aufgrund der Wichtigkeit dieser Aufgabe nicht als Ausrede dafür herhalten, keine Zeit für eine persönliche Diskussion der Beurteilung zu haben. Beurteilungen sollten im Konsens erfolgen. Auch wenn dies vielleicht zunächst merkwürdig erscheint, so sollten Beurteilungen zwischen Beurteiltem und Beurteiler in Übereinstimmung erfolgen. Diese Übereinstimmung sollte durch gemeinsame Unterschrift unter die Beurteilung dokumentiert werden. Ist die Beurteilung gut begründet und erfolgte anhand der nachvollziehbaren Skalenwerte, so sollte ein Konsens ohne weiteres möglich sein. Hierzu ist es notwendig, dass der Beurteilte sich möglichst vor einem Beurteilungsgespräch selbst anhand der bekannten Kriterien bewertet. In der Praxis habe ich es auch nur sehr selten erlebt, dass ein solcher Konsens nach einem Gespräch nicht herzustellen war. Dies mag auch in dem bekannten Effekt begründet sein, dass die meisten Mitarbeiter bei einer Selbstbewertung sehr kritisch sind. Ist ein Konsens nicht herstellbar, so ist es gut, auch dies zu dokumentieren, damit der Beurteilte die Möglichkeit hat darzustellen, warum er der Beurteilung nicht zustimmt. Beurteilungen sollten durch mindestens eine weitere Person abgesichert sein. Bei allen Versuchen, durch Skalen und Ziele die Beurteilungen zu objektivieren, erfolgen sie durch Menschen und basieren auf deren subjektiven Wahrnehmungen. Daher sollte es einen Sicherungsmechanismus geben, bei dem mindestens eine weitere Person die Beurteilung auf Konsistenz prüft. Geeignet ist hierbei insbesondere ein Patensystem, bei dem eine Führungskraft über einen langen Zeitraum dafür zuständig ist, die Beurteilungen einer Person zu sammeln und auf Plausibilität zu prüfen. Gut ist auch, wenn hierzu Beurteilungen weiterer Personen zusammengeführt werden können, im Falle von Beratern etwa von Auftraggebern oder Kollegen (siehe hierzu die Arten der Beurteilung im folgenden Text). Es ist hilfreich, für diese Aufgabe des Paten eine Führungskraft zu wählen, da diese im Falle der Notwendigkeit des Eingreifens wegen Verdachtes auf unfaire Bewertungen die notwendige Durchsetzungskraft besitzt. Bewertungen sollen vertraulich sein. Diese Vertraulichkeit sichert dem Bewerteten den notwendigen Freiraum zu, sich verbessern zu können, ohne an den Pranger gestellt zu werden. Transparenz sollte lediglich den Personen gegenüber bestehen, die auf die Bewer-

200


tung für ihre Arbeit angewiesen sind. Etwa muss ein Projektleiter informiert sein, wenn ein Mitarbeiter Probleme im Kundenkontakt hat. Welche Personen können in einem Projekt sinnvollerweise beurteilt werden? Abbildung 84 gibt hierüber eine Übersicht. Beschränkt ist dies natürlich zunächst einmal auf die Personen, die eine Aufgabe im Projekt übernehmen. Dies können entsprechend Mitarbeiter des Klientenunternehmens sowie des Beratungsunternehmens sein. Dort sind es zunächst die Projektmitarbeiter (in der Managementberatung „Berater“ genannt) sowie die Projektleiter. Der Auftraggeber und der Partner übernehmen im Projekt wichtige Rollen und können daher auch beurteilt werden. Da sie in der jeweiligen Hierarchie ihrer Unternehmen keine Vorgesetzten haben, ist die Frage der Zuständigkeit für eine Beurteilung nicht so leicht zu klären. Daher sind sie in der Abbildung gestrichelt eingezeichnet. Für sie kann eine Beurteilung ihrer Arbeit im Projekt aber auch erfolgen. Beispielsweise können sie durch die Projektleiter und Mitarbeiter aus ihrer Organisation beurteilt werden oder der Partner der Managementberatung kann durch den Auftraggeber beurteilt werden. Darüber hinaus werden sie in ihrer Tätigkeit üblicherweise am Gesamterfolg gemessen, in den natürlich auch der Projekterfolg einfließt.

Klientenunternehmen

Auftraggeber

fachseitige Projektleitung

Managementberatungsunternehmen Partner

Mitarbeiterbeurteilung im Projekt

Mitarbeiter

beratungsseitige Projektleitung

Berater

Abbildung 84: Mitarbeiter, die bei Projekten beurteilt werden können

Personalbeurteilung

201

Für die Personalbeurteilung von Projektmitarbeitern aus dem beratenen Unternehmen ist zu unterscheiden, ob die Mitarbeiter in eine reine Projektorganisation, eine Projektkoordination oder eine Projekt-Matrix-Organisation eingebunden sind (siehe Abschnitt 4.3 ab S. 158): In der reinen Projektorganisation erfolgt die Mitarbeiterbeurteilung ausschließlich über die Projekttätigkeit durch den im Projekt Vorgesetzten. In der Projektkoordination erfolgt die Mitarbeiterbeurteilung in der Regel über den Linienvorgesetzten. Dieser kann beim Projektleiter eine Stellungnahme zur Leistung des Mitarbeiters im Projekt einholen, verantwortet die Mitarbeiterbeurteilung jedoch ausschließlich allein. In einer Projekt-Matrix-Organisation erfolgt die Mitarbeiterbeurteilung aus der Sichtweise des Linienvorgesetzten und des fachseitigen Projektleiters. Um die Einheitlichkeit für den Mitarbeiter, aber auch für das Unternehmen zu gewährleisten, erfolgt in der Regel eine Zusammenführung der Beurteilungen beim Linienvorgesetzten, der die letztendliche Verantwortung trägt. Diese Beurteilung der Arbeit der Mitarbeiter im Projekt ist für das Projektmanagement besonders wichtig. Projekte sind außergewöhnliche Vorhaben, für die entsprechend ein besonderer Einsatz notwendig ist. Erfolgte nun lediglich eine Leistungsbeurteilung der Linienfunktion, so wäre nicht zu erwarten, dass sich die Mitarbeiter für ihre Projekttätigkeit besonders anstrengen. Durch die Leistungsbeurteilung auch dieser Tätigkeit wird hierfür ein entsprechender Leistungsanreiz gegeben.

Etwas anders gestaltet sich die Mitarbeiterbeurteilung in der Managementberatung. Die Art der Projektorganisation spielt hier keine Rolle, da die Mitarbeiter der Managementberatung immer ihren Hauptteil der Arbeitszeit mit Projektarbeit verbringen werden. Interne Aufgaben in der Managementberatung sind zwar auch vorhanden, spielen aber trotz aller Bedeutung für das Beratungsunternehmen meist nur eine Nebenrolle bei der Mitarbeiterbewertung. Oft ist ihre Bewertung als ergänzender Punkt in die Beurteilung der Tätigkeit im Projekt integriert. Es gibt verschiedene Arten der Mitarbeiterbeurteilung in Managementberatungen (zu Arten allgemein siehe Bröckermann 2001, S. 185): Top-down-Beurteilungen, Auftraggeber-Beurteilung Bottom-up-Beurteilungen, 360° Beurteilungen und übergreifende anonyme Mitarbeiterbefragungen.

Bei der Top-down-Beurteilung beurteilt der Vorgesetzte den jeweiligen Mitarbeiter, d. h., der Partner beurteilt den Projektleiter und der Projektleiter beurteilt die in seinem Projekt arbeitenden Berater. Hierdurch kann gesehen werden, inwieweit die Vorgesetzten mit der Leistung der Mitarbeiter im Projekt zufrieden sind. Sie können aus ihrer übergeordneten Sicht beurteilen, wie die Arbeit erledigt wurde, wie das Verhalten der Mitarbeiter dem Klienten gegenüber war, wie die fachlichen und sozialen Fähigkeiten des Mitarbeiters sind, inwieweit im

202


Team gearbeitet wurde etc. Dabei können sie insbesondere die Erfüllung der Aufgaben, die sie den Mitarbeitern im Projekt gegeben haben, bewerten. Die Auftraggeber-Beurteilung ähnelt der Top-down-Beurteilung, nur erfolgt hier die Beurteilung der Mitarbeiter der Beratung durch den Auftraggeber aus dem Klientenunternehmen heraus. Der Auftraggeber ist aufgrund der Kundenbeziehung des Beratungsunternehmens ja quasi der Vorgesetzte des Partners der Beratung und natürlich auch des Projektleiters und der Berater. Letztendlich ist die Auftraggeberzufriedenheit ja das Ziel des Projektmanagements einer Managementberatung. Insofern ist es einleuchtend, dass auch die Auftraggeber die Leistung der zuständigen Mitarbeiter des Beratungsunternehmens beurteilen sollten. Dies setzt natürlich voraus, dass sie die Leistung der Mitarbeiter beurteilen können. In der Regel ist dies mindestens für Partner und Projektleiter möglich, da diese in den Gremien des Projektes vertreten sind und sie das Gesamtprojektgeschehen beeinflussen. Grundsätzlich ist es natürlich auch möglich, die Berater durch den Auftraggeber beurteilen zu lassen, soweit deren Leistung einzeln beurteilt werden kann. Die Bottom-up-Beurteilung geht den anderen Weg. Hier beurteilen die Mitarbeiter ihre Vorgesetzten, d. h. die Berater den Projektleiter und Partner und die Projektleiter die Partner. Hier geben die Mitarbeiter an, inwieweit die Vorgesetzten aus Sicht der Mitarbeiter einen „guten Job“ gemacht haben. Dies betrifft die bei den Vorgesetzten angesiedelten Aufgaben des Projektmanagements (Projektdefinition, Arbeitspaketplanung, Zeitplanung, Budgetplanung, Kommunikation etc.) sowie natürlich auch die Mitarbeiterführung (Motivation und Information der Mitarbeiter), Unterstützung der Mitarbeiter und die fachliche Kompetenz. Die Mitarbeiter sind in der Regel hierbei sehr gut in der Lage einzuschätzen, ob die Vorgesetzten ihrer Rolle gerecht wurden. 360° Beurteilungen sind weit reichender als die bisher vorgestellten Methoden. Hier werden die Berater, Projektleiter und Partner nicht nur von den Vorgesetzten, Mitarbeitern oder Auftraggebern beurteilt, sondern auch von den Kollegen, weiteren internen und externen Kunden sowie durch eine Selbstbeurteilung. Ziel ist es hierbei, den Mitarbeitern ein möglichst umfassendes Bild zu verschaffen, wie sie von den Menschen wahrgenommen werden, mit denen sie im Projekt regelmäßig zu tun haben. Aufgrund der Komplexität einer solchen Beurteilung wird diese meist schriftlich durchgeführt und anonymisiert durch die Personalabteilung ausgewertet und kommuniziert (Bröckermann 2001, S. 188-189). D. h., der einzelne Mitarbeiter bekommt keine Aufschlüsselung, wer was über ihn gesagt hat, jedoch erhält er die Statements. Es gibt auf solche Analysen spezialisierte Beratungsunternehmen, die hierbei unterstützen und die Anonymität gewährleisten. Übergreifende anonyme Mitarbeiterbefragungen haben das Ziel, nicht die Leistung eines einzelnen Mitarbeiters zu beurteilen, sondern die Gesamtsituation aller Mitarbeiter. Daher können sie schriftlich und anonym durchgeführt werden. Dies hat den Vorteil, dass keine Verzerrung in den Antworten zu erwarten ist, da aufgrund der Anonymität keine unterschwelligen Sanktionen möglich sind. Beurteilt werden kann so die Gesamtstimmung aller Mitarbeiter im Projekt, die Zufriedenheit der Projektmitarbeiter insgesamt und ob es bestimmte Problembereiche (Ausstattung, Führung, Zieldefinition im Projekt, Unsicherheit über Einsatz

Personalbeurteilung

203

nach dem Projekt, Zufriedenheit mit der Art der Tätigkeit etc.) gibt. Eine solche übergreifende Beurteilung kann die Einzelbeurteilungen sehr gut ergänzen und der Abgleich hilft auch dabei, die Einzelfeedbacks beispielsweise bei der Bottom-up-Beurteilung zu plausibilisieren. Ergibt die übergreifende Befragung beispielsweise Probleme mit der Führung, zeigt sich dies jedoch in keiner Bottom-up-Beurteilung, so kann etwas nicht stimmen.

Praxisbox 22: Personalbeurteilungs- und Feedbacksystem Über die letzten Jahre hat das Inhouse Consulting ein Personalbeurteilungs- und Feedbacksystem entwickelt, das die im Text angesprochenen Aspekte größtenteils abdeckt. Aus Sicht des Inhouse Consultings ist dieses System von übergeordneter Bedeutung für das Beratungsunternehmen, da die Mitarbeiter die wichtigste Ressource der Managementberatung sind. Die Mitarbeiter bilden die Voraussetzung für gute Projektarbeit. Das System wurde von den Consultants, Projektmanagern und Partnern des Inhouse Consultings gemeinsam entwickelt und genießt daher eine hohe Akzeptanz bei allen Mitarbeitern. Es wird dennoch laufend weiterentwickelt, so dass das dargestellte System nur eine Momentaufnahme ist. Das System besteht aus sechs Bausteinen, die parallel nebeneinander bestehen, aber auch teilweise aufeinander aufbauen. Diese sind in Abbildung 85 dargestellt und werden im Folgenden nochmals kurz erläutert: Grundsatz ist, dass eine Kultur der Offenheit bestehen muss, in der jeder jedem jederzeit ein geeignetes Feedback geben kann, wenn dies der Verbesserung der Projektarbeit dient. Jeder Mitarbeiter ist aufgefordert, Feedback zum Verhalten anderer (und dies schließt Vorgesetzte ein) zu geben und auch offen für Feedback zu seiner Person zu sein und dies anzunehmen. Eine solche Kultur zu implementieren hat sich als durchaus herausfordernde Aufgabe herausgestellt. Erfolgsfaktoren sind dabei insbesondere das Vorleben der Feedbackkultur durch die Führungskräfte (etwa durch die so genannten. „open door policy“, d. h. die jederzeit vorhandene Offenheit für Gespräche) und die Risikofreiheit bei der Feedbackäußerung. Kein Mitarbeiter darf aufgrund selbst eines kritischen Feedbacks, das er anderen gegeben hat, kritisiert werden. Die Appraisals sind die regelmäßigen Bewertungen durch die jeweilige Führungskraft. Damit der Beurteilte schnell reagieren kann, werden diese Appraisals alle drei Monate durchgeführt. Endet ein Projekt zu einem anderen Zeitpunkt, so wird ein zusätzliches Appraisal durchgeführt. Zwar führt dies zu einer auf den ersten Blick hohen Zahl von Bewertungen, die Praxis zeigt jedoch, dass sich ein solches System schnell einspielt, zumal es durch geeignete Templates gut unterstützt wird. Da das Projektgeschäft zuweilen sehr durch schnellen Wandel geprägt ist, wird durch die Beurteilung in kurzen, regelmäßigen Abständen sichergestellt, dass jeder Mitarbeiter für die Leistung in seinem Projekt eine entsprechende Bewertung bekommt. Insbesondere für die persönliche Weiterentwicklung von Consultants hat sich dieser recht enge Rhythmus als sehr vor-

204


teilhaft erwiesen. Der Abgleich von Eigen- und Fremdbeurteilung und die Akzeptanz der Bewertung anderer werden als die Voraussetzung für eine persönliche Weiterentwicklung der Berater angesehen. Ein kontinuierliches Feedback aus verschiedenen Richtungen ermöglicht dem Berater diese Weiterentwicklung. Der Beurteilende ist aufgefordert, die Beurteilung durch das Einholen von Meinungen Dritter, besonders der der Auftraggeber, abzusichern und diese zu berücksichtigen. Das Appraisal dient auch als eine der Grundlagen für die Jahresbeurteilungen und der Festlegung von Trainingsbedarf. Anhand der Leistung wird festgelegt, welche Fähigkeiten (fachlich oder persönlich) des Beurteilten am ehesten eines Trainings bedürfen. Dies – wie auch die gesamte Bewertung – wird mit dem Bewerteten diskutiert und durchgesprochen, um möglichst einen Konsens hierüber zu erzielen. Halbjährlich werden Upward Feedbacks durchgeführt. Hierbei erfolgt die Bewertung genau in umgekehrter Richtung wie beim Appraisal. Die Mitarbeiter bewerten ihre Projektvorgesetzten. Es wird versucht, diese Bewertungen von den Appraisals zeitlich zu entkoppeln, d. h., die entsprechenden Upward-Feedback-Gespräche finden nach den Appraisal-Gesprächen statt. Dies hat den Vorteil, dass die Mitarbeiter nicht befürchten müssen, für ein schlechtes Upward Feedback ein schlechtes Appraisal zu bekommen. Die Halbjahresbeurteilung der Berater erfolgt im Rahmen eines Meetings, an dem alle Personalentwickler der Mitarbeiter teilnehmen. Personalentwickler begleiten die Karriere der Berater des Inhouse Consultings als Ratgeber über einen längeren Zeitraum. D. h., sie kennen den Mitarbeiter aus persönlichen Gesprächen, kennen dessen Entwicklungswünsche und die aktuellen und vergangenen Appraisals und Halbjahresbewertungen sowie deren Trainingsbedarf. Sie sprechen auch mit den Auftraggebern, für die die Mitarbeiter gearbeitet haben, und erlangen so ein umfassendes Bild. In dem Meeting zur Jahresbewertung vertreten sie quasi den Fall des Bewerteten und fassen alle Meinungen zusammen. Allerdings haben auch die anderen Partner und Personalentwickler die Möglichkeit, sich hierzu zu äußern. Die endgültige Bewertung (Jahresbeurteilung) erfolgt gemeinsam durch das gesamte Gremium. Hierdurch ist sichergestellt, dass eine persönliche Parteilichkeit bei der Bewertung möglichst gering bleibt und dass eine längerfristige Perspektive der Personalentwicklung berücksichtigt wird. Die Auftraggeber werden von den Beurteilenden idealerweise vor der Erstellung eines Appraisals und auf jeden Fall vor der Halbjahres- und Jahresbeurteilung kontaktiert und nach einem Fragenkatalog zur Leistung des Beurteilten befragt. Dies kann schriftlich oder auch mündlich erfolgen. Zudem erfolgt bei Projektende eine Online-Auftraggeberbefragung. Ziel dieser jährlichen Befragung ist es, die Auftraggeberzufriedenheit festzustellen. Diese wird vorher bereits während und nach dem Projekt durch den Projektleiter in einem Gespräch ermittelt. Aufgrund der Bedeutung dieser Zufriedenheit für Anschlussaufträge und positive Mund-zu-Mund-Propaganda wird dies zentral organisiert durch die Beratung unabhängig vom Projektteam nochmals abgefragt. Ziele sind eine Qualitätssicherung sowie die Möglichkeit, aufgrund der in der Regel etwas zeitverzögerten Befragung anhand eines Fragebogens neue Informationen zu erhalten. Dieser Fra-

Personalbeurteilung

205

gebogen enthält auch Fragen zur Leistung der Mitarbeiter im Projekt, die dann entsprechend auch in die Jahresbewertung eingehen. Letzter Baustein ist eine jährlich anonym durchgeführte Mitarbeiterbefragung zur Mitarbeiterzufriedenheit. Sie ist zwar nicht durchweg direkt projektbezogen, fragt aber viele Aspekte ab, die für die durchgeführten Projekte wichtig sind. Dies kann die Zusammenarbeit im Team, die Unterstützung durch die Vorgesetzten, das Eingehen auf persönliche Wünsche der Consultants und Projektleiter, die Ausstattung mit Laptops, Mobilfunk, Büros etc., aber auch die wahrgenommene Qualität der Projektergebnisse betreffen. Hierdurch wird ein Gesamtbild des Inhouse Consulting ermittelt – die Erhebung ist nicht mitarbeiterbezogen. Durch die vorgestellten Bausteine erhält das Inhouse Consulting ein umfassendes Bild von der Leistung und auch Zufriedenheit der Mitarbeiter. Ziel ist es zudem, die Möglichkeit zum Feedback zu geben, da dieses die erste Voraussetzung für Verbesserungen ist. Die Erfahrung zeigt, dass das doch sehr aufwändige Gesamtsystem dazu führt, gute Leistungsanreize für die einzelnen Mitarbeiter zu geben, da sie sehen, dass ihre eigene Leistung ihnen auch zugerechnet wird und eine gerechte und transparente Beurteilung erfährt.

Wann?

„Kultur der Offenheit“

Appraisals

UpwardFeedback

Halbjahresbeurteilung

Auftraggeber- Mitarbeiterbefragung befragung

laufend

4 x Jahr und bei Projektende

2 x Jahr und bei Projektende

2 x Jahr

Nach Projektende

Wer?

PL

Wie?

Partner

Partner

PL

PL

Partner

Consultant

Prinzip der offenen Tür, d.h., jeder ist frei ansprechbar Prinzip des „fast feedback“ Teamatmosphäre (Teamevents, Ansprache mit Vornamen) Risikofreiheit

Consultant

Consultant

Die Führungskraft beurteilt den Projektmitarbeiter anhand eines vorgegebenen Rasters und der Zielvereinbarung Appraisalgespräch und Schriftform

Mitarbeiter beurteilt die Führungskraft anhand eines Fragebogens UpwardFeedbackGespräch und Schriftform

Partnerrunde und Paten

PL

Consultant

Unter Verwendung Appraisal und UpwardFeedback Mitarbeitergespräch und Schriftform Basis für Gehalt und Beförderung

Partner

Partner

PL

Consultant

1 x Jahr

Auftrag geber

Consultant

PL

1 x im Jahr Anonyme Beschriftliche Befrafragung mit gung zur AuftragFragebogen geberzufrieden Diskussion der heit mit FrageErgebnisse in bogen, auf Partnerrunde und Wunsch anonym mit allen Mitar Mündliche Bebeitern in einem fragung im VorStrategiemeeting feld von Apprai anonym sals und Jahresbeurteilung

Abbildung 85: Personalbeurteilungs- und Feedbacksystem des Inhouse Consultings von Deutsche Post World Net

206


Praxisbox 23: Assessment Center als Sonderform der Personalbeurteilung Da bestimmte Fähigkeiten von Mitarbeitern nur sehr schwer trainierbar sind (dies betrifft insbesondere die persönlichen, sozialen und emotionalen Fähigkeiten), ist die Auswahl von Mitarbeitern mit den entsprechenden Persönlichkeitsprofilen wichtig. Um eine gute Personalentwicklung der Mitarbeiter über die Hierarchiestufen gewährleisten zu können, werden als Consultants im Inhouse Consulting grundsätzlich nur Mitarbeiter eingestellt, denen das Potenzial zugetraut wird, mindestens einen Beförderungsschritt erreichen zu können (zu dem Anforderungsprofil an Projektmanager siehe Abschnitt 4.1.4 ab S. 150). Dies ist wichtig, da nach dem Grundsatz „Grow-or-Go“ gehandelt wird, d. h., ein Mitarbeiter, der zu lange auf einer Stufe bleibt, ohne das Potenzial zu einem weiteren Beförderungsschritt zu zeigen, muss nach einiger Zeit das Beratungsunternehmen verlassen. Zudem werden Mitarbeiter gesucht, die relativ schnell als Projektmitarbeiter in Klientenprojekten einsetzbar sind und dort dann bereits eine Wertschöpfung erbringen können. Geprüft wird auch die intrinsische Motivation der Bewerber, d. h. ob die Bewerber sich aus eigenem Antrieb in Projekten engagieren würden. Um diese Mitarbeiterauswahl beim Einstellen neuer Mitarbeiter sicherstellen zu können, wird ein Assessment-Center eingesetzt. Grundsätzlich ist das Instrument des Assessment Centers auch unternehmensintern für bereits bestehende Mitarbeiter einsetzbar. Aufgrund des aufwändigen Beurteilungssystems beschränkt sich das Inhouse Consulting beim Einsatz von Assessment-Centern auf den Test von Bewerbern. Hierbei absolvieren die Bewerber innerhalb von zwei Tagen eine Reihe von Übungen und werden dabei von geschulten Beobachtern bewertet. Das Assessment-Center ist genau auf das Anforderungsprofil zugeschnitten und besteht aus beratungsspezifischen Übungen, die eigens entwickelt wurden. So werden in Einzelaufgaben die Belastbarkeit und die analytischen Fähigkeiten getestet und in Gruppenarbeit soziale Fähigkeiten. Zudem sind mehrere Interviews Teil des Assessment-Centers. Da das Assessment-Center davon lebt, dass die Bewerber die Aufgaben nicht kennen, soll an dieser Stelle hierauf nicht weiter eingegangen werden. Es gibt aber eine Reihe von Fachbüchern, die genau auf solche Assessment-Center vorbereiten (siehe Hesse/Schrader 2002, Beitz/Loch 2003 und insbesondere Hartenstein et al 2004). Der große Vorteil eines Assessment-Centers ist es aus Sicht des Inhouse Consultings, dass es ermöglicht, die Bewerber in einer der späteren Arbeitssituation im Projekt vergleichbaren Situation zu erleben. Dadurch, dass das Assessment-Center zwei Tage dauert und die einzelnen Aufgaben unter Zeitdruck bearbeitet werden müssen, gelingt es den Bewerbern kaum, sich dauerhaft zu verstellen. Man kann also schon einen recht guten Eindruck bekommen, wie die Bewerber später in einem Projekt arbeiten würden. Nachteile eines solchen Assessment-Centers sind die hohen damit verbundenen Kosten sowie der hohe Personaleinsatz. Da das Personal jedoch die Kernressource im Beratungsgeschäft

Kommunikation

207

ist, ist man beim Inhouse Consultings davon überzeugt, dass dieser Aufwand sich nicht nur lohnt, sondern sogar unvermeidlich ist. Um im Assessment-Center möglichst ohne Verzerrung zu arbeiten, wurde die Entwicklung von einem externen Institut begleitet, welches auch die Durchführung übernimmt und je Durchgang mindestens einen Beobachter stellt. Die weiteren Beobachter werden aus dem Kreis der Partner bzw. Associate Partner des Inhouse Consulting gestellt, wobei eine kurze Schulung als Voraussetzung für die Beobachtung/Bewertung ist.

6.2

Kommunikation

Kommunikation ist eine der Kernaufgaben im Projekt. Projekte sind ja gerade dadurch gekennzeichnet, dass Menschen in Teams cross-funktional zusammenarbeiten. Bei diesen temporären Aufgaben und Organisationsstrukturen ist ein reibungsloser Informationsaustausch, der jedes Teammitglied rasch mit den für ihn wichtigen Informationen versorgt, sehr wichtig. Als Projektleiter kann man nicht davon ausgehen, dass Kommunikationswege etabliert sind oder persönliche Beziehungen ein Manko offizieller Kommunikationswege wettmachen. Anders als bei über einen längeren Zeitraum bereits eingespielten Linienorganisationen ist bei der Bildung von Projekten aufgrund ihres Neuigkeitscharakters und ihrer oft abteilungsübergreifenden Organisation nicht davon auszugehen, dass Kommunikationswege bereits eingespielt sind. Ein Projektleiter hat also grundsätzlich die Aufgabe, die für das Projekt notwendige Kommunikation zu etablieren. Komplexe Projektaufgaben benötigen hierbei insbesondere ein hohes Maß an Informationen zur Durchführung (Lehner 2001b, S. 210). Cross-funktionale Schnittstellen müssen gehandhabt werden (d. h., verschiedene fachliche Disziplinen und Bereiche und Mitarbeiter mit unterschiedlichen Ausbildungen und Zuständigkeiten müssen verständlich miteinander kommunizieren), Informationen über den Projektstand in den verschiedenen Projektmodulen müssen weitergeleitet werden usw. Auch ist es wichtig, dass jeder Mitarbeiter über seine persönlichen Belange informiert ist. Dies bedeutet beispielsweise, dass er weiß, wie er beurteilt wird, wie sein späterer Einsatz nach dem Projekt sein wird, dass er motiviert wird, seine Arbeit zu erledigen, indem ihm die Bedeutung vermittelt wird (Meredith/Mantel 1995, S. 126-127) etc. Projekte sind für die Mitarbeiter Ausnahmesituationen (jedenfalls für die meisten Mitarbeiter), in denen sie ein großes Bedürfnis nach Informationen über ihre persönliche Situation besitzen. Gute Kommunikation kann eine Reihe von Zielen im Projekt erreichen (vgl. auch Portny 2001, S. 251):

208


Motivation der Mitarbeiter (siehe auch Abschnitt 6.3) durch Transparenz und Anerkennung, zielorientiertes Arbeiten im Projekt, durch Kommunikation und Feedback über Ziele, hohe Produktivität der Mitarbeiter durch Vermeidung von Dysfunktionalitäten, schnelles Erkennen von Problemen im Projekt und Lösung von Konflikten (siehe auch Abschnitt 6.4.2).

Projektmitarbeiter sind nicht nur daran interessiert, möglichst die für sie und ihre Arbeit relevanten Informationen zu erhalten. Sie können umgekehrt auch andere Personen mit einer Vielzahl von wichtigen Informationen versorgen. Dies sind zum einen Informationen über die „normale“ Projektarbeit (Status der Arbeit, Zwischenergebnisse usw.), zum anderen Informationen über Fehler, Entwicklungen oder Probleme, die sie erkannt haben. Nur wenn ein Kommunikationsmanagement im Projekt sicherstellt, dass Informationen in alle Richtungen fließen, können diese wichtigen Informationen schnell an die richtige Stelle weitergeleitet werden. Abbildung 86 stellt ein einfaches Schema der einseitigen und zweiseitigen Kommunikation sowie der Netzwerkkommunikation grafisch dar. Da eine Vielzahl von relevanten Informationen im Projekt bei den Projektmitarbeitern anfällt, ist eine rein zentralistisch vom Projektleiter ausgehende, einseitige Kommunikationsstruktur für ein Projekt nicht geeignet. Besser ist eine zweiseitige Kommunikation, die auch von den Projektmitarbeitern (in der Abbildung Consultants) ausgeht. Im besten Fall entsteht im Projekt eine Art Netzwerkkommunikation, in der die Informationen in alle Richtungen und über alle Hierarchiestufen hinweg fließen. Dies stellt die schnellste Art der Kommunikation dar, erfordert jedoch eine gute Kommunikationsstruktur, denn die Projektteilnehmer müssen wissen, welche Information für wen relevant ist. Außerdem ist sicherzustellen, dass der Projektleiter als verantwortliche Person immer auch alle notwendigen Informationen erhält und er nicht aus dem Kommunikationsfluss ausscheidet. Es ist die Aufgabe des Projektleiters sicherzustellen, dass eine Netzwerkkommunikation möglich ist. Die Kommunikation kann auf zwei Ebenen erfolgen, die im Folgenden erläutert werden sollen, der informellen und der formellen Kommunikation. Formelle Kommunikation ist quasi die offizielle Kommunikation im Projekt. Informelle Kommunikation ist die zwischenmenschliche Kommunikation auf privater Ebene (Held et al. 1999, S. 13).

Kommunikation

einseitige Kommunikation

zweiseitige Kommunikation

209

Sender

Projektleiter

z. B. Information über den Projektstatus

Consultant

Empfänger

Consultant

Sender/ Empfänger

z. B. Information über Probleme oder Ideen

Sender/ Empfänger

Projektleiter z. B. Information über den Projektstatus

Consultant

Netzwerkkommunikation

Sender/ Empfänger Sender/ Empfänger

Projektleiter

…

Mitarbeiter

Sender/ Empfänger

… Vgl. hierzu ergänzend Litke 1995, S. 223 Abbildung 86: Kommunikationsarten im Projektmanagement

6.2.1

Informelle Kommunikation

Informelle Kommunikation findet – so wurde es im vorherigen Absatz definiert – auf privater Ebene statt. Sie ist daher meist spontan, schnell, ungeplant und beinhaltet vielfältige, vorher nicht festgelegte Themen. Die Teilnehmer sind eher zufällig und es findet keine Dokumentation statt. Die Kommunikation ist sehr interaktiv und hat eine soziale Funktion (Held et al. 1999, S. 12). Nun ist es aber so, dass bei informeller Kommunikation nicht nur private Informationen weitergegeben werden, sondern auch projektbezogene Inhalte. Sie nimmt daher auch eine projektbezogene Funktion wahr. Daher ist informelle Kommunikation zunächst einmal hilfreich für das Projekt. Sie funktioniert sehr schnell und problemorientiert und ergänzt so die offizielle Kommunikation. Quasi nebenbei werden wichtige Botschaften weitergegeben und diese Informationen erlangen durch den privaten Kontext auch noch eine hohe Aufmerksamkeit und Glaubwürdigkeit. Beispiele für die positiven Effekte für die Projektarbeit sind vielfältig: Wichtige Informationen werden so schnell auf dem „kleinen Dienstweg“ weitergegeben oder kritische Fragen werden ad hoc zur Klärung gebracht (Held et al. 1999, S. 12). Aufgrund der

210


informellen Natur der Kommunikation bestehen hierbei kaum Hindernisse und es erfolgt der Austausch der für die Personen relevanten Informationen. Informelle Kommunikation ist darüber hinaus auch die Basis einer guten Zusammenarbeit in einem Team, da sie die Voraussetzung für ein auch zwischenmenschlich gut funktionierendes Team ist. Informelle Kommunikation ist also grundsätzlich zu fördern. Informelle Kommunikation ist auf verschiedene Arten förderbar. Zu nennen sind die Einrichtung von Teambüros, Kaffee-Ecken, gemeinsames Mittagessen, Feiern, Teamevents und Veranstaltungen etc. Zudem erleichtert es die informelle Kommunikation, wenn Menschen mit ähnlichem Alter, sozialer Situation und Bildungsniveau zusammenarbeiten, da dies eine Basis für ähnliche Interessen und Aktivitäten im privaten Bereich ist, die dann Gegenstand der informellen Kommunikation sind. Die nächste Praxisbox (Praxisbox 24) zeigt ein Beispiel der Förderung der informellen Kommunikation. Die Abgrenzung von Maßnahmen zur Förderung der informellen Kommunikation und der Teambildung (siehe Praxisbox 26) ist hierbei fließend, da die informelle Kommunikation die Teambildung fördert.

Praxisbox 24: Förderung informeller Kommunikation Im Inhouse Consulting von Deutsche Post World Net wurde ein Stammtisch eingerichtet, bei dem sich die Consultants, Projektleiter und Partner einmal im Monat in einem informellen Umfeld außerhalb der Arbeitsumgebung treffen. Die Teilnahme ist freiwillig und auf eigene Kosten und wird auch in keiner Form nachgehalten. Jeder Mitarbeiter kann nach eigenem Interesse im Laufe des Abends hinzukommen (oder eben auch nicht). Es wird keine Agenda vorgegeben, es ist keinerlei fachlicher oder sonstiger Inhalt vorgegeben. So finden die Gespräche über unterschiedlichste Themen statt, sei es privat oder auch beruflich. Da die Mitarbeiter in unterschiedlichen Projekten eingesetzt sind, findet hier bei Bedarf auch ein informeller, projektübergreifender Austausch statt. Es hat sich gezeigt, dass hierbei quasi als Nebeneffekt eine Vielzahl relevanter Informationen ausgetauscht wird. Hauptzweck des Treffens ist es, eine Teamveranstaltung für das ansonsten dezentral arbeitende Beratungsunternehmen zu haben. Eine weitere Maßnahme zur Förderung der informellen Kommunikation ist das Aufstellen eines Tischfußball-Automaten (Kicker). Dieser steht im Home-Office in Bonn und ist frei zugänglich. Der Kicker hat sich für Freitage und später abends als Kommunikationszentrum herausgebildet. Zusätzlich haben sich jahreszeiten-abhängig sportliche FreizeitEvents herausgebildet.

Informelle Kommunikation kann allerdings auch negativ für den Projekterfolg werden, wenn: zu viel Zeit mit nicht fachlicher Kommunikation verbracht wird,

Kommunikation

211

negative Kommunikation erfolgt und so die Unzufriedenheit eines Mitarbeiters auf andere Mitarbeiter im Projekt übertragen wird. falsche Informationen unkontrolliert in Umlauf gebracht werden oder Informationen an einen Adressatenkreis weitergegeben werden, für den sie nicht bestimmt waren.

Diese Gefahren können sich durchaus als beträchtlich darstellen, wenn nämlich die Projektarbeit hierdurch gefährdet ist. So kann eine Verunsicherung der Mitarbeiter aufgrund falscher Informationen die Arbeitsleistung erheblich senken, oder Fehlinformationen können dazu führen, dass falsche Entscheidungen getroffen werden. Trotz dieser Gefahr kann es nicht die Aufgabe von Führungskräften sein, die informelle Kommunikation direkt zu überwachen. Dies würde als „Bespitzelung“ privater Äußerungen zu Recht negativ von den Betroffenen wahrgenommen werden. Der Projektleiter muss aber durchaus darauf achten, dass die beschriebenen negativen Aspekte nicht überhand nehmen. Dies kann beispielsweise durch regelmäßige Personalgespräche erfolgen. Negative Folgen von informeller Kommunikation falscher oder ungewollter Inhalte können durch gezielte formale Gegenkommunikation der richtigen Fakten vermindert werden. Das Entstehen von Gerüchten und Falschinformationen in der informellen Kommunikation kann durch rechtzeitige, an den Bedürfnissen der Projektmitarbeiter orientierte formale Kommunikation schon im Vorfeld verringert werden. Wenn die Mitarbeiter über ein sie betreffendes Thema formal hinreichend informiert worden sind, besteht keine Notwendigkeit mehr, informell anders lautende Gerüchte zu verbreiten.

6.2.2

Formelle Kommunikation

Formelle Kommunikation ist die „offizielle“ Kommunikation im Projekt. Sie ist geplant, hat festgelegte Themen und einen formalen geschäftsmäßigen Stil (Held et al 1999, S. 13). Diese Kommunikation kann auf verschiedene Art und Weise erfolgen. Hier soll auf schriftliche Kommunikation und auf Meetings eingegangen werden. Dabei sollen einige Tipps aufgeführt werden, die die Kommunikation erleichtern können.

Schriftliche Kommunikation Schriftliche Kommunikation ist dann von Vorteil, wenn es darum geht, Daten und Fakten zu vermitteln. Es kann eine große Menge Informationen vermittelt werden, die sorgfältig und eindeutig aufbereitet ist. Zudem kann man mit schriftlicher Kommunikation einen großen Adressatenkreis erreichen (Portny 2001, S. 252), der diese Informationen selbst dann auch

212


wiederum weitergeben kann. Für wichtige, verbindliche Informationen sollte daher immer der schriftliche Weg gewählt werden. Nur mit ihr kann verbindlich festgehalten werden, dass bestimmte Informationen weitergegeben wurden. Über E-Mail-Versand ist schriftliche Kommunikation zudem sehr kostengünstig und schnell möglich.11 Allerdings ist hierbei die wahrgenommene Bedeutung beim Empfänger geringer. Dies kann dazu führen, dass nicht alle Adressaten tatsächlich die Informationen aufnehmen. Schriftliche Kommunikation hat jedoch einige Einschränkungen in ihrer Wirksamkeit: Die Kommunikation ist einseitig, d. h., es besteht nicht die direkte Möglichkeit für Rückfragen, falls der Adressat den Inhalt nicht versteht oder sonstige Fragen dazu hat. Bei E-Mail-Kommunikation gilt diese Einschränkung nur begrenzt, da sehr schnell Rückfragen gestellt werden können. Ob dann tatsächlich direkt geantwortet wird, ist natürlich dennoch fraglich. Es kann nur sehr bedingt kontrolliert werden, ob der Adressat die Information tatsächlich gelesen oder verstanden hat. Als Autor können Sie also den Erfolg der Kommunikation nicht beurteilen. Auch Lesebestätigungen bei E-Mails sind nicht zuverlässig, da sie technisch nicht sicher sind und keinesfalls angeben, ob die Information vom Empfänger auch tatsächlich durchgelesen und/oder verstanden wurde. Die Reaktion des Adressaten auf die schriftliche Kommunikation ist in der Regel nicht bekannt, d. h., es ist unklar, ob der Adressat zustimmt. Die Beziehungsebene der Kommunikation (d. h. die Art und Weise, wie miteinander kommuniziert wird) ist in der schriftlichen Form nicht so gut vermittelbar, da die nonverbalen Kommunikationselemente, die diese Ebene der Kommunikation stark transportieren, fehlen. Dies heißt dass aus der schriftlichen Kommunikation nur schwer erkenntlich ist, ob der Absender verärgert war, Sympathie verspürte, Ängste hat, Erwartungen damit verbindet etc. (vgl. Litke 1995, S. 221). Wesentliche Informationsteile fehlen daher.

Diese Einschränkungen können nicht grundsätzlich umgangen werden, jedoch kann die Beachtung von ein paar Regeln die sich daraus ergebenen Probleme etwas verringern (Portny 2001, S. 253): Jedes Schriftstück sollte ein klares, einfaches Ziel besitzen. Nur wenn der Autor in der Lage ist, die Grundidee des Papiers auch kurz in ein oder zwei Sätzen zu beschreiben, wird der Leser diesen Inhalt in der Unterlage erkennen können. Als Autor muss man sich also klar machen, was das Ziel der Unterlage ist, bevor der Text entsteht. Dazu gehört auch, dass die nächsten Schritte bzw. die Implikationen aus dem Inhalt explizit aufgeführt werden sollten. Strukturierung erleichtert die Informationsaufnahme. Prägnanz erhöht die Chance, dass die Informationen gelesen werden. In vielen Projekten gibt es daher die Regel: „One page on-

11

Sehr differenziert zur Wirkung des Mediums E-Mail siehe Meißner (1998).

Kommunikation

213

ly.“ Ist dies nicht möglich, sollte eine kurze Management Summary (Executive Summary) erstellt werden, die kurz die wesentlichen Aspekte zusammenfasst. Wiederkehrende Kommunikation ähnlichen Inhalts (wie zum Beispiel wöchentliche Projektstatusberichte oder Statusberichte über den Launch eines Produktes) sollten eine wiederkehrende Struktur haben, die auch optisch erkennbar ist. Dies erleichtert das Lesen (und damit erhöht es die Wahrscheinlichkeit, dass etwas gelesen wird) dadurch, dass der Leser die Struktur bereits kennt und sofort in die für ihn relevanten Abschnitte springen kann. Viele Beratungsunternehmen geben für bestimmte Arten der schriftlichen Kommunikation Vorgaben für die Struktur. So existieren in der Regel Vorlagen für Protokolle (siehe den nächsten Abschnitt), Statusberichte (siehe Abbildung 75 auf S. 180), Angebote (siehe Kapitel 2.4.1 ab S. 56), Zeitpläne etc. Sorgfalt bei der Texterstellung wird von den Empfängern wahrgenommen. Ein Text mit vielen Flüchtigkeitsfehlern spiegelt die Einstellung des Verfassers wider und die Leser nehmen die Botschaft nicht mehr so ernst wie die in einer fehlerfreien und sorgfältig gestalteten Unterlage. Berater neigen teilweise dazu, sich einer Fachsprache zu bedienen, die eine Vielzahl von Anglizismen verwendet. Begriffe wie „Appraisal“, „Scope“, „Target“, „Show stopper“, „Deliverables“, „Duedate“, „Master“, „Slides“, „Change Request“ usw. sind hier im Sprachgebrauch vorhanden und gelten als normal. Wird mit Mitarbeitern des Klientenunternehmens kommuniziert, kann jedoch nicht vorausgesetzt werden, dass diese Begriffe bekannt sind. Es ist möglich, dass diese einfach nicht verstanden, falsch interpretiert oder sogar als arrogant wahrgenommen werden. Es ist also darauf zu achten, dass alle Empfänger auch die verwendeten Fachausdrücke verstehen und deren Verwendung akzeptieren. Ggf. sollten bestimmte Fachausdrücke vermieden und durch allgemein verständliche Begriffe ersetzt werden. Im Extremfall gehört auch dazu, Unterlagen für bestimmte Adressatengruppen neu zu formulieren. Sinngemäß gilt dieses natürlich für sämtliche von Fachleuten in Unternehmen verwendeten Fachausdrücke und Formulierungen. Jedes Schriftstück muss einen Absender tragen und dessen Kontaktinformationen, so dass er für Rückfragen erreichbar ist. Insbesondere ist eindeutig zu kennzeichnen, ob es sich um ein Dokument der Fachseite oder der Beratung handelt. Die Verwendung von Formatvorlagen der Fachseite durch die Beratung kann hierbei zu Missverständnissen führen, die dringend zu vermeiden sind. Bei wichtigen Informationen sollte sichergestellt werden, dass der Empfänger die Nachricht erhalten hat. Das kann durch formalisierte Umläufe geschehen, bei denen der Leser den Umlauf abzeichnen muss – oder in Einzelfällen durch die mündliche oder telefonische Nachfrage. Auch kann um schriftliche oder telefonische Antwort bzw. Zustimmung bis zu einem gesetzten Termin gebeten werden.

214


Persönliche Kommunikation Im Rahmen formaler Kommunikation in Projekten sind Meetings die gebräuchliche Form persönlicher Kommunikation. Der Begriff des Meetings wird heutzutage recht inflationär gebraucht. Aber nicht jedes private Zusammentreffen ist ein Meeting. Von einem Meeting soll daher hier nur gesprochen werden, wenn mindestens zwei Personen gezielt zusammentreffen, um eine das Projekt betreffende Thematik zu besprechen. Die deutsche Bezeichnung der Besprechung meint hierbei denselben Sachverhalt – im Projektmanagement hat es sich jedoch durchgesetzt, die angelsächsische Formulierung Meeting zu verwenden. In den Projekten gibt es Meetings an vielen Stellen, sei es als Kick-off-Meeting, Statusmeeting, Jour Fixe, Kreativmeeting zur Ideensammlung, Entscheidungsmeeting bei der Festlegung der weiteren Vorgehensweise etc. Als direkte und interaktive Form der Kommunikation sind Meetings gut geeignet, Informationen weiterzugeben. Der „Sender“ kann unter Zuhilfenahme von Gestik, Mimik, Dokumenten oder ganzen Präsentationen seine Informationen vermitteln. Er kann im direkten Feedback sicherstellen, dass die Informationen auch verstanden wurden. Der „Empfänger“ kann Verständnisfragen stellen, wenn ihm etwas unklar ist. Darüber können weitere Informationen abgefragt werden, wenn zusätzlicher Informationsbedarf besteht. Der wichtigste Punkt in einem Projektmeeting ist aber, dass über die gemeinsame Diskussion von Punkten bessere Lösungen gefunden werden können, als eine Person dies einzeln vermag. Dies liegt darin begründet, dass Experten verschiedener Fachrichtungen interdisziplinär an einer Lösung arbeiten können. Einseitige Lösungen können durch Integration aller Experten vermieden werden. Ein Meeting ist darüber hinaus ein sehr gutes Kommunikationsinstrument, da schnell ein gemeinsames Verständnis für ein Thema gewonnen und verbindlich abgefragt werden kann, ob für bestimmte Themen die gleiche Sichtweise besteht. Neben der verbalen Kommunikation im Meeting selbst kann bzw. sollte das Ergebnis eines Meetings schriftlich fixiert werden. Um die Stärken ausnutzen zu können, die das Kommunikationsinstrument Meeting bietet, gibt es jedoch ein paar Voraussetzungen. Wenn diese gegeben sind, kann ein Meeting seine volle Wirkung entfalten: Zu Meetings sollte rechtzeitig und schriftlich (bzw. per E-Mail) eingeladen werden. Allen Teilnehmern sollte das Ziel des Meetings im Vorfeld kommuniziert werden (in der Einladung). Die Teilnehmer müssen im Vorfeld wissen, wer außer ihnen noch teilnimmt. Dabei ist im Hinblick auf das Ziel wichtig, sorgfältig zu planen, wer teilnehmen soll. Jeder Teilnehmer muss seine Rolle in dem Meeting kennen. Er muss wissen, welche Erwartungen an ihn im Meeting gestellt werden. Nur so werden die Teilnehmer in die Lage versetzt, sich angemessen vorbereiten zu können.

Kommunikation

215

Der geplante Startzeitpunkt eines Meetings sollte eingehalten werden. Unpünktlichkeit kommuniziert eingeschränkte Wichtigkeit des Themas und mangelnde Aufmerksamkeit des Managements. Jedes Meeting sollte einen Verantwortlichen haben, der darauf achtet, dass der Zeitplan eingehalten wird, dass das Ziel des Meetings verfolgt wird und dass alle relevanten Teilnehmer einen Beitrag zum Ziel geben. Die Ergebnisse des Meetings sollten in einem Ergebnisprotokoll festgehalten werden. Hierzu ist vor dem Start des Meetings ein Protokollant festzulegen, der auch die erforderliche Fachkenntnis besitzt. Also ist es nicht immer sinnvoll, dass „der Neue“ das Protokoll führt, wenn dieser thematisch noch nicht in der Lage ist, die richtigen Punkte zu protokollieren. Ein Ergebnisprotokoll ist auch eine hervorragende Möglichkeit, den Nachteil eines Meetings wettzumachen, dass es immer nur eine begrenzte Teilnehmeranzahl gibt. Durch die Verteilung eines Ergebnisprotokolls kann der Adressatenkreis sehr stark ausgeweitet werden. Jedes Meeting sollte mit einem verbindlichen Schlussstatement enden. Es sollte die wesentlichen Erkenntnisse zusammenfassen und das weitere Vorgehen aufzeigen. Meetings sollten pünktlich enden. Nach dem anvisierten Endzeitpunkt sinkt in der Regel die Aufmerksamkeit der Teilnehmer. Nach dem Meeting sollte eine Manöverkritik durchgeführt werden. D. h., der Leiter des Meetings bespricht mit den Teilnehmern oder einem Teil der Teilnehmer, wie effizient das Meeting abgelaufen ist. Hierbei wird insbesondere hinterfragt, ob das Ziel erreicht wurde, ob die Möglichkeiten des Meetings ausgeschöpft wurden, ob alle Teilnehmer ausreichend einbezogen wurden und welche Änderungen im Ablauf des Meetings in der Zukunft hilfreich wären. Wichtig ist diese Manöverkritik insbesondere dann, wenn Consultants Meetings zusammen mit Mitarbeitern eines Klientenunternehmen durchführen. Das Meeting ist dann Teil der Beratungsleistung, und alle Möglichkeiten, dies besser zu gestalten, sollten genutzt werden. Beschlüsse eines Meetings müssen relevant sein. Die im Protokoll festgehaltenen Beschlüsse sollten vom Einladenden nachgehalten werden. Dies bezieht sich natürlich insbesondere auf Punkte, die abzuarbeiten sind (so genannte to-do’s), deren tatsächliche Abarbeitung kontrolliert werden sollte.

Es lohnt sich, in der Projektarbeit sehr strikt auf die Einhaltung der Regeln für Meetings zu achten. Auch wenn diese Regeln manchmal etwas übertrieben erscheinen, besitzen sie jedoch einen großen Hebel, um dem Unternehmen Geld zu sparen. Obwohl in der Regel keine Belastung einer Projektkostenstelle erfolgt, so kosten Meetings doch tatsächlich große Geldsummen. Dies liegt daran, dass viele Mitarbeiter eine erhebliche Zeit in Meetings verbringen. So kann es bei Projektleitern sein, dass diese weit mehr als 50% ihrer Arbeitszeit in Meetings zubringen. Eine Effizienzsteigerung bei der Verwendung dieser Zeit ist also für den Projektleiter deutlich spürbar. Und wenn es durch die Einhaltung der Regeln gelingt, ein Meeting, an dem 20 Personen teilnehmen, um eine Stunde zu kürzen, dann hat man 20 Arbeits-

216


stunden gespart. Berechnet man diese als zwei Beratertage, so handelt es sich schon um eine Ersparnis im unteren vierstelligen Euro-Bereich. Dauern Meetings länger und dienen sie der aktiven Erarbeitung neuer Inhalte durch die gemeinsame Entwicklung neuer Lösungen, dann wird oft von Workshops gesprochen. Ein Workshop stellt grundlegend die gleichen Anforderungen wie ein Meeting, jedoch sollte die Planung noch genauer sein. Dies betrifft insbesondere die Auswahl der geeigneten Teilnehmer, die die inhaltliche Arbeit im Workshop übernehmen sollen sowie die Auswahl des Leiters. Dieser muss als Moderator sicherstellen, dass er, ohne inhaltlich einengend zu wirken, alle Teilnehmer optimal einbezieht und dass deren Fachwissen genutzt wird. Außerdem ist aufgrund der Dauer des Workshops ein besonderes Augenmerk auf die Planung des Ablaufs und der Vorgehensweise zu legen. Es muss im Vorhinein klar sein, welche Struktur der Workshop hat, da sonst leicht eine kontraproduktive Eigendynamik eintritt.

Die Kommunikationsstruktur in einem Projekt Wie wir gesehen haben, eignen sich unterschiedliche Formen der Kommunikation aufgrund ihres unterschiedlichen Informationsgehaltes in unterschiedlichen Situationen und für unterschiedliche Zwecke besser oder schlechter als andere. Auch haben unterschiedliche Adressaten oder Adressatengruppen unterschiedliche Informationsbedürfnisse. Um in komplexen Projektsituationen nicht den Überblick zu verlieren, bietet es sich daher an, die Regelkommunikation zu planen. In Projekten und insbesondere auch im Multi-Projektmanagement werden daher Kommunikationsstrukturen erstellt, die sicherstellen sollen, dass die richtigen Leute zur richtigen Zeit über das richtige Medium mit den richtigen Informationen versorgt werden. Ein Beispiel für eine Kommunikationsstruktur ist in Abbildung 87 auf Seite 217 wiedergegeben. Inhaltlich muss zusätzlich zu einer solchen Struktur natürlich noch festgelegt werden, was die einzelnen Berichte und Protokolle umfassen sollen. Ein Projektstatusbericht, mit dem der Projektmanager den Lenkungsausschuss über den Fortschritt des Projektes informiert, kann natürlich verschiedene Strukturen haben. Dies hängt vom Informationsinteresse des Lenkungsausschusses ab. Beispielsweise kann der Lenkungsausschuss lediglich am Fortschritt eines bestimmten Themas (etwa der Implementierung einer bestimmten Maßnahme) interessiert sein, er kann aber auch eine genaue Rechenschaft über die Tätigkeiten in einem bestimmten Zeitraum verlangen. Es bietet sich also an, hierzu eine Struktur vorzugeben, die die Erfordernisse verdeutlicht. Ein Beispiel ist im Kapitel 2 in Praxisbox 5: Angebotsmaster (Auszug) auf Seite 62 aufgeführt.

Kommunikation

217

Meetings Lenkungsausschuss (LA)

Steuerkreis Projektleiter

Teilprojekt 1

Teilprojekt 2

Berichte

Meeting: KW 32, 37, 44, 52 jeweils Mo 10.00 – 13.00 Uhr, Raum 123 LA-Protokolle werden dem Steuerkreis zur Verfügung gestellt Meeting: 14-täglich, jeweils Do 14.00 – 16.00 Uhr, Raum 234 Steuerkreis-Protokolle werden den Teilprojektleitern zur Verfügung gestellt wöchentliche Statusmeetings jeweils Mi 14.00 – 16.00 Uhr, Raum 345 Teil Teilprojekt-Protokolle werden projekt dem Projektleiter zur 3 Verfügung gestellt

Projektleiter erstellt: - schriftlichen Statusbericht 1x die Woche für LA-Mitglieder - Projektstatusmeldung für Projektbüro - Projektsteckbrief für Personal- und Organisationsabteilung Teilprojektleiter erstellt schriftlichen Statusbericht 1x die Woche für Projektleiter

Übergreifende Kommunikationsmaßnahmen: Einrichtung eines gemeinsamen Computer-Laufwerkes (share), auf den alle Projektteilnehmer zugreifen können. Hierauf sind sämtliche Projektdokumente entsprechend der vorgegebenen Struktur zu speichern Auf dem share wird ein Verteiler mit den Kontaktdaten aller Projektteilnehmer und deren Funktion bereitgestellt und aktualisiert Ein eMail-Verteiler für alle Projektteilnehmer und Gremien wird in Outlook bereit gestellt

Abbildung 87: Beispiel für eine Übersicht zur Projekt-Kommunikationsstruktur

In dem Beispiel aus Abbildung 87 handelt es sich um eine Darstellung der Regelkommunikation, wie sie beispielsweise durch den Projektleiter in Abstimmung mit den Gremien erstellt wird. Diese würde dann entsprechend im Kick-off-Meeting vorgestellt und verabschiedet werden. Dieses Kick-off-Meeting (siehe auch Abschnitt 1.6) übernimmt eine weitere wichtige Funktion in der Kommunikation. Denn selbstverständlich müssen Mitarbeiter auch über das Projektziel, -vorgehen und -ergebnis informiert sein. In Ergänzung zu den in der Abbildung aufgeführten Maßnahmen können daher noch das Kick-off-Meeting und die Endpräsentation extra aufgeführt werden. In der Abbildung sind diese lediglich als erster und letzter Lenkungsausschuss-Termin zu erkennen. Die Kommunikation mit den Mitarbeitern muss aber laufend erfolgen, damit ggf. sich ändernde Ziele oder andere aktuelle Nachrichten kommuniziert werden können. Hierbei darf natürlich auch kein Unterschied gemacht werden zwischen Mitarbeitern des Beratungsunternehmens und des Klientenunternehmens. Die Kommunikation muss unabhängig von diesen Organisationen in der Projektorganisation erfolgen.

Praxisbox 25: Kick-off-Meeting Aufgrund der Bedeutung von Kick-off-Meetings für den weiteren Projektverlauf hat das Inhouse Consulting eine Vorgabe definiert, die als Basis für Kick-off-Meetings dient und dabei natürlich entsprechend adaptiert werden kann.

218


Unter anderem gibt es einen Vorschlag für die Ziele und Teilnehmer eines Kick-offMeetings sowie eine Agenda, was im Rahmen des Meetings alles besprochen bzw. geklärt werden sollte. Die folgenden beiden Abbildungen 88 und 89 zeigen diese beiden Vorlagen.

Project-Kick-off-Meeting Objectives

Developing a common understanding on – strategic benefits of the project – Project objectives and project environment – How to proceed to make the project a success (rough planning, next steps) Building a high-performing project team

Participants

Assignment Manager Project team (IC and client) Experts Client (temporary presence) Sponsor (temporary presence)

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 88: Ziele und Teilnehmer eines Kick-off-Meetings Hauptziel eines Kick-off-Meetings soll es entsprechend sein, ein gemeinsames Verständnis des Projektziels und geplanten Projektnutzens zu gewinnen. Die gemeinsame Vorgehensweise, wie das Projekt erfolgreich zu Ende geführt werden kann, soll abgestimmt werden. Zudem soll das Meeting auch genutzt werden, um ein leistungsfähiges Projektteam zu etablieren. Teilnehmer sollten entsprechend der zuständige Partner oder Associate Partner der Beratung sein, der das Projektangebot verantwortende Projektleiter („Assignment Manager“), die Projektteams von Inhouse Consulting und des Auftraggebers, notwendige Fachexperten, um die Projektarbeit zu diskutieren, der Auftraggeber (zumindest zeitweilig – dies ist auch aus Fragen der Motivation der Teammitglieder wichtig) und ggf. Sponsoren (vgl. Praxisbox 18: Stakeholdermanagement ab S. 172). Die Standard-Agenda (Abbildung 89) sieht zunächst die Klärung des gemeinsamen Projektauftrags vor. Dies dient der Schaffung von Klarheit und des gemeinsamen Verständnisses der Projektarbeit. Hierzu wird allen Teilnehmern die Vorarbeit zum Projekt erläutert, die Ziele werden dargestellt, Stakeholder und Projektorganisation werden erläutert. Im zweiten Teil wird auf das Projektteam eingegangen. Gegenseitige Erwartungen werden abgefragt und Teamregeln werden vereinbart (etwa die Teilnahme an gemeinsamen Teambesprechungen). Zudem wird versucht, über die Stärken und Schwächen innerhalb des Projektteams Transparenz zu schaffen, damit keine falschen Erwartungen bestehen. Ab-

Personalmotivation

219

sehbare Konflikte werden jetzt schon angesprochen. Hierdurch werden sie entschärft, da über das rationale Ansprechen möglicher Konflikte die emotionale Eskalation erschwert wird. Der dritte Teil dient der Projektplanung. Es erfolgt die Planung von Arbeitspakten (WBS = Work Breakdown Structure), die Zuordnung von Verantwortlichkeiten, eine erste Zeitplanung, ggf. eine Detailplanung für bestimmte Aspekte, und es wird festgehalten, wann das nächste Treffen stattfindet.

Project-Kick-off-Meeting Standard Agenda 1. Clarification of contract Presentation: Background and early history Presentation and Clarification of project objectives (context model) Stakeholder Mapping Project organization and roles (client, customer, assignment manager & client counterpart, Project team 2. Building project team Discuss (personal) expectations Agree on project rules (team meetings, reviews etc.) Discuss strengths and weaknesses of project team (and derive possible actions) Discuss and prepare for possible conflicts and how to deal with them 3. Planning Define WBS and possible sub-projects Assign technical responsibilities Elaborate rough time planning over entire project cycle Elaborate detailed project plan for imminent project phase Define next steps up to the next meeting

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 89: Ziele und Teilnehmer eines Kick-off-Meetings

6.3

Personalmotivation

Damit ein Projekt erfolgreich verläuft, müssen nicht nur die Arbeitsabläufe effizient sein, sondern sie müssen auch reibungslos ablaufen. Dies wird dann eher der Fall sein, wenn die Mitarbeiter des Projektes hierzu motiviert sind und sich diesbezüglich anstrengen. Daher ist die Motivation der Mitarbeiter eine der wichtigsten Aufgaben eines Projektleiters.

220


Motivation ist hierbei die Gestimmtheit oder besser Bereitschaft etwas zu tun. Es ist letztendlich die Eigensteuerung einer Person, aktiv zu werden. Für das Projektmanagement muss entsprechend versucht werden, die Motivation der Projektmitglieder zur Durchführung der Projektarbeit und zum aktiven Einsatz im Sinne des Projektziels zu erlangen bzw. zu steigern. Man spricht hier von der spezifischen Motivation, bezogen auf das Projekt. Diese ist von der allgemeinen Motivation eines Menschen zu unterscheiden. Die allgemeine Motivation ist das Aktionspotenzial eines Menschen, dessen kreative Idee und dessen eigener Antrieb. Nur wenn diese allgemeine Motivation auf das Projektziel projiziert werden kann, wird sich der Projektmitarbeiter auch im Sinne des Projektes engagieren. Dies wird gelingen, wenn das Projektziel eine subjektive Bedeutung für den Mitarbeiter erlangt. Gelingt dies nicht, wird er seine allgemeine Motivation auf andere Dinge richten. Wodurch wird die Motivation des Mitarbeiters beeinflusst? Es gibt grundsätzlich zwei Variablen, die die Motivation des Mitarbeiters beeinflussen (Drumm 2005, S. 491): Der Mitarbeiter selbst durch eigenen Antrieb, Drang, Willen, Wunsch, Streben, Interesse etc. Es handelt sich also um einen inneren Antrieb, oder intrinsische Motivation. Man empfindet hierbei die Arbeit selbst und ihr Ergebnis als Belohnung für seine Bemühungen. Belohnungen, Anreize, Prämien, persönliche Zielvorgaben etc. Es handelt sich also um einen Antrieb etwas zu tun, der daraus resultiert, andere Dinge zu erreichen. Die Handlung ist also Mittel zu einem anderen Zweck, nämlich eine Belohnung hierfür zu erlangen. Man spricht hierbei von extrinsischer Motivation.

Die intrinsische Motivation hat nun den Vorteil, dass sie für die Unternehmen billiger ist, denn sie erfordert keine weiteren Belohnungen. Auch ist sie nach gängiger Meinung dauerhafter als die extrinsische Motivation (Drumm 2005, S. 491). Problematisch ist, dass sie von außen schwer erzeugbar oder förderbar ist. Im praktischen Projektalltag wird man daher nicht ohne extrinsische Motivation auskommen. Was kann man aber nun in Bezug auf die intrinsische Motivation unterstützend unternehmen? Zunächst ist bei der Auswahl der Projektmitarbeiter darauf zu achten, dass diese intrinsisch für die Projektarbeit motiviert sind. Die Managementberatung sollte dies schon bei der Personaleinstellung prüfen, da die Mitarbeiter ja fast ausschließlich in der Projektarbeit eingesetzt werden. Die intrinsische Motivation ist in einem Gespräch oder besser noch in einem Assessment Center abprüfbar (vgl. hierzu Praxisbox 23 ab S. 206). Bei der Projektbesetzung mit Mitarbeitern aus dem Klientenunternehmen ist die einfachste Methode, die Mitarbeiter offen zu fragen, ob sie Interesse an der Projektarbeit haben. Des Weiteren kann man die Rahmenbedingungen schaffen, die es den Projektmitarbeitern erlauben, Stolz auf ihre Bemühungen und ihren Einsatz zu entwickeln. Das heißt, es muss die Möglichkeit zu eigenverantwortlicher Arbeit gegeben sein. Engt der Projektleiter die Mitarbeiter zu sehr ein, dann können diese keine eigenständigen Ergebnisse produzieren und folglich auch keine Motivation hieraus bzw. hierfür erlangen. Ein guter Projektleiter muss also delegieren und in der Lage sein können, Verantwortung abzugeben. Das heißt nicht, dass er nicht kontrollieren darf bzw. muss, sondern dass er Freiheiten in der Ar-

Personalmotivation

221

beitsweise zulassen muss. Ein weiterer Punkt, der die wahrgenommene Eigenverantwortung stützt, ist die Verdeutlichung der Bedeutung der Arbeit des einzelnen Projektmitarbeiters. Sieht dieser seinen Beitrag zum Gesamtprojekt, dann kann er hierauf auch eher stolz sein. Es ist also die Aufgabe des Projektleiters, diese Bedeutung in Gesprächen, im Rahmen der Statusmeetings oder des Kick-off-Meetings herauszustellen. Auch sollte über die Fortschritte im Gesamtprojekt berichtet werden, damit die einzelnen Mitarbeiter den Fortschritt des Ganzen sehen können. Und allgemein sollten die Arbeitsbedingungen, die wahrgenommenen Aufstiegschancen und die Sicherheit des Arbeitsplatzes so geschaffen sein, dass diese die Motivation für die Sache nicht zerstören. Nach Hertzberg können diese Faktoren als Frustratoren (Drumm 2005, S. 476) wirken, die letztendlich die intrinsische Motivation zerstören. Grundsätzlich ist zu vermeiden, dass Mitarbeiter mit Aufgaben überfordert werden, da dies die Gefahr der Frustration bei Nichterreichen von Ergebnissen birgt. Eine sorgfältige Abwägung von Aufgabe und Fähigkeiten des Projektmitarbeiters ist vor der Übertragung einer Aufgabe daher sinnvoll. Zudem sollte dies in Zweifelsfällen ruhig vorab mit dem entsprechenden Mitarbeiter diskutiert werden.

Bei den Faktoren der extrinsischen Motivation findet man dann eher die Anreize, für die Unternehmensberatungen bekannt sind. Die Faktoren der extrinsischen Motivation sind jedoch nicht immer monetär, sondern es gibt auch noch eine Reihe anderer Belohnungen, die als Motivatoren geeignet sind: Die grundlegendste Form der Belohnung ist sicherlich die Anerkennung von Leistung. Dies kann auch rein als Wertschätzung geschehen, die nicht mit einer finanziellen Prämie verbunden ist. Diese Wertschätzung sollte nicht von oben herab als Lob erfolgen, denn dies setzt die gelobte Person als nicht gleichwertig herab. Sie sollte vielmehr auf der Ebene gleichwertiger Partner erfolgen (auch wenn es faktisch immer Vorgesetzten-Mitarbeiter-Verhältnisse geben wird). Es ist also die Aufgabe des Projektleiters, für gute Projektarbeit Anerkennung zu zeigen. Dies darf nicht im hektischen Projektalltag untergehen, sondern sollte immer erfolgen, wenn diese erbracht wird. Bei besonders guter Leistung sollte die Anerkennung auch öffentlich gegenüber anderen erfolgen (etwa in Statusmeetings) und auch schriftlich dokumentiert werden (etwa über Dankensbriefe, Protokollnotizen, Schreiben an den Personalbereich etc.). Bei entsprechend guter Projektarbeit sollte den Mitarbeitern auch Verantwortung übertragen werden. Zum einen stützt dies die intrinsische Motivation (s. o.), zum anderen wirkt sie als Belohnung, wenn damit Status oder die Erfüllung eigener Ansprüche/Wünsche verbunden ist. Wichtig ist hierbei, diese Verantwortung auch nach außen zu dokumentieren, da sonst die Statusfunktion nicht greifen kann. Ein Ausdruck dieser Anerkennung sind die Hierarchiestufen in Beratungsunternehmen (vgl. Praxisbox 17: Die Organisation von Managementberatungen ab Seite 157). Möglich sind natürlich auch materielle und monetäre Anreize für gute Leistung. So ist es in Beratungsunternehmen üblich, dass ein Teil des Gehaltes der Mitarbeiter als variabler Gehaltsbestandteil bei Erreichung bestimmter Ziele gezahlt wird. Gewöhnlich steigt dieser

222


Anteil, je höher die Mitarbeiter in der Hierarchiestufe aufsteigen. Auf der Ebene von Partnern sind variable Anteile von 50 und mehr Prozent des Gehaltes nicht unüblich. Bei Berufseinsteigern liegt dies geringer, meist bei 15 bis 30 %. Bekommen die Berufseinsteiger die Prämie noch allein bei Erreichen ihrer persönlichen Leistungsziele ausbezahlt, so ist die Prämie bei Mitarbeitern mit Personalverantwortung oft auch an die Erreichung von Unternehmenszielen gekoppelt. Andere denkbare Prämien sind Sach- oder Leistungsprämien für gute Projektarbeit (etwa ein Wochenende in einem Top-Hotel, Theaterkarten oder ein Gutschein für ein Abendessen), Dienstwagen ab bestimmter Hierarchiestufe etc. Mit den monetären Anreizen sollte ein Unternehmen sorgsam umgehen. Dies hat zwei Gründe. Zum einen kann ein zu geringer monetärer Anreiz als Frustrator wirken (Drumm 2005, S. 476), zum anderen nutzt sich der positive Effekt hoher Prämien schnell ab und die Mitarbeiter gewöhnen sich an das Geld. Prämien sind daher nicht als Selbstverständlichkeiten zu verteilen, sie dürfen tatsächlich nur bei guter Leistung gezahlt werden. Bei materiellen Prämien (etwa Dienstwagen) tritt der Gewöhnungseffekt nicht so schnell ein, da die Vorteile spürbarer und weniger abstrakt als bei Geldzahlungen sind. Zur Motivation sind diese daher besser geeignet. Weitere Maßnahmen zur extrinsischen Motivation sind die Teilnahme an Weiterbildungsveranstaltungen oder Tagungen, gemeinsame Teamveranstaltungen mit Prestige- oder Freizeitwert (etwa Weihnachtsfeiern), Möglichkeit zu Sabbaticals (längere Pausen, z. B. sechs Monate unbezahlter Urlaub), Teilnahme an Studienprogrammen wie z. B. MBAProgrammen, freie Tage, Ausstattung mit Arbeitsmaterial mit Prestigewert (Laptop, Mobiltelefon, PDA, mobile Datenkarten), Visitenkarten mit positiv formulierter Funktionsbeschreibung, Dienstreisen in der Business statt Economy Class, großzügige Erstattung von Taxifahrten usw. Bei allen diesen Maßnahmen ist allerdings die steuerliche Auswirkung zu beachten, da dies unentgeltliche Gehaltsbestandteile sein können.

6.4

Zusammenarbeit im Projekt

Projekte sind dadurch gekennzeichnet, dass Personen mit unterschiedlichen fachlichen Hintergründen zusammenarbeiten, um eine neue Aufgabe zu bewältigen (vgl. hierzu Kapitel 1.3 ab Seite 29). Eine Aufgabe des Projektleiters liegt hierbei darin, die reibungslose Zusammenarbeit sicherzustellen. Entsprechend ist es seine Aufgabe, den Teamgedanken bei den Projektmitarbeitern zu unterstützen, damit die Arbeit unter Ausnutzung der Stärken aller erledigt werden kann. Und sollten einmal Konflikte in dem Projektteam auftreten, so ist es seine Aufgabe, diese zu lösen, um wieder kooperativ zusammenarbeiten zu können. Konflikte in Projekten werden hierbei verstanden als Spannungssituationen, bei denen unterschiedliche Meinungen und/oder Werte mehrerer Personen aufeinanderprallen. Sie verursa-


223

chen hohe Emotionalität, negative Gefühle, Wahrnehmungsverzerrungen und Störungen im Arbeitsablauf (etwa durch Schaffung von Sündenböcken oder Verweigerung der Zusammenarbeit). In Projekten sind Konflikte meist unvermeidbar – geht es doch um die Einführung von etwas Neuem im Rahmen der Zusammenarbeit von unterschiedlichen Menschen. Die Aufgabe des Projektleiters liegt also nicht in der Konfliktvermeidung, sondern darin, die Konflikte im Sinne des Projektziels zu lösen und evtl. sogar neue Kraft für die Projektarbeit aus der Konfliktsituation entstehen zu lassen. Auf die inhaltliche Ebene von Konflikten kann an dieser Stelle hierbei nicht weiter eingegangen werden. Unterschiedliche Meinungen zu Projektinhalten lassen sich nur aus der jeweiligen Projektsituation beurteilen und allgemeine Managementtipps hierzu sind daher wohl kaum möglich. Diese unterschiedlichen Sichtweisen verschiedener am Projekt beteiligter Personen können im Vorfeld über Stakeholder-Management (siehe Abschnitt 4.4 ab Seite 166) abgefangen werden.

6.4.1

Konflikte bei Beratungsprojekten

Konflikte, und dabei gerade verdeckt ausgetragene Konflikte, sind eine Gefahr für Projekte. Konterkarierendes Handeln einzelner im Projekt beteiligter Personen kann die gesamte Projektarbeit gefährden. Dies gilt insbesondere, wenn dieses Handeln offiziell nicht gezeigt wird, so dass es verspätet erkannt wird oder keine Gegenmaßnahmen erlaubt. Zudem können verdeckte Konflikte für die beteiligen Personen sehr belastend sein, da man sich dem Konflikt nicht richtig stellen kann. Eine extreme Form der verdeckten Austragung von Konflikten ist das Mobbing, das sich dann gezielt gegen einzelne Personen richtet. Konflikte haben ihre Ursache dabei oft in der Beziehungsebene, werden aber auf der Sachebene ausgetragen. Die Beziehungsebene beschreibt die Ebene der menschlichen Beziehung – Konflikte können dabei ausgelöst werden etwa durch Verärgerung wegen mangelnder Konsultation, aus Angst, Macht und Einfluss durch das Projekt zu verlieren, Sympathie oder Abneigung gegenüber Mitarbeitern und Kollegen usw. (Wolf/Mlekusch 1997, S. 72) Um die Bedeutung der Beziehungsebene zu visualisieren, wird oft der Vergleich mit einem Eisberg (vgl. Abbildung 90) herangezogen. Sichtbar ist nur ein kleiner Teil des Eisbergs, dieser besteht aber in seiner Gesamtheit zusätzlich zu dem aus dem Wasser ragenden Teil auch aus einem viel größeren nicht sichtbaren Teil unter Wasser. Dieser Teil entspricht in dem Vergleich der Beziehungsebene, die für Konflikte viel bedeutsamer ist, jedoch nicht so leicht wahrgenommen werden kann. Und gerade diese Beziehungsebene ist als Auslöser von Konflikten für die Projektarbeit gefährlich, genauso wie es der unter dem Wasserspiegel liegende Teil eines Eisbergs für kollidierende Schiffe ist. Daher muss ein Managementberatungsunternehmen in der Projektarbeit auch immer die Beziehungsebene im Blick behalten.

224


Die Sachebene ist die Ebene, auf der Inhalte abgehandelt werden. Sie ist die formale Ebene im Projekt, in der es um Projektinhalte, Methoden, Ergebnisse, Strukturen und Vorgehensweisen geht.

Sachebene

Beziehungsebene

Abbildung 90: Beziehungs- und Sachebene von Konflikten

Dieses Zusammenspiel von Beziehungs- und Sachebene bei der Konfliktentstehung ist zwar oft zu beobachten, ist aber gerade für Projekte von Managementberatungen ein relevantes Thema. Die Zusammenarbeit von Beratern und Mitarbeitern des Klientenunternehmens birgt potenziell die Gefahr des Entstehens von Konflikten auf der Sach- und Beziehungsebene. Zuerst soll hier auf die Sachebene eingegangen werden. Es kann auf der Sachebene bei unzureichender Zieldefinition und -kommunikation dazu kommen, dass die Consultants der Managementberatung und die Mitarbeiter des Klientenunternehmens unterschiedliche Ziele verfolgen. Etwa, dass das Beratungsunternehmen Kosten einsparen will, während die Mitarbeiter des Klientenunternehmens an sicheren Arbeitsplätzen oder bewährten Prozessen interessiert sind. Häufig werden diese Sachzielkonflikte dann auch nur verdeckt ausgetragen, da die Mitarbeiter im Projekt gezwungen sind, formal die offiziellen Ziele ihres Auftraggebers aus dem Unternehmen zu verfolgen. Verdeckt können dann unter Umständen jedoch andere Ziele verfolgt werden. Ein anderer Konfliktpunkt auf der Sachebene ist dadurch gegeben, dass die Projektmitarbeiter aus der Beratung und von der Fachseite unterschiedliche berufliche Hintergründe besitzen. Dies kann dazu führen, dass unterschiedliche Methoden zur Problemlösung eingesetzt und unterschiedliche Vorgehensweisen gewählt werden (zur Methodenebene siehe Wolf/Mlekusch 1997, S. 73). So können die Mitarbeiter der Fachseite beispielsweise eher Lösungen aus den bestehenden operativen Prozessen heraus ableiten, während Berater topdown neue Ansätze verfolgen. In Bezug auf die Vorgehensweise im Projektmanagement arbeiten Mitarbeiter des Beratungsunternehmens in der Regel nach den Projektmanage-


225

mentansätzen, die in der Beratung üblich sind. Im Klientenunternehmen werden aber sonst bei Projekten andere Vorgehensweisen üblich sein. Für die Projektarbeit muss bereits beim Aufsetzen des Projektes genau geklärt werden, nach welchem Ansatz vorgegangen wird, um Spannungen während des Projektablaufes zu vermeiden. Ein weiterer in der Projektpraxis beobachtbarer Konfliktpunkt auf der Sachebene sind die unterschiedlichen Projektarbeitsintensitäten bei Beratung und Fachseite. Meist ist es so, dass die Berater sich während ihrer Arbeitszeit voll auf das Projekt konzentrieren können, während die Mitarbeiter der Fachseite in der Regel weitere Aufgaben des „normalen“ Betriebs übernehmen müssen. Die sich ergebenden unterschiedlichen Arbeitsintensitäten im Projekt können in der Art zu Spannungen führen, dass die Berater durch die Fachseite als die „Antreiber“ wahrgenommen werden, während die Fachseite aus Sicht der Beratung nicht alles tut, um das Projekt nach vorne zu bringen.

Weitere Konfliktpunkte ergeben sich auf der Beziehungsebene. Die aufgeführten Beispiele zeigen hierbei aber auch schon auf, wie eng Sach- und Beziehungsebene verbunden sind. So können die oben unter Sachebene aufgeführten Punkte zu Spannungen auf der Beziehungsebene führen. Ein sehr wichtiger Punkt auf der Beziehungsebene ergibt sich aus der schon oben angesprochenen unterschiedlichen Einbindung der Mitarbeiter von Beratung und Klientenunternehmen in die operativen Prozesse des Klientenunternehmens. Dies schlägt sich nicht nur formal bei den verfolgten Zielen nieder (s. o.), sondern auch beim wahrgenommenen Risiko von Veränderungen und der damit einhergehenden emotionalen Bereitschaft zu Innovationen. Bei anstehenden Änderungen im Unternehmen ist die Bindung an die IstSituation entsprechend bei den Mitarbeitern der Fachseite höher als bei den Consultants, die selbst nie in der Situation gearbeitet haben und die ein Wandel in der Regel nicht persönlich betrifft. So können auch hier die Berater emotional als die Agitatoren eines nicht positiv gesehenen Wandels abgelehnt werden. Auf der Beziehungsebene können zudem Konflikte aufgrund der unterschiedlichen Unternehmenskulturen von Beratung und Klientenunternehmen entstehen. Dies können z. B. Unterschiede bei der Gewichtung von gegebenen Zielen (Effizienz durch Wandel versus Beharrung), profane Dinge wie Kleidung oder einfach unterschiedliches Fachvokabular sein. Diese Unterschiede können zu Akzeptanzproblemen führen. Die Zugehörigkeit zur Managementberatung ist anhand des Auftretens der Mitarbeiter meist leicht zu erkennen und das dort gelebte Verhalten kann in anderen Bereichen auch als Arroganz ausgelegt werden. Konflikte können aber auch schlicht und einfach dadurch ausgelöst werden, dass die Berater als „Störenfriede“ angesehen werden, die sich in die Arbeit der Fachbereiche einmischen. Sei es, dass sie die interessantesten Projekte an sich gezogen haben, oder auch, weil ihre Projektarbeit mit negativen Folgen wie Personalabbau im Klientenunternehmen einhergeht.

226


In der Abbildung 91 sind die sich aus dem Spannungsfeld der Zusammenarbeit von Unternehmensberatung und Fachseite ergebenen Konflikte noch einmal aufgeführt.

Konfliktpotenzial Sachebene unterschiedliche Zielsetzungen

unterschiedliche Projektarbeitsintensität Beziehungsebene unterschiedliche Bindung an Ist-Situation unterschiedliche Unternehmenskulturen

Fachseite

Managementberatung

unterschiedlicher Erfahrungshorizont

Berater als die Privilegierten, die die interessanten Projekte durchführen Berater als Störenfriede, die negative Ergebnisse erzeugen

Abbildung 91: Konfliktpotenzial aufgrund der Beratungssituation

Gerade bezüglich dieser bei der Zusammenarbeit von Beratungsunternehmen und Klientenunternehmen inhärenten Spannungen, ist es zunächst Aufgabe der Managementberatung, dafür zu sorgen, dass sie nicht negativ zum Tragen kommen. Dies kann durch einfache Maßnahmen erfolgen, die in Abbildung 92 auf Seite 227 schematisch dargestellt sind. Erste Voraussetzung für die Vermeidung von Konflikten zwischen Beratern und Linienmitarbeitern ist, dass sich die Mitarbeiter die Gefahr dieser Konflikte vor Augen führen. Sie müssen also das entsprechende Bewusstsein hierfür erlangen. Jeder Mitarbeiter des Beratungsunternehmens muss wissen, dass es aufgrund der unterschiedlichen Rollen und Hintergründe der Mitarbeiter zu diesen Konflikten kommen kann. Auf die grundsätzliche Problematik sollte daher in den Projektmanagementschulungen für die Consultants hingewiesen werden und der Projektmanager sollte dies in Teambesprechungen mit seinen Consultants thematisieren. Im Zuge eines Feedbacks sollte die Wahrnehmung des Klienten bezüglich möglicher Spannungen abgefragt werden. Dies kann beispielsweise im Rahmen einer Auftraggeberbefragung (siehe Abschnitt 6.1 ab S. 196) erfolgen. Beide Parteien sollten so wahrnehmen, ob es zu Konflikten zwischen den Mitarbeitern des Beratungs- und Klientenunternehmen kommt – und wenn ja, worauf diese beruhen. In einem nächsten Schritt sollten nun Maßnahmen


227

ergriffen werden, diese Konflikte zu verringern oder auch schon proaktiv in der Entstehung zu verhindern. So muss zwischen Managementberatung und Klientenunternehmen sichergestellt werden, dass tatsächlich die gleichen Ziele verfolgt werden. Auch wenn dies eigentlich eine Selbstverständlichkeit ist, kann man hierauf doch besonders achten. So sollten die Ziele in einem gemeinsamen Kick-off-Meeting beim Projektstart nochmals herausgestellt werden. Hierbei ist insbesondere auf die Akzeptanz der Mitarbeiter zu achten und ggf. geäußerte Bedenken müssen ernst genommen werden. Das Kick-off-Meeting sollte dazu genutzt werden, die Rollenverteilung und -erwartungen klar zu kommunizieren. So entsteht die für die Vermeidung von Konflikten auf der Sachebene notwendige Abstimmung der Ziele. Ebenso sollte hierbei die notwendige Transparenz über mögliche zusätzliche Ziele und anderes Vorgehen der Partner hergestellt werden. Um auf der Beziehungsebene Konflikte zu vermeiden, sollten sich die in Kapitel 6.4.4 (ab S. 240) dargestellten Teambuilding-Maßnahmen auf das gesamte Projektteam beziehen. Sie dürfen nicht die Mitarbeiter eines Unternehmens ausgrenzen. Auch ist in der Projektarbeit auf eine möglichst enge Verzahnung der Arbeit zu achten, so dass jeweils Transparenz über die Arbeitsergebnisse der anderen Seite besteht (vgl. Kapitel 6.2 ab S. 207). Diese enge, zu beiderseitigem Vorteil bestehende Zusammenarbeit kann auch mit dem Begriff Collaboration beschrieben werden. Teilteams werden hierbei durch Mitarbeiter beider Unternehmen gemeinsam besetzt, es findet ein enger Informationsaustausch durch regelmäßige Meetings statt, Statusberichte der Mitarbeiter einer Seite sind für alle zugänglich etc. Gerüchte, was die andere Seite angeblich schon wieder gemacht oder nicht gemacht hat, kommen so erst gar nicht auf. Konflikte auf Sach- und Beziehungsebene werden vermieden.

Beziehungsebene – Teambuilding – Collaboration

Bewusstsein

Wahrnehmung Sachebene – Zielabstimmung – Transparenz – Collaboration

Abbildung 92: Konfliktreduktion in Beratungsprojekten

228

6.4.2


Konfliktmanagement

Treten trotz der Bemühungen, mögliche Konflikte in Beratungsprojekten zu vermeiden, dennoch Konflikte auf, dann ist das Konfliktmanagement gefragt. Konflikte und Spannungen werden in Projekten immer auftreten und sind natürlich nicht auf Beratungsprojekte beschränkt. Sie werden immer auftreten, wenn etwas Neues durch ein Projekt geschaffen wird, da eine neue Situation immer neue Arbeit, Anforderungen, Verschiebungen im Macht- und Zuständigkeitsgefüge und die damit verbundenen Unsicherheiten mit sich bringt. Im Rahmen eines Konfliktmanagements wird versucht, mit den Spannungen im Konflikt professionell umgehen. Dabei wird angestrebt, die negativen Folgen von Konflikten zu verhindern und sogar positive Effekte aus einer Konfliktlösung zu generieren (MCSG 2001). Denn Konflikte können positiv wirken, indem sie: Kreativität freisetzen, Stagnation verhindern, den Weg für eine reibungslose Projektarbeit schaffen und Probleme lösen, Erklärungen für Verhalten und Probleme liefern, Spannungen abbauen, Gruppen zu Teams formen und das Selbstbewusstsein der Einzelnen stärken.

Der Vergleich mit einem reinigenden Gewitter, das klare Luft hinterlässt, ist hierbei durchaus zutreffend. Die lähmenden Spannungen und Unklarheiten bei der weiteren Vorgehensweise und Verantwortlichkeiten, die häufig mit Konflikten einhergehen, werden durch die Lösung des Konfliktes beseitigt und man steht so besser da, als es ohne Konfliktaustragung der Fall gewesen wäre. Aber natürlich beinhalten Konflikte im Projekt auch Risiken. Neben der beschriebenen Behinderung einer konstruktiven Arbeit im Laufe von Konflikten, dem Verbrauch enormer Ressourcen für den Konflikt statt diese in die Projektarbeit einzusetzen, können sie natürlich auch das Erreichen des Endergebnisses eines Projektes gefährden, wenn beispielsweise kein Konsens über Ziel, Vorgehensweise oder Bereitstellung von Ressourcen erzielt werden kann. Es ist also ganz klar, dass Konflikte nicht sich selbst überlassen werden dürfen, sondern Handeln erfordern. Konflikte können sich hierbei recht langsam entwickeln, bis sie wirklich manifest sind und große Auswirkungen haben. Mögliche Eskalationsschritte eines Konfliktes, in den nicht eingegriffen wird, sind (vgl. Glasl 1990, S. 191-192): Negative Wahrnehmung einer Situation durch ein Projektmitglied


229

Zunehmende Projektion von negativen Wahrnehmungen auf andere Projektbeteiligte bei wachsender Selbstfrustration Ausweitung der strittigen Themen. D. h., es geht im Konflikt nicht nur mehr um eine Sache, sondern um ein ganzes Bündel von Themen, die gleichzeitig gesehen werden. Oft ist die gesamte Projektarbeit hier mit einbezogen. Dabei erfolgt aber eine kognitive Vereinfachung der Situation, insbesondere der Schuldzuweisung. D. h., „alles geht schief, weil Teilprojekt X nicht richtig mitarbeitet“ Weitere vereinfachte Schuldzuweisung bei Auflösung rationaler Ursache-Wirkungs-Zusammenhänge Einbeziehung weiterer Personen in den Konflikt (Koalitionssuche) bei Personalisierung der Schuldzuweisung und des Konfliktes („Herr X ist schuld“) Gegenseitige Gewaltandrohung (im übertragenen Sinne als Androhung von Zwangsmaßnahmen) mit dem Ziel, den Konfliktgegner zum Einlenken zu bewegen. Tatsächlich wird dies aber als Provokation verstanden und erzeugt Gegengewalt. Der Konflikt eskaliert.

Zuständig für das Konfliktmanagement ist der Projektleiter, der ja auch den Projekterfolg verantwortet. Für das richtige Verhalten in Konflikten gibt es eine Reihe von Regeln, die Projektleitern helfen sollen, Konflikte zu handhaben (beispielhaft MCSG 2001): 1. Sorgfältige Diagnose. Der Projektleiter darf nicht vorschnell urteilen, wenn es um die Diagnose von Konfliktursachen geht. Wird bei der Diagnose der Konfliktursachen ein Fehler gemacht, dann werden die eingeleiteten Maßnahmen zur Konfliktbewältigung immer die falschen sein. Gibt es beispielsweise im Teilprojekt EDV eine Verzögerung, worüber es mit anderen Teilprojektleitern zum Streit und Schuldzuweisungen gekommen ist, dann ist es maßgeblich, die Ursache für diese Verzögerung zu kennen. Schließt der Projektleiter beispielsweise aus einer Verzögerung darauf, dass dort nicht genug Ressourcen eingesetzt werden, liegt die wahre Ursache jedoch darin, dass die im Projekt verfolgte technische Lösung nicht für richtig gehalten wird, dann wird der Versuch des Projektleiters, weitere Ressourcen für das EDV-Teilprojekt zu gewinnen, keine Änderung bewirken. Eine sorgfältige Analyse ist zudem wichtig, weil es möglich ist, dass die Akzeptanz für Lösungen sinkt, wenn die Projektmitarbeiter den Eindruck gewinnen, dass der Projektleiter sich zu schnell und unreflektiert eine Meinung zum Konflikt gebildet hat. Die Diagnose setzt natürlich auch das richtige Erkennen des Eskalationsstadiums voraus, in dem sich ein Konflikt befindet. Ziel ist es, den Konflikt möglichst am Anfang zu erkennen. Dies wird immer dann besser erfolgen, wenn der Projektleiter gut in die Kommunikation im Projekt eingebunden ist – auf formeller wie auch auf informeller Ebene. Die informelle Ebene ist hierbei wichtig, da diese als eine Art Frühwarnindikator für Probleme dienen kann. Dort werden wegen der niedrigeren Hemmschwelle, die aufgrund der geringeren Formalität besteht, Probleme schneller und leichter angesprochen. 2. Klare Zielsetzung. Um einen Konflikt zu lösen, benötigt man eine klare Vorstellung eines Soll-Zustandes. Ein Konflikt beinhaltet immer zumindest zwei unterschiedliche Sichtweisen auf einen Sachverhalt – das lässt sich nur auflösen, wenn man eine Idee vom Soll-

230


Zustand hat. Dies soll nicht so verstanden werden, dass der Projektleiter immer schon die Lösung für jedes Problem parat haben muss. Er muss jedoch wissen, anhand welcher Kriterien entschieden werden soll, wie der Konflikt zu lösen ist. Ein wichtiges Kriterium ist zunächst einmal die Konsistenz der Vorgehensweise mit dem Projektziel, weitere Kriterien können die Konsistenz mit dem vereinbarten Projektplan, die allgemeine Effizienz und der Einsatz gemäß den Kompetenzen und verfügbaren Ressourcen sein. 3. Planmäßiges und strukturiertes Vorgehen. Konflikte führen oft zu Unklarheiten, wie es denn nun weitergeht. Wichtig bei der Lösung von Konflikten ist es, diese Unklarheit durch ein strukturiertes Vorgehen möglichst gering zu halten. Die Klarheit bei der Vorgehensweise schafft auch Akzeptanz, da die Problemlösung für jeden sichtbar ist (siehe Punkt 5. dieser Aufzählung). Auch kann logisch strukturiertes Vorgehen dabei helfen, die irrationale Eskalation von Konflikten zu durchbrechen und wieder eine höhere Rationalität zu erreichen. 4. Klarheit der Rollen sicherstellen. Auch hier ist oberstes Gebot wieder Transparenz. Bei diesem Punkt ist jetzt die Transparenz bezüglich der Zuständigkeiten im Konfliktfall angesprochen. Es ist insbesondere zu klären, was der Projektleiter als Schlichtungs- und Entscheidungsstelle entscheiden darf und was nicht. Gegebenenfalls muss sich der Projektleiter hierzu Rückendeckung vom Lenkungsausschuss oder Steuerkreis holen, wenn er nicht selbst die notwendige Kompetenz zur Entscheidung im Konfliktfall besitzt. Hat der Projektleiter nicht die notwendige Kompetenz zur Problemlösung, beispielsweise weil er bestimmte fachliche Entscheidungen nicht treffen darf oder die entsprechenden Projektteilnehmer ihm nicht unterstehen, dann ist es seine Aufgabe, das Problem rechtzeitig an die zur Lösung befugten Stellen zu kommunizieren. Konkret heißt dies, dass es Aufgabe des Projektleiters ist, Probleme an den Steuerkreis bzw. Lenkungsausschuss zu berichten und um eine Lösung zu bitten, wenn er sonst dazu nicht in der Lage ist. Es ist wichtig, dies nicht als „Petzen“ misszuverstehen, sondern als Teil einer konstruktiven Problemlösung anzusehen und entsprechend auch im Projektteam zu kommunizieren. Eine wichtige Rollenklarstellung betrifft noch die „Ausgrenzung“ von Nicht-Betroffenen. Es muss deutlich gemacht werden, dass der Konflikt im Kreise derer bleibt, die sachlich hiervon betroffen sind. 5. Einbeziehen und Akzeptanz schaffen. Projekte sind dann erfolgreich, wenn sie durch funktionierende Teams bearbeitet werden. Ein Team arbeitet zusammen, d. h., wenn man möchte, dass nach dem Konflikt wieder reibungslos zusammengearbeitet wird, dann muss jede Konfliktpartei die gefundene Lösung akzeptieren. Ist dies nicht der Fall, dann besteht die Gefahr, dass der Konflikt verdeckt weitergeführt wird oder sich sogar wieder in die Beziehungsebene verlagert. Konflikte können dabei nicht durch einen weisen Schiedsspruch geklärt werden. Es ist notwendig, in Konfliktgesprächen die im ersten Punkt geforderte Analyse durchzuführen, um tatsächlich alle Konfliktpunkte auf den Tisch zu bekommen. Betroffene sollen dabei zu Beteiligten gemacht werden, die sich möglichst aktiv um die Konfliktlösung kümmern. Konfliktgespräche dienen auch dazu, mehr Informationen über Gründe und Sichtweisen zu erlangen, ein erstes Ventil für Emotionen zu sein und die Akzeptanz für Lösungen zu erhöhen, indem den Beteiligten gezeigt wird, dass


231

man sich für ihre Sichtweise interessiert. Ziel der Kommunikation muss es sein, Konflikte so von latent zu manifest werden zu lassen, d. h. von verdeckt zu offen zu wandeln und idealerweise von der Beziehungsebene auf die Sachebene zu verlagern. 6. Win-Win-Situationen suchen. Setzt sich eine Konfliktseite durch, so muss dies nicht automatisch bedeuten, dass die andere Seite verliert. Auch wenn dies unser übliches Denkschema ist, so lohnt es sich doch, nach einer Lösung zu suchen, die beide Seiten integriert und so beide Seiten gewinnen lässt (siehe Abbildung 93). Man spricht auch von einer Win-Win-Situation. Im Rahmen der Eskalation legen es Konfliktparteien darauf an, sich gegen die andere Seite durchzusetzen (hier als Unterdrückung und Kampf enthalten). Dies ist für ein Projekt, das auf die Mitarbeit aller angewiesen ist, eine schlechte Lösung, da sie dazu führen kann, dass die unterlegene Seite sich (offen oder verdeckt) aus dem Projekt zurückzieht. Eine Win-Win-Situation als Lösung ist einem Kompromiss vorzuziehen, da dieser jeweils teilweise Einschränkungen für die Konfliktparteien mit sich bringt. Bei der Suche nach der integrativen Lösung kann es sinnvoll sein, gedanklich am Anfang des Konfliktes anzusetzen – also noch bevor es zu einer Eskalation kam und Versuche angestellt wurden, sich durchzusetzen.

Konfliktpartei A setzt sich durch

Kampf

Integration

Kompromiss

Flucht

Unterdrückung

Konfliktpartei B setzt sich durch

Quelle: MCSG 2001 Abbildung 93: Strategien der Konfliktbewältigung

Auch die Handlungsmöglichkeit Flucht beschreibt die Verdrängung des Konfliktes – dies führt dann zu den dargestellten negativen Konsequenzen eines Konfliktes und ist daher als Handlungsoption für einen Projektleiter nicht geeignet. 7. Emotionen zulassen. Unser Bild von Management ist häufig dadurch geprägt, dass ein Manager rationale Entscheidungen fällt und sich nicht durch Emotionen leiten lässt. Menschen sind aber emotionale Wesen und die Emotionen spielen gerade bei Konflikten eine

232


wichtige Rolle, sind sie doch ein wichtiger Faktor bei der Beziehungsebene und der Eskalation von Konflikten. Emotionen treten also faktisch auf und sind die Treiber von Konflikten. Lässt man diese nun nicht zu und geht nicht auf die real vorhandenen Emotionen der Konfliktparteien ein, dann entzieht man diesen Teil des Konfliktes auch einer Lösung. Richtig aus Sicht eines Projektleiters ist es also, die Emotionen der Projektteilnehmer verstehen zu wollen, möglichst auch die Ursachen zu begreifen und dann zusammen mit den Betroffenen in Gesprächen zu versuchen, diese Emotionen zu rationalisieren, zu kontrollieren und schließlich von der Emotionsebene auf die Sachebene zu gelangen. Sagt ein Projektleiter hingegen nur, dass er sich nicht für die Emotionen der Projektteilnehmer interessiert, weil diese unprofessionell wären, dann verschließt er sich diesem Lösungsansatz. 8. Neutralität bewahren; offen und ehrlich sein; bescheiden bleiben. Der Projektleiter sollte im Streitfall eine Art Schiedsrichter oder Obmann sein. Durch die Neutralität gewinnt der Projektleiter zwei wesentliche Punkte: Die Akzeptanz für eine Konfliktlösung steigt und er hält sich in jedem Fall den Weg zur besten Lösung offen. Diese Schiedsrichterfunktion kann man als Projektleiter natürlich nur wahrnehmen, wenn man dabei für alle Seiten offen ist, ehrlich im Sinne des Projektes entscheidet und seine eigene Rolle nicht zu wichtig nimmt. Als Teil des Projektteams ist der Projektleiter auf die Projektmitarbeiter angewiesen und daher sollte er auch nicht von oben herab in Konflikte eingreifen, sondern immer mit Respekt für die handelnden Personen. 9. Geduld haben. Wie erläutert entstehen Konflikte meist in einer Eskalationsdynamik über eine längere Zeit. Solche Konflikte lassen sich dann auch nicht umgehend lösen. Dabei gilt der einfache Zusammenhang: Je weiter ein Konflikt in der Eskalation fortgeschritten ist, desto mehr Zeit wird auch für die Lösung benötigt. 10. Konflikte abschließen. Da Konflikte in einer Eskalation dazu neigen, sich auszudehnen, ist es wichtig, sie unter Beteiligung aller auch wieder abzuschließen. Es besteht ansonsten die Gefahr, dass nur einer von vielen Konfliktpunkten beendet wurde und der Konflikt sich an einem anderen Punkt wieder entzündet. Den Abschluss eines Konfliktes und die formale, zukunftsgerichtete Festlegung der Lösung stellt man durch Gespräche aller Beteiligten miteinander sicher. Bei den Gesprächen ist darauf zu achten, dass die Lösung tatsächlich die Akzeptanz aller Beteiligten findet. Die formale Beendigung kann in einem Meeting stattfinden und sollte auch protokolliert werden, wobei man sich hierbei auf die Sachebene beschränken sollte. Die Beziehungsebene entzieht sich ohnehin Regeln wie schriftlicher Fixierung.


6.4.3

233

Transaktionsanalyse zur Erkennung und Lösung von Konflikten

Es wurde bereits darauf hingewiesen, dass viele Konflikte ihre Ursache nicht in inhaltlich begründeten Gegensätzen besitzen, sondern sich auf der Beziehungsebene abspielen. Eine Ursache für Probleme auf der Beziehungsebene ist schlechte Kommunikation. Dies ist insbesondere für Projektleiter wichtig zu wissen, da es sie auch selbst betreffen kann. Der Projektleiter ist wohl die Person im Projekt, die am meisten kommunizieren muss. Hierbei hat ein Projektleiter die unterschiedlichsten Ansprechpartner, die den unterschiedlichen beteiligten Partnern (Beratungsunternehmen und Klientenunternehmen) angehören können, die die verschiedensten beruflichen und privaten Hintergründe besitzen und den unterschiedlichsten Hierarchiestufen im Unternehmen und Projekt zuzuordnen sind. Beispielhaft zu nennen sind Projektmitarbeiter, die Mitglieder des Lenkungsausschusses und Steuerkreises, Mitarbeiter im Unternehmen, die dem Projekt zuarbeiten oder davon betroffen sind, die Mitglieder des Betriebsrates, die Partner der Beratung, der Vorstand des Klientenunternehmens etc. Um dem Umstand Rechnung zu tragen, dass die Kommunikation Konflikte auslösen kann, gibt es eine Reihe von Ansätzen, die das Entstehen von Konflikten in der Kommunikation erklären. Einer der prominentesten Ansätze hierbei ist die Transaktionsanalyse (Glasl 1990, S. 224; Schlegel 2005). Da sie eine sehr prägnante und gleichzeitig anwendungsorientierte Sichtweise umfasst, wird sie hier kurz vorgestellt. Die Transaktionsanalyse ist von der Lehre von Sigmund Freud abgeleitet. Freud unterscheidet drei Zustände des Menschen: das Über-Ich, das Ich und das Es. Die Transaktionsanalyse differenziert vergleichbar, bietet jedoch auch die Möglichkeit einer weiteren Unterteilung (Schlegel 2005, S. 1). Zudem lässt sie sich dabei direkt auf die Art der Kommunikation beziehen, was sie für die Zwecke der Konflikterklärung in der Kommunikation gut geeignet erscheinen lässt. Es wird davon ausgegangen, dass jede Kommunikation anhand von drei verschiedenen Positionen beschreibbar ist, die je nach Kommunikationssituation und kommunizierender Person unterschiedlich ausgeprägt sind. In jedem Menschen sind grundsätzlich diese drei Positionen angelegt, sie werden aber unterschiedlich stark gezeigt. Es werden Eltern-Ich, ErwachsenenIch und Kind-Ich unterschieden. Die Abbildung 94 zeigt diese drei Ich-Zustände. Jede Person nimmt nun in der Kommunikation explizit oder implizit diese Rollen ein. D. h., man kommuniziert aus der Rolle heraus und zeigt dies durch die Art der Kommunikation (auch nonverbal) dem Gesprächspartner. Wenn nun beispielsweise ein Projektleiter einen Projektmitarbeiter anweist, etwas zu tun, indem er ihm sagt „Sie müssen noch die Aufgabe erledigen“, so tut er dies durch eine Vorschrift („Sie müssen noch“) und nimmt dabei die Eltern-Ich-Rolle ein.

234


ElternIch

gelerntes Lebenskonzept, (überlegend, bestimmend, führend) Gebote, Verbote, Regeln, Soll- und Mussvorschriften

ErwachsenenIch

KindIch

gedachtes Lebenskonzept (selbständig, offen, beweglich Rolle zu wählen) rationales System, Überprüfung aller Daten

gefühltes Lebenskonzept (anlehungsbedürftig, unstelbständig, impulsiv) Gefühle, Bedürfnisse, Antriebe

Quelle: Glasl 1990, S. 224; MZSG 2001 Abbildung 94: Die drei Ich-Zustände der Transaktionsanalyse

Das Eltern-Ich ist also eine Position der Normen. Sie ist entsprechend gelernt (wie die Normen auch aufgestellt und gelernt werden) und die Kommunikation erfolgt aus einer Position der Überlegenheit heraus, dass man diese Normen umsetzen darf. Entsprechend ist die Art der Kommunikation oft auch bestimmend und man versucht, den Kommunikationspartner zu führen. Das Erwachsenen-Ich ist ein eher gedachtes Lebenskonzept in dem Sinne, dass es das Bild repräsentiert, wie man sich die Welt rational erklärt. Mit zunehmendem Alter beginnt der Mensch die gelernten Lebenskonzepte zu hinterfragen und auf ihre Angemessenheit zu überprüfen. Die Position ist offen und selbständig, da man als freier rationaler Mensch agiert und sich an Fakten orientiert. Es erlaubt, sich je nach Faktenlage andere Rollen und Sichtweisen anzueignen und ist so flexibler. Grundprinzip ist, dass das Erwachsenen-Ich auf einer gedanklichen Prüfung der Fakten basiert, d. h., Entscheidungen werden getroffen, weil sie bei Abwägung vorteilhaft erscheinen, und nicht, weil etwas so sein muss (wie beim Eltern-Ich). Ein deutliches Bild für die Position des Erwachsenen-Ichs sind daher Fragen, die der Erklärung dienen (wieso, weshalb, warum, wie ist die Begründung etc.?) Im Kind-Ich kommen die Emotionen nun stärker zum Tragen. Insofern kann es als gefühltes Lebenskonzept bezeichnet werden. Diese Emotionen können sich am Spaß an impulsiven Entscheidungen manifestieren oder auch an einem Bedürfnis nach Geborgenheit und Sicherheit durch Unterordnung. Rationale Abwägung und Normen spielen kaum eine Rolle. Bei den Zuständen Eltern-Ich und Kind-Ich lassen sich noch weitere Ausprägungen unterscheiden. Das Eltern-Ich lässt sich in das kritische Eltern-Ich und das schützende Eltern-Ich differenzieren. Das kritische Eltern-Ich ist normativ, versteht sich also als erhobener Zeigefinger. Aus dieser Position heraus möchte man Kontrolle ausüben und bevormunden. Hier ist ein


235

Drang nach Perfektion durch Vorschriften erkennbar sowie ein deutlicher Drang nach Dominanz. Das schützende Eltern-Ich ist belehrend bzw. bemutternd. Man kann dabei aus der Elternrolle heraus fürsorglich und helfend sein, Wärme und Geborgenheit spenden. Man tut dies aber immer aus einer übergeordneten Perspektive heraus, in der der Partner abhängig sein soll. Das Kind-Ich hat die Positionen des natürlichen und des angepassten Kindes.

Das natürliche Kind hat Spaß an Neuem, ist kreativ, verliert aber auch schnell den Spaß an Dingen. Dies ist also eine Position jenseits der Normen, die sehr impulsiv ist, einen Verzicht nicht zulässt und sehr stimmungsabhängig ist. Die zweite Ausprägung ist das angepasste Kind, das fleißig ist, es allen recht machen will und gemocht werden möchte. Nimmt man diese Position ein, so zeigt man, dass man die Normen akzeptiert und danach handeln wird. Allerdings wird aus der KindIch-Perspektive heraus Verantwortung abgelehnt und man sucht nach Orientierung und ist entsprechend beeinflussbar. Beispiele für Aussagen aus Projekten, die den jeweiligen Zuständen zuzuordnen sind, gibt die Tabelle in Abbildung 95 (in Anlehnung an MZSG 2001 und Glasl. 1990, S. 224):

Eltern-Ich

Pfui! Nein, das können Sie nicht machen. Bitte seien Sie in dieser Sache kooperativ. Schämen Sie sich. Das war eine schlechte Leistung. Sie hätten im Termin bleiben müssen. Lassen Sie das bitte. Machen Sie es mir zuliebe. Lassen Sie mich das machen.

Erwachsenen-Ich

Ich möchte Ihnen kurz die Gründe hierfür nennen … Darüber muss ich erst noch nachdenken. Die Erhebung zeigt, dass dies die beste Vorgehensweise ist. Nach Abwägung der Vor- und Nachteile sollten wir dies machen.

Kindheits-Ich

Ich bin nicht schuld. Ich kann nichts dafür. Mir wurde aber gesagt, ich soll das so machen. Da kann man nichts machen. Ich will das selbst machen.

Abbildung 95: Beispiele für Aussagen, die den Ich-Zuständen entsprechen

Das Hilfreiche an der Transaktionsanalyse ist nun, dass sie sich zur Erklärung von Konflikten in der Kommunikation einsetzen lässt. Hierbei wird betrachtet, in welchem Ich-Zustand der Sender eines Reizes (Kommunikator) und der Empfänger (Kommunikant) jeweils kommunizieren. Befinden Sie sich im gleichen Ich-Zustand, so tritt kein Konflikt auf, man spricht von

236


komplementären Transaktionen (Glasl 1990, S. 225). Die Abbildung 96 zeigt diese konfliktfreie Kommunikation bei komplementärer Transaktion.

ElternIch

ElternIch

Stimulus ErwachsenenIch

ErwachsenenIch Response

KindIch

KindIch

Mitarbeiter A

Mitarbeiter B

Abbildung 96: Konfliktfreie Kommunikation

Grundsätzlich gilt, dass parallele Kommunikation zwischen den einzelnen Positionen (Eltern-, Erwachsenen- und Kind-Ich) konfliktfrei ist. Auch konfliktlos ist eine Eltern-Ich-KindIch-Kommunikation, diese Zustände sind komplementär – der Erwachsene kümmert sich um das Kind, das diese Rolle akzeptiert (Glasl 1990, S. 224-225). Die folgende Abbildung 97 zeigt dies graphisch.

ElternIch

ElternIch St im

ErwachsenenIch

Re sp o

ns e

ulu s

ErwachsenenIch

KindIch

KindIch

Mitarbeiter A

Mitarbeiter B

Quelle: Glasl 1990, S. 225 Abbildung 97: Konfliktfreie Kommunikation zwischen Eltern- und Kind-Ich

Wenn sich aber nun die Ich-Zustände der beiden Kommunizierenden nicht entsprechen (siehe Abbildung 98), dann tritt ein Konflikt in der Kommunikation auf. D. h., in diesem Falle ist


237

die Beziehungsebene gestört und aufgrund der Art der Kommunikation wird ein Konflikt auftreten, selbst wenn auf der Sachebene Einigkeit herrscht. Das linke Bild der Abbildung zeigt dabei eine so genannte Dreiecks-Transaktion („angular transactions“) und das rechte Bild eine gekreuzte Transaktion. In beiden Fällen erwidert der Kommunikant die Botschaft nicht auf der Ebene, auf der sie gesendet wurde. Er entzieht sich quasi damit der ihm zugewiesenen Rolle. Ein Beispiel für die dargestellte Dreiecks-Transaktion ist der logisch begründete Hinweis eines Projektleiters („Um den Termin zu halten, müssen wir morgen mit den Arbeiten beginnen“), der auf der Kind-Ich-Ebene beantwortet wird („Das haben wir doch schon einmal gemacht, ich habe keine Lust mehr dazu“). Für die überkreuzte Kommunikation kann folgendes Beispiel angeführt werden: Projektleiter: „Machen Sie das bis morgen, so steht es ja auch im Projektplan.“ Projektmitarbeiter: „Die Fakten haben sich geändert, so dass sich die Reihenfolge im Netzplan verschoben hat. Daher ist es für den Ablauf effizienter, wenn wir ein anderes Arbeitspaket vorziehen.“

ElternIch

ErwachsenenIch

KindIch

Mitarbeiter A

Stimulus

Resp ons

e

ElternIch

ElternIch

ErwachsenenIch

ErwachsenenIch

KindIch

KindIch

Mitarbeiter B

St im

ElternIch

ulu s

Response

Mitarbeiter A

ErwachsenenIch

KindIch

Mitarbeiter B

Quelle: Glasl 1990, S. 225-226 Abbildung 98: Konflikte in der Kommunikation

Dieser Konflikt kann auch verdeckt sein, wenn zwar in der formalen Kommunikation keine Überkreuz-Beziehung vorhanden ist, einer oder beide Personen jedoch zwei Ich-Zustände wahrnehmen. Formal ist dann zwar kein Konflikt vorhanden, unterschwellig jedoch schon. Dies wäre etwa der Fall, wenn Projektmitarbeiter sich zwar formal als rational (ErwachsenenIch) nach außen geben, jedoch gleichzeitig den versteckten Eltern-Ich-Anspruch erheben. Dies wird eine geglückte Kommunikation auf Erwachsenen-Ich-Ebene verhindern. Ein extremes Beispiel für verdeckte und überkreuzte Kommunikation ist Mobbing. Formal wird ein Mitarbeiter nicht kritisiert, die verdeckte Ebene zeigt ihm jedoch deutlich eine Ablehnung. Solch verdeckte Kommunikationskonflikte sind nicht selten, denn im Management allgemein und so natürlich auch im Projektgeschäft wird formal immer eine Erwachsenen-Ich-Erwachsenen-Ich-Kommunikation erwartet, die sich an Fakten orientiert. Die Konflikte sind daher oft erst auf den zweiten Blick zu erkennen.

238


Der einzige Weg, um in Projekten erfolgreich zu kommunizieren, ist eine Erwachsenen-IchErwachsenen-Ich-Kommunikation. Alle anderen parallelen Kommunikationswege sind zwar konfliktfrei, führen aber nicht zu der Lösung von Problemen, da kein gleichberechtigter Informationsaustausch erfolgt. Eine reine Anordnung von Eltern-Ich zu Kind-Ich verspielt die Chance eines inhaltlichen Feedbacks, reine Kind-Ich-Kind-Ich-Kommunikation führt zu nicht rationalen, durch persönliche Vorlieben geprägten Ergebnissen. Eine gute Teamarbeit ist nur mit gleichberechtigter Erwachsenen-Ich-Kommunikation möglich. Das Ziel der Kommunikation muss daher sein, Erwachsenen-Ich-Erwachsenen-Ich-Transaktionen herzustellen. Der Projektleiter muss dies in seiner Kommunikation sicherstellen. Gekreuzte Kommunikation durch ein kritisierendes Eltern-Ich an ein angepasstes Kind („Mach bitte die Analyse“ – „Mach Deine Analyse doch selbst, schließlich ist es Deine Aufgabe“) kann nur durch einen so genannten Gesprächswendepunkt auf die notwendige Erwachsenen-Ich-Ebene zurückgeholt werden. Folgende Hilfsmittel können zur Erreichung des Gesprächswendepunktes eingesetzt werden (siehe auch MSZG 2001; Wolf/Mlekusch 1997, S. 77): Pacing. Pacing bedeutet, im gleichen Schritt gehen, und damit ist gemeint, dass man sich umfassend auf den Gesprächspartner einstellen muss (Ulsamer 1997, S. 109). D. h. dass guter Kontakt darüber aufgebaut werden kann, dass man sich in Sprache, Körpersprache, Denkweise, Entscheidungsweise auf den Gesprächspartner einlässt und mit diesem eine gemeinsame Geschwindigkeit und einen gleichen Rhythmus findet. Beispielsweise stellt man sich darauf ein, wenn ein Mitarbeiter gestresst und etwas langsam ist und „überfährt“ ihn nicht, sondern gleicht seine Kommunikation und Körpersprache in der Geschwindigkeit an ihn an. Die tatsächliche Umsetzung dieses Pacings ist nicht immer einfach, jedoch hilft es schon, wenn man sich die Unterschiede in Geschwindigkeit und Vorgehensweise zwischen Gesprächspartnern vor Augen führt und so besser in der Lage ist, sein Gegenüber dort abzuholen, wo es sich gerade befindet. Aktives Zuhören. Aktives Zuhören ist eine Technik, die dazu dient, ein genaueres Verständnis der Position des Gesprächspartners zu erlangen. Durch gezieltes Nachfragen und Wiederholung von Inhalten und Äußerungen zu Gefühlen kann man Aussage und Gefühle des anderen besser in ihrer Wirkung erfassen und vermeidet Missverständnisse. Durch Augenkontakt wird Aufmerksamkeit gezeigt. Insgesamt wird so die Bereitschaft zur offenen Auseinandersetzung bekundet. Auch kann aktives Zuhören dazu dienen, Zeit zu gewinnen, die man für eine überlegte Reaktion benötigt. Versachlichung. Der nächste Schritt in der Kommunikation ist die Versachlichung. Diese ist die Voraussetzung für einen Gesprächswendepunkt zur Erwachsenen-Ich-ErwachsenenIch-Kommunikation. Die inhaltlichen und emotionalen Standpunkte der Konfliktparteien werden bestimmt. Dies muss emotionslos auf einer Metaebene erfolgen, die die Standpunkte und Emotionen rein sachlich beschreibt. Das heißt, man spricht über die Positionen der Konfliktparteien, anstatt selbst in der Rolle der Konfliktparteien zu agieren. Hierdurch wird eine Erwachsenen-Ich-Reaktion gefunden, ohne dass man die Emotionen automatisch unterdrückt. Dieser Bezug auf die Meta-Ebene funktioniert aber nur, wenn man die


239

Vernunftebene erst dann anspricht, wenn die Gefühlswelle abgeklungen ist. Ansonsten ist es kaum möglich, dass sich die Gesprächsteilnehmer aus ihrer Rolle lösen. Die Transaktionsanalyse ist also ein Instrument, das dazu dient, Rollenverhalten in der Kommunikation als Ursache von Konflikten zu erkennen, Der Projektleiter wird so in die Lage versetzt, Konflikte besser zu erkennen und bekommt erste Ansatzpunkte für deren Lösung über die Herstellung eines Gesprächswendepunktes. Außerdem sollte er diesen Ansatz nutzen, um seine eigene Kommunikation kritisch zu hinterfragen, denn auch diese kann selbstverständlich eine Quelle von Konflikten sein. Über Trainings kann ein Projektleiter hierbei Erfahrungen sammeln und ein ehrliches Feedback zu seiner Kommunikation erhalten. Ein gutes Kommunikationstraining sollte daher in der Weiterbildung für Projektleiter enthalten sein. Das Kommunikationstraining beschränkt sich aber natürlich nicht nur auf die Erkenntnisse der Transaktionsanalyse. Ein weiteres bekanntes Konzept ist die Neurolinguistische Programmierung. Diese bietet eine ganze Reihe von Instrumenten für gelungene Kommunikation, die auf einem ganzheitlichen und humanistischen Ansatz beruhen (Ulsamer 1997, S. 12). Nach der Transaktionsanalyse geht gelungener Kommunikation eine „Ich bin O.K. – du bist O.K.“Einstellung voraus. Wobei „O.K.“ meint, dass man den anderen in seiner Rolle, seiner Arbeit und seiner Persönlichkeit respektiert und akzeptiert (siehe hierzu grundlegend Ulsamer 1997, S. 26 ff.). Dies ist in der Projektarbeit ohnehin eine Voraussetzung für das Funktionieren von Teamarbeit, bei der die Stärken aller gezielt eingesetzt werden. In der Kommunikation führen „Nicht-O.K.“-Haltungen automatisch zu einem Ungleichgewicht. Sie führen zu mangelnder Motivation und Unsicherheit. Hierbei ist es egal, auf welcher Kommunikationsseite die „Nicht-O.K.“-Haltung angesiedelt ist. Der Projektleiter muss daher eine „O.K.-Haltung“ als Vorbild zeigen. Eventuell vorhandene Konflikte (etwa wenn jemand der Meinung ist, ein anderer im Team ist nicht „O.K.“) sollten im Vorfeld beseitigt werden. Eine „Nicht-O.K.Haltung“ gegenüber Mitarbeitern der Beratung oder des Klientenunternehmens kann ein den Beratungsprojekten immanentes Problem sein (siehe hierzu Abschnitt 6.4.1 ab S. 223). Wenn sich Projektmitarbeiter über Dinge wie Terminüberschreitungen, Unpünktlichkeit, zu große Arbeitspakete oder schlechte Kommunikation ärgern, dann stauen sie ihren Ärger in Form von „Rabattmarken“ an (MZSG 2001). Dies bedeutet, dass man quasi Ärgerpunkte über einen Zeitraum sammelt. Irgendwann ist dann der Punkt erreicht, dass das Rabattbuch voll ist und ein kleiner weiterer Ärger zu einer starken Gegenreaktion führt. Dies kann beispielsweise ein Wutausbruch sein, aber auch die Aufkündigung der Mitarbeit. Das Rabattmarkensammeln ist daher zu verhindern. Bei rein rationaler Erwachsenen-IchErwachsenen-Ich-Kommunikation werden keine Rabattmarken gesammelt, weil gegenseitiges Verständnis für das rationale Ergebnis herrscht. Für die Praxis gibt es darüber hinaus einige Tipps, um das Rabattmarken-Sammeln zu vermeiden (MZSG 2001): Umgehende Reaktion auf Frustration eines Mitarbeiters durch den Projektmanager Rasches Abführen von Emotionen (ruhig zulassen, dass es mal lauter wird) Meiden von Situationen, die zu Frustration führen werden

240


Reden über Ärger

Die vorgestellte Transaktionsanalyse ist eine Methode, die dem Projektleiter erlaubt, ineffiziente Kommunikation und Ursachen für Konflikte zu erkennen. Kenntnisse über Kommunikation und Transaktionsanalyse erlauben es auch den Projektmitarbeitern, gezielter und besser zu kommunizieren und Konflikte zu vermeiden. Der Vorteil der Transaktionsanalyse ist, dass sie recht einfach ist, schnell zu Ergebnissen führt und persönliche Verhaltensänderungen erlaubt. Sie ist eine Methode der Selbsterkenntnis – daher ist ihre Wirkung auch eingeschränkt, wenn es darum geht, die Kommunikation anderer zu verbessern. Der Projektleiter kann die Erkenntnisse aber einsetzen, um seine Kommunikation zu verbessern oder auch um Projektmitarbeiter auf Konfliktursachen hinzuweisen.

6.4.4

Teambildung in der Managementberatung

In diesem Buch wurde bisher schon an vielen Stellen der Begriff des Teams verwandt, ohne dass er bisher geklärt wurde. Heutzutage spricht man gerne von Teams, auch wenn manchmal der eher altmodisch wirkende Begriff der Gruppe geeigneter wäre. Ein Team ist eine Gruppe von Personen, die den gemeinsamen Auftrag haben, miteinander etwas zu erreichen. Zum Gelingen des Auftrags trägt jedes Gruppenmitglied mit seiner Kompetenz aktiv und individuell etwas bei. Alle Mitglieder verfolgen dabei ein gemeinsames Ziel, und die Arbeit des Einzelnen hängt von den anderen Teammitgliedern ab (Stumpf/Thomas 2003, S. 300). Diese Definition macht deutlich, warum ein gut funktionierendes Team wichtig im Projektmanagement ist. Ein Team leistet als Gesamtheit die Arbeit im Projekt und kann aufgrund der Abhängigkeiten der einzelnen Teilarbeitsschritte im Projekt auch nicht durch eine unverknüpfte Reihe von Einzeltätigkeiten ersetzt werden. Funktioniert das Projektteam nicht, geht das gemeinsame Projektziel verloren, und einzelne für das Gesamtprojekt notwendige Arbeitspakete können unter Umständen nicht sinnvoll integriert werden. Die Folge sind Doppelarbeiten, Zeitverzögerungen, Demotivierung von Projektmitarbeitern, schlechtere Projektergebnisse, höhere Kosten und im schlechtesten Fall das Nichterreichen des Projektziels. Gut funktionierende Teams entstehen aber nicht von selbst und auch nicht sofort, sondern müssen zusammenwachsen. Dies gilt insbesondere, wenn die Teammitglieder sich noch nicht kennen und – wie bei Managementprojekten oft gegeben – aus Mitarbeitern unterschiedlicher Unternehmen bestehen (siehe zum Konfliktpotenzial in dieser Situation Kapitel 6.4.1 ab S. 223). Die Phasen, die ein Team bis zur Erreichung seiner vollen Leistungsfähigkeit idealtypisch durchläuft, sind:12 Phase 1: Forming

12

Unter Berücksichtigung von Dassler (2005).


241

Phase 2: Storming Phase 3: Norming Phase 4: Performing

Im Folgenden sollen diese Phasen kurz erläutert werden. Forming bedeutet, dass die Teammitglieder benannt werden. Dies erfolgt bei Managementberatungsprojekten in der Unternehmensberatung in der Regel durch die Partner, im Klientenunternehmen durch die Vorgesetzten. Die Aufgabe des Projektleiters ist es, den Projektmitgliedern den Projektplan zu erläutern und die Aufgabenbereiche zu besprechen. Die Positionen und Kompetenzbereiche der Projektmitarbeiter werden für alle transparent gemacht. Hierzu kann auch das Kick-off-Meeting dienen. In der Phase des Stormings geht es darum, mögliche persönliche Konflikte zwischen den einzelnen Teammitgliedern oder bezüglich des Projektes zu klären. Die Mitglieder sollten durch den Projektleiter ermutigt werden, Bedenken oder Fragen in Bezug auf das Projekt offen anzusprechen, um diese im Gespräch bereinigen zu können. Hier sollten auch gerade mögliche unterschwellige Konflikte zwischen Managementberatung und Klientenunternehmen offensichtlich gemacht werden und es sollte versucht werden, diese auf die Sachebene zu transferieren (vergleiche hierzu Abbildung 90 auf S. 224). Das Storming dient also dazu, mögliche Konflikte, die später die Teamarbeit behindern können, auf den Tisch zu bringen und zu lösen. Ein Projektmanager, der die Konflikte in dieser Phase verdrängt, wird später im Projekt einen hohen Aufwand dafür betreiben, diese Konflikte in der laufenden Projektarbeit in den Griff zu bekommen. Konfliktscheu zu Beginn eines Projektes ist ein Grund für spätere Verzögerungen. Das Norming dient nun dazu, für die Teammitglieder aus Beratungsunternehmen und Klientenunternehmen Normen und Richtlinien hinsichtlich des Vorgehens und Verhaltens im Projekt festzulegen. Diese sollten – dort wo es möglich ist – von der Projektgruppe selbst entwickelt werden. Die Managementberatung sollte nicht den Fehler machen, ihr Projektmanagementsystem und ihre Verhaltensregeln im Projekt dem Klientenunternehmen überzustülpen, da dies die Akzeptanz verhindert. In der Zusammenarbeit kann man das eigene System anbieten und die Vorteile darstellen – muss aber immer offen sein, hiervon auch abzuweichen. Die Phase des Normings ist im Projektablauf idealerweise vor der Durchführungsphase abgeschlossen (vgl. die Projektphasen in Abschnitt 1.6 ab S. 44). Da das gesamte Projektteam in der Konzeptions- und Planungsphase jedoch nicht zwingend zusammenkommt, kann das Norming auch in die Startphase integriert werden, findet jedoch auch häufig erst in der Durchführungsphase statt, wenn die intensive Zusammenarbeit beginnt. Das Performing ist dann die Phase, in der die Teammitglieder als Team gemeinsam an der Projektdurchführung arbeiten, was dann in der Durchführungsphase spätestens erreicht werden soll. Eine in Managementberatungen durchaus verbreitete Methode des Teambuildings ist das Outdoor-Event. Dies ist eine aktive, erfahrungsorientierte Methode, die die Phasen des Teamentwicklungsprozesses transparent und konkret erlebbar macht (Stumpf/Thomas 2003, S. 629).

242


Konkret geht es darum, dass meist unter Anleitung erfahrener Trainer in Gruppen Aufgaben wie die Überquerung eines Flusses, das Klettern auf einen Baum, gemeinsames Segeln, Bootswandern oder eine Orientierungswanderung gelöst werden müssen. Diese Maßnahmen sind recht teuer und zeitaufwändig, haben aber wesentliche Vorteile, weshalb sie dennoch gerne eingesetzt werden. Zu beachten ist dabei, dass tatsächlich das Team, welches geformt werden soll, geschlossen als solches teilnimmt. In einem Outdoor-Event werden die Teilnehmer in einen so genannten Herausforderungsbereich versetzt, indem sie die bisherige Komfortzone verlassen. Sie müssen also abseits der gewohnten und sicheren Umgebung neue Aufgaben bestehen. Dieser persönliche Herausforderungsbereich führt dazu, dass ein blockadefreies Denken einsetzen kann, welches evtl. noch vorhanden ist, solange man in die Projektsituation eingebunden ist. Das Verhalten in eingefahrenen Mustern wird unmöglich, da es neue, überraschende Herausforderungen gibt, für die die Mitarbeiter und das Team noch kein eingefahrenes Vorgehensmodell haben. Die gewohnten Hierarchien können hier durchbrochen werden, und da man jenseits der normalen Umgebung ist, ist ein Probehandeln möglich, indem man neue Vorgehensweisen im Team zur Problemlösung einsetzt, die nur hier möglich sind, da man keine unwiderruflichen Konsequenzen fürchten muss. Outdoor bedeutet also nicht nur „unter freiem Himmel“, sondern auch außerhalb der betrieblichen Denkmuster und Zwänge. Das Lernen soll hier durch den körperlichen Anteil des Events noch verstärkt werden, da es über den Kopf hinausgeht und den ganzen Körper einbezieht. Die scheinbar vorhandenen Gefahren beim Event sollen dazu führen, sich auch emotional authentisch zu verhalten, was sonst in kontrollierten Firmensituationen nicht immer stattfindet. Ohne einen geeigneten Trainer, der sicherstellt, dass die Teamaspekte bei der Aufgabenstellung- und -lösung berücksichtigt werden, ist die Gefahr bei einem solchen Event jedoch gegeben, dass es zu einer eher touristischen Veranstaltung gerät. Ein Event ist daher professionell zu planen und die Durchführung eng zu steuern. Auch sollte der Transfer in die betriebliche Praxis sichergestellt werden. Dies kann beispielsweise durch Folgetreffen mit Bezugnahme auf die Teamphasen, Abfrage von Verhaltenskonsequenzen und die personenindividuelle Vereinbarung von Verhaltenszielen geschehen. Ein Outdoor-Event kann man trotz der hohen Kosten in Beratungsunternehmen einsetzen, da die Mitarbeiter des Beratungsunternehmens langfristig in unterschiedlichen Projekten zusammenarbeiten werden. Zudem ist es dort aufgrund der Projektarbeit relativ schwierig, einen über die jeweiligen Projektteams hinausgehenden Teamgedanken zu etablieren. Dieser ist aber für die Managementberatung als solche und auch für zukünftige Projektarbeit in neuen Teamkonstellationen wichtig. Bei gemischten Teams aus Beratung und Klientenunternehmen würde man ein Outdoor-Event nur einsetzten, wenn es akute Teamprobleme gibt, die man lösen möchte. Möglich ist natürlich auch der Einsatz als Incentive zur extrinsischen Motivation. Die Phasen des Teambuildings können auch in Teambuilding-Maßnahmen als Diagnose und Zielinstrument eingesetzt werden. Sie werden dann als Teamuhr graphisch auf einem Ziffernblatt eingetragen, wobei die Begriffe in chronologischer Reihenfolge drei, sechs, neun und


243

zwölf Uhr zugeordnet sind. Ein Team stellt dann zu Beginn des Trainings per Selbsteinschätzung jedes Teammitglieds fest, wo das Team sich gerade befindet. Dies kann etwa durch das Kleben von Klebepunkten auf eine solche Teamuhr erfolgen. Nach Abschluss des Trainings erfolgt dann eine erneute Einschätzung – verbunden mit der Hoffnung, dass sich das Team auf der Uhr weiterentwickelt hat. Durch den Einsatz der Uhr hat man nicht nur ein Diagnoseinstrument, sondern auch die Möglichkeit, den Teambildungsprozess für die Teammitglieder greifbarer zu machen.

Praxisbox 26: Teambildung Das Inhouse Consulting von Deutsche Post World Net veranstaltet für alle Mitarbeiter einmal im Jahr eine meist dreitägige Strategiesitzung. In diese Strategiesitzung ist ein eintägiges Teamevent integriert. Meist startet die Veranstaltung an einem Mittwoch und dauert bis Samstag. Der Mittwoch wird zur Anreise an einen vom Arbeitsplatz entfernten Ort genutzt. Hierbei handelt es sich um Tagungshotels, die so gelegen sind, dass man etwas abgeschieden von der Arbeit und anderen Ablenkungen ist. Am ersten Tag der Strategiesitzung sowie teilweise am Vormittag des zweiten Tages werden inhaltliche Themen bearbeitet. Dies erfolgt als Workshop in der gesamten oder auch in Teilgruppen. Die Mitarbeiter entwickeln hierbei ausgewählte Aspekte des Managementsystems der Beratung und arbeiten so an den Grundsteinen der Beratungsorganisation mit. Zum Beispiel wurden hier Themen des Wissensmanagements, des Aufbaus von einheitlichen Beratungstools, der Personalentwicklung (etwa Sabbaticals; Unterstützung von ph. D.- oder MBA-Programmen) oder des Projektstaffings (d. h. der Frage, welche Person welches Projekt bearbeitet) gemeinsam entwickelt. Die Partizipation aller Consultants an diesen übergreifenden Fragestellungen enthält mehrere positive Aspekte: Die Bearbeitung erfolgt dabei in Gruppenzusammensetzungen, die nicht den Teams der Beratungsprojekte entsprechen. Hierdurch wird auch der beratungsprojektübergreifende Zusammenhalt gefördert. Die Arbeit wird von den Consultants selbst geleistet. Die Mitarbeiter entwickeln die entsprechenden für sie selbst relevanten Aufgabenstellungen nach ihren Vorstellungen, so dass die Ergebnisse auch für sie praktikabel sind. Die Möglichkeit, aktiv bei der Gestaltung von Fragen der Organisation eingebunden zu sein, soll die Gesamtmotivation der Consultants steigern, da wahrgenommen wird, dass der eigene Einsatz tatsächlich Auswirkungen auf die eigene Arbeitsumgebung hat. Am zweiten Tag schließt der Strategieworkshop dann mit einer Veranstaltung, die rein teambildende Funktion besitzt. Dies kann beispielsweise das gemeinsame Orientierungswandern, das Bauen von Brücken, Flößen etc. sein. Hierbei gilt es stets, im Team Lösungen für Aufgaben zu erarbeiten, die jenseits des normalen Arbeitsalltags liegen. Die Aufgaben sind dabei so gewählt, dass sie nur lösbar sind, wenn jeder im Team sich mit seinen

244


speziellen Fähigkeiten einsetzt. Durch die ungewöhnlichen Aufgaben und das Aufbrechen alltäglicher Strukturen und Vorgehensweisen findet man neue Wege der Zusammenarbeit. Ein Ziel dieser Maßnahmen ist es auch, eine persönliche Basis für informelle Kommunikation zwischen den Mitarbeitern zu schaffen. Weitere auch in vielen anderen Unternehmen übliche Maßnahmen dieser Art sind Weihnachtsfeiern oder gemeinsames Grillen im Sommer. Im Inhouse Consulting ist man sich dabei sehr wohl bewusst, dass diese Maßnahmen lediglich eine Unterstützung der schon in der täglichen Projekt- und Beratungsarbeit gelebten Teamorientierung sein können.

Projektabschluss

245

7 Projektabschluss

Diese letzte Phase ist für das gesamte Projekt und den Projektleiter enorm wichtig, denn letztendlich entscheidet sich hier, ob die mit dem Projekt verbundenen Ziele erreicht wurden. Die Wahrnehmung des Auftraggebers an diesem Punkt des Projektes ist aus Sicht des Managementberatungsunternehmens daher sehr wichtig, denn der Projektabschluss bestimmt die wahrgenommene Ergebnisqualität. Diese wiederum wird die Bereitschaft des Auftraggebers zu neuen oder Anschlussprojekten stark beeinflussen. Zudem wird sie einen wesentlichen Einfluss auf die aufgrund der Unsicherheit der Qualitätsbeurteilung einer Beratungsleistung sehr wichtige persönliche Weiterempfehlung durch den Auftraggeber (positive Mundpropaganda) besitzen. Kritisch ist es, ein Projekt sang und klanglos auslaufen zu lassen – also quasi ohne offizielles Projektende. Dies hat meist zur Folge, dass noch Restarbeiten verbleiben, deren Erledigung nicht geregelt ist, dass die Wahrnehmung beim Auftraggeber unscharf bis negativ ist und die Projektmitarbeiter aufgrund der unklaren Situation unzufrieden sind. Die in Unternehmen mitunter beobachtbare Tendenz von Projektmitarbeitern, Projekte nicht abzuschließen, um nicht nach Projektende andere, unangenehmere Tätigkeiten übernehmen zu müssen (Litke 1995, S. 248), ist bei Managementberatungsprojekten zumindest auf Seiten des Beratungsunternehmens kaum gegeben. Aufgrund der Fakturierung der Arbeit wird ein Auftraggeber eine solche unbegründete Projektverlängerung nicht akzeptieren. Das Projektende bedeutet dabei nicht automatisch, dass das Projekt erfolgreich abgeschlossen wurde. Es kann aus verschiedenen Gründen eintreten: Das Projekt kann aufgrund mangelnder Aussicht auf Zielerreichung abgebrochen werden, es kann faktische beendet werden, wenn Mitarbeiter für andere Funktionen abgezogen werden, es kann aufgelöst werden, weil veränderte Rahmenbedingungen das Projektziel in Frage stellen, oder es kann erfolgreich zum Projektabschluss gebracht werden.

In allen Fällen sollte der Projektleiter für ein geregeltes Projektende sorgen. Am einfachsten und strukturiertesten ist dies natürlich bei erfolgreichem Projektabschluss möglich, weil dort der Projektleiter die Kontrolle über den Projektabschluss besitzt.

246

Projektabschluss

Hier wird deshalb auf den erfolgreichen Projektabschluss eingegangen. Wird das Projekt aus anderen Gründen beendet, dann sind grundsätzlich die gleichen Schritte beim Projektende zu beachten, jedoch kann es sein, dass der eine oder andere Punkt hinfällig wird. Beim erfolgreichen Projektabschluss sollten einige Schritte beachtet werden, die hierbei zu erledigen sind. Sie dienen dazu, die durch das Projekt angestoßenen Aktivitäten zu beenden und die durch das Projekt entstandene neu geschaffene Situation als Regelzustand abzusichern. Man spricht bei Letzterem auch von der Überleitung in die Linie, d. h., die Projektergebnisse werden im normalen Geschäftsbetrieb eines Unternehmens implementiert. Als Schritte zum Projektabschluss sind zu nennen: a)

Formales Projektende durch Abschlusspräsentation mit dem Lenkungsausschuss und dem Auftraggeber. Es bietet sich an, eine solche Präsentation durchzuführen, weil diese einige wichtige Funktionen erfüllt, die durch eine reine Übergabe von Dokumenten zum Projektende nicht gewährleistet sind: Möglichkeit, offene Fragen direkt anzusprechen, falls nötig noch Konsens im Lenkungsausschuss herstellen Direktes Feedback durch den Auftraggeber und die Lenkungsausschussmitglieder zu den Ergebnissen und Inhalten, dem weiterem Vorgehen und zur Zufriedenheit Direktes Treffen von notwendigen Entscheidungen Motivation der Projektteilnehmer durch die Möglichkeit, die eigene Arbeit zu vertreten und Setzen eines offiziellen Schlusspunktes

Eine sehr sorgfältige Vorbereitung dieser Abschlusspräsentation ist wichtig, da diese Präsentation von vielleicht 30 oder 90 Minuten die gesamte Projektarbeit von Monaten repräsentiert. Neben der inhaltlichen Sorgfalt ist hier insbesondere auf die formale Sorgfalt hinzuweisen. Die Endpräsentation muss gestalterisch höchsten Anforderungen genügen und sie muss textlich mehrfach Korrektur gelesen worden sein, um Rechtschreib- oder Rechenfehler zu vermeiden. Dies ist deshalb so bedeutsam, weil sich die Projektergebnisse in Managementberatungsprojekten teilweise einer direkten Qualitätsbewertung entziehen. So ist beispielsweise die Güte einer Unternehmensbewertung oder eines Strategievorschlages inhaltlich vorab nicht beurteilbar. Also werden zur Qualitätsbeurteilung die sichtbaren Eigenschaften herangezogen. Dies ist neben Faktoren wie der Güte der Quellen auch die Sorgfalt bei der Erstellung der Präsentation. Tendenziell besteht die Neigung, hinter einer sorgfältigen Präsentation auch eine sorgfältig erstellte Analyse oder Empfehlung zu vermuten. Aus diesem Grund besitzen viele Managementberatungen auch ein Backoffice, das die Berater bei der professionellen Präsentationserstellung unterstützt (siehe auch Praxisbox 17 ab S. 157). b)

Entlastung der Projektmitarbeiter und des Projektleiters durch den Auftraggeber. Die Entlastung des Projektleiters findet in der Regel in der Abschlusspräsentation statt (siehe vorherigen Punkt). Es ist meist sinnvoll, eine entsprechende Formulierung als Beschluss-

Projektabschluss

247

vorlage in die Endpräsentation aufzunehmen. Diese sollte einfach formuliert sein. Ein Beispiel ist: „Der Lenkungsausschuss beschließt, das das Projektziel erreicht wurde, und entlastet den Projektleiter und das Projektteam.“ Hiermit kann dann die Entlastung beschlossen und im Protokoll festgehalten werden. Die Entlastung dient dazu, formal festzustellen, dass der Projektleiter und das Projektteam ihre Aufgaben im Projekt erfüllt haben und dass die Arbeit hiermit beendet ist. Sollten noch Nachforderungen bestehen, sollten sie konkret benannt werden. c)

Erstellung einer Enddokumentation und Übergabe an den Auftraggeber. Die Übergabe sollte in der Abschlusspräsentation erfolgen, da dies eine hohe Aufmerksamkeit erzeugt und zudem die Möglichkeit besteht, ein paar erläuternde Worte zu der Dokumentation zu sagen. Eine solche Enddokumentation bzw. ein Abschlussbericht sollte als Dokumentation der Projektarbeit dienen und so nicht nur die erstellten Ergebnisse umfassen, sondern auch den Weg dorthin dokumentieren. Dies kann für die spätere Verwendung der Ergebnisse sehr hilfreich sein. Die Enddokumentation sollte entsprechend folgende Punkte enthalten (in Anlehnung an Boy/Dudek/Kuschel 1997, S. 111-122): Projektziele Vorgehen/Projektplan Teilnehmer und Funktionen Leistungen und Ergebnisse des Projektes Kosten Implementierung bzw. Implementierungsvorschlag Probleme Ausblick/weitere Empfehlung

Ein Endbericht sollte so formuliert sein, dass er für Personen lesbar ist, die nicht am Projekt teilgenommen haben. Dies ermöglicht, die Informationen möglichst breit und lange zu nutzen, auch wenn die Projektteilnehmer nicht mehr verfügbar sind. d)

Durchführung eines internen Projektreviews. Es sollte also eine Bewertung des Projektes erfolgen, um daraus für die Zukunft Schlüsse ziehen zu können. Dies kann insbesondere die in der Projektplanung enthaltenen Punkte umfassen. „Intern“ bedeutet hierbei, dass das Projektteam und der Projektleiter dieses Review aus ihrer Sicht durchführen. Im Review können folgende Punkte enthalten sein: Wurden die Zielvorgaben (für den Auftraggeber, für das Projektteam, für die Stakeholder) erreicht? Wurden Ressourcenpläne eingehalten? Wurden Kostenpläne eingehalten?

248

Projektabschluss

Wurden Zeitpläne eingehalten? Abweichungsanalyse, d. h., Gründe für mögliche Abweichungen vom Plan werden ermittelt und dokumentiert. Welche Probleme gab es, wie wurden sie gelöst?

Das Review sollte dokumentiert werden, und es sollte sichergestellt werden, dass die notwendigen Informationen über Schwachstellen in der bisherigen Vorgehensweise anderen Projektleitern im Unternehmen zur Verfügung stehen. e)

Durchführung von Feedback-Runden mit dem Auftraggeber. D. h. Befragung des Auftraggebers bzgl. seiner Zufriedenheit mit dem Ergebnis, der Zusammenarbeit, der Qualifikation der Projektteilnehmer, der Planeinhaltung, der Kommunikation etc. Bei externen Beratungsprojekten kann zudem gefragt werden, wie das Preis/Leistungs-Verhältnis eingeschätzt wird und ob der Auftraggeber in Zukunft wieder mit dem Team zusammenarbeiten würde. Wichtig ist an dieser Stelle, dass nicht nur die Zufriedenheit bzw. die Qualität des Projektergebnisses abgefragt wird, sondern auch die Einschätzung des Vorgehens im Projekt (Prozessqualität) und die Einschätzung der Leistungsfähigkeit der Projektmitarbeiter (Potenzialqualität). Es wird also versucht, ein möglichst ganzheitliches Bild der Wahrnehmung des Auftraggebers zu erlangen. Dies kann auch auf wichtige Stakeholder ausgedehnt werden. Diese Feedback-Runden dienen in erster Linie nicht der Personalbeurteilung, um etwa Prämien zu bestimmen oder über Beförderungen zu entscheiden, sondern sie dienen in erster Linie dazu, aus der Projektarbeit zu lernen und zu verstehen, was aus Sicht des Auftraggebers Stärken und Schwächen des Projektes waren. Weiterhin sollten Feedback-Runden mit den Projektmitarbeitern durchgeführt werden, um deren Zufriedenheit zu ermitteln und ebenfalls hieraus für die Zukunft lernen zu können. Dies ist wichtig, da nur leistungsfähige Teams sehr gute Ergebnisse erbringen können. Hierzu bieten sich neben Gesprächen in größeren Projekten auch anonyme Fragebögen an. Diese erlauben eine strukturierte Informationserhebung und ermöglichen unbeeinflusste Ergebnisse durch die Anonymität.

Praxisbox 27: Kundenbefragung Um für die strategische Steuerung des Inhouse Consultings vergleichbare Daten zu haben, wird ein Fragebogen zur Kundenbefragung eingesetzt. Aufgrund der hohen Anzahl von internationalen Projekten, ist man dazu übergegangen, die Kundenbefragungen standardisiert über das konzernweite Intranet durchzuführen. Der Fragebogen hierzu steht in Englisch und in Deutsch im Intranet zur Verfügung. Die Befragung selbst wird vom Marktforschungsbereich von Deutsche Post World Net durchgeführt, um die Unabhängigkeit der Erhebung sicherzustellen. Die Abbildung 99 zeigt einen Ausschnitt dieses Fragebogens.

Projektabschluss

249

Neben diesen Erhebungen werden bei Projektende zusätzlich noch persönliche Gespräche mit dem Auftraggeber geführt.

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 99: Kundenbefragung (Auszug) Insgesamt ist der Fragebogen bewusst kurz gehalten, um die Antwortwahrscheinlichkeit zu erhöhen. Es werden daher nur die wichtigsten Aspekte für ein Projekt und die Managementberatung abgefragt. Enthalten sind: Gesamtzufriedenheit mit dem Inhouse Consulting von Deutsche Post World Net Gesamtzufriedenheit mit dem letzten Projekt Zufriedenheit mit der Qualifikation der Mitarbeiter (um Schulungsbedarf zu erkennen) Zeitmanagement der Mitarbeiter (stand der Projektleiter ausreichend zur Verfügung, wurde der Zeitplan eingehalten, wurden die Prioritäten richtig gesetzt?) Zusammenarbeit von Beratern und Linienorganisation bzw. Auftraggeber (gab es Reibungsverluste?) Vergleich der Arbeit des Inhouse Consulting mit anderen Managementberatungen. Wird Verbesserungspotenzial beim Inhouse Consulting gesehen?

250

Projektabschluss

Ist weiterhin Beratungsbedarf vorhanden? Würden Sie nochmals mit dem Inhouse Consulting zusammenarbeiten?

f)

Abschlussmotivation und Dank an die Projektmitarbeiter. Je nach Projektdauer und Einbindung haben die Projektmitarbeiter mitunter sehr intensiv und lange an den Projektaufgaben gearbeitet. Wenn es gelungen ist, die richtige Motivation und den richtigen Teamgeist zu erzeugen, dann haben die Mitarbeiter sich stark für das Projekt eingesetzt und damit identifiziert. Ein Dank an die Projektmitarbeiter ist bei erfolgreicher Projektarbeit selbstverständlich. Es kann aber auch sinnvoll sein, eine darüber hinausgehende Abschlussmotivation durchzuführen. Diese kann verschiedene Ausprägungen haben. Sie kann monetär sein (wovon wegen der geringen Dauerhaftigkeit eines solchen Incentives eher abzusehen ist) oder sie kann nichtmonetär sein (vgl. Kapitel 6.3 ab S. 219). Ein Beispiel für eine nichtmonetäre Abschlussmotivation ist ein gemeinsames Teamessen oder eine andere Teamveranstaltung. Eine solche Veranstaltung kann folgende Zwecke haben: Das Team noch einmal zu stärken, damit ein Teamzusammenhalt auch nach Beendigung des Projektes bestehen bleibt. Dies kann sinnvoll sein, wenn einige Funktionen aus dem Projekt nach Abschluss des Projektes im Team verbleiben oder das Team in anderer Konstellation oder mit anderer Aufgabe bestehen bleibt. Die Motivation der Mitarbeiter für weitere Projekte zu steigern. Motivation während des Projektes durch Aussicht auf ein Incentive bei erfolgreichem Projektende. Dabei muss das Incentive dem Aufwand der Projektarbeit angepasst sein, da es sonst eher lächerlich wirkt.

g)

13

Wissensmanagement. Wissensmanagement ist ein weites Thema und kann hier nur von der Bedeutung her angerissen werden.13 Das Wissen ist eine der Kernressourcen einer Managementberatung. Sachwerte bestehen in einer Beratung kaum. In erster Linie wäre noch eine IT-Infrastruktur zu nennen, die in der Regel aber auch austauschbar ist und kein Alleinstellungsmerkmal einer Managementberatung ist. Der Wert eines Managementberatungsunternehmens bestimmt sich durch die Fähigkeiten und das Wissen der Mitarbeiter (Nohr 1999, S. 16). Diese bringen einiges Wissen mit in das Beratungsunternehmen, lernen aber dort auch vieles, was für die Beratung wichtig ist. Dies sind spezielle Methoden im Projektmanagement und in der Projektdurchführung, dazu zählt aber auch Wissen über die beratenen Unternehmen, die durchgeführten Projekte und beteiligten Personen. Dieses Wissen sollte in der Managementberatung möglichst jedem Berater zur Verfügung stehen, damit Fehler nicht doppelt gemacht werden und gute Beispiele adaptiert werden können, was auch aufgrund der in Beratungen im Vergleich zu anderen Unternehmen durchaus höheren Personalfluktuation wichtig ist, da das Wissen nicht verloren gehen darf, wenn ein Mitarbeiter das Beratungsunternehmen verlässt. Aus diesem Grund haben alle großen Beratungsunternehmen aufwändige Prozesse und IT-

Eine Übersicht bietet beispielsweise Willke (2004).

Projektabschluss

251

Lösungen etabliert, um das Wissen ihrer Mitarbeiter zu speichern und allen Mitarbeitern wieder verfügbar zu machen. Dies wird insbesondere auch dann notwendig, wenn Projekte dezentral, international arbeiten und die Beratungsgesellschaften auch entsprechend aufgestellt sind oder sogar nur aus virtuellen Netzwerken verbundener, aber selbständiger Unternehmen bestehen. Hier muss dann gezielt das richtig gefilterte Wissen an der richtigen Stelle zur Verfügung gestellt werden. Was genau beinhaltet aber nun das Wissensmanagement? Die Ziele des Wissensmanagements sind zunächst recht einfach. Sie sind in Abbildung 100 dargestellt:

Das richtige Wissen …

…zur richtigen Zeit

…am richtigen Ort.

Quelle: Nohr (2001), S. 4 Abbildung 100: Ziele des Wissensmanagements

Die Aufgaben, die sich daraus ergeben, können wie folgt zusammengefasst werden (in Anlehnung an Nohr 2001, S. 4): Erschließen von Wissen. D. h. Erfahrungen und Best Practice aus Projekten sammeln. Es muss entsprechende Prozesse geben, in denen die Informationen gesammelt und strukturiert werden. Neben der formalen Regelung durch Prozesse bedarf es auch einer Informationskultur, d. h., Wissen muss geschätzt werden und Leistung für das Wissensmanagement muss belohnt werden. Verfügbarmachen von Wissen für die Projekte. Dies ist in der Regel durch den Aufbau von Wissensdatenbanken geregelt, auf die nach einem Berechtigungskonzept zugegriffen werden darf. D. h., nicht jeder bekommt jede Information, sondern bestimmte Informationen sind bestimmten Empfängern vorbehalten. So darf zum Beispiel nicht jeder auf vertrauliche Studien zugreifen. Eine Herausforderung hierbei

252

Projektabschluss

ist wiederum die Struktur der Informationen, denn das Wissen muss nicht nur existieren, sondern auch gefunden werden. Erleichtern des effektiven und effizienten Entwickelns von neuem Wissen. So werden in Beratungen oft Cases aufbereitet, um aus Projekten gezielt Wissen zu gewinnen. Zudem werden Methoden entwickelt, die als Standardmethoden allen Mitarbeitern für die Projektarbeit zur Verfügung stehen. Den Mitarbeitern wird entsprechend Zeit für die Entwicklung dieser Tools gegeben und im Rahmen der Beurteilung wird die mit eingeflossene Arbeit berücksichtigt. Sicherstellen, dass jeder im Projekt weiß, wo Wissen verfügbar ist. Dies ist die Aufgabe des Projektleiters. Zudem muss er sicherstellen, dass Mitarbeiter des Beratungsunternehmens und des Klientenunternehmens gleichsam auf die für sie relevanten Informationen zugreifen können (unter Berücksichtigung der notwendigen Vertraulichkeit bestimmter Informationen). Verwendung und Einsatz des Wissens anregen. D. h., es muss Anreize für die Mitarbeiter geben, auf das Wissen zuzugreifen. Der beste Anreiz ist dabei, wenn die Mitarbeiter einen Nutzen aus der Information für ihre Arbeit ziehen können.

An den Aufgaben zeigt sich schon, dass Wissensmanagement streng genommen nicht beim Projektende angesiedelt sein darf, sondern kontinuierlich erfolgen sollte. Da Wissensmanagement aber auch Aufwand bedeutet, erfolgen zumindest die Wissensgenerierung und -speicherung zumeist am Projektende, nämlich dann, wenn das Wissensmanagement Teil der Beurteilung durch den Vorgesetzten ist. Problematisch im Wissensmanagement kann es nämlich sein, dass Wissen die Eigenschaften eines öffentlichen Gutes hat. Der Zugriff auf funktionierende Wissensdatenbanken ist für Berater frei, der Aufwand bei der Pflege und Erzeugung von Wissen wird aber nur ungern erbracht, da der eigene Nutzen dieses Aufwandes eher gering ist. Die Informationsinhalte, die im Wissensmanagement einer Beratung vorgehalten werden, können vielfältig sein. Dies kann Wissen über die Kunden/Auftraggeber sein, Branchenwissen, Methodenwissen, Projektmanagement-Tools und Erfahrungen etc. Gerade das Wissen, welches Vergleiche von verschiedenen Unternehmen zulässt, ist für Beratungsunternehmen natürlich besonders interessant, weil diese externen Informationen in der Regel nicht in den beratenen Unternehmen zur Verfügung stehen. Es ist also wichtig, ein Wissensmanagement durch entsprechende Sollprozesse und Strukturen im Beratungsunternehmen zu verankern.

Projektabschluss

253

Praxisbox 28: Wissensmanagement Das Inhouse Consulting hat ein umfangreiches Wissensmanagement mit verschiedenen Modulen etabliert. Dies umfasst verschiedenste Aspekte aus dem Projektmanagement aber auch bzgl. inhaltlicher Punkte der Projektarbeit. Die Informationen sind über ein Rechtemanagement klassifiziert, so dass die Vertraulichkeit erhalten bleibt. Die Mitarbeiter haben so gezielt gesteuerten Zugriff auf vertrauliche Projektergebnisse oder Personalinformationen. Die wichtigsten Bausteine sind: Methoden-Datenbank. Für die in der Projektarbeit eingesetzten Methoden (also etwa Benchmarking, Change-Management, Wertanalyse etc.) besteht eine Datenbank, in der die einzelnen Methoden erläutert werden. Darüber hinaus bestehen Verlinkungen zu den Dokumentationen der bereits mit der Methode durchgeführten Projekte. Zu den Methoden sind Experten aus dem Inhouse Consulting benannt, die ebenfalls über die Datenbank zu finden sind. Diese sind auch für die Pflege und Weiterentwicklung der Datenbank zuständig.

Project name 00_Proposal 00_Proposal 01_Project Fact Sheet 01_Definition 01_WBS 02_Stakeholder Map 03_Resource Requirements 04_Change Requests 02_Planning 01_Project Plan 02_Team Charter 03_Stakeholder Communication Plan 04_Financial Business Case 05_Risk Analysis 03_Execution 01_Method 02_Deliverables 03_Protocols 04_Analysis 05_NN 04_Closure 01_KM Documents 02_Closure Workshop 03_Projet Fact Sheet 05_Controlling 01_Status Reports 02_Partner Jour Fixe 03_Client Jour Fixe 04_Financial Controlling (opt.) 06_Meetings 07_Sources 08_Contact List

Projektdokumentations-Datenbank. Laufende Projekte und alte Projekte sind hier im Zugriff. Jedes Projekt hat im Rahmen des CCA eine standardisierte Dokumentation. Die einzelnen Templates sind in einer Datenbank verwaltet, so dass auf sie zentral zugegriffen werden kann. Jeder Projektleiter ist verantwortlich für die Dokumentation seiner Projekte und die Erfüllung dieser Aufgabe ist Teil der Personalbeurteilung. Um den schnellen Zugriff ohne langes Suchen zu ermöglichen, sind diese Dokumente in einem für jedes Projekt gleichen Verzeichnisbaum gespeichert. Die folgende Abbildung zeigt diese Struktur.

Quelle: Inhouse Consulting Deutsche Post World Net Abbildung 101: Projektordner-Struktur

254

Projektabschluss

Unternehmens-Factbooks. Über die wichtigsten Sparten und Tochterunternehmen gibt es Factbooks, die die wesentlichen Ansprechpartner, Unternehmenszahlen und eine Erläuterung der Produkte und das Geschäftsmodell enthalten. Einsatzplanungstool. Es dient der Ermittlung freier Personalressourcen auf Basis der laufenden Projekte und geplanten Projekte. So kann geprüft werden, ob ein Projekt „gestafft“ werden kann, d. h. ob ausreichend qualifizierte Mitarbeiter zur Verfügung stehen. Beraterdatenbank. Hier ist jeder Berater mit seinem Profil und insbesondere mit dem Kenntnisstand bezüglich Methoden und Unternehmensbereichen aufgeführt. Sie dient bei der Akquise dazu, die Kompetenzen der Mitarbeiter aufzeigen zu können sowie zur Entscheidung, welcher Mitarbeiter wo eingesetzt werden soll. Diese Informationen sind entsprechend nur einem eingeschränkten Personenkreis zugänglich.

h)

Formale Auflösung der Projektorganisation und Integration der Mitarbeiter in neue Tätigkeiten. Hierbei geht es darum, dass die Mitarbeiter formal in eine andere Organisationsstruktur eingebunden werden. Dies betrifft in der Hauptsache die Linienmitarbeiter, denn die Berater werden schnell in einem Folgeprojekt eingesetzt werden. Der Einsatz der Mitarbeiter nach Projektende sollte natürlich nicht erst bei Projektende angesprochen werden, denn die Mitarbeiter beschäftigt ihr zukünftiger Arbeitsplatz schon vorher. Unwissenheit über die folgende Aufgabe kann demotivierend wirken und sollte daher grundsätzlich vermieden werden, soweit dies möglich ist.

Literaturverzeichnis

255


BACKHAUS, K. (1999): Industriegütermarketing, 6. A., München. BECKER, M. L. (2002): Personalentwicklung, Stuttgart. BDU (2006): Der Markt der Unternehmensberater in Deutschland, online veröffentlicht unter dem URL: www.bdu.de, Zugriff vom 19.05.2006. BEITZ, H./LOCH, A. (2003): Assessment Center. Erfolgstipps und Übungen für Bewerber. München. BIERMANN, T (1999): Dienstleistungsmanagement, München, Wien. BLAZEK, A./ZILLMER, D. R. (2001): Projekt-Controlling. Das Projekt als Unternehmen in der Unternehmung, Offenburg. BOY, J./DUDEK, C./KUSCHEL, S. (1997): Projektmanagement, 4. A., Offenbach. BRÖCKERMANN, R. (2001): Personalwirtschaft. Lehrbuch für das praxisorientierte Studium, 2. A., Stuttgart. BRUHN, M. (1998): Wirtschaftlichkeit des Qualitätsmanagements. Qualitätscontrolling für Dienstleistungen, Berlin et al. BRUHN, M. (2000): Wirtschaftlichkeit des Qualitätsmanagements für Dienstleistungen, in: STAUSS, B./BRUHN, M. (Hrsg.): Dienstleistungsqualität, Konzepte – Methoden – Erfahrungen, 3. A., Wiesbaden, S. 535-546. DASSLER, F. (2005): Events als Instrument zur Teambildung, Dokumentation zum Referat in der Lehrveranstaltung „Einführung in das Projektmanagement“ an der Hochschule für Angewandte Wissenschaften Hamburg im Wintersemester 2004/2005. DRUMM, H. J. (2005): Personalwirtschaft, 5. A., Berlin, Heidelberg, New York. ELFGEN, R./KLAILE, P. (1987): Unternehmensberatung, Stuttgart. FINK, D. (2004): o. T., zitiert nach Student, D./Werres, T./Stuhr, A.(2004): McKinsey & Co. im Praxis-Test, online veröffentlicht unter dem URL: http://www.managermagazin.de/unternehmen/beratertest/0,2828,296166,00.html, Zugriff vom 11.05.2004. GABLER (1995): Gabler Lexikon Wirtschaft, 5. A., Wiesbaden.

256


GARTNER, P./WUTTKE, T. (2000): Projektmanagement. A Guide to the Project Management Body of Knowledge, Berlin. GLASL, F. (1990): Konfliktmanagement: ein Handbuch für Führungskräfte und Berater, 2. A., Bern/Stuttgart. HALLER, S. (1998): Beurteilung von Dienstleistungsqualität, 2. A., Wiesbaden. HARTENSTEIN, M./BILLING, F./SCHAWEL, C./GREIN, M. (2004): Karriere machen: Der Weg in die Unternehmensberatung 2005/2006. Consulting Case Studies erfolgreich bearbeiten. 5. A., Wiesbaden. HECHE, D. (2004): Praxis des Projektmanagements, Berlin et al. HELD, M./VON BISMARCK, W.-B./BUNGARD, W./CIERJACKS, M. (1999): Informelle Kommunikation und betrieblicher Wandel, in: Mannheimer Beiträge, Themenheft 1/1999, S. 10-20. HESSE, J./SCHRADER, H. C. (2002): Assessment Center. Das härteste Personalauswahlverfahren bestehen, 2. A., Frankfurt a. M. HÖSELBARTH, F. (2005): Höselbath-Lay-Index, Presseinformation Nr. 2 vom Oktober 2005, online veröffentlicht unter dem URL: www.hoeselbarth-lay-index.com, Zugriff vom 19.05.2006. INHOUSE CONSULTING, DPWN (2004): Interne Dokumente des Projektmanagements aus den Schulungen zu Advanced Consulting Skills, Bonn. KERBER-KUNOW, A. (2000): Projektmanagement und Coaching, Heidelberg. KEßLER, H./WINKELHOFER, G. (1999): Projektmanagement – Leitfaden zur Steuerung und Führung von Projekten, 2. A., Berlin u. a. KNOBLICH, H. (1972): Die typologische Methode in der Betriebswirtschaftslehre, in: Wirtschaftswissenschaftliches Studium (WiSt), 3. Jg. (1972), Nr. 4, S. 141-156. KÖHLER, P. T. (2006): Prince II, Berlin. KOTLER, P./BLIEMEL, F. (1995): Marketing-Management. Analyse, Planung, Umsetzung und Steuerung, 8. A., Stuttgart. KÜPPER, H. U. (1995): Controlling. Konzeption, Aufgaben, Instrumente, Stuttgart. LEHNER, J. M. (2001A): Projektorganisation, in: Lehner, J. M. (Hrsg.): Praxisorientiertes Projektmanagement. Grundlagenwissen an Fallbeispielen illustriert, Wiesbaden, S. 4758. LEHNER, J. M. (2001B): Kommunikation im Projekt, in: Lehner, J. M. (Hrsg.): Praxisorientiertes Projektmanagement. Grundlagenwissen an Fallbeispielen illustriert, Wiesbaden, S. 209-214.


257

LITKE, H.-D. (1995): Projektmanagement – Methoden, Techniken, Verhaltensweisen, 3. A., München/Wien. LITKE, H.-D. /KUNOW, I. (2002): Projektmanagement, 3. A., Freiburg im Breisgau. LOCK, D. (1997): Projektmanagement, Wien. LÜNENDONK, T. (2005): Die Top 25 Managementberatungsunternehmen in Deutschland, online veröffentlicht unter dem URL: www.luenendonk.de/management_beratung.php, Zugriff vom 19.05.2006. MADAUSS, B. J. (1984): Projektmanagement. Ein Handbuch für Industriebetriebe, Unternehmensberater und Behörden, Stuttgart. MAYLOR, H. (1999): Project Management, 2. A., Harlow. MAYRSHOFER, D./KRÖGER, H. A. (1999): Prozesskompetenz in der Projektarbeit, Hamburg. MCKINSEY (2000): Unterlagen zum Seminar „Erfolgreiches Projektmanagement“, o. O. MEFFERT, H. (2000): Marketing, 9. A., Wiesbaden. MEFFERT, H./BRUHN, M. (1997): Dienstleistungsmanagement, 2. A., Wiesbaden. MEIßNER, H. (1998): The Quality of Service Encounters via Electronic Mail, in: Quality Management in Services VIII, Proceedings of the EIASM Workshop in Ingolstadt, April 19-21, 1998, Appendix. MEREDITH, J. R./MANTEL, S. J. (1995): Project Management. A Managerial Approach, 3. A., New York et al. MESTER, V./ZAMPONI, R. (2004): Die Macht der Berater, in: Hamburger Abendblatt vom 15. Juni 2004. MEYER, A./DORNACH, F. (2000): Kundenmonitor Deutschland, München. MZSG [MANAGEMENTZENTRUM ST. GALLEN] (2001): Seminarunterlagen zum Seminar „Wirksame Mitarbeiterführung“, St. Gallen. NIEDEREICHHOLZ, C. (1996): Unternehmensberatung I, Beratungsmarketing und Auftragsakquisition, München. NOHR, H. (1999): Das Projekt OurKnowledge – Wissensmanagement in einem kleinen Beratungsunternehmen, in: HBI aktuell Nr. 2/1999, S. 16-19. NOHR, H. (2001): Wissen wird zum Fokus betrieblichen Managements – Eine Kurzübersicht zum Wissensmanagement, Arbeitspapiere Wissensmanagement, Nr. 4/2001, Fachhochschule Stuttgart. NÖCKER, R. (2005): Beratung, die von innen kommt, in: Frankfurter Allgemeine Zeitung vom 23.07.2005, S. 55. OLFERT, K. (2003): Personalwirtschaft, Ludwigshafen.

258


OLFERT, K./STEINBRUCH, P. A. (2003): Organisation, Ludwigshafen. O. V. (2004A):

McKinsey, in: Hamburger Abendblatt vom 15.06.2004.

O. V. (2004B):

Roland Berger, in: Hamburger Abendblatt vom 15.06.2004.

O. V.

(2004C): Unternehmensberater, online veröffentlicht unter dem http://www.net-lexikon.de/Unternehmensberater.html, Zugriff vom 11.05.2004.

URL:

O. V.

(2005): Geschichte des Informationsdesigns, online veröffentlicht unter dem URL: http://v.hdm-stuttgart.de/projekte/infodesign/g/geschichte_des_infodesigns.html, Zugriff vom 01.06.2005.

PALMER, A. (2000): Principles of Marketing, Oxford. PATZAK, G./RATTAY, G. (1998): Projekt Management, 3. A., Wien. PORTNY, S. E. (2001): Projektmanagement für Dummies, Bonn. RINZA, P. (1998): Projektmanagement, Berlin u. a. SCHADE, C. (1998): Marketing für Unternehmensberatungsleistungen, in: Meyer, A. (Hrsg.): Handbuch Dienstleistungs-Marketing, Stuttgart, S. 1833-1845. SCHLEGEL, J. (2005): Was ist Transaktionsanalyse?, online veröffentlicht unter dem URL: http://195.129.94.216/web/dsgta/ressourcen/ta-handbuch/was-ist-ta.pdf, Zugriff vom 26.02.2005. SCHLÜTER, A. (O. J.): Management- und Consulting-Verträge, in: Recht des internationalen Wirtschaftsverkehrs, Band 4, Loseblattsammlung. SCHMIDT, C. (1996): Personalmanagement-Konzept für Dienstleistungsunternehmen, München/Mering. SCHREYÖGG, G. (2003): Organisation, Wiesbaden. SILICON (2004): Marktübersicht Projektmanagement, Rubrik B3.19, online veröffentlicht unter dem URL: http://www.silicon.de/cpo/sguide/sget.php3?id=silicon&seite=prog_n/pn_0811.htm, Zugriff vom 27.10.2004. STAUSS, B./SEIDL, W. (1998): Beschwerdemanagement, 2. A., München/Wien. STOLORZ, C. (1997): Controlling in Beratungsunternehmen: Aufgaben, Probleme und Instrumente, in: Stolorz, C./Fohmann, L. (Hrsg.): Controlling in Consulting-Unternehmen – Instrumente, Konzepte, Perspektiven, Wiesbaden, S. 3-20. STUMPF, S./THOMAS, A. (2003): Teamarbeit und Teamentwicklung, Göttingen et. al. THE GOAL SETTING SITE (2004): SMART Goal Setting, online veröffentlicht unter dem URL: http://www.goal-setting-guide.com/smart-goals.html, Zugriff vom 21.02.2005. ULSAMER, B. (1997): Excellente Kommunikation mit NLP, 6. A., Offenbach.


259

WEBER, J. (1992): Die Koordinationssicht des Controlling; in: Spremann, K./Zur, E. (Hrsg.): Controlling. Grundlagen – Informationssystem – Anwendungen, Wiesbaden, S. 169183. WEGMANN, G. (1986): Der Leitungsprozess im Unternehmen, in: Preitz, O. (Hrsg.): Allgemeine Betriebswirtschaftslehre für Studium und Praxis, 5. A., Baden-Baden und Bad Homburg, S. 173-220. WILLKE, H. (2004): Einführung in das systematische Wissensmanagement, München. WISCHNEWSKI, E. (2001): Modernes Projektmanagement, 7. A., Braunschweig/Wiesbaden. WOLF, M. L. J./MLEKUSCH, R. (1997): Projektmanagement live. Prozesse in Projekten durch Teams gestalten, Renningen-Malmsheim. ZEITHAML, V./BITNER, M. J. (2002): Services Marketing. Integrating Customer Focus Across the Firm, 3. A., New York. ZIELASEK, G. (1995): Projektmanagement. Erfolgreich durch Aktivierung aller Unternehmensebenen, Berlin et al.

Die Autoren

27

Die Autoren

Prof. Dr. Christoph Wegmann studierte Wirtschaftswissenschaften in Hannover und Dublin. Er hat an der Katholischen Universität Ingolstadt/Eichstätt promoviert. Berufliche Stationen waren Tchibo, wo er als Produktmanager gearbeitet hat, und Deutsche Post World Net, wo er als Projektmanager im Inhouse Consulting tätig war. Zurzeit ist Christoph Wegmann Inhaber einer Professur für Betriebswirtschaftslehre mit dem Schwerpunkt Marketing an der Hochschule für Angewandte Wissenschaften in Hamburg. Er ist Prodekan der Fakultät Life Sciences. Zudem ist er einer der Geschäftsführer der TreSolutions GbR, die Trainings rund um Projektmanagement und Unternehmensberatung anbietet.

Holger Winklbauer studierte Elektrotechnik und Wirtschaftswissenschaften an der RWTH-Aachen und der University of Portland, Oregon. Nach dem Studium war er u. a. als Technischer Einkäufer bei Mannesmann Anlagenbau, Düsseldorf, als Projektleiter am Forschungsinstitut für Rationalisierung in Aachen sowie bei der Metro Gruppen Logistik, Düsseldorf tätig. Im Jahre 2000 begann er als Projektmanager bei dem kurz zuvor neu gegründeten Inhouse Consulting des Konzerns Deutsche Post World Net. Es folgte die Beförderung zum Partner und später zum Head of Inhouse Consulting. Heute ist Holger Winklbauer Geschäftsführer der Deutsche Post World Net Business Consulting GmbH in Bonn. Unter seiner Leitung wuchs die Einheit zu einer der größten und erfolgreichsten internen Top-Managementberatungen weltweit, mit Standorten in Deutschland, den USA und Singapur.

Projektmanagement fur Unternehmensberatungen: Mit Beispielen aus dem Inhouse Consulting von Deutsche Post World Net

Projektmanagement mit Excel

Projektmanagement mit Excel

Projektmanagement mit Excel

Projektmanagement mit Excel GERMAN

30 Minuten fur besseres Projektmanagement

Ammoniten aus dem Valanginien von Spitzbergen

Eventrecht kompakt: Ein Lehr- und Praxisbuch mit Beispielen aus dem Konzert- und Kulturbetrieb, Zweite Auflage

Aus dem Nachlass von R. Brauer

Von Dem Umgange Mit Und Unter Verliebten

Eventrecht kompakt: Ein Lehr- und Praxisbuch mit Beispielen aus dem Konzert- und Kulturbetrieb

C. Mit einfachen Beispielen programmieren

Controlling von Projekten Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle

Projektmanagement fur technische Projekte: Ein prozessorientierter Leitfaden fur die Praxis

Endlich im grunen Bereich! Projektmanagement fur jedermann

Social Development mit .NET

Deutsche Lieder aus der Schweiz

Sturz aus dem Frostrubin

Flucht aus dem Adlerhorst

Mensch aus dem Nichts

Todesschreie aus dem Blutmoor

Flucht aus dem Tarkihl

Aus dem Frauenleben

Sturz aus dem Frostrubin

Flucht aus dem Vergessen

Todesschreie aus dem Blutmoor

Stimmen aus dem Hyperraum

Anruf aus dem Jenseits

Bluthand aus dem Jenseits

Invasion aus dem Dunkeln

Flucht aus dem Adlerhorst

Projektmanagement fur Unternehmensberatungen: Mit Beispielen aus dem Inhouse Consulting von Deutsche Post World Net

Projektmanagement mit Excel

Projektmanagement mit Excel

Projektmanagement mit Excel

Projektmanagement mit Excel GERMAN

30 Minuten fur besseres Projektmanagement

Ammoniten aus dem Valanginien von Spitzbergen

Eventrecht kompakt: Ein Lehr- und Praxisbuch mit Beispielen aus dem Konzert- und Kulturbetrieb, Zweite Auflage

Aus dem Nachlass von R. Brauer

Von Dem Umgange Mit Und Unter Verliebten

Eventrecht kompakt: Ein Lehr- und Praxisbuch mit Beispielen aus dem Konzert- und Kulturbetrieb

C. Mit einfachen Beispielen programmieren

Controlling von Projekten Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle

Projektmanagement fur technische Projekte: Ein prozessorientierter Leitfaden fur die Praxis

Endlich im grunen Bereich! Projektmanagement fur jedermann

Social Development mit .NET

Deutsche Lieder aus der Schweiz

Sturz aus dem Frostrubin

Flucht aus dem Adlerhorst

Mensch aus dem Nichts

Todesschreie aus dem Blutmoor

Flucht aus dem Tarkihl

Aus dem Frauenleben

Sturz aus dem Frostrubin

Flucht aus dem Vergessen

Todesschreie aus dem Blutmoor

Stimmen aus dem Hyperraum

Anruf aus dem Jenseits

Bluthand aus dem Jenseits

Invasion aus dem Dunkeln

Flucht aus dem Adlerhorst

Recommend Documents