Guys! You have to escalate!

„Guys! You have to escalate immediately when a delay shows up!”

15 Uhr MESZ, täglicher Eskalationscall. 6 Uhr morgens Westküste USA, 18:30 Uhr Indien, 9 Uhr Ostküste USA, 21 Uhr China – der einzige Termin, der diese Zeitzonen einigermaßen zusammenbringt. Gut für die deutschen Kollegen – in diesem Fall.

“Even if you see any small risk of a delay, put it on our escalation list! Send emails to the people in charge and mark the issue in bold, red letters. They have to fix it EOB!”

Das gesamte Team von Projektleitern ist in diesem Call. Dazu Repräsentanten aus den beteiligten Fachabteilungen. 40 Personen, jeden Tag, 1 Stunde (Minimum). Ich mag mir die Kosten gar nicht ausrechnen. Und ich habe Mitleid mit den Kollegen in China, die nach einem solchen Call sicherlich nicht ganz ruhig in den späten Feierabend gehen.

„Please remember, guys: We`re in this together, we are one team. We´re all sitting in the same boat. However, you are the experts, you have to solve this.”

Warum er wohl immer wieder auf den Teamgedanken hinweist in solchen Telefonkonferenzen? Sonst macht er das ja auch nicht. Was haben Eskalationen überhaupt mit Teamspirit zu tun? Und im Endeffekt sollen wir es dann doch wieder alleine lösen.

“By the way: we are changing reporting from tomorrow on. We will send out the new Excel template right after this call. We also need to use the current one for a while, so please fill out both templates for an intermediate period of time.”

Oh, mal wieder eine Änderung im Reporting, jetzt die dritte Änderung in zwei Monaten. Natürlich wird die „intermediate period“ mindestens 4 Wochen dauern – oder für immer.

Nach dem allgemeinen Call folgen ab und zu „persönliche“ Gespräche. „Persönlich“, weil in der Regel bis zu 10 Personen daran teilnehmen (die Programmleiter müssen ja ihre Zeitplanung optimieren). „Dieter (Name von der Redaktion geändert)! Wir haben Dich als erfahrenen Projektleiter ausgewählt. Ich habe erwartet, dass Du das Projekt erfolgreich und in-time über die Bühne bringst. Du hast mich mit Deinem Verhalten im Projekt XXX persönlich enttäuscht…“

Nun kommt die persönliche Schiene. Wie spricht der eigentlich mit mir? Vor all den Leuten! Ich habe viel mehr Erfahrung als dieser Jungspund und der macht mich so an. Das muss ich mir nicht bieten lassen, ich gebe das Mandat zurück. Was kann ich dafür, dass dieses Unternehmen beratungsresistent ist und auf Prozesse pfeift. Sollen die doch ihren Mist alleine machen. Na gut, eine Weile schaue ich mir das noch an…

Kaffeepause: „Schon gehört, Kollege XYZ wurde aus dem Programm genommen. Ja ich habe den Dreizeiler mit der Aussage „Unterschiedliche Auffassung über Qualität“ gelesen…“

So geht das – Tag für Tag. Manchmal am Wochenende. Eskalation als Dauerzustand. Dummerweise nutzt sich dann so ein Eskalationsprozess (und die dazugehörigen Calls) schnell ab, wenn quasi alles eskaliert wird. Was tun? Genau: man führt einen zweiten Eskalationsprozess (mit dazugehörigen täglichen Calls) ein. Zunächst macht man dies für einen Kunden, der besonders drängelt. Vorab ist dann immer ein weiteres Template mit dem aktuellen Status auszufüllen. Nicht, dass diese Updates im Call berücksichtigt werden. Es wird Fall für Fall durchgegangen und die Updates nochmals in dasselbe Template eingetragen.

Später nimmt man dann Super-wichtige-Eskalationen für andere Kunden hinzu. Ein weiteres Mitglied einer höheren Management-Stufe wird dazu genommen (oder dieser initiiert den neuen Eskalationsprozess). So schiebt man nach und nach alle Eskalation vom ersten Prozess in den zweiten Prozess – bis quasi alle Eskalationen dupliziert sind.

Nun kann man auf zwei Arten vorgehen: Entweder jemand erkennt, dass alles doppelt ist und ein Prozess wird gelöscht. Oder – nun folgt die hohe Kunst der Eskalation – man definiert einen DRITTEN Prozess, in dem wiederum nur die Top-Eskalationen behandelt werden. Undsoweiter, undsoweiter…

So kann man den ganzen Tag mit Telefonkonferenzen und Ausfüllen von Formularen füllen. Das Beste dabei: da die normale Arbeit darunter leidet, kommen immer mehr Eskalationen hinzu. Irgendwann sind dann alle Projekte irgendwie in Eskalation. Natürlich könnte man auch mal über Ursachen sprechen, warum so viele Projekte Probleme haben – und natürlich haben viele Personen solche Gedanken – aber neben Tagesgeschäft und Eskalationen fehlt dazu einfach die Zeit. Man kann eben nicht alles haben.

“Guys! We have to escalate! We are ONE Team!”

Du mich auch…


Soweit für dieses Mal. Im nächsten Beitrag komme ich zurück auf das Thema “Projektreflexion oder Retrospektive – der ungeliebte Projektabschluss“. Haben Sie Fragen zum Thema, wie man mit Eskalationen Spaß haben kann? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

Projektreflexion oder Retrospektive – der ungeliebte Projektabschluss

Egal ob Scrum, XP (Extreme Programming), Kanban oder Wasserfall: bei vielen Projekten steht zum Schluss die Projektreflexion an. Bei XP ist sie eine der 14 Prinzipien. Bei Scrum nennt man es Retrospektive. In vielen Unternehmen und bei vielen Teams ist sie so beliebt wie Fußschweiß und keiner ist traurig, wenn sie ausfällt. Das wiederum finde ich traurig.

Man kann mit Eis locken, mit Kärtchen arbeiten oder spontane Zweiergruppen bilden. Methoden gibt es hier viele. Bei einer behördlichen Einrichtung muss man vorher einen Fragebogen ausfüllen (u.a. mit der allseits beliebten Frage „Mein persönlicher Beitrag zum Projekt“). Beliebter wird sie dadurch nicht. Dazu kommt, dass viele Menschen eine Reflexion mit der Suche nach Fehlern verbinden. Natürlich mit der guten Absicht, solche Fehler in der Zukunft zu vermeiden und welche Veränderungen dafür erforderlich sind. Aber wer spricht schon gerne über Fehler, vielen ist dies unangenehm.

Und Schließlich: Reflexionen sind rückwärtsgerichtet, es wird auf das letzte Projekt, den letzten Sprint, die letzte Zeitspanne zurückgeschaut. Da am Ende eines Projekts oft Stress steht (Einführung unter Zeitdruck, mit Überstunden, am Wochenende, etc.) fühlt sich das Team „ausgelaugt“, müde und hat wenig Motivation das Projekt nun zu reflektieren. Man möchte nach vorne schauen, nicht zurück. Wird Zeit mal darüber zwei Blog-Beiträge zu schreiben 😉 – nachdem ich vor einiger Zeit schon über Selbstreflexion berichtet habe. Im ersten Beitrag geht es um das „Warum“ und um Tools.

Warum, Was und was nicht

Die meisten Beteiligten sind sich der Wichtigkeit von Reflexionen (oder Retrospektiven) durchaus bewusst. Oben habe ich schon erwähnt, dass für viele Reflexion = Fehlersuche ist. Sicherlich sollte in einer Reflexion auch über Schwächen und Fehler im abgelaufenen Projekt gesprochen werden. Dies ist aber nur ein Aspekt. Folgende Themen können in der Reflexion besprochen werden:

  • Wie hat sich das Team im letzten Projekt entwickelt (gerade wichtig für Gruppen, die über mehrere Projekte (oder Sprints) zusammenbleiben?
  • Welche Erfahrungen wurden gemacht, die eventuell in zukünftige Abläufe oder Prozesse integriert werden sollten?
  • Welche Chancen zur Erleichterung zukünftiger Projekte sieht die Gruppe aus den Erfahrungen des Zurückliegenden?
  • Welche positiven Erlebnisse wurden gesehen?
  • Aber auch: welche Schwächten traten zutage, welche Fehler wurden gemacht? Wie kann man diese zukünftig vermeiden?
  • Sind Risiken zutage getreten, die zukünftige Projekte beeinflussen könnten?
  • Sind persönliche Zwistigkeiten zwischen einzelnen Beteiligten / Gruppen aufgetreten und wie soll man damit für zukünftige Projekte umgehen?
  • Ein Thema für Teams, die schon lange zusammenarbeiten: wird man langsam betriebsblind, sind wir zu sehr eingefahren? Dieses Thema bedingt ggf. eine extra Session.

Vor einer Reflexion oder innerhalb der ersten Reflexion sollten die Ziele definiert werden, die erreicht werden sollen. Ganz wichtig – gibt es „No Go“ Themen? Dies mag zunächst widersprüchlich klingen. Eine Reflexion ist ja eigentlich dazu da, alles aufzuarbeiten was passiert ist. Aber leider gibt es in der Realität Zustände, die nicht zu ändern sind. Darüber zu sprechen ist für eine Gruppe frustrierend, weil es die eigene „Unfähigkeit“ aufzeigt, daran etwas zu ändern. Man sollte aber reflektieren, wie man mit diesen „Tatsachen“ umgehen möchte.
Eignet sich eine Reflexion zur Teambildung und als vertrauensbildende Maßnahme? Ich denke nicht – bin mir aber bewusst, dass einige Kolleginnen und Kollegen dies anders sehen. Teambildungsmaßnahmen sollten vor einer Reflexion stehen. Nur wenn sich die Teilnehmer als Team sehen und sich vertrauen, werden sie offen das zurückliegende Projekt reflektieren. Andernfalls werden Meinungen „hinter dem Berg“ gehalten oder man macht sich gegenseitig Vorwürfe. Eine Reflexion kann (und sollte) das Vertrauen im Team vertiefen. Ist dieses Vertrauen aber nicht vorhanden, wird eine Reflexion es nicht aufbauen können. Hier sind andere Maßnahmen gefragt (hey, wieder ein Thema für einen Blogbeitrag…).

Toolauswahl

Tools für Reflexionen gibt es wie „Sand am Meer“. Obwohl die Suche nach Methoden für die Projektreflexion im deutschsprachigem Netz erstaunlich wenig Ergebnisse bringt, abgesehen von einigen allgemeinen Sätzen. Aber es gibt eine exzellente, englischsprachige Seite im Netz mit sehr vielen Tools, Tipps und Guidelines. Hier findet sich wohl für fast jede Situation die richtige Vorgehensweise. Für den deutschsprachigen Bereich kann dieses Buch Unterstützung geben. Ich gehe hier nicht auf einzelne Tools ein, um ein „Copy – Paste“ zu vermeiden (beantworte aber gerne Fragen dazu). Später werde ich auf die drei Schwäne genauer eingehen, als kleinen Exkurs.

Hat man wenig Erfahrung mit Reflexionen, sollte man sich die Zeit nehmen, diese Liste von Tools sorgfältig zu studieren. Im Hinterkopf sollte man sich die Fragen stellen, welches Tools passen zu einer Gruppe von Personen, mit denen eine Reflexion durchgeführt werden sollte. Um die Unbeliebtheit von Reflexionen nicht noch zu verstärken, sollten Sie auf Vorbereitungsaufgaben verzichten. Schon in der Einleitung erwähnte ich einen Fragebogen, der vor einer Reflexion bei einer behördlichen Einrichtung auszufüllen ist. Sie können sich vorstellen, wie ein solcher Fragebogen die Stimmung für eine Reflexion ins Negative beeinflusst.

Suchen Sie sich mehrere Tools heraus und bauen Sie sich einen kleinen „Baukasten“ auf, insbesondere, wenn Ihnen die Gruppe noch nicht bekannt ist. Bedenken Sie, dass am Ende von aufwändigen Projekten oft die Kraft der Teilnehmerinnen und Teilnehmer gering ist. Tools können daher gerne etwas leicht und spielerisch sein – falls dies die Gruppe zulässt. Wobei selbst gestandene „Seniors“ für kreative Tools meist offener sind als gedacht. Finden Sie es heraus. Überraschen Sie die Gruppe mit einem Tool, welches noch nie verwendet wurde. Im schlechtesten Fall brechen Sie ab und kommen zu den berühmten „Kärtchen“ zurück. Gewonnen haben Sie, wenn sich die Gruppe auf eine weitere Reflexion mit Ihnen freut, da sie Ihre Tools so gut findet.


Soviel für heute. Natürlich darf der Hinweis nicht fehlen, dass man Reflexionen am besten durch eine neutrale, außenstehende Person durchführen lässt . Im nächsten Beitrag berichte ich über die Vorbereitung, Durchführung und die Nachbereitung einer Reflexion.

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

4 Plus 1 Irrtümer über Kanban in der IT

Irrtümer

Unbewusste oder bewusst gestreute Irrtümer über Kanban in der IT

Dies ist mein vierter Blog-Beitrag über Kanban. Im ersten Beitrag propagierte ich Kanban nicht nur für Software-Entwicklung, sondern auch für andere IT-Bereiche. Im zweiten Beitrag erklärte ich, warum Kanban-Einführungen scheitern können und was man dagegen tun kann. Zuletzt diskutierte ich die Unterschiede zwischen lean und agil.

Anhand des Feedbacks und einiger Gespräche seitdem möchte ich heute über 4 Plus 1 Irrtümer über Kanban aufklären. 4 Irrtümer, die immer wieder zu hören sind plus einem Irrtum, der meines Erachtens gerne bewusst gestreut wird.

Irrtum 1: Wenn das Management nicht voll und ganz hinter Lean, Pull statt Push und Kanban steht, lassen Sie es besser bleiben.


Ein Team will Kanban zunächst lokal einführen aus unterschiedlichen Gründen. Aber sie hören, dies ginge nicht, wenn andere Bereiche nicht mitmachen, die aber am Rande involviert sind.

Dies stimmt für die Einführung agiler Methodiken – „Scrum von unten“ kann nicht funktionieren. Für Kanban stimmt das nicht. Kanban kann schon bei kleinen Teams Abläufe, Workflows etc. optimieren – ohne dass das ganze Unternehmen dahinterstehen muss. Der Unterschied ist, dass Kanban eine Change-Management Methode ist und beim Status Quo startet. Man muss keine Prozesse ändern, keine Methoden austauschen, keine Arbeitsabläufe ändern. Die kontinuierliche Verbesserung startet im hier und jetzt. Agile Methodiken dagegen benötigen einen „Big Bang“ bei der Einführung. Alle involvierten Bereiche müssen mitmachen. Dafür ist in der Regel eine Management-Entscheidung erforderlich.

Dies bedeutet nicht, dass man Kanban als „U-Boot“ hinterrücks einführen sollte – schaffen Sie nicht einfach irgendwie vollendende Tatsachen. Natürlich muss man sich „Rückendeckung“ aus dem Management holen, informieren was eine Kanban-Einführung bedeutet. Aber: ist Support vorhanden, oder ist den verantwortlichen Stellen schlichtweg „egal“ ob man Kanban einführt, kann man dies auch in abgegrenzten Projekten sehr gut machen. Wenn ich dies erläutere, höre ich oft den Einwand: Niemals wird unser Management akzeptieren, dass Mitarbeiter „herumsitzen“ und nichts zu tun haben. Dies kann durch das Pull statt Push Prinzip in Kanban – gerade am Beginn einer Einführung – geschehen. Nun, wird Mikromanagement betrieben, kann dies passieren. Ansonsten wird eher auf Durchlaufzeiten und Output geachtet. Und diese werden sich in der Regel mit Kanban schnell verbessern. Also: proaktiv informieren, Push statt Pull erläutern, immer wieder Updates geben.

Irrtum 2: Ohne komplizierte wissenschaftliche Methoden kann Kanban nichts optimieren

Kanban frustriert Teams. Es zeigt zwar die Probleme und Bottlenecks, löst sie aber nicht. Um sie zu lösen muss man komplizierte wissenschaftliche Methoden anwenden, wie in der Automobilindustrie üblich. Dafür fehlt die Zeit in unserem hektischen Alltag. Außerdem wäre dies mit „Kanonen auf Spatzen geschossen“.

Nun kann man mit Kanban wirklich einfach Bottlenecks in knapper Zeit visualisieren. Vielleicht waren sie bekannt, aber niemand wollte sie sehen. Oder sie waren wirklich bisher unbekannt. Und alleine diese Visualisierung ist meistens schon ein großer Schritt zur Lösung, da die „Flaschenhälse“ nicht mehr zu ignorieren sind – man kann / muß nun beginnen, sie zu beseitigen. Verwendet man Kanban etwas länger, lassen sich – mehr oder weniger automatisch – die durchschnittlichen Laufzeiten und Liegezeiten von Aufgaben ermitteln und darstellen. Auch diese Informationen helfen zu verdeutlichen, „wo es hakt“ („woran liegt es, dass diese Art von Aufgaben so lange in Stufe 4 warten, bis sie weiter verarbeitet werden können?“). Dies sind einfache, aber große Schritte nach vorne. Man kann die richtigen Fragen stellen und an den Antworten arbeiten. Ideen kommen meist alleine durch die Visualisierung. Es stimmt, dass Kanban aus der Automobilindustrie kommt und hier kleine Verbesserungen große finanzielle Auswirkungen haben. Daher gibt es eine Vielzahl wissenschaftlicher Methoden zu Verbesserung und Optimierung. Für Kanban in der IT sind diese aber meistens nicht notwendig. Hier reichen schon die „Basics“ aus.

Wenn man sich denn überhaupt verbessern möchte. Denn man muss sich klar sein: wenn man Kanban einführt, dann führt dies zu Ergebnissen. Wenn man dann nichts mit diesen Ergebnissen anfängt, sollte man sich schon fragen, warum man dies überhaupt gemacht hat.

Irrtum 3: Kanban für IT ist ein Modell zur Softwareentwicklung


Mit Kanban fängt man zwar im Ist-Zustand an, es ist aber im Grunde wie Scrum ein Modell (oder Methodik) für die Softwareentwicklung (eine Art Scrum light).

Der Klassiker der Kanban Irrtümer. Kanban für IT wurde zuerst von David Anderson für die Softwareentwicklung entwickelt. Es ist aber keine Methodik, auch wenn das deutschsprachige Wikipedia es Vorgehensmodell nennt. Der englischsprachige Eintrag zu Kanban für IT ist hier aussagekräftiger, da er von Kanban als „process management and improvement method“ spricht. Aber auch dieser Artikel erwähnt Kanban hauptsächlich in Kontext für Softwareentwicklung. Kanban wird aber auch immer mehr in anderen Bereichen in der IT eingesetzt, wie ich hier erläutert habe.

Was bedeutet dies: zunächst, dass Kanban für sich alleine kein Vorgehensmodell wie Scrum, Wasserfall oder andere Modelle sein will. Der deutsche Wikipedia-Eintrag ist IMHO nicht korrekt. Dies bedeutet weiterhin, dass man Kanban parallel zu diesen Methodiken (oder Vorgehensmodellen) einsetzen kann. Sicherlich lässt sich Kanban sehr gut mit agilen Modellen kombinieren – es ist aber kein Muss. Schließlich passt Kanban besonders gut zu Bereichen, die eben keine Software entwickeln, aber ein hohes Aufkommen an Tasks besitzen. Ich habe dies am Beispiel eines IT Service Centers skizziert.

Irrtum 4: Kanban verhindert Zusammenarbeit von Gruppen

Mit Scrum wurde man agil, man tauschte sich aus, saß in Workgroups zusammen – und dann kam das Kanban Board. Seitdem schaut jeder/ jedes Team nur noch auf das Board, welche Tasks in ihrer / seiner Spalte ist und trollt sich an den Arbeitsplatz.

Ist dem so? Es scheint – laut David Anderson, der in seinen Vorträgen davon berichtet – einer der am weitesten verbreiteten Irrtümer von Kanban zu sein.

Nun, für mich klang dies zunächst merkwürdig. Scrum nutzt das Scrum Board um den Fortschritt der Tasks WÄHREND eines Sprints zu visualisieren. Kanban nutzt das Kanban Board um den Fortschritt von Tasks VON TEAMS zu visualisieren (etwas vereinfacht ausgedrückt). Ein Kanban Board ist daher zeitlich nicht gebunden, im Gegensatz zu einem Scrum Board, welches nach einem Spint endet. Daher gibt es eigentlich keinen Grund, warum die Kommunikation innerhalb von Arbeitsgruppen, Teams etc. stoppen sollte beim Einsatz von Kanban. Das Gegenteil sollte der Fall sein, Probleme aus Sprints gehen nicht vergessen, sondern werden weiter verfolgt. Kanban visualisiert sehr schön die Bottlenecks im Workflow. Diese Visualisierung animiert normalerweise die Kommunikation zwischen den Teams und stärkt hoffentlich die Zusammenarbeit.

Falls dies allerdings nicht geschieht, läuft in der Kommunikation des Teams etwas verkehrt. Über Kommunikation (oder Nicht-Kommunikation) in Teams gibt es viel Literatur. Funktioniert die Kommunikation im Team nicht, liegen die Probleme meist tiefer. Und wie heißt es so schön „exzellente Teams benötigen exzellente Führung“. Kanban „verhindert“ die Zusammenarbeit von Gruppen also nicht – sondern verstärkt sie. Eine Krise im Team sollte man aber nicht versuchen mit Kanban (alleine) zu lösen.

Nun noch zu einem Irrtum, den ich aber unter „Plus 1“ aufzähle, da dieser Irrtum von Kanban-Ablehnern IMHO gerne bewußt gestreut wird:

Plus 1: Kanban ist nur ein Visualisierungs-Tool (daher mögen Mitarbeiter Kanban nicht)

Kanban wird ja nur benutzt, damit unsere Chefs jederzeit wissen, woran wir arbeiten. Unsere Probleme löst es aber nicht.

Kanban wird gerne als reines Visualisierungs-Tool bezeichnet, insbesondere von agilen Befürwortern. Woran liegt das?

Hier möchte ich nochmal auf eine Facette eingehen, die ich schon oben erläutert hatte: Kanban visualisiert unter anderem die Bottlenecks. Entweder von Teams – oder aber eben auch von einzelnen Personen, wenn man das Kanban-Board entsprechend „schneidert“. Es kann damit eine Transparenz schaffen, die gerne manche Vorgesetzte gerne nutzen, um kritische Fragen zu stellen. Es kann aufdecken, dass sich vielleicht manch eine Kollegin / ein Kollege „versteckt“ – im Unternehmensdeutsch gerne „Minderleister“ genannt. Ist dies das versteckte oder offene Ziel für eine Einführung von Kanban ist es nicht verwunderlich, dass Kolleginnen und Kollegen dies verunsichert und sie die Einführung ablehnen. Weiterhin können die Ergebnisse auf dem Kanban-Board Vorgesetzte zum Mikromanagement treiben („warum haben Sie vorgestern nur 2 Aufgaben bearbeitet?!? Hätten Sie sich nicht noch weitere Aufgaben ziehen können?!?“).

In jedem Fall sollte Kanban nicht dazu missbraucht werden. Stoppt man nach der Visualisierung, um ins „Fingerpointing“ überzugehen, ist die Verweigerung vorgezeichnet. Allerdings wird dieses Szenario auch gerne verwendet, um Kanban „anzuschwärzen“. Denn die Einführung von Kanban erfordert einen gewissen Aufwand und die Unterstützung aller Beteiligten. Die Einführung eines Reportings für die Mitarbeiter ist meist schneller und effektiver, will man mikrogenau wissen, was jeder so tut. Daher halte ich dieses Argument oft für vorgeschoben.

Generell ist es im Moment etwas ruhiger um Kanban geworden. Der Hype ist etwas abgeflaut. Kein Fehler, um über Kanban konstruktiv diskutieren zu können. Ich hoffe meine Blog-Beiträge können dazu etwas beitragen.

Haben Sie Fragen zu 4 + 1 Irrtümern über Kanban. Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

IT-Strategie Entwicklung: Weitere gern gemachte Fehler…

Wer braucht in agilen Zeiten überhaupt noch eine IT-Strategie?

4.1.1„Wir wuseln hier so rum von Tag zu Tag ohne wirkliche Richtung, ohne Strategie für unsere IT…“ Kommt Ihnen das bekannt vor? Aber Sie sind schon dabei dies zu ändern? Dann willkommen zu meinem zweiten Blogbeitrag zu gern gemachten Fehlern bei der Erstellung einer IT-Strategie.
Im ersten Teil zu diesem Thema habe ich über Schwierigkeiten berichtet, wenn man keine Unternehmensstrategie hat, warum man Quick Wins in die Strategie integrieren sollte und warum es problematisch ist, wenn eine IT-Strategie zu weit weg von der Unternehmensstrategie ist. Alles gern gemachte Fehler auf dem Weg zum Ziel. Aber es gibt noch mehr Stolperfallen. Einige weitere davon diskutiere ich im Folgenden.

Die IT-Strategie ist zu ambitioniert

Sie können sich denken was passiert, wenn hochmotivierte, visionäre Kolleginnen und Kollegen gefragt werden an der Definition einer IT-Strategie für ihr Unternehmen mitzuwirken. Mit Sicherheit entsteht dann eine ambitionierte, visionäre IT-Strategie mit großen Zielen und einer Flut von neuen Ideen. Haben wir das nicht alle an der Uni gelernt: Visionär und hochmotiviert ambitionierte neue Ideen zu generieren?

Nur will diese visionäre und ambitionierte IT-Strategie auch in der Praxis umgesetzt werden. Und im Daily Business kann dies schwierig werden, neben den ganzen Aufgaben die täglich auf uns warten. Kein Budget, keine Zeit, aber richtig Arbeit die auf die Kollegen warten. Sehr ambitionierte Ziele machen in der Regel viel Arbeit und benötigen viele Ressourcen. Daher achten Sie bei der Erarbeitung Ihrer Strategie auch darauf, wie realistisch eine Umsetzung ist – und in welchem Zeitraum. Erreichen Sie Ihre hehren Ziele erst in vielen Jahren, dann ist die Gefahr groß, dass bis dahin die Ziele obsolet sind. Überprüfen Sie jedes Ihrer Ziele auf Machbarkeit, ob die Ressourcen dafür vorhanden sind (oder es realistisch ist, diese zu bekommen) – und wer sie verantwortet. Ist diese Person bereit, für das entsprechende Ziel Verantwortung zu übernehmen? Und noch eine wichtige Frage sollten Sie sich stellen: Passen die ambitionierten Ziele in die gegenwärtige Abteilungskultur? Oder sollte man nicht zunächst einmal an der Kultur arbeiten? Müsste man den Kulturwechsel mit in die Strategie einplanen? Leider müssen manchmal Träume eben Träume bleiben, auch wenn sie noch so erstrebenswert erscheinen.

Eine Umsetzung findet nicht statt

Der Klassiker: es wird viel Arbeit in die Ausarbeitung einer IT-Strategie gesteckt, eventuell mit externer Unterstützung und mit Support von „ganz oben“. Die Strategie wurde verabschiedet, vorgestellt und Umsetzungsmaßnahmen erörtert. Und dann passiert: nichts. Einfach nichts.

Dafür kann es unterschiedliche Gründe geben. Einen Grund dafür habe ich im vorherigen Abschnitt schon angesprochen – die Strategie ist zu ambitioniert, sie kann nicht Wirklichkeit werden. Aber es gibt weitere Gründe.
Mangelnde Managementunterstützung: Eine Strategie kann nur umgesetzt werden, wenn sie Sponsoren im Management hat. Auch wenn sie bei der Erstellung der Strategie noch vorhanden war, kann die Managementunterstützung schnell verblassen, wenn es an die Umsetzung geht. Andere Projekte sind wichtiger, neue Kunden müssen „versorgt“ werden, bei der Budgetkürzung ist es am einfachsten an den Strategie-Projekten zu sparen. Die Liste ist lang, warum eine Umsetzung nicht die Unterstützung erhält. Hier ist Standfestigkeit der IT-Leitung gefragt. Fordern Sie die Unterstützung ein, lassen Sie sich nicht alle Strategie-Projekte wegkürzen, zeigen Sie die Konsequenzen auf (insbesondere für die Zukunft) – finden Sie Kompromisse. Auch in diesem Fall zeigt sich: die IT-Leitung muss Management-Fähigkeiten besitzen.
Aber auch in der anderen Richtung kann es Probleme bei der Umsetzung geben: Keine Unterstützung im Team. Die Strategie wurde nicht vorgestellt, nicht begründet. Sie hat keinen Rückhalt im Team, die sie nicht versteht und / oder nicht unterstützt. Stellen Sie daher Ihre Strategie vor – nicht erst wenn sie fertig ist, sondern schon während der Erarbeitung. Nehmen Sie Ihren Bereich von Anfang an mit, präsentieren Sie Zwischenergebnisse. Eine ausführliche Präsentation mit Diskussion sollte am Ende stehen. Bei großen Umbrüchen durch die Strategie sind effektive Change-Management-Maßnahmen erforderlich – schließlich generieren große Änderungen Ängste und Ablehnung.

Wir arbeiten agil, wir brauchen keine IT-Strategie

„Strategie – das ist doch sowas von Neunziger in Zeiten von Agilität. Wir arbeiten doch agil – nicht nur bei der Softwareentwicklung und setzen zudem erfolgreich Kanban ein. Strategie ist uns zu aufwändig. Wir hatten letztens einen Berater hier, der meinte, er habe 5 Startups gegründet (und zwei davon erfolgreich verkauft) und hat sich noch nie um Strategie gekümmert.“

Nun ja. Dies mag für kleine Startups stimmen – wobei ich auch hier eine Strategie durchaus für sinnvoll erachten würde. Aber die Diskussion sieht man öfters: Brauchen wir noch eine IT-Strategie in Zeiten von Agilität? Was bedeutet dieser Begriff für Unternehmen?
Schon in einem früheren Beitrag habe ich über negative Auswirkungen geschrieben, wenn sogenannte Agilität im Management dazu genutzt wird, um ständig Anforderungen zu ändern. Dies kann bis hin zur Unternehmensstrategie gehen oder sogar (noch schlimmer) ein Zeichen sein, dass man keine wirkliche hat. Dieses Spiel mitzumachen und die IT-Strategie ständig mit zu ändern ergibt keinen Sinn. Kann man dem Management nicht klarmachen, dass dies kein Ansatz ist, dann sollten Sie es lassen. Oder Sie bieten einen Vorschlag an, wie Leitplanken für eine IT-Strategie aussehen könnten.

Denn bei Agilität in Unternehmen reden wir nicht von Scrum & Co, aber auch nicht vom hektischen Ändern der Unternehmensziele. Wir reden von flexiblen Unternehmen, die schnell auf Änderungen im Markt reagieren können. Dazu ist eine flexible (oder nennen Sie es „agile“) IT erforderlich, welche diese Flexibilität unterstützt. Um da hin zu kommen, benötigen Sie sehr wohl eine IT-Strategie. Insbesondere, wenn Sie in einem Unternehmen arbeiten, welches schon länger existiert und daher sicherlich einige IT-Altlasten mit sich „rumschleppt“.
Dies bedeutet: Weg von historisch gewachsenen Architekturen, hin zu einer modularen IT-Landschaft. Dazu benötigen Sie eine IT-Strategie, wie Sie dieses Ziel erreichen können. Allerdings benötigt die Umsetzung einer solchen Strategie viel Zeit, in der Regel mehrere Jahre. Die Planung hierfür ist nicht trivial und benötigt ein gutes Enterprise Architektur Team (und ein paar Quick-Wins).

Hat man diese Zeit nicht, sollte man an Cloud-Lösungen denken. Es gibt ja an Anwendungen fast nichts mehr, was man in der Cloud nicht findet. Man kann solche Lösungen eventuell eine Zeitlang parallel fahren – muss aber parallel wirklich hart an der Migration arbeiten (und keine neuen Lösungen mehr an Altsysteme anbinden).

Wir sehen: um agil zu werden, benötigt man eine IT-Strategie. Ist man schon agil, benötigt man eine Strategie, dass man es auch bleibt. Denn Altlasten wachsen schneller als man denkt.

Und: benötige ich überhaupt eine IT-Strategie?

Wird die IT lediglich als interner Dienstleister für IT-Commodity-Produkte benötigt, die Endgeräte, Applikationen und Zugänge bereitstellt, benötigt man dann eine IT-Strategie? Die einzige Frage, die sich hier doch stellt ist: externer Dienstleister oder interne Abteilung?
Und wirklich ist in diesem Fall eine IT Strategie eher kurz. Nicht krampfhaft etwas definieren, was auf ein Blatt Papier passt: interner Dienstleister für IT-Commodity Produkte. Man muss sich nicht größer machen, als man ist. Niemand würde dies ernst nehmen. Es sei denn, Sie haben wirklich eine tolle Idee wie der IT-Bereich Mehrwert für das Unternehmen generieren kann. An etwas, an was noch niemand gedacht hat. Allerdings sollten Sie Ihre Idee erst einmal High Level vorstellen und sich Feedback und Zustimmung einholen, bevor Sie eine Strategie erstellen.


Mit diesen Hinweisen im Hinterkopf wird Ihre neue IT-Strategie sicherlich ein voller Erfolg 😉 . Benötigen Sie Unterstützung – melden Sie sich bei mir! Haben Sie generelle Fragen bzgl. IT-Strategie oder welche Fehler man dabei vermeiden sollte? Dann weise ich nochmal auf den ersten Teil zu diesem Thema hin. Oder kontaktieren Sie mich.

Berater, Mitte 50, sucht Anerkennung…

Grumpy old man

Mitte 50

Mitte 50

Bevor ich zum zweiten Teil über gern gemachte Fehler bei der Definition einer IT-Strategie komme, mal zu etwas völlig Anderem. Es ist schon einige Jahre her, es war in meinen Anfängen als selbstständiger Berater, als ich in einem Mandat einen Kollegen kennenlernte, der mich sehr – nun sagen wir mal – „beeindruckt“ hat. Er war damals Mitte 50. Heute bin ich Mitte 50 und muss ab und zu wieder an dieses Erlebnis denken. Es war einmal…

Unrasiert, Spitzbauch, altes Polohemd, welches ich nicht einmal mehr zuhause anziehen würde. Eigentlich immer schlecht drauf. Wir tauften ihn „grumpy old man“. Er galt als fachliche Koryphäe – bald merkten wir, dass er mit sehr viel Wasser kochte. Da die Leiter auf Mandantenseite jung und wissensunbelastet waren wie man sich Stakeholdern gegenüber verhält, galt er dort lange Zeit als Held – allein schon, weil er den Stakeholdern auch mal Widerworte gab. Die ganzen jungen Nerds, die keine Erfahrung vom Leben hatten, waren froh über etwas Widerstand gegenüber unerfüllbare Forderungen des damaligen Managements.

Mit einigen Kollegen, die in ähnlichem Alter waren, weinten sie sich in Kaffeepausen gegenseitig etwas vor. „Was habe ich doch für eine große Erfahrung, nur nützt sie uns hier nichts. Keiner will hören, was man alles verbessern könnte.“
Mein Kollege tat sich beim Jammern und Meckern besonders hervor.

Was war er für ein toller Chef, er hatte das Vertrauen seiner Mitarbeiter und er hat sie mitentscheiden lassen. Hatte Verantwortung, konnte was bewegen – aber auch delegieren. „Heute dagegen muss ich mir von den jungen Burschen hier erzählen lassen, was ich zu tun habe. Und dafür bekommt man keinerlei Anerkennung“. Uns gegenüber trat er dagegen sehr autoritär auf, verteilte Aufgaben, traf Entscheidungen (unbeeindruckt davon, dass er keinerlei Mandat dafür hatte oder sich abgestimmt hätte). Der eine oder andere Kollege gab sein Mandat deswegen zurück.

Nun vom Aussehen her habe ich ihn damals eher nicht als Führungskraft eingeschätzt. Vielmehr als einer dieser Typen, die als gute Fachkraft zur Leitung befördert wurden – und danach völlig überfordert waren und versucht haben, diese Überforderung mit autoritärem Stil zu übertünchen.

Zu unserer Erleichterung war er ohnehin nur ein bis zwei Tage im Büro, die anderen Tage machte er Homeoffice – angeblich wegen seiner kranken Frau. Eigentlich war Homeoffice nur in Ausnahmefällen gestattet, ihm war es anscheinend egal. Was er im Homeoffice arbeitete, war uns nicht klar – aber uns war es egal 😉

Nun wissen wir ja, Berater in Großprojekten zu sein ist oft kein Spaß für erfahrene Personen: große Teams, leider meist so gut wie keine Gestaltungsmöglichkeiten. Es ist im Grunde nur Ausführung, Controlling, PMO, Flöhe hüten. Da kommt dann schnell der Frust hoch – insbesondere, wenn man sieht, was alles schiefläuft und man kann so gut wie nichts dagegen tun.

Als damals frisch ausgebildeter systemischer Coach war mein Ehrgeiz geweckt. Kannst Du diesem Kollegen helfen? Starten wir doch mal mit einer klassischen „Warum“-Frage.

„Warum bist Du noch hier?“ „Eckhard, ich bin eine Hure, ich verkaufe mich an jeden, der mich haben will.“

Ich war verblüfft. Was für eine erstaunlich offene Aussage. Desillusioniert vom Leben und anscheinend ohne Perspektive für die berufliche Zukunft. Dann ging es weiter. Lange Jahre bei einem aufstrebenden Unternehmen gewesen, immer höhere Positionen innegehabt bis zur Leitung. Weltweite Verantwortung für die IT, Reisen in vielerlei Länder. Irgendwann war es dann zu Ende (ohne zu erzählen warum). Privat kam die Scheidung von der ersten Frau hinzu, die angeblich einen cleveren Anwalt hatte, die Scheidung ruinierte ihn finanziell. Danach hat er wohl begonnen als Berater zu arbeiten (selbstverständlich mit sensationellen Erfolgen…).

Schuld waren immer die anderen, er war immer das Opfer.

Abschließend meinte er zu mir: „Eckhard, meine jetzige Frau sagte letztens zu mir: Als ich Dich kennenlernte, lebtest Du in einer 1-Zimmer-Wohnung mit einem Schwarzweiß-Fernseher und hattest kein Geld. Mach nur so weiter und Du wirst wieder so leben. Was soll ich also machen? Und überhaupt: Besser als zuhause sitzen…“.

Ich war mir damals sicher: So möchte ich nicht enden.

Irgendwann fiel auch den Verantwortlichen beim Mandanten auf, dass sein Mehrwert im Projekt sich in engen Grenzen hielt. Er behielt Informationen für sich, um sich so unersetzlich zu machen, und tat wenig, um das Projekt voran zu treiben. Außerdem häuften sich die Beschwerden über seinen rüden Umgangston von den beteiligten Abteilungen und aus unserem Kreis. Irgendwann war er weg. „Leider hatte ich keine andere Wahl als „xxx“ aus dem Projekt abzuziehen“, hieß es in der lapidaren Email vom Programm-Manager. Kein Dank, keine guten Wünsche für die Zukunft. Empathie in der Kommunikation sieht anders aus.


Cut.


Nun bin ich Mitte 50. Keine Ahnung, was aus dem Kollegen geworden ist. Aber in der Zwischenzeit habe ich erschreckend viele Kolleginnen und Kollegen getroffen, die ähnlich „drauf“ waren (und sind) – wenn auch nicht in dieser Ausprägung. Ich kann die Geschichten aus ihrer „glorreichen“ Vergangenheit nicht mehr hören. Die weltweite Erfahrung, die sie besitzen. Welche großen Leistungen sie vollbracht haben. Wie ihr ach so großes Wissen doch nun ignoriert wird. Niemand ihre Leistung anerkennt. Dazed and confused. Wie wird man so? Und was ist mit einem selbst? Werde ich auch langsam so?

Denn Menschen wie ich sind ein Auslaufmodell, ich weiß: Weiß, Mitte 50, hetero, ohne Migrationshintergrund, glücklich verheiratet! Außer in Werbung für Prostatabeschwerden („endlich weniger müssen müssen“) finden wir in der Öffentlichkeit nicht mehr statt. Und auch ich habe früher internationale Bereiche geleitet und hatte den LH Senator Status. Und heute?

Heute als Berater ist es eben anders. Wenn man sich dazu entscheidet als Consultant zu arbeiten, dann sollten einem auch die Konsequenzen klar sein. Man hat i.d.R. keine Personalverantwortung mehr (wenn man nicht gerade als Interimsleiter arbeitet), es gibt Projekte mit hoher Reisetätigkeit – sie sind aber selten. Meist werden die festangestellten Mitarbeiter auf Reisen geschickt (was fast immer auch vernünftig ist). Und oft führt man aus, was interne Bereiche einem vorgeben. Als „Externer“ hält sich die Anerkennung, die man vom Mandanten bekommt, meist in Grenzen.

Gerade mit großer Erfahrung sieht man Fehler, die immer wieder gerne gemacht werden. Oft ist man nicht in der Lage, dies zu verhindern – Ratschläge sind nicht erwünscht (Ratschläge sind immer auch Schläge…). Wenn man es überhaupt nicht erträgt, wie es in einem Unternehmen zugeht, dann sollte man sich überlegen, ob man das Mandat nicht zurückgibt. Besser für die eigenen Gesundheit, besser als ein „grumpy old man“ zu werden. Ergänzend hilft aktive Selbststeuerung.

Zudem: das oben beschriebene Verhalten des Kollegen führt nicht zu Neuaufträgen, sondern schadet der gesamten „Generation“ der älteren Consultants. „Wer will mit solchen Beratern arbeiten, wie kann ich vorher wissen ob es „Jammerlappen“ sind. Dann doch lieber jüngere Modelle…“. Die Gefahr ist groß, dass die Erfahrung, die sie mitbringen, bei Gemecker und Besserwisserei untergeht. Solche „Kollegen“ nerven einfach.

Nun meckere ich auch ab und zu ganz gerne über manche Mandate. Aber ich mache dies im kleinen Kreis und versuche mich immer wieder an den Kollegen von damals zu erinnern. „Grumpy“ ist im Film niedlich – in der Realität einfach nur eine Belastung fürs Team. Und hey – Kollegen – meckere ich mal zu viel, erinnert mich an meinen Blogbeitrag 😉

Nun, dieses war es für dieses Mal. Wir wissen ja, nicht alle Mandate machen Spaß. Demnächst geht es wirklich weiter mit gern gemachten Fehlern bei der Erstellung der IT-Strategie. Haben Sie Fragen zu grumpy old men oder sind vielleicht auch einer. Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

IT-Strategie Entwicklung: Gern gemachte Fehler…

Gern gemachte FehlerSchon seit einigen Jahren hören wir es immer wieder: die IT im Unternehmen muss zum Partner der Geschäftsleitung auf Augenhöhe werden. Man liest oder hört Stichworte wie „Business-Agilität-Enabling“ (der Begriff „Agil“ kommt heutzutage immer gut) oder Sätze wie „die IT muss vom Kostenfaktor zum Business-Partner werden“ (oder sogar zum „Moneymaker“). Die IT-Führung muss „alignt“ sein mit dem Business (Ask any CIO to name the Holy Grail of the IT executive, and he is likely to say „alignment“).

Und sicherlich wird es wohl kaum noch große Konzerne ohne IT-Strategie geben. Nicht nur laut Matthias Moritz, CIO der Bayer Healthcare AG, ist es am besten, wenn diese so nah wie möglich an der Unternehmensstrategie ist („Die beste IT-Strategie ist es, keine zu haben“). So gibt es viele Bücher, Seminare, Blogs und Berichte wie man zur besten IT-Strategie kommt. Möglichst einfach, in wenigen Schritten und mit vielen schönen Templates. Dennoch ist es in mittelständischen Unternehmen (von kleinen Unternehmen ganz zu schweigen) keineswegs Standard, eine IT-Strategie zu haben. Zuviel Tagesgeschäft, zu wenige Ressourcen, zu wenig Knowhow wie man so etwas macht. Oder die Strategie wird von Personen entschieden, die ihr Wissen aus Magazinen oder von IT-Vertriebleuten haben. In diese Gruppe fallen CEOs CFOs oder auch COOs, an denen IT-Leiter (die oft noch sehr technisch unterwegs sind) berichten.

Ich möchte hier nicht auf die Notwendigkeit einer fundierten (und aktuellen) IT-Strategie eingehen, sondern in diesem und im nächsten Blogbeitrag ein paar Fehler aufzählen, die bei der Erstellung einer solchen Strategie gerne passieren. Wobei ich den ersten Fehler ja schon im letzten Absatz erwähnt habe 😉

Es gibt keine Unternehmensstrategie, also machen wir uns eine

Voraussetzung für die Erstellung einer IT-Strategie ist eine Unternehmensstrategie (gerne auch Vision und Mission genannt). Es herrscht Einigkeit unter den Experten, dass eine IT-Strategie sich nahe an der Unternehmensstrategie anlehnen sollte. Dies ist naheliegend, wenn sich die IT als Partner und Enabler des Unternehmens sehen möchte und nicht als reiner Dienstleister.

Leider findet man insbesondere in kleinen und mittelständischen Unternehmen nach wie vor keine (oder keine dokumentierte) Unternehmensstrategie. Was tun? Manchmal findet man in der Literatur und in Blogs den Ratschlag sich eine eigene zu definieren, basierend auf den eigenen Annahmen. Ich kann davor nur warnen. Denn stimmen diese Annahmen nicht, ist die gesamte IT-Strategie falsch. Natürlich könnte man mit seiner Annahme auch zur Unternehmensführung gehen: „Hey seht mal, ich habe eine Unternehmensstrategie für Euch gemacht“. Es mag Fälle geben, in denen so ein Vorgehen gut ankommt (wenn man es besser verkauft) – in vielen Fällen aber wohl eher nicht.

Sinnvoller ist es nach Leitplanken für eine IT-Strategie zu fragen, die von der Unternehmensleitung kommen sollten. Eventuell ist das der Startschuss einer Definition einer Unternehmensstrategie (an der man idealerweise mitarbeiten kann), vielleicht bekommt man aber auch nur Hinweise, in welche Richtung die Reise geht. Any help would be greatly appreciated, welche die Definition der IT-Strategie unterstützen kann.

Hat man aber keine Unternehmensstrategie und nicht einmal Leitplanken, muss die IT-Strategie auf eigenen Zielen aufbauen, die man erreichen möchte. Diese kann dann nur Optimierungen im eigenen Bereich beinhalten, also nicht so umfassend sein. Aber es ist besser als keine Strategie zu haben. Was macht das Unternehmen aus, in dem man arbeitet – dies sollte man auch in der IT-Strategie abbilden. Wie ist der Ist-Zustand? Welche Schwächen erkennen wir darin? Wo wollen wir hin? Vor welchen Herausforderungen stehen wir? Mit diesen Fragen kommt man schon weiter. Aber dennoch ist es die am schwächste aller Voraussetzungen für die Entwicklung einer IT-Strategie.

IT-Strategie ist zu weit weg von der Unternehmensstrategie

Gibt es eine Unternehmensstrategie sollte dies der Ausgangspunkt für die IT-Strategie sein (siehe oben).

Allerdings denken manche IT-Verantwortliche anders. Sie verfolgen andere Ziele oder bekommen andere Vorgaben. Ich habe selbst schon den Fall erlebt, dass als Voraussetzung eine IT-Strategie auf SAP-Produkten basieren musste. Die Entscheidung wurde vom CFO gefasst, der Angst hatte eine neue Strategie könnte ihn viel Geld kosten. In diesem Fall ging die Unternehmensstrategie in eine völlig andere Richtung, sodass dies nicht passen konnte. Inzwischen weiß ich, dies kommt öfters vor, als ich damals dachte. Schon in der Einleitung habe ich darauf verwiesen, dass öfters die IT-Strategie von Nicht-Fachleuten entschieden wird, die dann andere Prioritäten (niedrige Kosten, wenig Aufwand, gute Beziehung zu einem Hersteller, etc.) haben.

Aber es gibt auch andere Gründe für eine IT-Strategie weit ab von der Unternehmensstrategie. „Ich habe meine eigenen Ziele“. „Die Unternehmensstrategie taugt nichts und ändert sich dauernd“ (darauf gehe ich noch näher im nächsten Blogbeitrag ein). „Wer außer mir weiß am besten, was für die IT gut ist“ – alles öfters gehörte Phrasen. Ob solche Strategien zielführend (und nachhaltig) sind, steht auf einem anderen Blatt. Aber in vielen Fällen liegt es daran, dass die IT-Verantwortlichen einfach zu weit weg von der Unternehmensleitung sind, noch selbst zu technisch unterwegs sind oder die Unternehmensstrategie zu wenig kennen oder verstehen.

Richtet man die IT-Strategie allerdings bewusst weit weg von der Unternehmensstrategie aus, sollte man sich klar über die Konsequenzen sein. Und darüber proaktiv informieren, schon in der Definitionsphase. Kommunizieren Sie Zwischenergebnisse und begründen Sie den Weg, den Sie gehen. Es mag bequemer sein eine solche Strategie im „stillen Kämmerlein“ zu definieren. Aber spätestens bei der Umsetzung wird es schwierig.

Keine kurzfristige Quick-Wins berücksichtigen

Eine IT-Strategie muss „verkauft“ werden. Schließlich wird sie wahrscheinlich einige Konsolidierungsprojekte enthalten, die erst einmal kosten und sich erst in Jahren auszahlen werden. Man benötigt also „Sponsoren“, die unsere schöne neue Strategie auch unterstützen. Warum sollten Sponsoren dies tun? Vielleicht ist das Unternehmen sogar börsennotiert und muss quartalsweise Anleger überzeugen. Höhere IT-Kosten kommen da gar nicht gut. Es sein denn – man kann einige kurzfristige Erfolge generieren…

Aus der neuen IT-Strategie lassen sich mit Sicherheit einige Quick Wins ableiten – machbare Projekte, Zielsetzungen oder Meilensteine, die sich mit überschaubarem Aufwand realisieren lassen. Die Risiken bei diesen identifizierten Quick Wins sollten klein sein. Sie sollten sich sofort anpacken lassen und in einer überschaubaren Zeitspanne und mit überschaubarem Aufwand positive Ergebnisse liefern. Wenn solche Quick Wins dann noch nachhaltig sind (Quick Wins dürfen keine „Quickies“ sein), dann kann man sie gut als Teil der IT-Strategie positiv verkaufen – auch wenn sie vielleicht nicht notwendigerweise Teil dieser Strategie sein mussten. Aber wer überprüft nach einem Erfolg so etwas schon 😉

Idealerweise plant man neben Quick Wins auch mittelfristig Erfolge ein – die IT Strategie wird zur „Road of Success“. Natürlich klingt dies in einem Blogbeitrag einfacher als in der Realität – daher sollte man permanent über Quick Wins nachdenken – und diese in die IT Strategie integrieren. Sie sehen, unternehmerisches Denken ist einfacher als man denkt . Natürlich darf man dabei die großen, langfristigen Ziele nicht aus den Augen verlieren. Aber die IT-Strategie an sich ist ja nicht statisch, sondern muss ständig angepasst werden.


Damit mag es in diesem Beitrag genug sein („Eckhard, Deine Beiträge sind viel zu lang…“, TL;DR). Im nächsten Beitrag berichte ich unter anderem, wann eine IT-Strategie zu ambitioniert ist, ob agile Teams überhaupt eine Strategie benötigen und einiges mehr. Stay tuned!

Haben Sie Fragen zu der Erstellung einer IT-Strategie oder welche Fehler man dabei vermeiden sollte? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

Ablösung bestehender Systeme – geliebtes Scheusal…

Die fünf Phasen des Sterbens – im Projektmanagement

Abschied ist ein bisschen wie sterben – Katja Ebstein

4.1.1Change-Management kann so einfach sein – auf Papier, Webseiten und in Projektmanagementstandards. Gut gemachte Kommunikationskonzepte nehmen die Kolleginnen und Kollegen mit auf die Reise von einer veralteten zu einer modernen neuen Lösung, die außerdem noch die Unternehmensprozesse viel besser abbildet. Man ist sich sicher: alles wird gut.

Die Realität sieht anders aus. Man hasst das alte CRM-, ERP-, Mail-System (in einem Unternehmen gab es einen inoffiziellen Wettbewerb für den besten Fluch auf Lotus Notes – leider kann ich den Gewinnerspruch hier nicht nennen ). Aber es weggeben – also nee eh, das muss doch nicht sein. Nun kommen diese Berater und wollen ein besseres System einführen. Moderner, mit besserer Funktionalität, super auf die Prozesse des Unternehmens angepasst, auf allen modernen Spielzeugen, äh Devices lauffähig. Aber dennoch – eigentlich war es doch mit dem alten System recht schön. Man wusste, was man hat und wie man es austrickst. Wie man auf dem kleinen Dienstweg doch vorankam. Wie man die Kaffee- oder Zigarettenpausen mit Lösungen verband. Man hatte seine Rolle. Dies soll nun vorbeisein, unser altes System weggeben? Abschied ist doch immer ein bisschen wie sterben – auch wenn es so ein mieses, bescheuertes System wie XXX (bitte fügen Sie hier ein System Ihrer Wahl ein) ist.

Wie geht man mit diesen Emotionen und Ängsten um? Dies möchte ich im Folgenden beleuchten. Basis für meinen Beitrag sind „Die fünf Phasen des Sterbens“ von Elisabeth Kübler-Ross.

Die fünf Phasen sind „Nichtwahrhabenwollen“, „Zorn“, „Verhandeln“, „Depression“ und „Akzeptanz“.

Wie der Name schon aussagt, bezieht Frau Kübler-Ross ihre fünf Phasen auf das Sterben und auf die Trauer. Ich denke aber sie passen auf viele große Veränderungen im Leben. Wählen Sie mal als Beispiel ein einschneidendes Erlebnis aus Ihrem Privatleben und gehen Sie die Phasen durch (Beschreibung siehe unten). Die Ablösung bestehender Systeme ist ebenso eine große Veränderung – die Mitarbeiterinnen und Mitarbeiter oft mehr trifft, als Verantwortlichen bewusst ist – schließlich hören sie nur die Klagen über die Systeme. Daher fehlt dann das Verständnis, wenn die „alte Pest“ endlich abgelöst werden kann. Auf in die Zukunft, nicht mehr eingeschränkt von einer altertümlichen IT, fehlenden Prozessen und unklaren Zuständigkeiten. Warum beklagt ihr Euch dennoch?!?

Gehen wir daher mal die fünf Phasen durch – begleitet mit einigen typischen Sprüchen, die man in diesen Phasen zu hören bekommt. Sicherlich kommen Ihnen einige der Sprüche bekannt vor 😉 . Dazu einige Tipps, wie man in den Phasen reagieren kann.

Vorab möchte ich noch darauf hinweisen, dass die Akzeptanz neuer Technologien bei Menschen unterschiedlich ist. Nur als Nebensatz: dies gilt auch für Unternehmen, wie man dem „Crossing-the-Chasm“-Modell“ entnehmen kann. Für diese Akzeptanz gibt es verschiedene Modelle, die ich hier nicht aufführen möchte. Für meine Zwecke reichen hier folgende „Typen“ aus:

  • Early Adopters (Nutzer, die sich früh für neue Technologien begeistern, um sich frühzeitig Vorteile zu verschaffen).
  • Early Majority (frühe „Wechsler“, die sich pragmatisch mit neuen Technologien beschäftigen, wenn sie sehen, dass diese sich durchsetzen werden).
  • Late Majority (Wechsler, die gerne zu einem späten Zeitpunkt wechseln, wenn die Anfangsrisiken beseitigt sind).
  • Laggards (Personen, die sich erst mit neuen Technologien beschäftigen, wenn es keine weitere Möglichkeit mehr gibt).

In diesem Kontext ist natürlich nicht gemeint, wann die User auf ein neues System oder neues Tool wechseln – da es hier in der Regel einen „hard cut“ gibt – sondern wann sie sich auf die Reise durch die 5 Phasen begeben. Solche unterschiedlichen „Typen“ haben Sie bestimmt schon oft erlebt. Einige sind technikverliebt und gehen offen auf alles Neue zu, andere ändern sich erst wenn es absolut nicht mehr anders geht. Welchen Typus repräsentieren Sie?

Kommen wir also zu den fünf Phasen, die Frau Kübler-Ross definiert hat.

Nichtwahrhabenwollen (Denial)

„Das kommt doch eh nicht“, „Die reden schon seit so vielen Jahren davon“, „Das klappt sowieso nicht“, „Ich höre nichts“…

In dieser Phase wollen die Betroffenen die Veränderung nicht wahrhaben oder glauben nicht an die Verwirklichung des Projekts. Sie ignorieren Projektpläne und „schwänzen“ Meetings, in denen über neue Systeme informiert wird. Durch frühere, negative Erfahrungen aus anderen Projekten wird dieses Gefühl oft noch verstärkt, z.B. wenn Systeme schon viel früher abgelöst werden sollten, dies sich aber immer wieder verzögert hat. Oder einige andere Projekte sind in der Vergangenheit gescheitert, aus welchen Gründen auch immer.

Solange Betroffene nicht bereit sind, sich zu informieren (oder informieren zu lassen) kann man sie direkt nur schwer erreichen. Aber schon hier zeigt sich, dass die Betroffenen keine „homogene Masse“ sind, sondern den verschieden Typen angehören, die ich oben beschrieben habe.
Hier greifen die üblichen Kommunikationsmaßnahmen: Zeitpläne kommunizieren und öfters mal verdeutlichen, Fortschritte zeigen, eventuell erste Alpha-Systeme zeigen. Aber: sicher sein, dass Zeitplan auch wirklich eingehalten wird, sonst macht man sich unglaubwürdig. Zudem zeigen sich wieder die Vorteile von agilem Vorgehen. Da neue Versionen in kurzen Zeitabständen kommen, entkräftet sich das „Nichtwahrhabenwollen“ in diesen Fällen von selbst.

Gewinnen Sie in dieser Phase „Early Adopters“ für sich und nutzen Sie sie als Multiplikatoren für Ihre Kommunikation.

Und man sollte immer für ein Gespräch bereit sein für die Kollegen, die den „Kopf in den Sand stecken“ – denn irgendwann kommen sie in die nächste Phase…

Zorn (Anger)

„Das geht doch nicht“, „Nicht mit mir“, „Ich kündige“…

Auf das Nichtwahrhabenwollen folgt Wut und Zorn – „warum gerade wir“ – und manchmal auch Neid auf Personen, die der Wandel nicht betrifft.

In dieser Phase werden auch – gerade von Verantwortlichen – Drohungen ausgesprochen, die eine Einführung wirklich gefährden können. Killerargument aus dem Vertrieb ist hier „wenn das kommt, kostet uns dies XXX Prozent Umsatz im nächsten Jahr!“. Aus dem Service hört man „wir brauchen XXX mehr Personen, um dieselbe Last stemmen zu können“. Auch andere Bereiche sind hier kreativ. Bei solchen Killerargumenten ist Managementsupport erforderlich, da diese oft mit Eskalation einhergehen (zum Thema Eskalation bereite ich gerade einen Blogbeitrag vor).
Hier kommt aber auch oft die Angst bei den Beteiligten hervor, man könne etwas von seiner jetzigen Macht oder von seinem Netzwerk verlieren.

Als Projektleiter bekommt man die Aggressionen gerne auch mal direkt und persönlich ins Gesicht geblasen. Hier ist es erforderlich, sich nicht persönlich angegriffen zu fühlen oder gar selbst aggressiv zu reagieren (auch wenn dies nicht immer einfach ist). Versuchen Sie sich in die Personen hineinzuversetzen und deren Probleme und Ängste zu verstehen – damit einfühlsam darauf reagieren zu können. Auch eine Unterstützung durch interne oder externe Coaches ist oft hilfreich – kommt aber nicht immer an die Leute ran.

Verhandeln (Bargaining)

„Können wir das nicht verschieben“, „Jetzt kommt doch das Weihnachtsgeschäft“, „Nächstes Jahr können wir Leute dafür abstellen, aber nicht jetzt“, „Mit etwas optimieren geht das alte Tool doch noch“, „etwas Prozessoptimierung und alles läuft besser“, „Ein paar Aushilfen können die Daten doch wieder reinigen“…

Ist der Zorn verflogen, die Unausweichlichkeit des Projekts erkannt, wird versucht zu verhandeln. Ziele können eine Verschiebung des Projekts, aber auch eine Verhinderung des Projekts sein. Es mag Gründe geben, die sinnvoll erscheinen lassen, ein Projekt zu verschieben. In den meisten Fällen wird dies nicht möglich sein. Hier ist Überzeugungsarbeit gefordert. Rationale Argumente, warum eine Verzögerung nicht möglich ist. Ganz wichtig: keine falschen Hoffnungen wecken („ich versuche das mal…“). Aber hier kann eine „softe“ Betreuung sinnvoll sein. Ängste besprechen und mildern.

Depression

„Das wird die Hölle“, „Damit gehen wir unter“, „Ich habe meinen Urlaub schon storniert“…

Da verhandeln in der Regel zu keinem Erfolg führte, ist die nächste Phase die Depression. In dieser Phase wird die Situation als hoffnungslos und sinnlos empfunden.

Aktives Zuhören ist hier gefragt. Nachfragen ggf. Nachbohren (falls die Personen dies zulassen). Aber auch „in Ruhe“ lassen, wenn keine Kommunikation erwünscht ist. Ggf. eingreifen, wenn Personen in dieser Phase ihre Umgebung „anstecken“ wollen. Insbesondere wenn „Early Adopters“ sich „anstecken“, laufen Sie in ein Problem.

Aber gerade durch aktives Fragen und Nachbohren sollten Allgemeinplätze und Killerargumente entlarvt werden. Negativen Meinungsführern, die keine stichhaltigen Argumente besitzen, wird damit leichter „die Luft aus den Segeln“ genommen. Haben sie aber stichhaltige Argumente, kann man sich ihnen widmen.

Akzeptanz (Acceptance)

„Na gut, wenn es denn sein muss“, „Augen zu und durch“, „Auch diese Umstellung werden wir schaffen“…

In dieser Phase nimmt man das Schicksal an und willig darin ein – es wird sich mit der Situation arrangiert. Auch eine „klare“ Ansage des Managements kann bewirken, dass man sich mit der Wirklichkeit auseinandersetzt.

Jetzt „kriegen“ wir sie! Allerdings wird sich auch erst in dieser Phase wirklich intensiv mit dem neuen System beschäftigt – trotz vorrangegangener Testphasen oder Schulungen. Diese hinterließen oft nur geringe Effekte. Daher muss in dieser Phase Unterstützung angeboten werden – durch Nachschulungen, „Sprechstunden“, ggf. Unterstützung in den ersten Tagen, Buddy Systeme (Early Adopters für Late Adopters) etc.

Wichtig hier: die Bereitschaft sich mit dem Neuen zu beschäftigen nicht stören durch schlechte Rahmenbedingungen. Hierzu gehört z.B. als Voraussetzung eine geeignete und performante Schulungsumgebung. Sonst besteht die Gefahr eines Rückfalls in die Depressions-Phase.


Abschiednehmen: Sie als Berater oder Projektverantwortlicher sind Begleiter in diesem Prozess – obwohl Sie in der Regel dafür nicht engagiert wurden (und erst recht keine Zeit dafür haben). Es macht unsere Aufgabe nicht einfacher. Mit Kenntnis dieser Phasen können wir aber darauf entsprechend reagieren (oder sie zumindest verstehen).

Denn wie sagte schon Arthur Schopenhauer: Jedes Ding erscheint zuerst lächerlich, dann wird es bekämpft, schließlich ist es selbstverständlich. Wie wahr ist dieses Zitat bei der Einführung neuer Systeme…

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

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.