Neue Seite 0

Seit Tausenden von Jahren wissen die Menschen, dass sich komplexe und schwierige Aufgaben besser in eng zusammenarbeitenden Gruppen erledigen lassen. Dies haben uns bereits die alten Ägypter bei dem Bau ihrer Pyramiden vorgemacht. Ebenso vor Tausenden von Jahren zeigte sich, wie wichtig Kommunikation für komplexe Projekte ist: Wegen der Sprachverwirrung wurde der Turm von Babel nie fertig gestellt.

Heute sehen wir im Projektmanagement sowohl eine Arbeitsmethode mit einem wertvollen Pool an erprobten und bewährten Methoden und Instrumenten als auch ein Management- und Steuerungsinstrument für projektorientierte Unternehmen.

In diesem Kapitel werden die Entwicklung und die Trends im Projektmanagement aufgezeigt; dabei werden vor allem diejenigen Konzepte und Themen angesprochen, die derzeit im Zusammenhang mit der Projektarbeit in virtuellen Projektteams diskutiert werden.

1.1 Entwicklung der Erwartungshaltung an das Projektmanagement

Im Laufe der Jahre wandelte sich das Verständnis über die Schwerpunkte des Projektmanagements. Von einer Fachdisziplin „Projektmanagement“ lässt sich erst seit den fünfziger Jahren reden: durch den Zweiten Weltkrieg erzwungene militärische Gründe ließen nach neuen Formen und Methoden zur Lösung komplexer innovativer Vorhaben suchen. Den Anfang machten nationale und internationale Organisationen der Luft- und Raumfahrt und des Militärs[i] (siehe Abbildung 2). In der Wiederaufbauphase nach dem Zweiten Weltkrieg führte man allmählich die als nützlich erkannten Projektmanagement-Konzepte in der Industrie ein. Vor allem in den USA wurden bei der Vergabe von Regierungsaufträgen diejenigen Unternehmen begünstigt, die bereits eine Projektorganisation vorweisen konnten. Dadurch wurden die Unternehmen stark motiviert, sich mit der neuen Disziplin Projektmanagement auseinander zu setzen. Mit einiger Verzögerung gelangten die Projektmanagement-Konzepte nach Europa. Hier, insbesondere in der Bundesrepublik, war bis in die siebziger Jahre Projektmanagement gleichzusetzen mit Netzplantechnik. Die schwerpunktmäßige Orientierung auf Methoden und Werkzeuge dauerte bis in die neunziger Jahre. Erst dann fing man an, ein Projekt nicht nur als eine sachliche Aufgabe, sondern auch als eine Menge von Prozessen, die technischen, betriebswirtschaftlichen, juristischen oder soziopsychologischen Charakter haben können, und neuerdings auch als ein soziales System zu betrachten.

Abbildung 2: Entwicklung des Projektmanagements am Beispiel von F&E-Projekten aus dem militärischen Bereich bzw. Luft- und Raumfahrt

Anlässlich der Einleitungsrede bei einer GPM-Expertentagung im Herbst 2000 fasste Hasso Reschke[ii] die Entwicklung des Projektmanagements wie folgt zusammen:

Die Unterstützung der Projektmanagement-Konzepte, deren Weiterentwicklung und die Aus- und Weiterbildung der Projektmanagement-Gemeinde wird heute weltweit durch zwei Projektmanagement-Vereinigungen vorangetrieben. In Europa wurde 1965 die heutige IPMA, International Project Management Association, mit Sitz in Zürich, gegründet. Zur IPMA gehören inzwischen weltweit über 30 nationale Mitglieds-Projektorganisationen; eine davon ist die 1979 gegründete deutsche GPM, Gesellschaft für Projektmanagement. In den USA wurde 1969, unabhängig von der IPMA, das PMI, Project Management Institute, gegründet[iii]. Beide Organisationen hatten lange Zeit wenig gemeinsam und entwickelten eigenes Verständnis und unterschiedlichen Zugang zum Thema Projektmanagement: Die auf einer relativ homogenen Landeskultur und Sprache basierte amerikanische Vereinigung hatte wenig Verständnis für die als umständlich geltende europäische Fraktion. Die europäischen Projektmanager waren stark durch die unterschiedlichen nationalen Landeskulturen beeinflusst und brauchten Jahre, um einen gemeinsamen Konsens bezüglich des Verständnisses der Projektmanagement-Inhalte zu finden. Erst 1999 wurde als Ergebnis des Konsolidierungsprozesses die IPMA Competence Baseline [IPMA 1999] publiziert. Hier werden die gemeinsam abgestimmten Inhalte und Anforderungen an das Projektmanagement-Personal als Standard festgehalten und erläutert. Dennoch werden hier einige in den USA bereits intensiv diskutierte Themen wie Projektkultur, internationales Projektmanagement und virtuelle Projektorganisationen noch nicht angegangen.

Anlässlich des GPM-Forums 1997 kündigte Saynisch[iv] das Projektmanagement der zweiten Ordnung an (siehe Abbildung 3). Er fasste die Etappen im Verständnis des Projektmanagements wie folgt zusammen:

· In das „Projektmanagement der ersten Ordnung “ gehört das so genannte „klassische“ Projektmanagement. Dies wurde vor allem stark durch technische und methodische Ansätze der Ingenieurwissenschaften geprägt. Dass im Projektmanagement auch „soft factors“ zu berücksichtigen sind, setzte sich als Projektmanagement der zweiten Art mit dem Einfluss der Organisationspsychologen erst ab Mitte der achtziger Jahre durch.

· Ab Mitte der neunziger Jahre kann man über „Projektmanagement der zweiten Ordnung“ sprechen: Hier werden der klassische und der verhaltensorientierte PM-Ansatz zusammengefasst. Das Projekt wird als eine Kette von unabhängigen Prozessen verstanden, es kommt eine so genannte evolutionäre Projektplanung zum Einsatz, bei der die sich während des Projektverlaufs ändernden Anforderungen die Projektplanung dynamisch beeinflussen. Außerdem finden neue Organisationsformen für die Durchführung der Projekte Verwendung.

Die Betrachtung von Saynisch ging nicht über das Jahr 2000 hinaus. Die Projektmanagement-Praxis zeigt jedoch, dass wir uns auch noch in den nächsten Jahren intensivst mit der Thematik des Projektmanagements der zweiten Ordnung auseinander setzen werden müssen.

1.2 Wandel der Themenschwerpunkte

Im Laufe der letzten 30 Jahre wandelte sich die Position des Projektmanagements in den Augen seiner Betrachter: von reiner Netzplantechnik hin zu einem Management-Stil. Die Entwicklung einer Disziplin kann sehr gut daran gemessen werden, welchen Schwerpunkten in deren Verlauf die meiste Beachtung geschenkt wird.

Der Wandel der Themenschwerpunkte im Projektmanagement der letzten 30 Jahre wurde im Rahmen zweier Studien am Institut für Projektmanagement und Wirtschaftsinformatik (IPMI) der Universität Bremen durch Analyse der Trends, Entwicklungen und Prognosen internationaler Tagungsbeiträge der Jahre 1967 bis 1998 untersucht.

Der Untersuchungszeitraum der ersten Studie[v], veröffentlicht 1987, erstreckte sich über 20 Jahre, von 1967 bis 1987. Basierend auf den Ergebnissen ihrer Studie trafen Dworatschek und Gutsch Aussagen über die Bedeutungen bestimmter Projektmanagement-Themen für die neunziger Jahre:

· Der Komplex der Human Resources wird in zunehmender Weise das Projektmanagement dominieren.

· Ebenso wird der Bereich der Organisationsmodelle einen Schwerpunkt im Projektmanagement darstellen.

· Die Gewichtigkeit der Kostenkontrolle als Projektmanagement-Thema wird schwinden.

· Der Themenkomplex Netzplantechnik wird auch weiterhin einen stark uneinheitlichen Verlauf aufweisen.

Die meisten dieser Prognosen trafen bisher zu, gleichwohl sind starke Relevanzschwankungen in unterschiedlichen Branchen zu beobachten.

Für den Zeitraum 1988 bis 1998 stellte Tina Nehlsen im Rahmen einer zweiten Studie am IPMI Thesen über den weiteren Wandel der Themenschwerpunkte im Projektmanagement auf. Nicht alle ihre Thesen konnten durch die Analyse internationaler Tagungsbeiträge bis 1998 bestätigt werden; die Themenschwerpunkte der nach dem Ende dieser Studie folgenden zwei Jahre zeigen jedoch, dass sie mit ihren Annahmen weit gehend richtig lag.

· Innovationen auf dem Gebiet der Informationstechnologie, insbesondere dem Internet.

In den frühen neunziger Jahren entspannte sich der Ost-West-Konflikt und es entwickelte sich der europäische Binnenmarkt. Dies ermöglichte eine zunehmende Globalisierung der Märkte und Unternehmen, die sich auch im Projektmanagement niederschlägt. Diese zunehmende Globalisierung führt zur

· steigenden Thematisierung multikultureller Teams und kultureller Differenzen,

· anwachsenden Bedeutung von neuen Projektorganisationsformen in Joint Ventures und virtuellen Kooperationen und

Die steigende Konzentration in der Weltwirtschaft verschärft für die einzelnen Unternehmen den Wettbewerbsdruck. Dies bedingt eine große Nachfrage nach effizientem Projektmanagement mit

Mit der wachsenden Notwendigkeit, time-to-market zu optimieren und Organisationen zu straffen, findet Projektmanagement in immer mehr Branchen und Sektoren Anwendung. Damit verbindet sich eine

· zunehmende Thematisierung des Projektmanagements in sämtlichen wirtschaftlichen Sektoren und

Innovationen auf dem Gebiet der Informationstechnologie verstärken die Bedeutung von EDV-Systemen und Software. Die Computernutzung steigt im Projektmanagement an. Die anwachsende Verwendung von Informationstechnologien impliziert eine

· eine abflachende Häufigkeit der Thematisierung von reiner PC-Software, verbunden mit einer Diversifizierung auf dem Gebiet der Informationstechnologie und

· die steigende Anwendung des Projektmanagements in der Software-Branche aufgrund der zunehmenden Nachfrage in der auftragsbezogenen Produktion.

Seit Mitte der Neunziger dominiert das Internet den Datenverkehr. Diese Tendenz beeinflusst das Projektmanagement nachhaltig und führt zu

Nehlsens Studie hat ergeben, dass trotz einer erhöhten Notwendigkeit von effizientem Projektmanagement die Elemente Ablauf- und Terminplanung sowie Kosten-, Einsatzmittel- und Finanzmittelmanagement nicht mehr im Schwerpunkt der Betrachtung stehen.

Die neuen Wege auf der Suche nach Effizienz im Projektmanagement beschäftigen sich mehr mit den soft factors, dem Einfluss unterschiedlicher nationaler und Unternehmens-Kulturen auf den Projekterfolg sowie mit der Qualität im Projekt. Dies belegt auch die jährlich steigende Zahl an Bewerbungen von Projektteams um den deutschen projektmanagement award. Dieser Award wurde von der GPM ins Leben gerufen und 1997 erstmalig vergeben. Er orientiert sich an den TQM (Total Quality Management)-Modellen für Business Excellence in Unternehmen[vii]. Für diesen Award werden Projektteams nach Ergebnissen in folgenden Bereichen gemessen:

Zu den Finalisten gehören Projektteams aus unterschiedlichen Branchen und Unternehmen wie DeTeSystem (Deutsche Telekom Systemlösungen), Deutsches Zentrum für Luft- und Raumfahrt, Landesbausparkasse Württemberg, Lufthansa , Merck , Siemens u. a.[viii]

1.3 Projektmanagement in Unternehmen

1.3.1 Projekt oder Nicht-Projekt?

Trotz aller Standardisierungstendenzen im Verständnis der Inhalte und Kompetenzen im Projektmanagement sind sich die PM-Spezialisten über den Einsatz des Projektmanagements nicht gänzlich einig: Die einen finden den Projekteinsatz allein nach der klassischen Definition nur für große und einmalige Vorhaben sinnvoll und sprechen über „Projektitis“, wenn auch kleinere Aufgaben mit Projektansatz angegangen werden[ix]. Die anderen zeichnen die Vision über projektorientierte Unternehmen[x] und Management by Projects als zentrale Managementstrategie eines projektorientierten Unternehmens, um neue Chancen und Herausforderungen wahrnehmen zu können, am Unternehmenshimmel[xi]. Die Praktiker versuchen die Wahrheit irgendwo dazwischen zu finden.

Die „klassische“ Definition eines Projekts gibt uns die DIN-Norm: Nach DIN 69 901 ist ein Projekt ein

„Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z. B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben und projektspezifische Organisation“.

Ist nun das Vorhaben eines Softwareunternehmens, das jeweils zweimal im Jahr, jeweils getaktet auf die aktuellen Messetermine, ein neues Release seiner Software vorstellen möchte, ein Projekt? Oder ist es kein Projekt, weil es sich jährlich wiederholt und – solange das Unternehmen auf dem Markt bleibt – die Software wie am Fließband weiterentwickelt wird? Ist die Auftragsfertigung eines Maschinenbau-Unternehmens, das auf Sonderbestellung eines Kunden Baumaschinen im Wert von mehreren Millionen Mark fertigt, ein Projekt, oder ist es kein Projekt, weil Baumaschinenfertigung zur klassischen Produktion gehört? Diese Fragen könnten mit Beispielen aus verschiedenen Geschäftsfeldern weitergeführt werden. Kann man das Vorhaben „Projekt“ noch etwas genauer abgrenzen?

Die allgemeine Projektmanagementlehre ist hochgradig abstrakt, um Projekte aller Art und verschiedener Bereiche umfassen zu können. In den Projektmanagementpublikationen finden wir vielfach Versuche, Projekte nach verschiedenen Merkmalen zu klassifizieren und zu diversifizieren, beispielsweise nach

· dem Projektinhalt (Investitionen, Forschung und Entwicklung, Organisationsänderungen in unterschiedlichen Fachbereichen und Branchen),

· der sozialen Komplexität (multikulturelle Projekte sowohl im Sinne der unterschiedlichen Unternehmenskulturen als auch im Sinne der Multinationalität),

· dem Innovationsgrad (komplexe Lösung aus bekannten Komponenten versus Projekt an den aktuellen technologischen Grenzen der Machbarkeit),

· der Bedeutung für das Unternehmen (Business as usual, strategische Projekte, unternehmenskritische Projekte)[xii].

Darüber hinaus wurde gerade in den letzten Jahren, belebt durch die schwierige Wirtschaftssituation, eine Vielzahl von Konzepten in das Unternehmensleben übernommen, deren Abgrenzung, Schnittstellen und Integration zum und mit Projektmanagement noch genauer definiert werden müssen. Es sind, um nur einige zu nennen: Total Quality Management (TQM), die mit ISO 9000 verbundene Prozessoptimierung, Quality Function Deployment (QFD), Lean Production, Concurrent Engineering, Business Process Reengineering und andere mehr.

In seinem Buch „In Search of Excellence in Project Management“[xiii] betont Kerzner:

„Another strategic benefit of Project Management is that it can be integrated successfully with other management systems. The four most relevant today are concurrent engineering, total quality management, risk management and change management.“

Abbildung 4: Auswirkungen der Synergien von Projektmanagement und anderen Management-Systemen auf die Produktentwicklung (Erhebung von 1991)

Hierzu führt Kerzner ein Beispiel an, wie sich die Synergien aus dieser Kombination in einigen großen Unternehmen bei deren Einführung 1991 ausgewirkt haben. Die Ergebnisse waren beeindruckend, der Produktlebenszyklus verkürzte sich teilweise von mehreren Jahren auf etwa zwölf Monate (z. B. bei IBM und Honeywell, siehe Abbildung 4).

1.3.2 Projekte und Kulturen

Kommen wir noch einmal auf die Frage von „Projekt oder Nicht-Projekt“ im Unternehmen zurück: Diese kann, wie auch Schelle in seinem Taschenbuch „Projekte zum Erfolg führen“ betont, nur durch Definition von firmenindividuellen Kriterien beantwortet werden.

Wie ein Unternehmen Projekte definiert und von den Geschäftsprozessen abgrenzt oder sie in diese integriert, hängt von der Unternehmenskultur und der Projektkultur im Unternehmen ab.

1.3.2.1 Unternehmenskultur und Gesellschaft

Unter Unternehmenskultur wird allgemein ein Werte-, Normen- und Verhaltens-Modell im Unternehmen verstanden, von dem die Entscheidungen und das Verhalten der Unternehmungsmitglieder geprägt wird. Eine Unternehmenskultur steht immer im Kontext zur Gesellschaftskultur; das Verhalten der Menschen im Unternehmen ist also auch von den Normen und Werten der Gesellschaft geprägt. Eine Tatsache, die besonders bei globalisierten, weltweit operierenden Unternehmen berücksichtigt werden muss.

Die Gesellschaft in Zusammenspiel mit der Unternehmenskultur beeinflusst letztendlich auch das Verhalten jedes einzelnen Mitarbeiters.

„Der Erfolg der japanischen Wirtschaft ist nicht zuletzt darauf zurückzuführen, dass in japanischen Firmen eine andere Art der Zusammenarbeit praktiziert wird. Das in der japanischen Gesellschaft geltende Gruppenprinzip, also das Zurücktreten des Einzelnen zugunsten der Gruppe, findet sich naturgemäß auch als Element ihrer Unternehmenskultur wieder. Bedingt dadurch dauern Entscheidungsprozesse für unsere Verhältnisse scheinbar unnötig lange. In Wirklichkeit finden dabei jedoch die für den späteren Erfolg maßgeblichen Abstimmungsprozesse statt.“

Gleichzeitig warnt Müller davor, zu versuchen, diese Unternehmenskultur in westlichen Unternehmen zu kopieren:

„Nicht nur, dass es vermutlich katastrophale Folgen hätte, sondern im Gegenteil, wir brauchen es nicht. Die traditionellen Stärken unseres Kulturkreises, wie z. B. Kreativität, Individualität, Flexibilität und daraus resultierende Eigenschaften wie Forscherdrang und Risikofreude, sind völlig ausreichend, um im internationalen Wettbewerb zu bestehen.“

Die Globalisierung der Märkte geht nicht mit einer Globalisierung der Unternehmenskultur einher. In den einzelnen Ländern und in verschiedenen Unternehmen bestehen enorme Unterschiede im Führungsstil [xv]. Wie unterschiedlich auch gleiche Management-Konzepte in verschiedenen Ländern angewendet werden und wie dadurch die Ergebnisse beeinflusst werden können, zeigt eine internationale Studie des Massachusetts Institute of Technology aus dem Jahre 1992. In dieser Studie wurden alle F&E-Projekte bei der Entwicklung eines neuen Automobil-Modells in Zusammenhang mit dem damals neuen Konzept der Lean Production verglichen. Die Ergebnisse der Studie zeigen, dass japanische Projekte ihr Ziel mit kleineren Projektteams und weniger Aufwand bei kürzeren Entwicklungszeiten erreichten (siehe Abbildung 5).

Abbildung 5: Internationaler Vergleich der Effektivität der F&E-Projekte in der Autoindustrie (nach [Womack+ 1992], Seite 124)

Mit dem Wunsch, im Rahmen der Globalisierung von einem Wettbewerb zur Kooperation überzugehen und ihr Geschäft auf Japan oder den asiatischen Raum auszuweiten, haben einige westliche Unternehmen schmerzhaft teure Lektionen lernen müssen: Man soll die fremde Unternehmenskultur nicht kopieren, jedoch ohne deren Kenntnis, Verständnis und gegenseitigem Respekt ist jede Art von Kooperation zum Scheitern verurteilt.

1.3.2.2 Projektkultur

In Projekten werden in der Regel interdisziplinäre Teams gebildet. Die einzelnen Fachdisziplinen bringen dabei in das Projekt ihre eigene Fachkultur mit ein. Diese Fachkultur, auch funktionale Kultur[xvi] genannt, ist die Summe der Eigenschaften, Fähigkeiten und Verhaltensmuster, die aus der Zugehörigkeit zu einem bestimmten funktionellen Fachbereich resultieren.

Die Überlegungen zur Projektkultur können analog aus der Unternehmenskultur abgeleitet werden. Nach DIN 69 905 „Projektabwicklung“, vom Mai 1997, wird Projektkultur wie folgt definiert:

„Projektkultur ist die Gesamtheit der von Wissen, Erfahrung und Tradition beeinflussten Verhaltensweisen der Projektbeteiligten und deren generelle Einschätzung durch das Projektumfeld.“

In den letzten Jahren finden aufgrund von Globalisierung, Firmenfusionen und Produktions-Outsourcing in wirtschaftlich günstigere Länder immer mehr internationale Projekte statt. In Projekten, die Unternehmens- und Landesgrenzen übergreifend durchgeführt werden, kann ein Aufeinanderprallen von unterschiedlichen Unternehmens- und Landeskulturen schwerwiegende negative Folgen für die Projektarbeit haben. Nur eine stark ausgeprägte Projektkultur kann in solchen Projekten den Zusammenhalt für das Team bieten und dadurch den Projekterfolg positiv beeinflussen.

Der Zusammenhang von Gesellschaft, Unternehmen und Projekt bis zum Verhalten eines Einzelnen ist in Abbildung 6 dargestellt.

1.3.2.3 Multikulturelles Projektmanagement

Das Thema multikulturelles Projektmanagement ist aus oben genannten Gründen zur Zeit hoch aktuell und wird zunehmend auf den Projektmanagement-Fachkongressen diskutiert. Die unten skizzierte Problematik potenziert sich beim Einsatz virtueller multikultureller Teams.

In einer Studie von Gemini Consulting und der Fachhochschule Gießen, die anlässlich des GPM Projektmanagement-Forums 2000 vorgestellt wurde, haben 80 % der befragten Unternehmen angegeben, dass für sie internationale Projekte hohe Bedeutung haben. 72 % der Befragten gaben gleichzeitig zu, dass den kulturellen Aspekten nicht genügend Beachtung geschenkt wird:

· es fehlt die Sensibilität für kulturelle Unterschiede und die Bereitschaft, darauf einzugehen,

· die Bildung einer Projektkultur ist demnach unmöglich, die Kultur der Muttergesellschaft wird als „Die Kultur“ angenommen.

Die typischen Probleme bei internationalen Projekten ziehen sich über alle Projektphasen hinweg und erschweren wesentlich die Projektarbeit: von Missinterpretation der Projektziele über mentalitätsbedingte Unterschiede in der Zeit- und Aufwandsplanung bis zum Verhalten in Konfliktsituationen gibt es keinen Fettnapf, in den man in einem internationalen Projekt nicht treten kann. Dies sollte bereits bei der Auswahl des Projektteams berücksichtigt werden: Die Teambesetzung ist ein kritischer Erfolgsfaktor internationaler Projekte.

Bei internationalen Projekten werden Faktoren wie Sprachkompetenz, emotionale Kompetenz und Kulturkompetenz als unabdingbar empfunden, die Fachkompetenz wird dagegen als nicht so wichtig betrachtet wie in nationalen Projekten. So muss bereits in der Startphase eines internationalen Projekts im Rahmen der Umfeld-Analyse auch eine Ist-Analyse der beteiligten Kulturen durchgeführt und auf der Basis deren Ergebnisse eine entsprechende Projektkultur etabliert werden. Dabei darf nicht eine der beteiligten Kulturen dominieren, sondern es muss eine „Mischkultur“ geschaffen werden, mit der sich alle Projektteam-Mitglieder identifizieren können. Wie bereits erwähnt: Eine gut eingeführte und gelebte Projektkultur kann helfen, die kulturellen Unterschiede länder- und unternehmensgrenz-übergreifend zu überbrücken.

Kooperation heißt Kommunikation! Eine gut funktionierende Kommunikation, im Sinne von

· alle relevanten Informationen, wenn benötigt, (bezüglich Zeit und Ort) verfügbar zu haben und

Bei interkulturellen Teams ist oft die Unkenntnis nationaler Symbole, Helden, Rituale und Werte eine Ursache für Probleme. Projektmitglieder solcher Teams sollten die unterschiedlichen verbalen und nonverbalen Kommunikationsverhaltensweisen der am Projekt beteiligten Kulturen kennen, um diese richtig interpretieren zu können. Erreicht wird das beispielsweise mit Techniken des interkulturellen Trainings, denen in der Projektstartphase genügend Beachtung geschenkt werden sollte. Dieses kann das Studium von Literatur zum Thema enthalten, Vorträge, Filme, Bearbeitung von Fallbeispielen, Rollenspiele, Sensitivity Training oder anderes mehr[xviii]. Internetbasierte E-Learning-Anwendungen sind hierfür ebenfalls ein hilfreiches Werkzeug.

Das internationale Team führt eine Videokonferenz mit modernster Technik durch. Die Mitglieder aus den USA, Brasilien und Bulgarien kennen sich noch nicht. Sie sind der Projektleiter: „Guten Tag, alle zusammen, sind wir bereit für die Konferenz?“ fragen Sie in die Kamera. Alle nicken, nur der Bulgare schüttelt den Kopf. Was hat der denn?!? Tja, in Bulgarien bedeutet Kopf-Schütteln ein „ja“, nicken ein „nein“. Können Sie sich vorstellen, welche Missverständnisse eine falsche Interpretation dieser Geste hervorrufen kann, wenn er erstmal nickt!? Die Konferenz geht weiter. Sie fragen: „Waren die Projektberichte in Ordnung?“ Der Amerikaner zeigt mit der Hand das OK-Zeichen (Zeigefinger und Daumen zu einem „O“ gekringelt). Der Brasilianer ist sichtlich befremdet. Was hat der denn nun? In Brasilien bedeutet dieses Handzeichen so was wie „Du Arschloch“. Die Konferenz geht weiter ...

Im vorliegenden Buch wollen wir auf die spannende Problematik der internationalen Teams bezüglich ihres Verhaltens nicht weiter eingehen. Die Berücksichtigung aller das Projektteam beeinflussenden Kulturen muss ein fester Bestandteil der Projektmanagement-Prozesse werden. Wir werden aber die nicht minder spannende Thematik der Kooperation von verteilten Teams (die natürlich – je nach Grad der Verteilung – auch oft multikulturell sind) unter Zuhilfenahme des Werkzeugs Internet besprechen.

Will man das Internet als Instrument für das Projektmanagement nutzen, ist vor allem die Funktionalität von Interesse, die die Kommunikation in einem Projektteam unterstützt. Bei der internetbasierten Gruppenarbeit in Projektteams erhalten Kommunikation und Gestaltung von Kommunikationsprozessen eine neue Bedeutung. Mit den in diesem Buch skizzierten technischen Möglichkeiten werden nur die funktionellen Lösungen besprochen; der Leser sollte die Wichtigkeit der interkulturellen Unterschiede dennoch immer im Hinterkopf behalten.

Im Folgenden gehen wir also davon aus, dass die Entscheidung, ein Vorhaben in der Form eines Projekts durchzuführen, gefallen ist. Es werden Projekte betrachtet, deren Ablauf und Ergebnisse durch das Nutzen des Werkzeugs Internet wesentlich beeinflusst werden können.

1.3.3 Unternehmensstruktur und Projektorganisation

Um die unterschiedlichen Dimensionen der Problematik beim Projekteinsatz verständlich ordnen und erläutern zu können, vereinfachen wir die Vielfalt an organisatorischen Möglichkeiten, Projekte in Unternehmen und für Unternehmen durchzuführen, auf drei grundsätzliche Szenarien. Diese Szenarien werden dann jeweils schwerpunktmäßig unter folgenden Aspekten näher diskutiert[xix]:

1.3.3.1 Szenario 1: Internes Projekt im Unternehmen

Bei diesem Szenario werden wir zwei Varianten der Unternehmensstruktur unterscheiden:

· Variante 1b: ein Unternehmensverbund oder ein durch Neugründung, Fusionen oder Kooperationen neu entstandenes Unternehmen.

Unternehmen beider Varianten sind bereit, in Standardisierung, Qualitätsmaßnahmen, Mitarbeiterausbildung und Erfahrungssicherung bzw. Knowledge Management zu investieren und betrachten diese Investitionen als längerfristige Anlage mit einem gesicherten Return of Investment.

Es ist anzunehmen, dass das in der Variante 1a beschriebene „alteingesessene“ Unternehmen bereits einen höheren Reifegrad bezüglich der oben genannten Faktoren besitzt.

In diesem Szenario findet ein Projekt einmalig oder in ähnlicher Ausprägung wiederholt intern im Unternehmen und für das Unternehmen statt. Das Projektteam besteht überwiegend aus eigenen Mitarbeitern des Unternehmens und ist voll in die Unternehmensorganisation und Unternehmenskultur eingebettet.

Der Auftraggeber ist in der Regel die Geschäftsleitung oder ein Fachbereich. Beispiele solcher Projekte sind interne IT-Projekte, Organisationsprojekte oder F&E-Projekte.

Der Reifegrad des Unternehmens bezüglich Projektmanagement und Qualitätsmanagement sowie eventuell vorhandene Qualitätssysteme oder TQM-Konzepte beeinflussen direkt das Verständnis für Projektmethodik und Qualität in Projekten dieses Unternehmens. Finden in einem solchen Unternehmen wiederholt Projekte statt, wird bei Unternehmen mit einem höheren Projektmanagement-Reifegrad dafür in der Regel ein Vorgehensmodell und eine Arbeitsplattform zur Verfügung gestellt.

Bei einem „alteingesessenen“ Unternehmen gilt in der Regel, dass für alle Mitarbeiter eine einheitliche IT- und Kommunikations-Plattform existiert. Dies könnte beispielsweise eine auf Lotus Notes oder Microsoft Exchange basierte Lösung sein. Diese Plattform kann von den internen Projekten voll genutzt werden.

Internet spielt hier in der Regel keine große Rolle, da die meisten Unternehmen seit Jahren bereits mit LAN und WAN vernetzt sind, es sei denn, es wird vom Unternehmen als Intranet zur unternehmensweiten Kommunikation und als Wissensspeicher eingesetzt.

Bei einem Unternehmensverbund (Szenario 1b) existiert in der Regel noch keine einheitliche IT-Plattform. Für Projekte, die hier durchgeführt werden, bietet die Internet-Technologie mit den Anwendungen für E-Collaboration wirtschaftliche und durchgängig verfügbare Lösungen.

1.3.3.2 Integration der Projektorganisation in die Unternehmensorganisation

Die Projekte können organisatorisch in das Unternehmen unterschiedlich eingebettet werden. (In Abbildung 7 ist bei einem Projekt im Unternehmen beispielsweise eine Matrixorganisation angedeutet.)

„Projektorganisation ist die Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten Projekts.“

In der Literatur werden seit Jahren hauptsächlich die folgenden drei „klassischen“ Formen der Einbettung von Projektorganisation in ein Unternehmen diskutiert[xx]:

Bei der Projektabwicklung im Rahmen der Stabs-Projektorganisation (auch Einfluss-Projektorganisation genannt) wird für die Projekte keine gesonderte Organisation geschaffen, die Projekte werden neben dem Tagesgeschäft durchgeführt.

Die Vorteile dieser Organisation liegen darin, dass sie sich ohne zusätzlichen Aufwand einrichten lässt und recht flexibel ist. Die Projektmitarbeiter bleiben der Stammorganisation angegliedert und sorgen für das Know-how zwischen Fachabteilungen und Projekt. Nachteilig ist der relativ umständliche Entscheidungsweg, da der Projektleiter in der Regel keine Weisungsbefugnis hat.

Diese Organisationsform wird in der Praxis relativ häufig verwendet, obwohl sie für die Projektdurchführung nicht besonders effektiv ist. Sie eignet sich höchstens für kleinere Projekte.

Bei der Matrixorganisation wird, wie der Name bereits andeutet, die vertikale Linienorganisation mit einer horizontalen Projektorganisation überlagert. Jeder Mitarbeiter, der im Projektteam arbeitet, wird bei dieser Organisationsform zwei Instanzen unterstellt: dem Linienvorgesetzten und für die Dauer des Projekts dem Projektleiter. Die Verantwortung und die Kompetenzen müssen zwischen dem Linien- und dem Projektmanagement projektbezogen aufgeteilt werden. Diese Organisationsform ist für die Projektdurchführung recht effektiv, gleichwohl können Konflikte durch die unterschiedlichen Interessen des Projekts und des Linienmanagements entstehen, die dann auf dem Rücken der Mitarbeiter ausgetragen werden.

Diese Organisationsform wird ebenfalls recht häufig verwendet, auch wenn ihr die Fachleute kritisch gegenüberstehen. Sie wird als die aufwendigste aber auch die wirtschaftlichste und in Anbetracht der oft knappen Personalressourcen, oft als die einzig durchsetzbare Organisationsform für Projekte betrachtet.

Bei der autonomen oder auch „reinen“ Projektorganisation wird für ein Projekt eine praktisch eigenständige Organisationseinheit gebildet. Der Projektleiter hat für diese Organisationseinheit die volle Verantwortung. Bei größeren Bauprojekten ist es üblich, dass für ein Projekt eine selbständige Firma gegründet wird, die nach Ende des Projekts wieder aufgelöst wird. Ansonsten ist das Projekt wie ein Geschäftsbereich zu nehmen, nur dass er zeitlich befristet besteht.

Diese Projektorganisation eignet sich für große Projekte und wird als die effizienteste Form der Projektdurchführung betrachtet. Kritisch ist der Know-how-Transfer aus den Unternehmens-Fachbereichen in das Projekt und aus dem Projekt in die Fachbereiche. Problematisch ist auch die Wiedereingliederung der Projektmitarbeiter in das Unternehmen nach dem Projektende.

1.3.3.3 Szenario 2: Projektorientiertes Unternehmen als Projektauftragnehmer

Bei diesem Szenario ist der Projektauftragnehmer ein Unternehmen, das auf dem Markt hauptberuflich Projekte für andere Unternehmen durchführt. Es können Projekte aus dem Bau- oder Anlagenbaubereich sein oder Investitions- bzw. IT-Projekte. Der Auftraggeber ist ein externer Kunde. Die Vergabe des Projektauftrags wird in der Regel unter mehreren konkurrierenden Anbietern entschieden. Das Ergebnis der Projektarbeit mag vom Auftraggeber als schlüsselfertige Lösung gewünscht sein (Variante a) oder unter Beteiligung des Auftraggebers in einem gemeinsamen Projektteam erarbeitet werden (Variante b).

Da die Durchführung von Auftragsprojekten zum Kerngeschäft der anbietenden Unternehmen gehört, sind diese in der Regel projektorientiert ausgerichtet und haben eine mit der Unternehmenskultur verbundene Projektkultur aufgebaut. Das heißt, dass diese Unternehmen in der Regel projektorientierte Vorgehensmodelle verwenden, in denen auch entsprechende Qualitätsmaßnahmen, Methoden und Instrumente verankert sind. Ihre Mitarbeiter werden projektorientiert ausgebildet und gefördert, die Erfahrungen aus den Projekten werden gesammelt, ausgewertet und in die Folgeprojekte eingebracht. Ein projektorientiertes Unternehmen betrachtet Investitionen in Standardisierung, Qualitätsmaßnahmen und Mitarbeiterausbildung als lebensnotwendig und wettbewerbsbeeinflussend.

Gareis[xxi] definiert die Merkmale eines projektorientierten Unternehmens wie folgt:

· Die Dynamik der Umwelt wird in den dynamischen Unternehmensstrukturen abgebildet.

Patzak und Rattay[xxii] weisen darüber hinaus darauf hin, dass projektorientierte Unternehmen sich typischerweise auch durch Kundenorientierung auszeichnen.

Dieses Szenario (insbesondere Variante a in Abbildung 12) dürfte demnach die wenigsten Probleme bezüglich Projektmanagement, Methoden, Instrumenten und projektbezogenen Kommunikationsplattformen in Projekten erwarten lassen. In der Praxis prallen jedoch oft unterschiedliche Unternehmenskulturen, Arbeitsstile und Vorstellungen aufeinander, insbesondere bei Projekten, die in gemeinsamer Teamarbeit mit einem im Projektmanagement unerfahrenen Kunden abgewickelt werden sollen (Variante b in Abbildung 12): bezüglich der geforderten Qualität und des Aufwands, diese zu planen, zu steuern und zu kontrollieren und in der Beziehung zwischen Auftragnehmer und Auftraggeber.

Darüber hinaus möchte meist keines der Unternehmen einem „fremden“ Projektteam ohne weiteres Zugriffsrechte zu seiner IT-Infrastruktur einräumen. Auch bei diesem Szenario ist also eine projekteigene Arbeits- und Kommunikations-Plattform für das Projektteam ein notwendiges Instrument für die gemeinsame Projektarbeit.

Die Projektmitarbeiter des Auftragnehmers, unabhängig von dessen Standort, verrichten meist (insbesondere bei der Variante b in Abbildung 12) ihre Projektarbeit vor Ort beim Kunden. Daher sind solche Projekte mit immensen Reise- und Opportunitätskosten aufgrund der unproduktiven Reisezeiten behaftet. Es überrascht nicht, dass gerade projektorientierte Unternehmen in geeignete internetbasierte Standardlösungen für die Teams ihrer Projekte investieren, die eine Projektarbeit abgekoppelt von der Vor-Ort-Präsenz ermöglichen. Eine Lösung für virtuelle Teams ermöglicht darüber hinaus eine gute Eingliederung aller Projektpartner in die Projekt-Informations- und Kommunikationsprozesse.

Wie dies einige große Unternehmen wie Siemens, Hewlett-Packard oder IBM realisieren, wird in Abschnitt 2.4.5 beschrieben.

1.3.3.4 Szenario 3: Generalunternehmen als Projektauftragnehmer

Das dritte Szenario kommt in der Praxis immer häufiger vor. Grund dafür ist die Notwendigkeit, aktuelles Spezialwissen oder Kapazitäten, die in einem einzelnen Unternehmen nicht in der erforderlichen Qualität und Menge für ein Projekt vorhanden sind, in das Projekt einzubringen. Zu diesem Zweck bilden die Unternehmen Netzwerke oder rechtlich-organisatorische Kooperationsformen, die speziell für die Durchführung des Projekts etabliert und danach in der Regel aufgelöst werden (siehe Abbildung 13).

Keines der beteiligten Unternehmen betrachtet sich in der Regel zuständig für Investitionen in Standardisierung, Qualitätsmaßnahmen, Ausbildung des Gesamtteams und Bereitstellung entsprechender einheitlicher Arbeits- und Kommunikationsplattformen. Projektmanagement in diesem Szenario ist eine überaus anspruchsvolle Aufgabe. Sie ist mit einem Risikopotenzial behaftet, das direkt proportional zu folgenden Faktoren ist:

· Unterschiede der kooperierenden Unternehmen im Reifegrad des Projektmanagements und Qualitätsmanagements,

· Mangel an Bereitschaft, vertrauliche Vorgehensmodelle, die als intellektuelles Kapital des Unternehmens betrachtet werden, an die kooperierenden Unternehmen oder Unterauftragnehmer weiterzugeben,

· Mangel an Bereitschaft des Auftragnehmers, in die Ausbildung eines temporären Projektteams aus unternehmensfremden Mitarbeitern zu investieren,

· keine gemeinsame Arbeits- und Kommunikationsplattform bei gleichzeitig mangelnder Bereitschaft des Auftraggebers, den Aufwand für diese Plattformen im Projektbudget zu berücksichtigen,

Dieses Szenario ist eine echte Herausforderung und ohne eine durch das Projektbüro tatkräftig unterstützte gemeinsame IuK-Plattform schwer zu meistern, unabhängig davon, ob das Projektteam überwiegend vor Ort oder verteilt arbeitet. In der Regel fallen hier für das Projektteam ebenfalls immense Reisekosten sowie Opportunitätskosten wegen langer unproduktiver Reisezeiten an. In diesem Szenario werden wir uns daher künftig intensiver mit vernetzten Kooperationsformen und virtuellen Teams beschäftigen müssen.

Da die IuK-Plattform nur für die Dauer des Projekts von Interesse ist und mit dem Auflösen des Projektteams am Projektende in der Regel ebenfalls aufgelöst wird, sind Projektteams in solchen Szenarien die künftige Kunden-Zielgruppe der Application Service Provider (ASP) im Allgemeinen und der Anbieter für Virtual Project Management Offices (VPMO) im Besonderen. Mehr über ASP steht in Kapitel 4. Die Funktionalität eines VPMO sowie einige Anbieter sind im Anhang vorgestellt.

Die Nutzung der Internet-Technologien in diesen Projekten ist eine unabdingbare Voraussetzung für eine erfolgreiche Teamarbeit und darüber hinaus auch noch die wirtschaftlichere Lösung.

1.3.3.5 Virtuelle Projektteams

In allen bisher besprochenen Organisationsformen wird implizit angenommen, dass das Projektteam räumlich nah zusammenarbeitet.

Die Diskussion der in Abschnitt 2.3.3.2 aufgeführten Organisationsformen erhält eine neue Dimension, wenn es sich beim Projektteam um ein virtuelles Team handelt, das heißt, wenn die Projektmitarbeiter räumlich und eventuell auch zeitlich verteilt arbeiten (in unterschiedlichen Zeitzonen, beispielsweise in Deutschland und England oder den USA).

Virtuelle Teams können bereits entstehen, wenn Projekte in einem Unternehmen durchgeführt werden, das im Land oder über die Landesgrenzen hinaus verteilte Geschäftstellen oder Tochterunternehmen hat (Szenario 1a). In einem solchen Unternehmen finden wir in der Regel eine einheitliche Unternehmenskultur vor, in der vielleicht auch schon die unterschiedlichen Landeskulturen berücksichtigt sind. Die einzelnen Projektmitarbeiter oder Teilprojektteams können, je nach Präferenz des Auftraggebers, in allen in Abschnitt 2.3.3.2 beschriebenen Organisationsformen arbeiten. Die räumliche Entfernung zu den Projektkollegen muss in einem virtuellen Team mit Hilfe der im Unternehmen verfügbaren IuK-Technologien kompensiert werden.

Wird das Projekt dagegen in einem kürzlich durch Fusion oder eine vernetzte Kooperationsform erweiterten Unternehmen durchgeführt, bringt auch jedes der Unternehmen seine Kultur und seinen Managementstil in den Verbund mit ein: Unternehmenskulturen und je nach geografischer Verteilung auch unterschiedliche Landeskulturen können hier aufeinander prallen. In diesem Fall muss die Projektleitung von der Geschäftsleitung, die als Auftraggeber fungiert, genügend Freiraum und Unterstützung erhalten, um die Konfliktpotenziale abzufangen. Es empfiehlt sich, Vertreter aller Unternehmen in den Projektlenkungssausschuss aktiv einzubinden.

In einem Unternehmensverbund steht dem Projektteam in der Regel ebenfalls keine einheitliche IT- und Kommunikationsplattform zur Verfügung. Hier gewinnt das Internet eine strategische Bedeutung, da es meist die einzig mögliche wirtschaftliche Informations- und Kommunikationsplattform für das Projektteam bietet. Welche Software-Lösungen man auf einer solchen Plattform erreichen kann, wird in Abschnitt 2.4 besprochen.

Bei Projekten, die in den Organisations-Szenarien 2b und 3 stattfinden, bei denen also die Projektteam-Mitglieder prinzipiell aus mehreren Unternehmen stammen, wird der professionelle Einsatz von virtuellen Teams mittelfristig zu einem entscheidenden Projekterfolgsfaktor und dadurch auch Wettbewerbsfaktor.

Für die Unterstützung der Projektarbeit in virtuellen Teams empfiehlt es sich auf jeden Fall, ein Projektbüro einzurichten, das u. a. auch für die Projekt-Kommunikationsplattform sorgt. Die Rollen und Aufgaben eines Projektbüros werden in Abschnitt 2.5 besprochen.

1.3.4 Aspekte der Personalentwicklung

Trotz wachsender Bedeutung der Informations- und Kommunikationstechnologien für die Projektarbeit dürfen wir nicht vergessen, dass es Menschen sind, die diese nutzen, und von diesen Menschen hängt zuletzt der Projekterfolg ab. In den folgenden Abschnitten werden wir uns deshalb mit den Anforderungen beschäftigen, die ein Projekt an diese Menschen stellt und auch damit, wie man diese Menschen darauf vorbereiten kann.

1.3.4.1 Anforderungen an Projektmanager

In Projektmanagement-Kreisen wurde das Projektmanagement lange als allgemein gültige, das heißt, branchenunabhängige und auf alle Projekte anwendbare Methode verstanden. Dieses Verständnis hat sich in den letzten Jahren etwas gewandelt. Insbesondere IT-Projekte haben z. B. Eigenheiten, die nicht mit den herkömmlichen klassischen PM-Planungsmethoden in Griff zu bekommen sind. Auch die Anforderungen an einen Softwareentwicklungs-Projektleiter sind etwas anders gelagert als z. B. die an einen Bauprojektleiter.

In Kaffeepausengesprächen anlässlich großer Projektmanagement-Tagungen konnte man oft Unterhaltung folgender Art verfolgen:

„Projektleiter? Der? Der hat doch nur fünf Programmierer, die den ganzen Tag im Büro sitzen! Unser Projektleiter dagegen muss auf der Baustelle seinen Mann stehen und da hat er 150 Leute unter sich!“

Das Qualifikationsspektrum eines Projektmanagers muss gleichermaßen Projektmanagement-Kenntnisse, allgemeine Management-Fähigkeiten sowie Branchenkenntnisse abdecken (siehe Abbildung 14).

Diese Bereiche und deren Überlappung erhalten je nach Komplexität und Größe des Projekts eine unterschiedlich gewichtete Bedeutung: Je kleiner das Projekt, desto mehr kommt das Fachwissen des Projektmanagers zum Einsatz; bei komplexen Projekten, die mehr Potenzial für Konflikte bieten, sind eher seine Management-Fähigkeiten und soziale Kompetenz gefordert. Ein Projektmanager muss je nach Einsatz und Situation mal mehr ein Spezialist und mal mehr ein Generalist sein.

Abbildung 15: Zusammenhang zwischen Fachkompetenz und sozialer Kompetenz eines Projektleiters in Abhängigkeit von der Komplexität des Projekts

Wenn wir die Definition eines Projekts als ein „einmaliges, zeitlich begrenztes Vorhaben“ berücksichtigen, ist jeder Projektmanager bezüglich seiner Projekte ein Manager auf Zeit. Die gleichen strengen Anforderungen sollten dennoch für alle professionellen Projektmanager gelten. Solche Forderungen sind z. B. durch die Internationale Projektmanagement-Vereinigung, IPMA, standardisiert in der IPMA Competence Baseline (ICB) festgehalten[xxiii]. Es werden gleichermaßen Forderungen an Wissen und Erfahrung in projektbezogenen Themen, an die Fähigkeit des Projektmanagers zum Systemdenken, das heißt, interdisziplinärem und ganzheitlichem Betrachten von umfangreichen und komplexen Sachverhalten sowie an seine Mitarbeiterführung, sein persönliches Verhalten und seine Sozialkompetenz gestellt.

Um einen internationalen Vergleich dieser Anforderungen und deren Erfüllung zu ermöglichen, können sich Projektmanager einem Zertifizierungsverfahren der IPMA (in Deutschland über GPM) unterziehen. Durch das PMI werden ebenfalls Projektmanager-Zertifizierungen durchgeführt, hier wird jedoch über ein Multiple Choice-Verfahren schwerpunktmäßig nur das Fachwissen abgefragt[xxiv].

Die Aufgaben eines Projektmanagers werden durch die Projektziele definiert; die Grenzen werden durch das Unternehmensmanagement gesetzt.

1.3.4.2 Einflussgrößen und Wirkungen der Teamarbeit in innovativen Projekten

Unser Schulsystem erzieht Einzelkämpfer und Individualisten. Nur einige wenige Hochschulen tragen dem Bedarf nach Teamarbeit im späteren Berufs- und Projektleben Rechnung und bieten den zu erarbeitenden Lehrstoff in Projektform an. Zu diesen Ausnahmen gehört auch das Institut für Projektmanagement und Wirtschaftsinformatik (IPMI) der Universität Bremen.

Am IPMI werden als Pflichtveranstaltung für die Studenten der Wirtschaftsfächer zweisemestrige Lehrprojekte durchgeführt. Ziel dieser Projekte ist es zum einen, einen bestimmten Fachinhalt zu erarbeiten, zum anderen, dieses Vorhaben in Gruppenarbeit mit der Projektmethodik durchzuführen. Die Studenten werden während ihrer Facharbeit in die Grundlagen der Projektarbeit eingeführt und motiviert, diese gleich in die Praxis umzusetzen. Für die meisten Studenten ist dieses Lehrprojekt nach eigenen Aussagen die erste Gelegenheit überhaupt, in einem Team zu arbeiten.

Reibungslos funktionierende Teamarbeit ist für einen guten Projektverlauf unabdingbar. Es ist schon schwer genug, eine Gruppe von nicht weiter miteinander bekannten Individualisten zu einem produktiven Team zusammenzuschweißen. Mit diesem Thema beschäftigen sich zahlreiche Publikationen und Seminaranbieter. Die meisten gehen davon aus, dass man diese Gruppe in einen Raum sperrt und erst rauslässt, wenn alle miteinander gut auskommen. Erfolgreiche Zusammenarbeit im Team wird oft mit einer guten Moderation gleichgesetzt[xxv]. Mitarbeiter in einem Projektteam müssen aber auch außerhalb der moderierten Gruppenveranstaltungen bei fortlaufendem Leistungs- und Termindruck zusammenarbeiten. Einflussgrößen auf diese Teamarbeit in innovativen Projekten wurden 1998 von Högl im Rahmen einer empirischen Studie untersucht[xxvi]. Für diese Untersuchung wurden Fachinterviews mit insgesamt 575 Mitgliedern aus 145 Softwareentwicklungsteams deutscher und in Deutschland operierender Softwarefirmen durchgeführt. Es galt, folgende Hypothesen zu untersuchen:

· Hypothese 1 (H1): Die Teamarbeit wirkt positiv auf die Ergebnisse von innovativen Projekten.

Alle diese Hypothesen wurden im Rahmen der erwähnten Studie bestätigt. Högl untersuchte dabei nur lokal an einem Ort arbeitende Teams; gleichwohl stellte er die räumliche Nähe als einen Faktor fest, der die Teamarbeit positiv beeinflusst. Nach dem Kenntnisstand der Verfasser liegen derzeit keine wissenschaftlich gesicherten empirischen Untersuchungen über die Erfolgsfaktoren der virtuellen Teams vor. Die besonderen Herausforderungen der Arbeit in virtuellen Teams werden deshalb nach den bisherigen Erfahrungen aus der Praxis formuliert (siehe auch Abschnitt 2.3.4.3).

Eine Untersuchung in Ländern mit anderen Kulturen könnte andere Ergebnisse bringen. Die für internationale Projektteams typischen, von der nationalen Kultur abhängigen Faktoren werden in Abschnitt 2.3.4.3 gesondert betrachtet.

Für die Untersuchung der Einflussgrößen auf eine erfolgreiche Teamarbeit im Kulturkreis der westlichen Industrieländer stellte Högl das nachfolgend beschriebene Denkmodell auf (siehe auch Abbildung 16).

1.3.4.2.1 Teambesetzung

Die Teambesetzung ist der Teil des Teamdesigns, das sich mit der Auswahl der Teammitglieder beschäftigt.

Soziale Kompetenz bringt die Grundlagen dafür „in guten und in schlechten Zeiten“ mit anderen Teamkollegen erfolgreich zusammenzuarbeiten. Sie wird hier im Sinne von Umgang mit sich selbst (Verantwortungsbewusstsein, Frustrationstoleranz, Aufrichtigkeit, Konfliktfähigkeit, u. a.) und als Umgang mit den anderen (Einfühlungsvermögen, Kommunikationsfähigkeit, Toleranz, Achtung u. a.) verstanden. Soziale Kompetenz ist eine elementare Voraussetzung für erfolgreiche Teamarbeit.

Methodische Kompetenz beschreibt die Fähigkeiten, die Projektplanung, Projektsteuerung und die daraus resultierenden Aufgaben mit bewährten Methoden anzugehen. Das diesbezügliche Know-how der Teammitglieder erleichtert die Aufgabenkoordination und deren zeitliche Steuerung. Methodische Kompetenz der einzelnen Teammitglieder beeinflusst ebenfalls positiv die Teamarbeit.

Wie bereits in der Einleitung dieses Abschnitts erwähnt, besteht unsere Gesellschaft, im Gegenteil zum japanischen Kulturkreis, überwiegend aus Individualisten und Einzelkämpfern. Die grundsätzliche Bereitschaft eines Menschen, mit anderen gemeinsam an Lösungen zu arbeiten, beeinflusst alle Komponenten der Teamarbeit. Diese Präferenz kann durch Motivation und bereits erlebte positive Erfahrungen unterstützt werden. Sie wirkt sich auf jeden Fall positiv auf die Teamarbeit aus.

Die absolute Teamgröße beeinflusst die Teamarbeit in mehrfacher Hinsicht: mit steigender Anzahl der Mitglieder werden sowohl die Kommunikation als auch die Koordination der Aufgaben komplexer und die Abstimmung der Ergebnisse langwieriger. Bei zu großen Teams wurde beobachtet, dass sich das Engagement des Einzelnen tendenziell verringert (eine böse Definition sagt: TEAM = Toll Ein Anderer Macht‘s). Ein Team sollte also gerade so groß sein, wie es die gegebene Aufgabe erfordert. Eine adäquate Teamgröße wirkt positiv auf die Teamarbeit.

Jedes Teammitglied in innovativen Projekten soll sein Spezialwissen und seine Erfahrung einbringen. Es zeigte sich jedoch, dass große Unterschiede im Wissens- und Fähigkeitsstand der einzelnen Teammitglieder die Zusammenarbeit wesentlich erschweren. Heterogenität im Wissens- und Fähigkeitsstand hat einen signifikant negativen Einfluss auf die Teamarbeit.

Als Faktoren mit weniger signifikanter Beeinflussung für die Teamarbeit wurden eingestuft:

Sie schafft die Voraussetzungen dafür, dass Teammitglieder oft informell und offen miteinander kommunizieren. In der Regel ist es jedoch nicht möglich, das Team wirklich in einem Büroraum (oder physikalisch an einem Ort) arbeiten zu lassen. Auch in einem ausgedehnteren Firmengebäude können die Teammitglieder demnach voneinander bereits räumlich getrennt und voneinander entfernt arbeiten. Im Zuge der zunehmenden Verwendung der elektronischen Kommunikationsmöglichkeiten wird die räumliche Distanz relativiert und durch gezielte Erreichbarkeit der Kommunikationspartner subjektiv bzw. virtuell hergestellt. Räumliche Nähe wird in diesem Fall subjektiv durch „vertraut sein“ und „füreinander verfügbar sein“ kompensiert. Man ist sich nicht wirklich nah, man fühlt sich aber so: Man ist sich virtuell nah.

Räumliche Distanz, die nicht durch das subjektive Empfinden der Nähe kompensiert wird, wirkt auf die Projektarbeit negativ.

Je nach Organisationsform des Projekts, wie bereits in Abschnitt 2.3.3.1 besprochen, muss der einzelne Mitarbeiter sowohl die Projektaufgaben als auch das Tagesgeschäft, das heißt, die Aufgaben aus seiner Linienorganisation wahrnehmen. Dadurch können durchaus wertvolle Synergien entstehen. Auf die Dauer wirkt sich vor allem eine mit Rollenkonflikten behaftete Mehrfachbelastung auf die Teamarbeit negativ aus.

Als für eine erfolgreiche Teamarbeit nicht signifikante Faktoren haben sich herausgestellt:

· Heterogenität bezüglich des Alters, Geschlechts, Dauer der Organisationszugehörigkeit, Ausbildungsgrad und Fachrichtung der Ausbildung.

Wie bereits erwähnt, wurden alle diese Faktoren schwerpunktmäßig für Deutschland bzw. für die westlichen Industrieländer untersucht und bewertet. In anderen Ländern mit anderen Kulturen (beispielsweise Asien, Fernost, arabische Länder) können auch diese Faktoren ihrer Bedeutung nach unterschiedliche Ergebnisse liefern.

1.3.4.2.2 Teamführung

Unter dem Begriff Teamführung werden alle die Faktoren zusammengefasst, die unabhängig von der Teambesetzung die Teamarbeit beeinflussen. Dazu gehören folgende Faktoren mit einem signifikanten Einfluss auf die Teamarbeit:

Zieldefinition als einer der Erfolgsfaktoren im Projekt wurde in der Literatur bereits vielfach diskutiert[xxvii]. Eine klare, überschaubare und regelmäßig überprüfbare Zieldefinition (siehe auch Faktor Feedback) wirkt positiv auf die Teamarbeit. In den IT-Projekten haben sich beispielsweise die Spezifikation und Verfolgung der Teilziele in der Form von Meilensteinen bewährt. Dabei ist wichtig, dass sich jedes Teammitglied den kollektiven Teamzielen persönlich verpflichtet fühlt.

Um den positiven Effekt einer professionellen Zieldefinition voll entfalten zu können, muss die Zielerreichung regelmäßig überprüft und an das Projektteam zeitnah kommuniziert werden. Die Rückmeldungen müssen regelmäßig vorgenommen werden und sich dabei auf die inhaltlichen Aspekte sowie konstruktive Verbesserungsvorschläge konzentrieren und nicht zur Suche nach Schuldigen missbraucht werden.

Das Einbeziehen der einzelnen Mitglieder in den Entscheidungsprozess führt zur höheren Identifikation der Mitglieder mit der Entscheidung. In Abhängigkeit vom Zeitdruck oder von der Aufgabenart ist es oft notwendig, dass auch einzelne Teammitglieder die Kompetenz haben, Entscheidungen alleine zu treffen. Es hat sich gezeigt, dass Gleichberechtigung bezüglich Entscheidungsfindung im Team positive Auswirkung auf die Teamarbeit hat.

Vergleichsweise schwächere Auswirkung auf die Teamarbeit haben folgende Faktoren:

Autonomie des Teams wird als seine Unabhängigkeit von externem Management bzw. seine Freiheit, teamintern Entscheidungen zu treffen, verstanden. Starkes Eingreifen in die Arbeit des Teams seitens der Linienmanager führt zu hierarchischen Strukturen und beeinträchtigt die Teamarbeit. Autonomie des Teams gegenüber dem Linienmanagement wirkt sich positiv auf die Teamarbeit aus.

Ein Team ist autark, wenn es über alle für die Teamarbeit notwendigen Ressourcen verfügen kann. Dazu gehören z. B. finanzielle Ressourcen und die Kompetenz, sie für die Teamarbeitszwecke zu nutzen (wie Reisekosten, Materialeinkauf, Know-how-Einkauf), materielle Ressourcen (wie IuK-Infrastruktur, Projekt-Arbeitsplatzausstattung u. a.). Autarkie hinsichtlich notwendiger Projektressourcen wirkt positiv auf die Teamarbeit.

1.3.4.2.3 Komponenten der Teamarbeit

Teamarbeit wird als Maß der Qualität der Interaktion in einem Team bezüglich folgender Komponenten verstanden:

Kommunikation ist der elementarste Bestandteil der Teamarbeit. Wie häufig, wie offen und wie formell im Team kommuniziert und Information ausgetauscht wird, beeinflusst direkt die Teamleistung. Kommunikation und Informationsaustausch im Projektteam werden, durch eine Vielzahl von Studien bestätigt, als der wesentliche Erfolgsfaktor im Projekt gesehen.

Die besondere Rolle der Kommunikation in virtuellen Teams wird in Abschnitt 2.3.4.3 erläutert.

Ein weiteres wesentliches Element der Teamarbeit ist die kollektive Aufgabenerfüllung; dazu muss die Kooperation bezüglich einzelner Teilaufgaben entsprechen koordiniert werden. Die effektive Aufgabenkoordination ist ebenfalls eine wesentliche Voraussetzung für den Projekterfolg.

Die einzelnen Teammitglieder sollen nicht konkurrieren, sondern kooperieren. Das bedeutet, sie teilen ihre Information, respektieren die Beiträge anderer Teammitglieder und unterstützen einander; diese Einstellung hilft Konflikte zu vermeiden und fördert die Integration des Wissens aller Teammitglieder.

Unter Arbeitsnormen versteht man an dieser Stelle die im Team gemeinsam getragenen Erwartungen bezüglich bestimmter Verhaltensweisen der Teammitglieder. Dazu gehören Aspekte wie Arbeitseinsatz, persönliches Engagement für die Ziele und Priorisierung der Teamaufgaben gegenüber anderen Aufgaben. Um Konflikte im Team zu vermeiden, ist es wichtig, dass diese Normen allen Teammitgliedern bekannt sind und von ihnen akzeptiert werden. Insbesondere der Arbeitseinsatz beeinflusst direkt die Teamleistung.

Unter Team-Zusammenhalt werden der Stellenwert, den die Teammitglieder der Teamaufgabe beimessen, der Stolz, den sie bezüglich ihrer Mitgliedschaft empfinden, und deren Glaube an die Leistungsfähigkeit des Teams verstanden. Dieser Zusammenhalt wird durch persönliche Sympathie der Teammitglieder unterstützt. Der so entstandene Teamgeist hilft auch schwierige Phasen im Projekt gemeinsam zu überstehen und kann nicht nur die Qualität der sozialen Beziehungen im Team sondern auch die Qualität der Ergebnisse beeinflussen.

Als letzte Komponente der Teamarbeit wird die wechselseitige Ausgewogenheit der Beiträge der einzelnen Teammitglieder verstanden. Dies heißt nicht, dass alle „gleich viel arbeiten“ müssen, sondern dass jedes Mitglied seinem Potenzial und seinen Fähigkeiten entsprechend in das Team integriert und an der Problemlösung beteiligt wird.

1.3.4.2.4 Ergebnisse der Teamarbeit

Zu den Ergebnissen der Teamarbeit gehört einmal die tatsächlich erbrachte inhaltliche und fachliche Leistung, das erstellte Produkt, zum anderen ein Zuwachs des Team-Reifegrads und dadurch auch des Potenzials für den Erfolg in künftigen Projekten. Diese Effekte werden in so genannten Lernenden Organisationen besonders beachtet.

Die Leistung eines Teams wird dadurch bestimmt, wie es die Zielvorgaben bezüglich Qualität, Kosten und Zeit erfüllt. Diese drei Vorgaben werden im Projektmanagement auch „das magische Dreieck“ genannt. Der Grad der Zielerreichung und seine Qualität bestimmen die Effektivität der Teamleistung, die Abweichungen von den Zielvorgaben bezüglich Kosten und Zeit seine Effizienz.

Neben der direkten Leistung des Teams sind aus der Sicht eines projektorientierten Unternehmens auch die neu hinzugewonnene Fähigkeit und Motivation der Teammitglieder für die Arbeit in künftigen Projekten von Bedeutung. Wiederholte Frustration kann die Bereitschaft der Mitarbeiter, in künftigen Projekten mitzuarbeiten, negativ beeinflussen. Es ist deshalb wichtig, dass die Teammitglieder während ihrer Teamarbeit auch die Befriedigung persönlicher und sozialer Bedürfnisse wie Kontakt, Sicherheit und Wertschätzung erfahren. Darüber hinaus bietet Teamarbeit die Möglichkeit, aus gemeinsamen Erfahrungen zu lernen und dabei neues Wissen zu generieren. Dies kann sowohl die inhaltlichen Aspekte des Projekts (also Zuwachs an Fachkompetenz) als auch die Zusammenarbeit im Team (also Zuwachs an Sozial- und Methodenkompetenz) betreffen.

Um die Voraussetzungen für eine teamarbeitsorientierte Organisation – ein projektorientiertes Unternehmen – zu schaffen, müssen die Einflussgrößen des erweiterten Modells (siehe Abbildung 17, ebenfalls nach Högl) berücksichtigt werden: Art der Aufgabenstellung, Rolle und Kompetenzen der Manager und letztendlich die Strategie, Struktur und Kultur des Unternehmens. Diese sind Gegenstand künftiger empirischer Untersuchungen.

1.3.4.3 Einfluss- und Erfolgsfaktoren in virtuellen Teams

Wie bereits erwähnt, muss ein virtuelles Team nicht notwendigerweise über die ganze Welt, deren Kulturen und Zeitzonen verteilt sein. Mit zunehmender Globalisierung nimmt jedoch auch die Wahrscheinlichkeit zu, dass dies der Fall ist. Der Vollständigkeit halber nehmen wir also im Folgenden an, dass ein virtuelles Team auch multikulturell ist.

Nach Duarte und Snyder[xxviii] sind die kulturellen Unterschiede für virtuelle Teams die einzigen wahren Grenzen, die die Teamarbeit und deren Ergebnisse sowie deren Einstellung zur Nutzung der IuK-Technologien signifikant beeinflussen. Diese Unterschiede, richtig verstanden und im Team richtig eingesetzt, können andererseits durch ihre Vielfalt wertvolle Synergien und innovative Lösungen entstehen lassen.

· nationale Kultur (Kultur, Sprache, Verhalten, Sitten und Werte des Landes, in dem man lebt),

· organisationale Kultur (in Abschnitt 2.3.2.1 als Unternehmenskultur besprochen) und

· funktionale Kultur (beispielsweise Fachsprache, fachspezifisches Verhalten und Werte in unterschiedlichen funktionellen Gruppen wie Softwareentwicklung, Bauwesen, Maschinenbau u. a.).

Die nationale Kultur prägt den Menschen seit seiner Kindheit und ist am schwersten zu ändern oder gar abzulegen. IBM hatte bereits 1967 eine Untersuchung der nationalen Unterschiede in den einzelnen weltweit verteilten Geschäftsstellen initiiert und die Ergebnisse in so genannten Diversity Programmen in die Personal- und Führungsstrategie des Unternehmens integriert.

Haywood untersuchte die Erfolgsfaktoren virtueller Teams in High-Tech-Projekten und listet diejenigen auf, die mit hoher Korrelation die erfolgreiche Teamarbeit virtueller Teams unterstützen[xxix]:

4. Information wird überwiegend aktiv abgeholt, der Anteil an zugestellter Information ist erheblich kleiner,

Anmerkung: Bei dem Informationsfluss im Team unterscheidet man prinzipiell zwei Möglichkeiten, die Information zu erhalten:

5. Manager und Teammitglieder mit einer über dem Durchschnitt liegenden Fähigkeit zur genauen Einschätzung der Lage,

Die Faktoren 7 bis 10 kann man als allgemeingültig für alle Projekte bzw. alle Projektteams betrachten. Die Faktoren, die die Kommunikation betreffen, wollen wir im nächsten Abschnitt etwas genauer besprechen.

1.3.4.4 Aufbau der Kommunikationskultur in virtuellen Teams

Die Arbeit im Projektteam verläuft fast ausschließlich über Kommunikationsprozesse. Wie im vorherigen Abschnitt erwähnt, gehören Kommunikation und Informationsaustausch schon in „normalen“ Teams zu den wichtigsten Erfolgsfaktoren. In virtuellen Teams, erschwert durch die räumliche Distanz und eventuell unterschiedliche Zeitzonen, gewinnen diese Faktoren zusätzlich an Bedeutung und erfordern weit mehr Aufmerksamkeit und Unterstützung.

Der Informationsaustausch in virtuellen Teams wird durch das Einrichten eines internetbasierten Projekt-Portals mit Wissensmanagement-Eigenschaften unterstützt, wie in den Abschnitten 2.4.3 und 2.5.4 beschrieben.

Kommunikation und gegenseitige Unterstützung in virtuellen Teams sind aufgrund der räumlichen Entfernung nur mit besonders sorgfältig eingeführten Kommunikationskonzepten und deren stringenter Nutzung auf allen verfügbaren IuK-Kanälen möglich.

Empirische Untersuchungen stellten fest, dass etwa 20 % der Managerzeit auf das Schlichten der Konflikte oder deren Konsequenzen im Team verwendet wird. Wie hoch dieser Anteil bei den Projektmanagern in virtuellen Teams ist, ist derzeit nicht bekannt; dass das Schlichten über IuK-Kommunikationskanäle erschwert ist, kann sich jeder, der diese Rolle schon mal in seinem „normalen“ Team übernehmen musste, leicht vorstellen.

Dieser Abschnitt beschäftigt sich schwerpunktmäßig mit dem Konzept der zielorientierten Kommunikation, weit gehend unabhängig vom Kommunikationsmedium, das dafür verwendet wird. Die unterschiedlichen Möglichkeiten der IuK-Medien und Softwarefunktionalität, die die Qualität der Kommunikation zusätzlich beeinflussen, werden in Abschnitt 2.4.2 diskutiert.

Hinsichtlich der Bedeutung der nonverbalen Kommunikation und der verschiedenen Aspekte einer Nachricht aus psychologischer Sicht sei auf die zahlreiche Literatur verwiesen[xxxi]. Schulz von Thun führt die meisten Probleme in der zwischenmenschlichen Kommunikation auf die nicht immer wahrgenommenen vier Seiten einer Nachricht (wie in Abbildung 18 dargestellt) zurück.

Der gleiche verbale Inhalt kann seitens des Senders unterschiedliche Bedeutung haben, auf unterschiedlichen „Kanälen“ gesendet werden:

Der Empfänger kann die Nachricht ebenfalls mit „unterschiedlichen Ohren“ empfangen:

3. Das Beziehungs-Ohr: Wie redet er eigentlich mit mir? Wen glaubt er, vor sich zu haben?

4. Das Appell-Ohr: Was soll ich tun, denken, fühlen aufgrund seiner Mitteilung?

Die typischen Missverständnisse – die oft zu Konflikten führen – von der Art „Ich habe es ihm doch GESAGT!“ entstehen, wenn der Sender auf einem anderen Kanal sendet, als der Empfänger hört, ohne dass beide diese Diskrepanz realisieren. Abhilfe schafft hier aktives Zuhören: überprüfen, ob der Sendekanal dem Empfängerkanal entspricht, durch hinterfragen.

Abbildung 18: Ein psychologisches Modell der zwischenmenschlichen Kommunikation nach Schulz von Thun

Die meisten psychologischen Modelle berücksichtigen dabei noch nicht die Faktoren „fremde Sprache“ und „fremde Kultur“. Eine Rückmeldung über die angekommene Nachricht, bei Menschen wie in der Nachrichtentechnik, hilft auf jeden Fall eventuelle Konflikte aufgrund von missinterpretierten Nachrichteninhalten zu vermeiden.

Bei der Beschreibung der IuK-unterstützten Kommunikation wird oft der Unterschied zwischen synchroner und asynchroner Kommunikation gemacht: Als synchron wird die Kommunikation bezeichnet, bei der die Teilnehmer zu einer Zeit kommunizieren (wie Telefongespräch, Videokonferenz oder Chat), als asynchron, wenn die Kommunikation zeitlich unabhängig verläuft (wie typischerweise E-Mail). Für eine zielorientierte Qualität der Kommunikation in einem verteilt arbeitenden Team ist es bei jeder Art der Kommunikation wichtig zu wissen:

Bei einem persönlichen Gespräch kann sich der Sender eventuell einige der Antworten auf die oben gestellten Fragen aufgrund der Körpersprache des Empfängers selbst geben (wenn dieser abwinkt, oder beispielsweise fragend die Augenbrauen hochzieht). Bei einer synchronen Kommunikation per Telefon oder Chat kann der Empfänger den Empfang und das Verständnis der Nachricht noch hinterfragen. Bei asynchroner Kommunikation ist er hilflos.

Existieren im Team keine gemeinsam aufgestellten und abgestimmten Verfahren, die den Kommunikationsprozess „Senden/Empfangen/Bestätigen“ regeln, sind Aggression, Frust und Konflikte vorprogrammiert. In der Projekt-Set-Up-Phase sollten deshalb mit dem Team Kommunikationsregeln für alle Arten der verwendeten Kommunikation aufgestellt und abgestimmt werden. Nur wenn diese Regeln von allen im Team akzeptiert und aktiv verwendet werden, entfaltet der Erfolgsfaktor Kommunikation sein positives Potenzial.

Der Aufbau einer Kommunikationskultur im Team erfolgt in mehreren Ebenen und Schritten. Zunächst sollten für jede Kommunikationsart Verhaltensregeln definiert werden:

1. Regeln für persönliche Kommunikation: aktives Zuhören, konstruktive Kritik, Sensibilität für fremde Sprachen und Kulturen.

Es hat sich beispielsweise bewährt, in einem Projektteam, dessen Muttersprache nicht die Projektsprache ist (das ist in internationalen Projekten mit US-Englisch als Projektsprache für die meisten Europäer der Fall), die Mitteilung des Senders von dem Empfänger immer zur Bestätigung in eigenen Worten kurz zusammenfassen zu lassen. Eingeführt und geübt als Teamnorm führte diese Regel zwar zu etwas längeren Besprechungszeiten, mittelfristig hilft sie jedoch etliche Missverständnisse aufgrund von Missinterpretation der Fremdsprache zu vermeiden. Dieses Verhalten ist natürlich auch für Projektleute mit gleicher Muttersprache hilfreich und besonders dann sinnvoll, wenn sie aus verschiedenen Fachbereichen kommen.

Wer hatte noch nicht solche oder ähnliche Nachricht auf der Handy-Mailbox empfangen: „Hallo, Frau Müller, leider habe ich Sie nicht erreicht, aber ich versuche es später wieder!“

Der Informationsgehalt dieser Nachricht lässt zu wünschen übrig, weil er niemanden weiterbringt: Weder den Empfänger, da dieser nicht erfährt, was der Zweck des Anrufs war und daher auch weder seine Wichtigkeit einschätzen noch Vorbereitungen treffen kann, noch den Sender, da sein Versuch „später“ genauso erfolglos ausfallen kann.

„Hallo, Frau Müller, ich möchte Sie über ein Gespräch mit dem Auftraggeber informieren. Er hatte einige Fragen zum Budget, für die ich Ihre Hilfe brauche. Ich bin heute ab 14:00 Uhr erreichbar, bitte rufen Sie mich an oder lassen Sie mich per E-Mail wissen, wann und wo ich Sie spätestens bis Donnerstag erreichen kann.“

Bei Nutzung von synchronen Kommunikationsmedien wie Telefon, Chat, Videoanruf oder Videokonferenz ist es notwendig zu wissen, wann meine Kommunikationspartner prinzipiell verfügbar sind und wie reagiere ich, wenn ich sie mal nicht erreiche. Dafür werden folgende Regeln vereinbart:

Publikation der Information über persönliche Verfügbarkeit jedes Teammitglieds in einem für alle Teammitglieder zugängigen Bereich (in so genannten Personal Web Pages, Gruppenkalendern und Urlaubslisten),

Vereinbarung der Struktur einer Nachricht, der Mindestinformation und des Vorgehens, falls der Kommunikationspartner nicht erreicht wurde, im Sinne einer bilateralen Kommunikation (wie Zweck des Anrufs, Zeit, Medium und Vereinbarungen für die Wiederaufnahme der Kommunikation),

Wenn ich meinen Gesprächspartner telefonisch nicht erreiche, hinterlasse ich ihm auf der Sprach-Mailbox den Zweck und die Priorität des Anrufs, meine Verfügbarkeit und einen Vorschlag für die Wiederaufnahme der Kommunikation. Oder: Ich hinterlasse ihm nur die Uhrzeit, wann ich angerufen habe, und dass er seinen Posteingang überprüfen soll und schreibe ihm alle weiteren Kommunikationsparameter per E-Mail.

Wenn ein Gesprächspartner zur vereinbarten Zeit nicht pünktlich anruft, warte ich 15 Minuten und muss dann nicht mehr verfügbar sein. Oder: Ich versuche ihn selbst anzurufen. Oder: In diesem Fall überprüfe ich meinen Posteingang nach weiteren Instruktionen.

Vereinbarung des prinzipiellen Vorgehens für die Gruppenkommunikation, wenn einer oder mehrere der Kommunikationspartner an dem Kommunikationsvorgang nicht teilnehmen können, (wie Zeit, Medium und Vereinbarungen für die Wiederaufnahme der Kommunikation).

Wenn eine Videokonferenz nicht stattfinden kann, wird sie immer auf den nächsten Tag, gleiche Uhrzeit, verschoben. Oder: Anstelle der Videokonferenz wird eine Telefonkonferenz durchgeführt; in diesem Fall werden aber die Unterlagen allen Teilnehmern vom Projektbüro parallel dazu per E-Mail zugeschickt. Oder: In diesem Fall müssen sich alle Teilnehmer die Unterlagen vom Projekt-Internet holen.

3. Regeln für die Nutzung der asynchronen Kommunikationsmedien mit „Senden/Empfangen (push)“-Eigenschaft:

Vereinbarung von Prioritätenstufen und Reaktionsmustern für eine Antwort auf eine asynchrone Nachricht für jedes Medium (wie E-Mail, Fax).

Die meisten E-Mail-Clients enthalten eine Funktionalität für die Verfolgung der E-Mail: zugestellt/vom Empfänger geöffnet; eine Nachricht darüber wird dann dem Sender automatisch rückgemeldet. Ob der Empfänger die Nachricht auch wirklich gelesen und verstanden hat und bereits bearbeitet, kann der Client derzeit natürlich nicht zurückmelden. Jede E-Mail sollte deshalb (am besten in der Betreff-Zeile) in einer vereinbarten Kurzform die Angaben über den Projektnamen, die Priorität der E-Mail und den Handlungsbedarf bezüglich dieser E-Mail enthalten. Dazu vereinbart man beispielsweise folgende Verhaltensregel:

Wenn ein Teammitglied eine E-Mail mit Priorität „hoch“ und Handlungsbedarf „Erledigen“ erhält, bestätigt er am gleichen Tag, ob er den Inhalt verstanden hat, und er teilt dem Absender einen voraussichtlichen Fertigstellungs-/Erledigungstermin mit.

Die meisten E-Mail-Clients enthalten eine Filterfunktionalität, mit der der Empfänger eine so gekennzeichnete E-Mail aus der Vielzahl der eingegangenen E-Mails der Priorität und dem Handlungsbedarf nach – also zielorientiert – herausfiltern kann.

4. Regeln für die Nutzung der asynchronen Kommunikationsmedien mit „Information bereitstellen/Information abholen (pull)“-Eigenschaft.

Jedes Teammitglied schaut mindestens einmal täglich in das Projekt-Intranet nach den Projekt-News. Oder: jeweils montags.

Oder: Wenn neue Informationen in das Projekt-Intranet eingestellt werden, erhält jedes Teammitglied eine Benachrichtigung hierüber (je nach verfügbarer Funktionalität automatisch oder manuell durch den Ersteller oder durch das Projektbüro).

· genügend Zeit zur Einführung und zum Üben dieser Regeln eingeplant wird (an dieser Stelle sind auch Mentoring und Coaching durch erfahrene „Kommunikatoren“ hilfreich),

· diese Regeln schriftlich dokumentiert und für alle jederzeit verfügbar gehalten werden (sinnvollerweise im Projekt-Intranet).

Als nächster Schritt – sozusagen als Basis für IuK-unterstützte Kommunikation – sollten Standards bezüglich der verwendeten Medien, Anwendungen und deren Funktionalität festgelegt, dokumentiert und geschult werden wie z. B.:

· Formate oder Anwendungen für den Austausch und das gemeinsame Bearbeiten von Dokumenten und Grafiken,

· Verwendete Funktionalität für E-Mail-Clients (nicht alle E-Mail-Clients sind beispielsweise in der Lage, mit MS-Outlook formatierte Zeichensätze und -Farben zu verarbeiten; dann sollte man auf diese Funktionalität im Team gänzlich verzichten),

· Nutzung und Pflege von Wörterbüchern und Glossaren im internationalen Team.

Als letzter Schritt gilt es, einen kontinuierlichen Verbesserungsprozess für die Teamkommunikation einzuführen: eine fortlaufende Unterstützung und regelmäßige Überprüfung der Qualität aller Kommunikationsprozesse im Team, Auswertung der Erfahrungen und Berücksichtigung neuer Anforderungen.

Bei projektorientierten Unternehmen sorgt bereits das Unternehmen durch längerfristige Konzepte zur Mitarbeiterentwicklung und -förderung für die personellen Voraussetzungen einer Kommunikationskultur im Team:

· fortlaufende Aus- und Weiterbildung der Mitarbeiter zu Themen wie Aktives Zuhören, Effektive Präsentation, Rhetorik, Fremdsprachen, Persönliches Zeitmanagement u. a.,

· Qualifizierung der Mitarbeiter im Projektmanagement, insbesondere in der Nutzung der Methoden und Instrumente,

· Sensibilisierung der Mitarbeiter in Bezug auf die Berücksichtigung und das Respektieren anderer Kulturen (sowohl nationaler als auch funktionaler),

· Bereitstellung der organisatorischen und technologischen Infrastruktur (Projektbüro, Projekt-Intranetplattform).

1.4 Software für Projektteams

Dieser Abschnitt beschäftigt sich mit der Software-Unterstützung für Projektteams. Er zeigt, wie sich die Anforderungen mit der Entwicklung der IuK-Technologien geändert haben, welche Funktionalität vor allem ein Projektteam braucht, das räumlich verteilt arbeitet und welche Alternativen zu einer Lösung führen.

Im Folgenden werden wir die Begriffe Projektmanagementsoftware und Software für das Projektmanagement verwenden und wie folgt unterscheiden:

· Als Projektmanagementsoftware wird die spezielle Anwendung verstanden, die die Planung und Steuerung der Projekte bezüglich Termine, Kosten und Ressourcen unterstützt (als Vertreter dieser Gattung seien z. B. die Anwendung Microsoft Project genannt). Hierbei wird als Anwender eine Einzelperson betrachtet.

· Als Software für Projektmanagement werden alle Software-Anwendungen verstanden, die im Rahmen der unterschiedlichen Projektprozesse die Projektarbeit im Allgemeinen unterstützen (als Vertreter dieser Gruppe können heute integrierte Projektplattformen genannt werden, wie sie auch später im Text besprochen werden). Hierbei wird als Anwender das ganze Projektteam betrachtet.

Im letzten Abschnitt schauen wir uns an Beispielen an, wie es einige „Große“ machen.

1.4.1 Wandel der Anforderungen

Die Zeiten, als Projektplanungssoftware auf Zentralrechnern endlose Tabellen mit Netzplanterminen berechnete, sind längst vorbei. Die Anforderungen an die Computerunterstützung für Projektmanagement-Aufgaben haben sich verständlicherweise mit der Entwicklung der IT- und Kommunikationstechnologie der letzten Jahre stark geändert. Diese Entwicklung erhält mit dem Siegeszug des Internet in die kommerzielle Anwendung einen weiteren gewaltigen Schub.

Bis ungefähr Ende der achtziger Jahre wurde die Software-Unterstützung für das Projektmanagement grundsätzlich als eine Anwendung für einzelne Personen konzipiert. Erst mit den Möglichkeiten der Vernetzung der neuen IuK-Technologien gingen die Hersteller dazu über, die Software-Unterstützung für das Projektmanagement als eine Gruppenanwendung zu betrachten.

Einige innovative Vordenker haben bereits zu Zeiten der Hochkonjunktur der individuellen netzplanbasierten Projektplanungssoftware, als das Faxgerät noch zu den progressiven Kommunikationsgeräten zählte, die künftigen Trends erkannt: Dworatschek und Hayek haben 1987 in ihrem damals sehr populären Marktspiegel für Projektmanagementsoftware die Forderung nach folgenden fünf Typen von Software für die Projektarbeit aufgestellt:

· Projektplanungs- und Steuerungssoftware, die es ermöglicht, die Projekte strukturiert zu planen, die Termine, Kosten und den Ressourceneinsatz zu verfolgen und den aktuellen Projektstand jeweils für das Berichtswesen darzustellen,

· Spezifische funktionale Software für andere Projektmanagement-Bereiche und Prozesse wie Risikoanalyse, Konfigurationsmanagement, Controlling u. a.,

· Arbeitsplatz-Software, wie Textverarbeitung, Tabellenkalkulation, Präsentationsgrafik, Datenbank u. a. und schließlich

· Teachware (Computer Based Training, CBT), um einen gemeinsamen Wissensstand im Projektteam zu gewährleisten.

Diese Forderungen sind mit kleinen Modifikationen auch heute noch aktuell. Dabei wird als Zielanwender nicht mehr der einzelne Projektmitarbeiter, sondern das ganze Projektteam adressiert:

· Anstelle der in den achtziger Jahren verfügbaren Kommunikationsmöglichkeiten mit Fax, BTX und DFÜ dient heute als Basis für die Projektkommunikation eine internetbasierte Informations- und Kommunikationsplattform,

· zusätzlich zu der Teachware kommen die E-Learning-Anwendungen und Knowledge Management-Datenbanken hinzu,

· die Funktionalität aller Anwendungen verfügt über gemeinsame Schnittstellen und ist in die Internet-Plattform integrierbar,

Abbildung 19: Fünf Typen von Software für die Projektarbeit (nach [Dworatschek+ 1987b])

Im Folgenden wollen wir diese Software-Pyramide von oben nach unten „abarbeiten“. Die einzelnen Anwendungen und Funktionen sind dabei in unterschiedlicher Ausprägung und in unterschiedlichen Teilmengen auf unterschiedlichen IT-Plattformen vorzufinden. Wir gehen hier davon aus, dass alle diese Anwendungen entweder eine Schnittstelle zum Internet haben, in das Internet integrierbar sind oder gar ganz auf einem Internetserver ablaufen. Sie alle zusammen bilden letztendlich die Projekt-Informations- und Kommunikationsplattform und sind als Bestandteil eines virtuellen Project Management Office (VPMO) zu verstehen. Eine Vorstellung für einen konkreten Einsatz einiger Anwendungen über ein solches VPMO liefert das Beispiel eines fiktiven Projektleiters in einer Muster AG in Kapitel 5.

Der Einsatz von CBT und E-Learning/E-Conferencing-Anwendungen im Rahmen eines Projekts adressiert folgende zwei Ziele:

Wie in Abschnitt 2.3.4 bereits besprochen, wirken sich große Unterschiede im Wissensstand der Teammitglieder negativ auf die Teamarbeit aus. Diese Anwendungen – sinnvoll eingesetzt – können helfen, eventuelle Unterschiede einzelner Teammitglieder bezüglich Wissen und Methodik auszugleichen und dadurch wesentlich zum Projekterfolg beitragen.

Darüber hinaus enthalten die meisten E-Learning-Anwendungen auch so genannte E-Conferencing -Funktionalität. Diese kann sehr effektiv für eine moderierte Durchführung von Projektbesprechungen in virtuellen Teams eingesetzt werden.

Mehr über die Entwicklung und Problematik des Themenbereichs E-Learning ist in Anhang D zu finden.

Knowledge Management ist als Unternehmenskonzept zu verstehen. Für dessen Realisierung werden in der Regel internetbasierte Kommunikations- und Informationsplattformen eingesetzt, wie sie beispielsweise im Anhang E beschrieben sind. Wie einige große Unternehmen das Thema angehen zeigt auch Abschnitt 2.4.5.

Als Arbeitsplatz-Software hat sich in der NT/Windows-Umgebung als ein De-facto-Standard die MS-Office-Software etabliert. Für UNIX-Plattformen gibt es derzeit noch keinen solchen De-facto- Standard. Recht weit verbreitet ist Applix-Office von Applix-Ware. In jüngster Zeit macht die Sun Initiative „Open Office“ auf sich aufmerksam: Nach der Übernahme von Star Office plant Sun diese Office-Anwendung plattformübergreifend als Open Source der UNIX-Anwenderwelt zur Verfügung zu stellen. Über Open Source-Konzepte und -Anwendungen steht mehr in Anhang B: Freie Software.

Die Funktionalität der Arbeitsplatz-Software wird nicht weiter besprochen. Die spezielle funktionale Software an dieser Stelle besprechen zu wollen, würde den gegebenen Rahmen sprengen. Der Leser sei auf die diesbezüglichen Informationen der Hersteller im Internet und auf den Fachmessen[xxxii] verwiesen.

Die letzten zwei funktionellen Ebenen der vorgestellten Software-Pyramide sind in den nächsten Abschnitten näher erläutert.

1.4.2 Projektmanagementsoftware

Die Anforderungen an die Projektplanungs- und Steuerungs-Software sind auch nicht bei der alten Netzplantechnik geblieben. Heute kann man davon ausgehen, dass die meiste Projektmanagementsoftware die so genannte „klassische“ Funktionalität mehr oder weniger zufrieden stellend erfüllt. Diese Funktionalität ist noch überwiegend für eine Anwendung an einem Arbeitsplatzrechner vorgesehen; die meisten Anwendungen enthalten aber bereits Kommunikationsschnittstellen für die Arbeit in verteilten Teams. Einige wenige Projektmanagement-Anwendungen haben bereits begonnen, die ganze Funktionalität als Internet-Anwendung anzubieten (z. B. Applix oder WebProject).

Zur „klassischen“ Projektmanagement-Funktionalität gehören folgende Funktionen:

Zusätzlich zu dieser klassischen Funktionalität kommen neue Forderungen für die Arbeit in verteilten Teams hinzu:

Die Funktionalität von Projektmanagementsoftware wurde für einige der bekanntesten Projektmanagement-Pakete im Rahmen einer Diplomarbeit im Herbst 2000 untersucht. Die Ergebnisse sind im Anhang C aufgelistet.

1.4.3 Projekt-Informations- und -kommunikationsplattform

Die einzelnen für die Projektkommunikation benötigten Anwendungen und Funktionen sind in unterschiedlicher Ausprägung und in unterschiedlichen Teilmengen auf unterschiedlichen IT-Plattformen vorzufinden. Im Folgenden gehen wir wieder davon aus, dass alle diese Anwendungen entweder eine Schnittstelle zum Internet haben, in das Internet integrierbar sind oder vollständig auf einem Internetserver ablaufen. Internetbasierte Plattformen für Kooperation im Projektteam werden Projekt-Portale genannt.

Um die Anforderungen an die elektronische Unterstützung der Projektkommunikation seitens der Anwender abgrenzen zu können, versuchen wir zunächst die Kommunikationsprozesse im Projekt darzustellen.

Angenommen, das Projektteam arbeitet in der klassischen Teamarbeit, alle mehr oder weniger regelmäßig zur gleichen Zeit am gleichen Ort. Die Kommunikation findet zum größten Teil in Abstimmungsmeetings und in persönlichen Gesprächen am Kaffeeautomaten statt. Welche Funktionalität braucht dann ein solches Team außer der Projektplanungs- und Arbeitsplatzsoftware? Die gute, alte Ablage. Die hatte früher der Projektleiter in dicken Projektordnern, heute hat er sie auf dem gemeinsam zugänglichen Serververzeichnis des Projektrechners, in dem oft genug nur er alleine den Überblick hat. Findet man etwas nicht, sind immer genug hilfreiche Kollegen zur Stelle: „Hey, wo hast du eben das Protokoll von der letzten Woche abgelegt?“ Die neuesten Informationen, die aktuellen Terminlisten und Telefonnummern findet man auf der Projekt-Pinnwand.

Angenommen, das Projektteam arbeitet nicht zur gleichen Zeit am gleichen Ort: Es ist räumlich und eventuell auch über die Zeitzonen hinweg verteilt, also ein virtuelles Projektteam. Welche IuK-Technologie und -Funktionalität braucht es dann? Welche steht ihm zur Verfügung? Diese Frage beantworten teilweise bereits die CSCW/Groupware-Konzepte, wie in Abschnitt 1.2.2 erwähnt. Wir wollen uns dennoch diese Funktionalität nachfolgend etwas detaillierter anschauen:

Die Abstimmung der Projektplanung, der Termine und Aufgaben kann asynchron erfolgen. Eine Voraussetzung ist, dass alle Teammitglieder die elektronischen Dokumente in gleicher Weise lesen und bearbeiten können; also eine gemeinsame Anwendungsplattform haben. Das bedeutet nicht nur den gemeinsamen Zugriff auf die Projektdokumente, sondern auch die Fähigkeit, mit allen verwendeten Dokumentformaten arbeiten zu können. Beim Organisationsszenario 1 könnte es möglicherweise eine standardisierte Konfiguration mit einem gemeinsamen Zugriff auf einen zentralen Datenserver sein. Eine solche Lösung findet man beispielsweise in Unternehmen mit einem Exchange-Server in Form von gemeinsamen, öffentlichen Outlook-Ordnern. Oder z. B. in einer Lotus Notes-basierten Plattform. Beide Lösungen können die Datenbanken auf verteilte Server replizieren und so an jedem Standort einen schnellen und kostengünstigen Zugriff ermöglichen.

Bei allen anderen Szenarios ist es meist günstiger, zu einer Internet-Lösung zu greifen, wie sie z. B. in Kapitel 5 für die Muster AG beschrieben ist. Die Projektablage und die Projektnachrichten sind über ein Projekt-Portal erreichbar; der Zugriff wird je nach Teilprojektteam bzw. je nach Projektzielgruppe konfiguriert.

Wenn im Projekt keine gemeinsame Anwendungsplattform verabschiedet wurde, kann es beispielsweise zu folgenden Situationen kommen: Angenommen die Projektteam-Mitglieder stammen aus zwei Unternehmen, die unterschiedliche Standardplattformen verwenden (MS-Office und Lotus).

Es ist Freitag nachmittag. Kollegin A muss für den Projektausschuss einen wichtigen Bericht vorbereiten und hat nicht alle Informationen auf dem aktuellen Stand. Kein Problem: Per E-Mail bittet sie Teamkollegen B um Hilfe. Dieser antwortet auch in wenigen Stunden: „Liebe Kollegin, die verschobenen Termine sind rot hervorgehoben. Die Präsentationsfolie mit der Agenda finden Sie in der Anlage. Ich wünsche Ihnen ein schönes Wochenende.“ Die Kollegin A hält diesen Wunsch für reinen Hohn. Warum? Während der Konvertierung des E-Mail-Textes unter den verschiedenen E-Mail-Clients (MS-Outlook und Lotus) sind jegliche Farbformate, in diesem Fall auch der Informationsgehalt der Nachricht, verloren gegangen. Die Anlage war in einem nur für Lotus-Anwender lesbaren Format (Freelance), für Kollegin A nicht lesbar. Das Wochenende für A ist gelaufen.

Es ist nicht nur wichtig, Information abzulegen, sondern sie auch bei Bedarf schnell finden zu können. Dies wird mit der Recherche-Funktion abgedeckt.

Wenn mehr als zwei Autoren an einem technischen Dokument (Konzept, Systembeschreibung u. a.) arbeiten, besteht die Gefahr, dass sie sich gegenseitig das Dokument „kaputtschreiben“. Die MS-Office-Software enthält bereits eine Sperr-Funktionalität für Bearbeitung von Dokumenten in Gruppen. Die Gruppenmitglieder können jedoch alle parallel mit einer Kopie des Dokuments arbeiten und müssen demnach diese Arbeit gut koordinieren. In verteilten Teams wird die gemeinsame Dokumenterstellung auf zwei Anwendungsebenen vorgenommen:

- am Arbeitsplatz werden die Dokumente erstellt und bearbeitet, dies wird in der Regel mit der Arbeitsplatz-Software vorgenommen;

- an einem zentralen Speicherplatz werden die Dokumente vorgehalten und verwaltet, das heißt: für weitere Bearbeitung versioniert freigegeben. Dafür bietet der Markt zahlreiche Dokumentenmanagement-Systeme an. Die Dokumentenmanagement-Funktionalität ist ebenfalls ein Bestandteil aller E-Cooperation-Anwendungen.

Auch ein verteiltes Projektteam braucht synchrone Abstimmungsmeetings. Für diese Meetings müssen sich die Teammitglieder also zu einer Zeit zusammenfinden. Diese Funktionalität könnte man versuchen, mit Telefonkonferenzen abzudecken. Das Einrichten einer Mehrteilnehmer-Telefonkonferenz gehört inzwischen zur Standardfunktionalität jeder größeren Telefonanlage. Es ist jedoch extrem schwer und unübersichtlich, vor allem in einem mehrsprachigen internationalen Team, mittels Telefonkonferenz Projektergebnisse und -unterlagen abzustimmen.

Man könnte Abstimmungsmeetings auch per Videokonferenzen durchführen. In den meisten Managementetagen internationaler Unternehmen sind bereits seit Jahren Fernseher-Videokonferenzanlagen installiert. Leider ist es dabei ziemlich schwer, auf benötigte Projekt- und Präsentationsunterlagen einzugehen.

Für Videobesprechungen im Projektteam ist die so genannte E-Learning- oder E-Conferencing- Software besser geeignet. Sie ermöglicht eine elektronische Konferenz mit dem Team in einem virtuellen Raum bei gleichzeitiger Einsicht in die benötigten Unterlagen. Ist es möglich, die Unterlagen während der elektronisch unterstützen Besprechung auch von jedem Arbeitsplatz aus gemeinsam zu bearbeiten, spricht man von Document Sharing. Können diese Dokumente auf den Arbeitsplätzen der einzelnen Teilnehmer darüber hinaus auch bearbeitet werden, obwohl die dafür benötigte Anwendungssoftware nicht lokal installiert ist, spricht man über Application Sharing. Für solche elektronische Video-Konferenzen in großen Teams muss für die Kommunikation eine genügend große Bandbreite verfügbar sein, ansonsten ist es empfehlenswert, sich lieber in der Live-Video-Funktion und Application Sharing etwas einzuschränken. (Die technischen Details über Bandbreiten und Anschlussmöglichkeiten sind in Anhang A beschrieben.)

Für Zweier-Konferenzen kann man bei NT/Windows-Arbeitsplätzen Videobild sowie Document Sharing gleichzeitig schon mit einem ISDN-Anschluss und der kostenlosen Anwendung Microsoft NetMeeting[xxxiii] vornehmen.

- einmal, um gemeinsame Termine zu finden und abzustimmen (um z. B. eine Videokonferenz durchzuführen),

- zum anderen, um die persönliche Verfügbarkeit der einzelnen Teammitglieder anzuzeigen.

Mit der Funktion eines Gruppen-Kalenders ist es möglich, besetzte Termine der Teammitglieder nachzuhalten und gemeinsame freie Termine zu finden. Eine solche Scheduling -Funktionalität ist beispielsweise in den MS-Exchange- oder Lotus Notes/Domino-Servern enthalten. Es ist nicht einfach, diese Funktionalität auf einer gemischten Plattform zu realisieren. Virtuelle Teams mit gemischten Plattformen müssen einen internetbasierten Gruppenkalender verwenden.

Die meistverbreitete Anwendung für informelle Kommunikation ist das Mobilfunk- oder ISDN-Telefon mit integrierter Mailbox sowie E-Mail.

Die heutigen Mobilfunk- und ISDN-Telefone bieten eine Vielzahl an Funktionen, die die Kommunikation erleichtern und unterstützen: Umleitung, Anrufbeantworter mit Aufzeichnung, Einrichten von Mehrteilnehmergesprächen und Telefonkonferenzen, Speichern von Teilnehmernummern, automatische Wiederwahl u. a.

Zusätzlich zu dieser Basisfunktionalität bieten größere TK-Anlagen eine Voice-Mail -Funktionalität an. Hierbei können die aufgesprochenen Nachrichten ähnlich wie die E-Mail-Nachrichten an mehrere Teilnehmer verteilt oder weitergesendet, mit Kommentar versehen und variabel verwaltet werden. Vor allem für Teammitglieder, die viel im Auto unterwegs sind, bietet Voice-Mail eine willkommene Möglichkeit, mit dem Rest des Teams zu kommunizieren.

Die beliebteste Kommunikationsart für informelle Kommunikation ist wohl die E-Mail-Funktion. Sie ermöglicht, Nachrichten plattformübergreifend und weltweit zu empfangen und an eine beliebige Anzahl von Teilnehmern zu versenden. Es ist jedoch zu beachten, dass nicht alle verwendeten E-Mail-Clients (also die Software, die die E-Mail am Arbeitsplatz aufbereitet) die gleiche Funktionalität haben. Sie können insbesondere unterschiedliche Formatierung bei Texten und Darstellung von Grafiken und Anhängen verwenden. Vor der Nutzung dieser Funktionalität im Team ist der kleinste gemeinsame Nenner abzustimmen, um eine Lesbarkeit aller E-Mails im Team zu gewährleisten. (Protokolle und technische Details zu den E-Mail-Systemen sind in Kapitel 3 und Anhang A erläutert.)

Für Projektteams, die noch über keine gemeinsame Projektarbeitsplattform verfügen, wird E-Mail auch als Trägermedium für die formelle Projektkommunikation verwendet, insbesondere zum Austausch und für die Bereitstellung der Projektdokumente. Dies kann nur als Interims-Lösung akzeptiert werden: Außer, dass sie die Posteingänge aller Teilnehmer verstopft, ist sie mit einem enormen Koordinationsaufwand verbunden.

Eine Mischung aller dieser Kommunikationsdienste bieten die Unified Messaging Services. Hier kann eine digital aufgenommene Information auf mehrere oder alle vorhandene Medien und Dienste in beliebiger Kombination verfügbar gemacht werden. Eine E-Mail kann als Voice-Mail „vorgelesen“ werden, als Fax oder E-Mail weitergesendet oder dessen Eingang per SMS (Small Message Service) dem Empfänger mitgeteilt werden.

Sehr nützliche Anwendungen für informelle Kommunikation sind auch die synchronen und asynchronen Diskussionsforen. In einem Diskussionsforum (Newsgroup) können strukturiert Fragen gestellt und beantwortet sowie Meinungen ausgetauscht werden. Synchrone Diskussion wird Chat genannt. Ein Chat ist meist nicht strukturiert und ähnelt einem Gespräch, das eben nur schriftlich geführt wird. Ein Vorteil ist, dass man nach Ende eines Chat über die schriftliche Form verfügt, diese ist allerdings meist recht unübersichtlich.

Der Begriff „Informelle Kommunikation“ soll nicht bedeuten, dass für diese Art der Kommunikation im Team keine Regeln gelten! Wie wichtig gerade bei der informellen Kommunikation die Abstimmung von Kommunikationsregeln im Team ist, wurde in Abschnitt 2.3.4.4 dargestellt.

Die überaus nützliche Funktion einer physikalischen Projektpinnwand im Projektbüro kann mit Hilfe der in ein internetbasiertes Projekt-Portal (im virtuellen Projektbüro) zentral eingestellten Information realisiert werden. Hierbei ist wieder wichtig, welche Verhaltensregeln bezüglich solcher Information im Team vereinbart werden. Wie im Leben: Wer daran „vorbeikommt“ sieht, was darauf ist? Oder erhält jedes Teammitglied beispielsweise eine E-Mail- oder SMS-Nachricht, wenn ein neuer Beitrag eingestellt wird?

Im Projektteam ist es oft wichtig, insbesondere im Rahmen der Qualitätssicherung der Projektergebnisse, bestimmte Abläufe einzuhalten, beispielsweise bei der technischen Freigabe der Dokumente oder bei der Abstimmung der Projektinformationen die an den Auftraggeber oder Lenkungsausschuss weitergegeben werden. Diese Abstimmung wird in einem „Vor-Ort-Team“ meist organisatorisch vorgenommen. In einem virtuellen Team ist es hilfreich, wenn die gemeinsame Projektplattform eine Workflow-Funktionalität bietet, die diese Abläufe festhält und unterstützt. Dies ist bereits bei den meisten Anbietern von Software für Team-Collaboration der Fall, wie in Anhang E aufgeführt.

1.4.4 Auswahl der Software für Projektteams

Wie geht man vor, um eine optimale Informations- und Kommunikationsplattform für das Projektteam auszuwählen und bereitzustellen, in der alle benötigte Funktionalität integrierbar ist?

Insgesamt gibt es für die Auswahl einer Projekt-Informations- und Kommunikations-Plattform folgende Alternativen:

1. „Best of the Breed Products“ auswählen und integrieren: Hierbei werden für die einzelnen Funktionsbausteine jeweils die auf dem Markt als Top-Klasse geltenden Anwendungen ausgewählt und in eine gemeinsame Plattform integriert. Erfahrungsgemäß ist jedoch hierbei der Integrationsaufwand recht hoch.

2. Basis-Integrationsplattform erwerben und funktionell zu einem Projekt-Portal bzw. Knowledge Center ausbauen: Hierbei wird eine Lösung auf einer vorhandenen Plattform erstellt. Als solche Plattform wird z. B. Lotus Notes/Domino, Microsoft Exchange oder so genannte Collaborative-Umgebungen von verschiedenen Herstellern verstanden (LiveLink von OpenText, iTeam von Documentum, Hyperwave Information Portal und Community Engine von Webfair).

3. „Out-of-the-box“-Lösung erwerben und selbst betreiben: Eine solche Lösung wäre z. B. eine der im vorherigen Abschnitt erwähnten E-Collaboration-Umgebungen, wenn sie nicht weiter angepasst werden muss, oder eine für virtuelle Projektbüros maßgeschneiderte Lösung wie sie auch später in diesem Buch (siehe Kapitel 5) beschrieben wird.

4. Die letzte Möglichkeit ist, eine Lösung für virtuelle Projektbüros für die Dauer eines Projekts von einem ASP zu mieten.

Unternehmen, in denen regelmäßig Projekte stattfinden und projektorientierte Unternehmen, die bereit sind, in eine standardisierte Projektinfrastruktur zu investieren, wie im Organisationsszenario 1 und 2 beschrieben, können langfristige strategische Konzepte realisieren, um eine geeignete Lösung zu finden. Für diese bieten sich Alternative 1 und 2 an.

In Unternehmen, die noch keine einheitliche IT-Plattform haben, oder in Projekten, die schnell eine Lösung brauchen, bieten sich die Alternativen 3 und 4 an.

Die Alternative 4, also die Möglichkeit, eine ASP-Lösung zu mieten, bietet sich vor allem für aus mehreren Unternehmen zusammengesetzte Projektteams wie in Szenario 3 beschrieben an oder als Interimslösung, bis eine eigene Lösung realisiert ist. Vorteil dieser Alternative ist, dass der ASP auch Unterstützung und Administration anbietet. Nachteil könnte – in Abhängigkeit von der Qualität und dem Sicherheitsbewusstsein des ASP-Anbieters – die ungenügende Sicherheit der empfindlichen Projektdaten sein. Das Thema Sicherheit wird in den Kapiteln 3 und 4 besprochen.

1.4.5 Wie machen es die großen Unternehmen?

Wie bereits in Abschnitt 2.3.3 erwähnt, gehört die Bereitstellung einer geeigneten Projektplattform für ihre Mitarbeiter bei projektorientierten Unternehmen zu den strategischen Entscheidungen. Bei den meisten internationalen Unternehmen werden konzernweit Regeln und Standards für die IT-Nutzung festgelegt. Den Mitarbeitern stehen vor allem internetbasierte Wissensdatenbanken und kollaborative Lösungen zur Verfügung. E-Mail gehört heute genauso zu den Standardinstrumenten wie ein Telefonanschluss. Alles gut geschützt durch Firewalls und konzernweite Zutrittsregelungen. Was geschieht aber, wenn ein Projekt mit externen Partnern und Subunternehmern gestartet wird? Die meisten Intranet-Lösungen sind für Firmenfremde nicht vorgesehen. Wir wollten wissen, wie die Bereiche in Unternehmen wie Siemens, Hewlett-Packard oder IBM, deren Kerngeschäft es ist, Projekte durchzuführen, dieses Thema angehen. Dazu haben wir im Dezember 2000 bzw. im Januar 2001 telefonische Interviews mit den entsprechenden Projektverantwortlichen der erwähnten Unternehmen durchgeführt[xxxiv]. Wir haben folgendes erfahren:

Bei Siemens wurde 1999 auf Veranlassung des CIO (Chief Information Officer) ein Projekt mit dem Thema „Service for virtual Teams“ zur Evaluierung von IuK-Möglichkeiten für Project Communities durchgeführt. Das Kernteam hat nach Auswertung der möglichen Alternativen – von „Best-of-the-breed“ bis zu „Out-of-the-box-services“ – zwei unterschiedliche Lösungen empfohlen.

Für Projekte im Bereich Siemens Business Services wird als Plattform LiveLink von OpenText eingesetzt. Mit dieser Plattform sammelten die Betreiber bereits seit einem Jahr Erfahrungen mit Knowledge Management -Lösungen.

· Versionsverwaltung der abgelegten Dokumente (mit Releases = Einfrieren und Sperren von Versionen),

· Workflows (dort definierte zugeordnete Arbeitspakete – Tasks werden automatisch in die Tasklist des betreffenden Benutzers eingetragen),

· Change Agents: Der Benutzer kann sich automatisch auch per Mail über bestimmte Events informieren lassen. Dabei kann der Benutzer aus einer großen Anzahl von Ereignissen auswählen (beispielsweise „neue Tasks in der persönlichen Taskliste“),

· Generierung von Standard-Reports (z. B.: „Was ist seit gestern in diesem Projekt passiert?“ oder „Welche neuen Tasks habe ich in meiner Taskliste?“),

· LL Desktop, die Möglichkeit, direkt aus den MS-Office-Produkten (Word, Excel, Powerpoint, Outlook und Explorer) auf die Dateien zuzugreifen und automatisch Check-In/Check-Out und Versionierung durchzuführen und

· LiveLink Explorer (nur bei Verwendung von Internet Explorer als Browser): Dieser bietet eine Windows Explorer-ähnliche Oberfläche auf die Projektstruktur (Ablage) mit ihren Ordnern und Dokumenten mit Drag&Drop-Funktionalität zum Windows Explorer.

Die Ablagestrukturen und die Vorlagendokumente werden nach der Siemens-Projektmethodik CHESTRA zur Verfügung gestellt. E-Conferencing mit Application Sharing steht derzeit nicht zur Verfügung.

Zum Administrieren dieser Funktionalität steht dem Projektleiter derzeit kein Projektbüro zur Verfügung; ihm wird empfohlen, einen Team-Mitarbeiter, meist Projektassistenz, als Knowledge Broker für das Projekt auszubilden. Nach Einschätzung der Siemens-Verantwortlichen ist dies in einer eintägigen Schulung zu bewerkstelligen. Die ersten Erfahrungen bestätigten dabei: „Technologie ist nur der ‚enabler‘, ohne Treiber im Projekt funktioniert es nicht.“ Was mit den Projektdaten nach dem Projektende geschieht, entscheidet der Projektleiter. Sie können gelöscht, archiviert oder für Offline-Benutzung konserviert werden.

Diesen virtuellen Projektraum bietet Siemens nicht nur für eigene Projekte an, sondern auch als ASP -Lösung für interessierte Kunden (siehe Abbildung 20).

Der Siemens-Bereich ATD (Anwendungen, Technische Dienste) entschied sich für Lotus QuickPlace mit nahezu gleicher Funktionalität wie oben beschrieben (Beispiel von QuickPlace ist in Anhang E). Diese Lösung bietet ATD quasi als interner Application Service Provider allen internen Interessenten seit Oktober 2000 unter dem Namen „Teamsphere“ an. Die Administration ist nach Aussage der ATD-Verantwortlichen so einfach, dass ein zusätzlicher Administrationsservice als Project Office-Funktionalität nicht angeboten werden muss. Aufgrund der relativ kurzen Zeit seit der Inbetriebnahme der Teamsphere bis zur Fertigstellung des vorliegenden Textes konnten über die Erfahrungen und Akzeptanz der Lösung durch die Anwender noch keine Aussagen gemacht werden.

Im Unternehmen Hewlett-Packard wird seit Mitte 1998 für interne Projekte eine Lösung für die kollaborative Projektarbeit, „E-Room“, verwendet. Die Teilnahme externer Projektmitglieder ist hier nicht vorgesehen. Der Unternehmensbereich Hewlett-Packard Consulting (HPC), dessen Kerngeschäft es ist, Kundenprojekte durchzuführen, brauchte verständlicherweise eine Lösung, an der auch alle externen Projektpartner teilnehmen können. Diese Lösung ging HPC im Rahmen des konzernweiten Konzepts für Knowledge Management & Organizational Learning (KMOL) an.

· wiederverwendbares Material auch wiederzuverwenden (d. h., die Neuerfindung des Rads in jedem Projekt zu minimieren)[xxxv].

Als Plattform für die KMOL-Lösung wählte HP 1998 nach einer Evaluations- und Pilotierungsphase ebenfalls LiveLink von OpenText. Diese Lösung wird derzeit nach einer Pilotierungsphase im Verlauf des Jahrs 2000 als „K-Net“ unternehmensweit eingeführt. Die Lösung für kollaborative Projektarbeit virtueller Projektteams, „Client-Project-Workspace“, ist eine Untermenge von K-Net, erlaubt jedoch durch unterschiedliche Infrastruktur und Zugangskonzepte auch die Beteiligung aller, also auch externer Projektpartner. Im Client-Project-Workspace werden ebenfalls die Standarddokumente und Vorlagen des HP-Projektvorgehensmodells FocusPM integriert. Derzeit werden auch die Rolle und Aufgaben der Organisationseinheit „Project Office“ neu überdacht. Für Client-Project-Workspace ist im Verlauf des Jahrs 2001 eine konzernweite Einführung geplant.

Die interne strategische Lösung für eine generelle konzernweite Kommunikationsplattform von IBM ist seit der Übernahmen von Lotus Corporation verständlicherweise Lotus Notes/Domino. In den virtuellen „Team-Rooms“ stehen den Projektmitarbeitern standardisierte Vorlagen und Steuerdokumente nach dem IBM-Projektmanagement Modell WWPMM (World Wide PM-Method), Ablagestrukturen (Folders) und Tools zur Verfügung. Alle Mitarbeiter verwenden als Arbeitsinstrument standardmäßig vorkonfigurierte Laptops, mit denen sie sich über unterschiedliche Kanäle: LAN oder Telefoneinwahl in ihren Team-Room einwählen können. Einen Team-Room kann der Projektleiter über den zuständigen regionalen Koordinator beantragen.

Videoconferencing ist in Planung; derzeit können verteilt arbeitende Teams Konferenzen nur über Telefon abhalten. Für die Archivierung der Projektdaten nach dem Projektende ist der Projektleiter verantwortlich. Die Erfahrungswerte, technischen Lösungen und Ergebnisse aus dem Projekt werden im Rahmen des Intellectual Capital Management (ICM) für die nächsten Projekte bereitgestellt.

Diese Funktionalität wird für alle Projekte bereitgestellt; für mittlere und große Projekte steht dem Projektteam ein Project Office als Dienstleister zur Unterstützung und Administration zur Verfügung. Für Großprojekte ist die Nutzung eines Project Office sogar vorgegeben.

Die weltweit einheitliche Strategie erlaubt länderspezifische Eigenheiten und Tools und öffnet die Anwendung mit entsprechenden Zugriffsrechten auch für externe Projektpartner und Kunden. Bei Projekten, in deren Teams externe Partner oder Kunden mitarbeiten, können alle Vorlagen und Projektsteuerungsdokumente auf eine gemeinsame Plattform (z. B. MS-Office-Formate) angepasst werden. Bei Bedarf und Interesse können externe Partner und Kunden auch an einer Schulung über das IBM-Projektvorgehensmodel WWPMM teilnehmen.

Die Akzeptanz dieser Lösung unter den Projektmitarbeitern ist nach Aussage der IBM-Verantwortlichen sehr gut, denn für die Lösung wurden vorher die Anforderungen der künftigen Anwender abgefragt und berücksichtigt.

1.5 Wiederaufleben des Projektbüros

Projektbüros gab es bereits in den Pionierzeiten des Projektmanagements, als die meisten Pläne noch manuell gezeichnet und die Texte per Schreibmaschine geschrieben wurden. Damals war es hauptsächlich eine Art Projektschreibbüro oder -sekretariat. Die ersten Hinweise auf ein mehr technisch und funktionell ausgerichtetes Projektbüro gab es 1987 in den durch die GPM publizierten Periodika und 1994 im Handbuch für Projektmanagement von Madauss.

Bis heute existiert keine einheitlich gültige Definition über die Aufgaben eines „Projektbüros“. Die überaus uneinheitliche Verwendung des Begriffs erschwert diese Definition zusätzlich. Für die mehr oder weniger gleiche Institution werden beispielsweise folgende Namen verwendet:

Virtual Project Management Office (VPMO) bei Anbietern von internetbasierter Projektbüro-Funktionalität.

1.5.1 Rolle und Aufgaben

Was ist nun eigentlich ein wie auch immer benanntes Projektbüro und welche Aufgaben soll es wahrnehmen? Heute versteht man unter einem Projektbüro nach der Definition von Block und Frame[xxxvi] einen Anbieter von Komplett-Service im Bereich Projektmanagement, vertreten durch professionell ausgebildete Spezialisten. Ein solches Projektbüro als Dienstleister wird in der Regel von mehreren Projekten oder sogar unternehmensweit genutzt und deckt mindestens folgende Aufgabenbereiche ab:

bei administrativen Aufgaben und der Projektinfrastruktur: Controlling, Abrechnung, Administration und Pflege der IT-Plattform, Räumlichkeiten;

beim Einsatz von Tools und Methoden: Administration der elektronischen Projektablage, Aktualisierung und Pflege des Projekthandbuchs;

bei Projektmanagement-Aufgaben: Erstellung und Pflege der Zeitpläne, Erstellung und Verteilung der Projektberichte;

Project Visibility Room ist dabei das physikalische Büro oder ein virtueller Raum, in dem alle Interessierten (Auftraggeber, Kunden, Projektpartner, andere Stakeholder) die Projektinformationen (wie Projektpläne, Projektablage, Bildmaterial, Dokumentation u. a.) einsehen können.

Bereitstellung von Spezialwissen, Erfahrung und Expertise für interessierte Projektleiter und Projektmitglieder;

Bereitstellung von ausgebildeten Telecoaches und Moderatoren für moderiertes E-Learning und E-Conferencing.

Entwicklung von unternehmensweit gültigen Methoden und Standards sowie deren Bereitstellung für Projektteams.

Ressourcenpool an „ausleihbaren“, professionell ausgebildeten Projektmanagern.

Ein Projektbüro kann dabei in folgenden Schritten modular aufgebaut und eingeführt werden:

· über die Zentrale für Projektmanagement-Unterstützung und projektmanagementorientierte Dienstleistungen für alle Projekte,

· zur Stabsstelle für Qualitätssicherung der Projektprozesse und Multiprojecting bis zum

· Center of Competence/Center of Excellence für unternehmensweites Management by Projects.

1.5.2 Beispiele aus der Praxis

Über Projektbüros findet man erstaunlich wenig Literatur und Publikationen[xxxvii]. Die meisten Firmen betrachten alle Angaben über die Organisation ihrer Projektbüros als vertrauliches intellektuelles Kapital und publizieren darüber keine detailliertere Information. Ein sehr guter Informationsaustausch findet dennoch auf den Expertentagungen der Projektmanagement-Vereinigungen (PMI und GPM bzw. IPMA) statt. GPM veranstaltete beispielsweise im September 2000 erstmalig eine Expertentagung mit dem Fokus Project Office, bei der 18 verschiedene Vortragende 18 unterschiedliche Projektbüro-Konzepte und -Schwerpunkte vorstellten. Einige Beispiele für die Auslegung des Konzepts Projektbüro bei einigen bekannten Unternehmen sind nachfolgend aufgeführt.

Anlässlich der zweiten europäischen PMI-Konferenz 1998 in München berichtete IDG, eine Tochter von IBM Deutschland, über die Ziele und die Vorgehensweise bei der Einführung eines zentralen Projektbüros . Die Einführung wurde schrittweise und modular über den Zeitraum von mehreren Jahren (ab 1994) vorgenommen. Die daraus gewonnenen Erfahrungen und die offensichtlichen Erfolge veranlassten IBM Deutschland, ab 1999 die Einführung eines Projektbüros als Institution für alle Outsourcing-Projekte in Deutschland zur Pflicht zu machen.

UNISYS etablierte bereits 1996 ein zentrales Projektbüro , Practice Management Office (PMO), mit europäischer Zentrale und Zweigstellen in weiteren europäischen Ländern. Dieses PMO unterstützt alle Geschäftsstellen des Bereichs Information Systems bei projektbezogenen Aktivitäten: Bei der Angebotserstellung, durch Bereitstellung von Methoden, durch Standardisierung und durch das UNISYS-Projekt-Vorgehensmodell TEMmethod bis hin zur Zertifizierung der Projektmanager. Nach Aussagen von UNISYS-Projektmanagern gehören seit der Einführung des PMO „rote“ Projekte zu den Ausnahmen.

Bei den Hewlett-Packard Divisions ist ein Projektbüro seit etwa acht Jahren ein fester Bestandteil der Organisation. Als Integration Center ist es vor allem auf die kundenspezifische Integration und Installation von HP-Produkten auf paneuropäischer und globaler Ebene fokussiert: Seit 1996 wird auch für die Consulting-Bereiche im HP-Vorgehensmodell für Projektmanagement die Einführung eines Projektbüros bedarfsorientiert für große und komplexe Projekte empfohlen.

Lufthansa Systems führte ein Project Office zunächst Ende der neunziger Jahre für ein großes Projekt zur weltweiten Modernisierung der IT-Infrastruktur für Fluggäste, mit einer Laufzeit von fünf Jahren, als zentrale Verwaltungsstelle für die Projektinformation ein[xxxviii]. Das Projektbüro war zunächst schwerpunktmäßig für die Erstellung und Pflege des elektronischen Projekthandbuchs zuständig; dieses genoss im Projektteam keine große Akzeptanz. Die Projektleitung änderte die Ausrichtung des Projektbüros auf den Schwerpunkt Service-Einheit für Business Support mit folgenden Aufgaben:

· Process Owner und Ansprechpartner für alle Beteiligte, Dokumentation, Monitoring, proaktives Eskalieren, Abrechnung der Supportleistungen;

· Pflege und Bereitstellung des Produktkatalogs: Datenbasis aller Produkte und Releases mit technischen Produktdaten und Preislisten;

· Master-Milestone-Monitoring: Aggregation des Projektplans zu einem Masterplan, Abstimmung zwischen allen Beteiligten, Terminverfolgung und -pflege, Statusberichte;

· Sicherstellung, Pflege und Abrechnung der Projekt-Infrastruktur (IT sowie Räume);

· Ausbau der PM-Skills, Unterstützung bei der Personalbeschaffung und Stellenverfolgung;

Nach Ende des Projekts gehen die Funktionen des Project Office zum Teil in den Betrieb über (Change Management).

Die ARAG-Gruppe etablierte ihr Projektbüro ebenfalls Ende der neunziger Jahre unter dem Begriff Programme-Office als strategisches Controlling und Dienstleister bei allen Projekt- und Multiprojektmanagement-Themen in der Unternehmensgruppe mit folgenden Aufgaben:

· Erstellen von Berichten, Vorlagen, Präsentationen, Analysen zum Multiprojektmanagement u. a.;

Die ARAG Gruppe übertrug dem Programm-Office die volle Verantwortung für eine funktionierende Projekt- und Multiprojektumgebung.

Die Dresdner Bank zählt zu den Aufgaben ihres Projektbüros zusätzlich noch folgende Funktionen:

· Ressourcenmanagement (intern und extern): Planung und Verwaltung von Mitarbeiterkapazitäten und Profilen, Weiterentwicklung und Weiterbildung, Unterstützung bei Personalrekrutierung;

· Vertragswesen: Verwaltung und Disponierung von Verträgen, Kontakt und Schnittstelle zu Beschaffung, Initiierung der Folgeaufträge;

1.5.3 Organisatorische Einbettung

Abbildung 21 erläutert die mögliche organisatorische Einbettung des Projektbüros in die Unternehmens- oder Projektorganisation in Abhängigkeit von den in Abschnitt 2.3.3 vorgestellten Szenarios.

In einem Unternehmen (Szenario 1), das wiederholt intern Projekte durchführt, sollte das Projektbüro als eine Stabsabteilung direkt unter der Geschäftsleitung positioniert sein.

In einem projektorientierten Unternehmen (Szenario 2) werden Mitarbeiter und Dienstleistungen eines zentral etablierten Projektbüros nach Bedarf in die laufenden Projekte „ausgeliehen“.

Bei einem Team, das aus Mitarbeitern verschiedener Subunternehmen zusammengesetzt ist (Szenario 3), ist das Projektbüro als Stabsabteilung der Projektleitung der zentrale Träger der gemeinsam aufzubauenden Projektkultur . Ohne ein gut funktionierendes Projektbüro ist die Durchführung von Projekten unter diesem Szenario nur mit Qualitätseinbußen möglich.

1.5.4 VPMO – Virtual Project Management Office

Ein reelles Projektbüro ist eine Organisationseinheit, die dem Projekt bestimmte Dienstleistungen und Know-how bereitstellt. Unter einem virtuellen Projektbüro wird eine internetbasierte Anwendung verstanden (ein Projekt-Portal), die einem Projektteam als Informations- und Kommunikationsplattform dient und somit einige Funktionen des reellen Projektbüros IuK-mäßig realisiert bzw. unterstützt.

Bei verteilt arbeitenden Projektteams ist es auf jeden Fall sinnvoll und notwendig, ein virtuelles Projektbüro einzurichten. Die Aufgabe eines Project Visibility Rooms übernimmt hierbei das Projekt-Portal im Internet. Die Anwendung Virtuelles Projektbüro wird von den Mitarbeitern der Organisationseinheit Projektbüro administriert.

Virtuelle Projektbüros leiden heute noch ebenso am Mangel an einheitlicher Namensgebung und einheitlichem Verständnis über deren Funktionsumfang und Daseinsberechtigung wie vor einigen Jahren ihre „reellen“ Kollegen. Sie werden genannt: Team-Room, Project place, Virtueller Projektraum, virtual Project Management Office – vPMO, u. Ä. und bieten ein unterschiedliches Spektrum an Funktionalität und Unterstützung für die Arbeit eines virtuellen Projektteams.

Zu einem virtuellen Projektbüro kann man ebenso gelangen wie zu jeder anderen Softwareanwendung: von einer „Best-of-the-Breed“- bis zu einer „Out-of-the-Box“- oder ASP-Lösung, wie in Abschnitt 2.4.4 beschrieben.

Als Basis für eine „Best-of-the-Breed“-Lösung stehen die internetbasierten Plattformen für kooperative Teamarbeit zur Auswahl, beispielsweise LiveLink, Lotus QuickPlace , Documentum iTeam, Hyperwave, Webfair u. a.. Die Hersteller dieser Plattformen haben allerdings die Zielgruppe Virtuelle Projektteams noch nicht als solche erkannt: die Lizenzpolitik, die die Softwarepreise bestimmt, ist in der Regel voll auf eine typische unternehmensinterne Nutzung ausgerichtet, bei der es einige wenige Autoren und eine Vielzahl von dauerangestellten Mitarbeitern als Konsumenten der Information gibt. Die Dynamik eines Projektteams von seiner Entstehung bis zu seiner Auflösung wird in den meisten Fällen weder durch die Preispolitik noch durch die Funktionalität abgedeckt.

Einige Application Service Provider haben dagegen den Markt bzw. die Zielgruppe Virtuelle Projektteams bereits erkannt und versuchen, für diese fertige Lösungen bereitzustellen. Einige dieser Lösungen und entsprechende Links werden im Anhang E vorgestellt.

[i] Die Geschichte des Projektmanagements und den organisationalen Wandel erläutert Hannelore Dittberner im Rahmen ihrer Dissertation in [Dittberner 1998].

[ii] Dr. Hasso Reschke ist Professor an der Fachhochschule München.

[iii] Die Projektmanagement-Organisationen und -Standards werden detaillierter z. B. in [Bartsch-B. 2000], Seite 13 ff. erläutert. Über sich selbst publizieren die einzelnen Organisationen umfangreiche Information unter deren Web-Links (siehe Literatur und Quellenverzeichnis im Anhang).

[iv] Saynisch spricht in [Saynisch 1997] über Projektmanagement der zweiten Ordnung.

[v] Die Ergebnisse der ersten Studie über die Trends im Projektmanagement des Instituts für Projektmanagement und Wirtschaftsinformatik (IPMI) der Universität Bremen wurden in Dworatschek, Sebastian; Gutsch, Roland: Wandel der Themenschwerpunkte der internationalen Konferenzen von INTERNET und PMI (USA), in: GPM-Nachrichten Nr. 13, September 1987, Seite 23-33 veröffentlicht.

[vi] Tina Nehlsen stellte im Rahmen einer Studie am Institut für Projektmanagement und Wirtschaftsinformatik (IPMI) der Universität Bremen die Thesen über den Wandel der Themenschwerpunkte im Projektmanagement auf. Die Ergebnisse der Studie wurden als Diplomarbeit 12/1999 am IPMI veröffentlicht.

[vii] Der „deutsche projektmanagement award“ wurde detailliert in [Bartsch-B. 2000], Seite 129 ff., beschrieben. Die Anmeldungsunterlagen können über die GPM bezogen werden: www.gpm-ipma.de. Erläuterung eines TQM Modells ist z. B. bei der EFQM, European Foundation for Quality Management, zu finden unter: www.efqm.org oder bei deren deutscher Sektion, unter: www.deutsche-efqm.de.

[viii] Eine vollständige Auflistung der Preisträger und Finalisten des „deutschen projektmanagement awards“ ist auf den Web-Seiten der GPM unter www.gpm-ipma.de zu finden.

[ix] Über Projektitis spricht auch Schelle in [Schelle 1999]; er empfiehlt zur Abgrenzung von Projekten und Nicht-Projekten, also Daueraufgaben ohne Projektcharakter, firmenindividuelle Kriterien zu entwickeln.

[x] Die Merkmale von projektorientierten Unternehmen sind detaillierter z. B. von Gareis in [Schelle+ 1994], Kapitel 1.4, Seite 4 oder von Patzak und Rattay in [Patzak+ 1998] beschrieben.

[xi] Management by Projects als zentrale Managementstrategie eines projektorientierten Unternehmens, um neue Chancen und Herausforderungen einer dynamischen Unternehmensumwelt wahrnehmen zu können, beschreibt Dworatschek in [Dworatschek 1998].

[xii] Die Vielfalt der Klassifizierung der Projekte in den PM-Publikationen wurde von der Verfasserin bereits in [Bartsch-B. 2000] aufgeführt.

[xiii] In seinem Buch „In Search of Excellence in Project Management“ [Kerzner 1998] erläutert Kerzner den Weg und die strategischen Merkmale.

[xiv] In seinem Buch „Schlanke Führungsorganisationen“ [Müller 1996], Seite 22 ff., erläutert Müller den Zusammenhang zwischen Unternehmenskultur und Führungskultur.

[xv] Im Rahmen einer Studie der Unternehmensberatung Watson Wyatt, bei der weltweit 2.300 Führungskräfte befragt wurden, wurden Unterschiede im Führungsstil untersucht. Info: www.watsonwyatt.com

[xvi] Funktionale Kultur definieren Duarte/Snyder in [Duarte+ 1999] als Summe von Eigenschaften, Fähigkeiten und Verhalten, die durch Zugehörigkeit zu einem bestimmten Fachbereich bedingt sind.

[xvii] Die Erfolgsfaktoren in Projekten untersuchte Lechler anhand einer Auswertung von Ergebnissen von etwa 5.700 Projekten aus 44 bekannten empirischen Studien. Das Thema ist detailliert in [Lechler 1997] erläutert; eine zusammenfassende Darstellung findet der Leser in [Lechler 1998]. Die Konsequenzen für den Einsatz im Projekt werden auch in [Bartsch-B. 2000], Seite 79 ff., besprochen.

[xviii] Zum Thema „kulturelle Unterschiede“ gibt es in der Zwischenzeit zahlreiche Publikationen. Die folgenden können z. B. als hilfreich und gut zu lesen empfohlen werden:

· Understanding cultural differences [Hall+ 1990]; dieses Buch wurde für amerikanische Geschäftsleute geschrieben, um ihnen zu helfen, die deutsche und französische Mentalität zu verstehen. Es regt manchmal zum Schmunzeln, meist zum Nachdenken an.

· „Do’s and Taboos around the World“ [Axtell 1993]; ein Ausflug in fremde Kulturen und Sitten rund um den Erdball. Am Ende weiß der amerikanische Leser, warum er z. B. einigen Europäerinnen keine rote Rosen schenken soll und der Europäer weiß, dass der Amerikaner es normalerweise nicht weiß.

[xix] Die Basis-Szenarios zur Eingliederung des Projekts in Unternehmen wurden bereits in [Bartsch-B. 2000] im Hinblick auf die Voraussetzungen für Qualitätsmanagement in Projekten diskutiert.

[xx] Diskussion der drei „klassischen“ Projektorganisationsformen für Projekte in Unternehmen findet der Leser beispielsweise in [Littke 1995] oder im Projektmanagement-Fachmann [Chrobok 1998].

[xxi] Roland Gareis beschreibt in seinem Beitrag über „Management by Projects“ in [Schelle 1994], Kapitel 1.4, Seite 4, die Merkmale eines projektorientierten Unternehmens.

[xxii] Patzak und Rattay widmen in ihrem Leitfaden [Patzak 1998] dem Thema „Das projektorientierte Unternehmen “ ein ganzes Kapitel.

[xxiii] Die international standardisierten Forderungen an die Kompetenzen eines Projektmanagers sind in der IPMA Competence Baseline (ICB) [IPMA 1999] festgehalten.

[xxiv] Eine Beschreibung der Inhalte des Zertifizierungsverfahrens ist z. B. auf den Web-Seiten von GPM: www.gpm-ipma.de und PMI: www.pmi.org zu finden. Eine vergleichende Zusammenfassung wurde von der Verfasserin bereits in [Bartsch-B. 2000] vorgenommen.

[xxv] „Ein häufiger Grund für unstrukturiertes, ineffektives Arbeiten im Team: eine unzureichende Moderation.“ Dies sagt der Klappentext einer Publikation über Moderationstechniken. (Malorny, Ch.; Langner, M. A.: Moderationstechniken. Werkzeuge für die Teamarbeit, Carl Hanser Verlag)

[xxvi] Einflussgrößen und Wirkungen auf die Teamarbeit in innovativen Projekten erläutert Högl im Rahmen seiner Dissertation in [Högl 1998].

[xxvii] Erfolgsfaktoren in Projekten wurden beispielsweise von Lechler in [Lechler 1998] untersucht und u. a. in [Bartsch-B. 2000] diskutiert.

[xxviii] Duarte und Snyder publizierten eine „how to“-Anleitung für den Umgang mit virtuellen Teams in [Duarte+ 1999].

[xxix] Haywood gibt praktische Tipps für High-Tech-Projektmanager mit virtuellen Teams in [Haywood 1998].

[xxx] Für die Messung der Team-Performance verwendet Haywood [Haywood 1998] ein an CMM (Capability Maturity Model) angelehntes Modell: Maturity Model for Distributed Teams. CMM, bzw. People CMM sind vom Software Engineering Institute (SEI) entwickelte Modelle zur Messung und Verbesserung der Qualität von Software und Software-Entwicklungsteams.

[xxxi] Die Bedeutung der nonverbalen Kommunikation und der verschiedenen Aspekte einer Nachricht aus psychologischer Sicht erläutert Friedemann Schulz von Thun in seinen Publikationen. Eine Zusammenfassung seiner zwei Werke „Miteinander reden1 und 2“ ist in [Schulz von Thun 1999] erschienen.

[xxxii] Die wohl berühmteste Fachmesse für Software und IT ist die CeBIT, die jährlich im Frühjahr in Hannover stattfindet. Ebenfalls interessant ist die Systems, die ebenfalls jährlich im Herbst in München stattfindet. Außerdem finden fortlaufend zahlreiche kleinere fach- und funktionsorientierte Messen statt, deren Inhalte und Termine der Fachpresse oder dem Internet zu entnehmen sind.

[xxxiii] Die aktuelle Version von NetMeeting ist als freies Download auf den Microsoft-Seiten enthalten: www.microsoft.com.

[xxxiv] Die telefonischen Interviews über Realisierung von Kooperationsplattformen für Projektteams, für die wir uns an dieser Stelle nochmals herzlich bedanken, haben wir mit folgenden Verantwortlichen geführt:

Siemens Business Services: Herr Winfried Grundner und Herr Günther Etlinger,

Siemens Anwendungen, technische Dienste: Frau Dr. Ulrike Stutschka,

Hewlett-Packard Consulting: Herr Marcus Funke,

IBM Global Services: Herr N. Marschall.

[xxxv] Den Ansatz und das Vorgehen einiger Unternehmen, darunter auch Hewlett-Packard Consulting, bezüglich Knowledge Management & Organizational Learning, wurden in [Linkage 2000] publiziert.

[xxxvi] Mit dem Thema Project Office beschäftigen sich ausführlich Block und Frame in [Block+ 1998].

[xxxvii] Nach dem Kenntnisstand der Autoren ist zur Zeit der Erstellung dieses Buchs das einzige auf dem Markt verfügbare Buch über Project Office das bereits erwähnte Werk von Block und Frame [Block+ 1998]. Die Autorin hat die Aufgaben und Rollen eines Project Office als Träger des Qualitätsmanagements in IT Projekten in [Bartsch-B. 2000] beschrieben.

[xxxviii] Lufthansa Systems stellte das Konzept des Projektbüros als Service Einheit für Business Support anlässlich einer GPM-Expertentagung im September 2000 vor.

In den 50ern:	Alles ist sehr geheim PM in Wehrtechnik, Luft- und Raumfahrt
In den 60ern:	Knochenharte Projekte Bau und Anlagenbau
In den 70ern:	Innovation ist angesagt Produktentwicklungsprojekte (Automobil, Elektrotechnik)
In den 80ern:	Projektmanagement, das wäre doch was ... Verstärktes Interesse an PM, Software-Entwicklungen
Mitte der 80er:	Projektmanagement, wir haben es schon!“ Anfang einer breiteren und verstärkten Anwendung von PM in allen Bereichen
In den 90ern:	Projektmanagement wird salonfähig Komplexe IT-Projekte, Produktentwicklungen, Organisationsprojekte
Mitte der 90er:	Projektmanagement ist unverzichtbar Weite Verbreitung, Verständnis steigt, Notwendigkeit von PM wird nicht mehr bestritten