Diplomarbeit Scheipl

Fachhochschul-Studiengang
Projektmanagement und Organisation

Kennzahl des Fachhochschul-Studienganges: 0388
Diplomarbeit
Zur Erlangung des akademischen Grades: Master of Arts in Business (MA)
Titel der Diplomarbeit:
Arbeiten in virtuellen Projektmanagement-Teams Techniken und Tools zur Untersttzung verteilter Projektorganisationen
Fachbereich: Eingereicht von: Personenkennzeichen: Anschrift: Begutachter: Projektmanagement Peter Scheipl, MSc. BSc. 0910388040 Mariahilferstrae 128/10, 1070 Wien Prof. (FH) Mag. Dr. Gerhard Ortner, zPM
Erhalter:
Fachhochschule des BFI Wien GmbH Wohlmutstrae 22 1020 Wien
Wien, 19.04.2011
Ich versichere, dass ich die Regeln des wissenschaftlichen Arbeitens eingehalten habe, insbesondere, dass ich die Diplomarbeit selbstndig verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt und mich auch sonst keiner unerlaubten Hilfe bedient habe. Ich versichere weiters, dass ich diese Diplomarbeit bisher weder im Inland noch im Ausland in irgendeiner Form als Prfungsarbeit vorgelegt habe.
Mir ist bewusst, dass auch nach positiver Beurteilung der Diplomarbeit die Aufdeckung eines Verstoes gegen die Regeln des wissenschaftlichen Arbeitens (insbesondere bei Vorliegen eines Plagiats) die Einleitung eines Verfahrens zur Nichtigerklrung der Beurteilung sowie des akademischen Grades zur Folge hat.
________________ Datum
___________________ Unterschrift
Die vorliegende Diplomarbeit wurde vom/von der Begutachter/in mit der Note
_________________________
beurteilt.
Abstract
Sowohl Projektmanagement als auch verteiltes Arbeiten sind mittlerweile allgegenwrtig und aus der professionellen Arbeitswelt nicht mehr wegzudenken. Dieses Arbeiten in virtuellen Projektteams fhrt offensichtlich zu Problemen die in herkmmliche Projektteams kaum oder nur vermindert auftreten. In dieser Arbeit sollen daher diese Unterschiede hervorgehoben werden und hierfr einerseits methodische, andererseits technische Lsungsanstze angeboten werden um diese Probleme vorzubeugen oder sie aktiv zu lsen. Ziel dieser Arbeit ist es daher die technischen und methodischen Mglichkeiten zunchst zu beschreiben und zu erklren um sie im spteren Verlauf der Arbeit dann auf ihre Wirksamkeit hinsichtlich der Lsung der zuvor identifizierten Probleme zu beurteilen.
Project management as well as dispersed working are terms that are omnipresent nowadays and it is impossible to think of a professional world without them. This approach of working together in virtual project teams obviously leads into problems that are not observed or have less impact on conventional project teams. This thesis shall therefore point out these principal differences and offer on the one hand technical on the other hand methodical solutions to prevent these problems or even actively help to solve them. Therefore, aim of this thesis shall be first of all to describe und explain technical as well as methodical possibilities to later in this work use them in order to find out their effectiveness when trying to solve problems identified beforehand.
0910388040 Peter Scheipl
Inhaltsverzeichnis
1 Einleitung ........................................................................................................... 1 1.1 Prmissen .................................................................................................... 2 1.2 Formulierung der Forschungsfrage .............................................................. 3 Projektmanagementrollen ................................................................................ 4 2.1 ProjektleiterIn (ProjektmanagerIn) ................................................................ 4 2.2 Projektteam .................................................................................................. 6 2.3 Projektorganisation....................................................................................... 9 2.4 Weitere Projektrollen ...................................................................................10 2.4.1 ProjektauftraggeberIn ...........................................................................10 2.4.2 Projektlenkungsausschuss, Steering Committee .................................11 2.4.3 ProjektcontrollerIn ................................................................................12 2.5 Projektmanagementtools .............................................................................14 Virtualitt ...........................................................................................................15 3.1 Begriffsdefinition ..........................................................................................15 3.2 Abgrenzung .................................................................................................17 3.3 ProjektleiterIn ..............................................................................................18 3.4 Virtuelle Projektteams .................................................................................19 3.5 Virtuelle Projektorganisation ........................................................................22 3.6 ProjektcontrollerIn .......................................................................................23 3.7 Steering Committee.....................................................................................24 3.8 ProjektauftraggeberIn ..................................................................................24 3.9 Problemstellungen.......................................................................................25 Tools ..................................................................................................................26 4.1 Projektmanagementsoftware .......................................................................27 4.1.1 Primavera .............................................................................................37 4.1.2 Project.net ............................................................................................40 4.2 Kollaborations-Tools....................................................................................42 4.2.1 Google Docs ........................................................................................52 4.2.2 Doodle ..................................................................................................54 4.2.3 TalkAndWrite........................................................................................57 4.3 Kommunikations-Tools ................................................................................59 4.3.1 Skype ...................................................................................................67 4.3.2 Pidgin ...................................................................................................68 4.3.3 Thunderbird ..........................................................................................69 Projektphasen ...................................................................................................70 5.1 Projektstartphase ........................................................................................71 5.1.1 Projektentstehung und Projektumfeld (Projektvorlauf) .........................71 5.1.2 Projektbeauftragung und startprozess ...............................................73 5.1.3 Aufbau der Projektorganisation ............................................................76 I
5.1.4 Aufbau von Projektteams .....................................................................77 5.2 Projektplanungs- und -ausfhrungsphase ...................................................81 5.2.1 Gestaltung des Projektumfelds ............................................................81 5.2.2 Projektplanung .....................................................................................82 5.2.3 Gestaltung der Projektorganisation ......................................................84 5.2.4 Gestaltung der Teamarbeit ..................................................................86 5.3 Koordinations- und nderungsphasen ........................................................89 5.3.1 Umfeldnderungen...............................................................................89 5.3.2 Projektsteuerung ..................................................................................91 5.3.3 Projektorganisation ..............................................................................93 5.3.4 Projektteamarbeit .................................................................................94 5.4 Projektabschlussphase ...............................................................................98 5.4.1 Abschluss von Umfeldbeziehungen .....................................................98 5.4.2 Projektauswertung .............................................................................100 5.4.3 Auflsung der Projektorganisation .....................................................100 5.4.4 Auflsung des Projektteams ..............................................................101 6 7 Conclusio ........................................................................................................103 Literaturverzeichnis .......................................................................................105
II
Darstellungsverzeichnis
Nr. Bezeichnung Seite
Abbildung 1: interner Projektauftraggeber .......................................................... 10 Abbildung 2: Lenkungsausschuss ...................................................................... 12 Abbildung 3: Allen-Kurve .................................................................................... 21 Abbildung 4: Worldwide Project and Portfolio Management Software Revenue Estimates for 2009 (Millions of U.S.Dollars) ......................................................... 37 Abbildung 5: Primavera Project Management..................................................... 38 Abbildung 6: Primavera Cost Management ........................................................ 39 Abbildung 7: Project.net Time Management ....................................................... 40 Abbildung 8: Project.net Project Workplan.......................................................... 41 Abbildung 9: TalkAndWrite ................................................................................. 48 Abbildung 10: Gemeinsamer Online Kalender .................................................... 50 Abbildung 11: Google Drawings ......................................................................... 52 Abbildung 12: Google Drawings Chat ................................................................. 53 Abbildung 13: leerer Doodle Termin ................................................................... 54 Abbildung 14: befllter Doodle Termin ................................................................ 55 Abbildung 15: Doodle Terminkalender ................................................................ 55 Abbildung 16: TalkAndWrite ............................................................................... 57 Abbildung 17: Relative Richness of different media types according to four criteria ............................................................................................................................. 60 Abbildung 18: Media Richness nach Kohlhauser ................................................ 61 Abbildung 19: Numerical Values used to rank media types ................................ 61 Abbildung 20: Hierarchy of media richness ........................................................ 62 Abbildung 21: Skype ........................................................................................... 67 Abbildung 22: Pidgin ........................................................................................... 68 Abbildung 23: Mozilla Thunderbird ..................................................................... 69 Abbildung 24: Potential project success factors .................................................. 74 Abbildung 25: Top 10 potential problems of distributed projects ......................... 74 Abbildung 26: Potential project success factors .................................................. 82 Abbildung 27: Entscheidungsstile ....................................................................... 88 Abbildung 28: Moderations- und Visualisierungsmittel ....................................... 95
III
Abkrzungsverzeichnis
ICB IP IPMA JSON MbO PAP PC PMS SaaS SMS SOAP VOIP XML IPMA Competence Baseline Internet Protocol International Project Management Association Java Script Object Notation Management by Objective Projektablaufplan Personal Computer Projekt Management Software Software as a Service Short Message System Simple Object Access Protocol Voice over IP Extensible Markup Language
IV
Einleitung
Globalisierung, Internationalisierung und Virtualisierung sind ebenso wie Projektmanagement, Prozessmanagement oder Wissensmanagement keine Begriffe mehr die nur einem ausgewhlten Kreis von Wissenden vorenthalten sind oder nur vage als Gedankenexperiment vorhanden sind. Es sind Begriffe die im Middle- und Topmanagement zum praktischen Handwerkzeug gehren und tglich verwendet werden. Mittlerweile ist Projektmanagement beinahe Grundvoraussetzung fr einen guten Manager oder eine gute Managerin und das Verteilen von Teams oder Outsourcen von Prozessschritten schreckt kaum mehr Firmen ab. Umso alltglicher und gebruchlicher diese Konzepte aber werden, umso genauer muss betrachtet werden wie diese umgesetzt werden und welche Methoden und Techniken dazu angewendet werden. Gerade im Projektmanagement, wo sehr viel soziale Kompetenz gefragt ist, sowohl von Mitarbeitern und Mitarbeiterinnen als auch von Fhrungskrften, ist es wichtig, dass die richtigen Personen mit den richtigen Fhigkeiten und den richtigen Werkzeugen am richtigen Ort sind. Diesen Tools und Techniken des virtuellen Projektmanagements soll sich diese Arbeit widmen. Es sollen zunchst grundlegende Begriffe des herkmmlichen Projektmanagements erlutert und fr diese Arbeit definiert und abgegrenzt werden. In einem nchsten Schritt sollen diese Begriffe und Rollen hinsichtlich des virtuellen Projektmanagement nher betrachtet und kritisch hinterfragt werden. Es sollen hier auch Probleme und Spannungsfelder identifiziert und beschrieben werden, um in einem nchsten Schritt, mit Hilfe von Tools und Techniken mgliche Lsungsvorschlge bieten zu knnen. Diese Tools sollen zunchst erklrt und besprochen werden, um sie dann in einem letzten Schritt auf die Probleme des Projektmanagements, bezogen auf die Virtualitt auf ihre Ntzlichkeit hin zu untersuchen. Hierzu wurde in dieser Arbeit nicht nur eine ausfhrliche Recherche der aktuellen und in diesen Gebieten mageblichen Literatur durchgefhrt, sondern vor allem auch versucht die aktuellsten Entwicklungen in diesem Bereich durch eine grndliche und umfassende Internetrecherche darzustellen.
Gerade in einem sich sehr schnell entwickelnden Bereich wie der des Projektmanagements und gerade der des Managements virtueller Teams und virtueller Teamarbeit ist es wesentlich aktuelle Erkenntnisse in eine umfassende Betrachtung mit einflieen zu lassen. Patzak / Rattay sagen hierzu beispielsweise Sich verndernde Rahmenbedingungen, wie krzere Inoovationsund Produktlebenszyklen, komplexere Aufgabenstellungen, technologische Entwicklungsschbe und der Wunsch nach mehr Kundennhe, werden als Anforderungen der Umwelt an Unternehmen sprbar und verlangen von diesen ein hohes Ausma an Flexibilitt und Anpassungsfhigkeit.1 Dies beantwortet also auch die Frage nach den angesprochenen Personen. Prinzipiell werden hier jegliche Unternehmungen angesprochen die kundenorientiert am Markt agieren. Es soll aber auch Firmen, Personen und Organisationen helfen die sich mit der Virtualisierung ihres Projektmanagements und den daraus resultierenden Problemen konfrontiert sehen.
1.1
Prmissen
Im Folgenden werden die Annahmen die dieser Arbeit zugrunde liegen dargelegt und erklrt. Die Annahmen dienen einerseits der Abgrenzung und andererseits der nheren Spezifikation des Umfangs.
Folgende Annahmen wurden getroffen: Im virtuellen Projektmanagement und beim Arbeiten mit virtuellen Projektorganisationen sind vor allem dort Methoden und Tools notwendig wo sich virtuelle Projektteams von normalen Projektteams unterscheiden. Dies betrifft vorrangig Situationen in denen direkt persnlicher Kontakt zwischen den Projektmitgliedern notwendig ist oder unter normalen Umstnden notwendig wre. Im Gegensatz dazu unterscheiden sich die Methoden des Projektmanagements virtueller Projektteams kaum oder gar nicht von Methoden im nor-
Patzak / Rattay (2009), S. 63
malen Projektmanagement in Phasen oder bei Situationen die kaum oder keine persnliche Interaktion der Projektmitglieder erfordert. Aufgrund der zuvor getroffenen Prmissen lsst sich schlieen, dass mit groer Wahrscheinlichkeit auch die Tools des virtuellen Projektmanagements hauptschlich die Probleme der persnlichen Interaktionen zwischen den Projektmitgliedern betreffen, da hier die grten Problemfaktoren vermutet werden knnen.
1.2
Formulierung der Forschungsfrage
Auf Grund der zuvor getroffenen Prmissen sollen daher in dieser Arbeit folgende Forschungsfragen versucht werden im Zuge dieser Arbeit zu beantworten: 1. Welche technischen Mglichkeiten stehen im virtuellen Projektmanagement zur Verfgung und wie knnen diese zur prventiven Verhinderung oder aktiven Lsung von Problemen eingesetzt werden? a. Wie knnen technische Hilfsmittel bei der Untersttzung von virtuellem Projektmanagement kategorisiert und bewertet werden? b. Fr welche Problemstellungen sind technische Tools im virtuellen Projektmanagement am besten geeignet?
2. Welche Methodiken und Vorgehensweisen stehen der Projektleitung, neben dem Einsatz von technischen Tools, noch zur Verfgung? a. In welchen Projektphasen muss vermehrt mit Komplikationen auf Grund der Virtualitt gerechnet werden und wie knnen diese behoben werden?
Projektmanagementrollen
Zunchst sollen die wesentlichen Grundbegriffe des Projektmanagements fr diese Arbeit abgegrenzt und gegebenenfalls nher erlutert werden. Hierbei soll auch auf die in Punkt 1.11 aufgestellten Prmissen Rcksicht genommen werden. Die Grundbestandteile des Projektmanagements sollen hier also nicht nur beschrieben und abgegrenzt werden, es soll auch errtert werden inwiefern sie unter dem Gesichtspunkt der Virtualitt (siehe Kapitel 3) als wesentlich zu befinden sind. Die jeweiligen virtuellen Komponenten (z.B. virtuelles Projektteam, virtuelle Projektorganisation, etc.) sollen ebenfalls in Kapitel 3 weiter diskutiert und erlutert werden.
2.1
ProjektleiterIn (ProjektmanagerIn)
Die Rolle des Projektleiters/der Projektleiterin als Fhrungskraft und Spitze des Projektteams ist auer Frage eine der wesentlichsten Rollen im Projektmanagement. Nicht nur fllt ihr ein wesentlicher Teil der Arbeit zu, es ist auch anzunehmen, dass bei einer Virtualisierung oder Dispersion des Projektteams zustzliche Aufgaben vom Projektleiter bewltigt werden mssen. Patzak / Rattay identifizieren unter anderem folgende Aufgaben des Projektleiters beziehungsweise der Projektleiterin: Zusammensetzung und Entwicklung eines schlagkrftigen Teams Schaffung von Rahmenbedingungen, die eine erfolgreiche Zusammenarbeit im Team ermglichen Fhrung der Projektteams und Leitung der Projektteamsitzungen Gestaltung der Beziehung zu wichtigen Umfeldgruppen/Kunden2
Ebenfalls regen Caupin et. al. folgende Verhaltenskompetenzen als wesentlich an: Fhrung, Engagement und Motivation, Selbstkontrolle, Durchsetzungskraft, Entspannung und Stressbewltigung, Offenheit, Kreativitt, Ergebnisorientierung, Effizienz, Beratung, Verhandlungen, Konflikte und Krisen, Verlsslichkeit, Wertschtzung, Ethik3.
Diese Kriterien lassen eindeutig erkennen, dass persnliche Interaktionen mit dem Projektteam und anderen, ins Projekt Involvierten, zu den Kernaufgaben eines Projektleiters oder Projektleiterin gehren (z.B.: Fhrung, Beratung, Verhandlung, Konflikte und Krisen, etc.). Sowohl die Fhrung des Teams, als auch dessen Koordination, sowie viele Manahmen, Aktionen oder Reaktionen sind hauptschlich auf direkte Kontakte mit anderen zurckzufhren, oder eben dieser Kontakt bildet einen Hauptbestandteil der Aktion. Es liegt daher nahe, dass eine Virtualisierung oder Dispersion des Projektes, des Projektteams oder der Projektorganisation wesentlichen Einfluss auf die Handlungsweise der Projektleitung nehmen werden, da sie dadurch in der Mglichkeit der persnlichen Interaktion und direkten Kommunikation mit dem Projektmitgliedern zum Teil massiv beschrnkt wird.
Vgl. Caupin et.al. (2006), S. 43
2.2
Projektteam
Bei der Auswahl des Projektteams geht es natrlich zunchst primr um die Auswahl der richtigen Personen. Es soll zunchst gewhrleistet sein, dass die, zur Durchfhrung des Projektes und Erreichung der Projektziele, bentigten Fhigkeiten in Form von Wissen und Fhigkeiten der wesentlichen Teammitglieder, vorhanden sind. Es ist also zunchst wichtig die richtigen Personen auszuwhlen.4 Neben der Auswahl der richtigen Personen, stellt aber das Formen des Teams, also das Zusammenbringen der einzelnen Personen zu einer Gemeinschaft eine ganz spezielle Herausforderung dar. Die Teammitglieder eines Projektteams sollen demnach nicht als Einzelpersonen Leistung erbringen, sondern als Team Probleme lsen und Aufgaben bewltigen. Dazu ist es notwendig einen Entwicklungsprozess zu durchlaufen wie ihn unter anderem Tuckman5 beschrieben hat. Er regt die folgenden, gut bekannten, Phasen in der Teamentwicklung an: 1. Forming, 2. Storming, 3. Norming, 4. Performing, 5. Adjourning.6 Auch Patzak / Rattay7 erwhnen diese Phasen und beschreiben ihre Wichtigkeit fr die Teamentwicklung in Projektteams. Von groer Bedeutung sind hier vor allem die jeweiligen Ausprgungen der Phasen.
4 5 6 7
Vgl. Patzak / Rattay (2009), S. 180 Tuckman (1965) Vgl. Tuckman (1965), S. 384-399 Patzak / Rattay (2009)
Diese sind fr die Teammitglieder unter anderem 1. Forming a. Hoher Orientierungsbedarf b. Beginn des gegenseitigen Abtastens zwischen den Mitgliedern8 2. Storming a. Herstellung der natrlichen Rangordnung b. Erste Cliquenbildung und Konfrontation zwischen einzelnen Personen9 3. Norming a. Entwicklung von Gruppenzusammenhalt [] b. Gegenseitige Akzeptanz und Sorge dafr, dass der Fortbestand der Gruppe gewhrleistet wird10 4. Performing a. Nachrang persnlicher Probleme untereinander gegenber der Arbeit b. Tragfhige Vertrauensbasis c. Selbstverstndlicher Beitrag jedes Teammitglieds zum Gesamterfolg11 5. Adjourning a. Auflsung des Teams am Ende des Projekts b. Wechsel der Teammitglieder in ihre angestammten Positionen, bernahme anderer Projekte12 Hieraus lassen sich wesentliche Schritte zur erfolgreichen Gestaltung eines Projektteams ableiten, aber auch mgliche Gefahrenquellen identifizieren, zieht man die Prmissen aus Punkt 1.1 hierbei in Betracht. Betrachtet man zunchst die Punkte Forming, Storming und Norming so stellt man fest, dass in diesen Punkten persnliche Interaktionen eine wesentliche Rolle spielen.
8 9
Patzak / Rattay (2009), S. 186 f. ebd. ebd. ebd. ebd.
10 11 12
So sind Punkte wie die Herstellung einer natrlichen Rangordnung13, die Entwicklung von Gruppenzusammenhalt []14 und eine erste Cliquenbildung und Konfrontation zwischen einzelnen Personen15 wesentliche Bestandteile dieser Phasen. Diese sind ausschlaggebend um im spteren Verlauf sicherzustellen, dass das Projektteam auch richtig performed.
Vorallem in der Performing-Phase stehen nmlich Punkte wie Nachrang persnlicher Probleme untereinander gegenber der Arbeit und Selbstverstndlicher Beitrag jedes Teammitglieds zum Gesamterfolg die zeigen, dass in dieser Phase der Hauptteil des Projekts abgearbeitet wird. Das heit das in dieser Phase das Projektteam am produktivsten ist, was im Umkehrschluss bedeutet, dass ein Scheitern in den vorherigen Phasen mit groer Wahrscheinlichkeit eine schlechte Performance des Teams im spteren Projektverlauf zur Folge haben wird. Dieser Punkt soll in Kapitel 3 unter Einbezug der in Kapitel 1.1 aufgestellten Prmissen noch ausgebaut werden.
13 14 15
Patzak / Rattay (2009), S. 186 ebd. ebd.
2.3
Projektorganisation
Des Weiteren stellt die Projektorganisation einen wesentlichen Bestandteil des Projektmanagements dar. Hier wird bestimmt in welchem Rahmen das Projekt sich bewegen soll und welche Umgebungsvariablen dafr notwendig sind. So beschreiben Patzak / Rattay die Projektorganisation zum Beispiel als [] jene Regeln, Werte und Normen [] die dazu ntig sind, die Zusammenarbeit aller am Projekt Beteiligten mglichst effizient zu gestalten.16 Die ICB17 kommt im Kompetenzpunkt Projektorganisation zu einer hnlichen Beschreibung, in der die Projektorganisation als bestehend aus einer Gruppe von Menschen und der dazugehrigen Infrastruktur, fr die eine Vereinbarung bezglich Autoritt, Beziehungen und Zustndigkeiten unter Ausrichtung auf die Geschfts- und Funktionsprozesse getroffen wurde.18 beschrieben wird. Sie besagt des Weiteren, dass dieses Kompetenzelement die Entwicklung und Aufrechterhaltung von geeigneten Funktionen, Organisationsstrukturen, Zustndigkeiten und Fhigkeiten fr das Projekt19 umfasst. Auch wenn es sich hier also eindeutig um ein wesentliches Element des Projektmanagements handelt, so ist unter der Betrachtung der Prmissen aus Punkt 1.1 hier wesentlich weniger Spannungspotential zu erkennen. Zwar werden auch hier persnliche Interaktionen als wichtig erachtet, der wesentliche Bestandteil besteht aber im zur Verfgung stellen von Infrastruktur und dem entwickeln von Organisationstrukturen und Zustndigkeiten.
16 17 18 19
Patzak / Rattay (2009), S. 143 ICB - IPMA Competence Baseline Caupin et.al. (2006), S. 64 ebd.
2.4
Weitere Projektrollen
Neben Projektleiter und Projektteam kennt das Projektmanagement natrlich noch weitere wichtige Rollen wie Projektauftraggeber, Lenkungs- oder Steuerungsausschsse oder Projektcontroller. Im Folgenden sollen diese Rollen kurz besprochen werden und ihre Relevanz fr diese Arbeit unter Bercksichtigung der Prmissen aus Punkt 1.1 errtert werden.
2.4.1 ProjektauftraggeberIn
Whrend die Literatur oft zwischen internem Projektauftraggeber/interner Projektauftraggeberin und externem Projektauftraggeber/externer Projektauftraggeberin unterscheidet, soll in dieser Arbeit die Rolle des Projektauftraggebers oder der Projektauftraggeberin etwas allgemeiner betrachtet werden. Im Allgemeinen ist damit jene Rolle gemeint, die das Projekt beauftragt, es aber spter auch abnimmt und allgemein gesagt am (nachhaltigen) Erfolg des Projektes interessiert ist.
Abbildung 1: interner Projektauftraggeber
20
Auch werden von dieser Rolle in der Regel strategische Entscheidungen getroffen was das Projekt betrifft. Im Zweifelsfall kann der Projektauftraggeber oder die Projektauftraggeberin auch als letzte Eskalationsstufe gesehen werden, beziehungsweise als letztgltiger Entscheider.21
20 21
Patzak / Rattay (2009), S. 147 Vgl. Patzak / Rattay (2009), S. 147 f.
10
Organisatorisch ist der interne Projektauftraggeber oder die Auftraggeberin meist im Top-Management angesiedelt (siehe Abbildung 1) und von dem eigentlichen Projektteam und der Projektleitung organisatorisch eher entkoppelt. Hierdurch lsst sich vermuten, dass unter Rcksichtnahem auf die Prmissen in Punkt 1.1, der Projektauftraggeber oder Auftraggeberin (sowohl intern als auch extern) zwar im Projektmanagement eine wesentliche Rolle spielt, in dieser Arbeit aber eher von geringerer Bedeutung sein wird, da seine oder ihre Rolle bereits im herkmmlichen Projektmanagement von der eigentlichen Projektarbeit sehr abgekoppelt ist. Dies wird aber in Kapitel 3 noch weiter ausgefhrt.
2.4.2 Projektlenkungsausschuss, Steering Committee

hnlich wie beim Projektauftraggeber beziehungsweise der Auftraggeberin, handelt es sich bei den Lenkungsausschssen um wichtige Komponenten des Projektmanagements, in dieser Arbeit sind sie aber auf Grund der getroffenen Annahmen aber eher von geringer Bedeutung. Beim Lenkungsausschuss handelt es sich demnach meist um eine organisatorische Ebene zwischen Projektauftraggeber oder Auftraggeberin und Projektleitung Whrend der Projektauftraggeber/die Projektauftraggeberin eher die strategischen Ziele des Projekts verfolgt, der Projektleiter oder die Projektleiterin hingegen die operativen Ziele, versucht der Lenkungsausschuss meist die strategischen Ziele des Projektauftraggebers/der Projektauftraggeberin und die fachlichen Anforderungen an die Projektziele im Auge zu halten umso, gemeinsam mit den operativen Zielen der Projektleitung, einen idealen Projektfortschritt zu gewhrleisten.22 Die Interaktion besteht also eher zwischen Projektauftraggeber oder Projektauftraggeberin und Lenkungsausschuss, beziehungsweise zwischen Projektleitung und Lenkungsausschuss.
22
Vgl. Patzak / Rattay (2009), S. 152 f.
11
In Abbildung 2 ist zu sehen, dass auch hier organisatorisch keine enge Bindung zwischen dem tatschlich operativen Projektgeschehen und dem Lenkungsausschuss besteht.
Abbildung 2: Lenkungsausschuss
23
Auch diese Rolle soll in Kapitel 3 noch nher beleuchtet werden.
2.4.3 ProjektcontrollerIn
Der Projektcontroller beziehungsweise die Projektcontrollerin, als die letzte Projektrolle, ist prinzipiell von zwei Seiten zu betrachten. Seine beziehungsweise ihre Aufgaben beschrnken sich einerseits auf das Dokumentieren und das Berichtswesen, das regelmige Informieren der Projektstakeholder ber den Projektstatus oder die Untersttzung bei Projektplanungs und steuerungsaufgaben, andererseits aber auch die Mitgestaltung wichtiger Prozesse.24 Unter der Betrachtung der getroffenen Prmissen, kann diese Rolle also zweigeteilt betrachtet werden, einerseits die Dokumentationsaufgabe, die meist ohne interpersonellen Kontakten passiert, andererseits die Mitgestaltung wichtiger Prozesse, bei derer die Interaktion mit dem Teammitgliedern eine magebliche Rolle spielt.
23 24
Patzak / Rattay (2009), S. 153 Vgl. Patzak / Rattay (2009), S. 166 ff.
12
Patzak / Rattay schreiben hier ber die Rolle des Projektcontrollers, dass die Person die diese Funktion inne hat ein hohes Ma an sozialen Fhigkeiten25 erfordert, wie unter anderem das Wissen ber Moderationstechniken, Kreativittstechniken, Gruppenprozesse und, den Umgang mit Teams.26
Darber hinaus nimmt die Bedeutung des situationsadquaten Verhaltens im Umgang mit dem Team, dem Projektleiter und dem Auftraggeber (Sozialkompetenz) massiv zu.27 Das bedeutet natrlich, dass die Funktionen hinsichtlich ihrer Relevanz die Prmissen betreffend unterschiedlich betrachtet werden mssen. Einerseits hat diese Rolle Funktionen inne deren Relevanz hinsichtlich der Prmissen eher gering ist, was Dokumentations- oder Informationsttigkeiten betrifft, andererseits erfordert diese Rolle in bestimmten Situationen ein hohes Ma an Interaktion mit Teammitgliedern, Projektleitung oder Projektauftraggeber beziehungsweise Auftraggeberin, was wiederum von wesentlicher Bedeutung in dieser Arbeit ist. Auch dieser Punkt soll in Kapitel 3 weiter ausgefhrt werden.
25 26 27
13
2.5
Projektmanagementtools
Ein weiterer wesentlicher Bestandteil von Projektmanagement ist mittlerweile Projektmanagementsoftware. Fr Patzak / Rattay steht beim Einsatz von Projektmanagementsoftware die Untersttzung in der tglichen Arbeit in Projekten im Vordergrund28. Ebenfalls sind sie der Meinung, Projektmanagementsoftware zielt mir ihren Funktionen auf die unterschiedlichsten Anforderungen ab, die durch Projektmanagement entstehen.29 Auch bei der Frage auf welche Zielgruppen der Einsatz ausgerichtet gibt es eine klare Vorstellung. Diese sind unter anderem: Projektleitung, Projektcontroller oder Projektcontrollerin, Teammitglieder und Projektauftraggeber beziehungsweise Auftraggeberin.30
also unter anderem die Rollen, die in dieser Arbeit in Hinblick auf die zustzlichen Probleme durch die Virtualisierung als wesentlich erscheinen. Neben Projektmanagementsoftware sollen aber vor allem auch Tools untersucht werden, die den Problemstellungen aus Kapitel 3 Lsungen anbieten, das heit neben klassischer Projektmanagementsoftware auch Software zur Kommunikation, Kollaboration und Vernetzung der angesprochenen Rollen. Dieser Punkt wird vor allem in Kapitel 4 detailliert ausgefhrt. Zusammenfassend kann hier festgehalten werden, dass nicht alle Bestandteile des Projektmanagements die als wesentlich erachtet werden in Bezug auf die Prmissen aus Punkt 1.1 ebenfalls als wesentlich erscheinen. In dieser Arbeit sollen vor allem die Komponenten nher betrachtet werden und von Bedeutung sein, die sich in virtuellen Teams von herkmmlichen Teams wesentlich unterscheiden. Diese Unterschiede sollen vor allem in den Kapiteln 3 und 5 herausgearbeitet und besprochen werden.
28 29 30
14
Virtualitt
Der Begriff der Virtualitt bildet einen wesentlichen Bestandteil dieser Arbeit und soll im Folgenden daher nher erlutert werden. Ebenfalls sollen in diesem Punkt die Prmissen aus Kapitel 1.1 untermauert werden. Dieses Kapitel soll des Weiteren zur Ausarbeitung der wesentlichen Unterschiede zwischen herkmmlichem und virtuellem Projektmanagement sowie herkmmlichen und virtuellen Teams dienen um spter die wesentlichen Probleme von virtuellen Arbeitsgruppen oder Teams benennen zu knnen. Dies dient im spteren Verlauf der Arbeit dazu, diese Problemstellung auf die jeweiligen Bereiche des Projektmanagements umlegen zu knnen.
3.1
Begriffsdefinition
Um Begriffe wie virtuelles Projektmanagement und virtuelle Projektteams nher betrachten zu knnen muss zuerst der Begriff der Virtualitt nher spezifiziert werden. Hierzu gibt es in der Literatur bereits eine Vielzahl von Auffassungen und Definitionen. So beschreiben Khazanchi und Zigurs den Begriff zum Beispiel als [] typically defined in terms of dispersion.31 was bereits erkennen lsst das Virtualitt meist etwas mit Verteilung zu tun hat. Sie schreiben ber den Begriff weiter This view describes virtual entities as being dispersed on a variety of dimensions, most often geographically and in time, but also on such other dimensions as organizational affiliation, culture, continuity of team membership, experience, availability and variability in technology.32 Es lsst sich also spezifizieren, dass diese Dispersion nicht nur rtlich und zeitlich stattfinden kann, sondern auch in der Organisation selbst, der Kultur oder der Verfgbarkeit.
31 32
Khazanchi / Zigurs (2005), S. 3 ebd.
15
hnlich dieser Definition benennt auch Grunewald den Begriff als [] der Mglichkeit nach vorhanden sein, fluide, temporr, Grenzen und Verfahren berschreitend [] ohne im physikalischen Sinne wirklich existieren zu mssen.33 Grunewald geht sogar einen Schritt weiter und meint: Virtualitt entsteht erst durch konsequente Nutzung moderner I.u.K.Technologien bei rumlich und/oder zeitlich de-lokalisierten Arbeitsgruppen/Organisationen in a) lokalen (LAN= Local Area Network), b) organisatorischen (Intranet) und c) globalen Computernetzen (Internet).34 Das bedeutet, er sieht Virtualitt zwar hnlich Khazanchi und Zigurs als dispersiv was Zeit und geographische rtlichkeit betrifft, ist aber darber hinaus der Meinung, dass diese erst unter Einsatz moderner Telekommunikationstechnologien wirklich zustande kommen kann.
Kohlhauser erweitert diesen Begriff noch um Schlagworte wie nicht echt, nicht in Wirklichkeit vorhanden []35. Auch Dostal regt hier Begriffe wie [] nicht tatschlich, nur scheinbar oder nur gedacht []36 an. Mit Hilfe dieser Definitionen lassen sich im Weiteren auch die wesentlichen Unterschiede zwischen herkmmlichen Projekten und Teams und virtuellen Projekten und Teams ableiten. Diese werden in Punkt 0 nher erlutert.
33 34 35 36
Grunewald (2001), S. 31 Grunewald (2001), S. 31 Kohlhauser (2007), S. 4 Dostal (2007), S. 28
16
3.2
Abgrenzung
Aus den bisherigen Kenntnissen lassen sich also im Folgenden die wesentlichen Abgrenzungen in Bezug auf Virtualitt treffen, beziehungsweise folgende wesentlichen Merkmale beschreiben: Virtualitt im Projektmanagement wirkt sich vor allem hinsichtlich folgender Punkte mageblich aus: Geographische Dispersion; Zeitunterschiede (verschiedene Arbeitszeiten, verschiedene Zeitzonen, etc.); Organisatorische Unterschiede (z.B.: unterschiedliche Abteilung im Unternehmen, unterschiedliche Zweigstelle, unterschiedliche Unternehmen in derselben Unternehmensgruppe, etc.); Technologische Unterschiede.37
Hier soll noch ein weiterer Punkt angefgt werden der sich aus den vorhergehenden Problemen ergibt. Das Hauptproblem das sich durch die vorhergenannten Unterschiede zum herkmmlichen Projektmanagement ergibt ist das Fehlen von Face-to-Face-Zeit, dem direkten persnlichen Kontakt der einzelnen Beteiligten. Dieses Fehlen impliziert weiters, dass dadurch erhebliche Vertrauensprobleme unter den Beteiligten entstehen knnen, die zu massiven Behinderungen der Zusammenarbeit fhren knnen.38 Diese Unterschiede sollen im Weiteren in Bezug auf die in Kapitel 2 beschriebenen wesentlichen Rollen des Projektmanagements weiter besprochen werden um dadurch schlussendlich in Kapitel 3.9 die daraus resultierenden Problemstellungen besprechen zu knnen.
37 38
Vgl. Khazanchi / Zigurs (2005), S. 3 Vgl. Grunewald (2001), S. 33
17
3.3
ProjektleiterIn
Gollubits schreibt ber die Herausforderungen eines Projektleiters in virtuellen Projektteams The challenges that virtual team leaders face are immense. Many report that they feel as if they are the glue that holds their teams together.39 Des Weiteren meint er, dass These challenges necessitate the development of an additional set of competencies that complement the skills for leading teams.40 was insofern auf der Hand liegt, als dass Projektleiter und Projektleiterinnen nicht nur den Herausforderungen des herkmmlichen Projektmanagements gewachsen sein mssen, darber hinaus muss ebenfalls mit den Problemen die durch die Virtualitt noch hinzukommen (siehe Kapitel 0) umgegangen werden. ber diese zustzlichen Fhigkeiten eines Projektleiters oder Projektleiterin in virtuellen Teams schreiben unter anderem Patzak / Rattay. Sie regen an, dass im Gegensatz zu konventionellen Teams hier ein hohes Ma an Fhrungskompetenz erforderlich wird sowie die Fhigkeit Mitarbeiter und Mitarbeiterinnen effektiv zu koordinieren und die Aufgaben zeitgerecht und effizient zu delegieren. Die fehlende subjektive Einschtzung der Mitarbeiter und Mitarbeiterinnen durch den persnlichen Kontakt muss in diesem Fall durch objektive und ergebnisorientierte berprfungen kompensiert werden. Zustzlich dazu muss natrlich, mehr noch als bei herkmmlichen Teams, eine starke Vertrauensbasis herrschen. Nicht nur zwischen den Teammitgliedern untereinander, sondern vor allem auch vom Projektleiter oder von der Projektleiterin in seine oder ihre Mitglieder.41 Wie in Punkt 2.1 ebenfalls bereits errtert, fallen der Projektleitung viele Aufgaben zu, in denen Sozialkompetenzen und persnliche Interaktionen mit den jeweiligen Teammitgliedern von wesentlicher Bedeutung sind.
39 40 41
Gollubits (2007), S. 46 ebd. Vgl. Patzak / Rattay (2009), S. 192 f.
18
Besprochene Aufgaben der Projektleitung aus Kapitel 2.1, wie zum Beispiel das Entwickeln des Teams, die Schaffung von Rahmenbedingungen fr eine positive Zusammenarbeit oder das Gestalten der Beziehungen der Teammitglieder, unter dem Aspekt der, in Kapitel 0, ausgearbeiteten Punkte stellt natrlich die Aufgaben des Projektleiters vor zustzliche Probleme. So wird unter anderem das Fhren und Entwickeln des Teams oder das Gestalten der Beziehung zu den Teammitgliedern und der Teammitglieder untereinander wesentlich erschwert, betrachtet man diese unter dem Aspekt der geographischen Dispersion oder einer zeitlichen Verschiebung. Ein wesentlicher Faktor der hier nmlich fehlt ist die bereits angesprochene Faceto-Face-Zeit.
3.4
Virtuelle Projektteams
Auch hier gibt es in der Literatur zahlreiche Definitionen die von "Mitglieder virtueller Teams mssen nicht mehr an einem Ort ansssig sein, an dem sie zusammentreffen, um Informationen auszutauschen. Die Mitglieder knnen vielmehr ortsunabhngig Leistungen erbringen.42 ber Als ein virtuelles Projektteam wird eine Gruppe aus mehreren Mitarbeitern mit verschiedenen Kernkompetenzen bezeichnet, die sich an verteilt lokalisierten Arbeitsorten zu einer ergebnisorientierten Zusammenarbeit unter Einsatz der Informations- und Kommunikationstechnik zusammenfinden und dabei weitgehend auf Face-to-FaceKommunikation verzichten.43 hinzu [] a virtual team works across space, time, and organizational boundaries with links strengthened by webs of communication technology44 reichen und alle die Problemstellungen aus Kapitel 0 unterstreichen.
42 43 44
Konradt (2002), S. 18 Falck et.al. (2009): S. 41 Lipnack (2000), S. 7
19
Virtuelle Projektteams sehen sich daher ohne Frage mit groen Herausforderungen konfrontiert, das Projektmanagement betreffend. Gerade bei Teamarbeit und Zusammenarbeit untereinander sind zeitliche und rtliche Unterschiede ein wesentlicher Problemfaktor. In der Literatur zeigt sich durchgehend, dass Kommunikation und Kollaboration zu den wichtigsten Faktoren bei der Teamarbeit gezhlt werden. So sind laut Patzak / Rattay unter anderem folgende Merkmale wesentliche Erfolgsfaktoren fr Teamarbeit: Die Atmosphre ist informell. Jeder Beitrag wir aufgenommen, [] Ansichten werden diskutiert [] Die Gruppendiskussion ist nicht personen-, sondern sachbezogen. Alle Teilnehmer knnen ihre Meinung offen uern. Alle Gruppenmitglieder sind engagiert an Diskussion beteiligt.45
Diese Punkte zeigen bereits, dass es sich hier vorrangig um Kommunikation handelt. Siyamak schreibt hierzu: one of the challenges in virtual organizations is reaching to some patterns for collective interaction and communication between work groups and workforces that are separated in distant places.46 Auch hier stehen Interaktion und Kommunikation im Fordergrund. Es liegt also auf der Hand, dass zeitliche und rtliche Trennung, unterschiedliche Technologien und vor allem das Fehlen von Face-to-Face-Zeit das Arbeiten von virtuellen Teams mit Sicherheit deutlich erschweren. Ein weiterer Indikator hierfr ist die Allen-Kurve die zeigt, dass bei wachsender Entfernung der Mitglieder zueinander, die Chance fr informelle und spontane Kommunikation drastisch abnimmt. So soll die Wahrscheinlichkeit fr den Austausch spontaner, informeller Information, bei einer Entfernung von 30 Metern, schon bei 10% pro Tag liegen.47
45 46 47
Patzak / Rattay (2009), S. 66 Siyamak (2009), S. 42 Vgl. Gollubits (2007), S. 50
20
Abbildung 3: Allen-Kurve
48
Auch Lipnack / Stamps machen klar, dass die Wahrscheinlichkeit der Kollaboration mit der Entfernung meist sehr schnell abnimmt. Sie sagen hierzu: Based on proximity, people are not likely to collaborate very often if they are more than 50 feet apart.49 Es ist also klar erkennbar welche Probleme hinsichtlich der Teamarbeit des Projektteams gelst werden mssen, um deren erfolgreiches Zusammenarbeiten zu ermglichen. Diese Probleme sollen im Folgenden vor allem im Kapitel 4 aufgegriffen werden um zu eruieren inwiefern die jeweiligen Tools hierzu beitragen.
48 49
Gollubits (2007), S. 50 Lipnack (2000), S. 8
21
3.5
Virtuelle Projektorganisation
Wie bereits in Kapitel 2.3 erlutert, handelt es sich bei der Projektorganisation eher um Rahmenbedingungen und Normen betreffend der Zusammenarbeit im Projektmanagement. Natrlich bindet das auch Personen ein, die wesentlichsten Bestandteile der Projektorganisation bilden aber Rahmenwerke, Richtlinien und Regelwerke zur Zusammenarbeit im Projekt und Ablufe innerhalb des Projekts. Auch hier stellt sich die Frage inwieweit eine Virtualisierung dieser Rolle ein zustzliches Problem darstellen knnte. Die ICB schlgt bei der Einrichtung einer Projektorganisation prinzipiell neun Prozessschritte vor: 1. Feststellung, welche Art von Projektorganisation und Ressourcen bentigt werden. 2. Ermittlung der Organisationseinheiten, die dem Projekt Ressourcen zur Verfgung stellen werden. 3. Festlegung der Rollen, Verantwortungen, Schnittstellen, formale Kompetenzen und Ablufe im Projekt. 4. Beschaffung der Ressourcen von den Organisationseinheiten. 5. Festlegung und Regelung der Schnittstellen mit den Einheiten der Stammorganisation. 6. Mitteilung von Entscheidungen, Leitung der Projektorganisation. 7. Aufrechterhaltung, Aktualisierung und ggf. nderung der Projektorganisation whrend der Projektlaufzeit. 8. Kontinuierliche Bemhungen zur Verbesserung der Projektorganisation. 9. Dokumentation der Lessons Learned und Anwendung auf zuknftige Projekte.50 Bei genauerer Betrachtung dieser Prozessschritte lsst sich aber feststellen, dass einige davon mit hoher Wahrscheinlichkeit von einer Virtualisierung vllig unberhrt bleiben. So bleiben Prozessschritt 1, 2, 4, 6, 7 und 9 grtenteils unberhrt von Vernderungen wie rtlichkeit oder rumlichen Trennungen. So kann zum Beispiel das Dokumentieren der Lessons Learned von der Projektorganisation unabhngig von Ort und Zeit durchgefhrt und spter zur Verfgung gestellt werden. Des Weiteren sind aber auch Punkte die zunchst den Anschein erwecken ein hohes Ma an Interaktion zu erfordern wesentlich unproblematischer hinsichtlich einer Virtualisierung.
50
Caupin et.al. (2006), S. 65
22
So versteht die ICB zum Beispiel unter Festlegung der Rollen, Verantwortungen, Schnittstellen, formale Kompetenzen und Ablufe im Projekt eher einen formalen Akt als eine Zusammenarbeit der spter involvierten Personen. So wird hier zum Beispiel folgendes ber die Projektorganisation klargestellt: Die Kompetenz der fr die Mitarbeit am Projekt ausgewhlten Personen muss berprft und ihre Verfgbarkeit mit dem Linienmanagement abgestimmt werden. Im Idealfall werden der Projektmanager und der Linienmanager der Abteilung, die die Ressourcen zur Verfgung stellt, die Eignung eines jeden fr eine bestimmte Funktion im Projekt ausgewhlten Mitarbeiters miteinander besprechen.51 Das bedeutet also, dass die Zusammenarbeit zwischen Projektorganisation und Projektmanager beziehungsweise Projektmanagerin zum Beispiel zwar erwnscht ist, aber nicht unbedingt erforderlich. Daraus lsst sich des Weiteren schlieen, dass die Projektorganisation von einer Virtualisierung direkt nicht anders betroffen sein wird als zum Beispiel das Projektteam. Die auftretenden Probleme knnen hier in der Kollaboration und hauptschlich auch in der Kommunikation liegen, werden aber von der Auswirkung her wesentlich geringer sein als das zum Beispiel beim Projektteam der Fall ist.
3.6
ProjektcontrollerIn
Die Rolle des Projektcontrollings in virtuellen Projekten und im virtuellen Projektmanagement ist sehr fraglich. Zunchst ist festzuhalten, dass der Projektcontroller oder die Projektcontrollerin im herkmmlichen Projekten bereits nur dann eine wesentliche Rolle im Projektmanagement darstellt, wenn der Projektleiter oder die Projektleiterin selbst keine tieferen Projektmanagementkenntnisse besitzt (z.B. Forschungsprojekte, Anlagenbau, etc.).52 Wie aber bereits in Kapitel 3.3 beschrieben, sind die Anforderungen an Projektleiter oder Projektleiterin bei virtuellen Teams wesentlich hher als die an einen Projektleiter oder eine Projektleiterin eines herkmmlichen Projektteams. Um ein virtuelles Projektteam zu leiten bentigt es einen Projektleiter/eine Projektleiterin der neben seinen fachlichen Qualitten auch die sozialen Kompetenzen besitzt ein virtuelles Projektteam zu leiten.
51 52
Caupin et.al. (2006), S. 64 Vgl. Patzak / Rattay (2009), S. 166
23
3.7
Steering Committee
Wie bereits zuvor angedeutet, bildet der Projektlenkungsausschuss zwar einen wesentlichen Bestandteil des Projektmanagements, hinsichtlich der Virtualitt kann diese Komponente jedoch vernachlssigt werden. Es kann davon ausgegangen werden, dass zwar auch hier zwischen Projektauftraggeber oder Projektauftraggeberin und Lenkungsausschuss oder Lenkungsausschuss und Projektleitung Kommunikation stattfindet, es ist aber des Weiteren davon auszugehen, dass diese Kommunikation sich von der in herkmmlichen Projekten nicht unterscheidet. Daher wird auf die Rolle des Projektlenkungsausschusses im Weiteren in dieser Arbeit nicht eingegangen.
3.8
ProjektauftraggeberIn
Der Projektauftraggeber beziehungsweise die Projektauftraggeberin hat, hnlich dem Projektlenkungsausschuss oder dem Projektcontrolling, im herkmmlichen Projektmanagement zwar eine wesentliche Bedeutung, hinsichtlich seiner oder ihrer Aktivitten und Verantwortungen fllt dieser Rolle aber bezogen auf virtuelles Projektmanagement eher geringe Bedeutung zu. Zwar nimmt der Projektauftraggeber oder die Projektauftraggeberin aktiv am Projektgeschehen teil und es ist dadurch klar, dass im Zuge seiner Ttigkeit auch ein gewisses Ma an Interaktion und Kommunikation stattfinden muss, dennoch besteht ein Groteil der Aufgaben im Treffen von strategischen Entscheidungen und der Informationsaustausch erfolgt oft unidirektional.53 Es ist also davon auszugehen, dass eine Virtualisierung des Projektmanagements auf die Rolle des Projektauftraggeber/der Projektauftraggeberin nur geringen Einfluss hat, weshalb auch auf diese Rolle im weiteren Verlauf dieser Arbeit nicht nher eingegangen wird.
53
Vgl. Patzak / Rattay (2009), S. 147-152
24
3.9
Problemstellungen
Aus der Abgrenzung des virtuellen Projektmanagements gegenber des herkmmlichen Projektmanagements und den Betrachtungen der Rollen unter dem Gesichtspunkt der Virtualitt ergeben sich im Folgenden zusammengefasst einige Problemstellungen des virtuellen Projektmanagements mit denen, zustzlich zu den Problemen des herkmmlichen Projektmanagements, umgegangen werden muss. Wie bereits zuvor festgestellt sieht sich das virtuelle Projektmanagement mit Problemen wie rtlicher Dispersion, Zeitlichen Unterschieden, Unterschiedlichen Organisationen
konfrontiert, woraus sich prinzipiell das Problem der stark verringerten Face-toFace-Zeit ergibt. Dieses wiederum hat erhebliche Auswirkung auf das Vertrauen, die Kommunikation und die Kollaboration
innerhalb des Projektteams und zwischen Projektteammitgliedern und der Projektleitung. Diese Probleme lassen sich auf das virtuelle Projektmanagement insofern ausweiten, als dass einerseits die Arbeit des Projektteams und des Projektleiters oder der Projektleiterin gemeinsam den wesentlichsten Teil des Projektmanagements ausmachen und daher als reprsentativ angenommen werden knnen, andererseits aber die Interaktion und Kommunikation insofern als Hauptproblem identifiziert werden kann, als dass die Kommunikation und Interaktion zwischen Teammitgliedern und Teammitgliedern und Projektleitung als wesentlich auf den Projekterfolg auswirkend erwiesen ist. Diese Problemstellungen sollen als Basis fr Kapitel 4 dienen, in dem Tools erhoben werden sollen um diese Probleme zu lsen oder deren Auswirkung zumindest zu schmlern. Diese Tools sollen dann im Weitern in Kapitel 5 hinsichtlich der Probleme und der jeweiligen Projektphase auf ihre Ntzlichkeit hin untersucht werden.
25
Tools
Wie bereits in Kapitel 2.5 angesprochen, sollen in diesem Kapitel nicht vorrangig Tools des alltglichen Projektmanagements errtert werden, sondern vor allem Tools die virtuellen Projektteams bei der Kommunikation und Kollaboration untersttzend zur Seite stehen. Bei der Auswahl der Tools ist vor allem wichtig, inwiefern Sie die Probleme der jeweiligen Projektrollen (siehe Kapitel 2) beheben beziehungsweise diese in den jeweiligen Projektphasen (siehe Kapitel 5) untersttzen. Wie bereits besprochen haben virtuelle Projektteams prinzipiell mit geographischer und zeitlicher Unterschiede sowie unterschiedlichen Organisationen und Technologien umzugehen. Dies fhrt zu einem Verlust von persnlichen Kontakten und der angesprochenen Face-to-Face-Zeit. Dies wiederum hat wesentliche Probleme in der Kommunikation, Interaktion und Kollaboration der einzelnen Teammitglieder zur Folge, was auf das Projekt extrem kritische Auswirkungen haben kann. Im Folgenden sollen hierzu daher drei Kategorien von Tools besprochen werden. Zum Einen herkmmliche Projektmanagementsoftware, wobei hier erlutert wird inwiefern diese die Arbeit speziell virtueller Projektteams untersttzen kann. Kollaborationstools ebenso wie Kommunikationstools sollen hinsichtlich der Probleme der Virtualitt betrachtet werden und inwiefern sie die besprochenen Probleme lsen, oder zumindest schmlern knnen.
26
4.1
Projektmanagementsoftware
Wie bereits zuvor besprochen, ist der Einsatz von Projektmanagementsoftware im herkmmlichen Projektmanagement bereits alltglich vorhanden. Diese wird vorrangig fr Aufgabenplanung, Ressource- und Kostenplanungen, und zur Terminund Ablaufplanung genutzt. Der Umfang erstreckt sich aber natrlich auch noch darber hinaus und in manchen Fllen umfasst die Software hier noch wesentlich komplexere Funktionsmodule wie Workflowkontrolle, Risikound
Claimmanagement (inklusive Ticketsystem), Berichtswesen, Multiprojektmanagement und vieles mehr.54 Von wesentlicher Bedeutung soll aber in dieser Arbeit nicht die Funktionalitt dieser Software sein, sondern wie diese das Projektmanagement virtueller Projektteams untersttzen kann. Hier ist vor allem wichtig in den Bereichen verstrkt Untersttzung anzubieten in denen durch die Virtualitt des Projektes vermehrt Probleme zu erwarten sind. Um in diesem Punkt eine genauere Aussage treffen zu knnen, sollen zunchst die wesentlichen Merkmale von Projektmanagementsoftware angefhrt werden. Hier liefern unter anderem Mhlbauer et.al. eine mgliche Unterteilung, die PMS 55 nach Kriterien beurteilt. Diese Kriterien sind in folgende Kategorien unterteilt: graphical Interface o input adequacy o web support o internationalization o intuitive handling o aesthetics economical o cost o market share o open-source software o plattform independence
54 55
Vgl. Patzak / Rattay (2009), S. 616-627 PMS - Projekt Management Software
27
interoperability o standardized formats o automation o cooperation o exports and reports
data handling o versioning o synchronization
project management o resources o tasks o critical path o multi-scenario management o multi-project management
miscellaneous o documentation o support o performance o stability o transparency56
Hierbei ist natrlich zu differenzieren zwischen Komponenten die im herkmmlichen Projektmanagement wichtig sind (Cost, Market share, Versioning, etc.), in dieser Arbeit aber keine Relevanz haben, und Komponenten die in dieser Arbeit relevant sind, da sie auch auf Probleme des virtuellen Projektmanagements eingehen (Critical Path, Internationalization, Plattform Indepenence, etc.).
56
Vgl. Mhlbauer et.al. (2007), S. 4 ff.
28
Eine weitere Mglichkeit der Kategorisierung liefert unter anderem Bryce der folgende Kriterien als wesentlich bei der Auswahl von Projektmanagementsoftware benennt: General Requirements o Support any type of project (small, medium, large) o Distinguish between direct, indirect and unavailable activities o Promote the mini-project manager concept o Planning Support o Support various WBS o Support internal project dependencies o Estimating support o Allow multiple versions of estimates o Provide a means to maintain estimating guidelines o Scheduling support o Provide for automated calculations o Allow multiple versions of schedules o Be able to calculate critical paths of projects o Reporting support o Maintain historical time data to be used o Provide a standard facility to generate a variety of project reports o Control support o Provide various summary reports to analyse projects and human resources o Post reported time to projects and to human resources reporting it
29
Computer related considerations o Be easy to install and test on the computer o Be implemented as a cross platform solution o Be easy to learn and to use57 o
Auch hier muss zwischen dem herkmmlichen Projektmanagement zutrglichen Kriterien (support various WBS, Allow multiple versions of estimates , etc.), in dieser Arbeit aber unwesentlichen Komponenten, und solchen die im Zuge dieser Arbeit genauer betrachtet werden sollen, die vor allem auch virtuelles Projektmanagement untersttzen (be able to calculate critical path, be implemented as a cross platform solution, etc.). Auch Gollubits unterscheidet zwischen Komponenten von Projektmanagementsoftware von herkmmlichen Projekten wie: Project Structure, Capacity planning, Project progress presenting
und Funktionalitten die durch die Anforderungen aus dem Projektmanagement von virtuellen Projekten kommen wie: Internet-capable, Communication of project tasks via electronic media, Interface connectivity to other software applications.58
Von wesentlicher Bedeutung sind diese Kriterien vor allem, da ohne sie eine Auswahl des richtigen Tools bei der Vielzahl an, sich auf dem Markt befindlichen Produkten, eine Evaluierung unmglich ist.
57 58
Vgl. Bryce (2006) Gollubits (2007), S. 63 f
30
In dieser Arbeit sollen daher folgende Kriterien als wesentlich empfunden werden bei der Auswahl und dem Einsatz von Projektmanagementsoftware: Internationalitt o Mehrsprachigkeit Mehrsprachigkeit ist unabdingbar beim Arbeiten mit virtuellen Projektteams. Diese knnen nicht nur rtlich verteilt sein, die Projektmitglieder knnen natrlich auch aus unterschiedlichen Lndern stammen. Ein Tool das hier sinnvoll eingesetzt werden soll, muss daher zumindest die Sprachen der Beteiligten bereitstellen, oder eine Sprache in der sich die Mitglieder des Projekts untereinander verstndigen knnen. Sprache kann in vielen Fllen eine Barriere fr Teamarbeit sein und das Tool kann hier bereits helfen diese Barriere teilweise zu beseitigen.
o Eingehen auf landesspezifische Unterschiede (Whrung, Zeitzone, etc.) Wie Sprache ist auch das Eingehen auf nationale Unterschiede ein wichtiger Bestandteil eines Projektmanagementtools fr virtuelle Projektteams. Es ermglicht den Mitgliedern und der Projektleitung das Projekt zu planen ohne verstrkte Rcksicht auf landesspezifische Unterschiede nehmen zu mssen. Mssen Projektkosten erst umgerechnet, oder Zeitplne erst an die landesbedingten Wochentage, Feiertage, etc. angepasst werden, so resultiert daraus natrlich ein Zeitverlust, sowie natrlich auch ein Motivationsverlust.
31
Kollaboratives Arbeiten o Integriert state-of-the-art Kommunikation (Email, VOIP59, SMS60, etc.) Um verteilten Projektteams zu ermglichen mglichst effizient zusammenzuarbeiten, ist es natrlich unabdingbar das diese Informationen so unkompliziert wie mglich erhalten. Zeitliche und rtliche Verschiebungen machen es notwendig, dass der betreffende mglicherweise zu anderen Tageszeiten oder in unterschiedlichen Abstnden an Infrastruktur gelangt. Hier ist es notwendig, dass Informationen, die ja als wesentliches Gut im Projektmanagement anzusehen sind, die jeweilige Person erreichen. Das Tool sollte es also ermglichen diese Informationen auf jedem erdenklichen Weg dem Empfnger zuzustellen um diesen bestmglich in den Informationsprozess einzubinden.61
o Tasks knnen auch auerhalb des Tools koordiniert werden (per Email, shared documents, etc.) Zustzlich zu dem vorangegangenen Punkt wre es natrlich von Vorteil, wenn nicht nur Informationen zugestellt, sondern diese auch besprochen und koordiniert werden knnen, also nicht nur Informationszustellung stattfindet, sondern auch Kollaboration in anderen Kanlen mglich ist. Oft ist es nicht nur notwendig Information dem jeweiligen Projektmitglied zukommen zu lassen, sondern auch das dieses die berbrachte Informationen besprechen kann, beziehungsweise darauf antworten und sich dazu uern kann. Aus denselben technologischen Grnden wie zuvor wre es also hier von Vorteil wenn dieser Austausch nicht nur im Tool, sondern auch auerhalb des Tools mglich wre, diese Informationen aber trotzdem vorhanden bleiben. Das Dokumentieren dieser Austusche kann unter Umstnden sehr wichtig sein wenn es zu Differenzen von be-
59 60 61
VOIP Voice over IP SMS Short Message System Vgl. Gollubits (2007), S. 63 f.
32
sprochenen Inhalten kommt, oder zu einem spteren Zeitpunkt besprochene Informationen noch einmal reflektiert werden sollen.62
Projektmanagement o Berechnungen (kritischer Pfad, Ressourcen, etc.) nehmen Rcksicht auf die unterschiedlichen Teilnehmer (Zeitverschiebung, nationale Unterschiede bei Feiertagen, etc.) Ebenso wichtig wie es ist fr Projektteammitglieder von virtuellen Projektteams Vereinfachungen bereitzustellen, ist es fr deren Projektleitung Mglichkeiten anzubieten die jeweiligen Probleme zu beheben. So kann es in virtuellen Projekten mitunter sehr schwer, unter Bercksichtigung aller Umweltfaktoren, die Ressourcen richtig einzuteilen und Berechnungen richtig durchzufhren. So wird zum Beispiel das Erstellen eines Projektablaufplans (PAP) mitunter durch die geographischen und zeitlichen Unterschiede massiv erschwert. Hinzukommen das Bercksichtigen von nationsabhngigen Feiertagen, unterschiedliche Arbeitszeiten (zum Beispiel Schichtbetrieb) und dergleichen. Ein Tool das auf diese Unterschiede bereits Rcksicht nimmt, knnte eine wesentliche Arbeitserleichterung fr die Projektleitung bedeuten und zustzlich mgliche Missverstndnisse im Vorfeld ausrumen oder gar nicht erst zulassen.63
o Die Projektleitung hat die Mglichkeit seine Teammitglieder ber multiple Informationskanle zu informieren Dies ist wie bereits zuvor besprochen eine sehr wichtige Funktionalitt. Natrlich soll sie nicht nur den Projektteammitgliedern untereinander zur Verfgung stehen, sondern vor allem auch der Projektleitung, die so die Mglichkeit die Chance die weit verteilten Teammitglieder besser erreichen zu knnen. Dies ist vor allem bei zeitkritischen Projekten von besonderer Wichtigkeit.
62 63
Vgl. Gollubits (2007), S. 63 f. Vgl. Patzak / Rattay (2009), S. 617 ff.
33
o Unterschiedliche Informationen knnen unterschiedlich kommuniziert werden, laufen aber im Tool zusammen (Technologieunterschiede) Wie bereits zuvor angesprochen ist es wichtig Informationen ber unterschiedliche Kanle kommunizieren zu knnen. Es ist aber ebenfalls von Bedeutung, dass diese Informationen an einem gesammelten Punkt wieder zusammenlaufen. Es steht auer Frage, dass die besprochenen Tasks oder getroffenen Vereinbarung gespeichert und fr einen spteren Zugriff zugnglich gemacht werden mssen um einerseits einen berblick zu behalten, andererseits aber eine nachtrgliche Recherche mglich zu machen. Diese in den jeweiligen Kommunikationsmitteln (Email, Shared document, etc.) zu belassen wre kontraproduktiv, da mit fortschreitender Zeit der berblick verloren gehen wrde.
Technische Dispersion o Internet-fhig Die Verwendung des Internets beziehungsweise zumindest des Intranets, steht bei Tools zur Untersttzung virtueller Projektteams auer Frage. Geht man davon aus, dass die Teammitglieder geographisch weit verstreut sind, so liegt die Verwendung von Internettechnologien und internetbasierenden Technologien auf der Hand. Die Vernetzung der jeweiligen Mitarbeiter und Mitarbeiterinnen mit Hilfe eines internetbasierten Tools liegt insofern auf der Hand, als dass eine Internetanbindung mittlerweile global zur Verfgung steht. In Einzelfllen kann es sein, dass dieser Zugang nicht direkt mglich ist (zum Beispiel Satelitenverbindung in abgelegenen, nicht an die Infrastruktur angeschlossenen Gebieten), dennoch ist aber davon auszugehen, dass in fast allen virtuellen Projekten eine Internetanbindung Grundvoraussetzung ist.64
64
Vgl. Dostal (2007), S. 51 -53
34
o Web-fhig Die Webfhigkeit eines Tools ist nicht unbedingt fr seinen Einsatz im virtuellen Projektmanagement zwingend notwendig, kann aber signifikante Vorteile mit sich bringen. Verfgt ein Tool ber einen Webclient, so trgt dies nicht nur zur Plattformunabhngigkeit des Tools bei (siehe im nchsten Punkt), sondern kann es den Benutzern und Benutzerinnen auch ermglichen ohne die Installation einer Software auf das Tool zuzugreifen.
Dies hat im Regelfall folgende Vorteile: Das Tool ist schneller benutzbar da eine Installation nicht notwendig ist. Eine Installation bringt zustzlich das Problem einer dezentralen Architektur mit sich, was Probleme mit der Versionierung, Probleme unterschiedlicher Plattformen und dergleichen mit sich bringt. Dies kann durch eine zentrale Architektur wie einem Webserver basiertem Tool vermieden werden. Das Tool kann von unterschiedlichen Standorten verwendet werden. Eigene Infrastruktur ist nicht mehr zwingend notwendig. Dies bringt vor allem Vorteile in Lndern in denen eine Internetanbindung zwar vorhanden, diese aber nicht berall verfgbar ist. So kann ein Benutzer auch von ffentlichen Anbindungen aus Zugang erhalten ohne dort erst Software installieren zu mssen.
o Plattformunabhngig Plattformunabhngigkeit ist, wie im vorigen Punkt bereits angesprochen, ebenfalls von wesentlicher Bedeutung bei der Reduktion von Problemen in virtuellen Projekten. Natrlich steht auer Frage, dass eine einfache Installation auch im herkmmlichen Projektmanagement Zeit erspart und Komplikationen verhindert. Unabhngig davon, ist aber in herkmmlichen Projekten davon auszugehen, dass durch eine geographische Einheitlichkeit (zum Beispiel selbes Gebude, 35
selber Standort, selbe Stadt) diese aber einfacher zu lsen sind als wenn die Problembehandlung ber eine rtliche und zeitliche Entfernung hinweg stattfinden muss.
o Integriert unterschiedlichste Schnittstellen um eine mglichst breite Integration zu erwirken (XML65, SOAP66, JSON67, Excel, Word, etc.). Das Integrieren unterschiedlicher Datenformate und Schnittstellen bildet, neben der Plattformunabhngigkeit, mit Sicherheit einen der wesentlichsten technischen Anforderungen an ein Projektmanagementsystem, das das virtuelle Projektmanagement untersttzen soll. Ebenso wie geographische und zeitliche Unterschiede, zhlen, wie zuvor bereits erwhnt, auch technologische Unterschiede zwischen den einzelnen Mitgliedern des Projekts, zu wesentlichen Problemen des virtuellen Projektmanagements. So ist es beinahe unabdingbar, dass ein Tool durch das Untersttzen der gngigsten Datenformaten und Schnittstellen zu anderen Systemen, den Mitgliedern die Mglichkeit bietet Informationen aus anderen Systemen zu beziehen und diese mglicherweise in diese auch wieder zurckzuspielen. Eine Integration mehrerer Datenformate und Schnittstellen zu anderen Systemen bietet darber hinaus den jeweiligen Beteiligten die Mglichkeit, neben der Benutzung des gemeinsam vereinbarten Projektmanagementwerkzeugs unabhngig zu sein und Zusatzinformationen individuell aufzubereiten und bei Bedarf ber eine der Schnittstellen diese Information dem System zuzufhren.68 Die Anzahl der verfgbaren Tools am Markt ist sehr gro und so sollen im Folgenden drei Projektmanagementtools vorgestellt werden die vor allem den vorher genannten Kriterien entsprechen und somit in dieser Arbeit als besonders hilfreich im virtuellen Projektmanagement betrachtet werden knnen. Es sollen zwei Arten von Tools vorgestellt werden. Client-Server-Lsungen und Software as a Service-Lsungen (SaaS-Lsungen).
65 66 67 68
XML Extensible Markup Language SOAP Simple Object Access Protocol JSON Java Script Object Notation Vgl. Gollubits (2007), S. 64
36
4.1.1 Primavera
Primavera, eine Firma die 2009 von Oracle gekauft wurde, bietet eine Vielzahl an Projektmanagementtools an. Sie soll hier vorgestellt werden, da Oracle laut Gartner69 den grten Marktanteil an Projektmanagementsoftware hlt (siehe Abbildung 4).
Abbildung 4: Worldwide Project and Portfolio Management Software Revenue Estimates for 2009 70 (Millions of U.S.Dollars)
Primavera bietet folgende Produkte im Projektmanagement an: Primavera P6 Enterprise Project Portfolio Management, Primavera P6 Professional Project Management, Primavera Portfolio Management.
Diese gliedern sich meist in weitere Produkte wie Primavera P6 Professional Project Management sich zum Beispiel in die Punkte Oracle Project Portfolio Management Integration Pack for Primavera P6 and E-Business und Oracle Project Portfolio Management Integration Pack for Primavera P6 and JD Edwards EnterpriseOne gliedert. Daneben gibt es noch einige andere Produkte wie Primavera ProSight, Primavera Evolve, Primavera Contract Manager, Primavera Pertmaster oder Primavera Cost Manager die fr unterschiedliche Funktionen verantwortlich sind (wie unter anderem Dokumentenmanagement, Risikomanagement oder Ressourcenmanagement).
69 70
Gartner (2010) ebd.
37
Primavera P6, das eigentliche Projektmanagementtool, integriert
natrlich alle
diese Bausteine und erweitert so nach belieben den Funktionsumfang des Tools, damit aber auch die Komplexitt.
Abbildung 5: Primavera Project Management
71
71
Primavera Consultants (2011)
38
Abbildung 6: Primavera Cost Management
72
Wie in Abbildung 5 und Abbildung 6 zu erkennen, bietet das Tool umfangreiche Funktionalitten und Mglichkeiten. Diese bringen aber auch erhebliche Komplexitt mit in die Benutzung der Software. Vor allem beim Einsatz in virtuellem Projektmanagement ist abzuwgen wieviel Funktionalitt dem Benutzer zur Verfgung gestellt wird, da auch dementsprechend viel Know-How erforderlich ist, dass bei Fehlen selbigem angelernt und geschult werden muss. Dies erfordert wiederum zustzliche Zeit und Ressourcen die mglicherweise nicht vorhanden sind. Primavera wird daher auch vorrangig bei groen Firmen eingesetzt deren Hauptgeschft in Projekten abgewickelt wird und ein dementsprechendes Know-How meist in der Firma vorhanden ist. Des Weiteren ist Primavera natrlich in mehr als 50 Sprachen verfgbar und basiert auf einer Client-Server Architektur wobei Benutzer sowohl ber einen Desktop-Client als auch ber einen Webclient auf den Server zugreifen knnen.73 Andere Beispiele fr proprietre Projektmanagementsoftware mit hnlichem Funktionsumfang wren unter anderem Clarizen74, Microsoft Project75 oder Onepoint Project76.
72 73 74 75 76
Primavera Consultants (2011) Vgl. Primavera (2011) Clarizen (2011) Microsoft (2011) Onepoint Project (2011)
39
4.1.2 Project.net
Project.net77 ist im Gegensatz zu Primavera ein open-source Tool, dass von Integrated Computer Solutions Inc. entwickelt wird. Es ist unentgeltlich erhltlich bietet aber dennoch alle wesentlichen Funktionalitten wie unter anderem persnliche Dashboards, Zeitmanagement, projektbasierte Wikis, Dokumentenmanagement, Projektplne, Workflow-Steuerung sowie ein umfangreiches Reporting.
Abbildung 7: Project.net Time Management
78
Wie in Abbildung 7 und Abbildung 8 zu sehen ist, stehen auch hier zahlreiche Funktionalitten und Mglichkeiten zur Verfgung und auch hier gilt, dass mit wachsender Funktionalitt auch die Komplexitt wchst und die Benutzerfreundlichkeit dementsprechend abnimmt. Ungeachtet dessen ist das Tool aber kostenfrei erhltlich, Lizenzkosten entfallen hier dementsprechend, was aus einem konomischen Standpunkt heraus bei einer Gesamtkostenrechnung des Tools wesentlich niederschlgt. Etwaige Schulungs- oder Trainingsaufwnde wrden hier verhltnismig geringer ausfallen (im Vergleich mit einem kostenpflichtigen Tool).
77 78
Project.net (2011) ebd.
40
Abbildung 8: Project.net Project Workplan
79
Project.net ist plattformunabhngig und kann ber jeden Browser angesprochen werden. Zustzlich ist die Software in den Sprachen Englisch, Franzsisch, Deutsch, Italienisch, Japanisch und Spanisch verfgbar. Es knnen aber auf Wunsch (und Mithilfe durch den Interessenten) auf Grund des open-source Charakters auf Anfrage Sprachen hinzugefgt werden.80 hnliche Produkte sind Clocking IT81, Basecamp82 oder Endeavour83.
79 80 81 82 83
Project.net (2011) Vgl. Project.net (2011) Clocking IT (2011) Basecamp (2011) Endeavour (2011)
41
4.2
Kollaborations-Tools
Unter dem Begriff der Kollaboration soll in dieser Arbeit die Zusammenarbeit der einzelnen Mitglieder des Projektteams verstanden werden um die Projektziele zu erreichen. Cooperative arrangement in which two or more parties (which may or may not have any previous relationship) work jointly towards a common goal.84 Dementsprechend sollen in dieser Arbeit Kollaborationstools als Tools verstanden werden, welche die Projektteams bei der Zusammenarbeit untersttzen um die Projektziele zu erreichen. Es kann hier natrlich keine exakte Abgrenzung zwischen reiner Kollaboration und reiner Kommunikation stattfinden, da sowohl fr Kollaboration immer auch Kommunikation notwendig ist, umgekehrt aber auch Kommunikation immer zu einem gewissen Teil auch kollaborativ ist. Des Weiteren findet Kommunikation in Projekten immer zum Informationsaustausch statt, der meist zum Zweck der Zielerreichung geschieht. Dennoch soll in dieser Arbeit eine Unterscheidung stattfinden. Unter Kollaboration soll dabei hauptschlich die Zusammenarbeit zum Zwecke der Erreichung eines bestimmten Ziels verstanden werden. Kommunikation kann dahingegen aber auch informell stattfinden, unter anderem zum Beispiel zur Pflege von Beziehungen. Wie bereits im vorigen Punkt bentigt es auch hier Kriterien nach denen ein Kollaborationstool beurteilt werden kann, vor allem hinsichtlich der Anforderungen an virtuelles Projektmanagement.
84
Business dictionary
42
Klein / Adelmann nennen hierzu acht kollaborative Verhaltensmuster: Connection locating with whom to collaborate and how to contact them Transmission sending a message Notification alerting the intended party of an incoming transmission Identification designating the sender, receiver, and subject of a transmission Common Ground Preservation establishing and maintaining a shared context and meanings in transmissions Confirmation notifying the sender of a transmission that it has been received Synchronization orchestrating actions to facilitate joint action85
Gauthier gliedert die Funktionalitt hingegen in Basisfunktionalitt und Zusatzfunktionalitt. Basisfunktionalitt Diskussionthreads. Hier werden Diskussionen und Konversationen so gruppiert, so da der Gesprchsverlauf klar erkennbar ist. Speicherung und schneller Zugriff auf Text und Daten zur Problemlsung. Gruppenbasierte Filterung und Verteilung von Nachrichten und Informationen.86 Zusatzfunkionalitt Allgemeinzugngliche Whiteboards. Gruppenkalender. Ermglichen von elektronischen Abstimmung bei gleichzeitiger Wahrung der Privatsphre. Chatrooms. Erweitertes Dokumentenmanagement (Versionierung, Suchfunktionalitt, Auditierung, etc.). Mutlilingualitt und Multinationalitt.87
85 86 87
Klein / Adelmann (2005), S. 2 Vgl. Gauthier (2004) Ebd.
43
Sowohl bei Klein / Adelmann als auch bei Gauthier kann man erkennen, dass, wie bereits vermutet, Kollaboration und Kommunikation nicht klar trennbar sind. In beiden Fllen spielt auch Kommunikation eine wesentliche Rolle. So finden sich bei Gauthier unter anderem Punkte wie sending a message oder designating the sender, receiver and subject of a transmission die klar zeigen, dass es sich hier zwar im einen Fall um die bermittlung von Informationen und im anderen Fall um eine organisatorische Problematik handelt, es aber in beiden Fllen eine Kommunikationsthematik darstellt. Ebenfalls beinhalten die, nach Klein / Adelmann, beschriebenen Funktionalitten Punkte wie Diskussionthreads oder das Filtern und Verteilen von Nachrichten wobei es wie schon zuvor zwar um den Austausch von Informationen zur Zielerreichung geht, nichtsdestotrotz findet auch hier, da es sich auch hier um Informationsaustausch handelt, Kommunikation statt. Darber hinaus sind einige der dargestellten Funktionalitten bereits in Kapitel 4.1, im Zuge der Vorstellung von Projektmanagementsoftware, errtert worden (unter anderem zum Beispiel Multilingualitt und Multinationalitt). Dies soll lediglich noch einmal klarstellen, dass diese beiden Punkte nicht sauber von einander abgegrenzt werden knnen.
44
In dieser Arbeit sollen daher folgende Kriterien als wesentliche fr Kollaborationstools angesehen werden: Diskussionsthreads Wie bereits in Kapitel 4.1, bei der Beschreibung von Projektmanagementsoftware erwhnt, ist es nicht nur wichtig Informationen auszutauschen, sondern diese auch inhaltlich gruppieren zu knnen. So ist es bei einem Kollaborationstool von Wichtigkeit, dass hier nicht nur Informationen ausgetauscht werden, sondern zu diesen auch Metainformationen existieren, wie unter anderem wer hat wem wann was geschickt oder auch wer hat wem was worauf geantwortet. Es ist also nicht nur entscheidend das Informationen und Daten ausgetauscht werden, sondern auch wie, wann, von wem und warum. Dies scheint zwar whrend der Projektarbeit zunchst von eher geringer Bedeutung, da der Informationsaustausch und das Ziel das dieser verfolgt im Fordergrund stehen, im spteren Verlauf der Projektarbeit und vor allem auch nach dem Projekt kann es sehr wohl von Bedeutung sein diese Informationen abrufen zu knnen (zum Beispiel Lessons Learned, etc.). Ein weiterer, sehr wesentlicher, Punkt ist hier aber auch Konfliktlsung. Oft treten Konflikte vor allem durch das Nicht-Vorhandensein von Metainformation auf, da nicht nachvollzogen werden kann welche Person letztverantwortlich war oder bei welchem Projektmitglied welche Information als letztes eingelangt ist. Auch ist oft nicht klar welche Person welchen Informationsstand hat. Dies kann unter anderem auch zu einem erheblichen Zeitverlust fhren wenn die Informationsstnde der einzelnen Mitglieder nicht klarerkennbar sind und daher die Projektleitung diese Aufgabe bernehmen muss.88
88
Vgl. Gauthier (2004)
45
Dokumentenmanagement Wie bereits Gauthier anregt, ist das Filtern und Speichern von Daten und Dokumenten uerst wichtig. Informationen, Dateien und Dokumente mssen nicht nur zugnglich gemacht werden, sondern es muss auch mglich sein bei steigender Masse an Dokumenten einen berblick bewahren zu knnen und den administrativen Aufwand weiterhin gering zu halten. Dokumentenmanagement soll hier den Projektmitgliedern nicht nur ermglichen Dokumente abzulegen, zu teilen oder mit Zusatzinformation zu versehen (zum Beispiel wer hat dieses Dokument abgelegt, zu welchem Zweck, fr wen ist es bestimmt, etc.), sondern auch in der Vielzahl der Dokumente und Dateien effizient suchen zu knnen, diese rasch und unkompliziert gemeinsam bearbeiten zu knnen (siehe Shared Documents) und mglicherweise sie auch einer Hierarchie oder Gruppierung zu unterwerfen. Hierbei steht auer Frage, dass um diese Zusatzinformationen und -funktionalitten nutzen zu knnen, es nicht nur ein Tool bentigt das dessen mchtig ist, sondern auch die Bereitschaft der Beteiligten bestehen muss diese Daten einzutragen und zu warten. Hier kann zwar ein Teil der Arbeit vom Tool selbst erledigt werden (zum Beispiel durch Userinformationen, Zeitangaben, etc.), Teile dieser Informationen und Parameter mssen aber mit Sicherheit von Benutzern und Benutzerinnen gepflegt werden. Hierbei ist es wichtig, dass die diese eigenverantwortlich arbeiten um das System nicht verwildern zu lassen, andererseits ist es aber mit Sicherheit auch Aufgabe der Projektleitung periodisch dafr zu sorgen, dass die Richtlinien zur Benutzung des Systems eingehalten werden um eine effiziente Nutzung des Tools zu ermglichen. Zuletzt mag es bei wachsendem Umfang der Dokumente und bei steigender Frequenz der Benutzung notwendig sein, einen Systemverantwortlichen oder eine Systemverantwortliche zu ernennen der oder die die Wartung und Instandhaltung des Systems berwacht.89
89
Vgl. Senst (2001), S. 31 und Dostal (2007), S. 73 f.
46
Shared Documents Eine weitere Anforderung an Kollaborationstools ist Dokumente und Dateien nicht nur gemeinsam, sondern mitunter auch gleichzeitig bearbeiten zu knnen. Auch hier steht natrlich wieder auer Frage, dass es sich hier auch um eine gewisse Art der Kommunikation handelt, es steht aber ebenfalls auer Frage das dies eine sehr effektive und zeitsparende Methode sein kann um zu kollaborieren und sich auszutauschen. So knnten beim gleichzeitigen Arbeiten an ein und demselben Dokument mehrere Teilnehmer oder Teilnehmerinnen ihre Beitrge gleichzeitig vorbringen, hnlich einer Gruppendiskussion oder einem Brainstorming. Informationen mssten nicht mehr, zum Beispiel verbal, abstrahiert werden sondern wren direkt und sofort sichtbar. Eine definitive Einschrnkung dieser Funktionalitt ist, dass Teilnehmer und Teilnehmerinnen zwar rtlich voneinander getrennt sein knnen, aber eine zeitliche Verschiebung der Arbeitszeiten dadurch nicht kompensiert werden kann, da hier eine synchrone Informationsbertragung stattfindet, alle Teilnehmer und Teilnehmerinnen also zumindest anwesend sein mssen. Dennoch liegt der Vorteil der Gleichzeitigkeit ebenfalls auf der Hand, in dem Informationen nicht zeitverzgert ankommen (wie zum Beispiel per Email wo zwischen Abschicken des Dokuments, Ankunft der Email und Antwort eine gewisse Zeitspanne vergeht, der Informationsaustausch also asynchron stattfindet), sondern per Echtzeit verfgbar sind und auch sofort kollaboriert werden kann. Der Einsatz einer solchen Funktionalitt ist daher situationsbedingt, anhand der genannten Vor- und Nachteile, abzuwgen. In jedem Fall wre es von Vorteil ein Tool zu benutzen, welches diese Funktionalitt potentiell zur Verfgung stellt, um es, falls bentigt, zur Verfgung zu haben.
47
Whiteboardfunktionalitt Whiteboardfunktionalitt kann zustzlich zur Shared Document-
Funktionalitt gesehen werden. Hier haben die Anwender die Mglichkeit nicht nur textuell gleichzeitig zu arbeiten, sondern wie an einem herkmmlichen Whiteboard gleichzeitig graphisch und oder freihndig zu arbeiten.
Abbildung 9: TalkAndWrite
90
Wie in Abbildung 9 exemplarisch zu sehen ist, knnen Teilnehmer gemeinsam und gleichzeitig, hnlich wie an einem Whiteboard, gemeinsam arbeiten und zeichnen. Dies erleichtert es Probleme und Sachverhalte einfach und unkompliziert graphisch darzustellen und gleichzeitig zu besprechen. Auch hier ist der einzige Nachteil, dass es hierzu notwendig ist, dass alle Mitglieder anwesend sind, da es sich um synchrone Bearbeitung handelt. Zeitliche Unterschiede zwischen den Mitgliedern knnen hier nicht berwunden werden.91
90 91
TalkAndWrite (2011) Vgl. Gauthier (2004) und Vgl. Senst (2001), S. 30
48
Elektronische Abstimmungen und Umfragen Elektronische Abstimmungen und elektronische Umfragen, knnen bei der Zusammenarbeit von virtuellen Projektteams, gerade fr die Projektleitung eine wesentliche Zeitersparnis bringen. Durch das Durchfhren von Umfragen oder Abstimmungen im Tool kann insofern Zeit gespart werden, als einerseits die Verantwortlichen (meist die Projektleitung) sehr wenig administrativen Aufwand betreiben muss um die jeweilige Aktion durchzufhren und diese zustzlich zeitunabhngig stattfinden kann. Es sind also zeitliche und geographische Verschiebungen kompensierbar, in dem die Teilnahme an Umfrage oder Abstimmung des jeweiligen Mitglieds nicht gleichzeitig erfolgen muss. Diese kann (meistens unter Bercksichtigung einer Deadline) selbststndig durchgefhrt werden. Kritisch muss hier jedoch die Anonymitt des Einzelnen betrachtet werden. So kann es, gerade bei Abstimmungen, notwendig sein diese anonym durchfhren zu knnen. Hierzu muss das Tool nicht nur technisch in der Lage sein, es muss auch das Vertrauen der Benutzer und Benutzerinnen in das Tool vorhanden sein. Hier ist es notwendig, dass bereits bei der Einfhrung oder Einschulung das notwendige Vertrauen geschaffen wird und im Zweifelsfall Aufklrungsarbeit geleistet wird. Ohne Untersttzung durch die Benutzer und Benutzerinnen kann eine derartige Funktionalitt nicht eingesetzt werden. Hier muss daher gerade auch die Projektleitung die notwendige Professionalitt und Seriositt im Umgang mit dem Tool gewhrleisten.92
92
Vgl. Gauthier (2004)
49
Gemeinsame Kalender Gruppenkalender
Vor allem bei virtuellem Projektmanagement ist terminliche Koordination ein wesentlicher Erfolgsfaktor. Die Mglichkeit Termine, Meetings, Milestones oder Ereignisse fr alle Projektmitglieder zu planen und als Mitglied diese fr sich selbst einsehen und noch weiter bearbeiten zu knnen bietet natrlich eine umfangreiche Kollaborationsmglichkeit. Diese Vorteile knnen hierbei sowohl von der Projektleitung, die dabei einen wesentlichen Administrationsaufwand an das Tool bergeben kann, als auch von den Teammitgliedern, die die Mglichkeit haben ihre persnlichen und beruflichen Events gemeinsam planen und darber hinaus vorgegebene Ereignisse noch weiter detaillieren zu knnen, genutzt werden.
Abbildung 10: Gemeinsamer Online Kalender
93
Abbildung 10 zeigt schematisch einen dementsprechenden Kalender, wobei leicht erkennbar ist, dass zum Beispiel durch farbliche Trennung, klar erkennbar ist welcher Teilnehmer welche Aufgaben zu welchem Zeitpunkt hat. Hierdurch lassen sich Aufgaben und Zeitpunkte bersichtlich darstellen und sind von jedem Benutzer einfach nachzuvollziehen.94
93 94
Hyperoffice (2011) Vgl. Dostal (2007), S. 75 und Gauthier (2004)
50
Berechtigungskonzept Als letzter Punkt ist das Berechtigungskonzept ein wesentliches, oft aber vernachlssigtes, Kriterium bei der Auswahl und dem Einsatz von Kollaborationstools. Benutzer- und Gruppenberechtigungen ermglichen es, vor allem der Projektleitung, Aktionen, Dokumente und Bereiche des Tools individuell an einzelne Personen und Gruppen anzupassen und diese den jeweiligen Personen und Gruppen angepat zur Verfgung zu stellen. Dies ist vor allem bei Dateien und Dokumenten wichtig die sensible Daten beinhalten die nicht von jedem Projektmitglied gesichtet, beziehungsweise verndert werden knnen sollen. Vor allem aber fr virtuelle Teams ist das gezielte Verteilen dieser Informationen bezogen auf Gruppen und Rechte wichtig, um so den administrativen Aufwand gering zu halten. Gerade bei wachsender Anzahl der Projektmitglieder wchst auch der administrative Aufwand fr die Projektleitung was das Verteilen und Zugnglichmachen von Information betrifft. Das Vorhanden sein und Benutzen von Benutzer- und Gruppenberechtigungen kann hierbei von groer Hilfe sein. Es erfordert zwar zu Beginn einen hheren administrativen Aufwand da diese Berechtigungen und Beschrnkungen zunchst hinterlegt werden mssen, erspart aber im Verlauf des Projekts ein Vielfaches an Zeit- und Administrationsaufwand. Auch werden durch klare Berechtigungsstrukturen bereits prventiv Konflikte verhindert die durch mangelnde Berechtigungsstrukturen entstehen knnen, was wiederum Zeit erspart und gerade im Projektmanagement virtueller Teams von wesentlicher Bedeutung ist, da sich Konfliktmanagement hier wesentlich aufwendiger und schwieriger gestaltet als im herkmmlichen Projektmanagement und daher, wenn mglich, vermieden werden sollte.
Auch hier sollen im Folgenden einige Tools vorgestellt werden die den Anforderungen an Kollaborationstools dieser Arbeit gerecht werden.
51
4.2.1 Google Docs

Google Docs stellt eine der Funktionalitten dar die von Google Inc. gratis zur Verfgung gestellt werden. Durch anlegen eines Benutzerkonto erlangt man Zugriff auf die Funktionalitten des Tools. Hier knnen Dokumente, Spreadsheets, Prsentationen, Zeichnungen und Forms angelegt, bearbeitet, geteilt (geshared) oder gelscht werden.
Abbildung 11: Google Drawings
95
Als Kernfunktionalitt bietet Google hier die Mglichkeit gemeinsam mit anderen Benutzern Dokumente und Dateien gleichzeitig zu bearbeiten. Der Verfasser oder die Verfasserin ldt hierzu andere Benutzer und Benutzerinnen ein, ein Dokument gemeinsam mit ihm/ihr zu bearbeiten. So sehen alle Teilnehmer und Teilnehmerinnen in Echtzeit was die anderen Benutzer/Benutzerinnen bearbeiten und welche nderungen am Dokument vorgenommen werden. Dies ermglicht allen Benutzern und Benutzerinnen in Echtzeit zu sehen was an dem Dokument durch andere verndert wird. Zustzlich dazu steht den Benutzern und Benutzerinnen die Mglichkeit offen whrend der Bearbeitung gemeinsam miteinander zu chatten und sich so direkt auszutauschen (siehe Abbildung 12). Bei Dokumenten, Spreadsheets oder Prsentationen sind alle gngigen Funktionalitten die aus vergleichbaren Anwendungen bekannt sind (zum Beispiel Microsoft Office, OpenOffice oder hnlichen).
95
Google Docs (2011)
52
Abbildung 12: Google Drawings Chat
96
Google Docs ist in mehr als 100 Sprachen und als Browser-Tool auf allen Plattformen verfgbar. Es kann mit allen gngigen Browser bedient werden und ist, wie bereits erwhnt, kostenfrei erhltlich. Es ist neben der normal verfgbaren Version auch als Business-Version verfgbar. Diese Version ist kostenpflichtig, wird aber genauso wie die kostenfrei Version von Google gehostet. Dies erspart zwar Infrastrukturkosten, Google rumt sich aber in den allgemeinen Geschftsbedingungen exklusive Nutzungsrechte auf die erstellten Dokumente ein, was im professionellen Gebrauch als Nachteil ausgelegt werden kann.97 hnliche Tools sind Zoho98 oder Adobe Buzzword99.
96 97 98 99
Google Docs (2011) Vgl. Google Docs (2011) Zoho (2011) Adobe Buzzword (2011)
53
4.2.2 Doodle
Doodle ist eine von Doodle AG entwickelte Webanwendung die es den Benutzern und Benutzerinnen ermglicht per Browser Terminfindung durchzufhren. Auch dieses Tool ist kostenfrei verfgbar und benutzbar.
Abbildung 13: leerer Doodle Termin
100
In
Abbildung 13
ist ein leerer Terminvorschlag zu sehen. Man kann erkennen, dass es
hierzu eine Lokalitt gibt (Office) und eine Beschreibung (Task zur Terminfindung bzgl. Eines Konfliktfalls). Auch gibt es einen Urheber (Peter Scheipl). Nun stehen jedem Teilnehmer und jeder Teilnehmerin verschiedene Termine zur Ver100
Doodle (2011)
54
fgung die angewhlt werden knnen und diese Auswahl kann dann gespeichert werden. Nach durchgefhrter Umfrage sind dann fr alle Teilnehmer und Teilnehmerinnen die Eintragung der jeweiligen Benutzer sichtbar (siehe Abbildung 14). Es ist aber nicht nur erkennbar welcher Teilnehmer oder welche Teilnehmerin fr welchen Termin gestimmt hat, sondern auch wie viele Zusagen insgesamt zu einem Termin gegeben wurden.
Abbildung 14: befllter Doodle Termin
101
Zustzlich kann diese Ansicht nicht nur in Tabellen- sondern auch in einer Kalenderansicht angezeigt werden (siehe Abbildung 15). Dort sind die Termine auch in Kalenderform verfgbar.
101
Doodle (2011)
55
Abbildung 15: Doodle Terminkalender
102
Doodle ist frei verfgbar, kann aber auch kostenpflichtig betrieben werden, was funktionelle Vorteile bringt. Unabhngig davon ist Doodle aber wie auch Google Docs durch die Anwendung im Browser vollkommen plattformunabhngig. Es kann mit jedem gngigen Browser betrieben werden und wird dadurch nicht durch das Betriebssystem eingeschrnkt. Doodle bietet darber hinaus auch die Mglichkeit mit gngigen Kalenderprogrammen (zum Beispiel Microsoft Outlook, Google, Exchange, Lotus und anderen) zu interagieren und Termine ber diese auszutauschen. Des Weiteren ist Doodle bereits in ber 30 Sprachen verfgbar.103
102 103
Doodle (2011) Vgl. Doodle (2011)
56
4.2.3 TalkAndWrite
TalkAndWrite bildet ein AddIn zu einem anderen Programm (Skype104) und stellt typische Whiteboard-Funktionalitt zur Verfgung. In TalkAndWrite ist es den Benutzern mglich in Echtzeit ein elektronisches Whiteboard gemeinsam zu nutzen und gleichzeitig VOIP-Funktionalitt zu nutzen.
Abbildung 16: TalkAndWrite
105
Es stehen hier den Benutzern und Benutzerinnen eine Vielzahl an Mglichkeiten zur Verfgung wie das normale Schreiben von Text, das Einfgen von Bildern sowie freihndiges zeichnen. Die nderung die Benutzer und Benutzerinnen am Whiteboard durchfhren sind dann in Echtzeit sofort fr alle anderen sichtbar und ebenfalls bearbeitbar. Wie bereits erwhnt knnen alle Teilnehmer und Teilnehmerinnen auch gleichzeitig per VOIP miteinander kommunizieren. Zustzlich steht auch noch eine Chatfunktionalitt zur Verfgung die es denn Teilnehmern und Teilnehmerinnen ermglicht in Echtzeit Textnachrichten auszutauschen.
104 105
Skype (2011) TalkAndWrite (2011)
57
Auch TalkAndWrite bietet eine kostenfreie Version an, die alle Basisfunktionalitten enthlt, bietet daneben aber auch fr Firmen oder Bildungseinrichtungen zustzlich kostenpflichtige Versionen an die den Funktionsumfang noch erweitern.
58
4.3
Kommunikations-Tools
In diesem Kapitel sollen jene Tools besprochen werden die vorrangig der Kommunikation dienen. Wie bereits in den vorangegangenen Kapiteln erlutert, lsst sich zwischen Kollaboration und Kommunikation im Projektmanagement und vor allem im virtuellen Projektmanagement oft keine genaue Grenze ziehen. Es knnen daher einige Kommunikationstools Charakteristiken aufweisen die bereits im vorherigen Kapitel zu Kollaborationstools besprochen wurden, da wie bereits besprochen sowohl Kommunikation zur Kollaboration notwendig ist wie ebenso Kommunikation eine Art der Kollaboration darstellt. In dieser Arbeit soll Kommunikation daher, soweit mglich, als reiner Informationsaustausch betrachtet werden. Gabler definiert Kommunikation zum Beispiel als Prozess der bertragung von Nachrichten zwischen einem Sender und einem oder mehreren Empfngern.106 Die Art der Informationsbertragung und der Informationsverteilung kann unterschiedlich sein, existiert aber in jedem Fall zumindest ein Sender, ein Empfnger und eine Nachricht. So kann Informationsbertragung unter anderem in synchrone und asynchrone Kommunikation geteilt werden, wobei synchrone Informationsbertragung direkte, unverzgerte Kommunikation bedeutet, bei der Sender und Empfnger praktisch in Echtzeit kommunizieren. Asynchrone Kommunikation hingegen bedeutet, dass eine Zeitverzgerung zwischen dem Senden und dem Empfangen der Nachricht liegen und daher auch eine Antwort zeitverzgert geschickt wird. Sender und Empfnger kommunizieren hier nicht in Echtzeit.107 Unabhngig von der Art der bertragung und der Art der Kommunikation wirft diese im virtuellen Projektmanagement aber Probleme auf die es zu lsen gilt. So sagt unter anderem Krner [] dass Sie im virtuellen Team Distanzen und Kulturgrenzen zu berwinden haben. Daher mssen Sie davon ausgehen, dass bis zu 90% der Information, die Sie bermitteln, nicht verstanden oder falsch interpretiert werden. Umgekehrt verstehen Sie vielleicht nur 10% der Informationen, die Sie bekommen108
106 107 108
Gabler Vgl. Gollubits (2007), S. 53 ff. Krner (2005), S. 4
59
Das heit, dass im Gegensatz zu herkmmlichen Projektmanagement, wo Kommunikation bereits eine wesentliche Rolle spielt, im virtuellen Projektmanagement Kommunikation noch eine weitaus wesentlichere Rolle zufllt. Durch sie gilt es Miverstndnissen prventiv vorzubeugen und Informationen richtig zu bermitteln oder darzustellen. Hierbei bietet die, in der Literatur oft beschriebene, Media Richness Theory 109 Beispiele, welche Medien zu welchen Zwecken geeignet sind und wie fhig sie sind auch komplexe Information zu bertragen.
Abbildung 17: Relative Richness of different media types according to four criteria
110
In Abbildung 17 kann man die Gruppierung der einzelnen Medien (Face-to-Face, Video Conferencing, Synchronous Audio, Asynchronous Audio, E-Mail, Threaded Discussion, Text-Based Chat) nach den vier Kriterien (Feedback, Multiple Issues, Message Tailoring, Emotions) erkennen. Diese werden je nach Ausprgung mit High, bei hoher Anwendbarkeit, bis zu Low, bei schlechter Anwendbarkeit bewertet.
109 110
Vgl. Daft et.al. Newberry (2001), S. 4
60
Wie in Abbildung 18 zu erkennen, knnen natrlich unterschiedliche Medien nach unterschiedlichen Kriterien bewertet werden und diese auf unterschiedliche Art und Weise aufbereitet werden.
Abbildung 18: Media Richness nach Kohlhauser
111
Gleich bleiben aber in beiden Fllen die daraus resultierenden Schlussfolgerungen. So ist sowohl in Abbildung 17 als auch in Abbildung 18 klar zu erkennen, dass Face-to-Face Communication eindeutig als bestes Kommunikationsmedium eingestuft wird. Newberry112 bewertet zum Beispiel unter anderem den Faktor High mit einem numerischen Wert von 3, Medium mit 2 und Low mit 1 und kommt dadurch zu dem Ergebnis, welches in Abbildung 19 zu sehen ist.
Abbildung 19: Numerical Values used to rank media types
113
111 112 113
Kohlhauser (2007), S. 18 Newberry (2001) Newberry (2001), S. 4
61
Daraus wrde sich im Fall von Newberry114 folgendes Resultat hinsichtlich der Bewertung ergeben:
Abbildung 20: Hierarchy of media richness
115
Diese Bewertung soll auch im Folgenden in die Betrachtung der Kommunikationswerkzeuge einflieen.
Folgende Kriterien sollen, unter Rcksichtnahme der bisherigen Erkenntnisse, daher fr Kommunikationstools beim Einsatz und der Auswahl herangezogen werden:
Kommunikationsstruktur Wie bereits erwhnt findet Kommunikation auf verschiedene Art und Weise statt. So kann einerseits synchron, andererseits asynchron kommuniziert werden. Unter dem Gesichtspunkt der Echtzeit bieten beide Kommunikationsmodelle unterschiedliche Vor- und Nachteile. So bietet synchrone Kommunikation den Vorteil ohne Verzgerung kommunizieren zu knnen und somit Antwort- und Entscheidungszeiten zu verringern. Miverstndnisse und Konflikte knnen so auch wesentlich schneller und effizienter beseitigt und sogar vorgebeugt werden. Nachteilig hingegen ist hier dahingegen, dass alle Teilnehmer anwesend sein mssen, was vor allem bei einer zeitlichen Verschiebung zu Problemen fhren kann und daher einen definitiven Nachteil darstellt. Bei asynchroner Kommunikation hingegen ist eine Anwesendheit aller Mitglieder nicht erforderlich. So knnen nicht nur geographische sondern auch
114 115
Newberry (2001) Newberry (2001), S. 4
62
zeitliche Unterschiede bei dieser Art der Kommunikation gut kompensiert werden. Hinzukommt, dass durch die zeitliche Verschiebung mehr Zeit fr die Antwort verbleibt, da diese nicht wie bei Kommunikation in Echtzeit sofort erfolgen muss. Dies erlaubt den Teilnehmern und Teilnehmerinnen die Antwort besser aufzubereiten und genauer zu berdenken. Nachteilig hingegen ist hier der wesentlich langsamere Prozess was das bertragen von Informationen betrifft. Dies wirkt sich natrlich auch auf die Entscheidungsfindung aus die bei asynchroner Kommunikation wesentlich langsamer erfolgt als bei synchroner. Fr Kommunikationstools bedeutet das, dass diese, je nach Einsatzgebiet, eine dieser Kommunikationsformen untersttzen mssen und diese auch vom Funktionsumfang her begnstigen sollten. So sollte natrlich bei asynchroner Kommunikation die Mglichkeit bestehen Informationen nicht nur zuzustellen, sondern auch zu speichern und mglicherweise kategorisiert abzulegen (zum Beispiel E-Mail, Voice-mail, etc.). Vorteilhaft ist es natrlich wenn ein Kommunikationstool die Mglichkeit hat, je nach Bedarf beide Formen der Kommunikation anzubieten und diese bei Bedarf auch einsetzt. So wre es zum Beispiel von Vorteil wenn ein TextChat Programm, welches vorrangig in Echtzeit, also synchron, arbeitet die Mglichkeit htte die Nachrichten auch asynchron zuzustellen, also zum Beispiel bei der Verbindungstrennung eines Teilnehmers. Umgekehrt wre es natrlich auch von Vorteil, wenn grtenteils asynchrone Kommunikation wie zum Beispiel E-Mail ebenfalls in der Lage wre im Bedarfsfall synchron zu funktionieren (zum Beispiel Chatfunktion wenn beide Teilnehmer verfgbar sind). Abschlieend kann festgehalten werden, dass, wie zum Beispiel auch die Media Richness Theory zeigt, synchrone Kommunikation zu einer besseren Verstndigung fhrt als asynchrone Kommunikation da ein direktes Feedback mglich ist, was in den meisten Fllen zur Vermeidung von Missvestndnissen beitrgt und sofortiges Feedback mglich ist bei falscher oder fehlerhafter Kommunikation oder Informationsbertragung.116
116
Vgl. Gollubits (2007), S. 52-57 und Patzak / Rattay (2009), S. 198-201
63
Teilnehmeranzahl und -gruppierung Wie bereits zuvor erlutert, handelt es sich bei Kommunikation meist um Informationsbertragung eines Senders zu einem oder mehreren Empfngern. Bei virtuellem Projektmanagement ist es natrlich in vielen Fllen notwendig an mehrere Empfnger zu kommunizieren. Auch muss es einem oder mehreren dieser Empfnger auch mglich sein Rckmeldung zu liefern oder an der Kommunikation anderweitig mit Feedback beteiligt zu werden. Fr Kommunikationstools zur Untersttzung im virtuellen Projektmanagement bedeutet das, dass es mglich sein muss alle Projektmitglieder in die Kommunikation mit einzubinden, ihnen in selbiger aber auch mglicherweise unterschiedliche Rollen zuzuweisen. So kann es erforderlich sein, dass man nicht nur mehrere Mitglieder anspricht, sondern diese auch auf unterschiedlichen Kanlen, mit unterschiedlicher Prioritt oder verschiedene Informationen an verschiedene Teilnehmer und Teilnehmerinnen verteilt. Hierzu sollte ein Kommunikationstool in der Lage sein der Projektleitung zum Beispiel bestimmte Moderationsmglichkeiten zur Verfgung zu stellen, um diese Funktionalitt bei Bedarf zur Verfgung zu haben. Auch kann es (vor allem bei asynchroner Kommunikation) von Vorteil sein rollen- und gruppenbezogene Funktionen voreinstellen zu knnen, um verschiedene Stakeholder ber verschiedene Kanle mit unterschiedlicher Information versorgen zu knnen (zum Beispiel unterschiedliche Mailverteiler bei EMail, Moderationsfunktionalitt im Voice-Chat, Verschiedene Chatrooms fr verschiedene Projektgruppen, etc.). Dies ist vor allem wichtig, um den administrativen Aufwand der Kommunikation in der Gruppe gering zu halten und eine bersicht zu bewahren welche Information an welche Beteiligten ergeht und in welchem Fortschritt sich der Informations- oder Kommunikationsstand einzelner Gruppen befindet.
64
Art der Kommunikation Bei der Art der Kommunikation ist auchm im Sinne der Media Richness, zwischen reicheren und rmeren Medien zu unterscheiden, vor allem was die Mglichkeit betrifft komplexe Informationen zu bertragen. So kann bei zwischenmenschlicher Kommunikation zum Beispiel zwischen verbaler und nonverbaler Kommunikation unterschieden werden. Bei der Betrachtung von Tools zur Kommunikationsuntersttzung im virtuellen Projektmanagement bedeutet das vor allem die Art und Weise wie Kommunikation bertragen wird. So kann zum Beispiel zwischen visueller/graphischer, sprachlicher und textueller Kommunikation unterschieden werden. Natrlich kann mit unterschiedlicher Art der Kommunikation auch unterschiedlich komplexe Kommunikation stattfinden. Diese Unterschiede bergen natrlich auch dementsprechende Risiken oder Fehleranflligkeiten. So ist es bei verbaler, synchroner Kommunikation (zum Beispiel Telefon, VOIP, etc.) wesentlich einfacher und unkomplizierter Missverstndnisse auszurumen und eine groe Menge an Information zu bertragen. Dies macht die Kommunikationsform zu einer sehr effizienten im Vergleich zu textueller, asynchroner Nachrichtenbertragung wie E-Mail, Brief, Fax, etc. Auch kann bei verbaler Kommunikation Metainformation wie Emotionen und Gefhlslage der Beteiligten wesentlich einfacher bertragen werden als zum Beispiel bei textueller Kommunikation. Im Hinblick auf Kommunikationstools bedeutet das, dass je komplexer die Mglichkeiten zur bertragung sind, desto besser kann Information bermittelt werden und desto wahrscheinlicher ist es, dass die bermittelte Information auch richtig verstanden und richtig interpretiert wurde. Es ist aber gerade beim Einsatz von Tools darauf zu achten, dass die verschiedenen Arten der Kommunikation ressourceneffizient verwendet werden, um einem sogenannten Overhead vorzubeugen. So wre es zum Beispiel nicht sinnvoll fr eine Empfangsbesttigung eine Videokonferenz einzuberufen. Hierzu reicht natrlich auch asynchrone, textuelle Kommunikation wie zum Beispiel E-Mail, SMS oder dergleichen.117
117
Vgl. Kohlhauser (2007), S. 12 ff. und Pazderka (2008), S. 210 ff. und Dostal (2007), S. 93 f. und Gollubits (2007), S. 49 ff.
65
Technische Anforderungen Wie bereits im Kapitel 4 erlutert ist der technologische Aspekt des Tools auf keinen Fall zu unterschtzen. Wie auch bei Kollaborationstools, ist es vor allem im virtuellen Projektmanagement von Relevanz, dass die jeweiligen Kommunikationstools einigen wesentlichen Kriterien folgen. Neben Plattformunabhngigkeit und Interoperabilitt sind auch Mehrsprachenfhigkeit und intuitive Bedienung wesentliche technische Anforderungen an Kommunikationstools im virtuellen Projektmanagement. Die Mitglieder mssen das jeweilige Tools unabhngig von Betriebssystem, Arbeitsumgebung oder Infrastruktur bedienen und benutzen knnen. Von besonderem Vorteil sind hier Tools die mit Benutzerkonten arbeiten, bei denen die technische Basis immer gleich ist, benutzerspezifische Daten (zum Beispiel Kontaktdaten, Gesprchsverlaufe, gespeicherte Daten, etc.) aber erst beim Anmelden geladen werden. So ist es dem jeweiligen Benutzer mglich unabhngig von Infrastruktur und technischen Gegebenheiten mit den Mitgliedern zu kommunizieren. Diese technischen Vorraussetzungen mssen auch hier vor allem durch die Projektleitung evaluiert und vorgeschrieben werden. Hier ist es bei der Auswahl des spter eingesetzten Tools von groer Wichtigkeit, dass die Grundvoraussetzung aller Projektmitglieder und -mitgliederinnen und Teilnehmer sowie Teilnehmerinnen erhoben wird, um spter ein Tool zur Verfgung stellen zu knnen, welches zumindest hinsichtlich der Mindestanforderungen die Kriterien aller Teilnehmer und Teilnehmerinnen erfllt. Wird hier nicht nachhaltig evaluiert kann es vorkommen, dass einige Teilnehmer und Teilnehmerinnen durch ihre technischen Grundvoraussetzungen bereits vorab von der spteren Kommunikation ausgeschlossen werden. Dies wre natrlich ein weitreichender Nachteil den es zu vermeiden gilt da es dadurch zu betrchtlichen Komplikationen und mglicherweise zu einem erheblichen Mehraufwand kommen kann.
Auch in diesem Kapitel werden im Folgenden kurz einige Tools beispielhaft vorgestellt.
66
4.3.1 Skype
Skype ist wie bereits kurz erwhnt ein Programm zur Internettelephonie, fr Textchat und Videoanrufe. Es ist darber hinaus mglich mit mehreren Teilnehmern und Teilnehmerinnen gleichzeitig zu chatten, zu sprechen oder auch Videokonferenzen abzuhalten. Darber hinaus bietet Skype die Mglichkeiten auch Dateien zu bertragen oder Mobil- und Festnetznummern anzurufen sowie SMS zu versenden.
Abbildung 21: Skype
118
Skype ist in der derzeitigen Version fr die Betriebssysteme Windows, Linux und Mac erhltlich. Zustzlich kann das Programm auf einer Vielzahl von Mobiltelefonen installiert werden sowie auch auf einigen Fernsehgerten. Skype bietet wie andere Tools neben einer kostenfreien Version auch kostenpflichtige Versionen fr Firmen aller Gren. In diesen kostenpflichtigen Versionen stehen den Benutzern dann natrlich wesentlich mehr Funktionalitten zur Verfgung. 119 Skype ist in mehr als 30 Sprachen erhltlich und hnliche Produkte sind unter anderem TeamSpeak120 oder Ventrilo121 .
118 119 120 121
Skype (2011) Vgl. Skype (2011) TeamSpeak (2011) Ventrilo (2011)
67
4.3.2 Pidgin
Pidgin ist ein open-source Chatprogram, das fr die Betriebssysteme Windows, CentOS/RHEL, Fedora, Mac OS X und Ubuntu verfgbar ist. Es ermglicht den Teilnehmern Textnachrichten zu schicken und zu empfangen und Echtzeit miteinander zu chatten. Zuszlich haben die Benutzer wie bei anderen Chatprogrammen auch die Mglichkeit Dateien zu bertragen.
Abbildung 22: Pidgin
122
Pidgin untersttzt mehr als 60 Sprachen und bietet darber hinaus die Mglichkeit mit anderen Chatprogrammen zu interagieren (zum Beispiel AIM, Google Talk, IRC, Yahoo! und anderen). Zustzlich zu den bereits standardmig untersttzen Programmen bietet Pidgin eine Vielzahl an Plugins die es ermglichen unter anderem mit dem Instant Messaging System von Facebook zu kommunizieren oder an andere gngige Programme wie Skype oder Xfire anzuknpfen oder zustzliche Sicherheitsfunktionen zu aktivieren. hnliche Funktionalitten stellen unter anderem Programme wie AIM 123, Google Talk124 oder MSN125 zur Verfgung.126
122 123 124
Pidgin (2011) AIM (2011) Google (2011)
68
4.3.3 Thunderbird
Wie auch Skype und Pidgin, steht auch Thunderbird in dieser Arbeit selbstverstndlich stellvertretend fr die dahinterstehende Technologie, in diesem Fall EMail. Thunderbird ist ein von Mozilla entwickeltes Tool das ebenfalls gratis erhltlich ist und primr ein Email-Client ist.
Abbildung 23: Mozilla Thunderbird
127
Thunderbird bietet die Mglichkeiten neben den gngigen Funktionen eines EmailClients, Konversationen auch als Konversations-Thread anzuzeigen. Darber hinaus knnen eine Vielzahl von Emailkonten in Thunderbird eingebunden werden. Ebenfalls integriert das Programm neben normalen Emailfunktionalitten auch noch einen Kalender und Aufgabenlisten die ebenfalls mit den gngigen Programmen in dieser Kategorie kooperieren (unter anderem zum Beispiel Microsoft Outlook, Google Mail oder dergleichen). Darber hinaus steht Thunderbird fr die Betriebssysteme Windows, Mac OS X und Linux zur Verfgung. Thunderbird wird in ber 40 Sprachen angeboten. 128
125 126 127 128
MSN (2011) Vgl. Pidgin (2011) Thunderbird (2011) Vgl. Thunderbird (2011)
69
Projektphasen
In diesem Kapitel sollen die klassischen Projektphasen (Projektstartphase, Projektplanungs- und Projektdurchfhrungsphase, Koordinations- und nderungsphasen und Projektabschlussphase) hinsichtlich der Probleme aus Kapitel 3 im virtuellen Projektmanagement betrachtet werden. Zur etwaigen Lsung der Probleme sollen die Tools aus Kapitel 4 herangezogen werden. Um die Probleme der jeweiligen Phase zu identifizieren und im Weiteren dann besprechen zu knnen, sollen zu Beginn jedes Kapitels die Unterschiede der Phase im herkmmlichen Projektmanagement zum virtuellen Projektmanagement erarbeitet werden. Auf Basis dieser Unterschiede sollen dann unter Bercksichtigung der Kriterien und Problemfelder aus Kapitel 3 die jeweiligen Problemstellungen der Projektphase identifiziert werden. Anhand der Tools aus Kapitel 4 und der Erkenntnisse aus Kapitel 3 sollen dann in einem weiteren Schritte Lsungen fr die jeweiligen Problemstellungen angeboten werden um in einem letzten Schritt diese auf ihre Ntzlichkeit zu untersuchen.
70
5.1
Projektstartphase
In der Literatur wird die Projektstartphase einhellig als eine der wichtigsten Phasen im Projektmanagement erachtet, sowohl im herkmmlichen, als auch im virtuellen Projektmanagement. So schreiben hier Patzak / Rattay unter anderem Die Projektstartphase ist sowohl in traditionellen als auch in virtuellen Projektteams kritisch, d.h. dass vom Start eines Projekts der Erfolg oder Misserfolg wesentlich abhngt129. Sie regen fr die Unterteilung der Projektstartphase hier die Punkte Projektentstehung und Projektumfeld (Projektvorlauf), Projektbeauftragung und startprozess, Aufbau der Projektorganisation und Aufbau von Projektteams an.
Diese Punkte sollen im Folgenden einzeln unter dem Gesichtspunkt der Virtualitt betrachtet werden um so deren Problemfelder zu identifizieren und besprechen zu knnen.
5.1.1 Projektentstehung und Projektumfeld (Projektvorlauf)

In dieser Phase der Projektstartphase kommt es zur Entstehung des Projekts und es wird analysiert ob ein vorgeschlagenes Projekt durchfhrbar ist und insofern es durchfhrbar ist wie dieses grob aussehen wird. Patzak / Rattay regen hier unter anderem oder Werkzeuge die wie eine einer
Projektwdigkeitsprfung,
Projektvorbereitungen
Erstellung
Projektumfeldanalyse an.130 Hier gilt es im Zuge dieser Arbeit wiederum zwischen relevanten und nicht relevanten Themen zu unterscheiden. Hierbei ist wichtig inwieweit die jeweiligen Themen gerade das virtuelle Projektmanagement betreffen. Die Wichtigkeit fr das Projektmanagement im Allgemeinen soll hier nicht hinterfragt werden.
129 130
71
So schreiben Patzak / Rattay in dieser Phase Das rechtzeitige Erkennen, dass es sich bei einer Idee um ein Projekt handeln knnte, die Beurteilung der Projektwrdigkeit und die gezielte berfhrung der Idee zu einem Projekt sind die wesentlichen Managementaufgaben in dieser Phase der Projektentstehung.131 Wie sie beschrieben, handelt es sich in dieser Phase also hauptschlich um eine Managementmethode. Dies lsst des Weiteren bereits erahnen, dass sich hier die Methoden des herkmmlichen Projektmanagements kaum oder nur gering von denen des virtuellen Projektmanagements unterscheiden werden. So schreiben Patzak / Rattay zur Projektwrdigkeitsprfung weiter, dass diese [] eine systematische Beurteilung, ob eine Idee als Routineaufgabe oder als Projekt durchgefhrt werden soll132 erlaubt. Es wird eine Projektidee also anhand bestimmter Kriterien und Merkmalen beurteilt und im Weiteren anhand dieser dann eine Entscheidung getroffen. Dieser Prozess wird sich auch im virtuellen Projektmanagement kaum oder gar nicht von dem im herkmmlichen Projektmanagement unterscheiden da zu diesem Zeitpunkt noch keine oder nur sehr geringe Virtualitt herrscht. Im Zuge der Projektvorbereitung und der Projektumfeldanalyse wird hingegen bereits mehr Interaktion verlangt, vor allem wenn es darum geht mit Hilfe von Experten und Expertinnen oder Inputgebern/Inputgeberinnen Rcksprache zu halten oder Informationen auszutauschen. Gerade bei der Projektumfeldanalyse gilt es alle wesentlichen Einflussfaktoren auf das zuknftige Projekt zu identifizieren und auch zu bewerten. Hierzu kann es, vor allem wenn Know-How lokaler Mitarbeiter und Mitarbeiterinnen oder Experten beziehungsweise Expertinnen notwendig ist, bereits notwendig sein virtuell zu kommunizieren oder zu kollaborieren.133 In dieser frhen Phase lsst sich daher bereits erkennen, dass es notwendig sein kann, bereits frh im Projekt, noch in der Projektentstehung, auf virtuelle Arbeiten vorbereitet zu sein. In dieser frhen Phase werden aber noch keine umfassenden
131 132 133
Patzak / Rattay (2009), S. 85 Patzak / Rattay (2009), S. 91 ebd.
72
Tools zur Verfgung stehen und es sollten daher gerade einfache und kostenfreie Werkzeuge in Betracht gezogen werden um diese Probleme zu lsen. So knnte es in dieser Phase hilfreich sein ein Kommunikationstool wie beispielsweise Skype (siehe Kapitel 4.3.1) einzusetzen, welches des Weiteren auch die Mglichkeit hat ber Plugins oder Addins weitere Kollaborationsfunktionen zur Verfgung zu stellen (wie zum Beispiel TalkAndWrite, siehe Kapitel 4.2.3).
5.1.2 Projektbeauftragung und startprozess

Die wichtigen Elemente dieser Phase sind laut Patzak / Rattay vor allem die Projektdefinition oder Projektbeschreibung, der Projektstartprozess und vor allem die Kommunikationsformen im Projektstartprozess. Bei der Projektdefinition ist vor allem das Definieren von klaren Projektzielen von wesentlicher Bedeutung. Diese knnen im Zuge ihrer Definition in unterschiedliche Kategorien gegliedert werden oder anhand ihrer Art unterschieden werden, im Wesentlichen kann aber gesagt werden, dass hier unterschieden wird welche Inhalte fr das Projekt wesentlich sind (Projektziele) und welche definitiv nicht (Nicht-Ziele).134 In diesem Punkt ist sich die Literatur einig, dass das Vorhandensein klarer, zuvor definierter und kommunizierter Projektziele nicht nur ein wesentlicher Erfolgsfaktor des herkmmlichen Projektmanagements, sondern vor allem fr das virtuelle Projektmanagement von erheblicher Bedeutung ist. So zeigt unter anderem Gollubits, dass bei den Erfolgsfaktoren (siehe Abbildung 24) klare und vereinbarte Ziele den wichtigsten Erfolgsfaktor darstellen und das unter den 10 hufigsten Problemen bei verteilten Projekten (siehe Abbildung 25) unklare oder missinterpretierte Ziele das Hauptproblem darstellen. Das bedeutet weiter, dass das Definieren von Zielen daher auch im virtuellen Projektmanagement von wesentlicher Bedeutung ist. Auch hier ist wie bereits in der vorherigen Phase noch nicht mit einer ausreichenden technischen Infrastruktur zu rechnen warum es sich auch in dieser Phase empfiehlt auf kostenfreie und relativ unkomplizierte Hilfsmittel zurckzugreifen. Im konkreten Fall knnten Foren oder Diskussionthreads zur Zielkoordination und kommunikation verwendet werden da hier der Bearbeitungsverlauf klar ersichtlich ist und eine direkte synchrone Kommunikation oft nicht unbedingt erforderlich ist.
134
Vgl. Patzak / Rattay (2009), S. 116 ff.
73
Abbildung 24: Potential project success factors
135
Abbildung 25: Top 10 potential problems of distributed projects
136
135 136
Gollubits (2007), S. 72 Gollubits (2007), S. 73
74
Beim Projektstartprozess hingegen handelt es sich, wie bereits bei der Projektwrdigkeitsprfung eher um eine Systematik. Hier soll festgelegt werden welche Prozessschritte im Zuge des Projektstarts zu erfolgen haben und in welcher Reihenfolge. Dies ist zwar ein wichtiger Schritt und dient bei Unternehmen deren Hauptgeschft sich in Projekten abwickelt vor allem dazu keine der wichtigen Schritte zu vernachlssigen oder zu vergessen, ist aber im virtuellen Projektmanagement von hnlicher oder gleicher Bedeutung und unterliegt daher der selben Systematik. Daher ist in dieser Phase auch nicht oder nur vereinzelt mit zustzlichen Problemen zu rechnen.137 Ganz im Gegensatz hierzu stehen die Kommunikationsformen im Startprozess die von wesentlicher Bedeutung sind fr das Projektmanagement und sich von den Kommunikationsformen des virtuellen Projektmanagements wesentlich unterscheiden. Hier schlagen Patzak / Rattay Werkzeuge wir Kick-off-Meeting, Projektstart-Besprechung oder Projektstart-Workshop vor. Wesentlich fr das virtuelle Projektmanagement ist hier nicht die Unterscheidung der einzelnen Formen, sondern deren gemeinsame Eigenschaft, das physische Zusammentreffen aller Beteiligten.138 So schreiben unter anderem Patzak / Rattay es ist [] unbedingt anzuraten, am Beginn des Projekts ein gemeinsames, nicht-virtuelles Treffen zu organisieren, in dessen Rahmen auch die persnlichen Kontakte aufgebaut werden sollten. Entsprechender Platz ist durch den Projektleiter einzuplanen.139 Auch Dostal schreibt Fr das Team und seine Entwicklung ist es wichtig, dass die Beteiligten sich bereits vor Beginn der eigentlichen Projektarbeit zumindest einmal persnlich treffen, um dadurch die Weichen fr eine gute Zusammenarbeit aufzustellen. Dies vereinfacht die virtuelle Zusammenarbeit whrend der Projektlaufzeit in hohem Mae.140
137 138
Vgl. Patzak Rattay (2009), S. 116 ff. Vgl. Patzak / Rattay (2009), S. 140 ff. und Gollubits (2007), S. 51 ff. und Dostal (2007), S. 86 ff. Kohlhauser (2007), S. 12 ff. Patzak / Rattay (2009), S. 204 Dostal (2007), S. 86
139 140
75
Auch zeigt die Media Richness Theory (siehe Kapitel 4.3), dass die sogenannte Face-to-Face-Kommunikation die informationsreichste Art der Kommunikation darstellt, was wie bereits besprochen, gerade in der Projektstartphase am wichtigsten ist.141 Dennoch wird auch klar gemacht, dass es in vielen Fllen des virtuellen Projektmanagements nicht mglich ist Face-to-Face-Kontakte zu ermglichen. Ist ein persnliches, nicht-virtuelles Treffen nicht mglich, so knnte auch, unter Bercksichtigung der Bedrfnisse der Teilnehmer und Teilnehmerinnen, ein virtueller Projekt-Kickoff stattfinden. Hierzu wre es notwendig bei diesem Treffen den fehlenden persnlichen Kontakt so gut mglich zu ersetzen um den Teilnehmern und Teilnehmerinnen so zu ermglichen persnliche Beziehungen untereinander aufzubauen. Hierzu kann, wie in Kapitel 4.3.1 und auch Kapitel 4.3.2 beschrieben, direkte, synchrone Kommunikation uerst hilfreich sein. Um den Mitgliedern zu ermglichen den fehlenden persnlichen Kontakt zu kompensieren, ist es notwendig, dass die Kommunikation so direkt und persnlich wie mglich gestaltet wird. Hierzu bieten sich daher unter anderem Videokonferenzen und persnliche Telefongesprche an, um den Mitgliedern zu ermglichen sich untereinander kennenzulernen.
5.1.3 Aufbau der Projektorganisation

Bei der Projektorganisation handelt es sich wie bereits in Kapitel 2.3 und 3.5 beschrieben um die Regeln, Werte und Normen die notwendig sind um ein effizientes Zusammenarbeit im Projekt zu ermglichen. Wie in Kapitel 3.5 bereits ausgefhrt wird dieser aber im Zuge des virtuellen Projektmanagements auf Grund des geringen Unterschiedes zum herkmmlichen Projektmanagement nur wenig Bedeutung zugemessen. Die wesentlichen Punkte dieser Phase, wie sie Patzak / Rattay beschreiben, wie unter anderem das Definieren von Rollen und projektbezogenen Rollen oder etwaige Rollenkonflikte sind zwar auch hier weder im herkmmlichen noch im virtuellen Projektmanagement zu vernachlssigen, die Vorgangsweise unterscheidet sich aber in beidem kaum und ist daher nicht Gegenstand dieser Arbeit.
141
Vgl. Daft / Lengel (1986), S. 554 ff.
76
Ein Punkt, den Patzak / Rattay in dieser Phase anregen, soll jedoch genauer betrachtet werden, das Eingliedern des Projekts in die bestehende Projektorganisation. Nicht weil sich die Vorgehensweise im virtuellen Projektmanagement mageblich von der im herkmmlichen unterscheidet, sondern weil hier auf Grund der Virtualitt zustzliche Komplikationen auftreten knnen. In dieser Phase ist es vor allem wichtig die richtige Organisationsform fr das zuknftige Projekt zu whlen.142 Patzak / Rattay schreiben hierzu: Es ist ein der wesentlichen Aufgaben in der Projektstartphase, die optimale Projektorganisationsform und damit die Eingliederung in die bestehende Unternehmensorganisation festzulegen.143 Hierbei ist es aber hinsichtlich des virtuellen Projektmanagements nicht von Bedeutung welche Organisationsform gewhlt wird oder wie dessen Vor- und Nachteile aussehen sondern, dass beim Auswhlen der Organisationsform ein wesentliches Augenmerk auf die Virtualitt der Projektorganisation gelegt wird. Es mssen die alternativen Arten der Kommunikation, Kollaboration und Entscheidungsfindung bei der Wahl der Organisationsform bercksichtigt werden um nicht zustzliche Komplikationen bereits in der Projektstartphase zu verursachen. Diese wrde sich vor allem im spteren Verlauf des Projekts massiv auswirken.
5.1.4 Aufbau von Projektteams

Beim Aufbau von Projektteams gilt es insbesondere einen Projektleiter/ eine Projektleiterin und ein Projektteam auszuwhlen. Hierbei muss natrlich auf die Formen der Projektteam-Organisation sowie auch auf die Phasen der Teamentwicklung Rcksicht genommen werden um eine optimale Teambildung zu ermglichen. Beim Aufbau und der Auswahl des Projektteams handelt es sich wie bereits bei der Definition der Projektziele um einen wesentlichen Erfolgsfaktor des Projektmanagements.
142 143
Vgl. Patzak / Rattay (2009), S. 143 ff. Patzak / Rattay (2009), S. 169
77
Patzak / Rattay schreiben hierzu: Die dem Projektinhalt entsprechende Teamzusammensetzung ist eine wichtige Einflussgre fr den Projekterfolg. Daher sollte bei der Auswahl der Teammitglieder darauf geachtet werden, dass die wesentlichen Interessenlagen und die notwendigen Qualifikationen im Projektteam vertreten sind.144 Sowohl die Rolle des Projektleiters beziehungsweise der Projektleiterin als auch die Zusammensetzung des Projektteams wurden in dieser Arbeit bereits in den Kapiteln 2.1 beziehungsweise 3.3 fr die Projektleitung und in den Kapiteln 2.2 und respektive 3.4 fr das Projektteam besprochen. Sie sollen hier also nicht noch einmal angefhrt werden. Es soll lediglich wiederholt werden, dass die Auswahl des richtigen Projektleiters beziehungsweise der richtigen Projektleiterin und einem passenden Projektteam wie bereits erwhnt wesentlichen Einfluss auf den Projekterfolg nimmt. Zu den Formen der Projektteam-Organisation kann wie bereits bei der Projektorganisation gesagt werden, dass es hier bei der Auswahl auf die speziellen Gegebenheiten der Virtualitt zu achten gilt. Vor allem bei der Auswahl der ProjektteamOrganisation sind Kommunikation und Kollaboration wichtige Elemente beim Auswhlen der richtigen Organisationsform und drfen daher keinesfalls vernachlssigt werden. Den Phasen der Teamentwicklung soll hingegen spezielle Aufmerksamkeit gewidmet werden, da auch hier bei Vernachlssigung mit massiven Problemen im spteren Projektverlauf zu rechnen ist. Wie bereits in Kapitel 2.2 besprochen, ist bei virtuellen Projektteams vor allem in der Teamentwicklung, und dort vor allem in der Forming- und Storming-Phase mit vermehrten Konflikten und Komplikationen zu rechnen, verglichen mit herkmmlichem Projektmanagement. Gerade das Fehlen von persnlichen Kontakten, vor allem beim Ausfall des Startworkshops (siehe Kapitel 5.1.2), kann hier zu erheblichen Problemen bei der Teambildung fhren. Diese gilt es von vornherein gegenzusteuern und mit den dementsprechenden Manahmen diese zustzlichen Probleme zu vermindern oder sogar prventiv zu verhindern. Eine Mglichkeit ist natrlich die Kompensation durch technische Hilfsmittel. So knnen, wie in Kapitel 5.1.2 beschrieben, unter anderem Videokonferenzen oder
144
78
Telefonkonferenzen, gerade also direkte Kontakte, helfen, diese persnlichen Kontakte zu knpfen und aufrecht zu erhalten. Eine weitere Methode liefert unter anderem zum Beispiel Grunewald der hier anregt, dass vor allem in den ersten Phasen der Gruppenentwicklung auch Fhrungskrfte eine wesentliche Mitwirkungspflicht haben. Er schreibt hierzu: In der Forming-Phase einer virtuellen Ag. sind von Fhrungskrften und/oder Prozessberatern groe Anstrengungen ntig, um die einander zumeist unbekannten Experten zusammenzufhren.145 Er meint weiter, dass bereits in der Auswahl der Teammitglieder durch die Projektoder Teamleitung eine wesentliche Basis gelegt wird fr eine sptere positive, aber auch negative, Zusammenarbeit. Neben dem eigentlichen Fachwissen sind laut Grunewald auch positive Erfahrungen mit IT-Technologien unbedingt erforderlich. Er geht noch einen Schritt weiter und nennt abgesehen davon noch unerlssliche Persnlichkeitsmerkmale dieser Mitglieder wie unter anderem: Selbstmotivation, Zielorientierung oder auch [] der Wille und die Fhigkeit, trotz rumlich-zeitlicher Distanz mit den anderen Gruppenmitgliedern offen, ehrlich, vertrauensvoll, rechtzeitig und umfassend zielorientiert zu kommunizieren.146
Auch im weiteren Verlauf der Teambildung ist es laut Grunewald unbedingt erforderlich, dass die Teamleitung aktiv zur positiven Entwicklung der Gruppe beitrgt. So sind in der Storming-Phase latente Konflikte konkret anzusprechen und somit von vorneherein zu besprechen so wie in der Norming-Phase gezielt Konsensentscheidungen zu erwirken um so schneller in die Performing-Phase zu kommen, da laut Grunewald gerade in virtuellen Teams ein Konsens wichtig ist um schnellstmglich in die Performing-Phase zu kommen.147 Zusammenfassend kann gesagt werden, dass im Falle eines Fehlens eines persnlichen Projekt-Kickoffs mit Sicherheit sowohl der Einsatz von geeigneten Tools, als auch das Verwenden der situationsbedingt richtigen Methoden unbedingt erforderlich ist um den Gruppenzusammenhalt aufzubauen und zu strken.
145 146 147
Grunewald (2001), S. 4 Grunewald (2001), S. 4 f. Vgl. Grunewald (2001), S. 4 ff.
79
Auch hier gibt es eine groe bereinstimmung, dass gerade Vertrauen in der Teamzusammenarbeit von grter Wichtigkeit ist und ein fehlendes Vertrauen, welches meist durch fehlenden persnlichen Kontakt begrndet ist, zu groen Konflikten und Problemen in der Zusammenarbeit fhren kann was meist einen wesentlichen Einfluss auf den Projekterfolg hat.148 Es ist daher vor allem an der Projektleitung, insofern es nicht mglich ist zumindest zum Projektstart ein persnliches Treffen der Involvierten zu ermglichen, was wie bereits besprochen auf jeden Fall anzuraten ist, alle zur Verfgung stehenden Mglichkeiten auszuschpfen um gerade in der Startphase mglichst viel Vertrauen der Projektmitglieder in das Projekt und in die Projektleitung zu schaffen um so ein mglichst effizientes und produktives Arbeiten in der Zukunft zu ermglichen. Zusammenfassend bleibt zur Projektstartphase zusagen, dass hier die wesentliche Basis fr den weiteren Projektverlauf gelegt wird. Eine Vernachlssigung von den hier angefhrten Punkten oder Nachlssigkeit auf Grund von Routine zeigt sich oft erst spter im Projektverlauf. Dort sind die anfnglich gemachten Fehler oder Nachlssigkeiten aber meist nicht mehr oder nur unter Aufwendung erheblicher Zeit- und Kostenberschreitung mglich. Vor allem im virtuellen Projektmanagement ist es wichtig diese Basis sorgfltig und durchdacht aufzubauen um die zustzlichen Komplikationen die durch die Virtualitt im spteren Projektverlauf auftreten so gut wie mglich bereits in dieser frhen Phase zu verhindern oder Handlungsspielraum dafr einzuplanen.
148
80
5.2
Projektplanungs- und -ausfhrungsphase
Auch in diesem Kapitel wird nicht nher auf die Elemente und Prozesse des herkmmlichen Projektmanagements (zum Beispiel Ressourcenplanung, Kosten- und Finanzmittelplanung, Risikoplanung, etc.) eingegangen, insofern diese nicht auch fr virtuelles Projektmanagement relevant sind. Hier beschreiben Patzak / Rattay unter anderem die Gestaltung des Projektumfelds, die Projektplanung, die Gestaltung der Projektorganisation und die Gestaltung der Teamarbeit als wichtige Elemente dieser Phase. In dieser Phase werden nach den ersten groben Planungen und des formalen Projektstarts die wesentlichen Elemente weiter ausgebaut und langsam mit der eigentlichen Projektarbeit begonnen.149 Auch sollen nicht die einzelnen Methoden bewertet werden, sondern im Wesentlichen das Wesen der jeweiligen Methoden und Prozesse, hinsichtlich ihrer Problematiken das virtuelle Projektmanagement betreffend, betrachtet werden.
5.2.1 Gestaltung des Projektumfelds

Bei der Gestaltung des Projektumfelds regen Patzak / Rattay vor allem zwei Punkte an, das Projektmarketing und der Umgang mit Lieferanten oder Lieferantinnen. Hierbei ist aber wieder nicht jeweilige Ausprgung, sondern vielmehr der Unterschied zwischen herkmmlichem und virtuellem Projektmanagement von Bedeutung. Im Zuge des Projektmarketings wird vor allem Bezug auf die in der Umfeldanalyse (siehe Kapitel 5.1.1) erhobenen projektrelevanten Interessensgruppen eingegangen. Der wesentlichste Punkt des Projektmarketings stellt hier laut Patzak / Rattay der Nutzen des jeweiligen Beteiligten dar. Hier gilt es im Zuge des Projektmarketings die jeweiligen Interessensgruppen ber den Verlauf ihres jeweiligen Nutzens zu informieren.150 Hier unterscheidet sich das herkmmliche Projektmanagement kaum vom virtuellen Projektmanagement, da auch im herkmmlichen Projektmanagement damit zu rechnen ist, das Interessensgruppen sowohl zeitlichen als auch geographischen Unterschieden unterliegen.
149 150
Vgl. Patzak / Rattay (2009), S. 205 ff. ebd.
81
Patzak / Rattay regen daher hier bereits von Anfang an eine IT-untersttzte Informationsverteilung an, die sich nach dem Nutzen des jeweiligen Beteiligten oder der jeweiligen Beteiligten richtet. Dies gilt daher gleich bedeutend fr das virtuelle Projektmanagement. Beim Auswahl der Lieferanten und Lieferantinnen und dem Abschluss von Vertrgen mit diesen, ist wie bereits beim Projektmarketing mit wenig Unterschied zwischen herkmmlichem und virtuellem Projektmanagement zu rechnen. Auch hier muss im herkmmlichen Projektmanagement davon ausgegangen werden, dass es geographische oder zeitliche Unterschiede der Projektorganisation mit den Vertragsparteien gibt. Es ist hier also kein wesentlicher Handlungsbedarf im virtuellen Projektmanagement zu identifizieren.
5.2.2 Projektplanung
Die Projektplanung, beziehungsweise die einzelnen Teile der Projektplanung wie unter anderem die Aufgabenplanung, die Qualittsplanung, die Ablauf- und Terminplanung oder die Ressourcenplanung stellen natrlich wesentliche und wichtige Bestandteile des Projektmanagements dar.
Abbildung 26: Potential project success factors
151
151
Gollubits (2007), S. 72
82
So stellt zum Beispiel Gollubits fest, dass effektive Projektplanung nach der Zieldefinition der wichtigste Erfolgsfaktor im virtuellen Projektmanagement ist. Dennoch ist auch hier der Unterschied zwischen herkmmlichem und virtuellem Projektmanagement wesentlich und nicht die Arten der Planung oder deren allgemeinen Charakteristika.152 Zu den Projektplanungsarten kann bergreifend festgehalten werden, dass diese, unabhngig von der Planungsmethode, fast immer demselben Muster folgen. Mitglieder des Projekts haben, um den jeweiligen Planungsschritt abzuschlieen, bestimmte Informationen anzugeben. Diese Informationen sollen gespeichert werden oder abgelegt werden um spter zu bestimmten Anlssen zur Verfgung stehen. Hierbei steht auer Frage, dass zum Speichern dieser Informationen ein Projektmanagementtool (siehe Kapitel 4.1) verwendet werden sollte. Dieses stellt die geplanten Informationen sofort all jenen zur Verfgung die die geplante Information zur Arbeit oder weiteren Planung bentigen. Hier unterscheidet sich aber herkmmliches Projektmanagement kaum von virtuellem Projektmanagement. Auch im virtuellen Projektmanagement spielt Projektplanung eine wesentliche Rolle, die Vorgehensweise ist aber die Selbe. In dieser Phase erwhnen Patzak / Rattay zustzlich zur herkmmlichen Projektplanung aber auch die Planung des Managementsystems. Hierzu regen sie unter anderem folgende Punkte an: die Projektorganisation, das Projektumfeld und die Projektrisiken (d.h. deren Begegnung), das Projektinformationssystem (Datenerfassung, Kommunikation), das Projektmarketing, das Beschaffungsmanagement (Vertragsmanagement, Claim Management, ) und das Qualittsmanagement (Sicherung der Management-Qualitt).153
Es soll in diesem Kapitel auf die Punkte Projektorganisation, Projektumfeld und Projektmarketing aber nicht weiter eingegangen werden, da diese bereits im Zuge dieser Arbeit beschrieben wurden. Das Beschaffungsmanagement wird, wie unter anderem die Vertragsverhandlungen mit Lieferanten, in dieser Arbeit vernachlssigt. Nicht da es keinen wesentlichen Bestandteil des Projektmanage-
152 153
Vgl. Gollubits (2007), S. 72 f. Patzak / Rattay (2009), S. 218
83
ments darstellt, sondern da hier kein wesentlicher Unterschied zwischen herkmmlichem und virtuellem Projektmanagement besteht. Auf das Projektinformationssystem soll hingegen in Kapitel 5.2.3 nher eingegangen werden. Es verbleibt daher lediglich das Qualittsmanagement im Zuge der Planung des Managementsystems. Zustzlich zur herkmmlichen Qualittsplanung, welche sich hauptschlich nach der Qualittspolitik des jeweiligen Unternehmens richtet und hauptschlich an Kenngren gemessen wird, also einer klaren Systematik folgt, regen Patzak / Rattay hier zustzlich Optimierung der Projektplanung allgemein an. Hierbei sollen zustzlich zu den Ergebniszielen auch noch Prozessziele an. Aber auch diese richten sich grtenteils nach qualitativen und quantitativen Kenngren und sind daher fr das Projektmanagement zwar wesentlich, in dieser Arbeit aber unwesentlich daher hier kein wesentlicher Unterschied zwischen herkmmlichem und virtuellem Projektmanagement besteht.154
5.2.3 Gestaltung der Projektorganisation

Bei der Gestaltung der Projektorganisation gilt es vor allem die Schnitt- und Nahtstellen zu planen, die Aufgaben im Team zu verteilen und das Projektinformationssystem zu gestalten. Unter der Schnitt- beziehungsweise Nahtstellenplanung verstehen Patzak / Rattay hierbei der Umgang mit Spannungen an organisatorischen Grenzen des Projekts. Hierbei gilt es mit den jeweilig angrenzenden Systemen Vereinbarungen zu treffen die eine konstruktive Zusammenarbeit ermglichen ohne, dass eine der involvierten Parteien unverhltnismig benachteiligt wird. Im Mittelpunkt stehen hier also vorab getroffene Vereinbarungen ber Spielregeln an diesen Naht- beziehungsweise Schnittstellen. Es kann hier davon ausgegangen werden, dass hier keine wesentlichen Unterschiede bestehen. Zwar unterliegen im virtuellen Projektmanagement diese Naht- und Schnittstellen grerer geographischer, zeitlicher oder technischer Unterschiede, diese herrschen aber auch im herkmmlichen Projektmanagement vor. Es kommt also hier hchstens zu einer Verstrkung des Effekts, nicht aber zu zustzlichen Problemen durch die Virtualitt.155
154 155
Vgl. Patzak / Rattay (2009), S. 217 ff. Vgl. Patzak / Rattay (2009), S. 330 ff.
84
Hierzu kann es hilfreich sein getroffene Vereinbarung noch exakter zu definieren und etwaige Kenngren noch genauer zu vereinbaren um so vorab Komplikationen zu vermeiden die mglicherweise auf Grund interkultureller oder virtueller Unterschiede entstehen. Die Aufgabenverteilung des Teams ist hingegen kritischer zu betrachten, da es hier aufgrund der Virtualitt zu zustzlichen Problemen kommen kann. Allgemein ist zur Aufgabenverteilung zu sagen, dass hier Darstellungsformen unbedeutend sind. So kann zum Beispiel ein Funktionendiagramm oder ein Sitzungsprotokoll sowohl in einem Projektmangementsystem gepflegt werden, als auch per Hand geschrieben in einem Ordner abgelegt sein, dies ndert nichts an seiner Wertigkeit und daher ist die Darstellungsform in dieser Arbeit nicht von Bedeutung. Es wird angenommen, dass die Darstellungsform des jeweiligen Dokuments keinen Einfluss auf den Projektalltag nimmt. Hier sind daher keine Unterschiede zwischen herkmmlichem und virtuellem Projektmanagement auszumachen. Ausschlaggebend hierbei ist lediglich die Koordination der Aufgaben der Projektmitglieder untereinander. So ist zum Beispiel eine informelle Benachrichtigung ber den Abschluss einer Aufgabe im herkmmlichen Projektmanagement, wo die Projektmitglieder meist physischen Kontakt zueinander haben, wesentlich unkomplizierter als in einem virtuellen Projektteam, wo dessen Mitglieder meist rtlich und/oder zeitlich voneinander getrennt sind. Daher ist bei der Aufgabenverteilung von Teams neben den offensichtlichen Aufgaben wie der Erstellung, Verteilung und Berechtigung von Dokumenten auch der informelle Aspekt der Aufgabenteilung zu beachten. Hier ist bei virtuellen Teams durchaus mit Komplikationen zu rechnen, da wie bereits besprochen, ein informeller Kontakt wesentlich seltener und wesentlich schwerer zustande kommt als bei herkmmlichen Projektteams. Abhilfe knnen hier zum Einen virtuelle Treffpunkte schaffen (informelle Chatrume, informelle Foren, etc.) zum Anderen aber auch genauere Prozessablufe. So knnte beim Abschluss einer Aufgabe oder einem Teilergebnis eine dementsprechende Benachrichtigung an das jeweilige Projektmitglied ergehen um dieses von der Beendigung einer Aufgabe oder eines Prozessschritts zu informieren. Dies erfordert natrlich einen wesentlich hheren administrativen Aufwand. Hierzu schreiben Patzak / Rattay: Der Detaillierungsgrad der Aufgabenverteilung sowie die Darstellungsform [] hngt davon ab, wie lange ein Team schon miteinan85
der arbeitet, wie neuartig und komplex das gegenstndliche Projekt ist und wie die Unternehmenskultur ausgeprgt ist.156 Dies gilt ebenso fr das virtuelle Projektmanagement. Zum Projektinformationssystem bleibt zu sagen, dass dieses sowohl im virtuellen als auch im herkmmlichen Management von wesentlicher Bedeutung ist. Ein effizientes Informationswesen ist laut Patzak / Rattay ein wesentlicher Erfolgsfaktor, sowohl im herkmmlichen als auch im virtuellen Projektmanagement. Es behandelt alle Aktivitten und Instrumente des projektrelevanten Informationsaustauschs. Hierauf und auch auf die Unterschiede wurde in dieser Arbeit bereits in Kapitel 4.3 eingegangen. Es ist darber hinaus anzunehmen, dass die Verteilung der Information sowohl im herkmmlichen als auch im virtuellen Projektmanagement nach den gleichen Regeln erfolgt. In beiden Fllen sollen bestimmte Informationen an bestimmte Teilnehmer oder Teilnehmerinnen in einer bestimmten Qualitt verteilt werden. Dies erfolgt meist anhand der Verwendung eines dementsprechenden Tools und wird mittlerweile hauptschlich elektronisch durchgefhrt. Die Unterschiede zwischen virtuellem und herkmmlichem Projektmanagement sind hier also marginal.157
5.2.4 Gestaltung der Teamarbeit

In der Gestaltung der Teamarbeit sind vor allem die Projektteamkultur, die Fhrung des Projektteams sowie Problemlsungs- und Entscheidungsprozess im Team von wesentlicher Bedeutung. Zur Entwicklung einer Projektteamkultur schreiben Patzak / Rattay [] dass Projektorganisationen innerhalb bestehender Unternehmen eine relativ eigenstndige, unterscheidbare Kultur entwickeln, was fr den Projekterfolg notwendig und auch frderlich ist.158
156 157 158
Patzak / Rattay (2009), S. 333 Vgl. Patzak / Rattay (2009), S. 330 ff. Patzak / Rattay (2009), S. 375
86
Darber hinaus geben sie vier wesentliche Erscheinungsformen an: einen eigenen Projektraum, einen speziellen Sprachgebrauch (in Form von Abkrzungen, Spitznamen, Codes, etc.), eigene Organisatorische Spielregeln (wie Arbeitszeiten, Rituale, etc.), und eigene Episoden werden speziell dokumentiert und der Auenwelt mitgeteilt.159 Die oben angefhrten Merkmale lassen erahnen, dass das Entwickeln einer Projektteamkultur gerade bei virtuellen Projektteams zustzliche Schwierigkeiten birgt. Diese ist aber, wie bereits zuvor besprochen, von wesentlicher Bedeutung fr den Projekterfolg und darf auf keinen Fall vernachlssigt werden. Der eigene Projektraum oder gemeinsame organisatorische Spielregeln sind wesentlich schwieriger zu implementieren wenn die einzelnen Projektteammitglieder geographisch oder zeitlich voneinander getrennt sind. Wie bereits, in Kapitel 5.1.4, besprochen kann es hierzu hilfreich sein zu bestimmten Zeiten physische Treffen zu veranstalten, um die Teambindung zu strken und emotionale Bindungen zwischen den Projektteammitgliedern zu frdern. Anlsse sind wie oben bereits angeregt das Etablieren von Ritualen oder Routinen um den Teamzusammenhalt zu strken. Patzak / Rattay regen hier unter anderem das Feiern eines Geburtstages, aber auch die gezielt richtige Auswahl der Projektteammitglieder an. Beim Entwickeln der Teamkultur ist klar erkennbar, dass hier nicht technische Hilfsmittel, sondern vor allem soziale Kompetenz der Projektleitung und Methode ausschlaggebend sind. Auf die Fhrung von virtuellen Projektteams soll hier hingegen nicht mehr eingegangen werden da auf die Aufgaben der Projektleitung bereits in Kapitel 2.1 und 3.3 ausfhrlich eingegangen wurde. Problemlsungs- und Entscheidungsprozesse unterscheiden sich hingegen im virtuellen Projektmanagement wesentlich vom herkmmlichen Projektmanagement. Hier werden vor allem Kreativmethoden wie Brainstorming, Mindmapping oder Brainwriting angeregt.160
159 160
Vgl. Patzak / Rattay (2009), S. 375 f. Vgl. Patzak / Rattay (2009), S. 387 ff.
87
Gerade hier knnen Tools wie ein gemeinsames Whiteboard (siehe 4.2.3) magebliche Untersttzung fr virtuelle Projektteams bieten in dem sie genau diesen Prozess untersttzen und nicht zum Beispiel einen anderen Prozess vorschlagen. Noch wesentlicher wird die Notwendigkeit einer Tooluntersttzung bei der Betrachtung von Entscheidungen im Projektteam. Hier regen Patzak / Rattay klar an, dass bis auf Ausnahmen, Entscheidung die im und vom Team getroffen werden meist optimale Entscheidungen darstellen was Akzeptanz den Prozess und das Ergebnis betreffend angeht. (siehe Abbildung 27)
Abbildung 27: Entscheidungsstile
161
Gerade in der Projektplanungs- und ausfhrungsphase kann gesagt werden, dass die Kombination aus technischer Untersttzung und Managementmethode mit Sicherheit den hchsten Wirkungsgrad erzielt. Durch das aktive Einbinden der Projektmitglieder und die Verwendung der richtigen technischen Werkzeuge knnen die zustzlichen Probleme des virtuellen Projektmanagements gut kompensiert werden.
161
88
5.3
Koordinations- und nderungsphasen
In den Koordinations- und nderungsphasen sehen Patzak / Rattay vor allem Umfeldnderungen, Projektsteuerung, Projektorganisation und Projektteamarbeit als wesentliche Bestandteile.162 In dieser Phase des Projekts haben die Projektleitung sowie auch das Projektteam mit meist unerwarteten Ereignissen fertig zu werden. Diese sind insofern rasch zu bearbeiten, als das diese zum Beispiel durch nderung der Anforderungen oder Vernderungen der Projektrahmenbedingungen die Projektziele und dadurch den Projekterfolg gefhrden knnen.
5.3.1 Umfeldnderungen
Wie bereits kurz, in Kapitel 5.2.1, angesprochen unterliegt das Projektumfeld einer stndigen Vernderung. Manche Interessensgruppen gewinnen im Laufe des Projekts an Bedeutung, andere verlieren an Bedeutung. Auch kann sich die Art der Beziehung verndern in dem positiv gestellte Gruppen an berzeugung verlieren oder man bisher kritische Gruppen durch zum Beispiel gekonntes Projektmarketing positiv stimmt. Wichtig hierbei ist es, dass diese nderungen erkannt und aufgenommen werden. Wie bereits erwhnt, knnen diese nderungen mageblichen Einfluss auf den Projektverlauf haben und sind daher im Projektmanagement in jedem Fall zu bercksichtigen. Patzak / Rattay regen in diesem Bezug den Begriff ClaimManagement und im Zuge dessen die Erkennung und die Verfolgung von Claims an. In dieser Arbeit sollen jedoch nicht die Einzelheiten des Claim-Managements besprochen werden, sondern lediglich die Auswirkungen der Virtualitt auf selbiges. Hierzu ist festzuhalten, das neben den allgemeinen Ttigkeiten des ClaimManagements (zum Beispiel Dokumentation des Sachverhalts, Lagebeurteilung, Ausarbeitung von Manahmen, etc.) Kommunikation ein wesentlicher Bestandteil des Claim-Managements ist. Von der Erkennung und der Aufnahme des Claims bis hin zum Abschluss sind oft mehrere Interessensgruppen beteiligt und es muss bestimmte Information an bestimmte Beteiligte weitergeleitet werden. 163
162 163
Vgl. Patzak / Rattay (2009), S. 399 ff. Vgl. Patzak / Rattay (2009), S. 402 ff.
89
So schreiben Patzak / Rattay hier unter anderem: Die Erfahrung zeigt, dass ein Groteil von Claims ohne Gericht durchgesetzt oder abgewehrt werden kann. Voraussetzung ist jedoch eine optimale Kommunikation, die in der Regel mit der Analyse der Kunden-Auftraggeber-Beziehung beginnt.164 Auch kann es im Zuge des Claim-Managements immer wieder wichtig sein physische Treffen, Sitzungen oder Verhandlungen abzuhalten. Hierzu gilt, wie bereits in den Kapiteln 5.1.4 und 5.2.4. besprochen, dass der persnliche Kontakt so gut wie mglich zu kompensieren ist falls dieser nicht mglich ist. Auch im Zuge eines Fremdclaims mit Kunden oder Vertragspartnern, gilt es diese so gut wie mglich einzubinden und zu informieren um einen negativen Ausgang zu verhindern. Hinsichtlich des virtuellen Projektmanagements bedeutet dies, wie bereits in Kapitel 4.3 besprochen, dass bei fehlendem physischen Kontakt der Kommunikationsparteien optimale Werkzeuge hierfr bereit stehen sollten. Sollte es notwendig sein ein Treffen oder ein Sitzung abzuhalten bei der konstruktiv zusammengearbeitet werden soll, so bietet sich eine Videokonferenz, in jedem Fall aber direkte synchrone Kommunikation an. Diese sollte wenn mglich durch die dementsprechenden kreativen Kollaborationstools untersttzt werden (wie zum Beispiel einem elektronischen Whiteboard). Hier ist es aber auch an der Projektleitung auf die Virtualitt schon von Beginn des Projekts an Rcksicht zu nehmen und diese einzuplanen. So sollten Vertragspartner und Kunden mit derartiger Arbeitsweise bereits vertraut sein, um nicht im Falle eines Claims vor neue technische oder organisatorische Probleme gestellt zu werden. Dies wrde einen Schadens- oder Streitfall nur zustzlich verkomplizieren. Im Zuge der nderungs- und Koordinationsphase gilt es aber Probleme schnell und fr alle Parteien positiv zu lsen.
164
90
5.3.2 Projektsteuerung
Im Zuge der Projektsteuerung gilt es die Projektziele (siehe Kapitel 5.1.2) und die darauf basierende Projektplanung (siehe Kapitel 5.2.2) zu kontrollieren und im Falle von Abweichungen mit konkreten Manahmen gegensteuern zu knnen. Im Zuge des Projektcontrollings sollen hier vor allem Vergleiche der Soll- und der IstSituation helfen Abweichungen der zuvor festgelegten Parameter zu erkennen. Im Zuge dieser Arbeit sollen aber hier wiederum nicht konkrete Methoden (wie zum Beispiel Earned-Value-Analyse, Meilenstein-Trendanalyse, etc.) hinterfragt, sondern die Unterschiede zum virtuellen Projektmanagement beleuchtet werden. Die Projektsteuerung gliedert sich hier grob in zwei Aufgabengebiete, einerseits das Kontrollieren des zuvor erstellten Plans und Gegensteuern im Falle einer Abweichung und andererseits dem Krisenmanagement. Die Plankontrolle, beziehungsweise das Projektcontrolling, verfolgt hierbei einem relativ geradlinigen Ansatz. Es werden im Projekt zum aktuellen Zeitpunkt IstWerte erhoben und diese mit den zuvor geplanten Plan-Werten verglichen. Im virtuellen Projektmanagement entspricht dieser Prozessschritt dem des herkmmlichen Projektmanagements. Die Ist-Werte, die aus dem Projekt kommen, mssen von den dementsprechenden Projektbeteiligten geliefert und meist in ein ITSystem eingepflegt werden. Soweit diese verfgbar sind und der Prozessschritt abgeschlossen ist steht der Projektleitung oder dem Projektcontrolling die bentigte Information zur Verfgung und kann weiterverwendet werden. Im Gegensatz dazu kann sich das Krisenmanagement, als zweiter wesentlicher Punkt dieser Phase, im virtuellen Projektmanagement durchaus von dem des herkmmlichen Projektmanagement unterscheiden. Vor allem bei der Krisenbewltigung und der Krisenvermeidung kann es massive Unterschiede geben. Krisenvorsorge ist hier allerdings dem herkmmlichen Projektmanagement uerst hnlich und sollen hier daher nicht besprochen werden. Bei der Krisenvermeidung gilt es im virtuellen Projektmanagement, noch genauer auf die Anzeichen von sich anbahnenden Krisen zu achten. So schreiben Patzak / Rattay hier zu den Anzeichen einer Krise auf sozialer Ebene unter anderem: Das Nachlassen des Interesse des Auftraggebers am Projektgeschehen; Zeitmangel wird vorgeschoben, Projektberichte nicht gelesen, erforderliche Entscheidungen verschleppt. Es treten Gerchte, abfllige Bemerkungen, Nrgeleien und Spott auf. Distanzierte Gleichgltigkeit macht sich breit. 91
Es ist mangelnde Termintreue zu beobachten, ohne dabei nach Ausreden zu suchen; Verbindlichkeit nimmt stark ab, jeder vertrstet auf morgen. Es kndigt sich massiver Mitarbeiterwechsel an, wobei Sachzwnge vorgeschoben werden. Das Team ist gespalten. Seitenabsprachen und Vereinbarungen durch das Unternehmensmanagement werden ohne die Einbindung des Projektleiters getroffen. Die mndliche informelle Kommunikation im Team bleibt aus.165
Hierbei ist klar ersichtlich, dass die Anzeichen hier vor allem im Zuge informeller Kommunikation zu beobachten sind, was gerade bei virtuellem Projektmanagement nur sehr schwer zu verfolgen ist. Eine mgliche Lsung hierfr ist, wenn von Beginn des Projekts Mglichkeiten bestehen informell zu kommunizieren. So knnte die Projektleitung zum Beispiel von vorneherein Chatrooms oder Foren einrichten die nur fr informelle, projektunabhngige Kommunikation des Projektteams zur Verfgung steht. Sofern diese Mglichkeit aktiv genutzt und auch von der Projektleitung aktiv untersttzt wird, knnen die obenerwhnten Effekte hier sichtbar gemacht werden. Noch grere Unterschiede sind bei der Krisenbewltigung zu vermuten. Hierzu schreiben Patzak / Rattay: Im Ablauf eines komplexen Projekts mit hohem Risikoanteil kann es zu Situationen kommen, die durch Steuerungsmanahmen im Rahmen des Projektcontrolling nicht mehr beherrschbar sind; der permanent ablaufende Standardprozess des ProjektmanagementRegelkreises ist hier berfordert.166 Es kommt also zu einer Situation die auch im Risikomanagement des Projekts nicht vorgesehen wurde und pltzlich oder sehr kurzfristig eintritt. Von wesentlichem Unterschied zum herkmmlichen Projektmanagement ist vor allem die Eskalation der Situation sobald die Manahmen der Projektleitung nicht mehr wirken. Hier ist auf Grund der mglichen rtlichen, vor allem aber auf Grund mglicher zeitlicher Verschiebungen genau Eskalationsszenarien zu definieren und vorab zu berlegen, um in einem Ernstfall darauf zurckgreifen zu knnen.
165 166
Patzak / Rattay (2009), S. 441 Patzak / Rattay (2009), S. 442
92
Beim Bewltigen von Krisen schreiben Patzak / Rattay unter anderem: Der Ansto sollte mglichst zeitgerecht und prompt vom Projektleiter kommen, indem er den Vorsitzenden des Projektbeirats informiert oder einen Eskalationsantrag bermittelt.167 Es spielt also die Zeit hier eine wesentliche Rolle. Dies ist wie bereits erwhnt beim Planen der Manahmen auf Grund einer mglichen zeitlichen Verschiebung mit einzukalkulieren.168
5.3.3 Projektorganisation
In dieser Koordinations- und nderungsphase geht es in der Projektorganisation hauptschlich um etwaige nderungen, also meist dem Ausscheiden eines Teammitglieds, beziehungsweise dem Eintritt eines neuen Teammitglieds. Patzak / Rattay schreiben hierzu, dass dadurch Teams meist wieder in die Storming-Phase der Teamentwicklung zurckfallen (siehe Kapitel 2.2 und 3.4). Diese Themen wurden im Zuge dieser Arbeit bereits ausfhrlich besprochen und sollen hier daher nicht mehr ausgefhrt werden. Wichtig zu erwhnen bleibt aber, dass bei Vernderungen des Projektteams oder in der Zusammensetzung selbigen, hierauf gerade im virtuellen Projektmanagement speziell Rcksicht genommen werden muss. Vernderungen in der Teamzusammensetzung fhren hufig zu Spannung, auf die gerade in virtuellen Teams verstrkt Rcksicht genommen werden muss, um den Projektfortschritt und den Projekterfolg nicht zu gefhrden.
167 168
93
5.3.4 Projektteamarbeit
In dieser Projektkoordinations- und nderungsphase sollte sich das Projektteam bereits in der Performing-Phase der Teamentwicklung befinden. Die Projektarbeit sollte erledigt werden und die Teammitglieder sollten gemeinsam mit der Projektleitung ein eingespieltes Team darstellen. Dies ist umso mehr notwendig sobald Komplikationen, Konflikte oder unvorhergesehene Situationen auftreten. In dieser Phase liegt das Hauptaugenmerk daher auf den Gebieten der Teamarbeit und der Zusammenarbeit einerseits und auf dem Konfliktmanagement andererseits. Die Teamarbeit wurde bereits in dem Kapitel 2.2, 3.4, 4.2 und 4.3 ausfhrlich diskutiert. Vor allem was die Wichtigkeit der Koordination und Kommunikation im virtuellen Projektmanagement betrifft wurde in dieser Arbeit ausfhrlich eingegangen. Auf eine Art der Zusammenarbeit soll hier trotzdem noch einmal eingegangen werden. Patzak / Rattay regen gerade in den Koordinations- und Vernderungsphasen im Projektmanagement das Werkzeug der Sitzung an. Die Notwendigkeit einer Sitzung ist laut Patzak / Rattay genau abzuwgen und sie regen hierzu daher folgende Alternativen an: Individuelle Zweiergesprche Telefonkonferenzen, Videokonferenzen Rundschreiben, Newsletter Nachrichten mit Hilfe elektronischer Netzwerke versenden.169
Diese Alternativen zeigen, dass bereits im herkmmlichen Projektmanagement der Einsatz von technischen Tools weit verbreitet und anerkannt ist. Hier lsst sich klar erkennen, dass der Unterschied zum virtuellen Projektmanagement kein signifikanter ist. Zum Beispiel soll hier noch auf Visualisierungsmittel eingegangen werden. Hier werden im Zuge von Teamarbeit und Sitzungen vor allem kreative Werkzeuge wie Flip-Chart, Pinnwnde oder Plakate vorgeschlagen. Es werden aber auch vermehrt technische Hilfsmittel wie PC170 oder Beamer angeregt (siehe Abbildung 28).
169 170
Patzak / Rattay (2009), S. 452 Personal Computer
94
Abbildung 28: Moderations- und Visualisierungsmittel
171
Die kreativen Werkzeuge knnten wiederum zum Beispiel durch die Verwendung eines gemeinsamen Whiteboards (siehe 4.2.3) gut kompensiert werden knnen. Von wesentlicher Bedeutung fr das virtuelle Projektmanagement ist wiederum das Konfliktmanagement. Dieses stellt nicht nur allgemein einen wichtigen Bestandteil des Projektmanagements dar, sondern hier sind vor allem zwischen herkmmlichem und virtuellem Projektmanagement wesentliche Unterschiede zu erkennen, aus denen sich beim Auftreten eines Konflikts durchaus unterschiedliche Vorgehensweisen ableiten lassen. Gerade im virtuellen Projektmanagement, muss durch das Arbeiten mit unterschiedlichen Kulturen, unterschiedlichen Organisationen oder Menschen in unterschiedlichen Umgebungen vermehrt mit Konflikten gerechnet werden. Unabhngig von der Art und Ursache der Konflikte (Personalkonflikt, struktureller Konflikt, kultureller Konflikt, etc.), welche fr den Unterschied zwischen virtuellem und herkmmlichem Projektmanagement nicht ausschlaggebend ist, ist die Bewltigung des Konflikts von wesentlicher Bedeutung fr das Projektmanagement. Dies zeigt sich vor allem dadurch, dass Konflikte nicht als schlechte Performance des Unternehmens oder des Projektteams verstanden werden, sondern als natrliches Phnomen in Projekten und dort vor allem als Chance zur Weiterentwicklung.
171
95
Patzak / Rattay schreiben hierzu: Konflikte treten gerade in Projekten hufig zu Tage []. Konflikte sind daher immanent mit Projekten verknpft. Das Auftreten von Konflikten ist somit kein Zeichen von Schwche oder schlechter Fhrung.172 Wichtig ist es also vor allem diese zu Lsen und nicht zu bekmpfen. Auch hier werden kreative Methoden wie Brainstorming, Mindmapping oder Brainwriting zur Problemlsung angeregt. Diese lassen sich wiederum durch den Einsatz von Kollaborations- und Kommunikationstools kompensieren. So knnten die vorgeschlagenen Methoden gut mit Werkzeugen wie einer Videokonferenz in Zusammenabreit mit einem elektronischen Whiteboard umsetzen und somit die fehlende physische Zusammenarbeit ausgleichen.173
Zusammenfassend werden in dieser Phase vor allem die physischen Kontakte zwischen den Projektteammitgliedern verstrkt besprochen. Diese informellen, direkten Kontakte bilden einen wesentlichen Bestandteil der Projektkoordinationsund nderungsphasen. Fehlende persnliche Kontakte (zum Beispiel Treffen am Gang, gemeinsames Mittagessen, gemeinsames Kaffee-trinken, etc.) sollten im virtuellen Projektmanagement daher, durch dementsprechende virtuelle Treffpunkte ersetzt werden. So wird zum Beispiel vorgeschlagen diese fehlenden informellen Kontakte durch Foren oder Chatrume zu ersetzen in denen informelle Kontakte im Vordergrund stehen und auch ein dementsprechender Umgangston gewahrt wird.174 Patzak / Rattay regen aber weiter an, das in dieser Phase auch die Prsenz durch die Projektleitung nicht verloren gehen darf. Es muss auch hier versucht werden, die fehlende physische Prsenz zu kompensieren, um nicht den Anschluss ans Team oder sogar Fhrungsanspruch gegenber dem Team zu verlieren. Hierzu regen sie weniger konkrete technische Lsungen, als organisatorische Methoden an. So ist ein konkreter Vorschlag Emails schneller zu beantworten. Auch hier ist klar erkennbar, dass nicht nur technische Hilfsmittel hier Abhilfe schaffen knnen und sollen, sondern vor allem auch organisatorische Konzepte und/oder Manage-
172 173 174
Patzak / Rattay (2009), S. 466 Vgl. Patzak / Rattay (2009), S. 466 ff. Vgl. Patzak / Rattay (2009), S. 481 f.
96
mentmethoden zum Einsatz kommen um die zustzlichen Probleme der Virtualitt zu lsen.175
Dies unterstreichen Patzak / Rattay abschlieend sagen Grundstzlich gelten fr virtuelle Teams die gleichen Regeln wie fr physische Teams, mit dem Unterschied, dass virtuelle Teams mehr vom selben bentigen, also mehr Augenmerk auf die Untersttzung von Kommunikation und Zusammenarbeit gelegt werden muss.176
175 176
Vgl. Patzak / Rattay (2009), S. 481 f. Patzak / Rattay (2009), S. 482
97
5.4
Projektabschlussphase
Auch in dieser letzten Projektphase gibt es eine Vielzahl von wichtigen Aufgaben im Zuge des Projektmanagements, dennoch sollen auch hier wiederum nur solche betrachtet werden die im Sinne dieser Arbeit von Bedeutung sind, also solche die sich im virtuellen Projektmanagement wesentlich von dem im herkmmlichen Projektmanagement unterscheiden. In dieser Phase gilt es die Umfeldbeziehungen abzuschlieen, eine Projektauswertung durchzufhren sowie die Projektorganisation abzuschlieen und das Projektteam aufzulsen. Wesentlich anzumerken ist in der Projektabschlussphase vor allem, dass gerade hier Nachlssigkeiten verstrkt auftreten und dadurch die Probleme der natrlichen Auflsung noch verstrken. Diese Auflsung tritt auf da: die meisten Mitarbeiter nur mehr punktuell Kapazitten einbringen mssen, die geistige und emotionale Bindung vieler Mitarbeiter bereits auf andere Aufgaben gerichtet ist die Motivation fr das Projekt bei vielen Mitarbeitern nicht mehr vorhanden ist.177 Auf Grund der ohnehin bereits wesentlich loseren Beziehung des Projektteams im virtuellen Projektmanagement ist es umso wichtiger, in dieser Projektphase alle wichtigen Aufgaben mit Nachdruck zu verfolgen und das Projekt so einer positiven Beendigung zuzufhren.
5.4.1 Abschluss von Umfeldbeziehungen

Beim Abschluss von Umfeldbeziehungen gilt es vor allem mit dem Projektumfeld (Lieferant, Behrden, etc. vor allem aber mit dem Kunden) eine offizielle und formale Beendigung des Projekts durchzufhren. Wesentliche Punkte hierbei, wie die Wahl des tatschlichen Projektendereignis (ob Projektbergabe oder Projektevaluierung) oder der bergabeprozess sind in dieser Arbeit nicht von Bedeutung. Es steht zwar auer Frage, dass es sich hier um wesentliche Elemente in dieser Phase handelt und diese unter keinen Umstnden vernachlssigt werden sollten, hinsichtlich des virtuellen Projektmanagements gibt es hier aber keine wesentlichen Unterschiede gegenber dem herkmmlichen Projektmanagement. Auch im
177
98
virtuellen Projektmanagement gilt es das Projektendereignis klar zu bestimmen und den bergabeprozess klar zu definieren. Die Vorgehensweise ist aber im virtuellen Projektmanagement hier analog der des herkmmlichen Projektmanagements. Bei der Auflsung der Umfeldbeziehungen hingegen sind sehr wohl Unterschiede auszumachen und diese sollen im Folgenden auch kurz besprochen werden. So regen Patzak / Rattay hier, vor allem bei der Erhebung der Kundenzufriedenheit, Werkzeuge wie ein informelles Gesprch mit dem Kunden oder einen Projektabschluss mit einer schriftliche Befragung des Kunden an. Anhand der geographischen und zeitlichen Unterschiede der Projektorganisation mit dem oder den Kunden und Kundinnen muss hier aber angenommen werden das dies zu Schwierigkeiten in der Umsetzungen fhren kann, da ein physisches Treffen zu einem Workshop mglicherweise nicht fr alle Teilnehmer und Teilnehmerinnen mglich ist. Das Erheben der Kundenzufriedenheit sollte aber auch bei zustzlichen Schwierigkeiten auf keinen Fall vernachlssigt werden, da es von wesentlicher Bedeutung f den Projekterfolg ist.178 Patzak /Rattay schreiben hierzu: Ein wesentlicher Teil des Projektabschlusses ist die Erhebung der Kundenzufriedenheit, weil diese schlussendlich auch ber den Erfolg oder Nichterfolg des Projekts entscheidet.179 Hier empfiehlt es sich daher analog dem Startworkshop (siehe Kapitel 5.1.2) diesen auf jeden Fall unter Zuhilfenahme der jeweiligen technischen Tools zu ersetzen und das verlorene physische Zusammentreffen so zu kompensieren. Auch hier wrde sich beispielsweise eine Video- oder zumindest eine Telefonkonferenz aller Beteiligter und Beteiligten anbieten um so diesen Projektendworkshop abzuhalten.
178 179
Vgl. Patzak / Rattay (2009), S. 483 ff. Patzak / Rattay (2009), S. 488
99
5.4.2 Projektauswertung
Im Zuge der Projektauswertung gilt es vor allem letzte Aufgaben zu erledigen. So ist zum Beispiel im Zuge der Projektnachkalkulation ein letzter Soll-Ist-Vergleich durchzufhren, der Abschlussbericht zu erstellen der einen letzten Fortschrittsbericht darstellt beziehungsweise die letzten noch offenen Punkte zuzuteilen. Auch hier ist es wichtig, dass diese Aufgaben auch im virtuellen Projektmanagement durchgefhrt werden, so unterscheiden sich aber nur gering von denen des herkmmlichen Projektmanagement. Es wird daher in dieser Arbeit nicht mehr nher darauf eingegangen. Unterschieder dieser Phasen im virtuellen Projektmanagement gegenber dem herkmmlichen wurden darber hinaus bereits in den Kapitel 5.1.2, 5.2.2 und 5.3.2 ausfhrlich beschrieben.
5.4.3 Auflsung der Projektorganisation

Beim Abschluss der Projektorganisation werden alle zuvor aufgestellten Rahmenbedingungen und Regeln formal aufgelst und die bestehenden Restaufgaben verteilt. Wie auch schon bei der Beendigung der Umfeldbeziehungen wird beim Auflsen der Projektorganisation eine dementsprechende Sitzung nahegelegt, um die letzten Aufgaben noch zu besprechen und zu verteilen und die Projektorganisation formal aufzulsen. Hierbei sollten wiederum alle wichtigen Interessensgruppen wie Projektteam, Projektauftraggeber oder Projektauftraggeberin sowie die Projektleitung anwesend sein.180 Wie auch zuvor ist der wesentliche Unterschied in dieser Abschlussphase das Zusammentreffen, dass sofern physisch nicht mglich, zumindest virtuell abgehalten werden sollte. Dementsprechende Ausfhrungen wurden bereits in den Kapiteln zuvor gemacht und gelten hier dementsprechend.
180
100
5.4.4 Auflsung des Projektteams

Die Auflsung des Projektteams hat zunchst zwei wesentliche Komponenten. Einerseits muss das Projektteam aufgelst werden, andererseits sollte das erworbene Wissen sichergestellt werden, um diese fr knftige Projekte sicherzustellen. Beim emotionalen Projektabschluss ist kann hier gesagt werden, dass die gleichen Regeln gelten wie im herkmmlichen Projektmanagement. Es sind kaum Unterschiede zu vermuten, weder beim Abschluss erfolgreicher, noch beim Abschluss nicht erfolgreicher Projekte. Lediglich bei nicht erfolgreichen Projekten kann davon ausgegangen werden, dass sich hier die Beziehungen und die Arbeitsbereitschaft auf Grund der rtlichen und zeitlichen Unterschiede noch schneller verflchtigen als bei herkmmlichen Teams. Beim Nutzen der Lernchancen (Lessons Learned) sollte hingegen bei virtuellen Teams verstrkt darauf geachtet werden, dass sich das erworbene Wissen und die erworbene Erfahrung nicht zu schnell verloren geht. Um zuknftigen Projektteams das erlangte Wissen und die erlangte Erfahrung zur Verfgung stellen zu knnen, ist es notwendig das Wissen und die Erfahrung dementsprechend abzulegen. Hier kann es durch die geographischen und zeitlichen Unterschiede zu Komplikationen kommen und zum Ende des Projekts knnen manche Mitglieder unter Umstnden kaum mehr greifbar sein. Dieser Effekt verstrkt sich durch die Virtualitt. Es gilt daher fr diese Information eine geeignete Ablage bereitzustellen. Dies kann zum Beispiel in Form eines geeigneten Projektmanagementsystems, oder zumindest einem Funktionsbaustein dessen passieren, aber auch in vorher vereinbarten Dokumenten- oder Informationsmanagementsystem. Vor allem bei virtuellen Projektteams ist es von Vorteil diese Information auch laufend abzulegen um sie dann zum Projektabschluss fr alle Beteiligten greifbar zu haben.181 Abschlieend kann gesagt werden, dass auch hier der alleinige Einsatz von Tools keine Lsung bringt. Diese sollten immer in Begleitung durch die passenden Methoden und Managementwerkzeuge untersttzt werden. Das Fehlen von persnlichen Kontakten muss hufig durch Sozial- und Methodenkompetenz der Projektleitung wettgemacht werden um die zustzlichen Konflikte und Spannungen innerhalb des Projektteams abzufangen und prventiv zu verhindern.
181
101
Patzak / Rattay schreiben hierzu abschlieend Der bewusste Abschluss eines Projekts ist gerade bei virtuellen Teams besonders zu beachten. Durch die fehlende Nhe luft das Team Gefahr, sich zu verlieren, Restaufgaben werden nicht mehr erledigt. Ein bewusster Abschluss [] ermglicht eine adquate Form der Erfolgsanalyse und des Abschiednehmens.182
182
102
Conclusio
In diesem Kapitel soll abschlieend eine kurze Zusammenfassung der Arbeit stattfinden und beantwortend und abschlieend auf die Forschungsfragen aus Kapitel 1.2 eingegangen werden. Zur Beantwortung der Forschungsfrage 1 kann gesagt werden, dass diese bereits hauptschlich in Kapitel 4 stattgefunden hat. Es wurden hier umfassend technische Mglichkeiten vorgestellt die nicht nur zur prventiven Verhinderung von Problemen zu Rate gezogen werden knnen, sondern vor allem auch zur aktiven Lsung von Problemen die durch das virtuelle Projektmanagement entstehen. So knnen zum Beispiel zur aktiven Lsung des Problems der Virtualitt und damit fehlenden physischen Kontakte unteranderem Kommunikationstools, im Beispielfall hier Video- oder Voice-chat, als mgliche Kompensation herangezogen werden und somit sowohl Konflikte die durch den fehlenden physischen Kontakt der Projektteammitglieder entstehen prventiv vorgebeugt werden, bei konkreten Konfliktfllen aber auch Videokonferenzen mehrerer Teilnehmer aktiv zur Lsung des Problems herangezogen werden. Auch auf die Kategorisierung und Bewertung ist in Kapitel 4 intensiv eingegangen worden. Die Arbeit zeigt, dass eine saubere Kategorisierung nicht gnzlich mglich ist, da sich vor allem bei der zwischenmenschlichen Arbeit Inhalte oft vermischen (wie zum Beispiel im Fall der Kommunikation und Kollaboration, bei denen keine klare Trennung mglich ist). Trotzdem ist zumindest eine objektive Bewertung der technischen Hilfsmittel nach ihrer Ntzlichkeit zur Lsung der Probleme des virtuellen Projektmanagements mglich und auch sinnvoll. Bei der Beantwortung der Forschungsfrage 1b kann hingegen zusammenfassend keine klare Antwort gegeben werden. Es knnen keine klaren Problemstellungen identifiziert werden, die durch bestimmte Tools behoben oder vorgebeugt werden knnen. Trotzdem lsst sich sagen, dass das Lsen von Problemen meist auch eine Methode erfordert und diese oft von etwaigen Hilfsmitteln untersttzt werden kann. So wird unter anderem in Kapitel 5, in der Koordinations- und nderungsphase das erhhte Konfliktpotential dieser Phase unterstrichen und den dadurch vermehrt auftretenden Konflikten. Hierbei muss die Projektleitung oder eine dritte mediativ wirkende Stelle lsend eingreifen. Dies erfordert natrlich die dafr notwendig interpersonelle Methode oder Technik die zur Mediation oder Konfliktl103
sung herangezogen werden knnen. Trotzdem knnen aber hier Tools hilfreich sein, wenn es im Zuge der Virtualitt darum geht zum Beispiel geographische Distanz zu berwinden oder eine dementsprechende Methode zu Virtualisieren. So ist in diesem Fall ein Brainstorming oder Mindmapping, das blicherweise im Anwesenheit aller Beteiligten am selben Ort stattfindet, durch den Einsatz eines elektronischen Whiteboards gelst werden, sofern nicht alle Teammitglieder die Mglichkeit haben sich physisch zu treffen, was im Falle von Konfliktlsung meist die weitaus effektivere Manahme darstellt. Auch Forschungsfrage 2 wurde in Kapitel 5 besprochen, hier vor allem in den Kapiteln 5.2 und 5.3, wo es vermehrt um die richtige Fhrung der Projektleitung und die effiziente Kollaboration des Projektteams untereinander geht. Hier stehen der Projektleitung zahlreiche Methoden zur Verfgung, wie zum Beispiel Management by Objective verstrkt einzusetzen, um dem Projektteam durch klarere und genauere Zielsetzung auch ber geographische und zeitliche Unterschiede hinweg eine klare Fhrung zu bieten. Auch die letzte Frage wurde im Kapitel 5.3, der Projektkoordinations- und nderungsphase besprochen, vor allem was die Untersttzung der technischen Tools in dieser Phase betrifft. Hier lsst sich abschlieend zusammenfassen, dass natrlich keine Projektphase ohne Komplikationen funktioniert beziehungsweise in keiner Projektphase Komplikationen ausgeschlossen werden knnen. Mit den meisten zwischenmenschlichen Komplikationen ist aber in der Koordinations- und nderungsphase zu rechnen, die hier auch innerhalb des Projekts nderungen und Unstimmigkeiten auftreten und es zum natrlichen Wesen dieser Phase gehrt das es Vernderungen gibt.
Abschlieend kann gesagt werden, dass weder technische Hilfsmittel, noch Managementmethoden alleinig zur Lsungsfindung beitragen. Weder eine konkrete Managementmethode, noch ein bestimmtes Tool knnen hier als universale Alleinlsung funktionieren, es kann meist nur eine Symbiose beider zum Erfolg fhren. Die vorgestellten technischen Tools sollen als Untersttzung der Projektleitung und des Projektteams bei der Durchfhrung ihrer Arbeit oder der Anwendung bestimmter Managementmethoden verstanden werden. Ebenso wre es nicht zielfhrend ausgereifte Tools einzusetzen ohne dem entsprechenden methodischen Werkzeug durch die Projektleitung. 104
Literaturverzeichnis
Brewer, J. L. / Dittman, K. C. (2010): Methods of IT Project Management, 1st edition, Prentice Hall, Pearson Education Inc. Caupin, C. / Knoepfel, H. / Koch, G. / Pannenbcker, K. / Prez-Polo, F. / Seabury, C. (2006): ICB IPMA-Kompetenzrichtlinie Version 3.0, ICB Version 3.0, Nijkerk: International Project Management Association Daft, R.L. / Lengel, R.H. (1986): Organizational information requirements, media richness and structural design, Management Science, Vol. 32, No. 5 Dostal, T. (2007): Projektmanagement in virtuellen Teams. Chancen und Problembereiche, Saarbrcken: VDM Verlag Duarte, D.L. / Snyder, N. T. (2006): mastering virtual teams. Strategies, tools and techniques that succeed. 3rd Edition, USA: Jossey-Bass Duncan, W. R. (1996): A guide to the project management body of knowledge, Project Management Institute, 1996 edition, USA: Maryland Falck, M. / Scheitza, A. /Otten, M. (2009): Internationales Projektmanagement, Studienbrief: 2-010-0506, Fernstudienagentur des FVL: Berlin Gollubits, T. (2007): Diplomarbeit: Project Management in Distributed Projects, Wien: TU Wien Grunewald, W. (2001): Fhrung virtueller Arbeitsgruppen. Theoretische und empirische Aspekte. in: OrganisationsEntwicklung 20. Jg. 04/2001 Krner, M. (2005): Die Rolle des Projektleiters beim Aufbau virtueller Teams, Projektmanagement Magazin, Ausgabe 06/05, Mnchen Kerzner, H. (2010): Project Management, Best Practices, Achieving global excellence, 2nd edition, John Wiley & Sons Inc., USA: New York Khazanchi, D. / Zigurs, I. (2005): Patterns of Effective Management of Virtual Projects. An Exploratory Study, Project Management Institute
105
Klein, G. L. / Adelmann, L. (2005): A collaboration evaluation framework, The MITRE Corporation, Virgina Kohlhauser, D. (2007): Kollaboration in virtuellen Arbeitsumgebungen. Mit Desksharing im Vergleich zu fixen Arbeitspltzen (anhand des Fallbeispiels IBM), 1. Aufl., Wien: Facultas Konradt, U. / Hertel, G. (2002): Management virtueller Teams. Von der Telearbeit zum virtuellen Unternehmen. Beltz Verlag Lipnack, J. / Stamps, J. (2000): Virtual Teams. Reaching across space, time, and Organizations with Technology, Published by John Wiley&Sons Inc. Mhlbauer, R. / Klambauer, T. / Ruprechtsberger, W. / Schaitl, J. (2007): Comparison of Projectmanagement-Software, Seminar Projektorganisation, Johannes Kepler Universitt Linz Newberry, B. (2001): Raising Student Social Presence in Online Classes, World Conference on the WWW and Internet Proceedings, USA: Orlando (FL) Patzak, G. / Rattay, G. (2009): Projektmanagement. Leitfaden zum Management von Projekten, Projektportfolios und projektorientierten Unternehmen, 4. Aufl., Wien: Linde International Pazderka, M. (2008): Estalbishment and Integration of Best Practices for Project Management in Virtual Teams within the Organizational Project Management Maturity Model (OPM3), Wien Senst, E. (2001): Virtuelle Teamarbeit. Ein Lernprogram im Medienverbund zur Einrichtung und Betreuung virtueller Teams, Kiel: Sensed-Media Siyamak, N. (2009): Human Performance Factors in the Evaluation of Virtual Organizations, Vol. 4, No. 2, International Journal of Business and Management Staehle, W.H. (1999): Management. Eine verhaltenswissenschaftliche Perspektive, 8. Aufl., Mnchen: Vahlen Stger, G. / Thomas, G. (2007): Teams ohne Grenzen, Und es geht doch: Virtuelle Teams erfolgreich vernetzen, fhren, leben, Orell Fssli Verlag, Zrich
106
Tuckman, B. W. (1965): Special Issue on Group Development, Psychological Bulletin, Volume 63, Number 6, USA: American Psychological Association Internetquellen AIM (2011): http://www.aim.com/, AOL Instant Messaging, AOL Inc. letzter Zugriff: 14.04.2011 Adobe Buzzword (2011): https://acrobat.com/welcome.html, Adobe Systems Inc., USA: San Jose (CA), letzter Zugriff: 14.04.2011 Basecamp (2011): http://basecamphq.com/, 37signals LLC, USA: Chicago, letzter Zugriff: 14.04.2011 Bryce, T. (2006): http://www.projectsmart.co.uk/project-management-systemevaluation-checklist.html Bryce Tim, Project Smart
BusinessDictionary (2011): http://www.businessdictionary.com/definition/collaboration.html, letzter Zugriff: 05.04.2011, WebFinance, Inc. Clarizen (2011): http://www.clarizen.com, USA: San Mateo (CA), letzter Zugriff: 10.04.2011 Clocking IT (2011): http://www.clockingit.com/, Erlend Simonsen / Ellen Simonsen, Norway: Oslo, letzter Zugriff: 14.04.2011 Doodle (2011): http://www.doodle.com/, Doodle AG, Switzerland: Zurich, letzter Zugriff: 14.04.2011 Endeavour (2011): http://endeavour-mgmt.sourceforge.net/, Endeavour Agile ALM, Version 1.24, letzter Zugriff: 14.04.2011 Gabler (2011): http://wirtschaftslexikon.gabler.de/Definition/kommunikation.html, Gabler Verlag, Springer Fachmedien Wiesbaden, letzter Zugriff: 04.04.2011 Gartner (2010): http://www.gartner.com/it/page.jsp?id=1362014, Gartner, Inc. USA: Connecticut, letzter Zugriff: 10.04.2011
107
Gauthier, B. (2004): http://www.hfrp.org/evaluation/the-evaluation-exchange/issuearchive/harnessing-technology-for-evaluation/electronic-collaboration-toolsopening-up-a-new-world-of-possibilities-for-evaluators, the evaluation exchange, Vol. X, No. 3, Harvard Graduate School of Education, Canada, letzter Zugriff: 05.04.2011 Google Docs (2011): http://docs.google.com, Google Inc., USA: Menlopark (CA), letzter Zugriff: 14.04.2011 HyperOffice (2011): http://www.hyperoffice.com/online-calendars/, USA: Maryland, letzter Zugriff: 05.04.2011 Meyer, M. (2011): Institut fr Projektmanagement und Innovation,Bremen, http://www.pm-software.info/produktfilter.html, letzter Zugriff: 04.04.2011 Microsoft (2011): http://www.microsoft.com/project/en/us/default.aspx, Microsoft Corp., letzter Zugriff: 14.04.2011 MSN (2011): http://explore.live.com/windows-live-messenger?os=other, Microsoft Corp, Version 15.4.3502.922, letzter Zugriff: 14.04.2011 Onepoint Project (2011): http://www.onepoint-project.com/, Onepoint Software Gmbh, Austria: Graz, letzter Zugriff: 14.04.2011 Pidgin (2011): http://pidgin.im/, Version 2.7.11, letzter Zugriff: 14.04.2011 Project.net (2011): http://www.project.net/, Integrated Computer Solutions Inc., Version 9.0, letzter Zugriff: 14.04.2011 ProjektMagazin (2011): http://www.projektmagazin.de/marktplatz/projektmanagementsoftware.html, Projekt Magazin, letzter Zugriff: 04.04.2011 Primavera (2011): http://www.oracle.com/us/products/applications/primavera/index.html, Oracle Corp., letzter Zugriff: 14.04.2011 Primavera Consultants (2011): Zugriff: 07.04.2011 http://www.primaveraconsultants.com, letzter
108
Skype (2011): http://www.skype.com/intl/en/home, Skype Ltd, Version 5.3.0.108, letzter Zugriff: 14.04.2011 SoftGuide (2011): http://www.softguide.de/software/projektmanagement.htm, letzter Zugriff: 04.04.2011 TalkAndWrite (2011): www.talkandwrite.com, Version 5.1.1.217, TalkAndWrite Informtica, letzter Zugriff: 05.04.2011 TeamSpeak (2011): http://www.teamspeak.com/, Version 3.0.0-beta36, letzer Zugriff: 14.04.2011 Thunderbird (2011): http://www.mozillamessaging.com/de/thunderbird/, Mozilla Organization, Version 3.1.9, USA: Mountain View (CA), letzter Zugriff: 14.04.2011 Ventrilo (2011): http://www.ventrilo.com/, Version 3.0.8, letzter Zugriff: 14.04.2011 Zoho (2011): http://www.zoho.com/, Zoho Corp., USA: Pleasanton (CA), letzter Zugriff: 14.04.2011
109

Diplomarbeit Scheipl

Hochgeladen von

Copyright:

Verfügbare Formate

Diplomarbeit Scheipl

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diplomarbeit Scheipl

Hochgeladen von

Copyright:

Verfügbare Formate

Fachhochschul-Studiengang

Projektmanagement und Organisation

Titel der Diplomarbeit:

Fachhochschule des BFI Wien GmbH Wohlmutstrae 22 1020 Wien

0910388040 Peter Scheipl

0910388040 Peter Scheipl

0910388040 Peter Scheipl

0910388040 Peter Scheipl

0910388040 Peter Scheipl

0910388040 Peter Scheipl

Patzak / Rattay (2009), S. 63

0910388040 Peter Scheipl

Formulierung der Forschungsfrage

0910388040 Peter Scheipl

Patzak / Rattay (2009), S. 160

0910388040 Peter Scheipl

Vgl. Caupin et.al. (2006), S. 43

0910388040 Peter Scheipl

0910388040 Peter Scheipl

Patzak / Rattay (2009), S. 186 f. ebd. ebd. ebd. ebd.

0910388040 Peter Scheipl

Patzak / Rattay (2009), S. 186 ebd. ebd.

0910388040 Peter Scheipl

0910388040 Peter Scheipl

Abbildung 1: interner Projektauftraggeber

Patzak / Rattay (2009), S. 147 Vgl. Patzak / Rattay (2009), S. 147 f.

0910388040 Peter Scheipl

2.4.2 Projektlenkungsausschuss, Steering Committee

Vgl. Patzak / Rattay (2009), S. 152 f.

0910388040 Peter Scheipl

Auch diese Rolle soll in Kapitel 3 noch nher beleuchtet werden.

0910388040 Peter Scheipl

Patzak / Rattay (2009), S. 167 ebd. ebd.

0910388040 Peter Scheipl

Patzak / Rattay (2009), S. 616 ebd. ebd.

0910388040 Peter Scheipl

Khazanchi / Zigurs (2005), S. 3 ebd.

0910388040 Peter Scheipl

Grunewald (2001), S. 31 Grunewald (2001), S. 31 Kohlhauser (2007), S. 4 Dostal (2007), S. 28

0910388040 Peter Scheipl

Vgl. Khazanchi / Zigurs (2005), S. 3 Vgl. Grunewald (2001), S. 33

0910388040 Peter Scheipl

Gollubits (2007), S. 46 ebd. Vgl. Patzak / Rattay (2009), S. 192 f.

0910388040 Peter Scheipl

Konradt (2002), S. 18 Falck et.al. (2009): S. 41 Lipnack (2000), S. 7

0910388040 Peter Scheipl

Patzak / Rattay (2009), S. 66 Siyamak (2009), S. 42 Vgl. Gollubits (2007), S. 50

0910388040 Peter Scheipl

Gollubits (2007), S. 50 Lipnack (2000), S. 8

0910388040 Peter Scheipl

Caupin et.al. (2006), S. 65

0910388040 Peter Scheipl

Caupin et.al. (2006), S. 64 Vgl. Patzak / Rattay (2009), S. 166

0910388040 Peter Scheipl

Vgl. Patzak / Rattay (2009), S. 147-152

0910388040 Peter Scheipl

0910388040 Peter Scheipl

0910388040 Peter Scheipl

Vgl. Patzak / Rattay (2009), S. 616-627 PMS - Projekt Management Software

0910388040 Peter Scheipl