Praktische Umsetzung eines internationalen Web- Relaunchs mit Hilfe einer hybriden Projektmethodik
Hans Christian Liebig HTWSaar Waldhausweg 14 66123 Saarbrücken christian.liebig@htwsaar.de
Abstract:Internationale Unternehmen stehen gerade in exportorientierten Bran- chen vor der Herausforderung international ihre Produkte zu bewerben und in zahl- reichen Zielländern präsent zu sein. Neben der Landessprache sind kulturelle, technische und auch juristische Herausforderungen zu lösen. Ausgehend von ei- nem realen internationalen Internetprojekt unter der Beteiligung verschiedener Kulturkreise (u. a. US-amerikanisch, Chinesisch, Indisch, Europäisch) stellt die Arbeit Herausforderungen und Lösungsmöglichkeiten durch eine hybride Projekt- methodik anhand einer Fallstudie dar. Ein besonderer Fokus liegt in der Integration externer Dienstleister
1 These
Komplexe, internationale IT-Projekte, wie ein Web-Relaunch, können von einer hybri- den Projektmethodik profitieren, soweit einige Voraussetzungen beachtet werden.
2 Einleitung
Mittelständische Unternehmen in Deutschland sind vielfach international ausgerichtet und exportorientiert. Aufgrund ihrer Größe sind sie jedoch nicht in der Lage in jedem ihrer Zielmärkte mit einer vollständigen unternehmerischen Infrastruktur präsent zu sein.
In Webprojekten werden in aller Regel zahlreiche Informationen aus unterschiedlichen Bereichen den Besuchern angeboten. Dies führt insbesondere bei IT-Projekte mit einem starken Kundenbezug zu vielfältigen Herausforderungen, die insbesondere bei Webpro- jekten gelöst werden müssen. Wie in [Kl11] dargestellt ist, sind insbesondere auch tech- nische Fragestellungen zu lösen, um in den Zielmärkten entsprechende Wettbewerbsvor- teile zu haben.
3 Fallstudie
Die vorliegende Fallgestaltung basiert im Wesentlichen auf einem realen Projekt, wel- ches sowohl mit internen, wie auch externen Projektteilnehmern realisiert wurde:
Ein mittelständisches Unternehmen, in der Größenordnung von 3.000 Mitarbeitern und einem konsolidierten Jahresumsatz von ca. 1 Mrd. Euro hat als Zielmarkt 150 Länder identifiziert und die Webpräsenz soll in 30 Sprachen realisiert werden. Neben den Mit- gliedsländern der EU, sollen insbesondere die sogenannten BRIC-Staaten berücksichtigt werden. Das Unternehmen ist in der Elektrotechnik im Investitionsgüterbereich tätig.
Die Produkte seien erklärungsbedürftig und unterliegen regulatorischen Anforderungen (s. z. B. Maschinenrichtlinie der EU [EU06]).
3.1 Projekt Anforderungen
Die Reaktionszeit jedes Seitenabrufs im geplanten Zielgebiet soll deutlich unter 3 Se- kunden liegen, um ein abwandern potentieller Kunden zu verhindern. Daneben sollen folgende Altsysteme angebunden werden: ERP, PIM, MAM und CRM-System. Hierzu ist insbesondere eine geeignete Infrastruktur zu entwerfen, die dynamisch Geschäftspro- zesse in Form von technischen Workflows umsetzt. Zudem ist davon auszugehen, dass die Produkte variantenreich sind, so dass hier neben der reinen Suchfunktionalität auch Produktkonfiguratoren verwendet werden sollen. Daneben ist die Ausgabe in unter- schiedlichen Sprachen (inkl. der jeweiligen Zeichensätze und Übersetzungsworkflows) zu gewährleisten. Die jeweiligen rechtlichen Rahmenbedingungen in den unterschiedli- chen Zielländern sind einzuhalten.
3.2 Kulturelle Anforderungen
Wie in [VBW12] ausführlich dargestellt wurde, sind insbesondere bei internationalen IT-Projekten die kulturellen Unterschiede zu berücksichtigen (s. auch [Ho80] [Ho93]).
Diese sind in zwei Perspektiven zu berücksichtigen: Zum einen im Projektmanagement und zum anderen bezüglich des Projektergebnisses.
Gerade ein Web-Relaunch trifft aufgrund seiner gewünschten Außenwirkung in den Kernbereich von Kulturen. Im Rahmen der Projektabwicklung zeigte sich, dass im US- amerikanischen Umfeld neueste Technologien (insbesondere Integration von Social Media Elementen) erwartet werden, während gerade diese Technologien und deren An- wendung im europäischen Kulturkreis teilweise unerwünscht bzw. verboten sind (Ver- stoß gegen Datenschutzgesetze). Auch bezüglich der Darstellung von Menschen ist auf die Einhaltung einer „Diversity“-Repräsentation zu achten.
4 Auswahl der Projektmethodik
Es gibt eine Vielzahl von Projektmethoden. Im Folgenden wird zunächst das klassische Wasserfallmodell den agilen Methoden gegenübergestellt und eine hybride Projektme- thodik dargestellt, welche in der Fallstudie zum Einsatz kam.
4.1 Das klassische Wasserfallmodell und dessen Implikationen
Im Rahmen des klassischen Wasserfallmodells werden durch Lasten- und Pflichtenhefte sehr genau und umfassend alle wesentlichen Anforderungen sowie deren Realisierung beschrieben. Das Projekt wird in starren Phasen durchlaufen. Gerade in der Anforde- rungs- und Projektplanungsphase müssen alle wesentlichen Arbeitspakete erkannt, be- schrieben und vom Aufwand zuverlässig abgeschätzt werden. Dies ist bei hoch standar- disierten Projekten, wie z. B. im Baubereich gut möglich, bei innovativen, komplexen IT-Projekten jedoch sehr schwierig, da es häufig Sachverhaltsänderungen (z. B. neue Softwareversionen) gibt, die die Anforderungen an das Projekt wesentlich verändern.
Sollte es Abweichungen zu den festgelegten Spezifikationen geben, so lässt sich bei einem ordnungsgemäßen Vorgehen die Verantwortung klären und damit die Haftung abgrenzen.
4.2 Agile Methoden
Agile Methoden, wie z. B. Scrum [Sc97] verzichten demgegenüber auf eine initiale Detailplanung, sondern durchleben das Projekt in sehr kurzen Phasen (Sprints) wieder und wieder. Von Sprint zu Sprint werden dann einerseits die Anforderungen angepasst, wie auch auf einer Metaebene die Zusammenarbeit verbessert.
Innerhalb eines Unternehmens, in denen der Leistungsaustausch im Unternehmen selbst stattfindet sind solche Methoden auch gut anwendbar. Behält doch das Unternehmen das direkte Direktionsrecht gegenüber allen Akteuren. Schwierig wird es allerdings, wenn innerhalb eines Projektes externe Unternehmen in der Weise eingebunden werden sollen, wie es agile Methoden erfordern: Die externen Berater etwa sollen integrierte Projekt- mitglieder werden. Die Verantwortung zwischen den Unternehmen verschwimmt damit und ist im Falle einer etwaigen juristischen Auseinandersetzung nur noch schwer zuzu- ordnen. Rechtsabteilungen neigen daher dazu gerne in typisierten Verträgen die Projek- tabwicklung zu strukturieren. Das ist gerade bei agilen Methoden nur schwer möglich.
Folgendes Beispiel soll dies erläutern: Der klassische Werkvertrag setzt voraus, dass das abzuliefernde Werk hinreichend spezifiziert ist, dies ist jedoch bei agilen Methoden nicht möglich. Ein Dienstvertrag greift in aller Regel auch nicht, da für die einzelnen Sprints der Erfolg, d.h. die Erstellung funktionsfähiger Artefakte, geschuldet werden soll.
4.3 Hybride Methoden
Gerade im Zusammenspiel von internen und externen Projektmitarbeitern besteht das Bedürfnis nach Rechtssicherheit aufGHUeineQSeite und Projektdynamik auf der ande-
ren Seite. Dies lässt sich durch hybride Projektmethoden realisieren. Die Ausprägung dieser Mischform ist in verschiedenen Konstellationen denkbar:
1. Die Grundmethodik ist ein klassisches (z. B. Wasserfall-) Modell. Innerhalb ei- nes oder mehrerer Teilprojekte wird komplett die Projektmethodik zu einem agilen Verfahren gewechselt. Das Risiko bei diesem Wechsel ist eine Verant- wortungsdiffusion und finanzielle Risiken. Zum Beispiel: Die einzelnen Web- seiten müssen bezüglichLhrer Darstellung und Funktionalität spezifiziert wer- den. Für dieses abgegrenzte Teilprojekt wird die Methodik gewechselt. Es wird ein Dienstleistungsvertrag geschlossen. Die externen Berater werden in das Pro- jekt vollständig, wie eigene Mitarbeiter, integriert, und erstellen direkt in Sprints zusammen mit Vertretern der Fachabteilung die jeweiligen Webseiten als Click-Prototypen.
2. Die Grundmethodik ist ein agiles Verfahren. Innerhalb der Projektabwicklung entscheidet man sich zum Wechsel der Methodik: Anstelle eines oder mehrerer Sprints wird nun ein Wasserfallmodell eingesetzt. Bei dieser Art des Wechsels besteht das Risiko im Verlust der Anpassungsfähigkeit und Dynamik. Das lässt sich jedoch begrenzen, wenn die Umsetzung zeitnah möglich ist, wie es regel- mäßig bei reinen Beschaffungen der Fall ist, die Anpassungen entweder nur eingeschränkt notwendig bzw. möglich sind oder wenn diese zu einem späteren Zeitpunkt nachzuholen sind. Ein Beispiel ist die Auswahl und Beschaffung ei- nes Content Management Systems (CMS).
3. Eklektische Verfahren: Die Grundidee ist hierbei die jeweils geeigneten Metho- den im jeweiligen Projektkontext frei miteinander zu kombinieren, ohne sich für eine führenden Methode zu entscheiden. Hier besteht das Risiko darin, dass sich die verantwortlichen „Projektleiter“ verzetteln und das Projekt unkontrol- liert voranschreitet. Zudem besteht die Gefahr der Überforderung der Projekt- mitarbeiter.
In der vorliegenden Fallstudie wurde als Grundmethode die Wasserfall-Methode mit agilen Teilprojekten gewählt. Dies hat seinen Grund in der bis dahin mangelnden Erfah- rung im betroffenen Unternehmen mit agilen Methoden und andererseits mit dem frühen Scheitern der reinen Wasserfallmethode im Rahmen und Planungsphase.
5 Erfahrungen in der Anwendung einer hybriden Projektmethodik im Rahmen der Fallstudie
Das im Rahmen der Fallstudie geschilderte Projekt wurde erfolgreich umgesetzt, ein SOA-basiertes PIM wurde als technische Lösung vorgeschlagen [Li12]. Die Budget- überschreitung lag bei ca. 30%. Schwerer wog jedoch die erhebliche Verzögerung in der Umsetzung. Neben den rein technischen Gründen, führten auch Schwierigkeiten in der hybriden Projektmethodik zu Verzögerungen. Folgende Erfahrungswerte sind festzuhal- ten:
• Das zunächst angedachte Wasserfallmodell scheiterte mit der Erstellung des Pflichtenheftes. Dieses war im Verhältnis zur Projektgröße einerseits zu kom- plex, zu unvollständig und wurde letzten Endes durch die schnellen technischen Entwicklungen kurz vor der Fertigstellung überholt.
• Innerhalb des eigenen Unternehmens funktionierten agile Methoden sehr gut und verkürzten geplante Projektphasen deutlich (z. B. Webseitenanpassungen).
Insbesondere verbesserte sich die Kommunikation zwischen den Projektteil- nehmern (s. hierzu auch [Al97]) durch die enge räumliche Nähe.
• Sobald unternehmensübergreifend mit agilen Methoden gearbeitet wurde, führ- ten Moral Hazards zu vielfältigen Problemen: Ressourcen wurden nicht verein- barungsgemäß zur Verfügung gestellt, Arbeiten je nach Auftragslage ver- schleppt bzw. nicht in der notwendigen Qualität abgeliefert.
• Rahmenverträge in Kombination mit „Sprintverträge“ zeigten sich als angemes- sene Lösung zur Lösung der Moral Hazard-Problematik auf der einen Seite und erhielten auf der anderen Seite die Dynamik im Projekt. Hierzu wurden in den Rahmenverträgen, neben den allgemeinen Regeln, wie sie bei vielen Unter- nehmen üblich sind, auch Regeln festgelegt, die insbesondere auch für agile Methoden sinnvoll sind: Klare Verantwortungszuordnung und definierte Reak- tionszeiten, Schweigen als Annahme in bestimmten Fällen, Eskalationswege, Festlegung von Fehlerbehebungsroutinen, festschreiben der Vertragsart bei Sprints als Werkvertrag mit geschuldeten Erfolg. Abgrenzung zu Dienstleis- tungsverträgen, die nur im engen Rahmen zugelassen wurden. In den Sprintver- trägen wurden die Arbeitspakete beschrieben, die im nächsten Durchlauf reali- siert werden sollten.
6 Zusammenfassung und Ausblick
Die Realisierung eines Web-Relaunch stellt höchste Anforderungen sowohl in fachlicher Hinsicht, wie auch im Bereich des Projektmanagements. Der Autor hat die Erfahrung gemacht, dass die technischen Fragestellungen beherrschbar sind, jedoch die Entschei- dungsfindung im interkulturellen Projektumfeld die eigentliche Herausforderung dar- stellt. Die Grundidee agiler Projektmethodik, mit schnellen kleinen Schritten sich dem Ziel zu nähern, findet gerade bei solchen Projekten ein gutes Anwendungsfeld. Anderer- seits ist in der unternehmensübergreifenden Zusammenarbeit auf die Beherrschung der Moral Hazard-Problematik zu achten. Diese ist in aller Regel nur durch ein angepasstes, striktes Vertragswerk sicherzustellen.
Literaturverzeichnis
[Al97] Allen, T. J.: Architecture and Communication: Among Product Development Engineers, Cambridge, 1997, S. 165-197.
[Eu06] E. R. Europäisches Parlament, Richtlinie 2006/42/EG; Maschinenrichtlinie, 2006.
[Ho80] Hofstede, G.: Culture's Consequences, London, 1980.
[Ho93] Hofstede, G.: Interkulturelle Zusammenarbeit, Wiesbaden, 1993.
[Kl11] North, K.: Wissensorientierte Unternehmensführung, 5. Auflage, Hrsg., Springer Gabler Verlag, Heidelberg, 2011.
[Li12] Liebig, H. C.: Referenzmodell eines internationalen Produktinformationsmanagements, PIK, S. 183-186, 2012.
[Sc97] Schwaber, K.: Scrum Development Process, OOPSLA Business Object Design and Implementation Workshop, London, 1997.
[VBW12] von Stetten, A.; Beimborn, D.; Weitzel, T.: „Auswirkungen kulturspezifischer Verhal- tensmuster auf das Sozialkapital in multinationalen IT-Projektteams - Ein Fallstudienan- satz.,“ Wirtschaftsinformatik, Bd. 54, S. 135-151, 2012.
