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.

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?!?