Project Leadership

Ein Jeder kehre vor der eigenen Haustür oder auch: wie kriege ich andere dazu, offensichtliche Probleme zu lösen

Veröffentlicht am

Ich erlebe es immer wieder, dass Kollegen sich wundern, warum „offensichtliche“ Probleme nicht gelöst werden (und ich will mich da gar nicht ausnehmen). Wir haben zu viele Fehler – warum beheben wir diese nicht? Unsere Usability ist schlechter als es unsere Kunden erwarten – warum verbessern wir diese nicht? Wir haben zu viele manuelle Prozessschritte – warum investieren wir nicht in Automatisierung und Schnittstellen?

In der Regel hat jeder dieser Kollegen recht. Es existiert tatsächlich ein Problem. In der Regel gibt es in Unternehmen aber auch genau eine Sache im Überfluss: Probleme (oder neudeutsch Herausforderungen). Insofern stellt sich weniger die Frage, ob ein Problem gelöst wird, sondern in welcher Reihenfolge die Probleme gelöst werden. Wenn das eigene Problem nicht gelöst wird, dann liegt es üblicherweise an einem der folgenden Punkte:

  • Das Problem passt nicht in die allgemeine Großwetterlage. Wenn das gesamte Unternehmen auf Kostensenkung fokussiert, hat es ein Vorschlag zur Verbesserung der Kundenzufriedenheit schwer. Wenn das Unternehmen nach Innovationen giert, sind Probleme (und Lösungen) zur Kostensenkung weniger gefragt. Sorgen Sie dafür, dass Sie die Großwetterlage des Unternehmens und Ihres Ansprechpartners kennen. Überlegen Sie, ob die Lösung Ihres Problems zur allgemeinen Richtung passt bzw. machen Sie deutlich, wie die Problemlösung die allgemeine Richtung unterstützt.
  • Das Problem ist im Vergleich zu anderen Problemen vernachlässigbar. Der Top-Seller steht 4 Wochen vor Weihnachten noch nicht in den Regalen der Händler. Die Verpackung des Top-Sellers könnte mit weniger Material auskommen. Welches Problem lösen Sie zuerst? Sorgen Sie dafür, dass Sie ein möglichst vollständiges Bild aller Probleme bekommen, welche das Unternehmen oder Ihren Ansprechpartner beschäftigen. Arbeiten Sie an den High-Impact-Problemen.
  • Die Dimension des Problems ist nicht transparent. Sind 1000 Fehler schlimm oder nicht? Welche Auswirkung hat die Behebung von 1000 Fehlern auf Umsatz, Kosten, Kundenzufriedenheit oder Reputation? Welche Auswirkung hat die Fortführung manueller Arbeiten? Sorgen Sie dafür, dass Ihr Gegenüber die Dimension des Problems in den für ihn relevanten Metriken versteht. Ihr Gegenüber denkt in Umsatz? Beschreiben Sie die Umsatzauswirkungen. Ihr Gegenüber denkt in Time to Market? Beschreiben Sie die Konsequenzen des Problems auf Time to Market. Auf diese Weise ermöglichen Sie eine Vergleichbarkeit von Optionen.

Wenn wir davon ausgehen, dass unsere Gegenüber weder faul noch dumm sind, sondern – genau wie wir – das Beste für das Unternehmen erreichen wollen, dann sollten wir die obigen Punkte berücksichtigen. Damit erreichen wir entweder, dass unser Problem gelöst wird oder aber, dass uns bewusst ist, warum es zum aktuellen Zeitpunkt nicht gelöst wird.


Ich hoffe, Ihnen hat dieser Artikel gefallen und Sie haben einige Anregungen für die tägliche Arbeit mitgenommen. Es gibt eine Sache, die Sie für mich tun könnten: Teilen Sie diesen Artikel mit Ihren Kollegen und Bekannten. Ich möchte möglichst viele Menschen erreichen!


Hier gibt es noch eine Videoversion des Beitrags:

Project Leadership

Wer ist verantwortlich? Oder auch: Wer hat Schuld?

Veröffentlicht am

In den letzten Monaten bin ich immer wieder mit der Frage konfrontiert worden, wer verantwortlich sei. Es handelte sich dabei um agile Sortwareentwicklungsprojekte in Organisationen, die noch nicht „geübt“ mit agilen Vorgehensweisen war. Hintergrund waren in der Regel Probleme in der Projektdurchführung (z.B. langsamerer Fortschritt als erwartet) und die Suche nach dem Äquivalent eines Projektleiters. 

Die übliche Antwort erfolgte dann im Sinne „der Product Owner ist verantwortlich dafür, dass das Richtige gebaut wird. Der Scrum Master ist verantwortlich für die Effizienz des Teams. Das Entwicklungsteam ist für die Herstellung und Qualität verantwortlich“. Aber die Antwort befriedigte nicht den Fragenden. Wen muss ich denn jetzt in den Arsch treten, damit es schneller geht? 

Mal abgesehen von grundsätzlichen Punkten wie Führungskultur zeigt sich hier ein Phänomen, was ich „Illusion von Kontrolle“ nennen möchte. Es existiert die Illusion, dass eine starke Person (der Projektleiter) die Kontrolle über das Projekt hat. Das war in klassischen Projektvorgehensweisen nicht so und ist im agilen Kontext weiterhin nicht der Fall. Lassen Sie uns mal typische Probleme im Projektalltag ansehen. 

Der Projektfortschritt ist langsamer als erwartet, ein Meilenstein ist in Gefahr. Ein Klassiker. Was sind denkbare Maßnahmen? 

  • Ein trotziges Aufstampfen „das muss aber funktionieren. Die Faulenzer müssen mal loslegen. Arme und Beine bilden rotierende Scheiben ohne Bodenkontakt“. Hilft das? Natürlich nicht. 
    • In der Regel ist das Projektteam motiviert und möchte ein erfolgreiches Projekt abliefern. Beleidigungen und Unterstellungen bewirken eher das Gegenteil. 
    • Sind tatsächlich Faulenzer im Team, werden diese durch bloßes Aufstampfen nicht zu Top-Performern. Hier muss an den Ursachen gearbeitet werden, was aber keine kurzfristigen Erfolge zeigen wird. Ob diese Aufgaben ein Projektleiter oder ein Scrum Master übernimmt, ist beliebig. 
    • Maßnahmen wie Überstunden oder Wochenendarbeit sind nicht nachhaltig. Es besteht die Gefahr, dass das Team ausbrennt und die Produktivität und Qualität langfristig geringer wird. 
  • „Wir müssen das Team vergrößern“. Eine Maßnahme, bei deren Wirksamkeit und Umsetzbarkeit ich Zweifel habe. 
    • Adding more resources to a late project makes it later. Brooks Gesetz ist sicherlich sehr pointiert formuliert. Nichtsdestotrotz ist „mehr Leute“ nicht immer eine geeignete Lösung und schon gar keine einfache Lösung. Es müssen diverse Dinge bedacht werden, z.B. die Projektphase, die Teamzusammensetzung, Komplexität der Software, Know-How der neuen Teammitglieder, Kommunikationsarten, Teilbarkeit der Aufgaben usw.  
    • Sofern man von der Wirksamkeit überzeugt ist, stellt sich ja die nächste Frage: wo kommen diese Menschen her? Wir reden ja nicht über Bleistifte, die man im Katalog bestellen kann, sondern über Menschen. Hier ist ein Projektleiter in keiner besseren Position als ein agiles Team. 
      • Es werden interne Mitarbeiter gesucht. Üblicherweise sitzen nicht Heerscharen von fähigen Mitarbeitern däumchendrehend auf der Bank. Diese müssen also aus anderen Projekten abgezogen werden. Dies kann der Projektleiter in derRegel nicht entscheiden, die Entscheidung über die Priorisierung mehrerer Projekte trifft eine Programmleitung, ein Portfoliomanager, eine Geschäftsführung etc. 
      • Es werden externe Mitarbeiter gesucht. Häufig hat ein Projektleiter nur ein fiktives Projektbudget. Sobald ein externer Mittelabfluss notwendig ist, ist eine Führungskraft mit echter Budgetverantwortung involviert, welche die Entscheidung trifft. 
  • Wir müssen den Scope reduzieren. Eine Entscheidung, die ein Projektleiter äußerst selten trifft, ein Product Owner hingegen sehr wohl. 
    • Wird ein Reduzierung des Scopes notwendig, unterbreitet der Projektleiter üblicherweise einen Vorschlag für den Auftraggeber oder Lenkungsausschuss. Dieser trifft dann die endgültige Entscheidung. 
    • Ein Product Owner mit weitreichendem Mandat kann diese Entscheidung selber treffen. Aber selbst ein PO als „Erfüllungsgehilfe“ des Auftraggebers kann die Entscheidung einfacher herbeiführen, da die wichtigsten Scope-Elemente bereits umgesetzt sind. 

Die Kosten laufen aus dem Ruder. Das Projektbudget reicht nicht. Hierfür kann es – bei Softwareentwicklungsprojekten – aus meiner Sicht nur drei Gründe geben.  

  • Möglichkeit eins: Die Projektdauer ist länger als erwartet, die höheren Kosten sind eine Konsequenz daraus. Dann siehe oben.  
  • Möglichkeit zwei: das Projektteam ist größer als erwartet. Siehe oben.  
  • Möglichkeit drei: das Projektteam ist zu teuer, d.h. der Anteil interne / externe Mitarbeiter ist anders als geplant oder die Tagessätze der externen Mitarbeiter sind höher als geplant. Eine Kostensteigerung aus diesen Gründen kann ja eigentlich nicht überraschend sein, sondern ließe sich zu Projektbeginn leicht ausrechnen. Aber sei es drum, leicht und schnell lässt sich diese Situation auch nicht ändern. Ein Ersatz externer Mitarbeiter durch interne dauert ca. 3-9 Monate und lässt sich nur unter Mithilfe der Linienorganisation stemmen. Ein Ersatz externer Mitarbeiter durch „günstigere“ funktioniert tendenziell schneller, aber auch hier ist der Handlungsspielraum eines Projektleiters häufig eingeschränkt. 

Das Projekt liefert nicht das erwartete Ergebnis. Dies ist aus meiner Sicht der GAU. Und es betrifft insbesondere Projekte, die mit klassischen Vorgehensweisen durchgeführt werden. Hier ist der Zeitraum zwischen Anforderungsformulierung und Sichtbarkeit der Ergebnisse besonders lang. Und die Gründe hierfür sind für einen Projektleiter auch nur schwer zu kontrollieren. 

  • Die Anforderungen sind unvollständig. Dieses Problem versucht man häufig, durch Abnahmen der Anforderungsdokumentation oder des Fachdesigns in den Griff zu bekommen. Damit ist man „formal“ aus dem Schneider, aber der Anforderer hat immer noch das Problem, dass die Anforderungen nur teilweise umgesetzt sind. 
  • Die Anforderungen haben sich geändert. Was heute richtig ist, kann in 12 Monaten schon wieder anders sein. Als Projektleiter hat man wenig Möglichkeiten, diese Problematik zu lösen. 
  • In jedem Fall kommt man um eine schwierige Entscheidung nicht herum. Das Projekt kann eingestellt werden oder es kann nachgearbeitet werden. Beide Entscheidungen trifft selten der Projektleiter, sondern entweder der Auftraggeber oder der Lenkungsausschuss.  

Diese Beispiele zeigen aus meiner Sicht recht deutlich, dass ein Projektleiter ein Projekt in Schieflage nicht alleine retten kann. Er ist eventuell alleine verantwortlich, aber für die Lösung gravierender Probleme ist er auf die Mitwirkung anderer angewiesen. Es gibt eine Illusion von Kontrolle. Allerdings ist es sehr viel einfacher, einen Schuldigen zu finden… 

Mich interessiert brennend Ihre Sicht auf dieses Thema!


Ich hoffe, Ihnen hat dieser Artikel gefallen und Sie haben einige Anregungen für die tägliche Arbeit mitgenommen. Es gibt eine Sache, die Sie für mich tun könnten: Teilen Sie diesen Artikel mit Ihren Kollegen und Bekannten. Ich möchte möglichst viele Menschen erreichen!


Vertiefende Beiträge: 

 

Project Leadership

Wie füllen Sie Ihre Rolle als Projektleiter oder Product Owner?

Veröffentlicht am

Ich kann mich noch gut an mein erstes Projekt als Projektleiter erinnern: Relaunch bucher-reisen.de. Eine coole Geschichte mit einem tollen Ergebnis. Ich erinnere mich an dieses Projekt allerdings weniger wegen des tollen Ergebnisses, sondern vielmehr wegen meiner damaligen Auffassung der Rolle des Projektleiters. Tatsächlich war ich eher ein Projektkoordinator als ein Projektleiter. Ich traf keine Entscheidungen, sondern bereitete Optionen auf und lies sie entscheiden. „Am Ende war es mir persönlich ja egal, wie die Entscheidung ausfiel“.

Anschließend habe ich nie mehr so gearbeitet. Es war fürchterlich – die totale Abhängigkeit von Anderen. Seitdem mache ich die Projektziele zu meinen eigenen Zielen und entscheide. Nach bestem Wissen und Gewissen.

Ich erlebe aber auch andere Vorgehensweisen. Ich erlebe Projektleiter (insbesondere von IT Dienstleistern), die schwachsinnige Anforderungen umsetzen. „Ja, ich weiß, dass diese Anforderung schwachsinnig ist, aber der Auftraggeber will es unbedingt so haben“. Ich erlebe Projektleiter, die keine Kontrolle über ihre Projektmitarbeiter haben. „Ja, ich würde ja gerne planen und steuern, aber jeder Plan ist schon morgen falsch, weil meine Annahmen zur Ressourcenverfügbarkeit morgen von der Programmleitung über den Haufen geschmissen werden“. Ich erlebe Product Owner, deren Entscheidungen, ein Feature nicht umzusetzen, vom Auftraggeber overruled werden.

Welchen Typ von Projektleiter brauchen wir? Einen Leiter, der selber denkt und selber entscheidet? Oder einen Koordinator, der gewissenhaft ausführt?

Mich interessiert brennend Ihre Sicht auf dieses Thema!


Ich hoffe, Ihnen hat dieser Artikel gefallen und Sie haben einige Anregungen für die tägliche Arbeit mitgenommen. Es gibt eine Sache, die Sie für mich tun könnten: Teilen Sie diesen Artikel mit Ihren Kollegen und Bekannten. Ich möchte möglichst viele Menschen erreichen!


Hier gibt es noch eine Videoversion des Beitrags:

Project Leadership

50% aller Projekte scheitern – aber wie messen wir eigentlich den Projekterfolg?

Veröffentlicht am

Stellen Sie sich bitte einmal folgende Situation vor. Sie haben die Frau (oder den Mann) Ihrer Träume gefunden und wollen heute das erste Mal ausgehen. Sie überlegen, zuerst in ein Restaurant zu gehen und anschließend ein paar Cocktails zu trinken. Sie rechnen damit, ca. 80€ auszugeben und gegen Mitternacht zu Hause zu sein.

Szenario 1: Das Essen ist wunderbar aber die Unterhaltung stockt immer wieder. Sie gehen mit Ihrer Traumfrau in die angesagteste Cocktailbar der Stadt aber auch hier herrscht immer wieder verlegenes Schweigen. Gegen 23:45 verabschieden Sie sich höflich. Auf der Rückfahrt kalkulieren Sie, dass Sie tatsächlich knapp 80€ ausgegeben haben.

Szenario 2: Das Essen ist wunderbar und Sie finden sofort gemeinsame Themen. Sie reden und reden und lachen und lachen. Eine Geschichte jagt die nächste. Nach vielen Stunden sind Sie die letzten Gäste im Restaurant und werden hinauskomplimentiert. Sie setzen die Unterhaltung in der Cocktailbar fort, der Alkohol befeuert die überschwängliche Stimmung. Gegen drei Uhr morgens verabschieden Sie sich, Ihre Traumfrau gibt Ihnen einen Kuss und bittet Sie, morgen anzurufen. Auf der Rückfahrt stellen Sie fest, dass Sie weit über 200€ ausgegeben haben.

In welchem Szenario sind Sie erfolgreich? Aus meiner Sicht Szenario 2: Sie sind Ihrer Traumfrau ein Stück näher gekommen. Dabei spielt es eine untergeordnete Rolle, dass der Abend anders gelaufen ist als geplant.

Vor ein paar Jahren führte ich ein Projekt, um eine neue Zahlart einzuführen. Hinsichtlich der Projektdurchführung waren wir erfolgreich. Aber die Akzeptanz der Zahlart blieb weit hinter den Erwartungen zurück und die prognostizierten Umsatzsteigerungen traten nicht ein.

In einem anderen Projekt benötigten wir ein Jahr länger als geplant und die Kosten lagen mehrere Millionen über dem Budget. Trotzdem war das Projekt aus Sicht des Unternehmens ein Erfolg, weil die realisierten Kosteneinsparungen die Projektkosten locker kompensierten.

Wie messen wir den Erfolg unserer Projekte? Ist unser Projekt erfolgreich, wenn wir „in Time, in Scope und in Budget“ abliefern? Oder sind wir erfolgreich, wenn wir den erwarteten Nutzen tatsächlich erzielen?

Aus meiner Sicht gibt es hier kein entweder … oder, sondern ein sowohl … als auch. Wir müssen einerseits die Lieferergebnisse erwartungsgemäß herstellen und andererseits auch den Nutzen erzielen. Die folgende Grafik veranschaulicht dies.

 

Welche Aufgaben stecken denn im rechten Teil der Grafik? Eine ganze Menge.

Vor dem Projektstart

  • Definition des Projektziels. Beispielsweise Reduzierung der Kosten im Call Center um 30% innerhalb von 12 Monaten.
  • Identifikation möglicher Werttreiber. Dies können in diesem Beispiel z.B. Reduzierung der Anruflänge, Reduzierung der Anzahl der Anrufe, Outsourcing, Automatisierung durch Chatbots o.ä. sein.
  • Auswahl initialer Werttreiber und Identifikation von Maßnahmen. Beispielsweise Reduzierung der Anruflänge durch Steigerung der Systemperformance. Dies ist gleichzeitig der initiale Scope des Projektes.
  • Erstellung eines initialen Business Cases.

Während des Projektes

  • Identifikation und Management der Wertrisiken (value risks). Dies sind die Risiken, deren Eintreten dafür sorgen kann, dass der erwartete Nutzen nicht eintritt. Dieser Punkt wird häufig vernachlässigt, daher möchte ich etwas detaillierter darauf eingehen.
    • Wenn ein Risiko besteht, dass Kunden das Projektergebnis nicht akzeptieren, dann helfen Methoden wie Design Thinking oder Lean Startup sowie eine interaktive Vorgehensweise. Ziel ist, mit möglichst geringem Aufwand herauszufinden, ob potenzielle Kunden das Projektergebnis nutzen würden und wie hoch ihre Zahlungsbereitschaft ist.
    • Wenn ein Risiko besteht, dass das Projektergebnis von internen Anwendern nicht genutzt wird, dann könnten Kommunikationsmaßnahmen, Workshops, Key-User-Konzepte o.ä. helfen.
    • Wenn ein Risiko besteht, dass Partner das Projektergebnis nicht nutzen, dann könnten Sie die Vertragsgestaltung überprüfen und den Nutzen für den Partner herausstellen.
    • Entscheidend ist, dass Sie die Wertrisiken möglichst früh adressieren. Die beste Projektdurchführung hilft Ihnen nichts, wenn das Projekt nicht den erwarteten Nutzen bringt.
  • Bestätigung oder Anpassung von Werttreibern und/oder Maßnahmen, d.h. Veränderung des Scopes. Dieser Punkt ist ja eigentlich ein „no-go“ in klassischen Projekten. Sofern Sie allerdings die Wertrisiken adressieren, ergibt sich mit großer Wahrscheinlichkeit eine Veränderung.

Was heißt dies eigentlich für Ihre Rolle als Projektleiter? Ich kenne viele Projektleiter, die ausschließlich den linken Teil der Grafik als ihre Aufgabe ansehen. Dies ist das klassische Szenario. Der initiale Scope und Business Case wird von Auftraggeber definiert, Scopeänderungen werden vom Lenkungsausschuss beschlossen. Dieses Szenario geht davon aus, dass die Annahmen hinter den Werttreibern und Maßnahmen richtig sind und nicht verändert werden müssen.

Dies ist aus meiner Sicht immer seltener der Fall. Das Unternehmensumfeld wird immer schnelllebiger, das Kundenverhalten immer weniger vorhersagbar. Einmal getroffene Annahmen hinsichtlich Werttreibern und Maßnahmen sollten kontinuierlich überprüft werden. Daher sollte es einen weiteren (fachlichen) Projektleiter geben, der die Aufgaben im „rechten“ Teil der Grafik wahrnimmt. Er ist dafür verantwortlich, dass der erwartete Nutzen (Wert) tatsächlich erzielt wird. Diese Aufgabe ähnelt insofern stark der Rolle des Product Owners in Scrum.

Insofern sollten wir den Projekterfolg sowohl an der Qualität der Projektdurchführung messen als auch an der Erzielung des erwarteten Nutzens.


Ich hoffe, Ihnen hat dieser Artikel gefallen und Sie haben einige Anregungen für die tägliche Arbeit mitgenommen. Es gibt eine Sache, die Sie für mich tun könnten: Teilen Sie diesen Artikel mit Ihren Kollegen und Bekannten. Ich möchte möglichst viele Menschen erreichen!


Hier gibt es noch eine Videoversion des Beitrags:

Project Leadership

Brainstorming 2.0 – Wie Sie zu mehr und besseren Ergebnissen kommen

Veröffentlicht am

Sicherlich kennen Sie diese Situation: Sie entdecken ein Problem und wollen ihr Team in die Problemlösung einbinden. Sie laden zu einer Brainstorming Session ein, schildern kurz die Problematik und bitten um Ideen. Die ersten Kollegen platzen mit Ideen in den Raum, diese werden aufgegriffen und verfeinert. Wenn Sie gut sind, dokumentieren Sie die Ideen und gruppieren diese. Am Ende stellen Sie die Frage: „okay, und welche Lösungsidee setzen wir um?“. Und auch hier finden sich ein paar Kollegen, die Ihre Meinung äußern.

So weit, so gut und bekannt. Diese Art der Ideensammlung entstand in den 50er Jahren des letzten Jahrhunderts und die damit verbundenen Vorgehensweisen und Regeln (viele Ideen, wilde Ideen, keine initiale Kritik an den Ideen, auf den Ideen anderer aufbauen) sind den meisten Berufstätigen in Fleisch und Blut übergegangen und werden nicht hinterfragt.

Das ist schlecht. Denn es gibt bessere Vorgehensweisen.

Die offene Diskussion in der Gruppe hat zwei gravierende Nachteile:

  • Die Ideen tendieren dazu, zu konvergieren. Sobald eine Idee geäußert wurde, beeinflusst diese Idee das Denken der Teilnehmer.
  • Ideen von stillen, introvertierten Personen werden leicht übersehen. Meinungsstarke Teilnehmer dominieren die Gruppe und die entstehenden Ideen.

Vor diesem Hintergrund wurden weitere Methoden entwickelt, wie z.B. die 6-3-5 Methode. Diese hat aber aus meiner Sicht den Nachteil, dass sie deutlich aufwändiger in der Vorbereitung und Durchführung ist. Ich habe gute Erfahrung mit Brainwriting und Punkt-Priorisierung gemacht.

Beim Brainwriting erfolgt die Einleitung durch den Moderator analog zum Brainstorming. Anschließend schreibt jedoch jeder Teilnehmer so viele Ideen wie möglich individuell auf. Post-Its eignen sich hervorragend. Je nach Problemstellung kann auch eine Visualisierung hilfreich sein, z.B. bei Prozessveränderungen oder Anwendungsworkflows. Die Zeit für die individuelle Arbeit sollte zwischen 3 und 10 Minuten liegen (eher kürzer als länger). Anschließend werden die Ergebnisse einzeln vorgestellt, ein gemeinsames Verständnis hergestellt und gruppiert.

Die Punkt-Priorisierung dient anschließend dazu, die umzusetzende Idee auszuwählen. Definieren Sie Kriterien für die Auswahl, z.B. Umsatzrelevanz, Umsetzungsgeschwindigkeit etc. Geben Sie Ihrem Team 2-5 Minuten Zeit, über die Ideen nachzudenken und den eigenen Favoriten auszuwählen. Wichtig: in dieser Phase sollte nicht diskutiert werden. Bitten Sie jedes Teammitglied, einen Punkt auf die gewählte Idee zu malen oder kleben. Bei sehr vielen Ideen können Sie auch zwei oder drei Punkte vergeben. Anschließend haben Sie eine dokumentierte Einschätzung, welche Idee umgesetzt werden sollte.

Aus meiner Sicht sind beide Methoden leicht zu erklären, schnell umzusetzen und liefern gute Ergebnisse. Probieren Sie es doch einmal aus!

Übrigens: Brainwriting (und Brainstorming) kann nicht nur zur Lösungsfindung eingesetzt werden, sondern auch zur Problemfindung! Das Bild des „double diamonds“ hilft mir regelmäßig, schon früh das Team einzubinden. Wichtiger als die richtige Lösung ist es, das richtige Problem zu lösen.

Hier gibt es noch eine Videoversion des Beitrags:

Project Leadership

Es ist hart, den besten Mitarbeiter zu verlieren

Veröffentlicht am

Richtig hart ist es, wenn er nicht nur das Projekt wechselt, sondern das Unternehmen verlässt. Und genau hier verstehe ich viele Projektleiter und Führungskräfte nicht.

Jeder kennt einen High Performer. Der Kollege, der qualitativ außerordentliche Ergebnisse liefert. Der Kollege, auf den Verlass ist. Der Kollege, der Sonderaufträge gerne annimmt und brillant umsetzt. Der Kollege, der das Projekt quasi im Alleingang rettet. Der Kollege, der aus Stroh Gold macht.

Doch viele vernachlässigen die Karriereentwicklung ihres High Performers (siehe hierzu auch meinen Artikel Woran du erkennst, dass du in einer toxischen Umgebung arbeitest). Dies kann aus den unterschiedlichsten Gründen passieren. Manche wollen ihn nicht aus ihrem Einflussgebiet entlassen. Manche vergessen es schlicht. Manche finden „gerade jetzt“ nicht die Zeit dazu. Was auch immer die Gründe, am Ende ist der High Performer frustriert und verlässt das Unternehmen.

Dabei ist die Karriereentwicklung eigentlich relativ leicht. Ich habe mit folgenden Bausteinen gute Erfahrungen gemacht:

  • Stellen Sie sicher, dass Hygienefaktoren wie z.B. Gehalt oder Bonus stimmen. Gerade junge Mitarbeiter verdienen im Vergleich zu älteren Kollegen bei gleicher Leistung häufig weniger. Sie sollten hier ein Auge drauf haben und die gute Leistung auch über Gehaltssteigerungen und Bonuszahlungen würdigen. Bitte nicht falsch verstehen: Geld kann eine Karriereentwicklung nicht ersetzen. Aber wenn die Rahmenbedingungen nicht passen, müssen Sie über den Rest nicht lange nachdenken.
  • Coachen Sie Ihren Mitarbeiter dahin, dass er Klarheit über seine Ziele hat. Wohin möchte er? Was möchte er tun? Wofür brennt er? Wenn er drei Veränderungswünsche hat, was würde er sich wünschen? Vielen Menschen fällt es sehr viel leichter, zu artikulieren, was sie nicht wollen („ich will aus dem Projekt raus“) als kund zu tun, was sie stattdessen tun wollen („mir egal, hauptsache anders“). Aber nur wenn er (und Sie) die Ziele und Beweggründe kennen, können sie darauf hin arbeiten.
  • Vergleichen Sie Ihren Mitarbeiter mit anderen Potenzialträgern im Projekt / Bereich / Unternehmen. Ist er der Beste in Ihrem Projekt, aber im Vergleich zu anderen Projekten / Abteilungen an Nummer 34? Sie brauchen diese Einschätzung, um erfolgreiches Erwartungsmanagement bei Ihrem Mitarbeiter zu betreiben. Was kann er realistischerweise erwarten – und was auch nicht.
  • Setzen Sie ein Zeichen im Unternehmen. Machen Sie deutlich und publik, dass hier ein außergewöhnlicher Mitarbeiter sitzt. Dieses Zeichen können Sie beispielsweise setzen, in dem sie ihn für Nachwuchsführungskräfteschulungen anmelden oder ihn für Beförderungen vorschlagen. Es ist dabei weniger wichtig, ob er tatsächlich an der Schulung teilnimmt oder befördert wird, entscheidend ist, dass andere auf ihn aufmerksam werden.
  • Geben Sie ihm Zusatzaufgaben im Projekt. Häufig lassen sich die Ziele des Mitarbeiters (siehe oben) nicht nur durch einen Wechsel des Projektes oder der Abteilung erreichen, sondern auch durch Zusatzaufgaben.
  • Erweitern Sie seine Aufgaben im Projekt. Während der Projektlaufzeit können sich hierfür günstige Gelegenheiten bieten. So könnte ein Business Analyst im späteren Verlauf die Aufgabe des Testleiters übernehmen. Oder sie bündeln alle Roll-Out-Aktivitäten (Datenmigration, Schulungen, Marketing & Kommunikation) an einer Stelle und übertragen ihm die Koordination vieler Bereiche.
  • Sprechen Sie eine deutliche Empfehlung aus. Ja, dies kann bedeuten, dass er Ihr Projekt verlässt. Ja, dies kann bedeuten, dass er aus Ihrer Einflusssphäre verschwindet. Aber Sie halten ihn in Ihrem Unternehmen. Und eventuell arbeiten Sie zu einem späteren Zeitpunkt wieder mit ihm zusammen.

Nichts machen ist keine Lösung. Gute Leute gehen ihren Weg – ob in Ihrem Projekt oder außerhalb Ihres Projektes!

Hier ist eine Videoversion des Beitrags:

Project Leadership

Keine Entscheidung – kein Fehler!

Veröffentlicht am

Kennen Sie das? Sie haben ein Problem. Sie suchen nach Lösungen. Sie finden zwei oder mehr Lösungen mit jeweils unterschiedlichen Vor- und Nachteilen. Da Sie die Lösungsideen nicht einfach im Projekt umsetzen können, bitten Sie um eine Entscheidung im Lenkungsausschuss. Und es passiert – nichts. Keine Entscheidung. Selbst in Situationen, in denen Sie objektiv eine Entscheidung „links oder rechts“ für die Fortführung des Projektes benötigen – nichts. Die Teilnehmer des Lenkungsausschusses verweigern eine Entscheidung (bzw. geben diese in das Projekt zurück).

Ich habe lange darüber nachgedacht, warum Führungskräfte, deren zentrale Aufgabe das Entscheiden ist, eine Entscheidung verweigern. Denn rational erscheint mir diese Vorgehensweise nicht. Meine zwei Hypothesen:

  • Fehler werden sanktioniert. Wir lesen ja häufig von einer „neuen Fehlerkultur“, wir „müssen Fehler zulassen“, „fail early, fail fast“. Häufig werden jedoch Fehler auch sanktioniert – entweder direkt (Entlassung, kein Bonus) oder indirekt (keine Weiterentwicklung, kein Aufstieg). Arbeiten Führungskräfte in einem derartigen Umfeld, könnte ihre Überlegung bei schwierigen Entscheidungen sein: Keine Entscheidung – Kein Fehler – Kein Problem. Zumindest kein Problem für sie. Das Problem des Projektleiters ist ein Problem anderer Leute.
  • Starke Konsenskultur. In manchen Unternehmen werden Entscheidung nur im Konsens getroffen. Dies kann die unterschiedlichsten Gründe haben, von einer starken Beteiligung der Betroffenen bis zu regelmäßiger Job-Rotation der Führungskräfte. Entscheidungen, bei denen kein Konsens möglich ist (links ODER rechts), führen zwangsläufig zur Benachteiligung einer Partei. Auch hier: Keine Entscheidung – keine Benachteiligung.

Bleibt noch die Frage, was Sie als Projektleiter in einer Situation tun können, in der Sie die möglichen Lösungsvarianten nicht ausschließlich im Projekt umsetzen können. Aus meiner Sicht bleibt Ihnen nur ein Weg: Zeigen Sie Rückgrat und geben Sie die Projektleitung zurück.

Project Leadership

Wenn du ein totes Pferd reitest – steig ab!

Veröffentlicht am

Ich habe in meinen Artikeln Top-3-Gründe für eine Projektvision und Wie sieht eine gute Projektvision aus die Vorteile einer Projektvision beschrieben. Wenn Sie aber feststellen, dass die Projektvision nur auf dem Papier existiert. Wenn Sie feststellen, dass die Projektvision nicht die Entscheidungen beeinflusst. Wenn Sie feststellen, dass Ihr Projektteam sich verzettelt und den Fokus verliert. Dann ist es Zeit, vom Pferd abzusteigen.

Vermutlich haben Sie sich zu Beginn des Projektes Gedanken zu der Projektvision gemacht. Idealerweise haben Sie die Vision gemeinsam mit dem Projektteam verfeinert, um zu einer geteilten Vision zu kommen. Und vielleicht haben Sie die Vision auch genutzt, um Ihre Stakeholder abzuholen und auf das Projekt einzuschwören. Im täglichen Klein-Klein des Projektalltags ist die Projektvision dann unter die Räder gekommen. Ja, sie ist in den Präsentationen für den Lenkungsausschuss enthalten, aber man gewöhnt sich daran und registriert den Inhalt nicht mehr wirklich. Neue Ideen tauchen auf und werden begeistert angenommen. Könnten wir nicht noch… Wäre es nicht toll, wenn… Die ersten Brandherde treten auf, Sie sind im Firefighting-Modus. Wer hat da noch Zeit für Visionen?

Falsch – gerade dann hilft Ihnen eine Projektvision. Die Frage ist nur, wie Sie die Vision in Ihren Projektalltag integrieren. Die gute Nachricht: Hier können Sie richtig kreativ werden! Die schlechte Nachricht: Hier können Sie richtig kreativ werden! Zum Start aber einige Anregungen:

  • Drucken Sie die Vision auf Poster. Hängen Sie die Poster regelmäßig im Raum um.
  • Bitten Sie in jedem Teammeeting einen anderen Kollegen, eine Geschichte zu teilen, wie ihr die Projektvision in der letzten Woche geholfen hat.
  • Nutzen Sie die Projektvision als Teil von formalen Entscheidungskriterien für Varianten (i.S.v. „zahlt auf Projektvision ein oder nicht“)
  • Verknüpfen Sie Teilerfolge (z.B. Erreichung von Meilensteinen) mit der Projektvision
  • Stellen Sie in Lessons Learned / Retrospektiven grundsätzlich die Frage, wie das Handeln im Projekt noch besser auf die Vision abgestimmt werden kann.

Entscheidend ist, dass die Projektvision lebt und ein lebendiger Bestandteil der Projektarbeit ist. Eine auf Hochglanz polierte Vision in der Schublade verfehlt ihre Ziele. Welche Erfahrungen haben Sie mit einer Projektvision gemacht? Wie haben Sie die Vision am Leben erhalten?

Allgemein

Präsentieren Sie noch oder informieren/unterhalten/überzeugen Sie schon?

Veröffentlicht am

Ich habe vor einigen Tagen eine Präsentation versemmelt. In unserem Bereichsmeeting sollte ich ein neues Projekt und den aktuellen Status vorstellen. Wie üblich kam diese Aufforderung relativ kurzfristig. „Kein Problem“, dachte ich, „es war ja gerade Lenkungsausschuss – ich kann die Folien recyceln“. In unserem Bereichsmeeting schauten mich dann 100 Mitarbeiter verständnislos an. Mir fiel es wie Schuppen von den Augen – meine Kollegen hatten nicht das notwendige Vorwissen, sie konnten den Hintergrund des Projektes nicht verstehen, sie mussten keine Entscheidungen treffen. Meine Präsentation war schlicht am Publikum vorbei.

Ein derartiger Faux-Pas ist sicherlich nicht die Regel, aber ab und zu passiert er. Vielleicht auch Ihnen. Lassen Sie uns kurz rekapitulieren, was es mit der Zielgruppe von Präsentationen auf sich hat.

Starten wir mit der Gretchenfrage: warum präsentieren Sie? Oder präsentieren Sie vielleicht gar nicht, sondern Sie wollen informieren, unterhalten, motivieren, inspirieren, zu Handlungen auffordern oder eine Entscheidung herbeiführen? Und Sie nutzen das (technische) Format einer Präsentation nur zur Unterstützung? Zwei Anregungen:

  • Verbannen Sie den unsäglichen Satz „ich halte eine Präsentation“ aus Ihrem Wortschatz. Nutzen Sie stattdessen einen Satz, der Ihre Absicht deutlich macht.
  • Sofern Sie die Antwort auf die „warum“ Frage nicht kennen – verzichten Sie auf die Präsentation, sparen Sie sich die Arbeit und Ihren Zuhörern das Leid. Das wird eh nix.

Sobald Ihnen Ihr Ziel klar ist, lohnt es sich, über die Zielgruppe (Ihre Zuhörer) nachzudenken. Es ist Ihr Ziel und Ihre Zielerreichung hängt maßgeblich davon ab, wie gut Sie Ihre Zielgruppe erreichen. Bringen Sie so viel wie möglich in Erfahrung, beispielsweise:

  • Präsentationsspezifisch
    • Interessen
    • Vorwissen zum Thema
    • Einstellung zum Thema (Befürworter, Kritiker, Neutral, …)
    • Motivation zur Teilnahme (Interesse, Abgesandter, Prüfer, …)
    • Erwartungen zum Thema und zur Präsentation
  • Unternehmensspezifisch
    • Hierarchieebene
    • Funktion / Tätigkeit
    • Interne / externe Mitarbeiter
    • Entscheidungsspielraum
  • Allgemein
    • Anzahl der Zuhörer
    • Alter
    • Ausbildung, Beruf

Überlegen Sie, wie Sie Ihre Zielgruppe bestmöglich informieren, unterhalten, usw. Ein Geschäftsführer erwartet andere Informationen als ein Sachbearbeiter. Ein fachlicher Experte fühlt sich durch andere Elemente (z.B. Wortspiele, war stories) unterhalten als ein Laie. Jede gute Präsentation orientiert sich am Publikum (da ist es wieder, das unsägliche Wort). Überlegen Sie, wie Sie die Inhalte, die genutzten Medien und den Wortschatz für Ihr Ziel und Ihre Zielgruppe anpassen.

Als Projektleiter gibt es eine Zielgruppe, mit der Sie üblicherweise oft interagieren: der Lenkungsausschuss. Bei relevanten Projekten ist dieser oft mit Geschäftsführern, Bereichsleitern, CIO u.ä. besetzt. In der Regel informieren Sie über den Projektfortschritt und führen Entscheidungen herbei. Diese Zielgruppe zeichnet sich meistens durch zwei Eigenschaften aus:

  • Die Teilnehmer sind extrem schnell im Kopf
  • Die Teilnehmer haben wenig Zeit

Ich habe gute Erfahrungen gemacht, auf diese Besonderheiten einzugehen. Hierfür nutze ich zwei Instrumente:

  • Ich verschicke eine ausführliche Unterlage mit allen relevanten Details vorab -> die Teilnehmer können diese zu einem Zeitpunkt lesen, der ihnen genehm ist und sie lesen schneller als ich spreche
  • In der eigentlichen Diskussion nutze ich eine stark verkürzte Version und gehe nur auf die kritischen Informationsbedarfe bzw. Empfehlungen ein sowie eventuelle Fragen

Habe ich Sie überzeugt, bei Ihrer nächsten Präsentation über Ihr Ziel und Ihre Zielgruppe nachzudenken? Ich freue mich über Ihr Feedback!

PS: Vielleicht finden Sie einige interessante Hinweise zur visuellen Gestaltung in meinen Beiträgen Aufschreiben und visualisieren – eine Führungsaufgabe? und Überlasse niemandem die Deutungshoheit über Daten

PPS: Hier gibt es die Videoversion dieses Beitrags.