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?

Project Leadership

Wenn du tust, was du liebst, musst du nie mehr arbeiten

Veröffentlicht am

Wenn du tust, was du liebst, musst du nie mehr arbeiten. Das klingt toll, oder? Nie mehr arbeiten… herrlich! Arbeit hat irgendwie einen negativen Beigeschmack. Arbeit ist etwas, was wir tun müssen – und nicht wollen. Woran liegt das eigentlich?

Viele Unternehmen sehen Mitarbeiter als Teil einer Maschine. Das ist noch das tayloristische Weltbild vom Beginn des letzten Jahrhunderts. Das Teilchen der Maschine wird definiert und nennt sich Rollenbeschreibung. Mitarbeiter werden erst zu dem Zeitpunkt gesucht, wenn ein Teil der Maschine defekt ist oder fehlt. Diese Mitarbeiter werden basierend auf den für die Rolle notwendigen Fähigkeiten ausgewählt. Und schließlich: was nicht passt, wird passend gemacht – Mitarbeiter bekommen Schulungen, um Defizite in den Fähigkeiten auszugleichen.

Klingt dies wie ein bekanntes Szenario? Was passiert denn in einem derartigen Fall mit den Mitarbeitern? Nun, das ist recht einfach: Mitarbeiter fühlen sich als Teil einer Maschine. Mitarbeiter führen Tätigkeiten aus, die sie weder interessieren noch sonderlich gut können, die aber Bestandteil ihrer Rollenbeschreibung sind. Mitarbeiter sind unglücklich im Job, sie streben nach work-life-balance, weil Arbeit nicht Teil des Lebens ist.

Wenn du tust, was du liebst, musst du nie mehr arbeiten.

Die Antwort steht schon in diesem Satz. Sie sollten genau das tun, was sie lieben. Sie sollten etwas tun, was Ihren Neigungen und Stärken entspricht (siehe mein Artikel zu Ikigai). Wie finden Sie allerdings heraus, was Ihre Stärken sind?

In einem ersten Schritt würde ich einfach einen Moment nachdenken. Versuchen Sie, die folgenden Fragen zu beantworten:

  • Was kann ich gut? Beispielsweise eine überzeugende Vision für ein Projekt entwickeln. Oder mein Team motivieren. Oder ein Fachkonzept entwickeln.
  • Was fällt mir leicht? Beispielsweise den Vortänzer vor einer großen Gruppe machen. Oder neue Kollegen kennenlernen. Oder einen Projektplan entwerfen.
  • Was mache ich auch beim 10. Mal noch gerne? Beispielsweise den Projektplan überarbeiten. Oder ein neues Projektteam zusammenstellen.

Ich bin mir sicher, dass Sie intuitiv erahnen, was Ihre Stärken sind. Vielleicht fällt es Ihnen schwer, dies in Worte zu fassen, aber in Ihrem Inneren wissen Sie es.

In einem zweiten Schritt könnten Sie Andere um Ihre Sichtweise und Einschätzung bitten. Fragen Sie Ihren Mentor. Fragen Sie Ihren Coach. Fragen Sie Ihren Chef. Fragen Sie Ihre Mitarbeiter. Auch hier: diese Personen wissen vermutlich intuitiv, was Ihre Stärken sind. Je nach Erfahrung sind sie besser oder schlechter in der Lage, dies auch in Worte zu fassen.

In einem dritten Schritt könnten Sie den Gallup Strengths Finder nutzen. Dies ist ein Online-Fragebogen (hier gibt es den Fragebogen, hier Buch und Fragebogen), der Ihre Stärken identifiziert und priorisiert. Das Hilfsmittel wurde mir von einer Freundin empfohlen und ich war zugegebenermaßen etwas skeptisch. Für mich klang es eher wie Hokuspokus und weniger wie sinnvoll investiertes Geld. Das Ergebnis hat mich allerdings überzeugt. Nicht, weil ich bahnbrechende, neue Erkenntnisse gewonnen hätte. Sondern weil es mir geholfen hat, meine Stärken in Worte zu fassen und auf den Punkt zu bringen. Darin liegt aus meiner Sicht der größte Nutzen: Der Strengths Finder hilft Ihnen, Ihre Stärken in Worte zu fassen und zu priorisieren.

Was er nicht tut: er verändert weder Sie noch Ihre Arbeit. Das müssen Sie selber tun. Was machen Sie mit den Ergebnissen? Was machen Sie, nachdem Sie herausgefunden haben, was Ihre Stärken sind? Schmeißen Sie alles hin, kündigen Ihren Job und beginnen mit der Selbstverwirklichung? Wohl eher nicht. Die meisten von uns haben Verpflichtungen – sei es die Familie, sei es die Wohnung, sei es das finanzierte Auto – und müssen auf die eine oder andere Weise Geld verdienen. Dennoch können Sie Veränderungen einleiten.

  • Ändern Sie Ihre aktuelle Rolle. Schreiben Sie einmal auf, welche Tätigkeiten Sie in Ihrer aktuellen Rolle durchführen. Markieren Sie die Tätigkeiten, die Ihnen Spaß machen und die Sie besonders gut können mit einem Plus. Ein Minus gibt es für die Tätigkeiten, die Ihnen die Kraft rauben. Suchen Sie nach Möglichkeiten, wie Sie mehr von den „guten“ Aufgaben und weniger von den „schlechten“ Aufgaben übernehmen können.
  • Wechseln Sie in eine andere Rolle im gleichen Unternehmen. Vom Betrieb in die Entwicklung. Vom Entwickler zum Scrum Master. Vom Call Center in das Produktmanagement. Aber bitte tappen Sie nicht in die Falle, dass das Gras auf der anderen Seite des Zauns grüner ist. Sie sollten ein sehr klares Bild von Ihren Stärken haben und die möglicherweise damit verbundenen Tätigkeiten. Sie sollten außerdem kritisch hinterfragen, ob die andere Rolle tatsächlich Ihren Stärken entspricht. Sprechen Sie mit Kollegen, die dort aktuell arbeiten. Vereinbaren Sie eine Hospitation. Stellen Sie sicher, dass Sie wissen, was auf Sie zukommt.
  • Wechseln Sie in eine andere Rolle in einem anderen Unternehmen. Hier gilt das oben Gesagte analog mit dem Unterschied, dass es üblicherweise sehr viel schwieriger ist, ein objektives Bild über die zukünftigen Aufgaben zu bekommen. Eine kleine Anekdote: ich habe gute Erfahrungen mit extrem konkreten und extrem schwammigen Rollenbeschreibungen gemacht. Bei Ersteren wusste ich sehr genau, auf was ich mich einlasse. Bei Letzteren gab es ausreichend Möglichkeiten, die Rolle auf mich zuzuschneiden.
  • Gründen Sie Ihr eigenes Unternehmen. Sinnvollerweise sollte ich hinzufügen: „… und finden Sie Mitarbeiter, welche komplementäre Stärken mitbringen“. Ja, als Unternehmer sind Sie grundsätzlich erstmal frei in Ihren Entscheidungen, welche Tätigkeiten Sie durchführen. Aber manche Dinge müssen einfach gemacht werden – Stichwort Buchführung. Sorgen Sie dafür, dass Sie nicht alles alleine tun, ansonsten haben Sie mit Zitronen gehandelt.

Wenn du tust, was du liebst, musst du nie mehr arbeiten. Auf dem Weg dahin gibt es zwei entscheidende Schritte: Sie müssen überhaupt erst einmal wissen, was Ihre Stärke sind. Denken Sie nach, sprechen Sie mit Kollegen und nutzen Sie den Strengths Finder. Zweitens müssen Sie schrittweise Ihre Tätigkeiten entsprechend Ihrer Stärken verändern. Das Spektrum ist enorm, von einer Veränderung Ihrer aktuellen Rolle bis zur Selbstständigkeit.

Können auch Unternehmen etwas tun? Oder können Sie auch in Ihrer Rolle als Projektleiter etwas tun, damit sich Mitarbeiter nicht als Teil einer Maschine fühlen? Natürlich. Das Konzept „hire for attitude, train for skills“ geht in eine ähnliche Richtung. Hier kann ich Ihnen Abschnitt „Team“ meines Onlinekurses Project Leadership empfehlen.

Project Leadership

Output vs. Outcome

Veröffentlicht am

Da war er wieder. Dieser Satz, der mich zusammenzucken ließ. „Wir müssen uns ja entlasten.“ Obwohl ich nun schon einige Jahre im Projektgeschäft bin, überrascht es mich immer wieder, wie unterschiedlich die Sichtweisen sein können.

„Das Ziel des Projektes ist ein bestellbares Produkt“ vs. „Das Ziel des Projektes ist es, die Kundenzufriedenheit um 2 Prozentpunkte zu steigern (mit Hilfe eines Produktes)“.

„Wir sind fertig, wenn das Produkt bestellbar ist“ vs. „wir sind fertig, wenn die Kundenzufriedenheit um 2 Prozentpunkte gestiegen ist“.

Ich habe in einem älteren Artikel schon einmal die Notwendigkeit beschrieben, für den Projekterfolg unbedingt auch den Nutzen zu berücksichtigen. Ein Projekt, welches perfekt und wie geplant durchgeführt wurde, aber nicht den erwarteten Nutzen abliefert, ist aus Sicht des Unternehmens ein Fehlschlag. Dies gilt aber nicht nur für Projekte, sondern für alles, was wir im Projekt tun. Ich plädiere für eine andere, erweiterte Denkweise!

Lassen Sie uns die unterschiedlichen Denkweisen einmal systematisch am Beispiel des ÖPNV durchgehen.

 

Input / Einsatz

Was ist das?

Mit Einsatz bezeichnen wir alles, was wir in das Projekt hineinstecken. Dies sind üblicherweise Arbeitstage, Softwarelizenzen u.ä. In unserem ÖPNV Beispiel könnten wir festhalten, dass wir 1.000 Tage gearbeitet haben.

Was messe ich?

Die Messung des Inputs ist meist einfach – ich kann die Arbeitstage bzw. Stunden einfach aufschreiben und mit einem Stundensatz multiplizieren, Kosten für Lizenzen o.ä. sind ebenfalls direkt ersichtlich. Hilft uns die Messung des Inputs, um den Projekterfolg zu bestimmen? Aus meiner Sicht nein – es erinnert mich eher an das Bonmot „am Ende des Geldes ist noch ein Stück Monat übrig“.

Eine Anmerkung am Rande: Die meisten Entlohnungssysteme in Unternehmen orientieren sich am Input – Mitarbeiter werden nach ihrem Input (=Arbeitszeit) bezahlt, unabhängig davon, ob ihre Arbeit dem Unternehmen auch nützt. Warum? Weil der Input leicht zu messen ist.

Activities / Tätigkeiten

Wenn bestimmte Inputs vorhanden sind, dann können bestimmte Activities durchgeführt werden.

Was ist das?

Die Tätigkeiten im Projekt sind genau das: alles, was das Projektteam tut. Beispielsweise ein Fachdesign erstellen, Code produzieren, Tests durchführen. In unserem ÖPNV Beispiel könnten wir festhalten, dass wir für eine Anwendung entwickelt und getestet haben.

Was messe ich?

Auch die Tätigkeiten sind leicht zu erfassen – Sie können das Team einfach beobachten oder nachfragen. Hilft die Messung der Tätigkeiten? Wieder nein – Sie wissen nicht, ob die Tätigkeiten überhaupt abgeschlossen sind.

Output / Ergebnis

Wenn bestimmte Activities durchgeführt werden, dann erwarte ich einen bestimmten Output.

Was ist das?

Der Output (Projektergebnis, deliverables) beschreibt die Dinge, die nach der Projektdurchführung vorhanden sind, beispielsweise eine funktionsfähige Anwendung (das Was). In unserem Beispiel könnten wir einen Anzeiger für Bushaltestellen entwickelt haben, der die Ankunft des nächsten Buses anzeigt.

Was messe ich?

Ich messe die konkreten, abzählbaren Projektergebnisse. Diese werden üblicherweise zu Projektbeginn vereinbart. Die Erreichung der Projektergebnisse liegt vollständig in der Hand des Projektteams und ist leicht (und objektiv) zu überprüfen.

Outcome / (Aus-)Wirkung

Wenn ein Output vorliegt, dann kann dies zu einem Outcome führen.

Was ist das?

Die Auswirkung beschreibt üblicherweise den Nutzen des Projektes (das Warum). In unserem Beispiel könnte ein Outcome eine Verbesserung der Kundenzufriedenheit sein.

Was messe ich?

Jetzt wird etwas kniffliger… Das Outcome ist erstens nicht immer leicht zu messen. Zweitens ist oft nur eine subjektive Einschätzung möglich. Drittens kann zwischen Herstellung des Outputs und Eintritt des Outcomes recht viel Zeit liegen. Viertens besteht nicht immer ein kausale 1-zu-1 Beziehung zwischen Output und Outcome (Ausfälle der Busflotte zieht die Kundenzufriedenheit nach unten, unabhängig von den Anzeigern).

Impact / (Ein-) Wirkung

Wenn es ein Outcome gibt, kann dies langfristig zu einem Impact führen.

Was ist das?

Impact beschreibt eine Wirkung über die eigentliche Zielgruppe hinaus. In unserem Beispiel könnte die höhere Kundenzufriedenheit dazu führen, dass noch mehr Menschen den ÖPNV nutzen und die Schadstoffbelastung sinkt.

Erkenntnisse

  1. Die dargestellte Kausalkette sollte uns bewusst sein. Dies gilt insbesondere für die Definition eines Projektziels – verspreche ich einen Output oder ein Outcome.
  2. Es ist problemlos möglich, einen Output ohne Outcome zu erreichen. Daher mein eingangs erwähntes „Zusammenzucken“.
  3. Es ist problemlos möglich, ein bestimmtes Outcome mit unterschiedlichen Outputs zu erreichen. Die Festlegung auf einen bestimmten Output (Deliverables) zu Projektbeginn verbaut unter Umständen einfachere Lösungen, die erst im Projektverlauf sichtbar werden (siehe auch mein Artikel zu Value Trees).
  4. Ohne Outcome gibt es keine Notwendigkeit für Output. Wenn sich die Kundenzufriedenheit durch Busanzeiger nicht erhöht, brauche ich keine Busanzeiger.
  5. Die Kausalkette gilt in unterschiedlichen Dimensionen, nicht nur für Projekte. Ich kann das Feature „Zahlung mit PayPal“ umsetzen (output) oder die adressierbare Kundengruppe um 12% erhöhen (outcome). Ich kann den Sprint 14 erfolgreich abschließen (output) oder eine Designvariante validieren (outcome). Ich kann eine User Story abschließen (output) oder den Aufruf der PayPal-Zahlungsübersicht um 70% schneller machen (outcome).

Ich plädiere für eine andere Denkweise! Der Fokus auf Outcomes führt vielleicht dazu, dass sich die geplanten Projektergebnisse verändern. Langfristig führt es aber zu erfolgreicheren Projekten und glücklicheren Kunden.