Improvisieren im Projekt: Warum Erfahrung hinderlich sein kann

„Resignieren oder improvisieren“ oder Erfahrung: Möglicher Tod der Improvisation

ImprovisationGeorgia on my mind – a thousand times…

Eine Saxophonistin spielt eines ihrer Lieblingsstücke – Georgia on my mind. Tausende Male gespielt. Sie ist Expertin für diesen Song (neben vielen anderen). Sie steigt in ihr Solo ein, gekonnt und routiniert wie seit Jahren. Das Publikum jubelt – die Erwartungshaltung wird erfüllt. Ist ihr Solo Improvisation? Jedes ihrer Soli klingt anders als die anderen in der Vergangenheit. Sie folgt keinen Noten, sondern spielt nach ihrer Intention, ihrem Gefühl, ihrer Stimmung. Dennoch ist ihr Solo aber geprägt aus der Erfahrung, die unsere Saxophonistin im Laufe der Zeit erworben hat. Ist wirklich irgendetwas Neues im Solo – eigentlich nicht. Wird dies vom Publikum erwartet – ebenfalls nicht. Ist dies also Improvisation?

Was ist eigentlich Improvisation? Nehmen wir für diesen Beitrag die Definition aus dem deutschen Wikipedia: „Improvisation bedeutet, etwas ohne Vorbereitung, aus dem Stegreif dar- oder herzustellen. Im allgemeinen Sprachgebrauch versteht man unter Improvisation auch den spontanen praktischen Gebrauch von Kreativität zur Lösung auftretender Probleme.“

Nach dieser Definition ist ein Solo unserer Musikerin keine Improvisation – sondern eben ein sehr gekonntes Solo. Wobei ich mit der Definition von Wikipedia meine Probleme habe – denn in der Kunst löst man meistens mit Kreativität keine Probleme – man ist einfach kreativ. Aber dennoch: ist die Erfahrung der Musikerin gleichzeitig der Tod ihrer Inspiration? Sie spielt dasselbe Stück wieder und wieder – was kann da noch spontan oder aus dem Stegreif sein? Sie muss nicht mehr improvisieren, wie vielleicht in den Anfangsjahren, wo sie vielleicht beim Solo auf einmal nicht mehr weiterwusste und sich einfach etwas einfallen lassen musste (so ging es mir früher öfters bei meinen Keyboard-Solos, eine eher unangenehme Erinnerung 😳 ). Sie kann auf ihre Erfahrung „bauen“.

Woran liegt es, dass wir mit zunehmender Erfahrung immer weniger improvisieren? Es liegt an ebendieser Erfahrung.


OK, wieviel Prozent meiner Leserschaft hat bis hierhin durchgehalten? Für die, die noch da sind – ja, dies kann man auch auf das Projektgeschäft übertragen. 😀

Schnitt: Berufsalltag. Wann improvisieren wir – z.B. im Projektmanagement – im Berufsalltag? Wenn wir nicht anders können. Wir sind in einer Situation, in der wir noch nicht waren. Unsere Ausbildung, unsere Erfahrung hilft uns nicht weiter. Was bleibt? Resignieren oder improvisieren. Ich denke, die meisten werden sich für das Improvisieren entscheiden. Dabei kommen manchmal erstaunliche Dinge heraus. Oder auch furchtbare…

Viele neue Produkte sind entstanden, weil ein „Need“ dafür da war, es aber keine Lösung gab. In Startups wird oft improvisiert (wenn auch immer weniger, aber dies wäre ein anderer Beitrag). Dadurch entstehen neue Lösungen, an die vorher niemand gedacht hat. Helfen agile Methodiken beim Improvisieren? Nicht unbedingt. Kurze Sprints bringen zwar schneller neue Produkte hervor, aber es wird nicht zwangsläufig improvisiert.

Und, hey: Improvisation ist in. Es kommt nur in einem anderen Zusammenhang vor, nämlich unter dem Stichwort „Disruption“. Man zerstört alte Industrien mit neuen Ideen, die durch Improvisation entstanden sind (ein schöner Artikel dazu ist aus der FAS: „Disruption, Baby, Disruption“).

Aber wie oft kommen wir in die Situation, improvisieren zu können? Immer weniger, je länger wir im Berufsleben sind. Je mehr Erfahrung wir haben, desto weniger „müssen“ wir improvisieren. Wir können aus unserer Toolbox der Methoden, die wir kennen, eine für die Situation passende herausgreifen und anwenden. Wir sind Experten auf unserem Gebiet. Dies ist doch positiv, oder? Engagieren Sie nur noch erfahrene Programm- oder Projektmanager (wie zum Beispiel mich ), die schon alles in ihrem Leben gesehen haben und nichts mehr überraschen kann. Der Projekterfolg ist garantiert!

Oder? Zurück zur Musik. Schaffen erfahrene Musiker große Werke? Hören Sie sich die letzten Werke von Jeff Lynne, Paul McCartney oder David Gilmour an. Sternstunden der Musik? Nicht wirklich. Mehr oder weniger gute handwerkliche Musik, aber nichts Neues. Irgendwie klingt es ähnlich (auch wenn verschiedene Produzenten versuchen, es anders klingen zu lassen). Liegt dies an ihrer großen Erfahrung aus ihrer Vergangenheit oder gehen diese Künstler „nur auf Nummer sicher“? Wahrscheinlich trifft beides zu. Genauso geht es Managern im täglichen Leben. Als Experten in ihrem Fachgebiet greifen sie bei neuen Herausforderungen auf ihre große Erfahrung zurück. Bis sie „disrupted“ werden. Denn wie lautet der Managerspruch des Jahrzehnts: „Wer nicht disrupted, wird selbst disrupted“. Punk-Musik war ein Beispiel in der Musik im letzten Jahrtausend, das Unternehmen Kodak steht als Beispiel für die Industrie, welches hinweggefegt – „disrupted“ – wurde.

Zudem: Als Künstler kann man noch eher improvisieren – nur das Kunstwerk hängt davon ab. Kunst ist damit weniger frei von Zwängen – insbesondere, wenn man aus der gesicherten Position eines Weltstars agiert. In verantwortlichen Positionen – sei es als Manager mit Personal- oder Umsatzverantwortung oder als Projektmanager mit Budgetverantwortung – fällt improvisieren deutlich schwerer, da die Folgen dramatisch sein können. Was passiert, wenn durch Improvisation Arbeitsplätze wegfallen, ein Unternehmen in finanzielle Bedrängnis gerät, ein Entwicklungshilfeprojekt scheitert?

Nun will ich nicht generell sagen, dass Erfahrung Improvisation hemmt. Auch umgekehrt kann es sein. Erfahrung kann auch beim Improvisieren helfen, indem man z.B. Best Practices aus anderen Industriezweigen überträgt. Generalisten, die nicht auf eine Branche festgelegt sind, können so etwas eher als Experten. Denn Erfahrung kann auch hemmen, wenn vergangene Erfahrungen wieder und wieder angewandt werden – und neue Ideen verhindern.

Nun bleibt die spannende Frage: wie kann man noch mit Erfahrung improvisieren? Brainstorming in Gruppen kann helfen. Bewusst verwendete Methoden vermeiden oder sogar verbieten! Wir wollen etwas Neues machen und ignorieren unsere Erfahrungen aus der Vergangenheit. Wir machen etwas völlig Verrücktes, was noch niemand gemacht hat. Als Positivbeispiel ging das Unternehmen „Rügenwälder Mühle“ im letzten Jahr durch die Presse. Die Umsätze waren seit Jahren rückläufig – wie überall in der Branche. Man musste etwas Neues wagen – gegen große Widerstände im eigenen Unternehmen.

Amy Edmondson meint dazu (zitiert nach managerSeminare, Heft 212): „Fördern Sie Experimente und feiern Sie Fehlerpartys, um gescheiterte Experimente zu würdigen.“ Der Tenor sollte sein: Machen Sie im Unternehmen mehr Fehler, um schneller Erfolg zu haben. Denn: Wer mehr Kreativität will, muss auch mehr Fehler zulassen und den Rechtfertigungsdruck verringern.

Dies erfordert harte Disziplin und eine Umgebung (sprich: Firmenkultur), die Fehler nicht nur zulässt, sondern in gewissen Maße auch fördert. Ferner einen Moderator, der konsequent darauf aufpasst, dass Vergangenes nicht wiederverwendet wird. Wobei dies für einen externen Moderator einerseits sehr schwer ist – kennt sie / er ja nicht die Vergangenheit aller beteiligten Personen. Andererseits kann er unabhängiger agieren als interne Mitarbeiter, da sie / er keine „Vergangenheit“ hat oder kennt. Der Moderator muss mehr Coach als Moderator sein. Und er muss sich zurücknehmen.

Zudem sollte es kein Experte sein, weil dieser zu sehr in seinem Expertentum gefangen ist. Experten möchten die Zukunft auf der Grundlage der Vergangenheit gestalten – sie sind oftmals in ihrer Erfahrung gefangen. Experten erklären gerne, warum etwas nicht funktionieren kann. Sie erklären es solange, bis sie „disrupted“ werden (ich hasse diesen Begriff…).

Die Kunst ist es Erfahrung mit Improvisation zu verbinden. Und nicht zu resignieren.

Haben Sie Fragen zum Thema Improvisation? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

Christine Paulus inspirierte mich zu diesem Blog-Beitrag.

Projektkontrolle – die ungeliebte Pflichtaufgabe

„Vertraue, aber prüfe nach“ (Dowerjai, no prowerjai) – russisches Sprichwort

KontrolleIm Nachgang meines Beitrags „Selbststeuerung für externe Berater in Projekten, Teil 2“ hatte ich eine interessante Diskussion zum Thema „Mikromanagement“ – insbesondere zum Thema Kontrolle. Zwei Meinungen bildeten sich heraus.

Einerseits: Mikromanagement käme doch bei externen Beratern kaum vor. Im Gegenteil – egal ob im Interimsmanagement oder bei der Programm- oder Projektleitung – man vertraue den Projektbeteiligten mehr als man sie „mikromanaget“, sprich: zu sehr kontrolliert. Außerdem ist eine zu enge Kontrolle doch eher etwas Unangenehmes, ist außerdem so „old school“ (obwohl die Generation Z anscheinend… – aber anderes Thema). Dazu kommt, dass man (als Projektleiter) sowieso nur die fachliche Leitung hat. Bei Abweichungen hat man wenig Handhabe. Also fragt man den Leistungserfolg ab und aktualisiert den Projektplan. Zu gegebener Zeit schaltet man die Projektampel auf „gelb“ und dann auf „rot“. Man ist ja nur „Externer“, ohne disziplinarische Befugnis. Hm, und wer ist bei einem Misserfolg dann verantwortlich?

Andererseits ging die andere Meinung in eine gegenteilige Richtung. Gerade in Unternehmen mit flachen Hierarchien müsse man oft mikromanagen, da sonst die internen Machtkämpfe einem das Projekt ruinieren und man bei niemandem eskalieren könne – gerade wenn man in der Verantwortung steht. Flache Hierarchien erfordern Mikromanagement, wie kann das sein?

Flache Hierarchien können das Recht des Stärkeren fördern – und erschweren die Kontrolle

In Unternehmen arbeiten viele Vorgesetzte bekanntermaßen nach dem Prinzip „solange ich nichts von meinem Mitarbeiter höre, läuft es gut“. Dies kann man verstehen, gerade wenn diese Vorgesetzten überlastet sind, welches durch die flachen Hierarchien heutzutage immer häufiger vorkommt. (Lehrbücher definieren die optimale Zahl der direkten Mitarbeiter/innen mit 7 bis 10. Zählen Sie mal wie viele es in Ihrem Umfeld sind…). Zu viele Mitarbeiter berichten an eine Person, die damit hoffnungslos überfordert ist. Viele Mitarbeiter/innen schätzen diese Vorgehensweise. „Sie / Er lässt mich in Ruhe meine Arbeit machen und wenn es Probleme gibt, kann ich zu ihr / ihm gehen“. Andere hingegen wünschen sich mehr Feedback und Unterstützung, die sie nicht genügend bekommen.

Nun die These aus der obigen Diskussion: Wenn die formalen Führungspositionen nicht besetzt sind oder die Führungsspanne zu groß ist, bilden sich oft natürliche Hierarchien heraus. Die stärksten (nicht unbedingt die besten) Teammitglieder werden inoffiziell um diese Führungspositionen „ringen“. Dies führt oft zu heftigsten Machtkämpfen innerhalb eines Teams. So modern flache Hierarchien sind, so sehr die Vorteile überzeugen – dies kann sich nachteilig auf ein Unternehmen (und auf unser Projekt) auswirken…
Für interne und externe Projektleiter/innen erschwert dies die Projektkontrolle (und den Projektfortschritt), da die Teams mit anderen Dingen beschäftigt sind als mit der Projektarbeit. Eskalationen sind schwierig, wenn es nur weit entfernte Vorgesetzte gibt, die keine Zeit (und kein Interesse – man ist im Unternehmen ja selbstverantwortlich) haben.

So oder so, Projektkontrolle bleibt eine ungeliebte Pflichtaufgabe, wenn man die Chancen ein Projekt erfolgreich abzuschließen deutlich erhöhen will.

Was bedeutet Kontrolle?

Worum geht es eigentlich bei Projektkontrolle, warum wird kontrolliert:

  • Zunächst einmal soll die Abweichung zwischen Sollplanung und Realität ermittelt werden. Hier überprüft man die Leistungen (Aufgaben, Qualität), Kosten und Termine.
  • Falls es Abweichungen gibt, muss eine Analyse erfolgen (Warum wurde vom Plan abgewichen?).
  • Haben diese Abweichungen Auswirkungen auf unser Projekt?
  • Wie gehen wir mit diesen Abweichungen um, welche Maßnahmen leiten wir daraus ab?

Hier sprechen wir von der sogenannten „operativen Kontrolle“. Leiten Sie ein Programm und nicht nur ein Projekt, dann sind Sie auch an den Auswirkungen auf andere Projekte interessiert (z.B. welche Auswirkungen haben Abweichungen im Projekt A für das Projekt B).
Daneben gibt es die „strategische Kontrolle“, die z.B. die Unternehmensstrategie im Fokus hat. Diese ist deutlich komplexer, da hier auch nicht oder nur teilweise beeinflussbare Faktoren kontrolliert werden müssen (mehr über komplexe Projekte hier).

Will man ein Unternehmen, ein Programm, ein Projekt erfolgreich führen, kommt man um Kontrolle eigentlich nicht herum – nicht alle Beteiligten bemerken selbst, wenn etwas „aus dem Ruder läuft“ und kommen auf uns zu. Wer von uns kennt nicht das Gefühl des Selbstbetrugs, wenn wir bis kurz vor Schluss glauben, es wird alles gut – auch wenn die Sache schon völlig aus dem Ruder gelaufen ist.

Dabei muss Kontrolle keine Einbahnstraße sein – trotz der Deadlines, die Projektleitungen haben, und die sie einhalten müssen. Kontrolle kann auf Augenhöhe mit allen Beteiligen stattfinden – im besten Fall selbstorganisiert bei den beteiligten Teams und Mitarbeitern.

Kontrolle gemeinsam planen hilft beiden Seiten

Es gibt einige einfache Tipps, wie Vorgesetzte oder Projektleiter kontrollieren können, ohne die Mitarbeiterinnen und Mitarbeiter zu sehr unter Druck zu setzen. Maßgeblich gehört dazu die Zusammenarbeit zwischen den Beteiligten und ein gemeinsames Einverständnis über die Maßnahmen zur Kontrolle:

  • Die Projektmitarbeiter oder -teams schlagen Meilensteine auf dem Weg zum Ziel vor.
  • Die Projektmitarbeiter planen die Kontrolle dieser Meilensteine selbst ein.
  • Regelmäßige Kontrolle durch die Vorgesetzten / Projektleiter ermöglicht einfacheres Nachsteuern von Meilensteinen.
  • Häufige Kontrolle am Beginn eines Projekts erhöht die Motivation (man könnte auch sagen den „positiven Stress“). Zudem beugt dies dem Effekt vor, dass bis zu 90% der Zielerreichung alles super ist und dann die Probleme beginnen.
  • Erfahrene Vorgesetzte und Projektleiter verbinden Kontrolle mit Lob, wenn es angebracht ist. Viel Lob erleichtert später Tadel, falls es mal erforderlich ist. Sicherlich lobt es sich als externer Berater manchmal schlecht (bzw. scheinen manche externen Berater Schwierigkeiten zu haben mit Lob). Aber aufmunternde Worte wie „Super“, „sehr gut“ oder einfach ein Dankeschön „gehen immer“ und sind leicht gesagt. Obwohl es viele Artikel gibt, die eine positive Wirkung solcher Worte verdeutlichen, kann dies gar nicht oft genug gesagt sein.
    Dies funktioniert auch bei gegenseitiger Kontrolle in selbstorganisierten Teams. So individuell man Kontrolle handhaben sollte, leider passt dies nicht immer in das verwendete Projektmanagementparadigma und/oder in die Unternehmenskultur. Hier ist die Empathie und Variabilität des Projektleiters gefragt. Einen Umgang mit den Kolleginnen und Kollegen auf Augenhöhe sollte für jeden externen Projektleiter eine Selbstverständlichkeit sein.

Transparenz bei Kontrolle des Projektfortschritts fördert das Vertrauen zwischen den Beteiligten. Übertriebene Kontrolle hingegen führt zwangsweise zu Mikromanagement und damit oft zu Unzufriedenheit der internen Kollegen und fördert Überwachungsangst (wie im Eingangs erwähnten Beitrag zur Selbststeuerung).

Übrigens: Das Wort „Kontrolle“ ist sicherlich negativ besetzt. Unternehmen und Managementschulen sind reich an Phantasie, diesen Begriff anders zu umschreiben. Kontrolle mit netteren, anderen Worten zu umkleiden bringt aber nichts. Unterschätzen Sie nie die Intelligenz Ihrer Projektkolleginnen und –kollegen. Daher gehen Sie offen mit dem Thema um und bevorzugen Sie die Zusammenarbeit, wie oben beschrieben. Kontrolle kann auch ein Schutz sein, wenn die eigenen Aufgaben „in time & in budget“ sind, aber Aufgaben anderer hinterherhinken.

Kontrolle bedeutet Kosten

Was übrigens gerne vergessen wird: Kontrolle bedeutet auch immer Kosten (oder zusätzliche Arbeitszeit). Je genauer man kontrolliert, umso höher steigt der Aufwand. Für externe Berater stellt sich die Frage – bekommen Sie diese zusätzliche Arbeitszeit bezahlt? Ist es sogar Teil Ihres Mandats? Oder übersteigt dies Ihren „durchschnittlichen Acht-Stunden-Tag“ (wie es so gerne in Verträgen geschrieben steht)?

Wie oben erwähnt muss Kontrolle keine Einbahnstraße sein. Selbstorganisierte Teams können die Kontrolle gemeinsam durchführen. Nebenbei: Agiles Vorgehen bedeutet keinesfalls, dass es keine Kontrolle gibt. Innerhalb eines Teams findet gegenseitige, eigentlich permanente Kontrolle statt (nennt sich dort aber anders). Durch kurze Iterationszeiten (und damit Lieferzeiten) kann man anhand fertiger Produkte von außen sehen, ob der Fortschritt wie geplant erreicht wird.

Fazit: Kontrolle ist erforderlich – in allen Arten von Projekten. Sie muss nicht negativ erscheinen, sondern von allen Beteiligten als Notwendigkeit verstanden werden, um gemeinsam ein Ziel zu erreichen. Legt man gemeinsam fest, wie und wann kontrolliert wird, ist die Akzeptanz und das Verständnis für Kontrolle ungleich größer – und für Projektleiter entspannter und weniger ungeliebt…

Haben Sie Fragen zum Thema Kontrolle? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

Lean und agil SIND unterschiedlich!

Kanban ist nicht Scrum, Scrum ist nicht Kanban – und die Konsequenzen daraus für die Praxis

SS30049Lean, agil, Scrum, Kaizen, Extreme Programming, Kanban für IT – alles ist doch irgendwie ähnlich, oder?

Schon in meinen früheren Blog-Beiträgen über Kanban für den Einsatz in der IT ärgerte ich mich, dass die Begriffe „lean“ und „agil“ oft synonym verwendet werden (im ersten Beitrag berichtete ich, wie ich Kanban auch außerhalb der Softwareentwicklung einsetze. Im zweiten Beitrag beschrieb ich, warum der Einsatz von Kanban scheitern kann und was man dagegen tun kann).

Die Vermischung geschieht, da agile Methodiken und lean Management oft gemeinsam eingesetzt werden. Der gemeinsame Einsatz ist gerade „hip“ in der IT, wohl weil sich immer mehr die Einsicht durchsetzt, dass agile Methodiken alleine doch nicht das Allheilmittel für alle Probleme in der Produkt- und Projektentwicklung sind (da agile Methoden oft auch aus falschen Beweggründen eingeführt werden…).

Warum beharre ich überhaupt auf den Unterschied? Ist dies nicht eher akademisch und nur ein Streit unter Experten? Ich betone es, weil es IMHO einen großen Unterschied gibt, wie ich gleich weiter ausführen werde.

Bei einer kurzen Internet-Recherche zu diesem Thema fiel mir allerdings auf, dass eigentlich immer wieder die Gemeinsamkeiten betont werden. Die Unterschiede werden meistens abgetan mit Aussagen wie „obwohl es auch Unterschiede gibt, überwiegen die Gemeinsamkeiten“ – ohne groß auf die Unterschiede einzugehen. Die Autoren haben meist einen agilen Background und verwenden Kanban als Unterstützung.

Die Gemeinsamkeiten

Und in der Tat fallen zunächst zahlreiche Gemeinsamkeiten ins Auge:

  • Lean und agil fördern / fordern die Selbstverantwortung in den Teams bzw. bei den beteiligten Personen, auch wenn bei „lean“ durchaus der Leadership-Aspekt gegeben ist (darauf gehe ich weiter unten noch ein).
  • Zur Verbesserung der Abläufe ist eine stetige Rückkopplung bei Beiden gegeben.
  • Die Dauer der Bearbeitungsintervalle wird verkürzt, wenn es auch Unterschiede gibt zwischen fixen und flexiblen Intervallen.
  • Die Reduktion der Komplexität ist maßgeblich bei lean (eliminate waste) und agil (to satisfy the customer through early and continuous delivery of valuable software).
  • Die beteiligten Personen stehen im Vordergrund – daraus leiten sich Prinzipien zur Interaktion und Kommunikation ab.

Einen guten Blog-Beitrag zu den Gemeinsamkeiten hat Pietari Kettunen 2013 geschrieben.

DER Unterschied und die Konsequenzen daraus

Also Eckhard, Butter bei die Fische. Was sind denn jetzt die Unterschiede? Deine frühere Aussage „Kanban ist eine Change-Management Methode zur Prozessverbesserung, keine Framework für agile Software-Entwicklung“ ist ja gut und schön, aber was bedeutet dies in der Praxis?
Also gut, in einem Satz: Der Hauptunterschied ist, „lean“ hat den Produktionsprozess im Fokus – agile Methodiken dagegen haben das Produkt im Fokus.

Betrachtet man die Entstehungsgeschichten von Kanban und agilen Methodiken, dann erscheint dies schnell einleuchtend. Kanban kommt aus der Automobilindustrie – von Toyota aus Japan. Das agile Manifest hingegen ist entstanden, um die Software-Entwicklung flexibler und schlanker zu machen. Später wurde das agile Manifest breiter gefasst, indem aus „Software-Entwicklung“ „Produkte“ wurden – sprich um die Produktentwicklung generell agiler (und damit schneller) zu gestalten (was dazu führte, dass in Unternehmen „agil“ und „schnell“ immer öfter synonym verwendet wird).

Was sind die Konsequenzen daraus: Agile Methodiken wie Scrum starten beim Team. Es beinhaltet ein klares Regelwerk mit Rollen, Abläufen, detaillierten Prozessen. Scrum oder XP werden mit einem „Big Bang“ eingeführt. Die Dauer für einen Sprint (eine Iteration bei XP) werden vorher festgesetzt. Der Umfang des Produkts wird definiert, was in der vorgegebenen Zeit zu schaffen ist und ggf. während des Sprints angepasst – solange es funktionstüchtig ist.
In der Automobilindustrie, aus der Kanban hervorging, ist dies schwer vorstellbar. Es ist nicht möglich zu sagen, ein Auto wird in einer vorher festgelegten Zeit produziert – solange es funktionstüchtig ist. Ich möchte den Besteller eines Automobils sehen, dem der Verkäufer erklärt: „Es fährt doch! Gut, die bestellten Assistenzsysteme und das LED-Licht sind nicht an Board – aber dies war in der vorgegebenen Zeit nicht zu schaffen.“
Konsequenz: Lean Management, wie z.B. Kanban startet beim Ist Prozess, es wird von bestehenden Strukturen und Teams ausgegangen. Agile Techniken hingegen wie Scrum startet beim Team. Bei einer Einführung entwickelt das Team nicht mehr Produkte wie bisher (z.B. nach dem Wasserfallmodell), sondern verwendet eine neue Methodik.

Auch wenn das agilen Manifest „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“ priorisiert, muss man doch feststellen, dass agile Methodiken die Arbeitsweise der beteiligten Personen einschneidend verändert. Scrum beinhaltet ein klares Regelwerk mit Rollen, Artefakten und definierten Prozessen. Nicht jedes „Individuum“ ist dazu bereit oder in der Lage. Letztendlich steht doch das Produkt im Vordergrund nicht der Mensch (oh, für diese Aussage werde ich Prügel beziehen…). Diese Tatsache soll die positiven Eigenschaften agiler Methodiken nicht schmälern, die frischen Wind in die Software-Entwicklung gebracht haben (siehe mein Verweis zu Punk & Scrum), aber es gibt „Opfer“ on the way. Warum wird man Software-Entwickler? Bestimmt nicht, weil man der geborene Kommunikator ist. Aber ist dies nicht eine Voraussetzung für Scrum und Co? Daily Standups, Pair Programming, Planungspoker und Retrospektiven sind nicht die Lieblingsbeschäftigungen für Nerds (oh, auch für diese Aussage werde ich wieder Prügel beziehen…).
Kanban hingegen geht vom Status Quo aus – und nimmt damit die Menschen mit. Kanban ist die „sanftere“ Art der Veränderung. Aber – auch dies habe ich schon früher betont – unsexy fürs Management. Neue Methodik, fixe Releasedauer, fertige Produkte klingen einfach besser als kontinuierliche Verbesserung. Es ist viel Überzeugungsarbeit (insbesondere beim Management) zu leisten, dass ein stetiger Fluss von fertiger Arbeit (wie z.B. Software) wichtiger ist, als hohe Auslastung der Leute und das Erreichen eines Releaseplans mit festem Termin und festem Umfang.

Oben erwähnte ich, dass bei „lean“ ein Leadership-Aspekt durchaus gegeben ist. Dies ist natürlich, da Kanban vom Status Quo ausgeht – inklusive Organisationsstrukturen. Auch dies ist ein Unterschied zu agilen Methodiken. Auch dies mag bei agil ein Problem bei der Einführung sein.
Ist also „lean“ gegenüber „agil“ zu bevorzugen? Eine pauschale Aussage ist wie fast immer nicht möglich (könnte das Leben nicht einmal schwarz-weiß sein 😉 ). Letztendlich steht bei Change-Management Projekten immer das Ziel im Vordergrund. Die Frage ist, wie kann ich dieses Ziel am besten erreichen. Aus meiner Erfahrung heraus stelle ich fest, dass gerade bei bestehenden Teams, die schon viele Jahre zusammenarbeiten und im Beruf sind, es immer wieder Schwierigkeiten bei der Einführung agiler Methodiken gibt. Man „wehrt sich nicht”, sondern „macht es mit“ und „irgendwie wird es schon gehen“ – aber Begeisterung sieht anders aus. Die Ergebnisse in der Realität sind oft dementsprechend. „Lean“ kann hier der bessere Ansatz sein – und nichts spricht dagegen es später mit „agil“ zu kombinieren. In der Praxis passiert es oft andersherum. Man möchte agil werden, sieht sich Problemen konfrontiert und versucht sich mit Kanban zu helfen.

Haben Sie Fragen zu agil, lean, Scrum, Kanban & Co? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

Schulungen – wenn neue Systeme oder Produkte auf die Wirklichkeit treffen

Change-Management in der Praxis. Wissen alle Bescheid? Wurde was vergessen?

Schulung

Schulung

Ich liebe Schulungen – konzipiere gerne Schulungskonzepte und führe genauso gerne Schulungen durch. Wann sonst hat man Kontakt mit den Personen, die wirklich mit einem System oder Produkt – welches man über lange Monate oder sogar Jahre (agil hin oder her) zusammengebastelt hat – tagtäglich arbeiten (sollen). Direkteres Feedback bekommt man nirgends – leider zu einem sehr späten Zeitpunkt.

Manchmal werde ich extra für Schulungskonzepte engagiert – meist, wenn Schwierigkeiten bei der Einführung befürchtet werden (warum finden mich immer die verkorksten Projekte?!?). Bei Schulungen trifft die Theorie auf die Praxis. Nach Anwender-Schulungen kann man in der Regel schon die nächste Version planen. Was kann man in Schulungen alles erleben: schockierte Anwender, spontane Protestschreiben, Heulkrämpfe – aber auch positive Aha-Erlebnisse, Freude aufs neue System und Erleichterung („wird ja viel besser als gedacht!“). Habe ich schon erwähnt, ich liebe Schulungen?

Schock in der Schulung

Bei einer Schulung, die ich konzipierte und durchführte, war es allerdings anfangs schwer sie zu lieben. Viele Mitarbeiterinnen und Mitarbeiter waren schockiert.
Der Schock basierte aus vielerlei Gründen:

  • Das System war im Schulungssystem einfach schlecht.
  • Die Daten im Schulungssystem waren idealistisch und fern jeglicher Realität (über die ersten beiden Punkte wird es einen extra Beitrag geben).
  • Aber der größte Schock: das Aufgabengebiet der Kolleginnen und Kollegen änderte sich merklich. Verantwortlichkeiten verschieben sich – und niemand hat sie darauf vorbereitet.

Daher war auch nicht erstaunlich, dass die positivsten Kommentare von Teilnehmern kamen, die das Alt-System nicht kannten und bisher in der Rolle nicht gearbeitet hatten. Sie erkannten die Vorteile des neuen Systems gegenüber der bisherigen, in der Praxis umständlichen Lösung – die aber den beteiligten Mitarbeitern große Verantwortung (und Macht) gab.

Was passiert bei Schulungen eigentlich? In Schulungen beschäftigen sich Mitarbeiterinnen und Mitarbeiter oft erstmals mit den Änderungen für ihre tägliche Arbeit, die auf sie zukommen. Klar hat man vorher schon davon gehört, aber alles war ja noch so weit weg und die Hektik im Alltagsgeschäft hat eine weitere Beschäftigung mit dem Thema verhindert. Oder man hat die bevorstehenden Veränderungen aus verschiedenen Gründen einfach beiseitegeschoben: zu viel Hektik, Verdrängung, Hoffnung es möge nicht kommen, etc. Der komplette Erfolg oder Misserfolg der vorangegangenen Change-Management- und Kommunikationsmaßnahmen wird in Schulungen deutlich. Schulungen sind der Lackmustest für gelungenes Change-Management. Zudem kann man in der (hoffentlich vorhandenen) Schulungsumgebung die ersten Erfolge einer Datenmigration in der Praxis testen.

Die Crux mit Power Usern

Im oben beschriebenen Fall waren die vorherigen Maßnahmen offensichtlich wenig erfolgreich. Aber wie konnte es überhaupt so weit kommen? Man hat doch so gut mit den Fachbereichen zusammengearbeitet – schon bei der Vorstudie. Gemeinsam wurden Ist- und Sollprozesse erhoben. Ein Lastenheft wurde erstellt und von allen beteiligten Stakeholdern unterzeichnet. Daraus ist ein Pflichtheft entwickelt worden, danach ist die Umsetzung mit der Unterstützung aller Bereiche erfolgt.

Die Projektleitung war stolz und froh, kompetente Ansprechpartner in den Fachbereichen zu finden. Neben der lokalen Management-Attention wurden Power-User am Hauptstandort identifiziert, mit denen man im Projekt vertrauensvoll zusammengearbeitet hat. Schließlich war dies in bisherigen Projekten ein Schwachpunkt gewesen. Aus den verschiedensten Gründen war damals die Unterstützung aus den Fachbereichen suboptimal. Daraus hat man gelernt. Ansprechpartner aus den Fachbereichen wurden benannt. Trotz ihrer knappen Zeit standen sie zur Verfügung und waren tief im Projekt eingebunden.

Trotzdem bestand anscheinend eine Lücke zwischen den „Daily Usern“ und dem neuen Projekt.

Dies habe ich oft beobachtet während Konzeptionsphasen und Konzepttest: Die Ansprechpartner in den Fachbereichen waren Manager oder Power User, die viel Ahnung und guten Willen haben – sich von der Basis aber inzwischen weit entfernt hatten. Bei Power-Usern gibt es eine größere Technik-Affinität und damit ein besseres Verständnis für technische Hintergründe. Sie besitzen zudem eine hohe Motivation, welches eine größere Leidensbereitschaft miteinschließt. Manager aus Fachbereichen kennen die unternehmerischen Hintergründe für Projekte (die sie nicht immer kommunizieren dürfen). Dies erhöht ihre Bereitschaft, sich auf neue Systeme einzulassen – trotz offensichtlicher Nachteile für ihre Mitarbeiter. Für Projektleiter sind solche Ansprechpartner „ein Segen“ – zuverlässig, motiviert, verständig, hart im Nehmen. Mit ihnen läuft das Projekt prächtig – bis zur Schulung…

Lieber später als früher?

Natürlich stellt sich bei Projekten auch immer die Frage, ob man vorab die Tragweite neuer Systeme oder Produkte wirklich den Kolleginnen und Kollegen mitteilen möchte. Ich habe in einem früheren Blog-Beitrag über die Einführung von CRM-Systemen darüber „gelästert“. Leider kommt dies in der Realität öfters vor, als man denkt. Man preist gegenüber den Fachbereichen, dem Betriebsrat und der Mitarbeiterschaft die Vorteile der neuen Systeme. Dass sich mit der Einführung die Prozesse ändern wird nur beiläufig erwähnt oder nur die positiven Auswirkungen herausgestellt. Dass man außerdem mit den neuen Prozessen auch etwas bewirken möchte (schnelleres Arbeiten, Standardisierungen, verringerte oder verlagerte Verantwortung etc.) noch weniger. In den Schulungen kommt dann die Wahrheit (meistens) ans Licht. Arbeitsabläufe und Verantwortlichkeiten (und damit Machtverhältnisse) verändern sich – oft werden sie eingeschränkt und durch neue Systeme begrenzt. Diese können bedeutend anders sein, als was man vorher kommuniziert hat – absichtlich oder unabsichtlich.

Als Trainer oder Schulungsleiter dürfen Sie sich nicht für neue Prozesse verantwortlich zeigen (wie schon in meinem Artikel über Selbststeuerung erläutert). Gibt es Fragen, Irritationen oder Ärger sind verantwortliche interne Manager hinzuzuziehen. Gerne werden die IT oder der Systemhersteller als Schuldige ausgemacht („das System ist halt so, da kann man nichts machen“). Aber über dieses Stöckchen sollten Verantwortliche heutzutage nicht mehr springen. Inzwischen weiß fast jeder, wie konfigurierbar heutige IT-Systeme sind – und dass eine vorgegebene Arbeitsweise meist Absicht ist. Frustration und schlechte Stimmung bei den Kollegen sind die Folge.

Merke ich solche Probleme, hole ich mir interne Verantwortliche dazu. Eine einfache Frage-und-Antwort Session hilft oft schon sehr viel, um Vertrauen wiederherzustellen. Nicht selten sind es Missverständnisse, die Irritationen schaffen, und keine „böse Absicht“.

Lessons learned

Gab es in Schulungen „Phänomene“ wie oben beschrieben, sollte man als Konsequenz die folgenden „Lessons Learned“ für Folgeprojekte in Betracht ziehen:

  • So sehr man es als Projektverantwortliche liebt mit Power Usern aus den Fachbereichen zusammen zu arbeiten: es sollte geprüft werden, ob dies ausreicht. „Normale“ daily User werden meist benötigt – schon in der Prozesserhebungsphase, erst recht bei den Prototypen und bei Konzepttests. Sie haben oft einen anderen Blickwinkel auf die Arbeitsweise und können auf mögliche Probleme hinweisen, sei es technischer, organisatorischer oder zwischenmenschlicher Art.
  • Jeder weiß es, dennoch wird es gerne vergessen: User aus den Fachbereichen benötigen Zeit, um an Projekten mitzuarbeiten. Oft kommt die Mitarbeit „on top“ zu ihren regelmäßigen Aufgaben dazu. Dementsprechend werden die zusätzlichen Aufgaben „geliebt“ und oft mit niederer Priorität (und Motivation) behandelt.
  • Verschiedene Standorte haben verschiede Anforderungen an ein Projekt. So selbstverständlich dies klingt, so gerne wird es in der Praxis vernachlässigt. Aus Kosten- und Zeitgründen werden Niederlassungen gerne vernachlässigt. Vieles kann man mit modernen Kommunikationstools lösen – aber nicht alles. Der Besuch vor Ort ist erforderlich. Die Kosten hierfür sind geringer als spätere Nachbesserungen in der Lösung.
  • Manager aus den Fachbereichen haben den Überblick über die Change-Management Maßnahmen ihres Unternehmens und viele Maßnahmen sind für sie selbstverständlich – bei den Mitarbeiterinnen und Mitarbeitern kann dies anders sein. Es sollte daher überprüft werden, ob der Kenntnis- und Verständnisstand auf dem selben Level sind.
  • Wie sieht das Kommunikationskonzept aus? Gibt es überhaupt eines? Nur ein kleines Beispiel: Ein Unternehmen wusste, der Unternehmensnewsletter wird kaum gelesen. Daher entschied man, große Banner in der Kantine aufzustellen. Daneben ein Stand mit Kollegen, die über die kommenden Änderungen Auskunft gaben. Ich könnte viel schreiben über Kommunikationskonzepte bei Projekten (und tue dies vielleicht in einem eigenen Beitrag).
  • Last but not least: der Betriebsrat wurde ja bestimmt schon früh in die Projektplanungen mit einbezogen, oder?!?

Mitnehmen, einbeziehen, proaktiv informieren – alles Grundsätze des Change-Managements. Doch in der Praxis immer noch viel zu wenig beachtet. Bis die Schulung kommt…

Haben Sie Fragen zu Schulungen oder Change-Management im Allgemeinen? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

1 Jahr Berater-Blog!

Schnell ging das Jahr vorbei – vor einem Jahr fing ich diesen Blog an.

1 Jahr Berater-BlogWie schrieb ich vor einem Jahr:

„Noch ein Blog? Muss das sein? Dies war meine erste Reaktion auf meine eigene Idee, einen Berater-Blog ins Netz zu stellen. Die Idee kam mir, als ich aus familiären Gründen eine berufliche Pause einlegte. Ich hatte abends viel Zeit und suchte im Netz nach einem Blog mit Geschichten aus der Sicht eines Beraters wie mich – der Projekte oder Programme leitet oder als Interimsmanager tätig ist. Ich dachte, so etwas musste es doch geben. Einen Platz im Netz, wo sich ein oder mehrere Berater / Beraterinnen austauschen, sich gegenseitig Tipps geben oder einfach mal Anekdoten erzählen. Fündig wurde ich nicht.“

Und da ich nicht fündig wurde, begann ich zu schreiben:

Ironisch oder ernst, lang oder kurz. Der Zuspruch war mal größer, mal kleiner. Google ist mittlerweile mein Freund, der mir viele Leserinnen und Leser auf meinen Blog bringt (schön, mal SEO im Kleinen zu erleben…). Bei fachlichen Beiträgen steigt der Traffic langsam, aber stetig. Persönliche Beiträge haben anfangs direkt einen hohen Traffic, dieser ist aber schnell wieder vergänglich.

Was gibt es über dieses Jahr zu berichten?

Am meisten war ich über den Traffic und die Resonanz des Beitrags „Die dunklen Tage des Beraterlebens“ erstaunt. Dieser Beitrag lag schon ewig auf meiner Festplatte, aber ich traute mich nicht ihn zu veröffentlichen – zu dunkel, zu negativ. Allerdings sind alle Fakten in dem Beitrag aus der Realität. Einige wenige habe ich selbst erlebt, viele andere aus Gesprächen erfahren (aber stark abgeändert, um Wiedererkennung zu vermeiden). Gelesen habe ich etwas Ähnliches aber noch nirgendwo. Selbstständige Berater gelten in den Unternehmen oft als Stars, die viel verdienen und wenig arbeiten. Umso mehr freute ich mich über die viele Resonanz (wenn auch meist persönlich).

Über das große Interesse an meinen beiden Kanban-Beiträgen („Kanban nicht nur für Softwareentwicklung“, „Was gegen Kanban spricht…“) bin ich sehr erfreut. Auf den Traffic bezogen sind es meine erfolgreichsten, fachlichen Beiträge. Kanban war vor einiger Zeit mal „the next big thing“ in der Entwicklung (nicht nur in der IT), aber irgendwie kam es nicht über diesen Status hinaus, was ich schade finde. Gerne wäre ich an Meinungen interessiert, warum dies so ist. Da ich einige neue Erfahrungen gemacht habe und einiges an Feedback bekam, werde ich demnächst wieder über Kanban schreiben.

Verwundert hat mich hingegen, dass meine Serie über komplexe Projekte weniger Resonanz gefunden hat, als von mir erhofft. Es hat mich viel Zeit gekostet, die Serie zu erstellen (aber ich habe auch viel Spaß gehabt). Ich finde den Umgang mit Annahmen, unbekanntem Wissen, hoher Dynamik und angeblicher Vertraulichkeit immer wieder spannend. Mit Methoden wie PESTLE zu arbeiten macht immer Spaß. Allerdings hätte ich mir hier mehr Reaktionen gewünscht. Haben Sie die Beiträge nicht interessiert? Enthielten die Beiträge für Sie keinen Mehrwert?

Daher meine Bitte: Feedback, Feedback, Feedback. Es ist schön, wenn ich zu hören bekomme, wie gut mein Blog gefällt. Konkreteres Feedback, Kritik und Tipps für weitere Beiträge würde mir noch mehr helfen. Am besten als Kommentare direkt unter die Beiträge – damit eventuell sogar mal Diskussionen entstehen (bitte beachten Sie, dass ich aufgrund des Spam-Aufkommens alle Beiträge freischalten muss). Ich weiß von anderen Blogs, die viel mehr Traffic haben als meiner, dass Kommentare aus der Mode kommen. Daher bitte ich hier mal direkt darum. Sonst gehen mir irgendwann vielleicht doch mal die Ideen aus 😉 .

Wie geht es weiter?

Mein Vorrat an Beiträgen, den ich damals während meiner Auszeit angelegt hatte, ist inzwischen längst aufgebraucht. Noch habe ich aber immer wieder Ideen für neue Beiträge bekommen. Die Praxis und Gespräche mit Kollegen liefern immer noch die besten Geschichten 😛 . Solange dies der Fall ist, lebt mein Blog weiter. Falls allerdings einmal der Zeitpunkt gekommen ist, dass mir die Ideen ausgehen, habe ich auch keine Probleme damit diesen Blog einzustellen. Schließlich lebe ich nicht davon, der Blog bringt mir nichts ein – keine Werbung, keine illegale Datensammlung (siehe „Datenschutz“). Meine Maxime: jeder Beitrag soll einen Mehrwert bringen, den ich woanders noch nicht gesehen habe.
Wie gesagt: keine Ideen mehr, keine weiteren Blog-Beiträge. Es sei denn – meine Leserinnen und Leser haben Ideen für Themen, die ich mal aufgreifen könnte. Daher wiederhole ich meine Bitte von oben: Feedback, Feedback, Feedback. Lob oder kritisch – alles wird gerne entgegengenommen.

Und ein Gastbeitrag wäre natürlich ein Traum…

Ich freue mich über die Resonanz auf meinen Blog und hoffe, auch weiterhin zahlreiche Leserinnen und Leser auf meiner Seite begrüßen zu dürfen.

Und wie immer zum Abschluss: haben Sie Fragen? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

Scrum aus falschen Beweggründen kann nicht funktionieren!

Vier Gründe, warum Scrum in Unternehmen scheitert – und wie man es besser machen kann.

ScrumIrgendwie ist es doch merkwürdig. Früher scheiterten anscheinend die meisten Softwareprojekte. Man war unflexibel, die Anforderungen wurden von der langen Projektlaufzeit überholt, Mitarbeiter waren nicht „committed“, wer RUP wirklich verstand war ein Theoretiker und nicht zum Coden geeignet, usw.

Daher besann man sich auf agile Methodiken. Aber hört man sich um, liest im Netz und spricht mit Kolleginnen und Kollegen, dann scheitern wieder viele Softwareprojekte – trotz Scrum und Co. Suchen Sie mal in Ihrer präferierten Suchmaschine nach „Scrum scheitern“ und Sie werden erstaunt sein, wie viele Ergebnisse Sie bekommen…

Wenn Sie sich dann die Gründe durchlesen, warum Projekte scheitern, sehen Sie Begründungen wie diese:

  • Keine Disziplin im Kollegenteam und bei Vorgesetzten
  • Das Team ist nicht committed für agile Methodiken
  • Das Umfeld im Unternehmen unterstützt agile Methodiken nicht
  • Der Scrum Master wird „missbraucht“ für viele andere, artfremde Aufgaben
  • Der Product Owner „zerbricht“ in der Sandwich-Position

Und so weiter. Alles gute Gründe, Sie und ich haben bestimmt auch öfters schon in der Realität einige erlebt. Dennoch ist meine Vermutung für das Scheitern aber eine andere: viele Unternehmen haben einfach die falschen Gründe, warum sie agile Methodiken wie Scrum einführen wollen. Und dann müssen Scrum, XP und andere agile Methodiken natürlich scheitern.

Bestätigt wurde ich wieder in meiner Vermutung, als ich von einiger Zeit folgende Anfrage in einem Mail-Verteiler las:

„Unternehmen sucht Unterstützung (…) Scrum wurde auf Wunsch einiger Vorgesetzter eingeführt (…) nun fragen wir uns, ob wir die richtigen Mitarbeiter dafür haben… (…) benötigen Hilfe.“

Oh! Meine! Güte! Und nein, dies habe ich nicht erfunden. Diese Anfrage ist aber ein typisches Beispiel für ein Problem bei der Einführung agiler Methoden. Daher möchte ich Ihnen im Folgenden die vier wichtigsten Gründe vorstellen, warum Scrum-Einführungen scheitern.

Problem 1: Scrum „von oben“

„Wir bringen da mal frischen Wind rein…“

Das Management ist unzufrieden mit der IT-Abteilung. Zu langsam, zu teuer, zu viel Widerstand gegen neue Ideen…

Statt den vermeintlichen Problemen durch Ursachenforschung zu begegnen, vorhandene Prozesse zu analysieren, Brüche zu identifizieren oder in den Dialog mit den beteiligten Bereichen zu gehen, wird beschlossen Scrum einzuführen. Ein weiterer, vielverbreiteter Grund: auf Managementebene findet ein Umbruch oder ein Generationswechsel statt. Die neue Mannschaft will sich profilieren, „neuen Wind ins Unternehmen bringen“ oder einfach Aktivität zeigen („in Zeiten wie diesen müssen wir agil werden…“). Egal, welche Gründe es sind, die Einführung findet „von oben“ statt, ohne vorherigen Dialog oder Analysen mit den Betroffenen. Kann so etwas funktionieren? Wohl nur schwer.

Dazu kommt eine Unkenntnis, was die Einführung agiler Methodiken eigentlich bedeutet. Mit Scrum bringt man nicht mal eben „die Entwicklung auf Vordermann“. Agiles Vorgehen setzt eine vertrauensvolle Zusammenarbeit aller Beteiligten auf Augenhöhe voraus. „Von oben“ muss es dazu Ermutigung, Ermächtigung und Unterstützung geben. Schließlich heißt es im Agilen Manifest „Customer collaboration over contract negotiation“. Ist dies der Fall bei einer Einführung „von oben“ – wenn der „Contract“ von einer Seite vorgegeben wird? Wohl eher nicht. Scrum ist eben nur ein Werkzeug, die Kultur dafür muss geschaffen werden. Die in einem Unternehmen herrschende Kultur muss dem agilen Wertesystem gegenüber aufgeschlossen sein oder geschaffen werden, sonst ist der Einsatz von Scrum zum Scheitern verurteilt!

Im Grunde ist es wie mit allen Neuerungen, die ohne Einbeziehung der betroffenen Bereiche „von oben“ eingeführt werden. Die Mitarbeiter fühlen sich nicht eingebunden, berechtigte Argumente und Ängste werden nicht gehört. Frustration ist oft die Folge.

Problem 2: Scrum „von unten“

„Die verstehen uns sowieso nicht…“

Die IT-Abteilung ist unzufrieden. Sei es mit den momentanen internen Entwicklungsprozessen, sei es mit der Einsicht, dass Wasserfall nicht mehr zum heutigen Business Modell „passt“, sei es mit der Kommunikation mit anderen Bereichen oder dem Management. Statt den Dialog zu suchen (oder die Meinung zu vertreten, dass ein Dialog zu nichts mehr führt) führt man Scrum quasi „von unten“ ein. Man beginnt in der Entwicklung agil zu agieren und hofft, dass andere Bereiche dann mitziehen. Eine solche Einführung muss aber früher oder später scheitern, wenn es die Abteilung nicht schafft, Support vom Management zu bekommen. So groß die begrenzte Optimierung bei der Entwicklung sein mag – wenn das Management es nicht zulässt, die angrenzenden Unternehmensbereiche zu ändern, wird der Ansatz schnell im täglichen Umgang mit anderen Abteilungen scheitern. Wie kann erfolgreich agil gearbeitet werden, wenn z.B. das Produktmanagement seine Arbeitsweise nicht umstellt? In den seltensten Fällen werden die angrenzenden Bereiche mitziehen und auch agil agieren.

Nun mag dies für eine einzelne Abteilung, die etwas verändern möchte, frustrierend klingen. Kann man sich nicht im kleinen, eigenen Bereich ändern? Doch man kann. Möchte man als Entwicklungsabteilung zeigen, dass eine agile Kultur Fortschritte bringt, dann sollten Sie es mit Kanban probieren (Mehr über Kanban erfahren Sie in meinen beiden Beiträgen hier und hier). Ja, Kanban ist keine agile Methodik, sondern eine Change Management Methode – weist aber in einigen Bereichen Ähnlichkeiten mit Scrum auf – und kann auch in lokalen Teams autark eingeführt werden und funktionieren (Und ja, ich weiß dass Kanban im eigentlichen Sinne keine Teammethode ist, aber mehr dazu ein andermal…).

Eine Organisation, die erlebt, dass eine einzelne Abteilung eine Methodik wie Scrum einführen möchte, sollte dies als Warnung ernst nehmen – als einen Hilferuf der (Entwicklungs-)Abteilung, dass es in ihren Augen so nicht weitergehen kann.

Problem 3: Scrum wegen übertriebener Agilität des Managements

„Mir ist gestern Abend mal eine Idee gekommen…“

Die Einführung von Scrum erfolgt „ganzheitlich“ im Unternehmen. Nicht nur die IT-Entwicklung soll agil arbeiten, sondern auch andere Bereiche und sogar das Management. Hier gibt es einige besonders „agile“ Köpfe, die vor Ideen nur so um sich sprühen.

Dies hat Folgen. „Agilität“ im Management wird dazu genutzt täglich Anforderungen zu ändern, hinzuzufügen, zu löschen oder in ihrer Priorität zu ändern. Der Product Owner (der es nach längerer Zeit endlich geschafft hat, abends keine Emails mehr zu lesen) fürchtet sich vor dem morgendlichen „Email-Check“ was wieder alles neu gekommen oder geändert wurde über Nacht (Hallo, ehemalige Kolleginnen und Kollegen: erinnert Ihr Euch noch :razz:). Versuche, dies einzudämmen enden mit Bemerkungen wie „dafür sind wir doch agil geworden…“. Es gibt immer wieder Versuche des Managements sogar in laufende Sprints einzugreifen. Mit den Sprint-Ergebnissen (so kurz die Sprints auch sein mögen) ist man nie zufrieden, da man gedanklich das Produkt schon längst in andere Richtungen entwickelt hat (Weiterentwicklung ist hier wohl das falsche Wort).

Um hier das absehbare Scheitern zu verhindern, sollten alle Beteiligten daran erinnert werden – wie bei „Scrum von oben“ – dass agiles Vorgehen unbedingt eine vertrauensvolle Zusammenarbeit aller Beteiligten auf Augenhöhe voraussetzt. Hier stellt sich die Frage, wer dies dem „Management beibringt“ (Nehmen Sie gerne mit mir Kontakt auf 😀 ).

Eine mögliche Lösung wäre die zusätzliche Einführung von Kanban – und alle Beteiligten bekommen ein WIP (Work in Progress) Limit, sprich eine Begrenzung der Aufgaben, die sie maximal parallel bearbeiten können (schon im vorherigen Abschnitt habe ich über Kanban gesprochen). Auch wenn das Backlog mit der Zeit durch viele kreative Ideen anwachsen kann, die Tickets werden nach Wichtigkeit priorisiert und nur eine vorher definierte maximale Anzahl (das WIP Limit) kann in den verschiedenen Stufen bearbeitet werden. Wie viele Tickets mit welcher Wichtigkeit dann „nachrutschen“ wurde vorher definiert. Aber auch hier muss klar sein, dass beschleunigte Tickets (Expedite) nur Notfälle enthalten dürfen – und keine neuen nächtlichen Ideen sogenannter kreativer Menschen.

Eine andere Lösung wäre das Konzept des „Minimum viable product“, welches aus der Produktentwicklung – insbesondere für Startups – stammt. Das Konzept beruht darauf, schnell ein Produkt zu entwickeln, welches den Nutzern einen Mehrwert bringt und so deren Problem löst (es ist für sie nützlich – „viable“). Die Betonung liegt bei dem Konzept auf EINEM Mehrwert. Anstatt in einer Version eine Vielzahl von Ideen zu realisieren (die sich nächtlich ändern können), einigt man sich auf eine Komponente, die dann aber schnell entwickelt wird. Dadurch zwingt man allzu agile Menschen sich zu fokussieren und sich für eine Komponente zu entscheiden. Diese ist dann aber zu präzisieren, da der Funktionsumfang ja begrenzt ist.

Das schnell entwickelte Produkt oder System besitzt wirklich nur diesen minimalen Funktionsumfang („minimum“). Weitere Funktionen lenken zudem nicht von seiner eigentlichen Aufgabe, das eigentliche Problem zu lösen, ab. Die kurze Entwicklungsdauer (und das Konzept an sich) hat einige Vorteile – in unserem Fall aber gibt sie dem ungeduldigen Management schnell was zum Spielen. Anhand des fertigen Produkts kann entschieden werden, in welche Richtung es weiterentwickelt werden soll (im Idealfall kommt dieser Input vom Kunden).

Die übertriebene Agilität einfach zu erdulden ist keine Lösung. Der Product Owner wird irgendwann aufgeben, die genervten Teammitglieder werden individuell für sich Lösungen finden.

Problem 4: Scrum wegen fehlender Vision

„Wir haben keine Vision, aber wir fangen mal an…“

Dieses Problem hat Ähnlichkeiten mit dem vorherigen Punkt, ist aber noch schlimmer. Das Unternehmen (oder ein Bereich des Unternehmens) befindet sich in einer Krise, die Leitung hat keine oder nur eine vage Vision für die Zukunft. Es erscheint nicht möglich oder willens, eine Vision, Mission und konkrete Ziele daraus abzuleiten.

Also beschließt sie, Scrum einzuführen. Mit Sprints kann man innerhalb von vier Wochen Ergebnisse produzieren, die man vorführen kann. Mal sehen, wie der Kunde darauf reagiert…

Sicher sind Methodiken wie Scrum geeignet, um den Wert von Features auszutesten und zu verfeinern. Schon oben sprach ich zudem über das „Minimum viable product“ Konzept. Aber ohne die Richtung zu kennen – eine Vision zu haben – geht es nicht. Wenn Unternehmen keine Vision – kein Fernziel – für ihre Organisation haben, wird es schwer einen Wandel anzustoßen. Es sollte eine Ideal-Vorstellung geben, wo sich ein Unternehmen in den nächsten Jahren sehen möchte. Scrum ist nicht dazu geeignet eine Vision zu finden – man sollte Scrum nicht überschätzen. Im Gegensatz dazu bietet das Gebiet des Strategischen Managements genügend Methoden und Maßnahmen, wie Unternehmen zu einer Vision, einer Mission und – daraus abgeleitet – zu konkreten Zielen kommen. Als Beispiele seien hier die Analyse und Erstellung von Wettbewerbsstrategien, Geschäftsmodellen oder Unternehmensstrategien etc. genannt. Diese Arbeit wird benötigt, bevor man an die Umsetzung herangeht. Ohne diese „eiert“ man herum – ohne Ziel kein Weg…

Für mich sind dies die Hauptgründe warum Scrum – meistens bei der Einführung oder kurze Zeit danach – in Unternehmen oder Bereichen scheitert. Sicher, Scrum kann auch nach einer erfolgreichen Einführung und einigen Projekten nach längerer Zeit irgendwann scheitern. Es hat sich alles eingespielt, aber langsam verlässt man doch wieder den agilen Pfad. Dies ist aber eine andere Geschichte…

Haben Sie Fragen zur Einführung von Scrum oder anderen agilen Methodiken in Unternehmen? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

P.S.: Wussten Sie schon, dass Punk und Scrum viel gemeinsam haben?!?

Frohe Weihnachten und einen guten Rutsch!

Frohe Weihnachten

Frohe Weihnachten

Allen Leserinnen und Lesern wünsche ich frohe Weihnachten, einige geruhsame Feiertage und einen guten Rutsch in das Jahr 2016.

Mein Blog ruht bis Mitte Januar und geht dann mit – für Sie hoffentlich spannenden – Beiträgen weiter.

Beitrag verpasst?

Sport ist wichtig für Unternehmen und für die eigene Karriere!

Meine kleine Serie über komplexe Projekte – Unbekanntes, Annahmen, Abhängigkeiten und Wechselwirkungen in Projekten…

Viel wird über virtuelle Teamarbeit geredet. Hier ein Beitrag, wie man verteilte Teams führt…

Auch über die Feiertage können Sie mich gerne kontaktieren! Bitte erlauben Sie mir einige Tage, bis ich mich bei Ihnen melde.

Die dunklen Tage des Beraterlebens…

Nicht alle Beratertage sind lustig, nicht alle Mandate machen Spaß…

Ein winziges Hotelzimmer mit Blick auf einen See. Eine Flasche Wein und Fastfood (heute Pizza) vor einem. Das Notebook aufgeklappt mit SPON auf dem Schirm. Die Pizza trieft vor Fett und schmeckt nach der Pappe des Kartons in dem sie liegt. Als Du mit dem Karton aufs Zimmer gingst, hast Du versucht den bösen Blick der Dame an der Rezeption zu übersehen.

Das Hotel W-LAN ist grottenlahm, die Verbindung via Skype mit zuhause entfällt. Kurzes Hallo übers Mobiltelefon, da die Roaminggebühren (Nicht EU-Staat) sonst die Aufnahme eines Kleinkredits erfordern würden.


Dein Tag war Scheiße. Es wird immer klarer, dass man Dich als Projektleiter nur als Sündenbock für ein gescheitertes Projekt geholt hat. Wahrscheinlich wollte man deswegen jemanden aus dem Ausland haben. Die Präsentation mit den Möglichkeiten für ein weiteres Vorgehen des Projekts (in deep shit), die in langer Arbeit von Dir erstellt wurde, ist von den Stakeholdern genüsslich zerpflückt worden – mithilfe von Informationen, die Du nie hattest und daher nicht berücksichtigen konntest. Dein Auftraggeber fiel Dir (offensichtlich bewusst) in den Rücken, anstatt Dich zu unterstützen. Natürlich war Deine Präsentation vorher mit ihm abgestimmt. Zudem entwickelte sich ein Disput zwischen den Stakeholdern, wie Du erkanntest nicht zum ersten Mal. Ein typisches Gegen- statt Miteinander.

Nun hast Du verstanden, dass Du als Bauernopfer im Streit zwischen Bereichsleiterin A, Bereichsleiter B und dem CFO missbraucht wurdest. Du verstehst, warum Du eine Reihe von Stakeholdern vorher angeblich nicht kontaktieren konntest.

Am Ende des Tages saßt Du in einem Glaskasten, welchen man neudeutsch „flexible office“ nennt, in einem großen Unternehmen in einer fremden Stadt. Dieses Mal stand niemand in der Tür. Du bist der gescheiterte Projektleiter, nicht jemand anderes. Niemand hat mir Dir nach dem Meeting mehr gesprochen, allerdings passte „Enjoy the silence“ nicht wirklich zu Deiner Gemütsverfassung. Andererseits bestand so nicht die Gefahr, dass Du Dich bei jemanden „auskotzt“ – ein extrem unprofessionelles Verhalten, welches Du bei anderen sonst immer (still) kritisierst.


Zurück im Hotelzimmer. Nachdem die SPON-Seiten endlich aufgebaut wurden, wechselst Du zum Handelsblatt. Die Kurse Deiner Aktien sind schon wieder gefallen. Mit Frührente wird es wohl nichts.

Flasche leer, gute Nacht…

Leider wird im Gastraum unter Deinem Zimmer heute mal wieder gefeiert, keine Ahnung was diesmal. Jedenfalls findest Du vor 2 Uhr keinen Schlaf.

Nächster Morgen, ein Blick aus dem Fenster – es hat gefroren und ist neblig. Kein See in Sicht. Nachdem Du zwei Minuten auf halbwegs warmes Wasser gewartet hast, zwängst Du Dich in die Mini-Dusche – auf der Webseite des Gasthofs als „Wellness-Dusche“ angepriesen, wegen der zwei zusätzlichen Duschköpfe aus denen ab und zu etwas Wasser tröpfelt.

Später im Frühstücksraum – das Frühstücksbuffet ist sehr übersichtlich (landestypisch, laut Webseite), anders als die Zimmerpreise. Messezeit. Männer in grauen Anzügen und Frauen in anthraziten Kostümen starren auf ihre Smartphones und essen still ihr karges Frühstück. Als Hintergrundmusik läuft eine Schlagerwelle. Zum Glück kannst Du die Texte nicht verstehen.

Beim Auschecken versuchst Du zu erklären, dass Du nichts aus der Minibar genommen hast. Die Dame an der Rezeption behauptet etwas Anderes. Zuletzt lässt sie „Gnade vor Recht ergehen“ und erlässt Dir die angeblichen Schnäpse und die Nutzung des Porno-Kanals (beides von Dir nicht angerührt). Du versuchst ein vorgespieltes Dankbarkeitslächeln aufzusetzen. Dein Gesicht, welches Du im Spiegel hinter ihr siehst, beweist das Misslingen dieses Versuchs.

Die Scheiben Deines Autos, welches am Seeparkplatz steht, sind dick vereist. Du benötigst 10 Minuten zum Kratzen, bis Du den Strafzettel findest.


Im Office Deines Auftraggebers holst Du Dir erst mal einen Kaffee. Der Kaffee wird nicht ohne Grund bei den internen Mitarbeitern „Plörre“ (le pleur), genannt. Trotzdem trinkst Du zu viel davon.

Du machst Deine Abschlussarbeiten. Protokolle schreiben und verteilen. Auf einen Folgeauftrag willst Du gar nicht hoffen. Du hast den Eindruck, dass alle Dich böse anschauen – dies ist aber mit Sicherheit nur Einbildung. Die Sekretärin Deines Auftraggebers (body woman) funkelt Dich aber wirklich böse mir ihren Augen an. Nein, Herr XXX hat heute keine Zeit für Dich, Du mögest Deinen Abschlussbericht bitte per Mail schicken. Du bist einerseits erleichtert (Feigling!), andererseits frustriert und hast ein schlechtes Gewissen. Schließlich weißt Du was Du kannst und aus welchen Gründen Du es dieses Mal nicht zeigen konntest. Du erarbeitest den ganzen Tag Deinen Bericht mit allen Dir zur Verfügung stehenden Informationen. Du berücksichtigst insbesondere die Erkenntnisse aus dem Meeting von gestern, inklusive wie mit den unterschiedlichen Sichtweisen der Stakeholder umzugehen wäre. Du inkludierst in Deinem Bericht unterschiedliche Lösungsansätze für weitere, mögliche Vorgehensweisen – und weißt doch, dass Dein Report nie gelesen wird.

Bevor Du Deine Sachen packst, verabschiedest Du Dich von den Kolleginnen und Kollegen vor Ort. Sie klagen Dir ihr Leid, wie deprimierend ihre Arbeit ist und die Stimmung im Unternehmen doch sei. Seit Jahren denken sie an Kündigung. Du weißt, sie bleiben bis man ihnen kündigt. Du hast dies so oft erlebt. Trotzdem versuchst Du ihnen Mut zuzusprechen und ihr tauscht Kontaktdaten aus. Wie immer wirst Du nie wieder etwas von ihnen hören. Acta est fabula (aus welchem Asterix-Band war das denn noch?) …

Nichts wie ab nach Hause. Ruhiges Wochenende und dann ab Montag wieder Klinkenputzen für das nächste Mandat. Audentis fortuna invat (Vergil in Aeneis, nicht Asterix…).

Du stehst im Stau auf der Autobahn – typischer Freitagnachmittag. Der Schneeregen macht es nicht besser. Der Verkehrsfunk und Dein Navi versprechen insgesamt 35 km Stau bis zuhause. Nebenan rast ein ICE vorbei. Als Du den Zug schnell vorbeifahren siehst bekommst Du so merkwürdige Gedanken. Was wohl wäre, wenn Du jetzt…

Ach Blödsinn, Festanstellung ist kein Thema mehr für Dich.

Da fließt der Verkehr wieder. Du fährst nach Hause. Familie wartet…


OK – so kann ich das natürlich nicht stehen lassen. Zunächst: dies ist ein FIKTIVER Blog-Beitrag mit Einflüssen aus allen möglichen Quellen. Er bezieht sich nicht auf mich!

Um die Dunkelheit wieder zu vertreiben, verweise ich hier auf meine „hellen“ Beiträge über Gesprächsführung, Selbststeuerung und komplexe Projekte – damit die dunklen Seiten bei niemand über Hand nehmen! Dennoch wollte ich mal solche, mir mitgeteilte Impressionen aufzeigen – weil ich sonst so etwas in anderen Blogs nicht lese. Ein solcher Beitrag ist für mich ein Experiment und ich bin gespannt auf Ihre Reaktionen und auf die Zugriffszahlen.

Wenn Sie darüber hinaus Fragen haben oder Informationen haben möchten, dann kontaktieren Sie mich. Ich freue mich, Ihre Fragen zu beantworten. Übrigens „Acta est fabula“ ist aus dem Asterix-Band „Die goldene Sichel“.

Selbststeuerung für externe Berater in Projekten, Teil 2

Worst-Case-Szenarien, verlorene Projektkontrolle, Mikromanagement und ja: we’re only in it for the money!

Selbststeuerung

Selbststeuerung

Wer steuert mich als externer Berater in Projekten beim Mandanten? „Ka Sau“ (ungefähr: Niemand) – außer ich mich selbst. So zusammengefasst begann ich meinen vorletzten Blog-Beitrag und berichtete über die Metapher der drei Schwäne – für die drei Steuerungsebenen Praxis, operative Ebene und Metaperspektive. Zudem lud ich dazu ein, die Methode des Rollentauschs mal für sich selbst anzuwenden, um herauszufinden wie Projektbeteiligte die Projektleiterin / den Projektleiter (sprich: Sie) sehen und beurteilen. Nach viel Theorie im ersten Teil möchte ich dies mit einigen Hinweisen und Beispielen in meinem heutigen Beitrag vertiefen. Beginnen möchte ich mit den Ängsten über das Scheitern von Projekten – und damit die Methode des Rollentauschs umzukehren.

Worst-Case-Szenario klären und Ängste nehmen

„Der Erfolg unseres Projekts ist alternativlos“ – unbekannt

Jedes Projekt bedeutet Veränderung – zum Guten oder auch zum Schlechten. Viele Mitarbeiter werden skeptisch, wenn sich durch ein Projekt ihr Arbeitsbereich, ihre Verantwortung, ihr Umfeld ändert. Viele haben Ängste – geäußert werden diese Ängste aber in den wenigsten Fällen. Und wenn, dann in der Kantine, bei einer Zigarette oder in der Kaffeeküche mit Kollegen. Zudem ist es Fakt – Projekte können scheitern. So gut wie jeder Mitarbeiter hat dies schon „am eigenen Leib“ erlebt. Und auch für Berater ist dies nicht neu (es soll sogar Fälle geben, in denen Berater als Sündenbock fürs Scheitern geholt werden – aber dazu wird es einen eigenen Blog-Beitrag geben). Manche Projekte scheitern sogar total, mit einem Crash – das Worst-Case-Szenario in der Praxis.

Aber was ist das Worst-Case-Szenario bei einem Projekt? Jeder Projektbeteiligte hat eine andere Sicht über sein / ihr persönliches Worst-Case-Szenario – solange man nicht darüber spricht. Das Projekt ist in Schwierigkeiten (wenn ich ein Mandat bekomme ist dies oft der Fall). Was passiert, wenn das Projekt scheitert? Welche Konsequenzen erfolgen daraus?

Reden Sie darüber! Denn Angst ist ein großes Hindernis und Hemmnis. Als Vorbereitung für Ihre Gespräche können Sie den Rollentausch vornehmen, indem Sie sich in andere Personen hineinversetzen und versuchen, deren Ängste zu verstehen. Sammeln Sie dann in offener Aussprache die Worst-Case-Szenarien der Betroffenen und analysieren Sie offen, welche davon wirklich eintreten können. Viele Szenarien sind unrealistisch oder gar unmöglich. Andere können durchaus eintreten und sollten im Risikomanagement aber auch individuell für einzelne Projektbeteiligte berücksichtigt werden. Ein gemeinsames Verständnis über die Risiken schafft Vertrauen und baut Ängste ab. Der Anfang einer solchen Analyse mag zäh sein – wer outet sich schon gerne. Vielleicht beginnen Sie mit Einzelgesprächen, dies hängt auch von der Atmosphäre im Unternehmen ab. Oder fangen Sie in einer kleinen Gruppe mit Ihrer Vorstellung über ein Worst-Case-Szenario mit sich selbst an. Vielleicht hören Sie dann von anderen Beteiligten, warum dieses Szenario eher unwahrscheinlich ist. Und schon ist die Diskussion im Gange. Neben der Klärung der Szenarien und der Vervollständigung Ihres Risiko Managements nehmen Sie damit oft „Druck aus dem Kessel“ und schaffen ein besseres und offeneres Klima.

Mikromanagement – ich doch nicht!

„Ich bin von Clowns und Zombies umgeben, also mache ich am besten alles selbst.“ – Nicolas Sarkozy

Zum Thema „Kontrolle über mich selbst“ (diskutiert im ersten Teil des Beitrags) passt natürlich das Problem des „Mikromanagements“. Suchen Sie mal im Web mit der Suchmaschine Ihrer Wahl nach dem Stichwort „Mikromanagement“. Ich habe brüllend gelacht, als ich einige Seiten mit Ratschlägen dazu gelesen habe (und verzichte hier auf Links). Als erfahrener Projektmanager vermeiden Sie normalerweise natürlich Mikromanagement, oder? In welchen Situationen passiert es Ihnen, dass Sie zum Mikromanager werden? Oder planen Sie direkt bei neuen Mandaten Mikromanagement zu betreiben?

Interessanterweise habe ich die Erfahrung gemacht, Mikromanagement anzuwenden trifft auf externe Berater noch mehr als auf andere Personen zu (wie sind Ihrer Erlebnisse hierzu?). Gerade weil erfahrene, externe Berater „schon so viel gesehen haben“, trauen sie anderen Personen anscheinend wenig zu und möchten alles selbst erledigen („Eckhard, so viele Pferde, die ich schon kotzen sah, sieht keiner in seinem Leben“). Und ja, ich neige auch dazu – gerade wenn der Stress in einem Projekt sowieso schon groß ist. Dazu kommt, Sie kommen in neue Unternehmen und kennen die Personen dort meist nicht. Sie wollen aber den Erfolg (und den Folgeauftrag). Ausreden, warum man alles selbst machen möchte gibt es viele:

  • Es geht schneller, wenn ich es selbst erledige
  • Ich habe darin die meiste Erfahrung
  • Dafür wurde ich doch geholt als Berater
  • Niemand sonst hat dafür Zeit
  • Man sieht doch bei VW wohin Delegieren führt
  • etc.

Aber beobachten Sie sich mal aus der Perspektive eines Mitarbeiters des Unternehmens. Da kommt jemand Fremdes und reißt alles an sich. Nimmt Ihnen eventuell sogar Aufgaben oder Verantwortung weg. Gewinnen Sie damit den ersten Platz im Wettbewerb „Prince Charming“? Sicher nicht. Als erfahrene Führungskraft wissen Sie zudem: Delegieren heißt NICHT Wissen abgeben, sondern Arbeit verteilen. Auch in externen Projekten sollten Sie sich an diesen Grundsatz erinnern.

Dazu kommt: In komplexen Projekten können Sie mit Mikromanagement mittel- und langfristig nicht überleben. Irgendwann werden Sie unter der Last der Arbeit zusammenbrechen. Beobachten Sie sich mal selbst: Planen Sie noch spät am Abend eine Einführungsveranstaltung, weil Sie dem PMO das nicht zutrauen? Schauen Sie sonntags die neue Datenbankarchitektur durch, obwohl Sie dafür Experten im Team haben? Wenn Sie sich als Mikromanager erkannt haben, dann heißt es gegensteuern: Delegieren, anderen Projektbeteiligten Vertrauen schenken, Arbeiten verteilen. Erweist sich die gegebene Aufgabe als zu groß, kann man überlegen ob man zunächst Teilbereiche löst. Aber Achtung: auch hier lauern Gefahren – wie ich im Beitrag über komplexe Projekte beleuchtet habe.

Kontrolle über den Auftraggeber

„Machen Sie das – Sie sind der Experte…“

Gerade Change Management Projekte werden oft von externen Beratern geleitet. Ein Unternehmen hat die Notwenigkeit für einen Wandel festgestellt und eventuell sogar schon neue Ziele identifiziert. Für die Umsetzung fehlen dem Unternehmen aber die Ressourcen und / oder die Kenntnisse. Man holt sich dafür externe Hilfe. Für Sie als Berater ist das gut – ein weiteres Mandat. Vermeiden Sie aber bei solchen Projekten Verantwortung zu übernehmen, für Entscheidungen die nicht von Ihnen getroffen wurden. „Change“ bedeutet Veränderung. Veränderungen erzeugen oft Unstimmigkeiten und Nichtübereinstimmung. Ihr Auftrag ist es vom Ist-Zustand zu dieser Veränderung zu kommen. Sie sind aber nicht für die neuen Ziele verantwortlich. Diese Ziele zu erläutern und ggf. zu verteidigen ist Aufgabe des Managements des Auftraggebers. Natürlich werden Sie hinter diesen Zielen stehen – sonst könnten Sie ein solches Projekt schlecht leiten oder begleiten. Aber das interne Management muss diese Ziele vor den Mitarbeitern vertreten. Hier sollte die Aufgabenteilung immer klar sein. Es soll Fälle geben, indem sich das interne Management hinter den externen Beratern versteckt. Auch in den Medien wird gerne auf Beratungsgesellschaften geschimpft, die angeblich die „richtige“ – alternativlose – Entscheidung für Unternehmen vornehmen. Aber letztendlich muss das Management des Unternehmens diese Entscheidungen treffen und vertreten. Sie müssen sich auf Ihren Auftrag konzentrieren.

Auch sollten Sie der Gefahr widerstehen, sich mit den internen Kolleginnen und Kollegen zu solidarisieren – wie ich es schon einige Male in großen Projekten erleben musste. „Du hast ja Recht, das Projekt wird scheitern, die Ziele sind unrealistisch – aber was soll ich machen…“. So etwas ist ganz schlecht und einfach unprofessionell. Was will ein Berater damit erreichen? Im besten Fall erkennen die Mitarbeiter sein Bemühen an, sehen aber, dass er nichts ausrichten kann. Im schlechtesten Fall hingegen wird der Berater für missglückte Änderungen verantwortlich gemacht.

Können Sie sich allerdings nicht mit den Zielen identifizieren, sollen Sie sich beobachten und klären ob Sie der Richtige für die Leitung des Projektes sind.

Kontrolle verloren – Lost In Space

„Nachdem wir unser Ziel endgültig aus den Augen verloren hatten, verdoppelten wir unsere Anstrengungen.“ ―Mark Twain

Dieser, zugegebenermaßen ziemlich bekannte Spruch von Mark Twain passt sehr gut ins Projektmanagement.

Es soll Projekte geben, bei denen die Projektleitung die Übersicht verloren hat – die Kontrolle ist entglitten. Ich bin mir sicher, Ihnen ist so etwas noch nie passiert – aber sicher haben Sie von einem solchen Fall schon gehört :razz:.

Es gibt viele Gründe, warum so etwas geschehen kann. Ziele können sich verschoben haben (Sie wissen ja: ein Projekt benötigt ein Ziel), das Umfeld hat sich geändert, das Commitment der Stakeholder ging verloren, usw.
Was wird in solchen Fällen getan? Gerne wird auf Mikromanagement „umgeschaltet“, sprich: man beschäftigt sich mit kleinen Details (Sind die Schulungsräume richtig eingerichtet? Ist das Catering für den Testevent bestellt?) und ignoriert das große Ganze – bis es „knallt“ und/oder man abgelöst wird. Ist man „lost in Space“ muss man sich zunächst selbst eingestehen, dass man die Kontrolle verloren hat. Dieser erste Schritt ist wohl der schwerste. Beobachten Sie sich aus der Sicht des zweiten Schwans. Fliegen Sie noch in eine Richtung? Oder trudeln Sie mal hier hin, mal dort hin – meist in geringem Tempo.

Hat man dies geschafft, dann muss man dies gegenüber dem Projektteam zugeben – und Maßnahmen verkünden, wie man die Kontrolle zurück gewinnt. Auch hier greifen die üblichen Maßnahmen im Projektmanagement: Status aller Teilprojekte, Kostenkontrolle, Ressourcenübersicht – und auslastung. Und die wichtigste Frage ist zu überprüfen: Ist das Ziel des Projekts – die Erreichung einer Dienstleistung oder eines Produkts – noch dasselbe wie vorher? Gibt es noch ein Ziel?

Doch es können sich auch Kräfte (Machverhältnisse, Situationen etc.) rund um das Projekt verändert haben – oder auch nicht. Wir wissen es nicht so genau, weil wir die Kontrolle verloren haben. Wie kann man die Kräfte, die an einem Projekt „zerren“ rasch analysieren? Für eine PESTLE-Analyse fehlt in dieser kritischen Situation die Zeit. Rascher geht es mit der sogenannten „Kraftfeldanalyse“.

Und schließlich: Ich! Will! Den! Folgeauftrag!

“We’re only in it for the Money” – Frank Zappa

We are only in it for the Money. Mehr oder weniger. Irgendwie wollen / müssen wir alle von unserer Tätigkeit leben. Manche von uns können sich ihre Aufträge aussuchen – oder einfach mal ein paar Monate pausieren. Viele andere können dies nicht. Dies kann dazu führen, dass ein Berater den Status eines Projekts anders darstellt, als es ist. Komplizierter, komplexer, umfangreicher – in jedem Fall wird es ohne ihn nicht funktionieren. Status-Reports werden entsprechend angepasst. Stakeholder werden „angebaggert“, um sie für Erweiterungen zu begeistern.

Muss ich mehr schreiben? Auftraggeber kennen dieses Verhalten natürlich und entwickeln mit einer Zeit oft ein feines „Näschen“, wann ein Berater übertreibt oder nicht. Ich kann nur jedem raten, es sein zu lassen. Setzen Sie lieber auf Empfehlungen zufriedener Auftraggeber. Die Aussagen von Roger Rankel und Marcus Neisen in ihrem Buch kann ich nur bestätigen: Kunden, die auf Empfehlung kommen, sind die besten Kunden. Dazu muss Ihr Mandant Sie aber auch weiterempfehlen. Dies tut er gewiss nicht, wenn die Situation anders ist, als von Ihnen dargestellt. Auch wenn es nichts wird mit dem Folgeauftrag – da er nicht erforderlich ist.


Dies soll es im Rahmen meines Beitrags über Selbststeuerung gewesen sein. Sie sehen anhand der Beispiele, die Kontrolle über sich selbst zu behalten, beinhaltet viele Facetten. Sicherlich konnte ich auf einige Punkte hier nur oberflächlich eingehen – sie hätten eigene Beiträge verdient (die eventuell später noch kommen). Und natürlich gibt es noch viele andere Anwendungsgebiete im Rahmen einer Beratung. Ich hoffe, diese Beispiele regen Ihre Fantasie an…

Haben Sie Fragen zu den besprochenen Punkten? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

Erfolgreich im Pilotprojekt – gescheitert in der Organisation

Think global, act local – die bessere Alternative für Veränderungen in Unternehmen

UnterschiedeEin großer, traditionsreicher Technologiekonzern in einem großen Land. Man möchte eine neue Methodik einführen. Man ist schlau – wir fangen mit einem Piloten an, um Erfahrungen zu sammeln. Ein junges Team mit großartigen Mitarbeitern wird dafür zusammengestellt. Dazu eine Trainerin aus einem noch größeren Land, die bei der Einführung hilft. Eine Koryphäe auf ihrem Gebiet. Die Management Attention ist beispielhaft. Alle beteiligten Abteilungen des Konzerns sind eingebunden. Ein Beispielprojekt wird ausgewählt. Alle Augen des Konzerns liegen auf dem Projekt. Jedem Projektmitglied ist die Wichtigkeit des Piloten bewusst. Die Trainerin gibt ihr bestes. Alle erforderlichen Mittel stehen zur Verfügung. Und ja: das Projekt – umgesetzt mit der neuen Methodik – wird ein großer Erfolg. In Time, in Budget, in Paris, in Love.

Natürlich lief noch nicht alles optimal. Diese Erfahrungen verarbeitet man anschließend in den „Leasons learned“ Sessions mit einem Coach auf. Prozessspezialisten nehmen die Ist- und Sollprozesse auf und analysieren sie. An allen erforderlichen Stellschrauben wird gedreht. Ein Folgeprojekt wird umgesetzt. Alle sind hochmotiviert – und ja, wieder wird es ein großer Erfolg.

Jubel in der Konzernzentrale – die überfällige Erneuerung hat erfolgreich begonnen. Der Anfang ist gemacht – nur wird die neue Methodik auf das gesamte Unternehmen übertragen und wird eingeführt. Nach dem Piloten weiß man ja, wie es geht. Alles Weitere sind nur noch Peanuts. Ein Kommunikations- und Schulungsplan wird erstellt und umgesetzt, der Betriebsrat frühzeitig involviert, Schulungen durchgeführt. Die Zentrale wendet sich anderen Dingen zu…

Einige Zeit später – Ernüchterung hat sich breit gemacht. Sicherlich, alle Abteilungen setzen die neue Methodik ein, aber irgendwie funktioniert es doch nicht so wie gedacht. Widerstände in den Abteilungen sind größer als gedacht. Mischformen aus alten und neuen Methodiken nisten sich ein. Hier und da erwischt man Abteilungen, die unter den Buzzwords der neuen Technik genauso weiterarbeiten wie bisher. Mood has changed. Wie konnte das geschehen?

Eine große Familie

Zunächst kennt jeder die Geschichten erfolgreicher Pilot-Projekte in großen Unternehmen. In der Realität haben sich nicht alle wie berichtet zugetragen. Zu Werbezwecken wird manches mit Absicht überhöht. Manches verklärt sich in der Rückschau. Der Erfolg war gewollt und wurde mit allen Mitteln erreicht. Das Umfeld hat gestimmt. Die Mitarbeiterinnen und Mitarbeiter im Pilotteam waren ein junges, handverlesenes Team. Widrigkeiten und Nachteile wurden im Nachhinein verdrängt oder vertuscht. „Hat doch alles prima funktioniert…“.

Nun will man dies auf das übrige Unternehmen übertragen. „Im Pilot klappte es, also auch bei Euch. Ihr seid schließlich ein eingespieltes Team!“ – So hören die Abteilungen die optimistischen Aussagen der Unternehmensleitung (per Email).

In diesem Zusammenhang stellen Sie sich mal ein Unternehmen als autoritäre Familie vor: An der Spitze des Unternehmens sind die „Eltern“, die bestimmen wo es lang geht. Neue Abteilungen, in denen frische Methodiken eingeführt werden, sind in dieser Familienaufstellung die kleinen, nachwachsenden Geschwister. Diese bekommen von den Eltern (der Unternehmensleitung) Ihrer Meinung nach viel zu viel Aufmerksamkeit, während Sie selbst –Mitarbeiter/innen einer seit Jahren gewachsene Abteilung (also die älteren Geschwister) – zusehen müssen, wo Sie bleiben. Die Neuen werden gefüttert und gestreichelt – und uns, die wir doch immer so brav waren, spucken die Eltern auf den Kopf, machen sich sogar noch über uns lustig, wenn wir uns ärgern. Eifersucht und Kränkung sind die Folge. Und natürlich Abneigung gegen den neuen, jungen Zwerg. Nun soll man auch noch dessen Methoden übernehmen? Sie haben doch viel mehr Erfahrung als dieser Wurm! Kein Wunder, dass es Widerstand gibt.

Zumal die Voraussetzungen völlig andere sind. Im Piloten war es ein junges, handverlesenes Team – eigenhändig gepampert von den Eltern mit Unterstützung von externen Nannys. Der Rollout im Rest des Unternehmens erfolgt nun nach einem einheitlichen Plan. Individuelle Bedürfnisse einzelner Bereiche (größerer Kinder) werden nicht berücksichtigt – wäre bei einem Konzern dieser Größe einfach zu kompliziert. Notwendige Voraussetzungen für die Einführung sind nicht gegeben. Zudem ist ein Ziel, dass man Mitarbeiter zukünftig einfacher in allen Abteilungen des Konzerns einsetzen möchte. Dies wird durch eine einheitliche Vorgehensweise enorm erleichtert, da Schulungs- und Einarbeitungskosten minimiert werden.

Außerdem soll es vorkommen, dass Mitarbeiterinnen und Mitarbeiter die schon länger in Konzernen arbeiten, eventuell nicht mehr so motiviert sind wie früher. Anders als die jungen, frischen Kollegen von der „Uni“ (diese neuen, jungen Zwerge). Ja, man war auch mal so ein Zwerg (und wurde ebenso gepampert) – aber dies ist lange, lange her…

Thing global, act local

Wie können Unternehmen es besser machen? „Evolution anstatt Revolution“ beim Ausrollen neuer Methodiken ist heute in vielen, sich schnell ändernden Märkten keine Lösung. Bis sich die Evolution im Unternehmen verbreitet hat, hat die Revolution der Märkte das Unternehmen weggespült.

Eine besser passende Vorgehensweise ist „Think global, act local“. Dieser Ansatz kommt eigentlich originär aus dem Umweltschutz (eine sehr interessante Präsentation dazu sehen Sie hier). Grob zusammengefasst bedeutet er, man solle global denken, aber lokal beginnen. Um die Welt zu verändern, sollte man vor der eigenen Haustüre (oder im eigenen Haus) beginnen. Man hat ein globales Ziel (z.B. den globalen Umweltschutz zu verbessern) und beginnt dies, indem man sein eigenes, lokales Tun verändert (z.B. weniger Auto fährt) – wie es am besten zu der persönlichen Situation passt. Der Grund hierfür ist, dass sinnvolle Maßnahmen um ein Ziel erreichen zu können, für andere Personen völlig anders sein können als für einen selbst. Wohnt man z.B. auf dem Land weit ab von einer Stadt, ist weniger Autofahren oft schwer möglich – ein sparsameres Auto anzuschaffen wäre gegebenenfalls eine Alternative. Das Ziel wird mit beiden Maßnahmen (weniger Autofahren, sparsameres Modell) erreicht.

Der Gegensatz dazu ist das (oben beschriebene) sogenannte Rasensprengerprinzip, indem man dieselbe Maßnahme überall gleich ausrollt – ohne auf lokale Gegebenheiten Rücksicht zu nehmen. In der Armutsbekämpfung ein sehr kontrovers diskutiertes Beispiel ist das weltweite Verbot von Kinderarbeit. Soll man Kinderarbeit weltweit ächten oder ist sie in einigen Teilen dieser Welt für Kinder überlebenswichtig? Wie bekämpft man Armut am besten? Ich möchte diese Diskussion hier nicht aufnehmen (dafür gibt es passendere Plätze im Internet), sondern verwende das Beispiel zur drastischen Veranschaulichung des Prinzips. Nebenbei bemerkt: Neben solchen Themen wirkt die Einführung neuer Methodiken in Unternehmen schon fast banal.

Auch in Unternehmen kann man den „Think global, act local“ Ansatz gut anwenden. Zunächst sollte entschieden werden: Welches Ziel möchte ein Unternehmen mit der Einführung einer neuen Methodik erreichen (Think global)? Solche Ziele werden in der Regel von der Unternehmensführung beschlossen. Aber dann: wie kann ein einzelner Bereich dieses neue Ziel am besten erreichen (Act local)? Selbst wenn das Ziel die neue Methodik selbst ist, kann sie angepasst an lokale Gegebenheiten individuell eingeführt werden. Der optimale Ansatz für die Einführung mag ein ganz anderer sein als bei dem Pilotteam. In manchen Fällen passt die neue Methodik ggf. überhaupt nicht. Die einzelnen lokalen Bereiche werden miteinbezogen in diese Entscheidungsfindung.

Scheinbarer Nachteil: es geht zu Beginn langsamer voran und bedeutet erheblich mehr Aufwand als beim Rasenmäherprinzip. Es muss mit jedem Bereich eine individuelle Lösung gefunden werden. Dazu benötigt man

  • Prozessanalysten für die Prozessaufnahme im Bereich (für den Ist-/Sollabgleich)
  • Trainer für individuelle Trainingskonzepte und deren Umsetzung
  • Ggf. Change Manager, falls die neue Methodik auf einen Bereich nicht passt und eine individuelle Lösung gefunden werden muss
  • Ein Budget, um dies alles finanzieren zu können 😉

Die letzte Voraussetzung ist oft der „Pferdefuß“. Je paralleler man die Einführung plant, desto höher steigen die Kosten. Da der Pilot oft schon eine Stange Geld gekostet hat, scheuen viele Unternehmen vor diesen Kosten zurück. Allerding ist durch die Parallelität die Einführung aber doch deutlich schneller als beim „Evolution“-Rollout.

Vorteil der „Think global, act local“ Vorgehensweise ist es im Endeffekt die größere Nachhaltigkeit der Einführung und damit langfristig der größere Erfolg. Damit relativieren sich „in the long run“ auch die Kosten wieder. Und natürlich ist die lokale Akzeptanz viel höher – man wurde ja schließlich gefragt, wie die Umsetzung erfolgen soll. Vielleicht hat der Bengel ja doch seine guten Seiten. 😆


Auf viele Details kann ich hier natürlich nicht eingehen, dies würde diesen Beitrag sprengen. Wenn Sie daher Fragen zu der „Think global, act local“ Herangehensweise haben, dann nehmen Sie doch mit mir Kontakt auf. Ich freue mich, Ihre Fragen zu beantworten.