Bei umfassenden IT-Projekten treten häufig verschiedene Konflikte mit Projektstakeholdern auf, die den Erfolg eines Projektes beeinträchtigen können. Beispielsweise stellen Linienvorgesetzte nicht genügend geeignete Projektmitarbeiter zur Verfügung mit dem Hinweis, das Tagesgeschäft habe Vorrang. Um solche Konflikte und Widerstände zu minimieren und eine möglichst breite Akzeptanz für das IT-Projekt zu erreichen, müssten die Stakeholder durch das Projektmanagement (PM) stärker als bisher berücksichtigt werden.
In der Literatur sind Projektstakeholder Gegenstand verschiedener, sich teilweise überschneidender Themenbereiche. Diese erweisen sich aber bei näherer Betrachtung als voneinander unabhängige Instrumente, die zwar im Rahmen von IT-Projekten zur Berücksichtigung der Stakeholder optional eingesetzt werden können, jedoch nicht zu einer ganzheitlichen Stakeholderorientierung 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-Kernprozesses die Stakeholder bei anstehenden Entscheidungen stärker berücksichtigt würden, könnten die vielfältigen Konflikt- und Widerstandspotenziale frühzeitiger und umfassender erkannt und minimiert werden – was sich wiederum 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 auch all jene Aufgaben einschließt, die notwendig sind, um die Legitimität aller relevanten Anspruchsgruppen zu erlangen bzw. zu erhalten. Legt man dies dem PM zugrunde, so könnte Projektmarketing ein Konzept für ein ganzheitlich stakeholderorientiertes PM bedeuten, bei dem sämtliche Projektfunktionen stakeholderorientiert ausgerichtet werden. In der etablierten PM-Literatur ist ein solcher Ansatz bislang nicht betrachtet worden. Insofern erscheint es angebracht ein Projektmarketingmodell zu entwickeln, das auf dem modernen Marketingverständnis basiert, sowie anschließend zu untersuchen, ob es die Konflikte und Widerstände bei einem IT-Projekt minimieren könnte.
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 umfassenden 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 Tagesgeschä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 Umstellungstermin 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 bisher berücksichtigt werden.
In der Literatur sind Projektstakeholder Gegenstand verschiedener, sich teilweise überschneidender Themenbereiche, bspw. des Stakeholder- und Informationsmanagements. Diese erweisen sich aber bei näherer Betrachtung als voneinander unabhängige Instrumente, die zwar im Rahmen von IT-Projekten zur Berücksichtigung der Stakeholder optional eingesetzt werden können, jedoch nicht zu einer ganzheitlichen Stakeholderorientierung 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 stakeholderorientiert ausgerichtet werden. In der etablierten PM-Literatur ist ein solcher Ansatz bislang nicht betrachtet worden. Insofern erscheint es angebracht ein Projektmarketingmodell zu entwickeln, das auf dem modernen Marketingverständnis basiert, sowie anschließend zu untersuchen, ob es die Konflikte und Widerstände bei der MKK minimieren und eine größere Akzeptanz des neuen ERP-Systems erreichen könnte. Die der vorliegenden Arbeit zugrunde liegende Frage lautet somit: Inwiefern kann Projektmarketing im Sinne einer ganzheitlich marktorientierten Unternehmensfuhrung die Stakeholderorientierung und dadurch die Erfolgsaussichten von IT-Projekten im Vergleich zum klassischen IT-PM verbessern und wie könnte eine beispielhafte Projektmarketingkonzeption 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 typischerweise 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 verstehen? 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 Projektorganisationen 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 implementiert 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 stakeholderorientierten PM-Konzept zusammengeführt Sodann werden die Implementierung des Projektmarketings, 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 Akzeptanz 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 Projektmarketingziele festgelegt. Danach werden die Projektmarketingstrategien ausgewählt und überlegt, wie der Projektmarketingmix ausgestaltet werden könnte. Zuletzt wird die Implementierung 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 Verwaltung der Kunden und zur Steuerung der branchentypischen Prozesse dasselbe ERP- System. Ein ERP-System ist eine aus mehreren Komponenten bestehende Anwendungssoftware, 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 System 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 Gegebenheiten 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: Auszahlungen von Versicherungsleistungen erfolgen bisher über einen komplexen Prozess, an dem abteilungsübergreifend mehrere Sachbearbeiter beteiligt sind, wobei die Hauptarbeit in der Finanzabteilung getätigt wird. Das neue ERP-System wird diesen Prozess größtenteils automatisieren, sodass durch den Wegfall manueller Prozessschritte weniger 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 Mitarbeiter 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 gleichberechtigten Projektleitern zusammen: Der erste Projektleiter ist ein langjähriger festangestellter Mitarbeiter der MKK, der zweite ist für die Dauer des Projekts befristet angestellt und hat Erfahrung mit SAP-Einführungsprojekten, der dritte stammt von dem Systemhaus, welches die Branchenlösung herstellt und vor Ort installiert. Der Projektleiter 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 Systemhauses besteht. Für die im Projekt anfallenden Aufgaben wurden neun Fachteilprojekte und acht Querschnittsteilprojekte gebildet, sodass das Projekt aus insgesamt 17 Teilprojekten (TP) besteht. Den Fachteilprojekten obliegt jeweils eine fachliche Verantwortung (bspw. die Personal-, Finanz- oder Kundenverwaltung), die Querschnittsteilprojekte 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 weiterhin nur ihren Linienvorgesetzten unterstellt, unabhängig davon, ob sie Teil- oder
Vollzeit am Projekt mitarbeiten. Die PL und TPL haben dementsprechend für die Projektmitarbeiter der MKK keine formellen Weisungsbefugnisse. Überdies sind die Projektmitarbeiter 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 erfolgt einerseits über sporadische E-Mail-Newsletter und andererseits über die Intranetseiten 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 Mitarbeitern der MKK. Dies ist deshalb problematisch, weil die informellen Kommunikationswege 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 zusammengefasst 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 Projektmarketingdefinitionen vier Hauptziele identifiziert werden:
W: Werbende Darstellung des Projekts: Projektmarketing soll das Projekt im Projektumfeld 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ägungen vorzufinden ist. Die umfassendste Definition liefern Stempkowski et al. Ihr Fokus liegtjedoch auf Infrastrukturprojekten, weshalb sie vor allem die Einbeziehung der Öffentlichkeit 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 Marketingverständnis im Sinne einer marktorientierten Unternehmensführung auf das PM selbst an, womit zwischen dem in der Literatur vorherrschenden Verständnis von Projektmarketing 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 Untersuchung 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 Begriffsdefinitionen zeigt.
2. Meist wird einfach das Unternehmensmarketing ohne Eignungsprüfung und Anpassungen 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 Investitionsmarketing zu verstehen ist und warum dies dem Projektmarketing entsprechen soll. Häufig anzutreffen ist weiterhin auch die ungeprüfte Verwendung des Konsumgütermarketings fürs Projektmarketing (vgl. bspw. Melbinger 2010a, S. 545).
3. Die Maßnahmen, die dem Themenbereich des Projektmarketings immer wieder zugeordnet werden, sind nicht neu. Sie wurden bisher anderen Themengebieten des PM zugeordnet, wie dem Stakeholder- und Informationsmanagement. - Auch dem ist zuzustimmen, denn das Ziel des Informationsmanagements besteht bspw. ebenfalls darin, 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 öffentlich 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 Projektmanagements 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 marktorientierten Ansatz noch nicht für sich beanspruchen kann. Zudem sei der Sinn eines solchen Ansatzes fraglich. Dessen ungeachtet sieht er eine Entwicklung des Projektmarketings 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 diesem 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 thematisiert, 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 Wesentlichen 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 beizupflichten, 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 Einmaligkeit auszeichnet sowie eine beachtliche Größe und einen hohen Grad an Komplexität aufweist“. Damit ist allerdings auch ihre Projektdefinition unpräzise, denn die Bedingungen „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 Projekt durchgeführt, das die Transparenz der Durchlaufzeiten fürjeden einzelnen Produktionsschritt 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 einzelnen Produktionsschritte bisher nicht erfasst wurden und nach Schaffung der technischen 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 Projekt dar. Die Bedingungen zeitliche Befristung, Neuartigkeit, Einmaligkeit und Komplexitä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 Neuartigkeit gekennzeichnet sind und wegen ihres interdisziplinären Querschnittcharakters 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 Bedingungen 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 Pharmaunternehmen 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“ zuzuwenden. Nach der Definition von Krcmar (2010, S. 30) bezeichnet IT „die Gesamtheit der zur Speicherung, Verarbeitung und Kommunikation zur Verfügung stehenden Ressourcen sowie die Art und Weise, wie diese Ressourcen organisiert sind“. Demzufolge steht IT für alle Informations- und Kommunikationssysteme eines Unternehmens, was jeweils deren Hard- und Software sowie deren Vernetzung umfasst. Diese Definition ist für die vorliegende Untersuchung ausreichend, denn sowohl das neue ERP-System der MKK als auch das zuvor beispielhaft angeführte Monitoringsystem des Pharmaunternehmens 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“ deutet 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 Aufgabe 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 betrifft, 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 Projektmarketingkonzeption 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 Verhä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 verstehen, dessen Kernaufgabe die Einführung, Anpassung oder Neuentwicklung von geschä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ührungsoder Instandhaltungsprojekte unterteilt werden. Bei der MKK soll eine neue Standardsoftware - 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 Untersuchungsinteresse erörtert wurde, erfolgt im nächsten Kapitel eine genauere Auseinandersetzung 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 Kontrolle 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 vorliegende 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 eingesetzten 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 besteht 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 geforderten 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üssten konsequenterweise auch die Kosten in personelle und monetäre Aufwände aufgeteilt werden. Ziele des PM sind somit die bestmögliche quantitative und qualitative Umsetzung des Projektauftrags unter Berücksichtigung der Projektkosten und -dauer.
Das Endergebnis der quantitativen und qualitativen Projektleistung kann als „Projektprodukt“ 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 Ergebnis seitens der Projektstakeholder unterschiedlichen Bewertungskriterien unterliegen können.
Wie aus dem linken Bereich der Abbildung 2 ersichtlich, ist gemäß DIN 69901-5 zwischen 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 - geplant, 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 bezeichnet. 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 Projektaufgaben strukturiert und der Aufwand geschätzt, sodass ein Projektplan erstellt werden kann, aus dem Reihenfolge und Abhängigkeiten der Aktivitäten, Termine, Kosten und Personaleinsatz hervorgehen. Darüber hinaus sind in dieser Phase die Projektorganisation zu bilden und die Projektführungssysteme zu installieren. In der Projektausführungsphase geht es schließlich um die inhaltliche Bearbeitung der Aufgabenstellung, also um die Steuerung des operativen Projektprozesses. In einem Projekt kann es abhängig vom Projektprozess mehrere Projektausführungsphasen geben, bspw. Konzeption, Planung, Realisierung und Inbetriebnahme. Nach jeder Projektausführungsphase 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 Projektabschlussphase 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 definierten 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 Standardsoftwareeinfü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 Standardsoftware in die Phasen Voruntersuchung, Konzeption, Detaillierung und Realisierung, Produktionsvorbereitung und produktiver Betrieb. Während der Voruntersuchungsphase geht es Gadatsch zufolge zunächst darum, die möglichen Handlungsalternativen zu prüfen (Kauf oder Miete, Fremd- oder Eigenbetrieb usw.), die Software auszuwählen und einen ersten Realisierungsplan zu erstellen. Im Rahmen der Konzeptionsphase 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 Realisierungsphase 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 abzuschließen und die Altdaten zu migrieren sind. Die Umstellung auf den Produktivbetrieb 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 abgelö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 vorzunehmen und Restarbeiten durchzuführen sowie zuletzt die Betreuung des Projektprodukts schrittweise an das Tagesgeschäft zu übergeben. Es kann somit festgestellt werden, 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 unterschieden. Die interne Projektaufbauorganisation bezieht sich auf die Struktur des Projektteams, 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 Projektorganisationsstruktur (intern) und Projektorganisationsform (extern) gesprochen. Die Projektorganisationsstruktur kann in Form der üblichen Organisationsstrukturen (Einlinien-, 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 Projektorganisationsstruktur 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 Ausgestaltung 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 zentrales 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 bestehen. Im Falle eines Teams müssen jedoch die Zuständigkeiten und Verantwortlichkeiten 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 Projektprozesses mithilfe ihrer Fachkompetenz das Projektprodukt erstellen.
Beim IT-Projekt der MKK ist der maßgebliche Entscheidungsträger des PLA der Vorstandsvorsitzende der MKK. Die PL besteht aus drei gleichberechtigten Projektleitern - es gibt also keine klaren Zuständigkeiten und Verantwortlichkeiten. Die Projektmitarbeiter setzen sich aus Mitarbeitern der IT-Abteilung und den Fachabteilungen der MKK sowie Mitarbeitern des Systemhauses zusammen. Sie wurden in mehrere TP zusammengefasst. Die jeweiligen TPL bestehen ebenfalls aus gleichberechtigten Teams, zudem sind die Zuständigkeiten und Verantwortlichkeiten von PL und TPL nicht geklärt. Bezüglich der Projektorganisationsstruktur besteht demnach Optimierungsbedarf.
Die Projektorganisationsform kann Wieczorrek und Mertens (2011, S. 28-33) zufolge als reine Projektorganisation, Einflussprojektorganisation oder Matrixprojektorganisation 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 Projektteam eine eigenständige Organisationseinheit innerhalb der Linienorganisation gebildet und die Projektmitarbeiter in die Projektorganisation versetzt (dies und das Folgende 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 geregelt sind. Allerdings stellt der Aufbau einer reinen Projektorganisation einen erheblichen Eingriff in die Unternehmensstruktur dar; die Wiedereingliederung der Projektmitarbeiter in die Unternehmensstruktur nach Projektabschluss kann problematisch sein. Außerdem ist es durch die Eigenständigkeit des Projekts möglich, dass dieses ein gewisses 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 unverä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 Unternehmensstruktur wie bei der Einflussprojektorganisation bestehen, sie wird jedoch um die Projektorganisation ergänzt, sodass eine Matrixorganisation entsteht. Die PL erhält fachliche Weisungsbefugnisse; personell bleiben die Projektmitarbeiter jedoch den Linienvorgesetzten unterstellt, womit sie zeitanteilig für das Projekt und die Linie tätig sind. Dadurch 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 Projekt und Linie kommen.
Die Projektorganisationsform tritt in der Praxis meist als Mischung der drei Grundformen 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 Einflussprojektorganisation und ab der Ausführungsphase eine reine Projekt- oder Matrixprojektorganisation gewählt werden. Dies erscheint zweckmäßig, denn für die in der Anfangsphase 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 Projektmitglieder vollständig fürs Projekt abgestellt, jedoch nicht in eine eigenständige Projektorganisation 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, allerdings mit einem weiteren Nachteil (der fehlenden fachlichen Weisungsbefugnis) versehen. Demzufolge besteht zusätzlich zur Projektorganisationsstruktur auch Optimierungsbedarf 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 Verständnis vom Projektumfeld erscheint zweckmäßig, denn ein Projekt kann nur dann sinnvoll von seinem äußeren Umfeld abgegrenzt werden, wenn einerseits die Projektmitglieder 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 Projektumfeld 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 gegebenenfalls 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 Projektprodukt in Berührung kommen. Das Projektumfeld bestehtjedoch nicht nur aus den Interessen, Erwartungen oder Befürchtungen der Stakeholder, sondern auch aus weiteren Faktoren wie bspw. dem Tagesgeschäft, anderen Projekten oder gesetzlichen Rahmenbedingungen, 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 -externe organisatorisch-soziale Umfeldgruppen sowie sachlich-inhaltliche Einflussfaktoren (ä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-inhaltliche 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, technologischen, ökologischen und rechtlichen Einflussfaktoren (vgl. Johnson et al. 2011, S. 80). Die wirtschaftlichen, technologischen, ökologischen und rechtlichen Einflussfaktoren wurden bei den sachlich-inhaltlichen Einflussfaktoren von Patzak und Rattay bereits berücksichtigt. Die politischen Einflussfaktoren können dieser Gruppe ebenfalls zugeordnet werden, da politischer Einfluss überwiegend in Bezug auf sachlich-inhaltliche Aspekte ausgeübt werden dürfte. Übrig bleiben die sozialen Einflussfaktoren, womit bei einer Projektumfeldanalyse insgesamt zwischen drei Einflussgruppen unterschieden werden kann: den organisatorisch-sozialen Umfeldgruppen, den sonstigen sozialen 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äutert. 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 Interessen 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 formellen oder informellen Einfluss auf die Projektmitarbeiter aus.
- Die internen und externen Projektmitarbeiter sind für die Erstellung des Projektprodukts zuständig, womit sie unmittelbar Einfluss auf das Projektergebnis nehmen. Sie werden wie jeder andere Mitarbeiter des Unternehmens auch eigene Interessen verfolgen 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 Demotivierung 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 Einfluss 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 Endbenutzer einwirken, wenn er im Unternehmen akzeptiert ist sowie rechtzeitig und umfassend 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 freistellen, womit diese für das Tagesgeschäft nicht mehr zur Verfügung stehen und Konflikte 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 haben, 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 Projektprodukt nach Fertigstellung in der gewünschten und vorgesehenen Art und Weise verwenden, wozu ihrerseits eine entsprechende Akzeptanz erforderlich ist.
[...]
- Arbeit zitieren
- Michael Pinnecke (Autor:in), 2012, Projektmarketing als Ansatz für ein ganzheitlich stakeholderorientiertes IT-Projektmanagement, München, GRIN Verlag, https://www.grin.com/document/212773
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.