Projektmarketing als Ansatz für ein ganzheitlich stakeholderorientiertes IT-Projektmanagement

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Stakeholderorientierung zur Verbesserung der Erfolgsaussichten von IT-Projekten

2 Vorstellung des als Beispiel dienenden IT-Projekts

3 Kritische Reflexion des in der Literatur vorherrschenden Verständnisses von Projektmarketing

4 IT-Projekte im unternehmerischen Kontext
4.1 IT-Projekte als Rahmen von Softwareeinführungen
4.2 Ziele und Phasen des Projektmanagements
4.3 Projektphasen zur Einführung einer Standardsoftware
4.4 Projektrollenund-organisationsformen
4.5 Typische Einflussfaktoren eines IT-Projektumfelds
4.6 Kriterien zur Ermittlung des IT-Projekterfolgs
4.7 Zwischenresümee

5 Marketing im Sinne marktorientierter Unternehmensführung als theoretische Grundlage fürs Projektmarketing
5.1 Begriff und institutionelle Besonderheiten des Marketings
5.2 Dienstleistungscharakter des Projektmanagements
5.3 Besonderheiten des Dienstleistungsmarketings
5.4 Implementierung einermarktorientiertenUnternehmensführung
5.5 Phasen und Schritte des Marketingmanagementprozesses
5.6 Marketingmix im Dienstleistungsbereich
5.6.1 Klassische Instrumente des Marketingmix
5.6.2 Zusätzliche Komponenten des Marketingmix im Dienstleistungsbereich
5.6.3 Verwendbarkeit des Marketingmix für ein Projektmanagementkonzept
5.7 Eignung des Dienstleistungsmarketings als theoretische Grundlage fürs ganzheitlich stakeholderorientierte IT-Projektmanagement

6 Konzept eines ganzheitlich stakeholderorientierten IT-Projektmanagements
6.1 Definition von Projektmarketing als ganzheitlich stakeholderorientiertes Projektmanagement
6.2 Synthese von Projekt- und Marketingmanagement zu einem ganzheitlich stakeholderorientierten IT-Projektmanagement
6.3 Implementierung einer stakeholderorientierten Projektführung
6.4 Phasen und Schritte des stakeholderorientierten Projektmanagementprozesses
6.5 Komponenten des Projektmarketingmix
6.6 Einschätzung der Verbesserung der Stakeholderorientierung bei IT-Projekten durch das vorgestellte PM-Konzept

7 Beispielhafte Projektmarketingkonzeption für die MKK
7.1 Analyse der Ausgangssituation
7.2 FestlegungderProjektmarketingziele
7.3 Auswahl geeigneterProjektmarketingstrategien
7.4 Ausgestaltung des Projektmarketingmix
7.5 Implementierung des Projektmarketings
7.6 Zwischenresümee

8 Fazit

Literatur- und Quellenverzeichnis

Abbildungsverzeichnis

Abbildung 1: Aufbauorganisation des Projekts bei der MKK

Abbildung 2: Ziele des Projektmanagements

Abbildung 3: Phasen des Projektmanagements

Abbildung 4: Projektphasen zur Einführung einer Standardsoftware

Abbildung 5: Typische Rollen innerhalb einer Projektorganisationsstruktur

Abbildung 6: Typische Einflussfaktoren eines IT-Projektumfelds

Abbildung 7: Projekterfolgskriterien in Bezug zum PM- und Projektprozess

Abbildung 8: Projekterfolgsfaktoren als Determinanten der Projekterfolgskriterien

Abbildung 9: Akteure und Dimensionen des Dienstleistungsmarketings

Abbildung 10: Marktorientierung der unternehmensexternen und -internen Marketingperspektive

Abbildung 11: Ebenen und Bestandteile einer Unternehmenskultur

Abbildung 12: Führungssysteme eines Unternehmens

Abbildung 13: Managementprozess des Dienstleistungsmarketings

Abbildung 14: Klassisch systematisierte Instrumente des Marketingmix im Dienstleistungsbereich

Abbildung 15: Zusätzliche Komponenten des Marketingmix im Dienstleistungsbereich

Abbildung 16: Akteure und Dimensionen des Projektmarketings

Abbildung 17: Konzept eines ganzheitlich stakeholderorientierten IT- Projektmanagements

Abbildung 18: Phasen und Schritte des stakeholderorientierten Projektmanagementprozesses

Abbildung 19: Projektstakeholder bei der MKK

Abbildung 20: Vorschlag für ein Logo für das Projekt bei der MKK

Abbildung 21: Beispiele für Motivationsplakate

Abbildung 22: Vorschlag für eine veränderte Aufbauorganisation des Projekts bei der MKK

Tabellenverzeichnis

Tabelle 1: Autorenspezifische Definitionen des Projektmarketingbegriffs

Tabelle 2: Mögliche Projektorganisationsformen

Tabelle 3: Hauptausprägungen des Dienstleistungsmarketings

Tabelle 4: Implikationen fürs Dienstleistungsmarketing aus den konstitutiven Dienstleistungsmerkmalen

Tabelle 5: Gegenüberstellung der Phasen des Marketingmanagement- und PM-Prozesses

Tabelle 6: Instrumente der Leistungspolitik im Dienstleistungsbereich

Tabelle 7: Instrumente der Preispolitik im Dienstleistungsbereich

Tabelle 8: Instrumente der Kommunikationspolitik im Dienstleistungsbereich

Tabelle 9: Instrumente der Vertriebspolitik im Dienstleistungsbereich

Tabelle 10: Ziele und Inhalte der Leistungspolitik im Projektmarketingmix

Tabelle 11: Ziele und Inhalte der Kommunikationspolitik im Projektmarketingmix

Tabelle 12: Ziele und Inhalte der Vertriebspolitik im Projektmarketingmix

Tabelle 13: Ziele und Inhalte der Personalpolitik im Projektmarketingmix

Tabelle 14: Ziele und Inhalte der Ausstattungspolitik im Projektmarketingmix

Tabelle 15: Ziele und Inhalte der Prozesspolitik im Projektmarketingmix

Tabelle 16: Chancen, Risiken, Stärken und Schwächen in Bezug auf das Projekt der MKK

Tabelle 17: Ziele für das Projekt der MKK

Tabelle 18: Strategien für das Projekt der MKK

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Stakeholderorientierung zur Verbesserung der Erfolgsaussichten von IT-Projekten

Im Rahmen eines seit zwei Jahren andauernden Informationstechnikprojekts (IT-Pro- jekts), an dem der Verfasser als Teilprojektleiter beteiligt ist, ersetzt die „Moderne Krankenkasse“ (MKK; Name anonymisiert) das vorhandene, mittlerweile als veraltet geltende Enterprise-Resource-Planning-System (ERP-System) durch eine auf der SAP Business Suite basierende Branchenlösung. Dabei treten - wie es bei derart umfassen­den IT-Projekten häufig der Fall ist - verschiedene Konflikte mit Projektstakeholdem auf, die das Projekt beeinträchtigen. Einige Beispiele: Linienvorgesetzte stellen nicht genügend geeignete Projektmitarbeiter zur Verfügung mit dem Hinweis, das Tagesge­schäft habe Vorrang; einige der potenziellen Endbenutzer sehen keine Notwendigkeit für die Ablösung des Altsystems und äußern verdeckt Befürchtungen über die negativen Folgen des Umstiegs; der Hersteller der Branchenlösung möchte den geplanten Um­stellungstermin mit allen Mitteln halten, weil das Projekt für ihn Vorzeigecharakter hat, während die fachlich Verantwortlichen der BMO als oberstes Ziel die bestmögliche Qualität der Daten und Prozesse im neuen System verfolgen, was jedoch eine längere Projektlaufzeit erfordern würde. Um solche Konflikte und Widerstände zu minimieren und eine möglichst breite Akzeptanz für das neue ERP-System zu erreichen, müssten die Stakeholder, so die Hypothese, durch das Projektmanagement (PM) stärker als bis­her berücksichtigt werden.

In der Literatur sind Projektstakeholder Gegenstand verschiedener, sich teilweise über­schneidender Themenbereiche, bspw. des Stakeholder- und Informationsmanagements. Diese erweisen sich aber bei näherer Betrachtung als voneinander unabhängige Instru­mente, die zwar im Rahmen von IT-Projekten zur Berücksichtigung der Stakeholder optional eingesetzt werden können, jedoch nicht zu einer ganzheitlichen Stakeholder­orientierung des PM führen, da sie jeweils einen vom PM-Kernprozess losgelösten und damit begleitenden Prozess darstellen. Ein ganzheitlich stakeholderorientierter Ansatz wäre jedoch wünschenswert, denn wenn integrativ auf der Ebene des PM-Kernprozes- ses die Stakeholder bei anstehenden Entscheidungen stärker berücksichtigt würden, könnten die vielfältigen Konflikt- und Widerstandspotenziale womöglich frühzeitiger und umfassender erkannt und minimiert werden - was sich wiederum vermutlich positiv auf die Projekterfolgsaussichten auswirken würde.

Auf der Suche nach einem möglichst ganzheitlichen Ansatz zur Stakeholderorientierung von Projekten bietet sich die betriebswirtschaftliche Disziplin des Marketing an. Denn nach dem modernen, erweiterten Verständnis ist Marketing ein Konzept zur ganzheitlich marktorientierten Unternehmensführung, das - und hier besteht die Verknüpfung - auch all jene Aufgaben einschließt, „die notwendig sind, um die Legitimität aller relevanten Anspruchsgruppen zu erlangen bzw. zu erhalten“ (Meffert et al. 2012, S. 18). Legt man dies dem PM zugrunde, so könnte Projektmarketing ein Konzept für ein ganzheitlich stakeholderorientiertes PM bedeuten, bei dem sämtliche Projektfunktionen stakehol­derorientiert ausgerichtet werden. In der etablierten PM-Literatur ist ein solcher Ansatz bislang nicht betrachtet worden. Insofern erscheint es angebracht ein Projektmarke­tingmodell zu entwickeln, das auf dem modernen Marketingverständnis basiert, sowie anschließend zu untersuchen, ob es die Konflikte und Widerstände bei der MKK mini­mieren und eine größere Akzeptanz des neuen ERP-Systems erreichen könnte. Die der vorliegenden Arbeit zugrunde liegende Frage lautet somit: Inwiefern kann Projektmar­keting im Sinne einer ganzheitlich marktorientierten Unternehmensfuhrung die Stake­holderorientierung und dadurch die Erfolgsaussichten von IT-Projekten im Vergleich zum klassischen IT-PM verbessern und wie könnte eine beispielhafte Projektmarke­tingkonzeption für die Ablösung des ERP-Systems bei der MKK aussehen?

Zur Beantwortung dieser Frage ist es zunächst erforderlich, sich mit der in der Literatur bislang vorherrschenden Auffassung von Projektmarketing auseinanderzusetzen, um den Projektmarketingbegriff im weiteren Verlauf abgrenzen zu können. Darüber hinaus müsste geklärt werden, was unter einem IT-Projekt und unter IT-PM genau zu verstehen ist: Welche Phasen durchlaufen IT-Projekte und der PM-Prozess? Wie kann die IT-Pro- jektorganisation aufgebaut werden? Welchen Einflussfaktoren sind IT-Projekte typi­scherweise ausgesetzt und von welchen Kriterien hängt der Projekterfolg ab? Anschlie­ßend müssen die theoretischen Grundlagen des Marketings aufgezeigt werden: Was genau ist unter Marketing im Sinne marktorientierter Unternehmensfuhrung zu verste­hen? Wie lässt sich eine solche Marktorientierung im Unternehmen implementieren und wie erfolgt die operative Umsetzung? Auf der Basis der theoretischen Grundlagen des PM einerseits und des Marketings andererseits kann sodann zunächst ein ganzheitlich stakeholderorientiertes PM-Konzept entwickelt werden, auf dessen Basis schließlich eine konkrete Projektmarketingkonzeption für den Austausch des ERP-Systems bei der MKK erstellt werden kann.

Dementsprechend wird wie folgt vorgegangen: In Kapitel 2 wird zunächst das IT-Pro- jekt der MKK vorgestellt, für das eine passende Projektmarketingkonzeption entwickelt werden soll. Danach erfolgt in Kapitel 3 eine kritische Reflexion der in der Literatur vorherrschenden Auffassung von Projektmarketing.

Anschließend werden in Kapitel 4 IT-Projekte näher betrachtet. Es wird geklärt, was unter IT-Projekten und PM zu verstehen ist, was die Ziele und Phasen des PM sind, welche Projektphasen bei einer Softwareeinführung durchlaufen werden, wie Projekt­organisationen aufgebaut sein können, welchen typischen Einflussfaktoren IT-Projekte ausgesetzt sind und anhand welcher Kriterien ein Projekterfolg ermittelt werden kann.

Sodann werden in Kapitel 5 die theoretischen Grundlagen des Marketings im Sinne marktorientierter Unternehmensführung erörtert. Es erfolgt zunächst eine Definition des Marketingbegriffs und eine Differenzierung der institutionellen Besonderheiten des Marketings. In diesem Zusammenhang wird auch der Dienstleistungscharakter des PM herausgearbeitet. Danach wird den Fragen nachgegangen, was die Besonderheiten des Dienstleistungsmarketings sind, wie eine marktorientierte Unternehmensführung im­plementiert werden kann, welche Phasen und Schritte im Marketingmanagementprozess durchlaufen werden und mit welchen Instrumenten eine operative Umsetzung des Dienstleistungsmarketings erfolgen kann. Schließlich wird geprüft, inwiefern sich das Dienstleistungsmarketing als Grundlage fürs IT-Projektmarketing eignen könnte.

In Kapitel 6 wird zunächst Projektmarketing als ganzheitlich stakeholderorientiertes PM definiert. Danach werden Marketing und klassisches PM zu einem stakeholderorientier­ten PM-Konzept zusammengeführt Sodann werden die Implementierung des Projekt­marketings, die Phasen und Schritte des stakeholderorientierten PM-Prozesses sowie die Komponenten des Projektmarketingmix erläutert. Anschließend wird geprüft, inwiefern IT-Projektmarketing die möglichen Konflikte und Widerstände reduzieren, die Akzep­tanz für das neue ERP-System erhöhen und die Projekterfolgsaussichten steigern kann.

In Kapitel 7 wird schließlich eine konkrete Projektmarketingkonzeption für die MKK erstellt. Zunächst werden die Ausgangssituation analysiert und die Projektmarketing­ziele festgelegt. Danach werden die Projektmarketingstrategien ausgewählt und über­legt, wie der Projektmarketingmix ausgestaltet werden könnte. Zuletzt wird die Imple­mentierung des IT-Projektmarketings erörtert.

Den Abschluss der Untersuchung bildet Kapitel 8 mit einem Fazit.

2 Vorstellung des als Beispiel dienenden IT-Projekts

Seit über 20 Jahren verwendet die MKK, eine gesetzliche Krankenkasse mit ca. 1.400 Mitarbeitern an drei Standorten in Hamburg, Niedersachsen und Hessen, zur Verwal­tung der Kunden und zur Steuerung der branchentypischen Prozesse dasselbe ERP- System. Ein ERP-System ist eine aus mehreren Komponenten bestehende Anwen­dungssoftware, die auf einer gemeinsamen Datenbasis basiert und alle wesentlichen Unternehmensprozesse funktionsübergreifend unterstützt (vgl. Hansen und Neumann 2009, S. 661). Das von der MKK eingesetzte ERP-System wurde im Laufe der Zeit zwar inhaltlich weiterentwickelt und an die veränderte Gesetzgebung angepasst; die technische Grundlage ist jedoch größtenteils unverändert geblieben, weshalb das Sys­tem inzwischen als nicht mehr zeitgemäß gilt. Der Hersteller hat zudem die Einstellung der Weiterentwicklung angekündigt. Seit über zwei Jahren läuft daher im Unternehmen ein IT-Projekt, in dessen Rahmen das vorhandene ERP-System gegen eine moderne, auf der SAP Business Suite basierende Branchenlösung auswechselt werden soll.

Von dem IT-Projekt sind zum einen alle Sachbearbeiter der MKK betroffen, die bereits das alte ERP-System für den größten Teil ihrer täglichen Arbeit nutzen. Die jeweiligen krankenkassenspezifischen Prozesse werden dabei seit Jahrzehnten durch das alte ERP- System vorgegeben, da es sich nicht flexibel an unternehmensspezifische Gegebenhei­ten anpassen lässt. Zum anderen sind auch alle übrigen Mitarbeiter der MKK betroffen, denn zukünftig sollen im Gegensatz zu heute auch viele interne Verwaltungsprozesse über das neue ERP-System abgebildet werden. Darüber hinaus wird sich der Wechsel des ERP-Systems auch auf die Organisationsstruktur auswirken. Ein Beispiel: Auszah­lungen von Versicherungsleistungen erfolgen bisher über einen komplexen Prozess, an dem abteilungsübergreifend mehrere Sachbearbeiter beteiligt sind, wobei die Haupt­arbeit in der Finanzabteilung getätigt wird. Das neue ERP-System wird diesen Prozess größtenteils automatisieren, sodass durch den Wegfall manueller Prozessschritte weni­ger Mitarbeiter in der Finanzabteilung benötigt werden. Der Wechsel des ERP-Systems wirkt sich damit sowohl auf die Prozesse als auch auf die Strukturen der MKK aus, weshalb der Wechsel des ERP-Systems eine tiefgreifende Veränderung für alle Mit­arbeiter darstellt. Des Weiteren sind von dem Projekt auch die Vertragspartner betroffen, die das ERP-System der MKK über eine Anbindung nutzen, sowie schließlich auch die Kunden, da das alte Online-Portal der Krankenkasse durch eine Komponente des neuen ERP-Systems ausgetauscht wird. Insgesamt wird sich das Projekt also nicht nur auf die Mitarbeiter, sondern auch auf die Kunden und Vertragspartner der MKK auswirken.

Die Projektorganisation ist wie folgt aufgebaut:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aufbauorganisation des Projekts bei der MKK (eigene Darstellung)

Wie aus Abbildung 1 ersichtlich, setzt sich die Projektleitung (PL) aus drei gleichbe­rechtigten Projektleitern zusammen: Der erste Projektleiter ist ein langjähriger festan­gestellter Mitarbeiter der MKK, der zweite ist für die Dauer des Projekts befristet ange­stellt und hat Erfahrung mit SAP-Einführungsprojekten, der dritte stammt von dem Systemhaus, welches die Branchenlösung herstellt und vor Ort installiert. Der Projekt­leiter vom Systemhaus ist Vollzeit für das Projekt der MKK tätig. Das Projekt ist der IT- Abteilung zugeordnet, weshalb der Projektlenkungsausschuss (PLA) aus dem Leiter der IT-Abteilung, dem Vorstandsvorsitzenden der MKK und dem Geschäftsführer des Sys­temhauses besteht. Für die im Projekt anfallenden Aufgaben wurden neun Fachteilpro­jekte und acht Querschnittsteilprojekte gebildet, sodass das Projekt aus insgesamt 17 Teilprojekten (TP) besteht. Den Fachteilprojekten obliegt jeweils eine fachliche Ver­antwortung (bspw. die Personal-, Finanz- oder Kundenverwaltung), die Querschnitts­teilprojekte sind für übergreifende Tätigkeiten verantwortlich (bspw. Migration, Test oder Training). Die Teilprojektleitungen (TPL) bestehen jeweils aus einem Mitarbeiter der MKK und einem Mitarbeiter des Systemhauses. Die Projektmitarbeiter sind wei­terhin nur ihren Linienvorgesetzten unterstellt, unabhängig davon, ob sie Teil- oder

Vollzeit am Projekt mitarbeiten. Die PL und TPL haben dementsprechend für die Pro­jektmitarbeiter der MKK keine formellen Weisungsbefugnisse. Überdies sind die Pro­jektmitarbeiter organisatorisch ausschließlich den Fachteilprojekten zugeordnet, die Querschnittsteilprojekte haben kein eigenes Projektpersonal. Das führt dazu, dass ein Projektmitarbeiter, der sich bspw. um die Migration der Finanzdaten kümmert, zwar weiterhin formal der Finanzabteilungsleitung untersteht und ggf. Aufgaben der Linie erfüllen muss, organisatorisch aber auch vom TP Finanzen gesteuert wird und vom TP Migration Aufgabenpakete erhält. Dementsprechend führt das Projekt bei der MKK neben den oben beschriebenen Konflikten und der hohen Arbeitsbelastung durch die gleichzeitige Bewältigung von Tages- und Projektgeschäft zusätzlich zu Situationen, in denen für die Mitarbeiter unklar ist, ob die Linien- oder Projektaufgaben Vorrang haben.

Die offizielle Kommunikation des Projekts in Richtung der Mitarbeiter der MKK er­folgt einerseits über sporadische E-Mail-Newsletter und andererseits über die Intranet­seiten des Unternehmens. Für die Intranetseiten zum Projekt sindjedoch die jeweiligen TP verantwortlich - entsprechend unterschiedlich sind Informationsqualität, -quantität und -aktualität. Der hauptsächliche Informationsfluss verläuft somit über informelle Wege von den Projektmitgliedern - worunter alle am Projekt beteiligten Personen zu verstehen sind (also auch die PL; vgl. Angermeier 2012c) - zu den restlichen Mitarbei­tern der MKK. Dies ist deshalb problematisch, weil die informellen Kommunikations­wege bei vielen Mitarbeitern der MKK nach den Erfahrungen des am Projekt beteiligten Verfassers inzwischen zu einem diffusen, teils sogar komplett falschen Bild über die Inhalte, Ziele und Auswirkungen des Projekts geführt haben.

Im nächsten Kapitel erfolgt eine kritische Auseinandersetzung mit dem in der Literatur vorherrschenden Verständnis von Projektmarketing.

3 Kritische Reflexion des in der Literatur vorherrschenden Verständnisses von Projektmarketing

Zur Untersuchung des bisher vorherrschenden Verständnisses von Projektmarketing wurde die für den Verfasser verfügbare PM-Literatur gesichtet. Dabei wurde mangels ausreichender Forschungsliteratur auch Ratgeberliteratur herangezogen. Die aus Sicht des Verfassers brauchbaren Projektmarketingdefinitionen sind nachfolgend zusammen­gefasst und anhand des jeweiligen Begriffsverständnisses kategorisiert:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Autorenspezifische Definitionen des Projektmarketingbegriffs

(eigene Darstellung, alphabetisch sortiert nach Autor; die Buchstaben geben die Zuordnung zum Verständnis des Projektmarketings wieder)

Wie aus Tabelle 1 ersichtlich, können bei den autorenspezifischen Projektmarketingde­finitionen vier Hauptziele identifiziert werden:

W: Werbende Darstellung des Projekts: Projektmarketing soll das Projekt im Pro­jektumfeld werbend darstellen. Damit ist ein einseitiger Prozess gemeint, der ausschließlich vom Projekt in Richtung Projektumfeld erfolgt.

B: Beeinflussung des Projektumfelds: Projektmarketing soll das Projektumfeld im Sinne des Projekts manipulieren. Das kann bspw. die Schaffung von Akzeptanz für das Projekt oder die Sicherstellung von Ressourcen bedeuten.

К: Kommunikation mit dem Projektumfeld'. Projektmarketing wird als Management der wechselseitigen kommunikativen Beziehungen zu den Projektstakeholdem angesehen.

P: Partizipation des Projektumfelds: Im Rahmen des Projektmarketings sollen die relevanten Projektstakeholder aktiv am Projekt beteiligt werden.

Je nach Autor wird Projektmarketing also als werbend, beeinflussend, kommunikativ oder partizipativ verstanden, wobei überwiegend eine Kombination dieser Ausprägun­gen vorzufinden ist. Die umfassendste Definition liefern Stempkowski et al. Ihr Fokus liegtjedoch auf Infrastrukturprojekten, weshalb sie vor allem die Einbeziehung der Öf­fentlichkeit eingehend erörtern. Dies ist jedoch bei internen Projekten (wie dem bei der MKK) unnötig, weshalb sich ihr Ansatz für die vorliegende Untersuchung nicht eignet. Insgesamt kann festgestellt werden, dass Projektmarketing durchgehend als zusätzliches und begleitendes Instrument angesehen wird, das im Rahmen des PM eingesetzt werden kann, aber nicht muss. Keiner der genannten Autoren wendet das moderne Marketing­verständnis im Sinne einer marktorientierten Unternehmensführung auf das PM selbst an, womit zwischen dem in der Literatur vorherrschenden Verständnis von Projektmar­keting und dem der vorliegenden Untersuchung zu unterscheiden ist.

Im Zusammenhang mit dem vorherrschenden Projektmarketingverständnis hat Möller bereits 2003 (S. 125-133) einige Feststellungen getroffen, die auch für diese Untersu­chung interessant sind:

1. Viele Definitionen des Projektmarketingbegriffs stammen aus der Projektpraxis. Sie sind deshalb häufig ungenau und vernachlässigen eine deutliche Angrenzung. - Dem ist heute weiterhin zuzustimmen, wie die Übersicht über die bisherigen Begriffsdefi­nitionen zeigt.

2. Meist wird einfach das Unternehmensmarketing ohne Eignungsprüfung und Anpas­sungen aufs Projektmarketing übertragen. - Auch diese Feststellung ist heute noch zutreffend. So postuliert Gareis (2004, S. 181) bspw., das Projektmarketing entsprä­che dem Investitionsmarketing, weil ein Projekt eine Investition darstelle. Er setzt sichjedoch nicht weiter mit der Frage auseinander, was genau unter Investitionsmar­keting zu verstehen ist und warum dies dem Projektmarketing entsprechen soll. Häu­fig anzutreffen ist weiterhin auch die ungeprüfte Verwendung des Konsumgütermar­ketings fürs Projektmarketing (vgl. bspw. Melbinger 2010a, S. 545).

3. Die Maßnahmen, die dem Themenbereich des Projektmarketings immer wieder zu­geordnet werden, sind nicht neu. Sie wurden bisher anderen Themengebieten des PM zugeordnet, wie dem Stakeholder- und Informationsmanagement. - Auch dem ist zu­zustimmen, denn das Ziel des Informationsmanagements besteht bspw. ebenfalls dar­in, den Informationsbedarf der Stakeholder zu decken (vgl. Bea et al. 2011, S. 244).

4. Es fehlen empirische Untersuchungen über die Verbreitung der Anwendung sowie die Inhalte und Vorgehensweisen des Projektmarketings. - Diese Feststellung hat heute ebenfalls noch Gültigkeit, da der Verfasser auch nach intensiver Recherche keine öf­fentlich zugänglichen Studien zu diesem Thema ermitteln konnte.

Die kritische Einschätzung des vorherrschenden Projektmarketingverständnisses von Möller (2003) ist somit nach wie vor aktuell. Er setzt sich im weiteren Verlauf seines Aufsatzes mit dem modernen Marketingverständnis (im Sinne einer marktorientierten Unternehmensführung nach Meffert) als Grundlage des Projektmarketings auseinander und stellt abschließend fest:

„Eine vollkommene Marktausrichtung [des Projektmarketings] ist also noch nicht zu erkennen. Der Sinn einer vollkommenen Marktausrichtung des Projektmanagements ist auch noch fraglich, dies istjedoch nach Auffassung des Autors eine äußerst wahrscheinliche Entwicklungsperspektive des Pro­jektmanagements und Projektmarketings.“ (S. 133)

Bereits 2003 hat Möller demnach Überlegungen angestellt, das Marketing im Sinne einer marktorientierten Unternehmensführung als Grundlage fürs Projektmarketing zu verwenden. Er kommt jedoch zu dem Schluss, dass das Projektmarketing einen markt­orientierten Ansatz noch nicht für sich beanspruchen kann. Zudem sei der Sinn eines solchen Ansatzes fraglich. Dessen ungeachtet sieht er eine Entwicklung des Projekt­marketings hin zu einem marktorientierten Ansatz als wahrscheinlich an. Es verwundert daher, dass seine Kritikpunkte und der Ansatz, das Konzept der marktorientierten Unternehmensführung als Grundlage für das PM zu verwenden, sowie seine Zweifel an einem solchen Ansatz bisher in der Literatur nicht aufgegriffen wurden. Dies wird nun mit der vorliegenden Arbeit unternommen, da ein stakeholderorientiertes PM-Konzept entwickelt werden soll, das auf einem modernen Marketingverständnis beruht. Zu die­sem Zweck erfolgt im nächsten Kapitel zunächst eine nähere Betrachtung von IT-Pro- jekten im unternehmerischen Kontext.

4 IT-Projekte im unternehmerischen Kontext

Der Begriff „IT-Projekt“ wird in der Praxis vielfach verwendet, oft jedoch ohne genau zu wissen, was genau unter einem IT-Projekt zu verstehen ist. Deshalb bedarf es als Erstes einer Definition des IT-Projektbegriffs. Anschließend wird das IT-PM themati­siert, indem die Ziele und Phasen des PM, die Projektphasen einer Softwareeinführung sowie die möglichen Projektrollen und -organisationsformen erörtert werden. Sodann werden die typischen Einflussfaktoren des IT-Projektumfelds untersucht und überlegt, anhand welcher Kriterien sich der Erfolg eines IT-Projekts bemisst.

4.1 IT-Projekte als Rahmen von Softwareeinführungen

Zur Präzisierung des Projektbegriffs wird in der Literatur häufig die Definition der DIN 69901-5 zitiert (vgl. bspw. Litke 2007, S. 19; Ruf und Fittkau 2008, S. 7 oder Pfetzing und Rohde 2011, S. 19), nach der ein Projekt ein Vorhaben darstellt, „das im Wesentli­chen durch [die] Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist“. Als Beispielbedingungen werden eine Zielvorgabe, eine zeitliche, finanzielle, personelle oder andere Begrenzung sowie eine projektspezifische Organisation angeführt. Bea et al. (2011, S. 33) kritisieren jedoch die Projektdefinition der DIN, da sie wesentliche Fragen offen lasse. So wird ihrer Ansicht nach bspw. nicht geklärt, was genau unter einer „projektspezifischen Organisation“ zu verstehen ist. Dieser Kritik ist beizupflich­ten, denn die Definition der DIN präzisiert die angeführten Bedingungen tatsächlich nicht weiter.

Bea et al. formulieren eine eigene Definition des Projektbegriffs, nach der ein Projekt ein Vorhaben darstelle, „das zeitlich befristet ist, sich durch Neuartigkeit und Einma­ligkeit auszeichnet sowie eine beachtliche Größe und einen hohen Grad an Komplexität aufweist“. Damit ist allerdings auch ihre Projektdefinition unpräzise, denn die Bedin­gungen „beachtliche Größe“ ist einerseits relativ - sie kann beliebig ausgelegt werden - und anderseits nicht für jedes Projekt zutreffend. So können auch kleinere Vorhaben aufgrund ihrer Neuartigkeit, Einmaligkeit und Komplexität Projekte darstellen. Ein Beispiel: Bei einem Pharmaunternehmen wurde unter Mitarbeit des Verfassers ein Pro­jekt durchgeführt, das die Transparenz der Durchlaufzeiten fürjeden einzelnen Produk­tionsschritt mithilfe eines neu zu erstellenden Monitoringsystems zum Ziel hatte (vgl. Möller und Pinnecke 2010). Das Grundproblem war, dass nur der Wechsel von einem zum nächsten Produktionsschritt im ERP-System erfasst wurde, die Zeitpunkte des Wechsels jedoch nicht gespeichert wurden. Das Projekt hatte deshalb aus technischer Sicht einen hohen Grad an Komplexität. Es war zudem auf wenige Wochen befristet und aus Sicht des Pharmaunternehmens neuartig und einmalig, da die Zeiten der ein­zelnen Produktionsschritte bisher nicht erfasst wurden und nach Schaffung der techni­schen Voraussetzungen ein solches Projekt auch nicht wieder durchgeführt werden braucht. Jedoch waren an dem gesamten Projekt hauptsächlich nur zwei Personen in Teilzeit beteiligt - es hatte somit keine beachtliche Größe, stellte aber trotzdem ein Pro­jekt dar. Die Bedingungen zeitliche Befristung, Neuartigkeit, Einmaligkeit und Kom­plexität erscheinen somit zur Definition des Projektbegriffs geeignet - nichtjedoch die Größe des Vorhabens.

Zweckmäßiger erscheint die Definition von Madauss (2000, S. 516):

„Projekte sind Vorhaben mit definiertem Anfang und Abschluß, die durch die Merkmale zeitliche Befristung, Einmaligkeit, Komplexität und Neu­artigkeit gekennzeichnet sind und wegen ihres interdisziplinären Quer­schnittcharakters eine vorübergehende organisatorische Veränderung und damit verbunden auch eine Neufestlegung der Aufgabenbereiche im Betrieb bewirken können; kurz: ein Projekt ist ein außergewöhnliches Vorhaben.“

Diese Definition enthält ebenfalls die Bedingungen zeitliche Befristung, Einmaligkeit, Komplexität und Neuartigkeit, aber eben nicht die Größe des Vorhabens. Zusätzlich führt Madauss zwei weitere optionale Bedingungen an: eine mögliche vorübergehende organisatorische Veränderung und eine mögliche Neufestlegung der Aufgabenbereiche aufgrund des interdisziplinären Querschnittcharakters von Projekten. Beide Bedingun­gen treffen auf das Beispielprojekt bei dem Pharmaunternehmen zwar nicht zu, da sie aber optional sind, würde die Definition dennoch zu dem Projekt bei dem Pharma­unternehmen passen. Betrachtet man exemplarisch das ERP-Projekt bei der MKK, so wird schnell deutlich, warum Madauss diese Bedingungen anführt: Hier muss abtei- lungsübergreifend gearbeitet werden, um das neue ERP-System einzuführen. Damit einher gehen sowohl während der Projektlaufzeit als auch nach Projektabschluss Ver­änderungen an der Aufbau- und Ablauforganisation. Somit sind alle Bedingungen von Madauss zur Definition von Projekten geeignet.

Nachdem nun der Projektbegriff geklärt wurde, gilt es nun, sich dem Begriff „IT“ zu­zuwenden. Nach der Definition von Krcmar (2010, S. 30) bezeichnet IT „die Gesamt­heit der zur Speicherung, Verarbeitung und Kommunikation zur Verfügung stehenden Ressourcen sowie die Art und Weise, wie diese Ressourcen organisiert sind“. Demzu­folge steht IT für alle Informations- und Kommunikationssysteme eines Unternehmens, was jeweils deren Hard- und Software sowie deren Vernetzung umfasst. Diese Defini­tion ist für die vorliegende Untersuchung ausreichend, denn sowohl das neue ERP-Sys­tem der MKK als auch das zuvor beispielhaft angeführte Monitoringsystem des Phar­maunternehmens können unter dem IT-Begriff subsumiert werden.

Unter einem IT-Projekt ist nach Ruf und Fittkau (2008, S. 8) ein Projekt mit folgenden Merkmalen zu verstehen:

1. Die Kernaufgabe ist die Einführung, Anpassung oder Neuentwicklung von IT,

2. die Projektmitarbeiter sind überwiegend IT-Spezialisten, und

3. das Projektergebnis ist IT, mit der Geschäftsprozesse unterstützt werden.

Das erste Merkmal ist nachvollziehbar, denn bereits die Bezeichnung „IT-Projekt“ deu­tet an, dass die Kernaufgabe des Projekts mit IT zu tun hat. Dabei kann es sich sowohl um eine Softwareentwicklung als auch um die Einführung einer neuen Software wie bei der MKK handeln. Brugger (2009, S. 8 f.) merkt dazujedoch an, dass IT-Projekte sich nur selten ausschließlich mit IT beschäftigen. Er führt dazu als Beispiel ein Projekt an, bei dem ein Customer-Relationship-Management-System (CRM-System) eingeführt werden soll. Ein solches IT-Projekt würde seiner Ansicht nach eher von einer Fach- als von der IT-Abteilung angestoßen werden, da das Kundenbeziehungsmanagement Auf­gabe einer Fach- und nicht IT-Abteilung ist. Zudem gingen die Projektaufgaben weit über IT-betreffende Projektaufgaben hinaus: Es müssten u. a. Geschäftsprozesse neu gestaltet und Mitarbeiter geschult werden. Womöglich gehe die Einführung des CRM- Systems sogar mit einer Umstellung der Vertriebsphilosophie einher. Die in IT-Pro- jekten zu tätigen Aufgaben würden deshalb meist nur zu einem kleinen Teil die IT im engeren Sinne betreffen. Brugger ist insofern beizupflichten, als IT heutzutage vor allem dazu eingesetzt wird, bestehende Geschäftsprozesse mithilfe der IT zu optimieren oder neue Geschäftsmodelle auf Basis von IT zu entwickeln oder auszunutzen - IT ist dabei jeweils nur ein Werkzeug. Natürlich werden auch IT-Projekte durchgeführt, die sich ausschließlich mit IT beschäftigen - man denke hier bspw. an Projekte zum Austausch von Netzwerk- oder Serverkomponenten -, jedoch dürften diese nach Erfahrung des Verfassers im Unternehmensalltag nur einen kleinen Teil der durchgeführten IT-Projekte darstellen. Infolgedessen kann dem zweiten Merkmal eines IT-Projekts von Ruf und Fittkau nicht zugestimmt werden: Wenn ein Großteil der Projektarbeit nicht die IT be­trifft, müssen die Projektmitarbeiter auch nicht überwiegend IT-Spezialisten sein.

Das dritte Merkmal eines IT-Projekts nach Ruf und Fittkau (Ergebnis ist IT, mit der Geschäftsprozesse unterstützt werden) bedarf einer Präzisierung, denn es wird damit zunächst nur zum Ausdruck gebracht, dass IT-Projekte keine IT als Konsumgut, sondern IT zur Unterstützung von Geschäftsprozessen betreffen. Nach diesem Verständnis könnte ein IT-Projekt also auch unternehmensextern durchgeführt werden, was ein unternehmensübergreifendes Verhältnis von Projektauftraggeber und -nehmer bedeuten würde. Ein typisches externes IT-Projekt wäre bspw. die Entwicklung einer Software durch einen Dienstleister. Bei dem Projekt der MKK, für das eine Projektmarketing­konzeption entwickelt werden soll, handelt es jedoch um ein internes IT-Projekt, denn der Projektauftrag erfolgte durch den Vorstand der MKK an ein internes Projektteam. In diesem sind zwar auch Mitarbeiter des Systemhauses vertreten, sie sind aber Mitglied des jeweils intern aufgestellten TP und unterstehen gleichermaßen den Teilprojektleitern der MKK und des Systemhauses. Der Aspekt des unternehmensübergreifenden Ver­hältnisses von Projektauftraggeber und -nehmer ist für die vorliegende Untersuchung somit nicht relevant, weshalb das dritte Merkmal auf unternehmensinterne IT-Projekte einzuschränken ist. Als IT-Projekt im hier gemeinten Sinne ist dementsprechend ein zeitlich befristetes, einmaliges, komplexes und neuartiges internes Vorhaben zu verste­hen, dessen Kernaufgabe die Einführung, Anpassung oder Neuentwicklung von ge­schäftsprozessunterstützender IT ist, wobei die Kernaufgabe nicht den Hauptteil der Projektarbeit repräsentieren muss.

Um das breite Aufgabenspektrum von IT-Projekten zum Zwecke der vorliegenden Untersuchung weiter einzugrenzen, können IT-Projekte nach Gadatsch (2008, S. 19 f.) zuletzt noch abhängig von der Aufgabenstellung u. a. in Entwicklungs-, Einführungs­oder Instandhaltungsprojekte unterteilt werden. Bei der MKK soll eine neue Standard­software - das neue auf SAP basierende ERP-System - eingeführt werden, womit es sich bei dem IT-Projekt der MKK um ein typisches Softwareeinführungsprojekt handelt.

Nachdem der IT-Projektbegriff im Zusammenhang mit dem hier bestehenden Untersu­chungsinteresse erörtert wurde, erfolgt im nächsten Kapitel eine genauere Auseinander­setzung mit dem PM-Begriff sowie den Zielen und Phasen des PM.

4.2 Ziele und Phasen des Projektmanagements

Mit dem Begriff „Projektmanagement“ (PM) wird Stahlknecht und Hasenkamp (2005, S. 215) zufolge „die Gesamtheit aller Tätigkeiten bezeichnet, mit denen Projekte geplant, überwacht und gesteuert werden“. Demnach ist unter PM der PM-Prozess zu verstehen, der aus den typischen Managementaufgaben Planung, Steuerung und Kont­rolle sämtlicher Projektaktivitäten während des gesamten Projektlebenszyklus besteht. Der Fokus von Stahlknecht und Hasenkamp liegt zwar auf IT-Projekte - ihre PM-Defi- nition istjedoch nicht IT-projektspezifisch. Auch in der PM-Literatur wird überwiegend nur das PM von Softwareentwicklungsprojekten separat behandelt, nichtjedoch das PM von allgemeinen IT-Projekten. Implizit wird damit zum Ausdruck gebracht, dass sich das PM von IT-Projekten - und damit auch das von Softwareeinführungsprojekten - nicht wesentlich von anderen Projekten unterscheidet. Dieser Auffassung ist zu folgen, wenn man sich den im vorangegangenen Kapitel genannten Aspekt von IT-Projekten vor Augen führt, nach dem IT-Projekte nur zu einem kleinen Teil aus IT-spezifischen Aktivitäten bestehen. Der Hauptteil der IT-Projektaktivitäten unterscheidet sich folglich nicht von anderen Projekten, weshalb es keiner separaten Definition des PM von IT- Projekten bedarf und die PM-Definition von Stahlknecht und Hasenkamp für die vor­liegende Untersuchung verwendet werden kann.

Als Ziele des PM werden in der Literatur übereinstimmend die klassischen Größen Kosten, Zeit und Leistung genannt. Unter den Kosten sind die durch das Projekt einge­setzten Aufwendungen (Finanzmittel, Arbeitskraft usw.) zu verstehen, unter der Zeit die Dauer von Projektstart bis -ende und unter der Leistung die Aufgabe, die das Projekt gemäß Auftrag zu erbringen hat (vgl. Angermeier 2012a). Beim Projekt der MKK be­steht die Leistung des Projekts aus der Ablösung des alten ERP-Systems. In Verbindung mit den Prozessen eines Projekts ergibt sich damit folgende Darstellung:

Prozesse

Wie im rechten Bereich der Abbildung 2 ersichtlich, sind die drei Größen Kosten, Zeit und Leistung miteinander verbunden (dies und das Folgende nach Bea et al. 2011, S. 40 f.). Damit soll zum Ausdruck gebracht werden, dass keine der Größen verändert werden kann, ohne die anderen Größen zu beeinflussen. Soll bspw. das Projekt in einer kürzeren Zeit bewältigt werden, so sind dafür entweder höhere Aufwände zu erbringen oder eine reduzierte Leistung zu akzeptieren. Die Leistung setzt sich dabei aus dem quantitativen und dem qualitativen Aspekt zusammen, denn aus Sicht des Auftraggebers muss das Projekt die beauftragte Leistung sowohl im geforderten Umfang als auch in der gefor­derten Qualität erfüllen. In der Literatur wird vereinzelt die Qualität gleichberechtigt zu den drei Größen Kosten, Zeit und Leistung hinzugezählt (vgl. bspw. Ruf und Fittkau 2008, S. 15 f. oder Abts und Mülder 2011, S. 321), wobei die Größe Leistung dann auf den quantitativen Aspekt beschränkt ist. Dem wird hier nicht gefolgt, denn dann müss­ten konsequenterweise auch die Kosten in personelle und monetäre Aufwände aufgeteilt werden. Ziele des PM sind somit die bestmögliche quantitative und qualitative Umset­zung des Projektauftrags unter Berücksichtigung der Projektkosten und -dauer.

Das Endergebnis der quantitativen und qualitativen Projektleistung kann als „Projekt­produkt“ bezeichnet werden (vgl. Jenny 2010, S. 132). Beim IT-Projekt der MKK ist das Projektprodukt bspw. das betriebsbereite neue ERP-System. Damit wird zwischen dem vom Projekt zu erbringenden Wertschöpfungsprozess (Einführung eines neuen ERP-Systems) und dem am Ende vorliegenden Ergebnis (das betriebsbereite neue ERP- System) unterschieden, was insofern sinnvoll ist, als Wertschöpfungsprozess und Er­gebnis seitens der Projektstakeholder unterschiedlichen Bewertungskriterien unterliegen können.

Wie aus dem linken Bereich der Abbildung 2 ersichtlich, ist gemäß DIN 69901-5 zwi­schen PM-Prozess und Projektprozess zu unterscheiden. Der PM-Prozess umfasst wie zuvor definiert die Managementaufgaben Planung, Steuerung und Kontrolle sämtlicher Projektaktivitäten. Sein Ergebnis besteht aus den Größen Kosten, Zeit und Leistung. Der Projektprozess ist dagegen der eigentliche Wertschöpfungsprozess eines Projekts - also der Prozess, mit dem die Projektaufgabe operativ ausgeführt wird und der - ge­plant, gesteuert und kontrolliert vom PM-Prozess - unmittelbar zum Projektprodukt führt. Der PM-Prozess wird Patzak und Rattay (2009, S. 27-29) zufolge in folgende Phasen unterteilt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Phasen des Projektmanagements (eigene Darstellung, basierend auf Patzak und Rattay 2009, S. 27-29)

Wie aus Abbildung 3 hervorgeht, durchläuft der PM-Prozess die Start-, Planungs-, Ausführungs-, Koordinations- und Abschlussphase, wobei es mehrere Ausführungs- und Koordinationsphasen geben kann. Diese Phasen werden auch als PM-Phasen bezeich­net. In der Projektstartphase werden nach Initiierung des Projekts der quantitative und qualitative Leistungsumfang, die personellen und finanziellen Ressourcen sowie der Zeitraum geklärt und festgelegt. Danach werden in der Projektplanungsphase die Pro­jektaufgaben strukturiert und der Aufwand geschätzt, sodass ein Projektplan erstellt werden kann, aus dem Reihenfolge und Abhängigkeiten der Aktivitäten, Termine, Kos­ten und Personaleinsatz hervorgehen. Darüber hinaus sind in dieser Phase die Projekt­organisation zu bilden und die Projektführungssysteme zu installieren. In der Projekt­ausführungsphase geht es schließlich um die inhaltliche Bearbeitung der Aufgabenstel­lung, also um die Steuerung des operativen Projektprozesses. In einem Projekt kann es abhängig vom Projektprozess mehrere Projektausführungsphasen geben, bspw. Kon­zeption, Planung, Realisierung und Inbetriebnahme. Nach jeder Projektausführungs­phase folgt eine Projektkoordinationsphase, die dazu dient, die Zwischenergebnisse zu kontrollieren und zu bewerten sowie bei Abweichungen und Änderungen entsprechende Maßnahmen in Bezug auf die Planung oder Umsetzung einzuleiten. Die Projektab­schlussphase bildet das Ende des PM-Prozesses. In ihr werden die Projektergebnisse bewertet und mögliche Lehren aus dem Projekt gezogen sowie die Projektorganisation geordnet aufgelöst. Der PM-Prozess entspricht somit den klassischen Bestandteilen eines Managementregelkreises (Planung, Steuerung, Kontrolle), mit dem Unterschied, dass der PM-Regelkreis aufgrund der zeitlichen Befristung eines Projekts einen defi­nierten Anfang und Abschluss aufweist. Nach der Betrachtung der Ziele und Phasen des PM werden im nächsten Kapitel die Phasen des Projektprozesses näher untersucht.

4.3 Projektphasen zur Einführung einer Standardsoftware

Die Phasen des Projektprozesses werden als „Projektphasen“ bezeichnet (Patzak und Rattay 2009, S. 30). Sie stellen einzelne Abschnitte im Prozess der Leistungserstellung dar und sind abhängig von der jeweiligen Aufgabenstellung des Projekts. Im Fall der MKK geht es um die Einführung eines neuen ERP-Systems, also um die Einführung einer Standardsoftware. Nach Gadatsch (2008, S. 76-78) können Standardsoftwareein­führungsprojekte in folgende Phasen unterteilt werden:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Projektphasen zur Einführung einer Standardsoftware (in Anlehnung an Gadatsch 2008, S. 76)

Wie in Abbildung 4 dargestellt, gliedert sich ein Projekt zur Einführung einer Stan­dardsoftware in die Phasen Voruntersuchung, Konzeption, Detaillierung und Realisie­rung, Produktionsvorbereitung und produktiver Betrieb. Während der Voruntersu­chungsphase geht es Gadatsch zufolge zunächst darum, die möglichen Handlungsalter­nativen zu prüfen (Kauf oder Miete, Fremd- oder Eigenbetrieb usw.), die Software aus­zuwählen und einen ersten Realisierungsplan zu erstellen. Im Rahmen der Konzep­tionsphase sind sodann die durch die Standardsoftware abzudeckenden Funktionen und Prozesse festzulegen, die Programme für die Datenmigration zu entwerfen und ggf. Erweiterungen und Anpassungen zu konzipieren. In der anschließenden Realisierungs­phase erfolgt die Abbildung der festgelegten Funktionen und Prozesse (Customizing) in der Software, die Erstellung der Migrationsprogramme und ggf. die Umsetzung der Erweiterungen und Anpassungen. Darauf folgt die Produktionsvorbereitungsphase, in der die Dokumentationen zu erstellen, die Endbenutzer zu schulen, die Altsysteme ab­zuschließen und die Altdaten zu migrieren sind. Die Umstellung auf den Produktivbe­trieb kann Gadatsch zufolge in Form einer „Big-Bang-“ oder einer Sukzessivstrategie erfolgen. Bei der Big-Bang-Strategie wird die neue Software als Ganzes in einem Schritt, bei der Sukzessivstrategie in Teilen in mehreren Schritten eingeführt. Bei der MKK erfolgt die Umstellung vom alten aufs neue ERP-System in Form eines Big Bang, da zu einem Stichtag das alte ERP-System vollständig durch das neue ERP-System ab­gelöst werden soll. Mit Beginn der Phase des produktiven Betriebs ist aus dem Projekt heraus zunächst noch Support zu leisten, es sind mögliche Nachbesserungen vorzu­nehmen und Restarbeiten durchzuführen sowie zuletzt die Betreuung des Projektpro­dukts schrittweise an das Tagesgeschäft zu übergeben. Es kann somit festgestellt wer­den, dass die Einführung einer Standardsoftware einen komplexen und umfangreichen Projektprozess bedeutet. Im Folgenden wird sich den Projektorganisationsformen und Projektrollen zugewendet.

4.4 Projektrollen und -organisationsformen

Beim PM wird zwischen der internen und externen Projektaufbauorganisation unter­schieden. Die interne Projektaufbauorganisation bezieht sich auf die Struktur des Pro­jektteams, die externe auf die Form der Einbindung des Projektteams ins Unternehmen (vgl. Ruf und Fittkau 2008, S. 72 und 82). Es wird deshalb meist auch von Projekt­organisationsstruktur (intern) und Projektorganisationsform (extern) gesprochen. Die Projektorganisationsstruktur kann in Form der üblichen Organisationsstrukturen (Einli­nien-, Mehrlinien-, Stablinienorganisation usw.) aufgebaut werden, wobei sich die Wahl der Projektorganisationsstruktur an der Projektaufgabenstellung und der vorhandenen Unternehmensstruktur orientieren sollte. Die typischen Rollen innerhalb einer Projekt­organisationsstruktur sind folgende:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Typische Rollen innerhalb einer Projektorganisationsstruktur (in Anlehnung an Kuster et al. 2011, S. 101)

Wie aus Abbildung 5 hervorgeht, wird zwischen den Projektrollen Auftraggeber, PLA, PL, und Projektmitarbeiter unterschieden (dies und das Folgende nach Kuster et al. 2011, S. 101 f.). Der PLA besteht aus dem Projektauftraggeber und je nach Ausgestal­tung weiteren Mitgliedern, wie Vertretern des oberen Managements, der betroffenen Fachabteilungen oder wichtiger Anspruchsgruppen. Er stellt innerhalb eines Projekts die oberste Hierarchiestufe dar. Der Auftraggeber ist derjenige, der das Projekt initiiert. Er mussjedoch nicht notwendigerweise auch der Antragsteller sein, denn der Projektantrag kann bspw. durch die Controllingabteilung an die Unternehmensführung oder ein zent­rales PM-Gremium gestellt werden, von wo aus das Projekt dann beauftragt wird. Der Projektauftraggeber ist üblicherweise der maßgebliche Entscheidungsträger innerhalb des PLA und damit auch für das gesamte Projekt. Es sind aber auch Konstellationen denkbar, bei denen sich Auftraggeber und Entscheidungsträger unterscheiden, bspw. wenn der Aufsichtsrat den Vorstand mit der Durchführung eines Projekts beauftragt. In diesem Fall würde der Vorstand das Projekt unternehmensintern vertreten, jedoch nicht die maßgebliche Entscheidungsinstanz darstellen.

Die PL ist für die Planung, Steuerung und Kontrolle - also das PM - eines Projekts verantwortlich. Sie kann aus einer Person (dem Projektleiter) oder einem Team be­stehen. Im Falle eines Teams müssen jedoch die Zuständigkeiten und Verantwortlich­keiten geklärt sein, um Konflikten vorzubeugen. Die Projektmitarbeiter sind schließlich für die inhaltliche Bearbeitung zuständig. Sie sind es, die im Rahmen des Projektpro­zesses mithilfe ihrer Fachkompetenz das Projektprodukt erstellen.

Beim IT-Projekt der MKK ist der maßgebliche Entscheidungsträger des PLA der Vor­standsvorsitzende der MKK. Die PL besteht aus drei gleichberechtigten Projektleitern - es gibt also keine klaren Zuständigkeiten und Verantwortlichkeiten. Die Projektmit­arbeiter setzen sich aus Mitarbeitern der IT-Abteilung und den Fachabteilungen der MKK sowie Mitarbeitern des Systemhauses zusammen. Sie wurden in mehrere TP zu­sammengefasst. Die jeweiligen TPL bestehen ebenfalls aus gleichberechtigten Teams, zudem sind die Zuständigkeiten und Verantwortlichkeiten von PL und TPL nicht ge­klärt. Bezüglich der Projektorganisationsstruktur besteht demnach Optimierungsbedarf.

Die Projektorganisationsform kann Wieczorrek und Mertens (2011, S. 28-33) zufolge als reine Projektorganisation, Einflussprojektorganisation oder Matrixprojektorganisa­tion gestaltet werden. Im Folgenden werden die Eigenschaften sowie Vor- und Nachteile dieser drei Projektorganisationsformen aufgeführt:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Mögliche Projektorganisationsformen (eigene Darstellung, basierend auf Wieczorrek und Mertens 2011, S. 28-33)

Wie aus Tabelle 2 ersichtlich ist, wird bei der reinen Projektorganisation für das Pro­jektteam eine eigenständige Organisationseinheit innerhalb der Linienorganisation ge­bildet und die Projektmitarbeiter in die Projektorganisation versetzt (dies und das Fol­gende nach Wieczorrek und Mertens 2011, S. 28-33). Die PL ist für das Projekt fachlich und personell alleine verantwortlich. Vorteilhaft bei der reinen Projektorganisation ist, dass die Projektmitglieder sich aufgrund der Versetzung voll auf die Projektaufgaben konzentrieren können und dass die Verantwortlichkeiten und Zuständigkeiten klar ge­regelt sind. Allerdings stellt der Aufbau einer reinen Projektorganisation einen erhebli­chen Eingriff in die Unternehmensstruktur dar; die Wiedereingliederung der Projekt­mitarbeiter in die Unternehmensstruktur nach Projektabschluss kann problematisch sein. Außerdem ist es durch die Eigenständigkeit des Projekts möglich, dass dieses ein ge­wisses Eigenleben entwickelt und sich so von der Linienorganisation entfernt.

Im Gegensatz zur reinen Projektorganisation wird bei der Einflussprojektorganisation keine eigenständige Organisationseinheit gebildet. Die Projektmitglieder bleiben un­verändert dem Linienvorgesetzten fachlich und personell unterstellt. Die PL hat hier nur die Rolle eines Projektkoordinators. Als Vorteile können genannt werden, dass die Unternehmensstruktur unverändert bleibt und dass für die Projektaufgaben flexibel auf alle Mitarbeiter des Unternehmens zurückgegriffen werden kann. Nachteilig ist jedoch vor allem die fehlende Weisungsbefugnis der PL, denn die Entscheidungen werden ausschließlich in der Linie getroffen, wodurch es Vorkommen kann, dass sich niemand für das Projekt voll verantwortlich fühlt.

Die Matrixprojektorganisation versucht, die Vorteile der reinen Projektorganisation und die der Einflussprojektorganisation zu verbinden. Bei ihr bleibt die Unternehmensstruk­tur wie bei der Einflussprojektorganisation bestehen, sie wird jedoch um die Projekt­organisation ergänzt, sodass eine Matrixorganisation entsteht. Die PL erhält fachliche Weisungsbefugnisse; personell bleiben die Projektmitarbeiter jedoch den Linienvorge­setzten unterstellt, womit sie zeitanteilig für das Projekt und die Linie tätig sind. Da­durch sind zwar die Verantwortlichkeiten klar festgelegt und die Projektmitarbeiter müssen aus der Linie nicht aus- und wieder eingegliedert werden, aber dadurch, dass ein Projektmitarbeiter zwei Vorgesetzte hat, kann es zu Weisungskonflikten zwischen Pro­jekt und Linie kommen.

Die Projektorganisationsform tritt in der Praxis meist als Mischung der drei Grundfor­men auf und kann zudem während der Projektdauer gewechselt werden (vgl. Wieczor- rek und Mertens 2011, S. 28 und 34; zum Wechsel ebenso Madauss 2000, S. 100 f und Litke 2007, S. 77). So kann bspw. für die Start- und Planungsphase eine Einflusspro­jektorganisation und ab der Ausführungsphase eine reine Projekt- oder Matrixprojekt­organisation gewählt werden. Dies erscheint zweckmäßig, denn für die in der Anfangs­phase anstehenden Projekttätigkeiten (Auftragsformulierung, Planung usw.) benötigt die PL meist noch keine Weisungsbefugnisse.

In Bezug auf das IT-Projekt der MKK kann keine eindeutige Projektorganisationsform identifiziert werden, denn PL und TPL tragen dort zwar die fachliche Verantwortung, haben aber keine entsprechende Weisungsbefugnis. Zudem sind zwar einige Projekt­mitglieder vollständig fürs Projekt abgestellt, jedoch nicht in eine eigenständige Pro­jektorganisation versetzt, wodurch die personelle Verantwortung bei einer Führungskraft liegt, die während der Projektdauer nichts mit dem Mitarbeiter zu tun hat. Am ehesten trifft auf das Projekt der MKK deshalb noch die Einflussprojektorganisation zu, aller­dings mit einem weiteren Nachteil (der fehlenden fachlichen Weisungsbefugnis) ver­sehen. Demzufolge besteht zusätzlich zur Projektorganisationsstruktur auch Optimie­rungsbedarf bezüglich der Projektorganisationsform. Im nächsten Schritt werden die typischen Einflussfaktoren eines IT-Projektumfelds analysiert.

4.5 Typische Einflussfaktoren eines IT-Projektumfelds

Das Projektumfeld stellt DIN 69901-5 zufolge jenes Umfeld dar, in dem das Projekt entsteht und durchgeführt wird. Demnach ist das Projektumfeld nicht im Sinne eines abgegrenzten Umfelds außerhalb des Projekts zu verstehen, sondern als umfassende Umgebung, innerhalb derer das Projekt durchgeführt wird. Dieses umfassende Ver­ständnis vom Projektumfeld erscheint zweckmäßig, denn ein Projekt kann nur dann sinnvoll von seinem äußeren Umfeld abgegrenzt werden, wenn einerseits die Projekt­mitglieder ausschließlich fürs Projekt tätig sind und andererseits das Projekt eine eigenständige Organisationseinheit darstellt. Sind beide Bedingungen nicht gegeben, entstehen fließende Übergänge zwischen innerem und äußerem Projektumfeld, da ein Projektmitarbeiter bspw. gleichzeitig sowohl zum inneren als auch zum äußeren Pro­jektumfeld zu zählen ist.

In der PM-Literatur beschränkt sich die Analyse des Projektumfelds meist auf eine Analyse der Projektstakeholder. Stakeholder eines Projekts ist nach Angermeier (2012d) „eine Person, Personengruppe oder eine Organisation, die aktiv am Projekt beteiligt ist oder durch den Projektverlauf oder das Projektergebnis beeinflusst wird [und] die ge­gebenenfalls den Projektverlauf oder das Projektergebnis beeinflussen kann“. Unter dem Begriff „Stakeholder“ werden demzufolge alle Personen, Personengruppen oder Organisationen verstanden, die in irgendeiner Weise mit dem Projekt oder dem Pro­jektprodukt in Berührung kommen. Das Projektumfeld bestehtjedoch nicht nur aus den Interessen, Erwartungen oder Befürchtungen der Stakeholder, sondern auch aus weite­ren Faktoren wie bspw. dem Tagesgeschäft, anderen Projekten oder gesetzlichen Rah­menbedingungen, die sichjeweils auf das Projekt auswirken können. Patzak und Rattay (2009, S. 96 f.) plädieren daher für eine umfassende Projektumfeldanalyse anstelle einer Stakeholderanalyse. Sie unterteilen das Projektumfeld in unternehmensinterne und -ex­terne organisatorisch-soziale Umfeldgruppen sowie sachlich-inhaltliche Einflussfakto­ren (ähnlich Tiemeyer 2005, S. 624 und Melbinger 2010b, S. 591-593). Unter den or- ganisatorisch-sozialen Umfeldgruppen verstehen Patzak und Rattay dabei Personen, Personengruppen oder Organisationen, die den Projektverlauf fördern oder hemmen können. Dementsprechend sind damit die Projektstakeholder gemeint. Als sachlich-in­haltliche Einflussfaktoren sind Patzak und Rattay zufolge all jene Einflussfaktoren zu verstehen, „die nicht durch direktes Einwirken von Personen entstehen, wie z. B. andere Projekte, Gesetze, Entstehung neuer Technologien, Marktgegebenheiten etc.“. Die von Patzak und Rattay beschriebene Umfeldanalyse unterscheidet sich von der klassischen Stakeholderanalyse also durch die Hinzunahme sachlich-inhaltlicher Einflussfaktoren. Damit bleiben allerdings die am Projekt beteiligten Organisationskulturen als weiterer relevanter sozialer Einflussfaktor unberücksichtigt, weshalb die von ihnen beschriebene Umfeldanalyse einer Ergänzung bedarf.

Hierfür bietet sich aufgrund des umfassenden Ansatzes die PESTEL-Analyse an, die üblicherweise zur Analyse des unternehmerischen Makroumfelds eingesetzt wird. Die PESTEL-Analyse differenziert zwischen politischen, wirtschaftlichen, sozialen, tech­nologischen, ökologischen und rechtlichen Einflussfaktoren (vgl. Johnson et al. 2011, S. 80). Die wirtschaftlichen, technologischen, ökologischen und rechtlichen Einflussfak­toren wurden bei den sachlich-inhaltlichen Einflussfaktoren von Patzak und Rattay be­reits berücksichtigt. Die politischen Einflussfaktoren können dieser Gruppe ebenfalls zugeordnet werden, da politischer Einfluss überwiegend in Bezug auf sachlich-inhaltli­che Aspekte ausgeübt werden dürfte. Übrig bleiben die sozialen Einflussfaktoren, wo­mit bei einer Projektumfeldanalyse insgesamt zwischen drei Einflussgruppen unter­schieden werden kann: den organisatorisch-sozialen Umfeldgruppen, den sonstigen so­zialen und den sachlich-inhaltlichen Einflussfaktoren. Das typische Umfeld eines IT- Projekts könnte sich basierend auf dieser Differenzierung wie folgt darstellen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Typische Einflussfaktoren eines IT-Projektumfelds (eigene Darstellung, basierend auf Patzak und Rattay 2009, S. 96 f.; Johnson et al. 2011, S. 80)

Die in Abbildung 6 genannten typischen Einflussfaktoren werden im Folgenden erläu­tert. Begonnen wird mit den organisatorisch-sozialen Umfeldgruppen:

— Projektlenkungsausschuss (PLA) und Projektauftraggeber sind die für ein Projekt maßgebliche formale Entscheidungsinstanz, womit sie einen direkten Einfluss auf die Entwicklung des Projekts nehmen. Der Projektauftraggeber ist Mitglied des PLA, er wird in Abbildung 6 jedoch separat aufgeführt, um zu verdeutlichen, dass er meist nur zeitweise mit dem Projekt beschäftigt ist. Innerhalb des PLA können konträre Interes­sen aufeinandertreffen, wie das Beispiel der MKK zeigt: Das Systemhaus will den Umstellungstermin halten, die Abteilungsleiter befürworten eine längere Projektdauer, um die Qualität des Projektprodukts zu erhöhen.
- Die Projektleitung (PL) ist für die Planung, Steuerung und Kontrolle des Projekts verantwortlich. Sie übt qua ihres Amts je nach Projektorganisationsform einen for­mellen oder informellen Einfluss auf die Projektmitarbeiter aus.
- Die internen und externen Projektmitarbeiter sind für die Erstellung des Projektpro­dukts zuständig, womit sie unmittelbar Einfluss auf das Projektergebnis nehmen. Sie werden wie jeder andere Mitarbeiter des Unternehmens auch eigene Interessen ver­folgen und Erwartungen haben, bspw. die Hoffnung auf berufliche Weiterentwicklung. Wenn Projektmitarbeiter nicht motiviert sind, können sie allerdings auch hemmend aufs Projekt wirken. Bei der MKK ist bspw. für viele der internen Projektmitarbeiter nicht klar, welche Tätigkeiten sie nach Projektende ausführen werden, da ihnen in dieser Hinsicht keine Perspektive geboten wird. Das führte bereits zu einer Demoti­vierung einiger Projektmitarbeiter, wodurch manche von ihnen nur noch mittelmäßige Leistungen erbringen.
— Die Unternehmensführung dürfte meist ein ureigenes Interesse an der erfolgreichen Durchführung des Projekts haben. Sie kann mittels ihrer Autorität erheblichen Ein­fluss aufProjektmitglieder und Linie ausüben.
— Der Betriebsrat (oder wie bei der MKK: Personalrat) kann durch Mitsprache- und Zustimmungsrechte das Projekt blockieren. Er kann aber auch positiv auf die Endbe­nutzer einwirken, wenn er im Unternehmen akzeptiert ist sowie rechtzeitig und um­fassend ins Projekt eingebunden wird.
— Die Linienvorgesetzten sind bei einer Matrixprojektorganisation die personellen und bei einer Einflussprojektorganisation zusätzlich auch die fachlichen Vorgesetzten der Projektmitarbeiter. Sie müssen qualifizierte Mitarbeiter für die Projektaufgaben frei­stellen, womit diese für das Tagesgeschäft nicht mehr zur Verfügung stehen und Kon­flikte zwischen Linien- und Projektziele die Folge sein können. Bei der MKK sehen einige Linienvorgesetzte die Erreichung ihrer Linienziele gefährdet, weshalb sie in der Vergangenheit zeitweise die Freistellung benötigter Projektmitarbeiter blockiert ha­ben, wodurch es zu Verzögerungen im Projektfortschritt gekommen ist.
— Als Endbenutzer werden alle IT-Benutzer in den Abteilungen außerhalb der IT-Abtei- lung bezeichnet (vgl. Stahlknecht und Hasenkamp 2005, S. 12). Sie müssen das Pro­jektprodukt nach Fertigstellung in der gewünschten und vorgesehenen Art und Weise verwenden, wozu ihrerseits eine entsprechende Akzeptanz erforderlich ist.

[...]