Kommentierte Links (LXXI)
 |
| Grafik: Pixabay / The Digital Artist - Lizenz |
Samstag, 30. Januar 2021
Charles Lambdin: Bureaucratic Blunderland
Sich zu sehr an sarkastischen Beschreibungen der Pathologien grosser Organisationen zu erfreuen kann ein starker Indikator dafür sein, dass man die innere Mitte verloren hat. Andererseits - die Sammlung von Antipattern die Charles Lambdin hier zusammengetragen hat verdient alleine aufgrund der Expertise verratenden Recherche und der liebevoll kommentierten Kuratierung Aufmerksamkeit. Selbst jemand der sich schon sein gesamtes Berufsleben mit professionellen Dysfunktionen beschäftigt hat wird neue, pointierte Beschreibungen vertrauter (und verabscheuter) Muster finden, zum Beispiel Zumwalt’s Second Law: "No matter what result is anticipated, there is always someone willing to fake it", oder Sevareid’s Law: "The chief cause of problems is solutions". Lesen lohnt sich, danach sollte aber zum Ausgleich etwas Positives konsumiert werden.Dienstag, 26. Januar 2021
Paradoxe und konsistente Kommunikation
 |
| Bild: Pexels / Andrea Piacquadio - Lizenz |
Zu den grössten Herausforderungen die agile Transitionen in bisher klassisch geprägten Unternehmen mit sich bringen gehört die begleitende Kommunikation. Vor allem dort wo die Mitarbeiter schon eine Reihe von Top-Down durchgeführten, auf "Ressourcenoptimierung" ausgelegten oder schlecht begründeten Change-Programmen hinter sich haben ist die Wahrscheinlichkeit gross, dass es zu Change Fatigue, Konzern-Anarchismus und brauchbarer Illegalität kommen wird wenn der Verdacht aufkommt, das die Veränderungen "mal wieder" nicht ernst gemeint sind - und dieser Verdacht kann durch kaum etwas so schnell ausgelöst werden wie durch unstimmige Botschaften.
Gerade um dieses Risiko auszuräumen ist es mittlerweile zum Standard geworden grössere Change-Programme mit aufwändigen Kommunikationskampagnen zu begleiten, in denen wiederholt und eloquent dargelegt wird, dass es diesesmal wirklich ernst gemeint ist mit der neuen Arbeitswelt und der neuen Unternehmenskultur. Jeglicher Verdacht auf fehlende Ernsthaftigkeit soll auf diese Art und Weise von Anfang an zerstreut werden. Soweit die Theorie. In der Realität sind es häufig gerade diese Kampagnen durch die das Misstrauen in der Belegschaft so richtig angefacht wird.
Um zu verstehen warum das so ist, ist ein kurzer Exkurs in die Wissenschaft nötig. Es ist Konsens in Sozialpsychologie und Soziologie, dass Kommunikation mehr ist als das explizite Austauschen von Botschaften in Schrift-, Bild- und Ton-Form. Auch nonverbale Kommunikation, öffentliches Vorleben und sogar bewusstes und unbewusstes Unterlassen gehören dazu. Berühmt ist z.B. Paul Watzlawicks Axiom "Man kann nicht nicht kommunizieren", ebenfalls bekannt ist Niklas Luhmans Definition, dass soziale Systeme praktisch nur aus Kommunikation bestehen. Alles was Menschen tun ist potentielle Kommunikation.
Zurück in die Realität. Ausgehend von der Erkenntnis, dass alles Handeln und Verhalten Teil der Kommunikation sein kann, stellt sich die Wirkung von Change-begleitenden Kommunikationskampagnen anders dar. Sie sind nur ein Teil der Gesamtkommunikation, der andere ist das tägliche Tun (und Unterlassen) der jeweils anderen Organisations-Mitglieder, und unter ihnen herausgehoben der Führungskräfte. Diese verschiedenen Kommunikations-Bestandteile werden von ihren Empfängern bewusst oder unbewusst gesammelt und zu einem Gesamtbild zusammengefügt.
Ist dieses Gesamtbild in sich widersprüchlich (z.B. wenn Feedback-Kultur gepredigt wird aber kritisches Feedback ignoriert wird) liegt eine so genannte "paradoxe Kommunikation" vor. Dieses in Konflikt miteinander Stehen von Kommunikationsteilen (so genannte Doppelbotschaften) führt bei den Empfängern zum Gefühl von Unsinnigkeit oder Unehrlichkeit, womit meistens genau das eintritt was eigentlich verhindert werden soll - das Change-Programm wird abgelehnt, mit den zu Beginn genannten Abwehrhaltungen als Folge.
Soll es nicht dazu kommen ist es nötig, dass auf eine Art und Weise kommuniziert wird die von den Empfängern als widerspruchsfrei und in sich stimmig wahrgenommen wird, die Rede ist dann von "konsistenter Kommunikation". Da in ihr das Gefühl vermittelt wird, dass Reden und Tun in Übereinstimmung sind, hat sie eine hohe Glaubwürdigkeit. Dadurch wird eine höhere Bereitschaft erzeugt sich auf die vermittelte Botschaft einzulassen, was in diesem Fall bedeuten würde sich am Change-Programm zu beteiligen und ihm so zum Erfolg zu verhelfen.
Das kurze Fazit der langen Geschichte: wer Organisationen erfolgreich verändern will muss das was er von anderen fordert selbst vorleben. Wenn das nicht geschieht wird es hingegen sehr, sehr schwer. Bei der Konzeption Change-begleitender Kommunikationskampagnen sollte daher immer bedacht werden, dass das tägliche Handeln und Verhalten entscheidend dafür ist ob die Kommunikation als paradox oder konsistent wahrgenommen wird. Man hat die Wahl.
Donnerstag, 21. Januar 2021
Verschachtelte Sprints
 |
| Bild: Pixabay / Hannah Alkadi - Lizenz |
Im Kosmos der agilen Frameworks gibt es Begriffe die niemand kennt, hinter denen sich aber Phänomene verbergen die in vielen Teams so alltäglich sind, dass es niemandem auffällt, dass sie keinen bekannten Namen haben. Verschachtelte Sprints (auf Englisch "nested Sprints") gehört in diese Kategorie. Kaum jemand nennt sie so, dort wo Scrum oder andere iterative Ansätze angewandt werden sind sie aber durchaus häufig anzutreffen.
Konkret verbergen sich dahinter mehrere aufeinanderfolgende Sprints deren Länge genau einem grösseren Zeitraum (der auch Sprint heissen kann, aber nicht muss) entspricht. Diese Anordnung - ein Objekt das mehrere andere Objekte enthält - entspricht genau der üblichen Definition von Verschachtelung. Die Benennung passt also. Nur - warum macht man so etwas? Die naheliegende Antwort: um die Arbeit von Scrum-Teams in grössere Planungs- und Lieferzyklen zu integrieren oder um Synchronisierungen zu erleichtern.
Häufig anzutreffen ist in diesem Zusammenhang ein "Einschachteln" in einen klassischen Planungszyklus, z.B. einem Quartals-, Halbjahres- oder Jahresplan. In einer klassisch aufgestellten umgebenden Organisation kann das ein einfacher erster Schritt in Richtung Agilität sein, da es die bestehenden Budgetierungs- und Planungsprozesse noch nicht angreift und so Konflikte vermeidet. Es besteht aber das Risiko, dass Sprints dadurch bewusst oder unbewusst lange im Voraus verplant werden, wodurch die eigentlich gewünschte Flexibilität verlorengeht.
Eine ebenfalls häufige Hybridform zwischen agilem und klassischem Vorgehen liegt vor, wenn mehrere Sprints der Dauer zwischen zwei Meilensteinen eines klassisch arbeitenden Teams entsprechen. Das macht vor allem Sinn wenn dieses andere Team zwar eine langfristige Grobplanung, dafür aber einen kürzeren Ausdetaillierungs-Rhythmus hat (eine so genannte Rolling Wave-Planung). Auch bei starrer geplanten Meilensteinen ist eine Synchronisierung mit Sprints möglich, dann aber erneut mit dem Risiko Flexibilität einzubüssen.
Selbst wenn verschachtelte Sprints vor allem in Hybrid-Kontexten häufig sind gibt es sie auch dort wo nur (mehr oder weniger) agile Teams zusammenarbeiten. Am bekanntesten dürften dabei die so genannten "Program Increments" im Scaled Agile Framework (SAFe) sein, die in der Regel vier bis fünf Sprints umfassen, ein anderes Beispiel sind die "light-weight, risk-based milestones" aus dem zum PMI gehörenden Disciplined Agile.
Zuletzt können mehrere Scrum Teams ihre Sprints ineinander verschachteln, etwa wenn ein Teil von ihnen Sprintlängen von einer Woche hat und ein anderer Teil von zwei Wochen. Ein Szenario in dem eine derartige Synchronisierung Sinn macht wäre zum Beispiel eines in dem gemeinsame Sprint Reviews stattfinden um die Kalender der Stakeholder zu entlasten. Ein anderes wäre gegeben wenn Nutzer einer Software um eine Zusammenlegung der Produktions-Releases am Sprintende bitten, um sich nur ein- oder zweimal pro Monat auf ein neues System-Verhalten einstellen zu müssen.
Zusammengefasst: es gibt viele gute, halbwegs gute oder schlechte Gründe dafür verschachtelte Sprints einzusetzen. Da nicht immer klar ist mit was man es zu tun hat (und da sich die Bewertung auch ändern kann) ist es sinnvoll ein regelmässiges Inspect & Adapt durchzuführen. Zum Glück ist das in derartigen Konstellationen leicht - gleichzeitig endende Sprints sind gute Anlässe für gemeinsame Retrospektiven.
Montag, 18. Januar 2021
Verknappung als Treiber für Kulturwandel
Über die Jahre habe ich einige Versuche erleben dürfen Unternehmenskulturen zu verändern, und Simon Sinek fasst es gut zusammen: viele werden betrieben wie Marketing-Kampagnen, durch die möglichst viele Menschen möglichst schnell überzeugt werden sollen. Leider ist auch seine darauf aufbauende Beobachtung richtig, die meisten davon sind bestenfalls relativ erfolgreich. Sein Ansatz ist erkennbar anders - er basiert darauf sich auf die Gruppe der Early Adopters zu konzentrieren und zu Beginn die Möglichkeiten zur Teilnahme zu verknappen. Dadurch steigt in der Wahrnehmung des restlichen Unternehmens die Wertigkeit Change-Programms und damit auch der Wunsch daran teilzunehmen.
Donnerstag, 14. Januar 2021
Digitalisierung (V)
 |
| Grafik: Pixabay / Geralt - Lizenz |
Einer der Gründe wegen denen ich diese kleine Website betreibe ist, dass ich das hier gesammelte Material zur Wissensvermittlung (und Meinungsäusserung) bei meinen Kunden einsetzen kann - und dass sie auch danach noch dauerhaft darauf zugreifen können. In diesem Zusammenhang sind nach und nach verschiedene Inhalts-Typen entstanden, unter anderem auch einer der mittlerweile so häufig geworden ist, dass er jetzt eine eigene Kategorie bekommt: die der Begriffsdifferenzierungen, in der es darum geht, dass man viele Begriffe auf unterschiedliche Weisen verstehen kann.
Auch heute gibt es wieder eine solche Differenzierung, diesesmal mit einem Klassiker: der Digitalisierung. Denn (Surprise!) auch hinter diesem Wort können sich durchaus verschiedene Bedeutungen verbergen. Diese hier sind aus meiner Sicht die Wichtigsten:
Digitalisierung von Dokumenten
Die vermutlich erste Variante der mit der die meisten der heute Berufstätigen in Kontakt gekommen sind, z.B. weil viele Universitäten seit Ende der 90er von ihren Studenten verlangen, dass Referatsunterlagen und Hausarbeiten auch als Word- oder Powerpoint-Dokument abzugeben sind. In vielen Organisationen bis heute die primäre Form der Digitalisierung. Ein Beispiel dafür wäre der Bundestag, der alle öffentlich zugänglichen Dokumente einfach in PDFs umwandelt und auf seine Website stellt.
Digitalisierung von Kommunikation
Ebenfalls eine grundlegende Form. Zu nennen ist hier zunächst die Digitalisierung der schriftlichen Kommunikation, die zuerst in Form von Emails und später in Messenger-Diensten wie WhatsApp stattfand, noch später kamen dazu die Digitalisierung von Gesprächen mit Voice over IP und von visueller Kommunikation mit den verschiedenen Videoconferencing-Diensten wie Skype oder Zoom. Da über sie nicht nur direkte Kommunikation sondern auch Meetings stattfinden gibt es einen fliessenden Übergang zum nächsten Typ.
Digitalisierung von Arbeitsprozessen
Wenn heute in grossen Organisationen Digitalisierungsprojekte gestartet werden ist meistens diese Variante gemeint, die sich in weiten Teilen mit der Prozess-Automatisierung überschneidet. Moderne Posteingangssysteme sind beispielsweise in der Lage bei eingehender Post die zuständige Abteilung zu erkennen und an sie weiterzuleiten, was früher von Hand passiert wäre. Ein Problem kann dabei auftreten wenn "historisch gewachsene" Abläufe eins zu eins digitalisiert werden. Mit den unsterblichen Worten von Thorsten Dirks: "Wenn sie einen Scheißprozess digitalisieren, dann haben sie einen digitalen Scheißprozess."
Digitalisierung von Geschäftsmodellen
Der heilige Gral der heutigen Digitalisierung, wenn man so will. Die Übertragung ganzer Geschäftsmodelle in die digitale Form macht völlig neue Produkte und Dienstleistungen möglich, etwa im Fall von Streaming-Diensten, die nicht nur ein digitalisierter Video-Versand sind, sondern auch Empfehlungs-Algorithmen und interaktive Filme umfassen oder im Fall von digitalen Notenheften, die es durch Software möglich machen aus Orchesterwerken einzelne Stimmen zu extrahieren, die Tonart einzelner Passagen zu verändern oder am Konzert-Ton zu erkennen wann umgeblättert oder gescrollt werden muss.
Digitalisierung von Kreativprozessen
Die höchste Stufe an der aktuell gearbeitet wird, und dazu eine die für viele Menschen leicht gruselig ist, da sie in einen Bereich hineingeht von dem man bis vor kurzem glaubte, dass ihn nur das menschliche Gehirn beherrscht. Da sich diese Entwicklung mit der (final noch ungeklärten) Frage überschneidet was eigentlich Kreativität ist fehlt hier noch eine allgemein anerkannte Definition. Klar ist aber auch, dass bereits heute Tätigkeiten von Computern ausgeübt werden die man früher als kreativ bezeichnet hätte, etwa das Malen von Bildern oder das Schreiben journalistischer Texte.
Digitalisierung des Bewusstseins
Im Moment noch Science Fiction. Auch hier besteht das Problem, dass die Phänomene "Intelligenz" und "Bewusstsein" nicht genau definiert sind, es besteht aber die theoretische Möglichkeit, dass der technische Fortschritt irgendwann zur technischen Singularität und künstlichem Bewusstsein führt. Eine mit Bewusstsein ausgestattete künstliche Intelligenz könnte dann (neben vielem Anderen) in der Lage sein selbst unternehmerische Entscheidungen zu treffen. Nach allem was wir wissen wäre das die Endstufe dessen was wir als Digitalisierung bezeichnen.
Montag, 11. Januar 2021
Der Vorteil von SAFe (I)
 | |
| Bild: Pexels / Skitterphoto - Lizenz |
Der zunehmende Wunsch grosser Unternehmen durch Agilität erfolgreich zu werden hat im letzten Jahrzehnt zum Entstehen und zum Aufstieg des Scaled Agile Framework (SAFe) geführt. Das Problem an dieser eigentlich begrüssenswerten Entwicklung ist, dass sich in ihm vieles von dem wiederfindet was die agile Bewegung eigentlich überwinden wollte: hohe Regulierung sowie Strukturen und Abläufe die der "alten Welt" sehr ähnlich sind. Für viele agile Practitioner, Coaches und Scrum Master hat SAFe daher wenig mit echter Agilität zu tun.
Ohne diese Probleme bestreiten zu wollen kann man auf der anderen Seite in SAFe aber durchaus das Potential sehen agile Transitionen voranzutreiben. Es gibt sogar Aspekte von Transitionsvorhaben die mit ihm einfacher zu erreichen sind als mit anderen Frameworks, und unter diesen ist vor allem zu nennen, dass es mit ihm einfacher ist ein eher traditionelles Management davon zu überzeugen sich überhaupt auf die Veränderungen einzulassen.
Ursächlich dafür sind nachvollziehbarerweise die weiter oben genannten Faktoren die auf die agile Comunnity abstossend wirken, also Regulierung, Hierarchie und längere Lieferzyklen. Ein Management das so sozialisiert wurde, dass es an diesen Prinzipien hängt, wird SAFe ansprechender finden als z.B. LeSS. Und da auch in SAFe (gebremste, aber doch vorhandene) Feedbackschleifen und Dezentralisierungen eingebaut sind gelangen diese so in die Organisation. Sie mögen dann zwar noch eingeschränkt sein, aber sie sind schonmal eingeführt.
In diesem Zusammenhang findet sich mitunter das Argument, dass SAFe im Rahmen einer agilen Transition ein früher Zwischenstand ist, über den man hinauswachsen kann sobald man die agilen Prinzipien verinnerlicht hat. Das kann man so sehen (und dort wo es wirklich zu einer Verinnerlichung gekommen ist wird es tatsächlich entweder formell oder informell zum Regelabbau kommen), man muss sich aber bewusst sein, dass das kein Automatismus ist. Viele Organisationen werden mit SAFe zufrieden sein.
Vielleicht ist aber auch genau das ein weiterer der Vorteile des Scaled Agile Framework. Es ermöglicht Organisationen nur "ein bisschen agil" zu werden. Natürlich muss jeder Manager der das so entscheidet sich bewusst sein, dass man damit auch nur ein bisschen von den Vorteilen bekommt die mit Agilität verbunden sein können. Aber wenn das bewusst so gewollt wird ist eben auch klar - es ist noch immer ein Fortschritt im Vergleich zum Zustand vorher.
Donnerstag, 7. Januar 2021
... und sie schrien nach Klopapier
 |
| Bild: Pixabay / Jasmin Sessler - Lizenz |
Klopapier ist ein ganz besonderer Stoff. Während Pandemien und anderen Katastrophen gehört es zu den ersten ausverkauften Produkten, und auch in normalen Zeiten kann es als die symbolhafte Verkörperung der sprichwörtlichen dünnen Schicht zwischen der Sauberkeit moderner Zivilisationen und dem Schmutz des Mittelalters gelten. Ganz nebenbei ist es aber auch das Hauptthema einer Anekdote die ich gerne erzähle, einer in der es um die Risiken lokaler Optimierung geht und die auch ein schönes Beispiel für die etwas abwegigen Impediments liefert, mit denen ein Scrum Master mitunter konfrontiert sein kann.
Die Geschichte ereignete sich vor einigen Jahren in einem grossen IT-Projekt eines internationalen Konzerns, einem jener Projekte die so gross sind, dass dafür ein eigenes Gebäude angemietet wurde und das soviel Büro-, Küchen- und Hygiene-Artikel verbrauchte, dass diese regelmässig mit Lastwagen und Gabelstaplern angeliefert wurden. Im Gesamtbudget waren die dafür nötigen Ausgaben kaum sichtbar, für sich genommen ergaben sie aber einen erstaunlichen Betrag.
Nachdem das einmal aufgefallen war wurde hier direkt ein Sparpotential erkannt und das Project Management Office wurde angewiesen die Einkaufspreise zu drücken. Das geschah zum Teil durch die Auswahl billigerer Anbieter, zum Teil aber auch dadurch, dass auf Sonderangebote gewartet wurde. Sobald die irgendwo auftauchten wurden die Bestände aufgefüllt, wenn nicht wurde mit dem Einkauf weitergewartet bis das wieder der Fall war. Sogar definierte Grenzbeträge wurden festgelegt die die Preise nicht überschreiten durften.
Was dann irgendwann passierte dürfte nach dieser Vorrede wohl keinen mehr wundern - die Klopapier-Vorräte waren einmal mehr aufgebraucht, aber gerade zu diesem Zeitpunkt lag kein Anbieter und kein Geschäft mit seinem Preis unterhalb des Grenzbetrages. Das Project Management Office wusste das, ihm waren durch die internen Vorgaben aber die Hände gebunden - es wurde also kein Nachschub gekauft, womit das Drama seinen tragischen Verlauf nahm.
Zuerst verschwanden auch die Vorräte an Küchentüchern und Papier-Wischtüchern, als nächstes begannen die Projekt-Mitarbeiter die Toiletten der umliegenden Lokale zu benutzen, was diese schnell unterbanden. Schliesslich setzten extreme Massnahmen ein: einige Kollegen assen nur noch kleinste Mengen zum Frühstück und Mittagessen (und waren ständig hungrig und schlecht gelaunt), andere fuhren täglich quer durch die Stadt zu anderen Standorten um sich dort zu erleichtern, wieder andere erschienen einfach nicht mehr und arbeiteten nur noch von zu Hause.1
"Wenn das kein Impediment ist, was dann?" fragten die Teams, und da ich zu der Zeit dort Scrum Master war durfte ich nach einer Lösung suchen. Um die unmittelbare Not zu lindern überredete ich das PMO zu einem Akt brauchbarer Illegalität. Das Hygieneartikel-Beschaffungsbudget war zwar nicht erreichbar, wir beschlossen aber ein anderes zweckzuentfremden. Es war das Briefmarkenbudget, das irgendwie den Umstieg auf Email überstanden hatte, nicht mehr genutzt wurde und daher prall gefüllt war. Mit ihm in der Tasche und allen Praktikanten im Schlepptau kaufte ich die Regale des nächsten Drogeriemarktes leer.
Das kurzfristige Problem war damit gelöst, das langwierige war etwas hartnäckiger. Letzten Endes bedurfte es einer konzertierten Anstrengung von verschiedenen Seiten: der Projektleitung wurde aufgezeigt woher der Produktivitätsrückgang kam, mehrere festangestellte Kollegen aktivierten den Betriebsrat, andere drohten ihren Vorgesetzten mit Kündigung, mehrere Teams korrigierten ihre Aufwandsschätzungen deutlich nach oben. Was genau den letzten Anstoss gab liess sich nicht mehr feststellen, aber irgendwann wurden die Einkaufs-Beschränkungen aufgehoben.
Wie oben gesagt, die Anekdote kann zur Illustrierung einiger entgleister Mechanismen grosser Organisationen benutzt werden. Dazu gehören der Drang zur Optimierung jedes noch so unbedeutenden Betrages, das parallele Existieren von sinnlos-Budgets (Briefmarken) und die scheuklappenhafte Ignorierung der Bedürfnisse anderer Organisations-Silos, aber auch das Vermeiden ernsthafter Aufarbeitung von Problem durch das "rückwirkende Verschwindenlassen" der Ursachen (noch gar nicht erwähnt: per Dekret wurde erklärt, den Grenzbetrag habe es nie gegeben, es wäre alles nur ein Missverständnis gewesen).
Vor allem ist es aber eine schöne Geschichte die immer dann erzählt werden kann wenn ein Beispiel für das gebraucht wird was ein Scrum Master den ganzen Tag macht.
Montag, 4. Januar 2021
Dystopische Software-Entwicklung
 |
| Bild: Pixabay / Crow Imagenes - Lizenz |
Wer in Familie oder Bekanntenkreis passionierte Computerspieler hat wird in der Weihnachtspause um ein Thema nicht herumgekommen sein: die verheerend verlaufene Markteinführung des dystopischen Rollenspiels Cyberpunk 2077. Angekündigt als Meilenstein seines Genres und mit hohen Erwartungen begrüsst erwies es sich als so unausgereift und fehleranfällig, dass es auf vielen Endgeräten praktisch nicht spielbar war. Die damit für den Hersteller verbundenen Geld- und Reputationsverluste dürften kaum abzuschätzen sein.
Zahlreiche Medien haben über die Geschichte hinter diesem Fehlschlag geschrieben, unter anderem die New York Times, die Washington Post, Slate, der Guardian, die Zeit und Heise. Der Tenor dieser Berichterstattung ist, dass er durch lang bekannte systemische Ursachen herbeigeführt wurde, die typisch für die Computerspiel-Branche sind. Ich würde sogar noch weitergehen und sagen, dass diese Ursachen (mehr oder weniger stark ausgeprägt) in den meisten grossen Software-Projekten vorkommen. Sie alle sind mir schon mehrfach begegnet. Hier sind sie:
Unrealistische Zeitplanung
Nicht nur einer der frühesten Fehler sondern auch einer der schwerwiegendsten. In sehr vielen Firmen werden grosse IT-Projekte zu optimistisch geplant, sei es aus Selbstüberschätzung, aus Wunschdenken, wegen fehlendem Sachverstand oder um sie überhaupt genehmigt zu bekommen. Schlimmstenfalls werden diese Planungen noch mit weiteren verknüpft, von den Karriereplänen des Managements bis zur Ressourcenplanung des nachfolgenden Projekts.
Keine Anpassung der Zeitpläne während des Projekts
Aus den gerade genannten Gründen, aber auch weil Neuplanungsprozesse in der Regel sehr aufwändig gestaltet sind, versuchen viele Organisationen eine Anpassung der Zeitpläne so lange wie möglich zu vermeiden - selbst dann wenn allen Beteiligten klar ist, dass sie unrealistisch sind. Gerade bei langlaufenden Projekten kommt noch ein weiterer Faktor dazu: gelingt es die Anpassungen weit genug in die Zukunft zu schieben ist man selbst nicht mehr betroffen.
Frühes Aufbrauchen des Zeitpuffers
Eine Auswirkung des letzten Punkts. In praktisch jedem grossen Vorhaben wird ein Zeitpuffer eingeplant, mit dem es möglich ist Verspätungen zu kompensieren. Wenn aber selbst in frühen Projektphasen erkannte Planabweichungen nicht zu Neuplanungen führen sondern nur zum Aufbrauchen des Puffers, dann ist die Flexibilität die er liefert zum Projektende hin nicht mehr gegeben - gerade dann wenn sie am dringendsten gebraucht würde.
Aufwändige Vermarktung des unrealistischen Zieldatums
Egal ob es Werbekampagnen für B2C-Produkte sind, Messeauftritte für B2B-Produkte oder sonstige Marketing-Massnahmen - man kann hier erstaunliche Summen investieren. Eine Markteinführung für die die Vermarktung bereits begonnen hat lässt sich daher meistens nur gegen massive Widerstände verschieben, da dieses Geld dann abgeschrieben werden müsste. Dabei ist es dann auch egal ob der Marketing-Verantwortliche wusste wie realistisch das Zieldatum ist oder nicht.
Qualitätssicherung erst kurz vor der Veröffentlichung
Eine weitere Folge unrealistischer Zeitplanung. Um länger an der Fertigstellung von Features arbeiten zu können wird versucht die nachfolgenden Schritte zu komprimieren. Im Fall von Software-Test eine folgenschwere Entscheidung - entweder müssen sie unter hohem Zeitdruck stattfinden und sind dann unvollständig und schlampig oder es werden zeitgleich zu ihnen noch Features gebaut, worurch vor allem frühe Integrations- und Regressionstests wertlos werden.
Massive Überstunden in der Schlussphase
Im Grunde schon das erste Anzeichen dafür, dass die Planungen fehlgeschlagen sind. Das was in der normalen Arbeitszeit nicht zu schaffen ist soll jetzt nachts und am Wochenende stattfinden, was zu Überarbeitung, Fehlern und weiterer Mehrarbeit führt. Eine in diesem Zusammenhang häufige Dysfunktion: sobald Überstunden in Projekt-Schlussphasen normal werden, werden sie oft von Anfang an schon verplant, wodurch es nicht mehr möglich ist sie am Ende zum Aufholen von Rückständen einzusetzen.
Kurzfristiges Ausbauen von Features
Irgendwann kommt der Moment in dem auch der letzte sich die Situation nicht mehr schönreden kann und allen klar ist, dass zum Lieferzeitpunkt nicht alles fertig wird. Auch hier gibt es einen häufigen Reflex: alles was nicht Kernfunktion ist wird auf den letzten Metern wieder ausgebaut, selbst wenn das auf Kosten von Usability, Lastfähigkeit, einheitlicher Benutzererfahrung oder Systemstabilität geschieht und für gründliches Testen keine Zeit mehr da ist. Hauptsache irgendetwas wird fertig.
Ausliefern unvollständiger und fehlerhafter Ergebnisse
Man mag es nicht glauben, aber auch das geschieht immer wieder - Produkte die zum Teil noch unfertig sind gehen raus an den Benutzer. Der stellt dann die inzwischen sprichwörtlichen "Kinderkrankheiten" fest, die durch Hotfixes, Patches und Updates nach und nach behoben werden. Das bedeutet aber auch, dass die Überstunden und die halbgare Qualitätssicherung hinter den Kulissen weitergehen - mitsamt der damit verbundenen negativen Effekte.
---
Soweit die Problembeschreibung, wie so oft gefolgt von der Frage wie es besser gehen soll. Die wichtigste Antwort darauf: durch die Verabschiedung von der Illusion komplexe und neuartige Grossvorhaben im Voraus genau planen zu können. Jeder Versuch es doch zu tun wird in die hier beschriebene Dystopie führen. Stattdessen ist es nötig in kurzen, regelmässigen Abschnitten den Fortschritt zu überprüfen und alle Strukturen und Prozesse darauf zu optimieren, dass Änderungen schnell, einfach und ohne das Verschieben von Problemen in die Zukunft möglich sind. [Werbeblock für Agilität bitte hier einfügen]
