Projektreflexion oder Retrospektive – gute Vorbereitung ist alles!

Dies ist mein zweiter Blog-Beitrag zu dem Thema Projektreflexion, der meist ungeliebte Projektabschluss. Im ersten Teil habe ich über die Gründe der Unbeliebtheit gesprochen, über Themen, die in eine Reflexion gehören (und welche nicht) und über die richtige Toolauswahl. Lassen Sie mich heute fortfahren mit den Themen Vorbereitung, Durchführung und Nachbereitung. Und mit der Königsdisziplin – die Reflexion der Reflexion mit Hilfe der drei Schwäne…

Vorbereitung

Feedback eines Sysadmins während meiner ersten Reflexion – eine unvergessliche Erfahrung: Auf die Frage „Was war gut, was war schlecht?“ erntete ich den Kommentar „Wir alle wissen was gut war, warum sollen wir darüber reden?“. Gelächter bei allen Beteiligten (außer mir). Heute kann ich souverän auf einen solchen Einwand („Gut, dass Du und die anderen Beteiligten dies wissen. Dann hole mich kurz ab und zähle die guten Punkte bitte auf“) reagieren. Damals war ich zunächst aus dem Konzept gebracht. Mein Fehler war, am Anfang nicht über den Sinn einer Projektreflexion aufzuklären – warum machen wir das eigentlich? Warum machte ich den Fehler? Ich war nicht richtig vorbereitet.

Vorbereitung ist 90% des Erfolgs. Daher sollten Sie die folgenden Themen vorbereiten:

  • Falls es die erste Reflexion ist: Wie ist eine neue Gruppe, wie kann man sie „bewerten“? Wie erklären Sie den Grund für regelmäßige Reflexion-Sessions? Wie können Sie die Gruppe dazu „mitnehmen“?
  • Falls es eine Folgereflexion ist: Was ist seit der letzten Reflexion passiert (Fortschritte, Misserfolge etc.), hat sich die Gruppe verändert, können Sie die Stimmung vorab einschätzen?
  • Wählen Sie mehrere, unterschiedliche Tools aus, insbesondere bei unbekannten oder wenig bekannten Gruppen.
  • Beantworten Sie die Frage, wie das Meeting für die Beteiligten in einer entspannten Atmosphäre stattfinden kann (Meetingraum etwas abseits, ggf. auswärts. Kaffee und Kuchen etc.). Gehen Sie dabei nicht von sich aus, sondern von der Gruppe.
  • Wie können Sie selbst positiven Mindset für die Reflexion mitbringen?
  • Und natürlich: Erstellen Sie eine Agenda für das Meeting, inklusive eines Rückblicks auf das vergangene Projekt / den vergangenen Sprint etc.

Zusätzlich gelten alle Tipps, die für eine gute Meeting Vorbereitung auch gelten. Wie immer gilt: Zeit in die Vorbereitung zu investieren, bedeutet einen Zeitgewinn bei der Ausführung und erhöht Ihre Flexibilität. Nicht zuletzt steigert es das Vertrauen der Teilnehmer zu Ihnen, weil sie Ihre Vorbereitung bemerken und anerkennen.

„Selbst positiven Mindset mitbringen“ – wie macht man so etwas? Dazu stellen Sie sich bitte die Frage „Warum freue ich mich auf die Reflexion?“ Sie können diese Frage nicht beantworten? Dann läuft etwas schief. Wenn sich die Leitung nicht auf die Reflexion freut, wie können sich die anderen Beteiligten darauf freuen? In diesem Fall sollten Sie mit der Gruppe analysieren, warum keine Freude aufkommt. Dieser Blogbeitrag und der erste Beitrag zu diesem Thema gibt Ihnen bestimmt Anstöße dazu (ansonsten kontaktieren Sie mich…)

„Mehrere Tools auswählen“: Wir alle wissen: Gruppen sind heterogen. Manche sind laut, manche leise, einige sind schnell, andere brauchen etwas Zeit. Wichtig ist, gerade die Stillen und die Zurückhaltenden auch abzuholen. Bei der Auswahl von Tools sollte diese beachtet werden. Haben Sie die richtigen Tools dafür?

„Was ist seit dem letzten Mal passiert“. Präsentieren sie eine Aufbereitung der Ergebnisse seit der letzten Reflexion. Geben Sie Ihrer Gruppe mit Ihrer guten Vorbereitung das Gefühl: Reflexion lohnt sich. Es bewegt sich etwas. Diese ungeliebten Sessions lohnen sich.

Durchführung

Gut vorbereitet beginnen Sie Ihre Reflexion-Session. Was kann schon passieren?

So beginnen Sie mit dem Anfang. Wie beginnt man eine Reflexion? Bisher habe ich mich mit der Vorstellung von Tools zurückgehalten, da es andere Quellen dafür gibt. Als Eingangsübung finde ich aber den „Wetterbericht“ hilfreich. Ich bevorzuge die einfachste aller Durchführungen: man befragt jedes Mitglied der Gruppe, welche Wetterlage sie im vergangenen Projekt / Sprint / Zeitdauer empfanden (z.B. Sonne, Regen, Gewitter, Nebel). Man kann vorher Kärtchen machen, man kann Vorgaben (Wetterarten) machen – man kann das Projektteam aber auch frei das Wetter formulieren lassen. Sie bekommen einen sehr guten Einblick in das Gefühlsleben der Projektteilnehmer und können damit gezielt Vertiefungen vornehmen.

Was kann denn schon passieren – Ablehner können in der Gruppe sein. Der oben erwähnte Kollege war ein typischer „Ablehner“ („Wir alle wissen was gut war…“), jemand der auf Reflexion gar keine Lust hat und mit verschränkten Armen finster in die Runde schaut. Mit offenen Fragen fangen Sie solche „Ablehner“ ein: „Bitte erzähle uns, warum alles schlecht war?“ „Warum kannst Du in dieser Umgebung nicht arbeiten?“ „Was genau stört Dich an dem Projektablauf?“ usw. Hier beziehen Sie das ganze Team mit ein, ob es die Meinung des „Ablehners“ teilt. Falls der „Ablehner“ alleine dasteht, fängt das Team ihn schnell wieder ein. Aber Vorsicht: genauso kann es die gesamte Reflexion sprengen. Wenn Sie merken, dass hier eine Endlosdiskussion in Gang kommt, stoppen Sie diese ab einem gewissen Punkt und schaffen Sie eine Vereinbarung: „Lasst uns dieses generelle Thema in einer gesonderten Besprechung diskutieren und nun mit der Reflexion weitermachen“. Dann wissen Sie, es gibt ein generelles Problem. Selbstverständlich sollten Sie dieses Follow-Up auch organisieren.

Was kann denn schon passieren – Killer Phrasen können kommen. Auch wenn Killer Phrasen in jeder Diskussion vorkommen können (insbesondere bei Brainstormings) höre ich sie verstärkt bei Reflexionen. Wie ich im ersten Beitrag schon erwähnt hatte, sind Reflexionen rückwärtsgerichtet und sprechen auch Fehler und Schwächen an – welches einigen Teilnehmerinnen und Teilnehmern unangenehm ist. Auch ist das Team oft ausgelaugt und daher leicht gereizt. Bereiten Sie sich darauf vor. Mir passiert es immer wieder, dass ich auf Killer Phrasen mit Ironie reagiere. Das kann in Gruppen funktionieren, die sich lange kennen und vertrauen. Besser ist es mit geschickten Rückfragen zu begegnen (z.B. allgemein „Was genau wollen Sie mir jetzt sagen?“). Ganz falsch wäre es, die Killer Phrasen im Raum stehen zu lassen und zu ignorieren. Mehr über Killer Phrasen und ihre Abwehr finden sie beispielsweise hier. Die Unterscheidung zwischen Todschlagargumente und Killer Phrasen, wie sie z.B. Wikipedia vornimmt, halte ich für akademisch und hilft Ihnen bei der Abwehr auch nicht weiter.

Erfolgreich wird Projektreflexion dann, wenn sie was bewirkt. Wenn Aktionen herauskommen, die auch nachverfolgt werden. All die bekannten Methoden motivieren auf Dauer nicht, wenn nichts bei „raus kommt“. Auch hier stellt sich oft ein Motivationsproblem: Gerade im Gefühl des „Ausgelaugtseins“ ist die Motivation eine Aufgabe zu übernehmen übersichtlich.

Doch bevor Sie die Action Items aufnehmen: wie ist die Wetterlage der Teilnehmer nun (siehe oben), mit Hinblick auf die Reflexion und die beschlossenen Maßnahmen. Hoffentlich besser als der Wetterbericht am Anfang. Falls nicht, nochmals nachhaken, was getan werden sollte.

Nachbereitung

Wie las ich in einem Leitfaden für eine Scrum Retroperspektive: „Zu guter Letzt wird die Retrospektive abgeschlossen. Die Ergebnisse werden dokumentiert und die nächsten Schritte geplant“. Dies ist nicht genug. Bei der Durchführung wurden ja neben solchen Schritten auch Verantwortliche und Zeitrahmen festgelegt. Wird die Reflexion von einer externen Beratung durchgeführt, muss außerdem festgelegt werden, wer diese nächsten Schritte auch „trackt“ (Hach, ich liebe Denglisch 😀 ). Zudem sollte man das Team laufend informieren über die Fortschritte. Warten Sie nicht bis zur nächsten Reflexion – geben Sie Wasserstandsmeldungen ab. Damit bleiben die Themen auch in Erinnerung und bei der nächsten Reflexion muss nicht wertvolle Zeit mit Wiederholung vergeudet werden.

Exkurs: die drei Schwäne

Als kleinen Exkurs möchte ich über eine Methode schreiben, die auf der Metapher der „drei Schwäne“ beruht. In meinem Beitrag über Selbststeuerung habe ich davon schon berichtet. Die Metapher ist folgende: Der erste Schwan fliegt, der zweite Schwan fliegt und beobachtet den ersten Schwan beim Fliegen. Der dritte Schwan wiederum fliegt ebenfalls und beobachtet den zweiten Schwan, wie dieser den ersten Schwan beobachtet. Klingt verwirrendend? Beim isb wird dies mit den drei Steuerungsebenen in Verbindung gebracht: Praxis, operative Ebene, Metaperspektive.

Wie kann man diese Metapher bei einer Reflexion einsetzen? Nun auf ein Projekt umgesetzt ist der erste Schwan die vergangene Periode – das beendete Projekt, der Sprint, die Zeitdauer. Die Reflexion ist der zweite Schwan: wir beobachten uns beim Fliegen, sprich wir reflektieren uns und unsere Arbeit. So weit, so gut. Aber was macht der dritte Schwan? Der dritte Schwan ist für Gruppen, die seit langem zusammenarbeiten und langsam das Gefühl bekommen, alles ist eingefahren. Mit dem dritten Schwan versucht man sich zu beobachten, wie man sich reflektiert. Dies bedeutet, man reflektiert die Reflexion. Mit welchen Methoden reflektieren wir uns? Haben wir etwas anders gemacht? Gibt es Themen, die wir immer verschweigen oder uns selbst etwas „vormachen“? Es ist ein Ausbruch aus der Routine der Reflexion. In der Praxis nicht ganz einfach und am besten von einem Berater außerhalb der Gruppe zu moderieren, kann dies Einsichten geben, die man sonst nicht bekommt.

Ich bitte zu beachten, dass beim isb die Metapher der drei Schwäne eine etwas andere Bedeutung hat (mehr Informationen gibt dieses Buch). Ich habe es aber auf die Projektreflexion übertragen, da es sich hier gut anwenden lässt.


Bei der Planung einer Retroperspektive ist es im Grunde wie bei der Planung eines normalen Meetings: Vorbereitung ist alles. Dazu kommt ein kleiner Baukasten mit Tools, aus dem man die zur Situation passende Tools auswählt. Und schließlich wird eine Reflexion am Erfolg gemessen. Bloßes „gut, dass wir mal drüber gesprochen haben“ frustriert Teams und lässt die Lust am Reflektieren gegen Null sinken. Und schließlich die Königsdisziplin: man reflektiert die Reflektion, z.B. mit Hilfe der drei Schwäne. Damit bringt man Teams wirklich vorwärts – und es kann Spaß machen. Aus ungeliebt wird geliebt.
Haben Sie Fragen zum Thema Reflexion oder benötigen Sie einen Moderator für Ihre Reflexion? Dann kontaktieren Sie mich und ich freue mich, Ihre Fragen zu beantworten.

Über Projektkontrolle berichte ich in diesem Blog-Beitrag.

Wurde im letzten Projekt viel improvisiert? Lesen Sie mehr darüber hier.

Zusammenarbeit in der Krise

Manche Krisen kommen sehr schnell. Wenn dann Zusammenarbeit und Reflektion nicht klappt kann es zur Katastrophe kommen – wie beim Flug AF447 im Juni 2009.

Vor einigen Wochen wurde das Ergebnis der erneuten Flugschreiber-Auswertungen des Fluges AF447 veröffentlicht. Das Flugzeug stürzte 2009 auf seinem Flug von Rio de Janeiro nach Paris in den Atlantik nachdem es zu einem Strömungsabriss kam. Alle 228 Insassen verloren ihr Leben.

Einen Bericht über die erneute Auswertung kann man hier nachlesen. Zwei Aussagen von Professor Müller-Seitz, Co-Autor der neuen Studie, möchte ich als Aufhänger für diesen Beitrag zitieren: „Als die Maschine nicht mehr wie gewohnt reagiert, ist der emotionale Stress für die Kopiloten so groß, dass jeder nur noch wie gebannt darauf achtet, was der Bordcomputer macht. An diesem Punkt kollabiert das organisierte Handeln.“ Und weiterhin: „Die letzten Sekunden sind dadurch geprägt, dass die Leute nur noch versucht haben, individuell die Steuerung anhand der Joysticks zu übernehmen, das aber gar nicht mehr abgestimmt war.“ Aus dem Bericht kann man folgendes schließen:

  • Es wurde nur auf Daten geachtet, die von den Systemen geliefert wurden, anstatt eigene Überlegungen anzustellen (es fand keine eigene Reflektion der Ereignisse statt)
  • Es fand keine Abstimmung zwischen den handelenden Personen statt. Ein „Zusammenbruch der Teamstruktur, der Kommunikationsstruktur“ wie es Müller-Seitz zusammenfasst.

Nun fand dies alles in wenigen Minuten statt, eine Situation die ich keinem von Ihnen (und mir) jemals wünsche. Aber diese Ergebnisse kann man auch gut auf plötzliche Krisen in Projekten und im täglichen Betrieb übertragen. Auch hier kommen manchmal Krisen „aus dem Nichts“ – unvorhergesehen und in keinem Risikomanagement berücksichtigt. Aber selbst bei „schleichenden“ Krisen, die sich langsam entwickeln kann man dieses Verhalten beobachten. Bund und Länder, Militär und große Unternehmen haben natürlich ein ausgefeiltes Notfall- und Krisenmanagementkonzept für solche Fälle. Das BSI hat für ihrem IT-Grundschutz einen extra Baustein für das Notfallmanagement – dies beschäftigt sich mit dem Betrieb von IT-Anlagen und ist weniger geeignet für Projekte.

Das oben beschriebene Verhalten der Nicht-Kommunikation und daher der Nicht-Zusammenarbeit in einer Krise ist sehr menschlich. Gerade in Krisensituationen gibt es die Neigung zur Panik und zum unkontrolliertem Handeln. Jeder versucht mit viel Aktivismus und gutem Willen die Krise zu meistern und das Projekt zu retten. Kommunikation bleibt dabei oft auf der Strecke oder beschränkt sich auf endlose Eskalationsmeetings (dieser Beitrag kommt irgendwann wieder…).

Damit meine ich nicht die Kommunikation nach außen, sondern die interne Kommunikation, die Zusammenarbeit, das Miteinander. Und wenn die Kommunikation abbricht gibt es auch kein gemeinsames Handeln mehr. Aber unkontrolliertes, sich teilweise widersprechendes Handeln einzelner Akteure führt selten zum Erfolg.


Welche Punkte sollte man in solchen Krisen beachten?

Zunächst einmal Innehalten – dies mag merkwürdig klingen, wenn man einem Flugzeugabsturz entgegensieht. Dennoch, ein kurzes Innehalten – und wenn es nur einige Sekunden sind – ist immer sinnvoll. Was ist eigentlich passiert? Können wir den Daten trauen? Wie sollte eigentlich die Datenlage aussehen? Wie konnte es so schnell zu dieser Situation kommen? Wie können wir als Team diese Situation meistern? Wer ist für welche Aufgaben verantwortlich? Kurzes Innehalten hilft oft auch, um emotionalen Stress wieder „einzufangen“ und rational handeln zu können.
In einem absoluten Notfall wie bei Flug AF447 bleiben dafür nur wenige Sekunden. Da wir aber keine Flugzeugführer sind, können wir uns etwas mehr Zeit nehmen und diese Fragen ein wenig tiefer betrachten:

  • Was ist eigentlich passiert – machen Sie eine kurze Root Cause Analyse. Was ist die eigentliche Ursache / der Auslöser für die Krise, was sind nur Symptome?
  • Können wir den Daten, die wir bekommen, glauben? Falls nicht, wie sollten die Daten eigentlich aussehen? Sind sie manipuliert worden? Zufällig oder absichtlich? Von wem?
  • Wie können wir die Situation möglichst schnell stabilisieren? Maßnahmen hierfür können unterschiedlich sein als für eine endgültige Lösung. Eine zwischenzeitliche Stabilisierung, die etwas Luft verschafft, hilft um an einer finalen Klärung der Situation zu arbeiten.
  • Wer ist für welche Aktionen verantwortlich? Hier kommt die Zusammenarbeit „ins Spiel“. Um effektiv und effizient im Krisenfall arbeiten zu könne, müssen die Verantwortlichkeiten geklärt werden. Diese können anders sein als im üblichen Projektalltag – da eventuell andere Fähigkeiten gefragt sind. Die Beteiligten sollten hier ihre Eifersüchteleien hintenanstellen und für den Moment am gemeinsamen Ziel arbeiten.
  • Wie kann sichergestellt werden, dass alle Beteiligten die Informationen bekommen, die sie benötigen?
  • Was können wir im Moment vernachlässigen? Vormals wichtige Dinge können im Moment ohne Belang sein. Irgendwelche Reportings, die im Moment nicht weiterhelfen. Abrechnungen am Ende des Monats, die sonst heute erledigt werden müssten, aber im Moment ignorieren werden können.
  • Wann beurteilen wir die Situation das nächste Mal?

All dies sollte schnell, informell und unbürokratisch geschehen. Keine großen Excel-Listen, keine Power-Point Präsentationen. Eine kurze Check-Liste, egal mit welchem Programm erstellt (zur Not auf Papier), auf welche alle zugreifen können. Keine Planung bis zum nächsten Jahr, sondern nur bis zum nächsten Check-Point. Der Zeitrahmen bis zum nächsten Check-Point ist der Situation anzupassen – sollte aber in jedem Fall kurz sein. Die Faktenlage kann sich in Krisen schnell ändern und muss dann neu beurteilt werden.

Noch ein wichtiger Punkt: Ist der eine oder andere Beteiligte emotional überfordert – lassen sie die Person außen vor, so hart das klingt. Betreuen sie andere Personen mit dessen Aufgaben und kommunizieren sie dies informell (mit Begründung, warum dies in der momentanen Situation so sein muss). Vielleicht gibt es im Team Personen, die sich um solche Mitarbeiter kümmern können und damit dafür sorgen – und ich sage es bewusst so hart – dass sie nicht im Weg stehen oder Unsinn anstellen.

Hoffen wir, dass sie damit Ihre Krise meistern können. Wurde ein solches Ereignis überwunden, geht das Team oft gestärkt daraus hervor. Auch ein schönes Ergebnis. Danach steht die Reflexion an, um eine erneute Krise dieser Art zu verhindern.

Noch ein Wort zum Thema „Planung“ – bevor eine Krise auftritt. Planen und Üben. Auf den ersten Blick die beste Möglichkeit sich vorzubereiten. Wie oben erwähnt, haben viele Behörden und Unternehmen ausführlich Notfallpläne – die auch geübt werden. Wer schon einmal eine Feuerwehrübung in einem Hochhaus mitgemacht hat und sich vorher im 49. Stockwerk befand, weiß wie anstrengend eine solche Übung sein kann (besonders mit Stöckelschuhen ). In Projekten mit oft wechselnden Verantwortlichkeiten ist dies aber meist sehr schwer möglich. Zudem: es ist schwierig vorherzusagen, was eine Krise auslöst. Dennoch möchte ich Teams, die lange zusammenarbeiten, selbstverständlich nicht davon abhalten, Krisenpläne vorab zu erarbeiten und zu üben. Es bleibt die Frage, ob die Zeit dafür vorhanden ist.


Der Ausfall des Autopiloten wird inzwischen von Piloten im Flugsimulator trainiert – auch als Konsequenz des Absturzes der Air France Maschine. Fliegen ist also noch etwas sicherer geworden als es sowieso schon war. Wenn es nicht etwas zynisch klänge würde ich sagen, die Verpflegung an Bord ist sowieso die größte Katastrophe…

Seien Sie also vorbereitet für die nächste Krise – egal ob im Projekt oder im Betrieb. Im nächsten Beitrag kommt dann die Fortsetzung von „Projektreflexion oder Retrospektive – der ungeliebte Projektabschluss“. Haben Sie Fragen zum Thema Krisenmanagement? 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.

Den zweiten Teil zum Thema Projektreflexion finden Sie hier.

Über Zusammenarbeit in der Krise berichte ich hier.

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.