Project Leadership

Delegation geht uns alle an

Veröffentlicht am

Eigentlich wollte ich in diesem Beitrag über sistemic underdelegation schreiben, ein Phänomen, welches ich sehr oft in Unternehmen beobachte. Ich hätte geschrieben, wie fürchterlich eine derartige Situation ist. Ich hätte analysiert, was die Ursachen für ein derartiges Organisationsversagen sind. Viele von euch hätten mir zugestimmt. Nur verändert hätte diese haarscharfe Analyse nichts.

Es gibt nichts Gutes. Außer man tut es. (Erich Kästner)

Ich mach mir die Welt, widewide wie sie mir gefällt. (Pippi Langstrumpf)

Fangen wir also bei uns an. Veränderung ist immer schwer. Neue Gewohnheiten zu etablieren ist schwer (siehe Du willst dich verändern? Tu. Es. Jeden. Tag.). Es ist allerdings leichter, sich selbst zu ändern, als andere.

Delegiere weniger Aufgaben nach oben

Verblüfft? Das ist meine Absicht. Es gibt immer wieder Momente, in denen wir nicht weiterwissen. Wie formuliere ich diese Kommunikationsmaßname? Wie erstelle ich eine Vorstandsvorlage? Wie lege ich einen Nutzer in Jira an? Wie löse ich eine Aufgabe in Code? Jetzt kommt es auf die richtige Balance an. Nein, du solltest dich nicht 5 Tage eingraben auf der Suche nach der Lösung. Du könntest dich allerdings durchaus fragen, ob es andere Informationsquellen als deinen Chef gibt. Google, das Intranet, Leitfäden, Benutzerhandbücher und auch die Kollegen. Ja, vielleicht ist dein Chef schneller mit einer Antwort zur Stelle. Ja, vielleicht ist es bequemer, den Chef zu fragen, als Dokumente zu wälzen. Nimm jetzt mal die Perspektive deines Chefs ein: du hast 7 Mitarbeiter. Jeder kommt einmal am Tag mit einer Frage, die du in 5 Minuten beantwortest. Allerdings wirst du auch immer wieder aus deiner Konzentration gerissen und brauchst 10 Minuten, um den Faden wieder aufzunehmen. Knapp 2h deiner Arbeitszeit sind weg.

Delegiere weniger Entscheidungen nach oben

Chef, wollen wir unser Team Event hier oder dort abhalten? Ist mir doch egal… Chef, ich würde gerne mit Frau Meier den Urlaub tauschen, ist das in Ordnung? Ja, mach halt… Chef, kann ich am Mittwoch Homeoffice machen, die Elektriker kommen? Ja, du kennst doch meine Einstellung zu Homeoffice…

Ja, es gibt Chefs, die wollen tatsächlich über jeden Scheiß entscheiden. Andererseits sind viele Chefs froh über jede Entscheidung, die sie nicht treffen müssen (im positiven wie im negativen Sinne).

Positionier dich. Entscheide dich. Das ist oft gar nicht so einfach. Du machst dich angreifbar, weil deine Entscheidung ja auch falsch sein könnte. Aber besser eine schnelle, falsche Entscheidung, als gar keine Entscheidung. Oder es gibt keine einfache Entscheidung, weil es gute Argumente für jede der Varianten gibt. Oder weil dir Informationen fehlen. Deinem Chef geht es aber nicht anders…

Probier es doch einfach aus. Das nächste Mal, wenn du deinen Chef um eine Entscheidung bitten möchtest, schick ihm stattdessen eine Nachricht „Chef, ich werde übrigens A,B,C tun“. Wenn dein Chef anderer Meinung ist, kann er noch rechtzeitig einschreiten.

Wenn das funktioniert, geh einen Schritt weiter: „Chef, ich habe übrigens A,B,C getan“. Wenn dein Chef anderer Meinung ist, kann er kurzfristig reagieren und den vermeintlichen / tatsächlichen Schaden problemlos bereinigen.

Delegiere mehr Aufgaben nach unten

Stell dir mal eine einfache Frage: welche meiner Aufgaben könnte auch ein „juniorer“ Mitarbeiter übernehmen, wenn er die entsprechende Einarbeitung und Coaching bekäme? Mit „juniorer“ Mitarbeiter meine ich nicht nur die „eigenen“ Mitarbeiter, welche dir fachlich und / oder disziplinarisch unterstellt sind, sondern auch Kollegen mit weniger Erfahrung in einem bestimmten Themengebiet.

Der Anteil der potenziell delegierbaren Aufgaben liegt oft bei 40-50% aller Aufgaben, und zwar quer durch ein komplettes Unternehmen und auch unabhängig von einer Hierarchiestufe.

Warum übernimmst du diese Aufgaben? Warum delegierst du diese Aufgaben nicht? Für den Fall, dass dir die Vorteile der Delegation nicht klar ersichtlich sind oder du nicht weißt, wie du am Besten delegierst – schau dir mal meinen Onlinekurs an, hier lernst du insbesondere diese zwei Aspekte.

Delegiere mehr Entscheidungen nach unten

An dieser Stelle sollte ich etwas präziser formulieren. Es geht mir nicht um einzelne Entscheidungen, sondern um Entscheidungsbereiche, in den immer wieder ähnliche Entscheidungen getroffen werden müssen. Dabei kann die Entscheidung an einen einzelnen Mitarbeiter delegiert werden oder auch an das Kollektiv des Teams. Beispielsweise könnten der Einsatz bestimmter Tools, die Kernarbeitszeit, Urlaubsplanung im Team diskutiert und vom Team entschieden werden. Warum bist du derjenige, der die beste Entscheidung treffen kann? Welche Qualifikationen oder Informationen hast du, die den Kollegen fehlt?

Analog zu der Delegation nach oben kannst du übrigens auch hier schrittweise vorgehen, z.B. „ich würde aus den folgenden Gründen so entscheiden – bildet euch selber eine Meinung und entscheidet “, „wie habt ihr denn entschieden und warum“. Auf diese Art und Weise kann man den möglichen Schaden durch andere Entscheidungen begrenzen.

Fazit

Was zeichnet eigentlich einen guten Chef aus? Er vertraut mir – er lässt mich einfach mal machen. Und wenn ich Hilfe oder einen Ratschlag brauche, ist er kurzfristig greifbar. Jetzt können wir nicht unbedingt unseren Chef ändern, aber wir können unserem Chef mehr Zeit verschaffen (Stichwort weniger Delegation nach oben) und wir können ein Role Model für unser Team sein (Stichwort Delegation nach unten). Insofern: nicht jammern sondern einfach machen!

Project Leadership

Wunsch und Wirklichkeit bei der Mitarbeitergewinnung

Veröffentlicht am

Es gibt Situationen, die machen mich fassungslos. Ein großes Unternehmen hat erkannt, dass wegen der alternden Belegschaft viele (sehr viele) neue Mitarbeiter eingestellt werden müssen. Besagtes Unternehmen hat viele Maßnahmen umgesetzt, um als Arbeitgeber attraktiv zu sein. Das Unternehmen fährt eine bundesweite Kampagne, um neue Mitarbeiter auch auf ungewöhnlichen Wegen zu finden und einzustellen. So weit, so gut. 

Eine neue Mitarbeiterin beginnt in diesem Unternehmen. Ihr wurde während der Bewerbungsphase gesagt, dass ihre Abteilung neue Impulse von außen benötige. Ihr wurde gesagt, dass sie in ihrem Arbeitsgebiet weitgehend eigenständig arbeiten könne. Sie ist begeistert und hoch motiviert, endlich anzufangen. 

6 Wochen später sieht es anders aus. Neue Impulse, Ideen oder Anregungen werden von ihrer Vorgesetzten konsequent abgewiegelt. „Das haben wir schon immer so gemacht“. Eigenständiges Arbeiten? Fehlanzeige. Ihre Chefin sagt ihr haarklein und detailliert, was sie wann und wie abzuarbeiten hat. Zu allem Überfluss wird jeder Schritt kontrolliert, persönliche Emails konsequent mitgelesen. Die Motivation ist im Eimer. Kämpfen? Einknicken? Kündigen? Ich weiß nicht, wie die Geschichte ausgeht. 

Mitarbeiter verlassen nicht ihren Job, sie verlassen ihren Chef. 

Die Maßnahmen, um die Attraktivität als Arbeitgeber zu verbessern? Überflüssig. 

Die Recruitingkampagne? Überflüssig. 

Die Mitarbeitersuche und Vorstellungsgespräche? Überflüssig. 

Ob das so von der Unternehmensleitung gewünscht ist? Ob derartige Situationen bedacht wurden? Vermutlich nicht. Dieses Beispiel zeigt aber aus meiner Sicht recht deutlich, vor welchen Herausforderungen Unternehmen stehen. Es geht nicht darum, „Vorgesetzte“ zu haben, sondern echte Führungskräfte zu haben. Vor 15 Jahren haben Mitarbeiter ihre Vorgesetzten ertragen. Heute wechseln sie das Unternehmen. 

Jetzt beschäftigen wir uns ja üblicherweise mit Projekten. Heißt das, wir müssen uns mit dieser Thematik nicht beschäftigen? Mitnichten, wir sind ebenfalls davon betroffen. Als Führungskraft im Projekt beeinflussen wir maßgeblich, wie Mitarbeiter ihr Unternehmen wahrnehmen, ob sie für „ihr“ Unternehmen brennen oder Dienst-nach-Vorschrift schieben. Wir beeinflussen maßgeblich, ob Mitarbeiter gerne in unserem Projekt arbeiten, oder so schnell wie möglich flüchten. Je nach Größe des Projektes und Organisation, haben wir evtl. auch ein faules Ei im Führungsteam, welches unsere Mitarbeiter vergrault. Insofern ist mein Appell, dass wir uns bewusst machen, wie gute Führung aussieht (meine Sicht hierzu findet ihr hier) und ob wir selbst und unsere Führungsmannschaft dies auch leben. 

Zu guter Letzt…

Eine Bitte

Hat dir dieser Artikel gefallen? Dann leite ihn an Freunde und Kollegen weiter, die ebenfalls von dem Artikel profitieren können.

Ein Hinweis

Willst du regelmäßig food-for-thought erhalten? Dann melde dich doch einfach für meinen Newsletter an, den ich einmal pro Monat verschicke.

Project Leadership

Du willst dein Team motivieren? Zelebriere Gemeinsamkeiten!

Veröffentlicht am

Beim Thema Motivation von Teams kann man sich viel vom Sport abschauen. Sowohl in guten wie auch in schlechten Zeiten. Daher möchte ich eine Erfahrung teilen, die mich lange beschäftigt hat. Ich spiele Volleyball. Vor einigen Jahren haben wir das Unmögliche möglich gemacht und sind mit eher durchschnittlichen Spielern in die Verbandsliga aufgestiegen. Wahnsinn! Der ganze Verein war aus dem Häuschen! So konnte es weitergehen – und damit die nächste Saison genauso erfolgreich verlief, verstärkten wir uns mit einigen exzellenten Spielern. Wir stiegen ab. Wie konnte das passieren?

In der Saison des Aufstiegs…

  • …hatten wir alle das gleiche Ziel: wir wollten aufsteigen! Die erfahrenen Spieler wollten es noch einmal wissen, die jungen Spieler wollten mehr und mehr. Niemand spielte, um nicht zu verlieren, jeder wollte gewinnen.
  • …teilten wir das Motto “work hard, party hard”. Nach Training oder Spiel wurde gemeinsam der Kohlenhydratspeicher aufgefüllt – gerne auch in flüssiger Form.
  • …zelebrierten wir unsere uralten, orangenen Trikots. Es kam ja auf den Inhalt an!
  • …retteten wir die unmöglichsten Bälle und machten “irgendwie” den Punkt.

Einer für alle, alle für einen.

In der folgenden Saison waren wir zwar nominell stärker, aber die Gemeinsamkeiten, die uns zusammengeschweißt hatten, waren nicht mehr so stark ausgeprägt.

Auch im Arbeitsumfeld können wir diese Erkenntnis nutzen. Wir können die Motivation nicht verordnen. Wir können allerdings sehr wohl Gemeinsamkeiten finden und zelebrieren – je höher das Zusammengehörigkeitsgefühl der Teammitglieder, umso höher die Motivation für das eigene Team. Gemeinsamkeiten lassen sich beispielsweise wie folgt gruppieren:

  • Vision & Ziel
  • Verhaltensweisen
  • Name & Symbol

Gemeinsame Vision & Ziel

Irgendwie logisch – wenn das gesamte Team das gleiche Ziel verfolgt, hängen sich alle mehr rein. Und zwar nicht, weil sie sollen, sondern weil sie wollen. Das ist jetzt auch der kleine, aber feine Unterschied – wir reden hier von intrinsischer Motivation. Das funktioniert am besten, wenn das ganze Team das Ziel selbst erarbeitet und es nicht verordnet wird. Das „buy-in“, wie es so schön heißt, ist im Team deutlich größer, wenn das Team das Ziel selbst entwickelt hat.

Ich muss gestehen, dass hier zwei Herzen in meiner Brust schlagen. Einerseits verstehe und befürworte ich den Ansatz, dass das Team das Ziel entwickelt. Andererseits bin ich ein starker Verfechter, dass der Product Owner oder Projektleiter die Vision des Produktes zu seiner eigenen macht (siehe beispielsweise hier oder hier). Wie lässt sich dieser potenzielle Konflikt auflösen? Aus meiner Sicht gibt es zwei Ansätze. Erstens kannst du als PO oder PL deine Vision kontinuierlich kommunizieren und die Gründe und Vorteile erläutern mit dem Ziel, dein Team zu überzeugen. Zweitens könntet ihr zwei (oder mehr) Ziele haben, beispielsweise ein inhaltliches Ziel (was wollen wir erreichen), welches du als PO/PL vertrittst, und ein Ziel zur Zusammenarbeit (wie wollen wir das erreichen), welches gemeinsam entwickelt wird.

Gemeinsame Verhaltensweisen

Gemeinsame Verhaltensweisen entwickeln sich in der Regel ganz automatisch, wenn ein Team längere Zeit zusammenarbeitet. Wenn du in ein anderes Team wechselst, hast du sicherlich schon einmal bemerkt, dass jedes Team ein bisschen anders arbeitet – selbst innerhalb der gleichen Firma. Was hat das jetzt mit Motivation zu tun? Nun, ihr könnt euch diese Verhaltensweisen bewusst machen und bewusst einsetzen, um die Gemeinsamkeiten im Team zu betonen und auch eine (freundschaftliche) Abgrenzung zu anderen Teams herzustellen. Ein paar Beispiele?

  • Wir sind das Team, das erst um 10:30 Uhr mit der Arbeit beginnt
  • Wir sind das Team, das extremes Timeboxing betreibt
  • Wir sind das Team, das einmal monatlich Kartfahren geht
  • Wir sind das Team, das immer eine einhundertprozentige Testabdeckung hat

Es geht insofern darum, die Verhaltensweisen, die „eh schon“ existieren, zu zelebrieren.

Ihr könntet auch noch einen Schritt weitergehen, und nicht nur die Verhaltensweisen zelebrieren, die schon etabliert sind, sondern gemeinsam gewünschte Verhaltensweisen definieren und umsetzen. Ein Vorgehen, welches aus meiner Erfahrung recht gut funktioniert, ist ein strukturiertes Brainstorming. Ihr definiert Bereiche, die euch in der Zusammenarbeit wichtig sind, z.B. Kommunikation, Qualität, Prozesse, usw. Jeder im Team denkt an sein bestes und sein schlimmstes Projekt. Anschließend schreibt jeder auf, welche Verhaltensweisen im besten und schlimmsten Projekt für diese Bereiche üblich waren. Ein paar Beispiele:

  • Fragen innerhalb des Teams wurden am gleichen Tag beantwortet vs. ich musste mehrere Tage auf eine Antwort warten
  • Wir haben Themen im direkten Gespräch geklärt vs. es wurden meterlange Email-Ping-Pongs geschickt

Nachdem ihr diese möglichen Verhaltensweisen gesammelt und diskutiert habt, könnt ihr euch bewusst für gemeinsame Verhaltensweisen entscheiden.

Gemeinsame Namen und Symbole

Wenig verwunderlich: auch ein Teamname und ein Symbol können die Gemeinsamkeiten betonen. Das Zusammengehörigkeitsgefühl zu einer Gruppe ist vielen Menschen wichtig und die Identifikation mit einer Gruppe kann extrem hoch sein.

Insofern: sucht euch im Team einen Namen aus. Der Name kann etwas mit der Vision oder dem Ziel zu tun haben, er kann bestimmte Verhaltensweisen aufgreifen, oder auch ein Phantasiegebilde sein. Wichtig ist nur, dass er vom gesamten Team mitgetragen wird.

Ähnlich verhält es sich mit Symbolen. Auch Symbole als ‚Markenzeichen‘ können die Identität eines Teams stärken. Warum kleben sich manche Leute einen Apple-Aufkleber auf die Heckscheibe? Weil sie ihre Zugehörigkeit zu der Gruppe der Apple-Nutzer demonstrieren wollen. Dies ist übrigens ein schönes Beispiel für den sogenannten T-Shirt-Test: wenn die Teammitglieder T-Shirts mit dem Namen und/oder Symbol des Teams mit Stolz in der Öffentlichkeit tragen, dann ist das Zusammengehörigkeitsgefühl hoch.

Fazit

Einer für alle, alle für einen. Eigentlich ist es gar nicht so schwer, aus einer Ansammlung von Menschen ein eingeschworenes Team zu machen. Du musst nur die Gemeinsamkeiten erarbeiten, finden und schließlich zelebrieren. Wann du all das neben deinem „eigentlichen“ Job tun sollst? Dies ist dein eigentlicher Job! Schau dir doch mal meinen Beitrag zu Project Leadership an!

Zu guter Letzt…

Eine Bitte

Hat dir dieser Artikel gefallen? Dann leite ihn an Freunde und Kollegen weiter, die ebenfalls von dem Artikel profitieren können.

Ein Hinweis

Willst du regelmäßig food-for-thought erhalten? Dann melde dich doch einfach für meinen Newsletter an, den ich einmal pro Monat verschicke.

Project Leadership

Project Leadership – was ist das eigentlich?

Veröffentlicht am

Ist das nicht das Gleiche wie Projektmanagement? Und wenn nein – brauchen wir das überhaupt? Immer dieses Denglisch – gibt es dafür auch einen deutschen Begriff? Fragen über Fragen… die ich nun beantworten will.

Lassen Sie mich aber mit einem Beispiel starten, welches ursprünglich von Stephen Covey verwendet wurde. Stellen Sie sich vor, es ist das Jahr 1817. Sie sind Teil eines Expeditionstrupps im brasilianischen Dschungel, um Handelsartikel für Europa zu suchen und um die Tier- und Pflanzenwelt zu erforschen. Ein Teil des Teams nimmt die Macheten in die Hand und bahnt sich einen Weg durch den Dschungel. Es ist harte, körperliche Arbeit, aber die Männer kommen gut voran, nachdem sie ihren Arbeitsrhythmus gefunden haben. Kein Strauch, kein Baum und kein Tier kann sich Ihnen in den Weg stellen. Kurz hinter ihnen laufen einige Gesellen mit dem komischen Titel „Manager“. Sie sorgen beispielsweise dafür, dass der Weg gerade verläuft, dass die Männer regelmäßig ruhen können, dass die Macheten geschärft werden und alle die richtige Schnitttechnik beherrschen. Das Team kommt gut voran und lässt sich nicht beirren. Bis zu dem Moment, wo Sie auf einen Hügel klettern und „wir sind im falschen Dschungel“ brüllen.

Peter Drucker wird folgendes Zitat zugesprochen: „Management is doing things right; leadership is doing the right things”. Im klassischen Projektmanagement sehe ich einen deutlichen Fokus auf der Exekution eines Projektes. Ein vorgegebener Scope wird in time und in budget umgesetzt. Ob der Scope nutzbringend ist, ist nach Beginn des Projektes sekundär (siehe hierzu auch mein Artikel 50% aller Projekte scheitern – aber wie messen wir eigentlich den Projekterfolg?). Nun wird der Eine oder Andere sicherlich anführen, dass genau aus diesem Grund Vorgehensweisen wie Scrum genutzt werden. Dies ist im Prinzip richtig… aber auch hier sehe ich oft, dass zwar der prozessuale Aspekt von Scrum genutzt wird, aber weiterhin ein vorab definiertes Projektziel umgesetzt werden soll. Soll heißen: die Managementaufgaben werden durch das Projektteam übernommen (dieses soll ja selbstorganisierend sein), aber diejenige, die auf den Hügel klettert und feststellt, dass das Team im falschen Dschungel ist, fehlt (oder hat nicht ausreichend Entscheidungsbefugnis).

Lassen Sie uns noch einmal zurück zu dem Expeditionsbeispiel gehen. Wen würden Sie in Ihr Expeditionsteam aufnehmen und an Hand welcher Kriterien? Sie wissen ja nur grob, was Sie erwartet… Dschungel, also kräftige Machetenhände. Wütende Einheimische, also Übersetzer oder Söldner. Ein Biologe, um die Pflanzenwelt zu erforschen, ein Geograph, um den Weg zurück zu finden, ein Geologe, um Gold und Silber zu entdecken, usw. Sie ahnen schon, nicht alle wünschenswerten Fähigkeiten haben einen Platz im Expeditionsteam und vom sozialen Gefüge habe ich noch gar nicht gesprochen. Der Erfolg der Expedition hängt aber maßgeblich vom richtigen Team ab. Genau wie im Projekt. Und genau wie oben könnten Sie argumentieren, dass diese Aufgabe vom gesamten Team unter Unterstützung des Scrum Masters übernommen wird. Auch hier stimme ich grundsätzlich zu, gleichzeitig beobachte ich jedoch, dass die Zusammenstellung von Teams oft zufällig erfolgt, Teams ohne Scrum Master arbeiten oder Team und Scrum Master die notwendige Erfahrung bzw. das notwendige Bewusstsein für die Weiterentwicklung fehlt.

Unter Project Leadership (oder Führung im Projekt) verstehe ich drei zentrale Aspekte:

  1. Sie wählen die richtigen Mitarbeiter für das perfekte Team aus, motivieren sie und entwickeln sie weiter.
  2. Sie formen aus den einzelnen Mitarbeitern ein grandioses Projektteam und entwickeln das gesamte Team weiter.
  3. Sie geben eine klare Richtung für das Team vor und vermitteln den Sinn des Projektes.

Warum sind diese drei Aspekte nun so wichtig? Denken Sie an den Dschungel… mit dem falschen Team und fehlendem „Überblickbehalter“ werden Sie Ihr Expeditionsziel nicht erreichen. Auch im Projekt sind Ihre Mitarbeiter Ihr wichtigstes „Produktionsmittel“ und auch im Projekt sollten alle Mitarbeiter kontinuierlich das Projektziel im Blick haben. Wozu es führen kann, wenn die drei zentralen Aspekte berücksichtigt werden, habe ich in meinem Artikel „6 Gründe, warum Spaß im Projekt wichtig ist“ beschrieben.

Bleibt noch die Frage, wer diese Führungsaufgabe im Projekt übernehmen sollte. Ich habe hier eine eindeutige Meinung: dies ist die Aufgabe des Product Owners in agilen Projekten oder des fachlichen Projektleiters in klassischen Projekten. Beide stehen dafür ein, ein fachliches Ziel zu erreichen. Insofern ist der dritte Punkt aus meiner Sicht unkritisch. Außerdem haben beide das größte Interesse daran, das Projekt erfolgreich durchzuführen, schließlich ist es ihr Ziel und ihr Projekt. Beide Rollen haben allerdings aus meiner Sicht aktuell nicht das notwendige Gewicht. Ein Product Owner ist oft der Erfüllungsgehilfe des eigentlichen Entscheiders und hat damit weder im Team noch in der Gesamtorganisation das notwendige Gewicht. Fachliche Projektleiter gibt es oft gar nicht oder gerne auch als 20%-Mitarbeiter im Projekt, auch hier fehlt das notwendige Standing.

Von alleine wird sich an dieser Situation auch nichts ändern. Als PO oder fachlicher Projektleiter müssen Sie Ihre Führungsverantwortung einerseits einfordern und ihr andererseits auch gerecht werden. Beides ist aus meiner Sicht unabdingbar, um Projekte erfolgreich durchzuführen.

Wie sehen Sie das? Sind Sie ebenfalls der Meinung, dass wir mehr Leadership im Projekt brauchen? Wie könnten wir dies erreichen? Ich freue mich auf Ihre Kommentare!

Zu guter Letzt…

Eine Bitte

Hat Ihnen dieser Artikel gefallen? Dann leiten Sie ihn an Freunde und Kollegen weiter, die ebenfalls von dem Artikel profitieren können.

Ein Hinweis

Wollen Sie regelmäßig food-for-thought erhalten? Dann melden Sie sich doch einfach für meinen Newsletter an, den ich einmal pro Monat verschicke.

Project Leadership

6 Gründe, warum Spaß im Projekt wichtig ist

Veröffentlicht am

Auf meiner Homepage habe ich beschrieben, was mich antreibt: Ich helfe Menschen dabei, Spaß und Erfolg im Projekt zu haben. Spaß? Bei der Arbeit? Schließt sich das nicht aus? Nein, überhaupt nicht. Es gibt sogar gute Gründe, warum Spaß im Projekt wichtig ist.

Das Leben ist zu kurz für langweilige Projekte

Jetzt mal ehrlich – wieviel Zeit verbringen Sie im Projekt? 8-9 Stunden jeden Tag, dazu noch Fahrtzeit und das Mittagessen mit den Kollegen? Dann sind Sie knapp die Hälfte des Tages mit Ihrem Projekt beschäftigt. Wollen Sie ernsthaft die Hälfte Ihrer Zeit mit Dingen verschwenden, die Ihnen keinen Spaß machen? Ich habe hierzu ja schon einmal einen Beitrag geschrieben, daher an dieser Stelle nur eine aktuelle Anekdote. Unser Sohn ist ABC-Schütze. Und glücklicherweise scheint ihm Schule und Lernen Spaß zu machen. Es macht ihm so viel Spaß, dass er selbst abends noch rechnet und liest. Wir hatten überlegt, ihn davon zu überzeugen, dass er abends doch lieber mit uns spielt. Aber warum eigentlich? Wer sagt denn, dass Lernen „Arbeit“ sei und Spielen „Spaß“? Unser Sohn offensichtlich nicht. Ich weiß nicht, wie lange unser Sohn Spaß am Lernen haben wird – aber schon mit Beginn der Schulzeit trennen wir deutlich und unnötigerweise zwischen Arbeit (=anstrengend, ernsthaft) und Vergnügen (=leicht, spaßig).

Spaß fördert die Kreativität und erleichtert Innovationen

Oft geht es im Projekt ja gerade darum, komplexe Probleme auf kreative Art zu lösen. Damit meine ich sowohl Probleme unserer Kunden, als auch technologische oder prozessuale Problem. Wir kommen mit einer anderen, neuen, innovativen Lösung um die Ecke. So weit, so gut. Was hat das jetzt mit Spaß zu tun?

  • Sowohl Kreativität als auch Spaß beinhaltet das Herumspielen mit Ideen und das Einnehmen von unterschiedlichen Perspektiven
  • Spaß und Spiele befeuern unser Gehirn, indem mehr Adrenalin ausgeschüttet wird und Sauerstoff in Richtung Gehirn transportiert wird
  • Spaß senkt unsere Hemmschwelle, so dass wir auch verrückte Ideen leichter äußern
  • Spaß führt zu mehr Spontaneität, so dass wir mehr Ideen generieren

Warum sehen Innovation Labs so anders aus als normale Büros? Jaja, weil Unternehmen sich als „hip“ und „cool“ darstellen möchten. Aber auch, um den Spieltrieb in uns wieder zu entfachen.

Spaß erhöht die Produktivität

Ein Grund für die Controller unter uns. Eine Studie aus dem Jahr 2015 hat herausgefunden, dass glückliche Menschen ca. 12% produktiver sind als eine Vergleichsgruppe. Was heißt das denn für uns? Ironie an: Glückliche Mitarbeiter können ca. 1h früher die „Arbeit“ verlassen und sich ihrer eigentlichen Passion widmen. Es ist betriebswirtschaftlich sinnvoll, einen Klassenclown pro 10-Personen-Team zu beschäftigen. Ironie aus.

Spaß bei Seite (habe ich das gerade wirklich geschrieben?!): Falls Sie bis jetzt auf dem Standpunkt beharrt haben, dass Ihre Mitarbeiter keine Zeit für ein Späßchen hier und da haben, sondern stattdessen etwas „schaffen“ sollten, so sollten Sie umdenken: Diese Späßchen können dazu führen, dass Ihre Projektkosten um ein Zehntel sinken und Sie den Nutzen des Projektes deutlich früher einfahren können.

Spaß führt zu mehr Kommunikation und Zusammenarbeit im Team

Ein Projektteam ist nicht eine Ansammlung von Menschen, welche die gleiche Arbeit ausführen. Ein Projektteam lebt von der Diversität der Mitglieder und der Art und Weise, wie sich die unterschiedlichen Fähigkeiten ergänzen. Voraussetzung ist natürlich, dass die Teammitglieder miteinander sprechen. Genau hier kommt der Spaßfaktor ins Spiel: Spaß kann dazu führen, dass Diskussionen offener und ehrlicher geführt werden. Das Vertrauen der Mitglieder ist höher, so dass die Zusammenarbeit vereinfacht wird. Zusätzlich führt der gemeinsame Spaß dazu, dass sich Mitarbeiter besser kennenlernen und die Eigenschaften, Fähigkeiten und Präferenzen der Kollegen besser einschätzen können.

Spaß sorgt dafür, dass die besten Mitarbeiter in Ihrem Team arbeiten wollen

Mitarbeiter sind keine Bleistifte. Auch wenn ich manchmal den Eindruck habe, dass die Zusammenstellung von Teams genauso erfolgt, als ob man Bleistifte bestellen würde. Warum wollen Sie die besten Mitarbeiter für Ihr Team? Nun, es gibt eine recht anschauliche Unterteilung von Mitarbeitern in A, B und C Mitarbeiter. A Mitarbeiter bringen Ihr Projekt weiter, B Mitarbeiter schwimmen mit im Strom und C Mitarbeiter sabotieren Ihr Projekt. Sie wollen nur A Mitarbeiter in Ihrem Team haben.

Eine andere Untersuchung besagt, dass inspirierte Mitarbeiter bis zu 2,2 mal produktiver sind als durchschnittliche Mitarbeiter. Stellen Sie sich vor, Sie könnten Ihre Projekte in der Hälfte der Zeit abschließen!

Wenig überraschend ist, dass jeder diese Mitarbeiter in seinem Projekt haben möchte. Wenig überraschend ist, dass diese Mitarbeiter sich ihre Arbeit aussuchen können. Spaß kann dazu führen, dass die besten Mitarbeiter genau in Ihrem Projekt arbeiten wollen!

Spaß führt zu einer niedrigeren Krankheitsquote

Die besten, kommunikativsten und kreativsten Mitarbeiter bringen Ihr Projekt nicht weiter, wenn sie krank im Bett liegen. Doch auch hier: Spaß führt zu einer verringerten Krankheitsquote. Damit meine ich nicht (nur) weniger Blaumachen, sondern tatsächlich ein verringertes Risiko für Herzleiden, eine Stärkung des Immunsystems, Reduzierung von Stresssymptomen und eine Verlängerung des Lebens. Okay okay, der letzte Punkt ist vielleicht etwas pathetisch. Aber mal abgesehen von den Vorteilen solider Gesundheit für die Mitarbeiter, werden Sie sich vermutlich an das letzte Mal erinnern, wo einer Ihrer Schlüsselmitarbeiter plötzlich krank wurde und ihn niemand wirklich ersetzten konnte. Dieses Problem können Sie mit ein wenig Spaß vermeiden…

 

Wie sehen Sie das? Sind Sie ebenfalls der Meinung, dass Spaß im Projektteam eine sinnvolle Sache sei? Haben Sie weitere Gründe, die für ein Späßchen und wider dem bitteren Ernst sprechen? Und wie stellen Sie ein spaßiges Umfeld her? Ich freue mich auf Ihre Kommentare!

Zu guter Letzt…

Eine Bitte

Hat Ihnen dieser Artikel gefallen? Dann leiten Sie ihn an Freunde und Kollegen weiter, die ebenfalls von dem Artikel profitieren können.

Ein Hinweis

Wollen Sie regelmäßig food-for-thought erhalten? Dann melden Sie sich doch einfach für meinen Newsletter an, den ich einmal pro Monat verschicke.

Project Leadership

Peer Feedback – wie Ihre Mitarbeiter mehr und besseres Feedback bekommen

Veröffentlicht am

Feedback ist nun kein neues Thema. Spätestens mit Eintritt in das Berufsleben wird jeder mit dem Thema Feedback in Berührung kommen und etwas über die Feedback Regeln erfahren. Auch ich habe dem Thema Feedback einen ganzen Abschnitt in meinem Onlinekurs gewidmet. In der Regel wird allerdings davon ausgegangen, dass Feedback von „oben“ nach „unten“ gegeben wird, also dass die Führungskraft oder der Projektleiter Feedback gibt. Es kann darüber hinaus aber sehr sinnvoll sein, dass Teammitglieder sich auch untereinander Feedback geben. Dies kann zu Arbeitsinhalten sein, beispielsweise durch ein Review von Dokumenten oder Code. Dies kann zum Verhalten sein, beispielsweise wenn ein Kollege regelmäßig zu spät zu Besprechungen kommt. Oder es kann auch Feedback zur Leistung sein. Die Frage ist nur – wie kriegt man das hin?

Warum Peer Feedback sinnvoll ist

Peer Feedback ist nicht nur gut für den Feedbackempfänger, auch der Feedbackgeber und das gesamte Team profitieren hiervon. Lassen Sie uns diese drei Aspekte ein wenig detaillierter betrachten.

Wenn Feedback ausschließlich von der Führungskraft gegeben wird, wird diese schnell zum Bottleneck. Einerseits räumt nicht jede Führungskraft dem Geben von Feedback eine hohe Priorität ein, andererseits gilt die Aufmerksamkeit der Führungskraft meistens mehreren Mitarbeitern. Peer Feedback kann insofern dazu führen, dass Teammitglieder mehr und schneller Feedback bekommen. Zweitens bekommt eine Führungskraft auch nicht alle Aspekte der Arbeit überhaupt mit. Sie ist beispielsweise nicht in allen Meetings und Diskussionen dabei. Teilweise kann eine Führungskraft auch nicht alle Aspekte inhaltlich beurteilen. Wenn eine Führungskraft beispielsweise nicht aus der Programmierung kommt, wird es ihr schwerfallen, inhaltliches Feedback zur Art und Weise der Programmierung zu geben. Viertens erhält der Feedbackempfänger ein breiteres Bild, wie er bzw. seine Arbeit von anderen wahrgenommen wird. Oft gibt es ja durchaus Unterschiede in der Selbst- und Fremdwahrnehmung und hier kann eine breitere Basis hilfreich sein. Schließlich ist Peer Feedback auch eine Wertschätzung der anderen Person. Der Feedbackgeber demonstriert, dass ihm die Arbeit der anderen Person nicht egal ist, sondern er investiert Zeit und Energie, um einem Kollegen zu helfen.

Peer Feedback ist allerdings nicht nur vorteilhaft für den Empfänger, auch der Geber profitiert. In erster Linie dadurch, dass er sich selbst im Klaren sein muss, warum er einen bestimmten Teil der Arbeit für gut bzw. verbesserungsfähig hält. Er muss sich insofern über die Bewertungsmaßstäbe im Klaren sein und diese verinnerlicht haben. Außerdem kann Peer Feedback dazu führen, dass der Feedbackgeber quasi gezwungen wird, auch andere Perspektiven einzunehmen und damit den eigenen Horizont zu erweitern.

Aus Sicht des ganzen Teams schließlich kann Peer Feedback dazu führen, dass ganz allgemein die Zusammenarbeit (oder neudeutsch Collaboration) verbessert wird und somit bessere Lösungen im Projekt gefunden werden.

Wie Sie Peer Feedback im Team einsetzen können

Lassen mich eins ganz klar vorwegschicken: Die unbedingt notwendige Grundlage für Peer Feedback ist ein hohes Maß an Vertrauen im Team. Ohne Vertrauen wird der Feedbackempfänger innerlich unsicher sein, ob das Feedback wirklich in seinem besten Interesse ist. Und ohne Vertrauen wird auch der Feedbackgeber nicht unbedingt das erklären, was er wirklich denkt, sondern eine politisch korrekte Aussage treffen. Ich habe in einem anderen Beitrag geschrieben, wie Sie Vertrauen aufbauen können.

Fangen wir mit dem einfachsten Thema an: Peer Feedback zu Arbeitsinhalten. Eigentlich könnte die Welt so einfach sein: ein Teammitglied erstellt etwas (z.B. ein Dokument, eine Präsentation, ein Stück Code, einen Testfall) und ein anderes Teammitglied schaut sich das Ergebnis an. Anschließend tauschen sich beide aus – warum hast du das so gemacht und nicht anders, was waren die Gründe für X, hast du über Variante Y nachgedacht usw. Wenn die beiden erst einmal zusammen sind, funktioniert das Feedback auch fast von alleine. Aber wie etabliert man das “Zusammensein”?

  • Legen Sie fest, in welchen Fällen es Feedback geben soll. Zum Beispiel während der ersten 3 Monate, nachdem ein neues Teammitglied dazugestoßen ist. Oder für besonders kritische Arbeitsergebnisse. Oder auch ganz einfach “immer”.
  • Legen Sie fest, wer Feedback geben soll. Sie könnten beispielsweise schon zu Beginn der Arbeit festlegen, wer später das Review durchführen soll. Die Arbeitsinhalte könnten von einer Person gereviewed werden oder von mehreren, es könnte immer die gleiche Person sein oder verschiedene, das Feedback könnte ad-hoc gegeben werden oder zu einem festgelegten Zeitpunkt.
  • Besprechen Sie im Team, welche Vorgehensweise für dieses Team passt. Es gibt hier kein “silver bullet”, sondern es hängt von der individuellen Situation ab. Dabei können Sie auch dafür sorgen, dass das gesamte Team die Sinnhaftigkeit von Peer Feedback versteht und dahintersteht – ansonsten beschränkt sich das Feedback auf ein belangloses “alles in Ordnung”.

Experimentieren Sie, probieren Sie unterschiedliche Ansätze aus. Wenn Sie mit einem sehr skeptischen Team arbeiten, nutzen Sie jede Gelegenheit, den Mehrwert von Feedback deutlich zu machen. Der Tenor sollte immer sein, dass unterschiedliche Sichtweisen dazu führen, dass das Ergebnis besser wird, als wenn einer alleine arbeitet. Exkurs: Evtl. kann es sinnvoll sein, genau diesen Punkt spielerisch zu beleuchten. Ein Augenöffner ist oft das sog. NASA Spiel.

Wenn Sie Peer-Feedback zu Arbeitsinhalten etabliert haben, ist der nächste Schritt gar nicht so schwer: Feedback zum Verhalten. Allerdings ist es hier auch für den Feedbackempfänger leichter, sich persönlich angegriffen zu fühlen. Insofern spielen hier das Vertrauen und die sichere Anwendung von Feedbackregeln eine noch größere Rolle. Ich halte es empfehlenswert, noch weitere Regeln im Team zu etablieren:

  • Sprechen Sie nicht übereinander, sondern miteinander. Heißt ganz konkret, dass Sie nicht über Personen sprechen, die nicht anwesend sind. Auch nicht in der Kaffeeküche.
  • Feedback zum Verhalten wird vorzugsweise in einem 4-Augen-Gespräch geführt. Dies hat zwei Vorteile: Erstens kann der Feedbackgeber direkt reagieren, wenn das Feedback nicht oder falsch verstanden wird. Für den Feedbackempfänger wird eine Situation vermieden, in der er von einer Gruppe quasi angeklagt wird.
  • Es kann ebenfalls sinnvoll sein, die Prime Direktive aus dem agilen Umfeld immer wieder in Erinnerung zu rufen: „Unabhängig davon was wir entdecken werden, verstehen und glauben wir aufrichtig, dass in der gegebenen Situation, mit dem verfügbaren Wissen und Ressourcen und unseren individuellen Fähigkeiten, jeder sein Bestes getan hat.“

Die Etablierung und Einhaltung dieser Regeln ist die eine Sache, auf die Sie Ihr Augenmerk richten sollten. Die andere Sache ist, dass Sie nicht in einen „Shuttle-Diplomatie“ Modus fallen dürfen. Ein Teammitglied A beschwert sich bei Ihnen über das Verhalten eines Kollegen B. Sie sprechen mit Kollege B und bringen das Ergebnis der Unterredung zu A. A ist nicht einverstanden usw. Ermuntern Sie Ihre Teammitglieder, Feedback zum Verhalten direkt anzusprechen und zu klären. Sie sollten maximal als Eskalationsinstanz zur Verfügung stehen.

Mit welchen Widerständen Sie rechnen müssen

Ist Peer Feedback ein Selbstläufer? Ganz klar nicht. Für die meisten Teams ist das eine deutliche Veränderung gegenüber dem Status Quo und wird damit zumindest skeptisch beäugt. Eine Auswahl von Vorbehalten gefälligst?

Feedback ist Aufgabe der Führungskraft. Dies ist ein Vorbehalt, den ich überwiegend in Unternehmen wahrnehme, in den selten Feedback gegeben wird. Hier wird Feedback üblicherweise nur im Rahmen eines jährlichen Beurteilungsgesprächs gegeben und daher mit diesem gleichgesetzt. In einer derartigen Situation könnten Sie erstens versuchen, die Gründe für Peer Feedback zu verdeutlichen (siehe oben). Zweitens könnten Sie deutlich machen, dass Feedback und Beurteilung getrennt sind. Schließlich könnten Sie durch ein regelmäßiges Feedback dem einzelnen Gespräch das Besondere nehmen und Feedback zu etwas ganz Normalem, zum Teil der Teamkultur, machen.

Ich kann doch nicht meinen Kollegen bewerten. Die platte Antwort wäre sicherlich „doch, kannst du“. Gerade am Anfang, wenn Sie also Peer Feedback etablieren möchten, hilft hier eher eine differenzierte Antwort mit Verweis auf Arbeitsinhalte, Verhalten und schließlich Leistung. Ergänzen könnten Sie die Antwort um den Hinweis, dass es nicht um eine (Be-) Wertung geht, sondern um den Austausch von unterschiedlichen Sichtweisen, den Diskurs und schließlich um eine kontinuierliche Verbesserung eines jedes Einzelnen und der Teamergebnisse.

Ich kann doch meinem Chef kein Feedback geben. In einem Projektteam kann es durchaus vorkommen, dass Mitarbeiter unterschiedlicher Hierarchien zusammenarbeiten. Wenn das notwendige Vertrauen vorhanden ist, spricht auch hier nichts gegen Peer Feedback. Vielleicht hilft es, sich auch zu vergegenwärtigen, dass die Qualitäten, die den Chef zum Chef gemacht haben, nicht notwendigerweise die Qualitäten sind, die im Projekt Anwendung finden. Auch Chefs sind nicht in allen Themen und Bereichen perfekt.

Umgang mit externen Mitarbeitern im Team. Können Sie einem externen Projektmitarbeiter genauso Feedback geben wie einem internen Mitarbeiter? Und andersrum: können Sie als externer Mitarbeiter einem internen Mitarbeiter Feedback geben? Wenn der externe Mitarbeiter Teil des Teams ist würde ich beide Fragen eindeutig bejahen. Im Falle einer distanzierten „Auftraggeber – Lieferanten – Beziehung“ eher nicht, hier scheint eine Zusammenarbeit auf Augenhöhe nicht gegeben zu sein. Insofern ist in diesem Fall auch der Begriff „Peer Feeback“ eher falsch.

Fazit

Peer Feedback ist aus meiner Sicht unheimlich wertvoll, um einerseits jeden einzelnen Mitarbeiter weiter zu entwickeln und andererseits auch die Ergebnisse des Projektteams zu verbessern. Peer Feedback lässt sich allerdings nicht von jetzt auf gleich verordnen. Es muss eine Feedbackkultur entstehen und dies erfordert Zeit, Experimente, Fehlschläge und Erfolge. Diese Reise beginnt mit Vertrauen. Vertrauen Sie Ihren Teammitgliedern. Missbrauchen Sie das Vertrauen Ihres Teams nicht. Machen Sie einen ersten Schritt hinsichtlich Peer Feedback und seien Sie sich darüber im Klaren, dass viele weitere Schritte folgen werden.

Project Leadership

Verstehen Ihre Stakeholder Ihre Vision nicht? Nutzen Sie ein Product Vision Board!

Veröffentlicht am

Ich bin ja ein großer Freund von Visionen. Nein, nicht die Art, bei denen man zum Arzt gehen sollte. Ich bin davon überzeugt, dass eine gute Unternehmensvision oder auch Projektvision dazu beitragen kann, die Mitarbeiter einerseits auf eine gemeinsame Sache einzuschwören und andererseits den Mitarbeitern viel Freiraum gewähren kann. In meinem Artikel Top-3-Gründe für eine Projektvision habe ich erläutert, warum eine Vision sinnvoll ist und in dem Artikel Wie sieht eine gute Projektvision aus beschrieben, wie eine gute Vision aussieht. 

Jetzt möchte ich diese Ideen aufgreifen und Ihnen eine andere, erweiterte Darstellungsform nahe bringen: das Product Vision Board (hier können Sie eine Vorlage herunterladen). Diese Idee ist nicht von mir, sondern von Roman Pichler 

Warum finde ich das Product Vision Board so toll? Weil es gleich zwei Probleme löst, über die ich immer wieder gestolpert bin: 

  1. Die Vision ist für Stakeholder oft zu “visionär” und nicht greifbar. Ja, bei der Erstellung der Vision machen Sie sich viele Gedanken. Sie wägen sorgfältig jedes Wort ab. Sie lassen jedes überflüssige Detail weg. Sie sprechen im Projektteam immer wieder über die Vision und wie sich aktuelle Entscheidungen aus der Vision ableiten lassen. Aber Ihre Stakeholder bekommen das nicht mit. Sie sind oft zu weit vom Projektgeschehen entfernt. Genau hier machen die Abschnitte zu Kunden, zum Produkt und zu den Zielen die Vision konkreter und greifbarer. 
  2. In der Projektarbeit bleibt es ja nicht bei der Vision. Sie untersuchen, welche Bedürfnisse Ihre Kunden haben. Sie versuchen, “typische” Kunden mit Hilfe von Personas zu beschreiben. Sie stellen fest, welche Herausforderungen Ihre Kunden aktuell bei der Befriedigung Ihrer Bedürfnisse haben. Sie entwickeln neue Lösungsideen, um die Kundenbedürfnisse besser zu befriedigen. Egal, ob Sie beispielsweise Design Thinking anwenden oder das Value Proposition Canvas, egal ob Sie Ihre Ergebnisse auf Papier oder digital dokumentieren – es wird viel. So viel, dass sich Ihre Stakeholder nicht immer die Zeit nehmen, Ihre Ergebnisse tatsächlich im Detail zu lesen und zu verstehen. Hier bietet das Product Vision Board die Möglichkeit, die Zusammenfassung “auf 30.000 Fuß Flughöhe” zu dokumentieren. 

Warum ist das jetzt gut? Nun, das Product Vision Board ermöglicht zum Einen eine bessere Diskussion mit Ihren Stakeholdern. Ihre Stakeholder sind ja oft zwischen zwei Extremen hin und her gerissen: einerseits haben sie meist wenig Zeit. Andererseits haben Sie oft viel Expertise und auch den Wunsch, Ihre Erfahrungen in das Projekt einfließen zu lassen. Das Product Vision Board ermöglicht nun eine inhaltliche Diskussion auf einem geeigneten Abstraktionslevel. 

Zum anderen dient das Product Vision Board als Richtschnur für Entscheidungen, indem es Sie und das gesamte Projektteam immer wieder erdet und auf den Kern des Projektes ausrichtet. Vielleicht ein paar Beispiele hierzu: 

  • Im Team überlegen Sie, wie Sie Ihre Kunden mit Echtzeitinformationen versorgen können. Ein Kollege schlägt vor, Push-Nachrichten auf dem Handy zu nutzen. Brilliant! Einfach umzusetzen und individuell! Bis Sie feststellen, dass Ihre Zielgruppe insbesondere aus “nicht-handy-affinen“ Menschen besteht. Das Product Vision Board sorgt dafür, dass Sie Ihre Zielgruppe immer im Blick haben! 
  • Ein Stakeholder schlägt vor, einen WLan-Access-Point in das Produkt zu integrieren. Die dafür notwendige Hardware ist eh schon vorhanden, insofern könne man das ja einfach mit abfrühstücken. Allerdings löst ein Access Point keines der relevanten Kundenbedürfnisse und trägt auch nicht zur Zielerreichung des Projektes bei. Das Product Vision Board sorgt dafür, dass Sie sich bei der Entwicklung nicht verzetteln. 
  • Im Team entwickeln Sie eine technische Lösung, die kostengünstig umzusetzen ist. Sowohl Sie als auch Ihre Stakeholder sind begeistert! Allerdings stellen Sie fest, dass Sie mit dieser Lösungsidee die Flexibilität für spätere Anpassungen verlieren – und eigentlich wollten Sie mit Ihrem Produkt flexibel auf sich ändernde Rahmenbedingungen reagieren können. Das Product Vision Board sorgt dafür, dass Sie die Kernfeatures Ihres Projektes nicht verwässern. 

Okay, ich muss zum Schluss noch etwas zurückrudern: Das Product Vision Board löst nicht alle Probleme, die im Projekt auftauchen können. Aber insbesondere für die Kommunikation und Erdung habe ich gute Erfahrungen gemacht. Kennen Sie das Product Vision Board? Welche Erfahrungen haben Sie gemacht? 

Project Leadership

Teams motivieren

Veröffentlicht am

Für die Zeitschrift health @ work habe ich eine Interview gegeben. In dem Interview drehte es sich grob um die folgenden Themen:

  • Unterschied zwischen einem Team und einer Gruppe von Mitarbeitern
  • Gemeinsame Vision
  • Jedes Teammitglied hat unterschiedliche Motivatoren
  • Experimente, ein Team zu motivieren

Viel Spaß beim Lesen!

Project Leadership

5 Tipps für eine erfolgreiche Zusammenarbeit in einem verteilten Team

Veröffentlicht am

Ich bin ein großer Freund von direkter Kommunikation. Ich kann an der Reaktion meines Gegenübers erkennen, ob er meine „Message“ verstanden hat. Ich kann nachfragen. Ich kann ihn bitten, die Message noch einmal zu wiederholen. Ich kann Kontext hinzufügen oder weitere Details ergänzen. Außerdem liebe ich Visualisierungen. Wie oft habe ich „Aha-Momente“ erlebt, wenn das Ergebnis einer Diskussion auf einem Flip Chart festgehalten wurde oder ein Arbeitsablauf auf einem Whiteboard skizziert wurde (siehe auch mein Beitrag Aufschreiben und visualisieren – eine Führungsaufgabe?). Das setzt natürlich voraus, dass alle Gesprächsteilnehmer auch das Flip Chart bzw. Whiteboard sehen können.

Insofern war ich einem verteilten Projektteam etwas skeptisch eingestellt. Die Vorteile waren klar: Einsatz von Mitarbeitern mit den benötigten Skills unabhängig vom Wohnort. Hohe Flexibilität des Zeiteinsatzes bei den Kollegen. Niedrige Reisekosten. Potenziell eine höhere Motivation durch niedrigere Reisetätigkeit. Insofern war die Frage weniger, ob wir in einem verteilten Team arbeiten, sondern wie wir die Zusammenarbeit optimal gestalten.

Inzwischen bin ich geläutert. Die Arbeit in einem verteilten Team kann wunderbar funktionieren und für jeden einzelnen und für das Projekt viele Vorteile bieten. Die folgenden Elemente tragen aus meiner Sicht dazu bei, dass verteilte Teams gut funktionieren.


Nutzen Sie eine Videokonferenzlösung mit guter Qualität und einfacher Bedienung.

Das erscheint auf den ersten Blick als Selbstverständlichkeit. In dem Moment, in dem eine direkte Kommunikation nicht möglich ist, wird sie durch Video ersetzt. Toolunterstützung gibt es wie Sand am Meer, beispielsweise Cisco WebEx oder Google Hangouts. Die Problematik liegt daher auch weniger in den Tools, sondern in den Details.

Benutzen Sie hochwertige Headsets oder Freisprecheinrichtungen

Rauschen in der Leitung, Störgeräusche, eine zu niedrige (oder zu hohe) Empfindlichkeit des Mikrophons machen jede Videokonferenz zur Qual. Probieren Sie es selbst aus, wie sich die Freisprecheinrichtung eines Handys, eines Computers, eines Festnetztelefons und eine hochwertige Konferenzspinne bzw. ein hochwertiges Headset anhören. Die Unterschiede sind gravierend!

Sorgen Sie für eine ruhige Umgebung während der Videokonferenz

Das beste Headset bringt nichts, wenn gleichzeitig 10 Kollegen lautstark diskutieren oder die Schnellstraße neben dem geöffneten Fenster verläuft. Diese Störgeräusche machen für alle anderen Teilnehmer die Konferenz schnell zur Qual.

Sorgen Sie für gute Beleuchtung Ihres Gesichts

Hochauflösende Kameras sind aktuell kein Problem, jeder PC, jede Videokonferenzlösung und jedes Handy bietet mehr als ausreichende Kameraauflösung. Achten Sie aber bitte darauf, dass die Gesichter der Teilnehmer ausreichend ausgeleuchtet sind und beispielsweise kein helles Fenster im Hintergrund die Belichtungsautomatik der Kamera in die Irre führt. Es ist wie bei Fotos: Bilder im Gegenlicht sind künstlerisch interessant, aber kaum zu erkennen.

Machen Sie die Nutzung des Videokonferenztools so einfach wie möglich

Ein Videoanruf sollte mit einem Klick möglich sein, bei einer Konferenz mit mehreren Teilnehmern könnte eine Integration in Ihre Kalender-Anwendung (z.B. Outlook) sinnvoll sein, damit Sie direkt beim Erstellen des Termins eine Videokonferenz hinzufügen können. Je umständlicher die Bedienung, desto größer die Hürde, eine Videokonferenz tatsächlich zu nutzen.

Passen Sie Ihre Methoden an

Es geht nicht darum, eine völlig neue Arbeitsweise zu erfinden, sondern die Essenz von bestimmten Vorgehensweisen auf eine andere Situation zu übertragen. Nehmen wir das Beispiel „Brainstorming“: Die Essenz des Brainstormings ist es, auf den Ideen anderer aufzubauen und sie weiter zu entwickeln. Insofern ist es hilfreich, diese Ideen für alle sichtbar zu dokumentieren. Hier kommt üblicherweise ein Flip Chart zum Einsatz oder Post-Its. In einem verteilten Team können Sie beispielsweise die Online-Version von Excel nutzen, damit alle gleichzeitig Ideen einbringen können. Auch das Gruppieren von Ideen ist problemlos. Und das Wichtigste: alle Teilnehmer können zu jeder Zeit alle Ideen sehen und darauf aufbauen. Ein anderes Beispiel: Planning Poker. Ja, die Poker-Karten sind schon sehr praktisch. Aber sind sie das Entscheidende beim Schätzen? Nein, es geht vielmehr um die unvoreingenommene Meinung eines jeden Einzelnen und den anschließenden Austausch. Hier gibt es inzwischen diverse Online-Tools, sie können aber auch wieder Excel nutzen und jeder schätzt auf Kommando in „seiner“ Spalte.

Nutzen Sie eine asynchrone Kommunikation – aber geschickt

Die bisherigen Tipps hatten im Wesentlichen das Ziel, eine direkte Kommunikation zwischen Menschen bestmöglich an verteilten Orten zu ermöglichen. Nicht immer ist eine direkte Kommunikation möglich und nicht immer ist sie sinnvoll. Vorhang auf für eine asynchrone Kommunikation, beispielsweise via Chat, Email oder Voicemail. Der Vorteil einer asynchronen Kommunikation ist recht offensichtlich: der Empfänger wird in seiner aktuellen Aufgabe nicht gestört und kann antworten, wenn es am Besten in seine Arbeitsgestaltung passt. Immer mal wieder artet diese Kommunikationsform allerdings in ein Ping-Pong aus, in dem Nachrichten 5, 10 oder 20 Mal hin und her geschickt werden. Damit dies nicht passiert, ist Kontext wichtig. Versetzen Sie sich in die Lage des Empfängers und versuchen Sie, alle für die Beantwortung der Frage oder Erfüllung der Aufgabe notwendigen Informationen beizusteuern. Das ist natürlich aufwändiger als „Hey Joe“ durch den Raum zu brüllen, aber es ermöglicht längere Phasen konzentrierten Arbeitens.

Suchen Sie disziplinierte, eigenständige Mitarbeiter

Durch die Arbeit an mehreren Standorten (unter Umständen auch Homeoffice) entfällt ein gewisses Maß an sozialem Druck in einer Gruppe. Es ist wenig praktikabel, die Arbeit in extrem kleine Teile zu schneiden und einmal pro Stunde nach der Fertigstellung zu fragen und die nächste Aufgabe zu verteilen. Mitarbeiter in verteilten Teams sollten in der Lage sein, ihren Arbeitstag diszipliniert und eigenständig zu gestalten, ohne dass jemand ständig Händchen halten muss.

Überprüfen Sie Ihre eigene Einstellung in Bezug auf verteilte Teams

Sehen Sie verteilte Teams als Chance, mit den besten Mitarbeitern zusammenzuarbeiten? Sehen Sie verteilte Teams als Chance, für jedes Teammitglied das individuell beste Arbeitsumfeld und die beste Arbeitsorganisation zu finden? Wenn ja, dann wird die Zusammenarbeit funktionieren. Wenn Sie allerdings ständig das Haar in der Suppe suchen, werden Sie auch ständig durch Probleme bestätigt und ausgebremst werden.

Vielleicht helfen Ihnen diese Tipps ja, mit Ihrem Team noch besser zusammenzuarbeiten oder den Schritt zu verteilten Teams zu versuchen. Welche Erfahrungen haben Sie gemacht und welche Tipps können Sie ergänzen?

Project Leadership

Wie wertvoll ist das Problem vs. wie teuer ist die Lösung

Veröffentlicht am

Ich frage mich immer wieder, warum Menschen im Geschäftsleben Dinge tun, die im Privatleben völlig absurd sind. Stellen Sie sich einmal folgende Situation vor: Eines Tages ärgern Sie sich über die horrenden Mietzahlungen für Ihre Wohnung. Ein eigenes Haus wäre doch viel angenehmer! Sie gehen zu einem Architekten und beschreiben ihm Ihr Traumhaus. Der Architekt erstellt einen ersten Entwurf. Sie diskutieren über einige Details, dann aktualisiert der Architekt den Entwurf. Er beauftragt einen Statiker für die Planung. Er beauftragt einen Makler, einen geeigneten Bauplatz zu suchen. Zufrieden präsentiert der Architekt die Ergebnisse. Sie stellen die Gretchenfrage: was kostet das Haus denn? Die Antwort „3,2 Millionen Euro“ schockiert Sie – nein, das können Sie sich auf keinen Fall leisten. Der Architekt, Statiker und Makler sind frustriert, weil sie absehbar für die Tonne gearbeitet haben. Absurd? Im Geschäftsleben passiert genau das.

Ein Fachbereichsmitarbeiter hat eine Idee, wie er ein Problem mit Hilfe von Technologie lösen könnte. Er bittet „die IT“ um eine Kostenschätzung. Basierend auf dem Zweizeiler in der Email ist keine Schätzung möglich. Es wird versucht, die Anforderungen zu detaillieren. Anschließend sitzen Projektleiter, Softwarearchitekt, Entwickler und Designer zusammen, um die Lösung zu entwerfen und zu schätzen. Die Antwort „320.000 Euro“ schockiert den Fachbereichsmitarbeiter – nein, damit ist kein sinnvoller business case möglich. Projektleiter, Softwarearchitekt, Entwickler und Designer sind frustriert, weil sie – mal wieder – absehbar für die Tonne gearbeitet haben.

Was also tun? Nun, wir müssen einfach ein paar Prinzipien aus dem Privatleben in das Geschäftsleben übertragen. Wenn Sie ein Haus kaufen wollen, haben Sie üblicherweise eine Vorstellung, was Sie sich leisten können bzw. was Ihnen das Haus wert ist. Basierend auf dieser Information geht dann die Suche bzw. der Entwurf los. Ein Haus für 200.000 Euro sieht anders aus als ein Haus für 500.000 Euro sieht anders aus als für 1.000.000 Euro. Aber alle Häuser lösen Ihr Problem und Sie vermeiden überflüssige Arbeit von Architekten, Statikern und Maklern.

Auch in der Softwareentwicklung sollten wir mit der Frage starten „was ist uns die Lösung dieses Problems wert“? Mit dieser Information können wir auch anders in die Diskussion mit der IT einsteigen. Wir fragen nicht „was kostet diese Lösung?“ sondern eher „wie sieht eine Lösung aus, die maximal X Euro kostet?“ Auf einmal nutzen wir die Kollegen nicht nur zum Schätzen, sondern auch für die kreative Phase der Lösungsentwicklung. Ja, der Ansatz hat auch Schattenseiten: der Fachbereichsmitarbeiter kann nicht mehr einen Zweizeiler an die IT losschießen, sondern er muss sich zuerst Gedanken über den Wert seines Problems machen. Um diese Gedanken zu strukturieren, habe ich vor einigen Jahren eine Vorlage entwickelt, welche die folgenden Eckpunkte beinhaltet:

  • Problem
  • Zielgruppe
  • Unternehmensvision & Strategie
  • Ziele der Problemlösung
  • Nutzen der Problemlösung

Welche Erfahrungen habe ich mit der Nutzung dieses Opportunity Assessments gemacht?

  • Es fällt vielen Mitarbeitern enorm schwer, zwischen Problembeschreibung und Lösungsidee zu unterscheiden
  • Ein Großteil der Opportunities betrifft „gefühlte“ Probleme ohne quantitative Evidenz
  • Ein Großteil der Opportunities zahlt nicht auf die Unternehmensstrategie ein
  • Die Variante, eine Lösung zu kaufen und nicht selbst zu entwickeln, wird systematisch vernachlässigt
  • Es fällt vielen Mitarbeitern enorm schwer, einen quantitativen Nutzen zu ermitteln

Zusammenfassend: Ein großer Teil der Opportunities sind schlicht überflüssig und eine Schätzung des Aufwands nicht notwendig. Es ist anfangs frustrierend für Fachbereichsmitarbeiter, langfristig führt es aber zu besseren Projektideen, einem höheren Mehrwert für das Unternehmen und weniger Frustration bei allen Mitarbeitern, sowohl in den Fachbereichen als auch in der IT.

Welche Erfahrungen haben Sie gemacht?