Regeln der Eskalation

2 min.

Summary

Eskalationen sind nichts Schlimmes im Projekt oder Programm. Sie sind das Einfordern der spontan notwendigen oder bisher nicht erfolgten Entscheidungen auf definierte Weise – vorausgesetzt eine geregelte Governance ist etabliert.

Regeln

Der Sachverhalt sollte immer von beiden Parteien (Kunde und Auftragnehmer) gemeinsam beschrieben werden und abgestimmt sein.

Inhalte der Eskalation

  • Genaue Beschreibung des Sachverhalts, so dass er von Dritten direkt verstanden werden kann.
  • In welchem Bereich und zu welchem Zeitpunkt ist der Sachverhalt entstanden?
  • Wer hat den Sachverhalt in welchem Reporting-Medium (z.B. wöchentlicher Statusbericht) auf die Tagesordnung gebracht?
  • Was ist getan worden, um das ursprüngliche Risiko bzw. Problem zu verhindern,  es  bei Auftreten zu lösen bzw. es abzumildern?
  • Wer war an der Lösungssuche beteiligt?
  • Wie zeitkritisch ist der Sachverhalt bzw. bis wann wird eine Lösung benötigt?
  • Benennung des Risikogrades und Bewertung der Auswirkung (Impact).
  • Welche Aktivitäten werden zur Lösung vorgeschlagen?
  • Beschreibung des Lösungsansatzes mit Schätzung der Zeitschiene (Timeline), der Ressourcen und der Benennung des Verantwortlichen für die Lösung.

Kommunikation

  • Eskalation immer über E-Mail.  Mails, die nicht alle obigen Sachverhalte beinhalten, sollten zurückgesendet werden.
  • Deutliche Nennung des Wortes “ESKALATION” in der Betreffzeile wie auch in der Mail selbst.

Nähere Informationen zu den Kommunikationsregeln finden Sie auch hier.

Eskalationsstufen

  • Alle möglichen Maßnahmen sollten ergriffen werden, um einen Eskalationssachverhalt auf der niedrigsten Stufe zu lösen. Vor dem Start eines Eskalationsprozesses sollten die Konsequenzen deutlich artikuliert werden.
  • Auf jeder Stufe sollte zwischen beiden Parteien versucht werden, eine Lösung zu finden. Ist diese nicht möglich, sollte – nach vorheriger Abstimmung und unter Berücksichtigung der Anzahl der Eskalationstage – der Eskalationssachverhalt an die jeweilig nächste Eskalationsstufe weitergegeben werden. (Eskalationstage = Verweildauer in Arbeitstagen auf einer Eskalationsstufe)
  • Der Projektmanager ist für die Problemlösung verantwortlich und bleibt es auch bei jeder Eskalationsstufe.
Eskalationspyramide

Internationales Projektportfolio-Management unter Berücksichtigung kultureller Unterschiede

17 min.

Summary

Bei aller Standardisierung ist besondere Rücksicht – vor allem in internationalen – Projektportfolios auf kulturelle Unterschiede bei den Projektbeteiligten zu achten. Die Unterschiede sollten zumindest „abgefangen“, wenn nicht sogar zum Vorteil genutzt werden. Der Aufgabenschwerpunkt eines Projektportfoliomanagers in einem internationalen Projektumfeld verschiebt sich etwas weg von den klassischen Portfoliomanagement-Aufgaben wie z. B. Standardisierung hin zu kultureller Moderation und Katalysation. Katalysation im Sinne von Reinigung von interkulturellen Differenzen und gleichzeitig Beschleunigung des interkulturellen Lernens.

Wenn es in internationalen Projekten Probleme bei der Zusammenarbeit gibt, treten diese meist stärker hervor als bei nationalen Projekten. Dennoch ist ein gut geführtes internationales Projekt mit mehr Erfolg gepriesen als ein rein national besetztes Projekt. Unter Einbeziehung eines „Cultural Agent“ können diese positiven Synergieeffekte gehoben werden.

Dennoch hat nicht jedes Problem internationaler Projekte kulturelle Ursprünge.

Es gibt aber auch interkulturell bedingte Probleme, die nicht als solche gesehen werden.

Kulturelle Unterschiede bei internationalen Projekt-Portfolios

Der vorliegende Beitrag ist ein Auszug meiner vor 10 Jahren verfassten Projektstudienarbeit im Rahmen der Zertifizierung zum Senior Projektmanager (GPM).

Die Fachgruppe „Internationale Projektarbeit“ der GPM hat bereits im Jahr 2002 eine Umfrage bei international erfahrenen deutschen Projektmanagern durchgeführt und folgende wichtigen Problemfelder identifiziert [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 13-14]:

  • Kulturelle Unterschiede
  • Kommunikation / Sprache
  • Rechtlich-politische Aspekte
  • Technologie / Infrastruktur
  • Persönliche Aspekte

Wobei den kuturellen Unterschieden die größte Bedeutung eingeräumt wurde.

Abgrenzung internationaler Unterschiede

In diesem Beitrag soll nicht auf Unterschiede im Bereich Gesetze, Normen, Richtlinien oder Standards des Projektgeschäftes eingegangen werden. Obwohl auch diese durch die kulturellen Gegebenheiten in verschiedenen Ländern geprägt sein können. Hier soll ausschließlich auf die Verschiedenheiten bzw. Auswirkung von Kultur auf das Projekt berücksichtigt werden. Kultur wird definiert als „die Veränderung der Natur durch menschliche Handlungen und Äußerungen und, darauf beruhend, die Gesamtheit der Lebens- und Arbeitsformen einer menschlichen Gruppe (Volk, Klasse, religiöse Gemeinschaft u. a.).“ [Wissen Media Verlag, https://www.wissen.de/lexikon/kultur-allgemein]

Der Kulturbegriff

Keller definiert Kultur anhand verschiedener Eigenschaften [Keller v., E.: Management in fremden Kulturen: Ziele, Ergebnisse und methodische Probleme der kulturvergleichenden Managementforschung, Stuttgart, 1982, S. 114ff]:

  • Kultur ist menschengeschaffen. Sie ist ein Produkt kollektiven gesellschaftlichen Handelns und Denkens einzelner Menschen.
  • Kultur ist überindividuell und ein soziales Phänomen, das den Einzelnen überdauert.
  • Kultur wird erlernt und durch Symbole übermittelt.
  • Kultur ist durch Normen, Regeln, und Verhaltenskodizes verhaltenssteuernd.
  • Kultur strebt nach innerer Konsistenz und Integration.
  • Kultur ist ein Instrument zur Anpassung an die Umwelt.
  • Kultur ist langfristig adaptiv wandlungsfähig.

Hofstede stellt Kultur als ein gruppenspezifisches, kollektives Phänomen von gemeinsam geteilten Werthaltungen dar. [Hofstede, G./Bond, M. H.: The Confucius connection: from cultural roots to econonmic growth, in: Organizational Dynamics, Spring 1988, S. 21]

Die kulturelle Programmierung eines Projektmitarbeiters / Kulturschichten

Wie beeinflusst Kultur den Menschen, und warum kann Hofstede von einer „kollektiven Programmierung des Geistes“ reden?
Ein Mensch wird immer in eine Kultur hineingeboren, und nimmt diese direkt auf. Die „Kultivierung“, bzw. kulturelle Programmierung, findet dabei bereits im Babyalter an – mit 7 Jahren ist dann bereits der größte Teil der Kultur verinnerlicht. [Dahl, Stephan (2000) „Introduction to Intercultural Communication“, aus dem Buch von Stephan Dahl: „Intercultural Skills for Business“, ECE, London, 2000]

Menschen eignen sich in verschiedenen Lebensabschnitten unterschiedliche Kulturschichten an abhängig ihres sozialen Umfeldes: [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 17]

  • Die innerste und damit erste Schicht stammt aus der Kindheit und ist geprägt durch
    • das Land,
    • die soziale Schicht,
    • die ethnische Gruppe,
    • den religiösen Glauben oder auch
    • die Region in der sie aufwachsen.
  • Die zweite Schicht wird gebildet aus der Berufsausbildung. Es zeigt sich oft, dass Personen aus der gleichen Berufsgruppe, aber unterschiedlichen Kulturusprüngen sich besser verstehen, als Personen aus dem gleichen Land aber aus unterschiedlichen Berufsgruppen stammen.
  • Die dritte und letzte Schicht entsteht aus den unternehmensspezifischen Normen und Verhaltensweisen. Dies ist die sogenannte Schicht der Unternehmenskultur.

Da sich der Großteil der Menschen oftmals nur innerhalb einer kulturellen Gruppe bewegen – und eine Auseinandersetzung mit einer anderen Kultur, wenn überhaupt, nur oberflächlich stattfindet – wird die „kulturelle Programmierung“ auch nur selten bewusst. Internationales Projektmanagement ist hier Vorreiter in der Veränderung. Nach meinen eigenen Erfahrungen werden erst nach typischen Projektdauern von mehr als 9 Monate kulturvergleichende Fragestellungen stärker erörtert. Nach circa 3 Monaten im Projektverlauf werden die jeweiligen Vorteile der verschiedenen involvierten Kulturen adaptiert. Nach circa 6 Monaten treten erste „Frustrationserscheinungen“ im Kulturbereich auf. Nach 9 Monaten werden die kulturellen Aspekte stärker betrachtet und auch wirklich berücksichtigt. Das heißt für Projektlaufzeiten von weniger als 9 Monaten kann ein ausgereiftes Kulturverständnis nicht erwartet werden bei den Projektbeteiligten.
Der Projektmitarbeiter/-leiter verhält sich weiter entsprechend seiner kulturellen Abstammung, und interpretiert alle Vorkommnisse entsprechend seiner kulturellen Programmierung. So wird das Verhalten von ausländischen Projektmitarbeitern oftmals als „komisch“ abgetan, da es nicht mit der eigenen kulturellen Programmierung zu erklären ist.
Eine offene Auseinandersetzung mit einer anderen Kultur ist daher unterschwellig problematisch, denn sie kann das eigene Wertesystem erschüttern, und kann das Hinterfragen der Grundwerte herausfordern. Es erscheint daher zumindest verständlich, dass viele Projektbeteiligten diese Konfrontation in vollem Umfang eher vermeiden, und sich in die Vertrautheit der eigenen Kultur zurückziehen.
Unvermeidbar wird diese Konfrontation natürlich für Projektleiter die in einem anderen Land für einen längeren Zeitraum leben. Dabei wird alleine für die Beherrschung der offensichtlichen Rituale und Verhalten rund 12 Monate gebraucht unter der Annahme, dass die lokale Sprache fließend gesprochen wird. [Dahl, Stephan (2000) „Introduction to Intercultural Communication“, aus dem Buch von Stephan Dahl: „Intercultural Skills for Business“, ECE, London, 2000]

Ein anderer Ansatz ohne genauen Ursprung sieht folgende „Kultur-Schockphasen“ vor:

  • Phase 1 bezieht sich auf die Euphorie, die Reisevorbereitung, das Reisefieber und die Neugierde auf das andere Land. Sie hält meist nicht lange an.
  • Phase 2 ist die Zeit des kulturellen Schocks, wenn der Alltag in der neuen Umgebung beginnt.
  • Phase 3 wird Akkulturation, d.h. kulturelle Anpassung genannt, wenn man lernt, unter neuen Bedingungen zu leben, wenn man einige der fremden Werte bereits kennt und in das eigene Verhalten integriert.
  • Phase 4 ist dann die schließlich gewonnene mentale Stabilität, die 3 verschiedene Ausprägungen annehmen kann. Entweder
    • Fremde fühlen sich weiterhin fremd
    • oder in der neuen Umgebung genauso wohl wie zu Hause, kann also in beiden Kulturen leben
    • oder in der Fremde wohler.

Die Länge der Phasen ist variabel und hängt von der Zeitdauer des Aufenthaltes im fremden Land ab.
Umgekehrt werden Fremde von Insidern (Einheimischen) auch in 4 Phasen erlebt:

  1. Neugier heißt, positives Interesse an Fremden.
  2. Ethnozentrismus heißt, Insider beurteilen Gäste/Neue/Fremde anhand eigener Normen. Die eigene kleine Welt wird als Mittelpunkt und Angelpunkt der Welt gesehen. Ethnozentrismus ist auf eine Kultur bezogen dasselbe, wie Egozentrik auf die Person bezogen.
  3. Polyzentrismus heißt, dass verschiedene Menschen mit verschiedenen Maßstäben zu messen sind, sowie die Fähigkeit, Fremde auf dem Hintergrund ihrer eigenen Normen zu verstehen. Eine gemäßigte Form von Multikulturalität.
  4. Xenophilie heißt, dass in der fremden Kultur alles als besser gesehen wird als zu Hause.

Die kulturelle Programmierung einer Kultur

Eine Kultur ist eine Gruppe aus Menschen, welche alle die gleiche oder zumindest sehr ähnliche kulturelle Programmierung haben. Das bedeutet, dass sie sich nahezu alle entsprechend den Normen und Werten der Kultur benehmen, und das Verhalten anderer Menschen an diesen Normen und Werten messen. Dabei soll dies natürlich nicht heißen, dass alle Personen innerhalb einer Kultur total identisch sind – sie verhalten sich nur relativ ähnlich, im Vergleich mit dem Verhalten in einer anderen Kultur, nicht notwendigerweise im Vergleich zur eigenen Kultur.

Modelle kultureller Zusammenhänge

Auf der Suche nach Erklärungsmuster, die das Verständnis logischer Zusammenhänge zwischen Normen und Regeln einer Kultur, wurden verschiedene Modelle entwickelt. „Ein Modell ist eine Vereinfachung der Realität.“ Ein Modell kann nie vollständig sein, da es immer nur eine Vereinfachung ist und nicht alle Aspekte der Wirklichkeit reflektieren kann. Aus diesem Grunde gibt es auch zur interkulturellen Zusammenarbeit verschiedene Modelle, die jeweils unterschiedliche Aspekte darstellen. Für eine Projektsituation ist es daher hilfreich wenn man mehrere Modelle vergleichend zu Rate ziehen kann. [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 32]

Kulturebenen nach Edgar Schein

Schein unterscheidet drei Kulturebenen [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 22]:

  • Die erste Ebene enthält die direkt wahrnehmbaren Merkmale wie z. B. Kleidung, Essen, Musik oder Umgangsformen. Diese sind zwar sichtbar, aber interpretationsbedüftig.
  • Die zweite Ebene besteht aus Werte und Normen, welche Richtlinien für das Verhalten in einer Kultur geben. Diese sind auch Personen der jeweiligen Kultur auch nur teilweise bewusst. Häufig treffen Kulturmitglieder annahmen, dass diese Richtlinien auch in anderen Kulturen identisch sein müssten.
  • Die dritte Ebene beinhaltet Überzeugungen, die als so selbstverständlich gelten, dass diese nicht beachtet werden.

Die Kulturdimension „Kontextbezug“ von Edward Hall

Hall vergleicht Kulturen hinsichtlich der Stärke ihres Kontextbezuges [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 25]. Unter Kontext eine Situation oder Botschaft kann alles aufgefasst werden, was damit in irgendeinem Zusammenhang stehen könnte (z. B. Tonfall und erfahrener oder unerfahrener Kollege) [http://changingminds.org/explanations/culture/hall_culture.htm]. Der Grad des Einflusses des Kontexts auf eine Situation ist kulturbedingt und deshalb für Hall interessant zu definieren. Eine Kultur mit hohem Kontextbezug ist eine Kultur in der der Kontext einen hohe Aufmerksamkeit genießt [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 25].

„Geschenke sind ein Zeichen der Wertschätzung und werden in Kulturen mit starkem Kontextbezug zur Geschäftsanbahnung erwartet.“ [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 65]

Kulturdimensionen nach Hofstede

Um Kultur zu erfassen wurden unterschiedlichste Ansätze geprägt und Studien durchgeführt. Eine der bedeutendsten und inzwischen in die Jahre gekommenen, aber dennoch richtungweisende Studie hält folgende vier wichtigsten Dimensionen fest (siehe Tabelle am Ende des Artikels: Hofstede Studie. Je höher der Wert desto ausgeprägter der Index.): [Hofstede, G.: Intercultural co-operation in organizations, in: Management Decisions, 5-6/1982, S. 53ff; Index und Einordnung: http://www.clearlycultural.com/geert-hofstede-cultural-dimensions/ ;Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 26ff]:

  • Machtdistanz
    Die Machtdistanz drückt aus wie hoch die Akzeptanz ist Machtunterschiede zu akzeptieren.
  • Individualismus versus Kollektivismus
    Hier ist beschrieben ob sich die Individuen als einzeln und unabhängig oder als Mitglieder einer Gruppe/Kultur sehen.
  • Maskulinität versus Feminität
    Maskulinität in einer Kultur wird als leistugsbezogen bzw. erfolgsbezogen und selbstbewusst erkannt. Eine feminine Kultur dagegen achtet stark auf zwischenmenschliche Beziehungen und Kooperation.
  • Unsicherheitsvermeidung
    Bedrohung durch ungewisse oder unbekannte Situationen und deren Vermeidung.

Die weiteren Dimensionen sind beschreibende oder den Ansatz stützende Dimensionen, welche 1987 hinzugefügt wurden:

  • Zeitvorstellungen
    Hier wird definiert wie stark eine Kultur Gegenwarts-, Vergangenheits- bzw. Zukunftsorientiert ist.
  • Raumvorstellungen
    Hier wird festgehalten wie stark sozial distanziert oder introvertiert Mitglieder einer Kultur sich verhalten.
  • Kontextualität
    Herrscht eine direkte oder indirekte Kommunikation. Das heißt wie viel Kontext oder nonverbale Kommunikation ist in der Kultur verankert.
  • Kognitive Prozesse
    Wie sind die gedanklichen Muster, die Art zu denken, zu urteilen und Schlussfolgerungen ausgeprägt in einer Gemeinschaft. Z. B. Analytisch, rational versus synthetisch, intuitiv.
  • Religiöse Vorstellungen
    Je nach religiöser Anschauung neigen die jeweiligen Kulturmitglieder dazu ihr Schicksal als selbst oder fremdkontrolliert anzusehen.

Auswirkungen der Kulturen auf das Projektgeschäft: Im Folgenden sollen die vier ersten Kulturdimensionen verwandt werden um die Unterschiede im internationalen Projektgeschäft festzuhalten.

Machtdistanz

Werden in einem Projekt Mitarbeiter aus verschiedenen Kulturen eingesetzt, welche damit unterschiedlichen Machtdistanzen folgen, müssen verschiedene Aspekte beachtet werden. Meine indischen Kollegen weisen im Vergleich zu skandinavischen oder deutschen Kollegen eine höhere Machtdistanz auf. Das bedeutet, dass ein indischer Kollege stärker Einzelanweisungen erwartet und weniger Entscheidungen ohne Rücksprache mit seinem Projektvorgesetzten treffen möchte um sich in seiner Komfortzone zu befinden. Dies sollte bis hin zu operativen Richtlinien Anwendung finden mit denen sich ein mexikanischer Kollege ebenso wie der indische Kollege „wohler“ fühlt mit sehr detaillierten Vorgaben z. B. bei der Erstellung eines Statusberichtes. Einarbeitungen sind im Vergleich – basierend auf gleicher Projekterfahrung – ausführlicher und systematischer zu gestalten. Ein indischer Kollege fühlt sich in einer stark kooperativ geführten Projektstruktur deplaziert und erwartet klare Strukturen und damit Halt in seinen kulturellen Strukturen.

Individualismus versus Kollektivismus

Diese Dimension beschäftigt sich mit der Prioritätensetzung innerhalb der Gesellschaft auf das Individuum oder auf die Gruppe. In einer individualistisch ausgeprägten Gesellschaft steht das Individuum im Vordergrund. In Projekten mit Mitarbeiter aus verschiedenen Kulturen, welche unterschiedliche Individualismus-Indizes (Grade der Individualität) repräsentieren, sollten Maßnahmen ergriffen werden um das Teambuilding zu unterstützen. Kulturen wie die USA gelten als sehr individualistisch, dass heißt Projektmitarbeiter aus diesem Land sollten besonders intensiv im Teamspirit aufgefangen werden. Asiatische Mitarbeiter benötigen intensives Feedback kontinuierlich im Projektverlauf. Diese sind angewiesen auf das Feedback von vielen Kollegen. Sie werden Feedback von allen Seiten aktiv einfordern. Hier ist anzuraten in ohnehin geplante wöchentliche oder 2-wöchentliche Meetings / Telefonate eine Feedback-Runde einzuplanen. Nordamerikanische Projekte benötigten stärker vom Portfolio gesteuerte Abstimmungsrunden als zum Beispiel asiatische Projekte. Das aufeinander Zugehen und aufeinander Abstimmen in asiatischen Projekten ist kulturell stärker verwurzelt.

Maskulinität versus Feminität

Die Studie Hofstede hatte festgestellt, dass die Unterschiede bei Frauen bei dieser Dimension geringer ausgeprägt sind als bei Männern. Die kulturellen Unterschiede bei Männern sind stärker ausgeprägt in Richtung der Pole versus . Bei meinen skandinavischen Kollegen konnte die Orientierung auf zwischenmenschliche Beziehung und Lebensqualität sehr deutlich festgestellt werden. Leistungsdruck ist in solchen Umgebungen nicht förderlich, sogar eher schädigend. Zielgrößen eines Projektes werden in der Regel dort anders definiert als im Vergleich zu Projekten welche im deutschsprachigen Raum initiiert werden. Dies konnte bei den sensiblen Thema Lokationsauflösungen besonders deutlich festgestellt werden. Themen welche besonders erörtert wurden unterschieden sich bei den Sites in Schweden und der Schweiz sehr deutlich. In der Schweiz lag der Schwerpunkt auf die Effektivität der Schließung (kurze Projektdauer) im Vergleich zu Schweden wo auf eine besonders mitarbeiterorientierte Zeitplanung wert gelegt wurde.

Unsicherheitsvermeidung

Die Unsicherheitsvermeidung, kann als Grad in dem die Mitglieder einer Kultur sich durch ungewisse oder unbekannte Situationen bedroht fühlen. Die Unterschiede sind im Umgang mit diesen Bedrohungen zu erkennen. Gesellschaften mit starkem Hang zur Unsicherheitsvermeidung versuchen durch Regeln, Gesetze, Verhaltensvorschriften und Sicherheitsmaßnahmen die Unsicherheit zu beeinflussen. Entsprechend sollte besonderen Wert gelegt werden auf die Risikoerfassung in Ländern mit geringer Unsicherheitsvermeidung. In „Aufbruchsländern“ wie Singapur, Hongkong und Indonesien sollte im Projektumfeld auf eine ausführliche Identifikation der Risiken Wert gelegt werden. Projektmanager aus diesen Ländern neigen eher dazu Projektrisiken zu übersehen oder zu übergehen. Projektmanager in Ländern mit einer hohen Unsicherheitsvermeidung wie z. B. Portugal identifizieren von sich aus rasch Risiken, haben aber eher Probleme damit die Risikovermeidung auszuarbeiten. Das heißt diese Projektmanager tendieren dazu dieselben Risiken auf den Tisch zu bringen ohne daraus die notwendigen Maßnahmen zu ergreifen. Diese sind stärker „blockiert“ durch die identifizierten Risiken im Vergleich zu anderen kulturellen Kreisen.

Zeitvorstellungen

Im Wesentlichen wurden zwei Zeitvorstellungen in der Studie von Hofstede identifiziert. Die lineare und die zyklische Zeitauffassung. Einfach dargestellt unterliegen Kulturen in Industiegesellschaften eher einer linearer Zeitvorstellung als Kulturen z. B. im asiatischen Raum. Der lineare Ansatz vertritt die Vorstellung, dass was in der Vergangenheit war für immer vorbei ist. Im Gegensatz dazu der Ansatz mit der zyklischen Zeitauffassung unterliegt der Annahme, dass ein ständiger Wechsel zwischen Tag und Nacht, von Monden, von Jahreszeiten und dem Mahlzeitenturnus geprägt ist. Dass heißt dieser Ansatz geht davon aus, dass eine aktuelle Leistungsschwäche in der Zukunft wieder ausgeglichen werden kann. Diese verschiedenen Ansätze konnten in meinem Portfolio tatsächliche festgestellt werden. Zielerreichungsgrade und vor allem Forecasts sind stark geprägt von der kulturellen Zeitvorstellung aus dem Heimatland des Projektmanagers. Meine asiatischen Projektmanager sind stark von dem Ansatz geleitstet, dass die derzeitige Leistungsschwäche des Projektes in naher Zukunft wieder wettgemacht werden kann. Generell zusammengefasst fallen Projektfortschrittsberichte in Kulturen mit zyklischer Zeitauffassung optimistischer aus, als in Kulturen mit linearem Zeitverständnis wie die USA und Zentraleuropa.
Ein weiterer Unterschied im Bereich der Zeitauffassung kann festgestellt werden im sequentiellen oder synchronen Denken. Dass heißt, dass bei der sequentiellen Prägung die Vorstellung vorherrscht, dass Dinge nacheinander gemacht werden sollen. Im Gegensatz zur synchronen Zeitauffassung, bei der der Ansatz zu Grunde liegt, dass mehrere Dinge gleichzeitig erledigt werden können. In meinem Portfolio konnte ich diese Tendenz nicht kultur-, sondern personenspezifisch erkennen. Das heißt, die Unterschiede im Bereich von z. B. Phasenmodellen konnte ich weniger aus der Herkunft, als aus der Persönlichkeit des Projektmanagers herleiten.
Die deutsche Kultur besagt: Jeder kann seine Zeit am effizientesten nutzen, wenn er so wenig wie möglich auf andere warten muss. Die spanische Prägung leitet: Jeder kann seine Zeit am effizientesten nutzen, wenn in einer Besprechung die anstehenden Themen abgeschlossen und keine weitere Besprechung notwendig ist. In Spanien gilt derjenige als unhöflich, wer eine Besprechung abbricht um den nächsten Termin einzuhalten. [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 20]

Kontextualität

Die Unterscheidung hier wird getroffen ob im Kulturkreis viel Kontext im Gesprochenen (z. B. non-verbale Kommunikation; „zwischen den Zeilen lesen“) oder ob mehr die direkte, explizite Kommunikation vorherrscht. Meine europäischen Projektmanager sind wesentlich direkter / „unverblümter“ in ihrer Kommunikation als Kollegen aus dem asiatischen Raum.

Kognitive Prozesse

Im Wesentlichen kann hier zwischen westlichen und östlichen Denkstil differenziert werden. Im Westen herrscht der analytische und im Osten (sehr stark ausgeprägt im asiatischen Bereich) der synthetische Denstil. Im Westen wird zergliedert, im Osten wir das Problem ganzheitlich und verknüpfend erfasst. Rational und systematischer Denkstil im Westen im Vergleich zum intuitiven und ganzheitlichen Denkmuster im Osten.
Die kognitive Orientierung ist auch in der Unterschiedlichkeit bei den Problemlösungsstilen vorzufinden. Einer meiner indischen Kollegen ist stark vom „Umzingelungsgedanken“ geprägt, das heißt, dass das Problem ganzheitlich umzingelt und eingekreist wird. Lösungsfortschritte sind hier langsamer zu erkennen, aber letztendlich kompletter und abschließend. Im Gegensatz dazu bricht ein deutscher Projektmanager das Problem in seine Einzelelmente stärker auf und löst Teilproblem für Teilproblem. Einzelfortschritte sind schneller zu erkennen bedürfen aber eventuell einer nachträglichen ganzheitlichen Korrektur.

Religiöse Vorstellungen

Je nach religiöser Anschauung tendieren verschiedene Kulturen dazu ihr Schicksal als fremd oder selbst gesteuert bzw. kontrolliert zu sehen. Auswirkungen auf religiöse Vorstellungen konnte ich in meinem Portfolio nicht bestätigen, da Kulturkreise mit typisch fremdkontrolliertem Hintergrund trotzdem Projektmanager mit starkem Eigenantrieb hervorbringen. Hier scheinen sich seit Erstellung der Studie Veränderungen eingestellt haben oder ich habe Ausnahmefälle identifiziert.

Die Kulturdimensionen von Fons Trompenaars

Ein weiteres Kulturmodell wurde von Fins Tromenaars und Charles Hamptopn-Turner mit folgenden sieben Dimensionen entwickelt: [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 29ff]

  • Universalismus / Partikularismus
    In universellen Kulturen (z. B. angelsächsische und deutschrachige Läner, Holland und Skandinavien) werden alle Menschen nach den gleichen Regeln und Gesetzen behandelt. In partikularistischen Kulturen dagegen werden Regeln und Gesetze von einer Person respektiert, ausser wenn ein für diese wichtiger Mensch davon benachteiligt würde. Ähnliches gilt auch für geschlossene Verträge: [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 67]. In partikularistischen Kulturen werden fallweise Ausnahmen von Verträgen gemacht. Universalistische Kulturen erlauben dies nicht.
  • Individualismus und Kollektivismus
    Identisch mit Dimension von Hofstede.
  • Gefühlsbetonung
    Hier wird vergleichend gemessen, wie Gefühle wie Freude, Trauer oder Engagement gezeigt wird. Projektmitarbeiter aus dem nahen Osten erheben die Stimme um Ihrem Vorheben Nachdruck zu verleihen. Asiatische Projektmitarbeiter wird eine laute Stimme mit Wut und damit Unkontrolle verbunden.
  • Spezifische / diffuse Kulturen
    Spezifische Kulturen (z. B. angelsächsische Länder, Skandinavien und Holland) definieren Rollen klar und ordnen diesen konkrete Situationen oder Lokalitäten zu. In solchen Kulturen wird die Rolle des Vorgesetzten nicht zwangsläufig in ein anderes (z. B. ins private) Umfeld übertragen.
    In diffusen Kulturen (z. B. arabische Länder und Afrika) bedeutet die Übernahme einer Rolle, dass diese auch bei einem Umfeldwechsel gilt.
  • Leistung versus Herkunft
    In leistungsorientierten Kulturen (z. B. angelsächsische und skandinavische Länder) werden Vorgesetzte respektiert, welche ihre Aufgaben kompetent ausführen und adäquate Fachkompetenz beweisen. In herkunftsorientierten Kulturen (z. B. China und Malaysia) hingegen erhält der Projektleiter seinen Status durch seinen Titel, sein Alter oder seine Familienzugehörigkeit.
  • Das Verhältnis zur Zeit
    In polychronen Kulturen (z. B. Lateinamerika, Afrika, dem mittleren Osten, Frankreich) ist Zeit ein unbegrenztes, simultanes Gut, dass sich dehnen kann. Man plant, kann aber die Planungen leicht anpassen. Mehrere Dinge werden gleichzeitig erledigt. Aus diesem Grunde kann man beobachten wie ein französisches Projektteammitglied eine Besprechung und wichtige Telefonate parallel angeht.
    In monchronen Kulturen (angesächsische, nord- und mitteleuropäische Länder) hingegen gilt Zeit als ein begrenztes Gut, das entsprechend sorgfältig zu planen und einzuhalten ist. Es wird eher sequenziell, das heisst linear gearbeitet.
  • Beziehung zur Natur
    Innengesteuerte Kulturen (z. B. angelsächsische Länder, Nordeuropa) wollen ihre Umgebung und Umwelt unter Kontrolle halten. Dies ist eng verbunden mit dem Glauben sein Schicksal durch Handlungen zu beeinflussen zu können. Aussengesteurte Kulturen (z. B. arabische, afrikanische und asiatische Länder) prägen Menschen so, dass sie sich als Teil der Natur verstehen und diese deshalb an seine Umgebung anpassen sollen.

Nonverbale Kommunikation

Die nichtverbale Kommunikation und Körpersprache ist keine direkte kulturelle Dimension, sondern eine Sammlung von Verhaltensweisen.
Eine direkte Verbindung mit einer kulturellen Dimension wie vorher beschrieben scheint es nicht, zumindest nicht direkt, zu geben. Grundsätzlich kann man jedoch davon ausgehen, dass in insbesondere in Asien die Körpersprache eher gedämpft ist, wohingegen in Südeuropa die Körpersprache mehr benutzt wird.
Es ist daher ratsam sich mit den am weitesten verbreiteten Symbolen vor einer Interaktion vertraut zu machen.

Vermeidung interkultureller Missverständnisse

Interkulturelle Kompetenz wird definiert als die Fähigkeit, sich auch in anderen Kulturräumen als den eigenen erfolgreich bewegen zu können. Die agierenden Personen sollten dabei in der Lage sein, Vorstellungen, Motive und Probleme von Gesprächspartnern anderer Kulturräume nachzuvollziehen und angemessen darauf zu reagieren. Da aber bis heute in der Wissenschaft keine eindeutigen Erkenntnisse über die Schlüsselfaktoren für die menschliche Anpassung an fremde Kulturen vorliegen, besteht auch keine eindeutige Klarheit darüber, woraus interkulturelle Kompetenz letztendlich genau besteht.
Wenn ein Projektleiter oder Projektmitarbeiter einen Regelverstoß durch einen Menschen anderer Kultur wahrnimmt, sollte seine Schlussfolgerung nicht „er verstößt gegen die Regeln“, sondern er verstößt gegen unsere Regeln“ sein. [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 18-19]

„Wichtig ist es also, das Verhalten anderer aus den Regeln Ihrer Kultur zu verstehen.“ [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 19]

Kulturelle Missverständnisse können auch vermindert werden durch Anwendung allgemeingültiger Kommunikationsregeln:

  • Meta-Kommunikation
    Meta-Kommunikation ist Kommunikation über Kommunikation. Es geht darum, die Bedeutung und die Absicht des Gesagten zu kommunizieren, indem man sich über die Regeln und Muster unterhält, nach denen die Kommunikation stattfindet.
    • „Meine Absicht ist es, … zu erfahren…“
    • „Wie würde man in Ihrer Kultur vorgehen, wenn man diese Absicht verfolgt?“
  • Aktives Zuhören
    Aktives Zuhören heißt den anderen in seiner Gefühlswelt abholen. Aktives Zuhören beinhaltet folgende Techniken:
    • Wiederholen des gehörten Sachverhalts – der Hörer gibt das, was der Sprecher sagt in seinen eigenen Worten wieder. „Sie meinen, dass…“
    • Ansprechen von Gefühlen – Der Hörer versucht, das in Worten zum Ausdruck zu bringen, was er beim Sprecher an Gefühlen und Empfindungen wahrgenommen hat.
      „Ich habe den Eindruck, dir macht das Spaß“
    • Nachfragen – Nachfragen bietet die Möglichkeit, die Problemsituation noch klarer darzustellen und besser zu verstehen. „Was meinen Sie mit…“

Förderliche Eigenschaften zum Lernen interkultureller Kompetenz:

  • Ambiguitätstoleranz die Fähigkeit, unstrukturierte und widersprüchliche Situationen aushalten zu können
  • Problemlösungsfähigkeiten
  • Empathiefähigkeiten das Einfühlungsvermögen, Anliegen und Interessen anderer aus vagen Andeutungen, Gesten oder anderen Signalen herauszulesen
  • Frustrationstoleranz mit Irrtümern, Missverständnissen und Fehlschlägen adäquat umzugehen.
  • Konfliktfähigkeit und Konflikttoleranz
  • Lernbereitschaft mit Neugier
  • Starke individuell-kulturelle Identität das Bewusstsein der eigenen kulturellen Prägung als Voraussetzung für die Auseinandersetzung mit Menschen anderer Länder/Kulturen
  • Distanzen Vermögen, sich selbst aus einer gewissen Entfernung zu betrachten
  • Humor die Fähigkeit, über sich selbst zu lachen

Vorurteile und Stereotypen

„Eine Sammlung von Informationen darüber, welche Verhaltensweisen und Normen in einem Kulturkreis typischerweise vorherrschen, wird als Stereotyp bezeichnet“. [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 19] Stereotypen helfen Personen, das Verhalten von Menschen aus einem anderen Kulturkreis zu interpretieren.

Dies erlaubt wiederum die Einordnung weiterer Informationen.

Das Vorurteil entsteht, wenn der geprägte Stereotyp nicht mehr durch neue Informationen verändert wird.

Niemand entspricht den Standards in allen Punkten, einige weichen sogar stark voneinander ab [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 21]:

Bevölkerungsverteilung und Stereotypen

Zudem befinden sich einige Länder in einem so starken Umbruch, dass es deutliche Kulturunterschiede zwischen Teilen der jüngeren und älteren Generation gibt, wie z. B. die ehemals kommunistischen Staaten. [Hoffmann, H.-E. et al., Internationales Projektmanagement, München 2004, S. 33]

Land Machtdistanz Individualismus Maskulinität Unsicherheitsvermeidung
Malaysia 104 26 50 36
Guatemala 95 6 37 101
Panama 95 11 44 86
Philippines 94 32 64 44
Mexico 81 30 69 82
Venezuela 81 12 73 76
China 80 20 66 40
Egypt 80 38 52 68
Iraq 80 38 52 68
Kuwait 80 38 52 68
Lebanon 80 38 52 68
Libya 80 38 52 68
Saudi Arabia 80 38 52 68
United Arab Emirates 80 38 52 68
Ecuador 78 8 63 67
Indonesia 78 14 46 48
Ghana 77 20 46 54
India 77 48 56 40
Nigeria 77 20 46 54
Sierra Leone 77 20 46 54
Singapore 74 20 48 8
Brazil 69 38 49 76
France 68 71 43 86
Hong Kong 68 25 57 29
Poland 68 60 64 93
Colombia 67 13 64 80
El Salvador 66 19 40 94
Turkey 66 37 45 85
Belgium 65 75 54 94
Ethiopia 64 27 41 52
Kenya 64 27 41 52
Peru 64 16 42 87
Tanzania 64 27 41 52
Thailand 64 20 34 64
Zambia 64 27 41 52
Chile 63 23 28 86
Portugal 63 27 31 104
Uruguay 61 36 38 100
Greece 60 35 57 112
South Korea 60 18 39 85
Iran 58 41 43 59
Taiwan 58 17 45 69
Czech Republic 57 58 57 74
Spain 57 51 42 86
Pakistan 55 14 50 70
Japan 54 46 95 92
Italy 50 76 70 75
Argentina 49 46 56 86
South Africa 49 65 63 49
Hungary 46 55 88 82
Jamaica 45 39 68 13
United States 40 91 62 46
Netherlands 38 80 14 53
Australia 36 90 61 51
Costa Rica 35 15 21 86
Germany 35 67 66 65
United Kingdom 35 89 66 35
Switzerland 34 68 70 58
Finland 33 63 26 59
Norway 31 69 8 50
Sweden 31 71 5 29
Ireland 28 70 68 35
New Zealand 22 79 58 49
Denmark 18 74 16 23
Israel 13 54 47 81
Austria 11 55 79 70

Je höher der Wert desto ausgeprägter der Index.

Projektfrühwarnsystem in 10 Fragen

5 min.

Summary

In Projektportfolio-Umgebungen oder auch für Projektdirektoren selbst, ist es oft nicht einfach, klare Signale aus den Projekten zu erhalten. Dies zur Prüfung, ob diese sich auf dem richtigen Weg befinden. Oft recht umfangreiche und komplexe Projektportfolio-Steuerungssysteme werden eingesetzt um genau dies zu ermitteln. Die Praxis zeigt, dass diese aufgrund der Heterogenität der Projekte (sehr groß vs. sehr klein, in Land X bzw. Land Y, im Geschäftsbereich A oder B) nicht dieselbe Zahl an zuverlässigen Messpunkten zu den verschiedensten Projekten verfügbar sind. Dieser Bericht zeigt, wie Sie auch bei unterschiedlichsten Projektgrößen und -arten durch 10 identische einfache Fragen, zuverlässige Frühwarnungen erhalten.

Warum bedarf es eines einfachen Projekt-Frühwarnsystems?

Eine andere Frühwarnung habe ich bereits hier beschrieben, die ganz andere Messgrößen hat. Je nach Anwendungsfall sollten diese Ansätze Anwendung finden. In einem Unternehmen mit hoch standardisierten Methoden, Prozessen und Tools im Projektmanagement ist der nächste logische Schritt weiter auf dem Weg zu noch mehr Qualität für Projekte die Überprüfung der Compliance dieser Vorgaben. Das Projektmanagementhandbuch beschreibt Prozesse, stellt Vorlagen und Tools zur Verfügung um jegliche Projektarten und Projektgrößen standardisiert abzuwickeln. Selbst die spezifische Anwendung von Standardapplikationen wie z. B. MS Project ist oft im Detail zu beschrieben und vorgegeben. Compliance-Kriterien ergeben sich daher im Bereich Policies, Prozesse, Vorlagen und Werkzeuge.

Weil effiziente und vor allem einheitliche Methoden oft fehlen, welche schnell Kernprobleme von Projekten aufzeigen können (und diese schnell abwenden können), wird das Senior-Management – trotz hoher Standardisierung im Projektmanagement – häufiger überrascht durch Projekte, welche

  • hinter dem Zeitplan liegen,
  • das Budget überschreiten
  • und den vereinbarten Leistungsumfang nicht erreichen

was wiederum zu

  • Unzufriedenheit von Kunden und das
  • Verfehlen von Geschäftszielen

führt.

Ein Frühwarnsystem (FWS) enthält Fragen zum Projektstatus, die in Form eines Fragebogens monatlich durch die Projektleiter zu beantworten sind.

Zielsetzung des Frühwarnsystems

Zielsetzung des Frühwarnsystems ist die Entwicklung und / oder die Integration einer Reihe von Tools und Prozessen, welche schnell potentielle Projekt-Problembereiche feststellen und ein sinnvolles Mittel zur Eskalation und Problembehebung bieten, solange sie noch in einfacher Form vorliegen um Überraschungen zu vermeiden.

Die Detail-Ziele können sein:

  • Einführung eines einfachen, skalierbaren Systems, das einfach zu warten ist durch „state of the art“-Technologie.
  • Einführung eines Systems welches es ermöglicht Probleme in Projekten aufzuzeigen und die Beseitigung dieser in der Angebotsphase, Start Up Phase und Run & Maintain Phase ermöglicht.
  • Einführung von Prozessen und Tools, welche nicht umgangen und ignoriert werden können; um die Compliance zu Prozessen und Tools zu bestätigen.
  • Die FWS-Ergebnisse zu nutzen um bestehende Berichte zu erweitern mit den FWS-Informationen.
  • Sicherstellen eines engen Time-Boxing von der Problemidentifikation bis zur Lösung.
  • Entwicklung eines Management-Kommunikationsplanes um das Senior-Management kontinuierlich zu informieren über die konsistente Implementierung und Durchsetzung der FWS Tools, Prozesse und Reporting im gesamten Unternehmen.

Die Erfolgsfaktoren des Frühwarnsystems

Um ein globales Frühwarnsystem sicherzustellen müssen folgende Erfolgsfaktoren eingehalten werden:

  • Zeitnahe und genaue Bewertung von Programm-/Projektstatus bezogen auf Schlüsselkennzeichen.
  • Das Linienmanagement mit Profit & Loss-Verantwortung für die Programme und Projekte ist verantwortlich auf negative Antworten zu reagieren und Maßnahmen zu verfolgen bis diese abgeschlossen sind.
  • Die Fragen müssen intensiv geprüft werden durch das Senior Management.
  • Die Fragen müssen global in allen eventuell vorhandenen regionalen Systemen unverändert verwendet werden.
  • Programm- und Projektmanager beantworten diese Fragen monatlich für jedes Projekt.
  • Standardreports werden den Programm-/Projekt-Sponsoren zur Verfügung gestellt um Maßnahmenverfolgung zu unterstützen.

Die Frühwarnsystem-Fragen

Folgende Fragen stellen eine Auswahl dar für ein Frühwarnsystem. Bei der Adaption für spezifische Organisationen werden auch die relativen Abweichungen in Form der Zahlenwerte angepasst. Die sogenannte Riskoantwort gibt die Antwortmöglichkeit an, welche zu einer Zwangskommentierung des Eintrages führt und in einer konsolidierten Auswertung als „Alarmsignal“ dient.

Nr.FrageRisikoantwort
1Ist die letzte Kundenumfrage mit mehr als 3,5 Punkten (von 5 Punkten) bewertet worden?
Nein
2 Wird der Projektplan wöchentlich mit geleisteter Arbeit und Restaufwänden aktualisiert und neu berechnet?
Nein
3 Sind alle genehmigten Änderungsanträge im Projektplan abgebildet?
Ja
4Verläuft die Personalbesetzung entsprechend der Planung im Projektplan?Ja
5Ist eine gemeinsame Projekt-Governance verabschiedet worden?Ja
6Wurde ein Lenkungsausschuss in den letzten 30 Tagen abgehalten?
Nein
7 Ist die Planabweichung (Schedule Variance) > 10%?
Ja
8 Ist die Kostenabweichung (Cost Variance) > 10%?
Ja
9Hat das Projekt Arbeit außerhalb des genehmigten Projektdefinitionsumfangs geleistet?Ja
10 Sind alle bisher erbrachten Leistungen abgenommen worden? Nein

In einem Datenbanksystem sind die Fragen im Feld „Antwort“ jeweils mit „Ja/Nein“ zu beantworten.

Ist eine Frage positiv beantwortet dann ist diese Frage abschließend beantwortet, also fertig.

Ist eine Frage negativ beantwortet dann wird von den Projektleitern die Eingabe von Maßnahmen zur Lösung der negativen Situation angefordert.

  • Feld „Maßnahme“: Maßnahme zur Lösung der negativen Situation eintragen
  • Feld „Verantwortlicher“: Den Namen des für die Maßnahme Zuständigen auswählen
  • Feld „Plan-Datum“: Datum angeben, bis zu dem die Maßnahme erledigt sein soll / muss (Plan-Datum)
  • Feld „Status“: Status der Maßnahme auswählen.

Die Ergebnisse werden idealerweise in ein unternehmensweites webbasiertes FWS-Tool dargestellt um zentrale Reports und Auswertungen erstellen zu können.

Das Zusammenspiel mit einem Projektmanagementhandbuch-Fragebogen

Sind (weltweit) einheitliche Richtlinien, Prozesse, Tools und Templates im Projektmanagementbereich verfügbar ist eine Erweiterung des Fragebogens in Betracht zu ziehen.

Eine detaillierte Befragung der Projektmanager sollte initial bei Projektstart und bei wesentlichen Projektänderungen durch einen ausführlichen Self-Assessment-Fragebogen erfolgen, welcher deutlich über folgende mögliche FWS-Ergänzungsfragen hinausgeht.

Nr.FrageRisikoantwort
1Wurde die Projektdefinitions-Vorlage aus dem Projektmanagementhandbuch verwendet?nein
2Wurde das Schätzverfahren und die Schätztemplates verwendet gemäß Projektmanagementhandbuch?nein
3Wird wöchentlich eine Earned Value Berechnung basierend auf dem aktuellen Projektplan durchgeführt?nein
4Werden Probleme, Risiken, Abnahmen, Change Requests kontinuierlich im Template aus dem Projektmanagementhandbuch festgehalten?nein

Persönliche Beobachtungen zum FWS

Folgende Beobachtungen konnte ich bei der Betreuung von Projektmanagern zum Thema FWS und den Auswertungen feststellen:

  • Trotz sehr präziser und eindeutiger Fragen ist häufig eine zusätzliche Erläuterung (idealerweise durch eine Handbuch) gegenüber den Projektmanagern und in anderer Richtung eine Kommentierung spezifischer Sachverhalte durch die Projektmanager erforderlich. Einheitliche Vorgaben durch die von zentraler Stelle für spezifische nicht standardisierte Fälle sind sicherzustellen. Damit kann die Qualität auch für diese Fälle bezüglich der Aussagekraft des Frühwarnsystems sichergestellt werden.
  • Bei den Projektmanagementhandbuch-Ergänzungsfragen hat sich bestätigt, dass nur durch bereits ausgebildete Projekt- und Programmmanager sprechende Antworten gegeben werden konnten. Es ist besser auf eine Muss-Antwort zu verzichten um die Qualität der Aussagen nicht zu verwässern.

Bei der Analyse zur Adaptierung eines vergleichbaren Systems in einer Organisation ergeben sich folgende grundsätzlichen Überlegungen:

  • Die ersten Fragen lassen sich nahezu vollständig auf andere Unternehmen übertragen.
  • Ein derartiges ergänzendes (paralleles) Reporting ist nur durch globale Vorgaben durchzusetzen. Regionale oder gar abteilungsbezogene Initiativen würden zu viel Widerstand erfahren.
  • Eine automatische Benachrichtigung und Erinnerung zur Anlage des FWS-Berichtes ist vorzusehen.
  • Eine monatliche Frequenz kann sich, bei anderen Unternehmen mit durchschnittlich kleineren Projekten, als zu gering erweisen.
  • Eine automatische Analyse der Ergebnisse ist erforderlich unter Berücksichtigung der manuellen Zusatzkommentare. Eine Analyse ohne Berücksichtigung der Zusatzkommentare ergibt ein falsches Bild auf die Gesamtauswertung.
  • Wie bei allen anderen Reporting ist auch hier zu beachten, dass bei besonders vertraulichen Projekten / Kundenumfeldern ein Frühwarnsystem ebenfalls ausgeschlossen sein kann.
  • Die Berichte müssen IT-technisch so abgebildet sein, dass sie (nahezu) nicht umgangen und ignoriert werden können; um die Compliance zu Prozessen und Tools zu bestätigen. Diese sollten z. B. mit der Ablage des offiziellen Statusreports verbunden sein.
  • Die FWS-Ergebnisse sollten in bestehende Reports eingebunden sein um die klassischen Adressaten des Projektstatusberichtes ebenfalls über den Zusatzstatus des Frühwarnsystems zu informieren. Somit ist sichergestellt, dass auch dieser Empfängerkreis eine direkte oder indirekte Qualitätssicherung der Angaben durchführt.
  • Die Ergebnisse des Frühwarnsystems sollten regelmäßig mit vollständigen Projekt- oder Programmaudits verglichen werden um die Aussagekraft zu validieren und kontinuierlich zu verbessern.
  • Das Frühwarnsystem darf in einem Projekt nicht erst durch die erstmalige Ablage eines Projektstatusberichtes, sondern z. B. durch die Anlage von Projektnummern oder Projektcodes initial ausgelöst werden.
  • Das Frühwarnsystem sollte in Stufen eingeführt werden. Zuerst sollten ausschließlich Projekte mit hohem Projektvolumina oder Komplexität in den Umfang eingeschlossen werden (wichtig ist hierbei harte Kriterien anzuwenden). Dies erlaubt auch den Betreuungsaufwand der Projektmanager durch die Analysten besser zu managen.

Übergabe eines Programmes in 6 Phasen

2 min.

Summary

Sobald Sie ein Programm übergeben, sollten Sie einige Dinge bei der Vorbereitung und Übergabe selbst beachten. Hier hat sich für mich ein 6-Phasen-Ansatz bewährt welcher bei mir immer wieder eingesetzt wird.

1. Preparation (so früh wie möglich!)

  • Abstimmung mit den Stakeholdern
  • Überblick über den Wissenstransfer-Plan
  • Budget für Wissenstransferperiode vereinbaren
  • Suche nach einem Nachfolger und Erhalt der Zustimmung zu einer bestimmten Person von Stakeholdern
  • Endgültiges Startdatum des Nachfolgers bestätigen (Zeitleiste des Wissenstransferplans anpassen)

2. On-Boarding (-3 Wochen)

  • Nachfolger startet im Projekt als zusätzliche Ressource
  • Projektvereinbarung definieren
  • Nachfolger in allen regulären Administrationstätigkeiten wie Zugriffsrechte, Kalendereinladungen, Übergabeprozessdokumentation etc. einbinden
  • Nachfolger im Newsletter vorstellen

3. Shadowing (-2 Wochen)

  • Nachfolger war Ihr bisheriger Stellvertreter, wenn möglich.
  • Der Nachfolger nimmt auch in Ihren besuchten Meetings teil.
  • Der Nachfolger beobachtet alle Ihre Kernaktivitäten.
  • Nachfolger aktualisiert und ändert gemeinsamen Plan für den Wissenstransfer und leitet Aktivitäten ein.

4. Re-Shadowing (-1 Woche)

  • Nachfolger übernimmt Verantwortung
  • Räumen Sie Ihren Schreibtisch und übergeben Sie ihn an den Nachfolger
  • Der Nachfolger leitet alle Ihre früheren Meetings
  • Der Nachfolger ist für alle Ihre bisherigen Prozesse verantwortlich
  • Stehen Sie zur Verfügung für alle Fragen Ihres Nachfolgers

5. Backup (beginnt mit dem Tag der Übergabe)

  • Weniger Präsenz zeigen, nur an internen Teambesprechungen teilnehmen, aber keine Kundengespräche
  • Seien Sie für jede Hilfe für Ihren Nachfolger da
  • Bereiten Sie sich darauf vor, einige operative Tätigkeiten zu übernehmen um den Nachfolger bei der Einarbeitung zu entlasten
  • Senden Sie alle noch eingehenden Anfragen / Fragen an Ihren Nachfolger

6. Phase Out (+1 Woche)

  • Erledigen Sie alle Off-Boarding-Aktivitäten selbst
  • Projektvereinbarung auflösen
  • Seien Sie da, um Ihrem Nachfolger zu helfen
  • Nehmen Sie keine Betriebsaufgaben mehr an
  • Geben Sie eine Abschiedsparty und verabschieden Sie sich im Newsletter
  • Senden Sie alle noch eingehenden Anfragen / Fragen an Ihren Nachfolger
  • Gehen Sie! (+2 Wochen)

Erfolgsfaktoren für eine ordnungsgemäße Übergabe

  • Binden Sie Kunden und alle Stakeholder frühzeitig ein.
  • Ordnen Sie Prozesse nicht programm- / personenzentriert an, sondern prozess- / verantwortungsszentriert.
    • Seien Sie nicht selbst Single Point of Contact für mehrere Prozesse,
    • Machen Sie stattdessen jedes Ihrer Teammitglieder von Anfang an für einen oder mehrere Prozesse verantwortlich (Management by Objective).
  • Planen und bereiten Sie Ihre Übergabe als eigenes Projekt vor.
  • Erstellung eines Wissenstransferplans, der von allen Beteiligten abgestimmt werden muss.
    • Aufschlüsselung des Wissenstransfers in granulare Aktivitäten (1-3 Stunden).
    • Bitten Sie Ihren Nachfolger, diesen Plan zu pflegen und jede abgeschlossene Aktivität abzuhaken.
    • Behandeln Sie diesen Plan und aktualisieren Sie ihn wie jeden anderen Projektplan.
  • Kommunizieren Sie Ihren Weggang dem gesamten Team spätestens zu Beginn der Wissenstransferphase.
  • Sehen Sie nach erfolgreichem Wissenstransfer eine Backup-Phase vor von bis zu zwei Wochen.
  • Definieren Sie ein klares Übergabedatum im Wissenstransferplan.

Viel Spaß in Ihrem neuen Projekt / Programm!

Agiler Wirbel?!

3 min.

Summary

Agile Arbeit bzw. Lieferung ist nur möglich, wenn notwendige Entscheidungen stets abgerufen werden können. Ebenso funktioniert es ohne entsprechende Governance nicht. Die Arbeitsweise in Turnaround-Situationen von klassischen Projekten ähnelt sich stark mit dem Ansatz agiler Projekte. Hier wird der Fokus auf kurze Iterationen und enge Abstimmung mit dem Kunden gelegt. Aus dieser Beobachtung heraus sollte die Einführung von agilen Prinzipien entsprechend erfolgen. Agile Prinzipien werden sich in unterschiedlichen Branchen auch weiterhin unterschiedlich verbreiten. Wer nun aber Agilität mit Methode oder Technologie verbindet liegt falsch! Frühe Ergebnisse im Projekt und enge Abstimmung mit dem wirklichen Kunden sind keine Methoden- oder Toolergebnisse.

Agiles Projektmanagement funktioniert ohne entsprechende Governance nicht

Agile Arbeit bzw. Lieferung ist nur möglich, wenn notwendige Entscheidungen stets abgerufen werden können. In meinem Beitrag „Kommunikationsprinzipien in einem Projekt“ ist gut zu erkennen, dass die kurze Dauer bis zu einer Entscheidungsfindung extrem wichtig ist. Diese wird oft durch die mittleren Schichten des Managements in einem Unternehmen verlangsamt oder gar blockiert. Dieser sogenannte Permafrost kann die vom Top-Management oft sinnvollerweise identifizierte Notwendigkeit von Agilität nicht nachvollziehen. Diese Schicht will ebenso im Projektverlauf die notwendigen Entscheidungen nicht selbst treffen, aber platziert diese dann auch nicht richtig beim Senior Management.

Agiles Projektmanagement ähnelt sich stark mit dem Ansatz klassischer Projekte in Turnaround-Situationen

Bei agilem Projektmanagement und bei Turnaround-Situationen von klassischem Projektmanagement wird der Fokus auf kurze Iterationen und enge Abstimmung mit dem Kunden gelegt. Aus dieser Beobachtung heraus sollte die Einführung von agilen Prinzipien entsprechend erfolgen. Der klassische Projektplan ist dann meist nur Referenz für vertragsrelevante Liefergegenstände. Die Kette des Versagens bei Projekten ist die Kundenbeziehung und damit die Governance-Struktur, danach die Tools und Prozesse und spätestens anschließend die Mitarbeiterfrustration. Bei der Einführung von agilen Prinzipen ist die Sequenz genau anders herum. Wobei meiner Erfahrung nach kann in Projektorganisationen die Teamstimmung zu jeder Zeit vielfältigste Probleme anzeigen und nicht nur pauschal, dass „etwas“ nicht stimmt, sondern auch in welchen Projektmanagement-Domänen (siehe mein Beitrag Teamstimmung). Interessant wäre hier bei der Einführung von agilem Projektmanagement ebenfalls diese Methode zu verwenden.

Wie wird der agile Wirbel sich nun verbreiten?

Wie in meinem Beitrag „Projektleiter im Jahre 2030“ abzuleiten ist, werden sich die agilen Prinzipien in unterschiedlichen Branchen auch weiterhin unterschiedlich schnell und stark verbreiten. Wie diese „Agilität“ dann aussehen wird, ob reines SCRUM, SRUM of SRCUM, Kanban, scaled agile, SAFe, LeSS oder Spotify wird durch die Kunden- und Unternehmensumgebung (also Produkte, Dienstleistungen, Branche, Größe usw. geprägt). Ist das „klassische Projektmanagement“ damit tot? Sicherlich nicht, denn es gibt bestimmte komplexe (sehr große Programme) und komplizierte (Wiederholungsprojekte) für die das klassische Projektmanagement die bessere Alternative sein wird. Sinnvollerweise wird der klassische Projektmanager dennoch Tool-Picking aus der agilen Box machen. Wer nun aber Agilität mit Methode oder Technologie verbindet liegt falsch! Frühe Ergebnisse im Projekt und enge Abstimmung mit dem wirklichen Kunden sind keine Methoden- oder Toolergebnisse. Konzepte und Planung sind in beiden Ansätzen erforderlich. Diesem Aspekt tragen Ansätze wie die skalierten agilen Ansätze wie z. B. SAFe besonders Rechnung.

Die Herausforderungen für Product Owner oder Projektmanager

Die Herausforderung für die Treiber von Vorhaben, ob nun Product Owner, Projektmanager oder Programm-Manager wird nun sein, dass diese in unterschiedlichen Umgebungen unterschiedliche Klaviaturen spielen sollen. Denn die dogmatische Ausrichtung „wir machen nur agile Einzel-Projekte“ kann nur in Unternehmen erfolgen, die keinen Bedarf für andersartige Schnittstellen und Umgebungen haben. Der reine Agile Product Owner oder klassische Programmmanager wird daher eher die seltene Spezies bleiben. Eine Stigmatisierung der beiden Ansätze ist daher sicherlich nicht sinnvoll, sondern die kombinierte Anwendung bzw. schlicht gesagt das agile klassische Projekt ist die Zukunft. Frühe und stete Resultate und enge Endkundenabstimmung sind in allen Vorhaben der Erfolgsfaktor.

Dieser Artikel entstand im Rahmen der Blogparade des Projektmagazins.

Projektplanungssoftware – alles nur Mist?!

< 1 Minute


Summary

Die Projektplanungs- und Steuerungssoftware nur als visuelle Darstellung des Planungsstandes zu nutzen ist vergeudete Zeit. Einige wenige Tipps sind zu befolgen und MS Project und Co sind auch für die Projektüberwachung und -steuerung sehr sinnvoll einzusetzen.

Ich höre immer wieder von angehenden Projektmanagern, aber auch von erfahrenen Projektmanagern, dass ein Projektsteuerungstool wie z. B. MS Project nicht praktikabel einzusetzen ist. Es sei zu kompliziert und die eigentliche Steuerung sei damit auch nicht wirklich möglich.

Wenn Du folgende Tipps beachtest geht nichts mehr schief

  • Stelle in den Optionen ein, dass MS Project oder das Tool Deiner Wahl die Planung auf „feste Arbeit“ basiert
  • Die Verfügbarkeiten (Stundenkapazität und Urlaube) der Ressourcen/Qualifikationen müssen im Projektkalender eingetragen werden.
  • Kein manuelles Datum (Termin) setzen, außer Projektstart oder Endtermin.
  • Für jeden Vorgang / Arbeitspaket muss ein Vorgänger (zumindest der Projektstartmeilenstein) und Nachfolger (zumindest der Projektendmeilenstein) eingetragen werden.
  • Keine Dauer eingeben, sondern nur Aufwand für den Vorgang / Arbeitspaket.
  • Für jeden Vorgang sollte nur eine Ressource/Qualifikation eingetragen werden.
  • Den kritisch Pfad im Ablauf- und Terminplan (Gantt) immer anzeigen lassen. Dieser muss durchgängig über die gesamte Projektlaufzeit ohne Unterbrechung angezeigt werden. Ansonsten liegt ein Fehler vor, wie z. B. manuelles Datum gesetzt.
  • Plane nur maximal 2-3 Monate rollierend im Detail (Ressourcen und Aufwände) voraus.

Und das letzte Hemmnis ist dann immer wieder, dass Dein Unternehmen keine MS Project Lizenz für Dich investiert. Dann besorge Dir ProjectLibre als Opensource oder eine andere Freeware.

Kommunikationsprinzipien in einem Projekt

2 min.

Summary

Die ersten Stunden oder zumindest Tage innerhalb eines Projekts prägen den Großteil der laufenden Kommunikation in einem Projekt oder Programm. Mit anderen Worten: Wenn Sie in einem Projekt keine oder zu spät Kommunikationsprinzipien definieren, müssen Sie sich später mit Problemen auseinandersetzen: Alle „weichen“ Themen wie die Nutzung von Mobiltelefonen oder Laptops bei Meetings, Respekt untereinander, Zuhören, Verständnis bestätigen, Teilnahme aller an Meetings, statt Mails besser anrufen und so weiter und so fort sind Themen, die oft leichter zu verfolgen sind als das individuelle Verhalten in folgenden Themen. Daher sollte eine Anleitung ausgegeben werden. Ein Beispiel meiner Standardkommunikation, die in Projekten etabliere.

Sinnvolle Kommunikationsprinzipien

Ich möchte Sie bitten, folgende Kommunikationsprinzipien zu befolgen.

Um unseren Mailverkehr zu minimieren und die Organisation unserer Mailboxen zu erleichtern, sollten wir uns auf folgende Regeln einigen:

  • Senden Sie nur Mails an die Teammitglieder, die die Informationen benötigen!
  • Klingt selbstverständlich, aber gemeint ist: Vermeide große Verteiler ohne Grund.
  • Solange wir an Entwürfen oder an der Fertigstellung von Vorlagen arbeiten, werden die Entwürfe nur an das definierte Team verschickt.
  • Häufig werden große Kopienverteiler in Mails zur Eskalation um auf Nummer sicher zu gehen verwendet: Bitte kontaktieren und informieren Sie den Programm-Manager bzw. das gewünschte Teammitglied vorher.
  • Die Stream Leads werden gebeten, einen Workaround für die interne Eskalationsverarbeitung in ihren Streams zu entwerfen, da wir alle der Meinung sind, dass die Arbeit von uns allen sehr wichtig für dieses Programm ist! Aus diesem Grund werden nur Mails mit einer kritischen Zeitachse als dringend markiert.
  • Mails mit einer kritischen Auswirkung auf den Programminhalt müssen im Betreff mit URG markiert werden
  • Um eine Überlastung der Kapazität unseres Mail-Servers zu vermeiden, senden wir Links, wo immer es möglich ist.
  • Last but not least: Vergraben Sie nicht die benötigten Informationen in E-Mail-Ketten….

E-Mail Richtlinie

  1. Alle Mails müssen mit der Art der Informationen gekennzeichnet sein, die in der E-Mail angegeben sind.
  • INF: Information; eine Information wird die Adressaten gegeben, es besteht kein Handlungsbedarf.
  • ACT: Datum, Aufgabe; und die Aufgabe ist vom Empfänger zu erledigen.
  • DEL: Lieferung; eine angeforderte Lieferung erfolgt.
  • URG: Dringende Informationen beginnen mit diesem Präfix.
  • z. B. URG: DREAM: SP01: …. – siehe auch Dateinamenskonvention
  1. Mail subjects needs to include a short and clear description of the content
  2. Addressees on copy have in general no action!
  3. Escalations
    In general the escalations come up as followed:
    1. Team Members to Subproject Managers
    2. Subproject Managers to Project Management
    3. Project Management to Program Sponsor / SteercoE.G.: INF: DREAM: SP01: Mail Convention

Dokumentnamens-Konvention

Alle Dokumente im Programm sind wie folgt benannt:

  1. Datum (yyyymmdd)
  2. Projektname (DREAM) und Unterprojektnummer (z. B. SP01)
  3. Dokumentname
  4. Version (Entwürfe V 0.1 ff; fertige Versionen V 1.0 ff)

Z. B.: 20170220_DREAM_WP01_name convention_V 0-1.doc

Die vier Elemente sind durch einen Unterstrich getrennt.

Alle Dokumente, die reviewed wurden, folgen dieser Namenskonvention:

  1. Name des Originaldokuments
  2. Rev<Initialen des Reviewers>
  3. Reviewdatum (yyyymmdd)

z.B.: 20170220_DREAM_WP01_name convention_V 0-1_RevMW_20170307.doc

Besprechungsagenda

< 1 Minute

Summary

Effektive Meetings sind immer eine Herausforderung. Es gibt viele Regeln und Checklisten für Meetings. Aber bis jetzt habe ich noch keine gute Vorlage für eine effektive Meeting-Agenda gefunden.

In meiner täglichen Anwendung habe ich den Bedarf an zwei verschiedenen Agenda-Formaten festgestellt, abhängig von der Dauer der Sitzung oder besser der Anzahl der Agenda-Themen.

Für eine Telefonkonferenz

verwende ich seit Jahren immer das folgende einfache Format (falls nicht viele Themen behandelt werden müssen):

INITIAL SITUATION/AUSGANGSSITUATION
  • Der Projektstatus muss bis Freitag 12:00 Uhr MEZ an Steerco gemeldet werden.
PREPARATION NEEDED / ERFORDERLICHE VORBEREITUNGEN (including owner)
  • Bitte aktualisieren Sie Ihre Arbeitspakete bis Donnerstag 10:00 Uhr CET Server Link (ALLE).
  • Bitte aktualisieren Sie den Status der Aktionspunkte / Server link (ALLE)
  • Berichtsvorlage aktualisieren (ML)
AGENDA
  • Überprüfung von Schnittstellenproblemen zwischen Arbeitspaketen (MW)
  • Abstimmung von Aktionspunkten über Arbeitspakete hinweg (MW)
  • Abstimmung über Teamdiskussionen auf dem Projektserver (ML)
  • Probleme und Risiken, auf die es abzustimmen gilt (ML)
RESULTS EXPECTED OF THE MEETING/ ERWARTETE ERGEBNISSE DES MEETINGS
  • Abgestimmte Sicht auf Projektstatus
NEXT STEPS AFTER THE MEETING/ NÄCHSTE SCHRITTE IM NACHGANG ZUM MEETING
  • Zu konsolidierender Bericht (ML)
  • Bericht zur Überprüfung und Übermittlung an Steerco (MW)

Für Präsenz-Workshops oder längere Telkos

bevorzuge ich das folgende Format:

Berlin, Hauptstr. 14-16, 1.OG, Raum E1.15a, Montag 05. Feb 2018 – CMO FMO Big Picture
Ziel: Gemeinsames Verständnis von CMO und FMO Big Pictures und damit verbundenen Aktivitäten
Ansatz: Time Boxing
Vorbereitung: Präsentation: Serverlink
Materialien: 2 Beamer, Moderationskoffer
Zeit (CET)ThemaHostInput und Vorbereitung erforderlich / VerantwortlicherErgebnis erwartet / VerantwortlicherTeilnehmer
09:30 – 10:00Einführung und Ziel der BesprechungMW Einführung – keine Vorbereitung erforderlich Alle Alle

Projektleiter im Jahre 2030

6 min.

Summary:

Gibt es den Projektleiter im Jahre 2030 noch – wie wir ihn heute kennen? Die Antwort in Kürze: Nein. Im Bereich Führung, der Organisation als auch in der Umsetzung des Vorhabens werden sich die Aufgaben der Projektleiter verändern.

Es hat mich gereizt bei der Blogparade des Projektmagazins mitzumachen. Denn zum einen sprechen wir hier über einen Begriff „Projektleiter“ der heftig in die Diskussion geraten ist und zum anderen über einen Zeitraum, der selbst für Zukunftsforscher sehr lange ist. Die Forscher trauen sich selbst nicht in dieser Zeitdimension festzulegen.

Der Projektleiter als Begriff

Beide Teile des Wortes Projektleiter sind derzeit in großer Diskussion, ob diese aussagekräftig oder gar noch zeitgemäß sind. Projekte werden wie z. B. im BI von Otto als nicht mehr erforderlich gesehen. Der (Projekt-) Leiter oder Projektmanager ist im reinen agilen Set nicht vorgesehen. Hier wird Führung oder Leadership noch einen wichtigeren Fokus bekommen als ohnehin heute schon. Leiter im Sinne von steuern und lenken wird immer weniger relevant werden aufgrund der bereits jetzt sichtbaren Entwicklungen.

Es ist problematisch eine Zukunftsaussage über den Projektleiter in 2030 zu geben, wenn bereits heute der Begriff als solches nicht mehr die Verankerung hat, wie vielleicht in den vorhergehenden Jahrzehnten. Wagen wir einen Versuch.

Der Maßstab Zeit

Bis 2030 sind es noch 12 Jahre. Erscheint lange. Wenn man überlegt wie die Welt aussah, vor 12 Jahren, von heute 2018 rückwärts gerechnet: Es gab kein iPhone, kein Android, keine Apps, kein Youtube, kein Spotify, kein Kindle, kein Tablet, keinen digitalen Vollformatsensor in einer Serienkamera (um auch mein Hobby in den Kontext zu bringen). Man erkennt es passiert mehr in 10 bzw. 12 Jahren als man annimmt. Deshalb rechnen Zukunftsforscher nicht in Jahren, sondern in Wochen, um die Kurzfristigkeit zu betonen und um die Zukunftsmodelle und -aussagen schneller zu bewerten und vergleichbarer zu machen. Der Zukunftsforscher nimmt 50 Wochen pro Jahr an. Wie viele Wochen seit Neujahr sind schon wieder vorbei? Drei. Also weniger als 50 Wochen bis Neujahr. In diesen drei Wochen sind nach dem menschlichen Gefühl nicht viele Dinge passiert. Im besten Falle haben Sie dreimal eine Wochenplanung gemacht und dreimal ein Resümee gezogen. Aber die „Wochen-übergreifenden“ taktischen Themen erscheinen nicht signifikant. Dennoch arbeiten Projektmanager, Scrum Master oder Ein-Mann-Unternehmen an den revolutionären Aspekten der Zukunft. In den nächsten 597 Wochen bis zum Jahr 2030.

Wie sieht das Projektumfeld aus in 500 Wochen?

Wie sieht die Welt in 500 Wochen aus? Ziemlich sicher scheint: In 500 Wochen werde ich und 70% der deutschen Bevölkerung kein Auto mehr besitzen.  In 500 Wochen werden wir keine Smartphones mehr besitzen. In 500 Wochen werden wir keinen Supermarkt mehr nutzen. In 500 Wochen werden wir mehr Strom in den Haushalten produzieren als wir konsumieren. In 500 Wochen werden wir Fleisch aus Laboren gezüchtet essen. In 500 Wochen werden wir Ohren für Menschen aus dem 3D-Drucker als medizinische Ersatzteile erhalten. In 500 Wochen werden Roboter die Pflege von alten Menschen unterstützen. In 500 Wochen werden 40% der deutschen Bevölkerungen intelligente nicht-medizinische Implantate besitzen. In 500 Wochen …

All diese Vorhaben – nennen wir sie mal hier einfachheitshalber Projekte – werden von Menschen begleitet. Es geht hier nicht um die Generierung der Ideen, sondern um deren Umsetzung. Dass Ideen-Gebung, -definition und -umsetzung personell nahe beieinander liegen sollen, befürworten die einen und kritisieren die anderen.

Anforderungen an die heutigen Projektleiter im Jahr 2030

Welche Auswirkungen hat dies denn auf mich und alle anderen Projektleiter aus dem Jahre 2018? Der Visionär Projektmanager, der diese eine Idee treibt, wird so nicht mehr existent sein. Wir erkennen bereits heute wie komplex die Arbeitswelt und die Welt als solches geworden ist. Dies kann nicht mehr eine Person in sich vereinen. Es wird also immer mehr eine Teamleistung sein müssen. Was gut ist. Dies wirkt sich selbstredend auf den Aspekt der Führung aus. Wir erkennen Trends bereits in agilen Ansätzen die aber noch nicht das Ende der Fahnenstange darstellen. Die nachkommenden Generationen haben und fordern eine andere Einstellung zur Arbeit. Das habe ich schon vielfach selbst erlebt und rede auch schon wie meine Opas („Die jungen Leute heutzutage“). Aber auch diese Veränderung ist gut, denn …

“Ohne Veränderung keine Entwicklung.”
Birgit Ramlow (*1948), Angestellte und Hobby-Aphoristikerin

Transformation vs. Revolution

Und nun ein viel kritisierter Begriff aus der BWL: Transformation. Wenn ich in Wochen denke und Vorhaben in einem überschaubaren Zeitrahmen gestalte hat man transformationelle Aspekte. Revolutionär ist es, wenn wir einen kompletten Technologie- oder Paradigmenwechsel erleben. Das Smartphone war keine Revolution, sondern eine mutige und kreative Zusammenstellung von verfügbaren Technologien. Der Push kam etwas verzögert erst durch die Apps. Aber auch diese sind keine klassische Revolution, sondern eine Weiterentwicklung auf einer anderen Plattform und daher durch mehr Nutzer eingesetzt. Wieso wurde denn das Smartphone letztendlich doch als revolutionär empfunden und hat auch diesen äußeren Anschein? Nun, meine These ist, dass Manager von Konkurrenten wie Nokia und Siemens nicht mutig genug waren und nicht auf den Markt gehört haben. Die Vorstellungskraft bzw. Kreativität hat nicht gefehlt. Denn auch den Autobauern wird heute die ganze Entwicklung vorhergesagt und die Reaktionen darauf sind meiner Meinung nach zu zögerlich. In Entwicklungszeiträumen von 4 Jahren pro wirklichen Modellwechsel, also 200 Wochen, kann man in der heutigen Zeit nicht mehr agieren. Was können wir also daraus für den Projektleiter ableiten?

Er wird viel in Transformationsvorhaben mitarbeiten und wird bei mutigen und schnell agierenden Geschäftsführungen durch das schnelle Platzieren von neuen Vorhaben damit zur Revolution beitragen.

Unternehmensführung oder Gremien in 2030

Die größten Veränderungen werden sicherlich noch eine Ebene höher (wenn man davon überhaupt sprechen mag – heute zumindest eine Ebene höher) erforderlich sein beim Portfolio-Board, bei den Product Ownern oder wie auch immer ein Unternehmen für sich die strategische Entscheidungsfindung implementiert. Bei Otto im Produktbereich, im agilen Umfeld durch den Product Owner – als Vertreter für die Geschäftsleitung oder das Portfolio-Board im klassischen Projektmanagement. Diese Gremien werden sicherlich noch mehr, als in meinem im Jahre 2016 verfassten Artikel, dem definierten Anspruch gerecht werden müssen, um die Taktung zwischen den Transformationen hin zu Revolutionen zu ermöglichen. Und seien wir mal ehrlich, in den ~ 60 Wochen seit dem dieser Artikel verfasst wurde, ist der Anspruch immer noch nicht erfüllt. Es gibt also Handlungsbedarf.

Unterschiedliche Anforderungen an die Projektleiter

Wird die Entwicklung abhängig sein von der Projektart?

Es wird nicht mehr den Projektleiter geben der universell in allen Branchen und Projektarten Projekte leiten kann. Zumindest die heutige Anspruchshaltung hierzu wird immer weniger zutreffend sein.

Im Bereich der Softwareentwicklung werden sich agile Ansätze und für große Programme hybride Mischformen entwickeln. Eine Ausgestaltung dieser Mischformen ist Material für einen weiteren Blogbeitrag.

Investitionsprojekte werden weiterhin ähnlich organisiert sein wie heute. Und damit auch die Rolle und Aufgabenstellung des Projektleiters. Auch wenn die heutigen Beispiele, wie Berliner Flughafen, nicht vielversprechend sind.

Der junge Projektmanager in 2030

Was ist aber mit dem jungen Projektleiter der im Jahre 2030 erstmals Projekte managen soll? Dieser startet mit einem Handicap. Denn er selbst, aber auch seine IT-Architekten und anderen Kollegen, werden hier in Deutschland keine „Gesellenjahre“ mehr erlebt haben, da alle „Gesellentätigkeiten“ schon in den 90er Jahren aus dem letzten Jahrhundert Nearshore oder Offshore verlagert wurden. Ein einsteigen in den Beruf Projektmanager, wie auch immer der geformt ist, wird nicht mehr so einfach möglich sein.  Dies beobachtet man heute in der schon vor länger veränderten Umfeldern, wie in der Textilindustrie. Hier gibt es heute oft in Deutschland Probleme qualifizierte Näherinnen für die Musterkollektion zu finden. Deshalb müssen Firmen selbst unternehmenskritische Bereiche wie Design und Musterkollektion ins Ausland verlagern. So wird es auch mit den Projektmanagern der Zukunft sein. In der virtuellen Welt, mit den unterstützenden Technologien, wird dies immer einfach sein trotzdem hier in Deutschland noch Projekte durchzuführen. Aber auch die Nähe zum Kunden ist aufgrund der virtuellen Unterstützungstechniken immer weniger wichtig. Das heißt, Vorhaben werden in 2030 auch komplett von remote aus durchgeführt werden können (inkl. Projektleiter), ohne die Kundennähe in Deutschland zu vermissen.

Projekt-Steuerungs- und Lenkungsgremien – verstehen, formen und nutzen

4 min.

Wieso bewegt uns das Thema Gremien als Projektmanager? Wir benötigen für unsere Projekte klare Entscheidungen in Fällen, in denen unsere Befugnisse nicht ausreichen. Wieso ist es oft schwer diese notwendigen Entscheidungen zeitnah, klar und präzise zu erhalten?

Dafür müssen wir verstehen, dass es unzählige Begriffe für ein und das Selbe gibt … und viele Begriffe mehrfach belegt sind in der Praxis.

Zu den daraus folgenden typischen Problemen mit den Gremien komme ich später.

Wo können wir hier Lösung finden? PMI klammert Rollenbeschreibungen und Aufbauorganisation auf. Hier kann uns also nicht geholfen werden. Prince2 definiert die genannten Gremien detailliert und harmonisch mit IPMA bzw. GPM.

Die DIN 69901-5 definiert den Lenkungssauschuss als  „übergeordnetes Gremium, an das der Projektleiter berichtet und das ihm als Entscheidungs- und Eskalationsgremium zur Verfügung steht.“
Das hilft nicht wirklich umfänglich weiter.

Dann schauen wir mal wie der PM3 (bei Amazon) der GPM uns unterstützt.

Was sind Steuerungsgremien? Diese können auf allen Meeren in alle Himmelsrichtungen das Steuerruder des Schiffes ausrichten.

Diese Steuergremien sind … intern und … projektübergreifend. Synonyme Begriffe definiert Patzak/Rattay (bei Amazon) als Steering Commitee, Steuerungsgruppe und Projektbeiräte. Die Aufgabe dieses Gremium ist die Auswahl von Projekten und die Zusammenhänge von Projekte zu analysieren, beobachten und zu steuern.

Der Lenkungsausschuss wir auch im Duden … meiner Meinung nach sehr gut … definiert. Nämlich als „Ausschuss für die wirtschaftliche Lenkung“. Hier geht es also im Gegensatz zum Steuerungsgremium nicht um die generelle Sinnbestimmung eines Projektes, sondern die wirtschaftliche Beobachtung und Einflussnahme. Der Lenkungsausschuss ist also nur am Lenkrad im Auto auf vorgegeben Straßen und kann entscheiden an welchen Kreuzungen welche Richtung eingeschlagen werden soll.

Dieses Gremium, der Lenkungsausschuss, kann auch externe Partner wie wichtige Lieferanten oder den Endkunden inkludieren.

Im PM3 wird festgehalten, dass es in den Organisationen keine einheitlichen Regeln gibt wie Steuerungsboards arbeiten sollen. Es ist also von Unternehmen zu Unternehmen unterschiedlich. Allerdings lässt sich eine typische Verantwortung herausarbeiten. Das Steuerungsgremium

  •          Ernennt den Projektmanager
  •          Wählt Projekte aus
  •          Stoppt Projekte
  •          Initiiert Projekte und prägt die
  •          Grobe Zielfestlegung.

Auch für den Lenkungsausschuss beschreibt der PM3 typische Verantwortungsbereiche. Diese sind

  •          Verfolgung des Projektfortschrittes
  •          Konflikte und Befugnisse zwischen Linie und Projekte zu klären
  •          Meilensteine und Projektergebnisse abzunehmen
  •          Eskalation an Unternehmensführung bzw. Portfoliomanagement und
  •          eventuell, falls es kein separates Change Board gibt, die Entscheidung von Änderungsanträgen.

Was müssen wir nun als Projekt- und Programmmanager tun um durch Gremien erfolgreich unterstützt zu werden. Hierfür erläutere ich die nach meiner Erfahrung nach wichtigsten Punkten.

  • Wir müssen diese Gremien formen in dem wir
  • notwendige externe Partner einbinden
  • hoch in der Hierarchie angesiedelte Mitglieder für die Gremien gewinnen
  • fordern, dass ein Sprecher des Gremiums festgelegt wird
  • Eskalationsinstanzen und Lösungsdauern auf den jeweiligen Eskalationsstufen vereinbaren und auch das
  • Änderungsmanagement vereinbaren.

Welche Voraussetzungen bzw. Wissen ist in den Steuerungsgremien erforderlich? Diese müssen laut Patzak / Rattay Transparenz und Wissen über die Unternehmensstrategie besitzen und Kenntnisse über das Projektportfolio. Ansonsten kann das Steuerungsgremium bzw. Portfolio-Board nicht sinnvoll agieren.

Um die Gremien richtig nutzen zu können müssen wir ein paar Grundregeln beachten.

Kinder und Manager haben zumindest eines gemeinsam. Sie können sich nur 3 Dinge merken.

Bei Ihren Ausführungen als Projektmanager im Lenkungsausschuss empfehle ich Ihnen daher

  •          Die wichtigste Statusinformation
  •          Einen Entscheidungswunsch und
  •          Einen Mitwirkungswunsch

an das Management zu adressieren.

Achten Sie dabei immer darauf diese Kernbotschaften knapp und präzise zu formulieren, denn seit dem Jahr 2000 bis heute ist die Aufmerksamkeitsspanne bei uns Menschen von 12 auf 8 Sekunden gefallen. Der neuen Technik und dem neuen Lifestyle sei Dank.

Das heißt nach 8 Sekunden schweift der Zuhörer oder Betrachter ab, sofern nicht etwas Neues für sie oder ihn kommt. Übrigens, der Goldfisch hat seit eh und je 9 Sekunden Aufmerksamkeitsspanne und übertrifft uns seit Neuestem.

Jetzt komme ich zu den bereits angekündigten typischen Problemen. Erfahrungen aus meinen Projekten.

Berlin. Öffentliches Projekt. Bei öffentlichen Projekten ist die Trennung des Projektauftraggebers und der Gesellschafter oft sehr schwierig. Besonders die Governance-Organisation wird dadurch komplex. Die Anforderungen zu definieren ist in solch einem Konstrukt besonders schwer, ebenso wie das managen von Änderungen. Ein „reinregieren“ – dieses Verb klingt ja schon staatlich bzw. öffentlich – ist hier vorprogrammiert.

Südafrika. Ein Projekt bei einem Energiekonzern mit mehreren Konzernbereichen, welches zentrale Prozesse und IT-Systeme vereinheitlichen soll. Aufgrund der schieren Größe des Projektes sind mehrere externe Parteien erforderlich. Oft werden bei Großprojekten die Projektbüros gerne durch externe Beratungsunternehmen besetzt um den herausfordernden und neutralen Charakter zu unterstreichen.

Selbst als größter Auftragnehmer kann es schwer fallen einheitliche Gremiendefinitionen und Besetzungen zu prägen. Maximale Lösungszeiten von eskalierten Problemen auf den jeweiligen Eskalationsstufen zu vereinbaren ist oft ein Ding der Unmöglichkeit, aber erfolgskritisch.

Israel. Nochmals ein Energiekonzern mit mehreren Konzerntöchtern welche Ihre Beschaffungsorganisationen und Prozesse harmonisieren sollen. Ein weiteres Problem bei der Gremiennutzung ist die Entscheidungsfixierung und vor allem Entscheidungsdurchsetzung. Im Vorfeld zu Gremiensitzungen vorsozialisierte Entscheidungsalternativen und Entscheidungen werden oft nach erfolgter Sitzung wieder in Frage gestellt bzw. nicht durchgesetzt. Hier ist der kulturelle Einfluss prägend und aussteuernd. Entscheidungsfindungen können ein Vielfaches dauern.

Bonn. Eskalationsebenen sind bei Auftraggeber und Auftragnehmer nicht gespiegelt, das heißt eine unterschiedliche Anzahl an Hierarchieebenen ist vorhandenen. Probleme sind vorprogrammiert.
Ein weiteres Problem entsteht durch leider häufige Aussage und Umsetzung von „ein internes Projekt muss auch ohne LA funktionieren“. Wie soll das gehen?!

Damit möchte ich mit den typischen Problemen abschließen.

Welche 3 Kernbotschaften sollten Sie heute mitnehmen.

  1. Wir müssen die Unterschiede zwischen Lenkungsausschuss und Steuerungsgremium verstehen und auch immer die beiden Gremienarten erkennen und
  2. aktiv gestalten.
  3. Gerne Kontakt mit mir aufnehmen für aktiven Austausch.