Donnerstag, 31. Januar 2019

Kommentierte Links (XLV)

FS
  • Henrik Bork: Toyota feuert die Roboter

    Diese Geschichte ist intensiv durch meine Timeline gegangen und wurde dort als Paradigmenwechsel wahrgenommen - ein Konzern verabschiedet sich von den Maschinen und vertraut wieder auf Menschen, da diese intelligenter, flexibler und präziser sind. Ich bin nicht sicher ob das richtig ist. Zum einen beruht das Toyota Production System schon immer grundlegend auf Autonomation, also darauf, dass Mensch und Maschine zusammenarbeiten. Zum anderen finden sich auch in der Vergangenheit zahlreiche Quellen die hervorheben, dass in dieser Firma menschliche Arbeiter Robotern vorgezogen werden, z.B. von 2017, 2014 oder 2011. Das bedeutet, dass Henrik Bork die Fertigungsstrategie von Toyota zwar richtig beschreibt, die Deutung als Paradigmenwechsel aber falsch ist - eher ist es seit langem gelebte Kontinuität.

  • Roger L. Martin: The High Price of Efficiency

  • Ein langer, langer Artikel, der auf eine zentrale Wahrheit eingeht: Effizienz ist nur dann etwas Gutes wenn sie in verträglichem Ausmass und sinnvollem Kontext stattfindet. Dort wo sie zum Fetisch überhöht wird treten früher oder später negative Folgen und Begleiterscheinungen auf. Monopole und Oligopole mit hoher Missbrauchsanfälligkeit entstehen, die so stark auf die bestehenden Bedingungen optimiert sind, dass selbst überschaubare Veränderungen zu existenziellen Krisen führen können. Roger Martin schlägt (unter anderem) eine interessante Lösung vor: einen wettbewerbsrechtlichen Rahmen der bewusst Friktionen einführt um Unternehmen dazu zu zwingen kleiner, beweglicher und anpassungsfähiger zu werden. Mit anderen Worten - agil.

  • Larry Larvik: 5 Reasons Why “Company Culture” is Overrated

    Bei dem Artikel bin ich zwiegespalten. Er adressiert zwar reale Probleme, die häufig auftreten und meistens als Teil einer erstrebenswerten Firmenkultur klein- oder schöngeredet werden. Diese Dinge sind allerdings weniger ein Teil tatsächlicher Firmenkulturen sondern eher von deren Perversion. Das was oft unter diesem Label vermarktet wird ist in erster Linie das Ergebnis der Bemühungen von gutmeinenden aber fehlgeleiteten HR- und Change Management-Abteilungen, die den restlichen Mitarbeitern ungefragt neue Verhaltensweisen überstülpen wollen. Denen die Deutungshoheit darüber zu überlassen was die Firmenkultur ist (und Gegenentwürfe dazu aufzubauen) geht am zentralen Punkt vorbei: die Firmenkultur ist das, was von der Mehrheit der Mitarbeiter täglich gelebt wird. Sie kann gar nicht "von oben" bestimmt werden.

  • Greg Satell: Don’t Teach Your Kid to Code. Teach Them to Communicate.

    Mit leicht anderer Schwerpunktsetzung entspricht das hier dem was Sascha Lobon schon 2017 geschrieben hat: die Fixierung auf das programmieren lernen in der Schule geht am Problem vorbei, da auf diese Weise versucht wird die Lösungen von heute auf die Herausforderungen von morgen zu übertragen, was zwangsläufig scheitern muss. Wesentlich wichtiger sind die Fähigkeiten des Erkennens bisher unbekannter Probleme und des Erlernens genereller Lern- und Anpassungsfähigkeit. Wenn irgendwann das Aneignen einer Programmiertechnik nötig sein wird, wird es mit diesen Fähigkeiten leichter fallen (und mit der heutigen Art zu Programmieren wird es ohnehin nicht mehr viel gemeinsam haben).

  • Yanna Vogiazou: Hacking the Design Sprint method to solve a complex problem

    Die Geschichte in Kürze: eine kalifornische Agentur hat die Design Sprints von Google übernommen und für die eigenen Zwecke angepasst. Die grössere Geschichte dahinter: Sprints gibt es nicht nur in Scrum. Jede Gruppe kann sie durchführen, egal ob in enger Folge, gelegentlich oder nur einmal. Auch dann wenn sie sonst nicht agil arbeitet, auch dann wenn ihre Mitglieder bisher noch nicht zusammengearbeitet haben oder später nicht mehr zusammenarbeiten werden. Vielleicht ist das einer der einfachsten Einstiege in die Agilität, einer der Vieles spürbar und erlebbar macht ohne bestehende Strukturen zu verändern. Wenn diese ersten Einzelsprints zu Erfolgen führen und Neugier auf mehr machen kann das ja noch kommen.

Montag, 28. Januar 2019

Minimum viable Team

FS
Bild: Pexels / Benji Mellish - CC0 1.0
Unbemerkt von den meisten Anwendern stecken in agilen Ansätzen wie Extreme Programming oder Scrum zwei Bestandteile der zumindest herausfordernd und in manchen Zusammenhängen sogar sich gegenseitig blockierend sind. Zum einen sollen die hier beschriebenen Produktentwicklungsteams crossfunktional sein, also alles selbst erstellen können was für eine Funktionserweiterung nötig ist, zum anderen soll ihre grösse unter zehn Mitgliedern liegen. Das beisst sich häufig.

Ein banales Beispiel macht das deutlich: in stark regulierten Branchen wie im Banken- oder Börsenbereich sind zahlreiche Gesetze und Vorschriften einzuhalten. Werden sie missachtet können Aufsichtsbehörden wie die Bafin oder die EZB Strafen verhängen oder sogar Produkte vom Markt nehmen. Es empfiehlt sich also, neue Produktinkremente von Juristen, Verbraucher- und Datenschützern freigeben zu lassen. Diese ins Team zu nehmen würde die Grössenbegrenzung sprengen, sie draussen zu lassen die Crossfunktionalität beeinträchtigen.

Wenn man dem Reflex wiedersteht die Teams einfach grösser zu machen bleibt nur eine Alternative: selten benötigte Aufgaben aus den Randbereichen des eigenen Tätigkeitsbereiches werden an Unterstützer- oder Spezialistenteams ausgelagert. Zurück bleibt eine Gruppe, die für die häufig durchgeführten Kerntätigkeiten verantwortlich ist, gewissermassen ein "Minimum viable Team". Die meisten agilen Teams gehören diesem Typ an, es stellt sich aber die Frage - welche Fähigkeiten sind in einer solchen Einheit unverzichtbar?

Ausgehend davon, dass die meisten agilen Teams Software produzieren ist die naheliegende Antwort die, dass es Software-Entwickler sein müssen. Mit den Worten von Extreme Programming-Begründer Ron Jeffries: "If you want a program, you can't get one without a programmer. All the designers and PMs and all those very important skills are stymied until someone can write the program." Mit anderen Worten: nahezu alles lässt sich in der IT von aussen zuliefern, nur die IT selbst nicht. Scheint offensichtlich - oder?

Wie so häufig gilt auch hier die Antwort: kommt drauf an. In den meisten Fällen liegt Jeffries zwar richtig, in einer frühen Phase der Produktentwicklung kann es aber sein, dass auch in einem Software-Kontext noch kein Entwickler nötig ist. Der initiale Tauglichkeits- oder Marktfähigkeitsbeweis ist oft noch ohne sie zu bewältigen. Ein scheinbarer Widerspruch, aber eben nur ein scheinbarer. Wie er aufzulösen ist kann man im lesenswerten Artikel "How to Build an MVP App Without Writing Code" erfahren.

Natürlich sind die hier genannten Beispiele der Bank-IT und der MVP-Apps Extremfälle, mit denen die meisten Teams nie zu tun haben werden. Der Punkt sind aber auch nicht diese beiden speziellen Konstellationen an sich. Wirklich wichtig ist die Frage die sie verdeutlichen: wenn ein Team nicht alles selbst erzeugen kann, was ist dann in keinem Fall verzichtbar? Sich diese Frage zu stellen (und das mit wirklicher Unvoreingenommenheit und Ergebnisoffenheit) ist das was zu einem wirklichen Minimum viable Team führen kann.

Donnerstag, 24. Januar 2019

Definition of Ready

FS
Bild: Pixabay / DCG:MAK - CC0 1.0
Scrum wird in Workshops häufig als Schleife (Loop) visualisiert, mit den Rollen in der Mitte, den Meetings und Artefakten am Rand und jeweils einem Quality Gate am Anfang und am Ende. Das am Ende ist hier bereits thematisiert worden, die Definition of Done (DoD), was noch fehlt ist das Gate am Anfang, die so genannte Definition of Ready (DoR).

Unter ihr versteht man üblicherweise eine Liste von Kriterien die erfüllt sein müssen bevor eine Anforderung zur Umsetzung in einen Sprint übernommen wird. Häufig anzutreffen sind z.B. "Alle Teammitglieder müssen die Anforderung verstanden haben", "Es müssen validierbare Akzeptanzkriterien formuliert sein" oder "Die Umsetzung dieser Anforderung muss einen erkennbaren Mehrwert erzeugen".

Der Hintergrund der DoR ist schnell erkennbar. Mit ihr lässt sich verhindern, dass unklare, nicht testbare oder betriebswirtschaftlich unsinnige Ideen in die Umsetzung geraten. Die in diesen Fällen unausweichlichen (und oft unschönen) Diskussionen können so unterbunden werden noch bevor es einen Anlass für sie gibt. Das Team kann sich stattdessen auf seine eigentliche, wertschöpfende Arbeit konzentrieren.

Für viele überraschend: trotz dieser Vorzüge ist die Definition of Ready kein offizieller Teil von Scrum sondern gehört zu den vielen good Practices, die man zwar befolgen, genau so gut aber auch weglassen kann. Da sie weit verbreitet ist kann das nicht an fehlender Bekanntheit liegen sondern ist von Schwaber und Sutherland bewusst beabsichtigt worden. Warum das?

Das mit der DoR verbundene Risiko ist, dass Teams sich dadurch versehentlich Wasserfall-artige Strukturen aufbauen können. Ein zu restriktives Beharren auf von allen Teammitgliedern verstandene Anforderungen wird zwangsläufig einen solchen Beschreibungsumfang zur Folge haben, dass wieder eine vorgelagerte Konzeptionsphase entsteht in der Detailspezifikationen erzeugt werden. Das wäre nicht mehr im ursprünglichen Sinn der Agilität.

Darüber hinaus ist eine zu detaillierte Definition of Ready ein Indikator für gleich zwei Antipattern: für unzureichende Backlog Refinements und für ein Misstrauen eines Entwicklungsteams gegenüber seinem Product Owner. Würden zur Umsetzung vorgesehene Anforderungen ausreichend besprochen (nicht beschrieben!) und würde das Team darauf vertrauen, vom PO nur umsetzbare Aufgaben zu erhalten - ein zusätzliches Quality Gate wäre unnötig.

Eine DoR ist aus diesen Gründen ein zweischneidiges Schwert. Sie kann unerfahrenen Teams bei der Umsetzung von Scrum helfen, kann aber auch versehentlich dazu führen, dass die Methodik sich selber aushebelt. Von vielen Teams wird sie daher gar nicht erst eingeführt oder irgendwann wieder abgeschafft.

Montag, 21. Januar 2019

Agile Governance (II)

FS
Zum Thema Agile Governance habe ich bereits vor einigen Jahren etwas geschrieben, aber Dan North geht mit einem weitaus grösseren Detailgrad darauf ein. Vieles davon ist "agiler common sense", aber es ist immer wieder interessant alles im Kontext zu sehen. Und die Automatisierungs-Beispiele am Ende können sogar als Vorbild genutzt werden.

Donnerstag, 17. Januar 2019

Stalemate-Machine

FS
Bild: Wikimedia Commons / US Army - CC0 1.0
Sucht man nach beispielhaften fehlgeschlagenen Grossvorhaben ist eines zwar nicht auf den ersten Blick naheliegend, in vieler Hinsicht aber gut geeignet: der verlorene Krieg der USA in Vietnam. Was nötig gewesen wäre um ihn zu gewinnen wird zwar für immer Spekulation bleiben, viele Faktoren die dazu beigetragen haben, dass er verloren wurde, kennt man aber. Um einen davon soll es hier gehen, die so genannte "Stalemate-Machine", sinngemäss übersetzt den "Stillstands-Generator".

Der Hintergrund dieses Phänomens war der steigende Unwille in der amerikanischen Bevölkerung und Regierung in diesen Krieg zu investieren. Aus Sorge um ihre Wiederwahl wollten die Regierungen der 60er und 70er Jahre nicht mit immer höheren Kosten an Leben und Geld in Verbindung gebracht werden. Ihr Ziel war es also diese Kosten möglichst gering zu halten. Die Kriegsführung wurde entsprechend angepasst.

So lange es irgendwie möglich war wurde die Beteiligung amerikanischer Einheiten gering gehalten, Auseinandersetzungen sollten in erster Linie von einheimischen Truppen ausgetragen werden. Erst wenn diese am Rand der Niederlage standen erfolgte ein Eingreifen der Amerikaner. Sobald die Situation dadurch wieder unter Kontrolle war zogen sie sich zurück, was ihren Gegnern die Neugruppierung ermöglichte.

Der Militär-Analyst und Whistleblower Daniel Ellsberg hat für diese Strategie den Begriff der Stalemate-Machine geprägt. Wegen der Möglichkeit bei drohenden Niederlagen einzugreifen konnte der Krieg nicht verloren werden, wegen der fehlenden Bereitschaft ohne drohende Niederlage grössere Operationen durchzuführen war er aber auch nicht zu gewinnen. Die Folge war ein "stillstehender Krieg" ohne Gewinner.

Die Parallelen zur Wirtschaft sind in vielen Unternehmen offensichtlich. Auch hier wird häufig der Punkt erreicht an dem ein Projekt oder Vorhaben so viel gekostet hat, dass weitere Ausgaben in Management-Runden nur schwer zu vermitteln sind. Es bekommt von da an nur noch überschaubare Beträge genehmigt, damit es aus den Bilanzen weniger heraussticht. Bedingt dadurch gerät es weiter in Verzug, was nur noch bei wichtigen Deadlines zu kurzfristigen Hau-Ruck-Aktionen führt, die schnell wieder vorbei sind.

Der grosse Vorteil im Vergleich zum Militär ist an dieser Stelle: man könnte ohne ethische Bedenken diesen Krisenmodus verlassen und eine angemessen moderate, dafür aber permanente Finanzierung sichern. Man müsste nur wollen. Noch besser wäre es, es gar nicht so weit kommen zu lassen und von Beginn an massvoll aber stetig zu investieren. Damit würde es gar nicht erst zum Stalemate kommen.

Montag, 14. Januar 2019

Backlog Konmari

FS
Bild: Pixabay / 123nurik123 - CC0 1.0
Wegen irgendeiner Fernsehsendung hört man gerade viel von einer Japanerin mit dem (Künstler?)Namen Marie Kondo. Bekannt geworden ist sie durch die von ihr entwickelte Konmari-Methode zum Aufräumen von Wohnungen und Garderoben, die mittlerweile aber auch für Büros, Werkstätten, Schreibtische, etc. angewandt wird. Das Ganze lässt sich aber noch weiter treiben - warum sollte man Konmari nicht auch für Product Backlogs anwenden? Auch die sind ja oft hoffnungslos überladen und zugemüllt.

Als ersten Schritt definiert Kono das Commitment. Dieses geht bei ihr über die engere Bedeutung des sich verpflichtet Fühlens hinaus und enthält auch einen Zeitplan. Es sollte ein Zieldatum geben bis zu dem die Aufräumarbeiten abgeschlossen sein müssen, es sollte Zwischenziele geben und es sollte einen oder mehrere Zeiträume geben die für diese Arbeit reserviert sind, z.B. jeden Werktag von 10 bis 11 bis zum Ende des Monats.

Als nächstes sollte Klarheit über das angestrebte Zielbild herrschen. Dazu sollte dieses in seinem Idealzustand beschrieben werden. Für ein Backlog bedeutet das: geordnet (z.B. nach Business Value, MVPs, Sprintzielen, oder Roadmap) und mit einer absteigend geringer werdenden Granularität. Basierend darauf lassen sich die Einträge später neuordnen, teilen oder zusammenlegen.

Das eigentliche Aufräumen beginnt dann mit dem Ausmisten. Orientiert am vorher verfassten Zielbild kann alles weg was nicht dazu passt. Für viele Teams dürfte das der schwerste Teil dieser Übung sein, gleichzeitig ist es auch der wichtigste. Ist die Gesamtmenge übersichtlicher geworden fällt das Sortieren leichter und geht schneller voran. Eine weitere Hilfe besteht darin, sich um Nostalgie und Emotionen weckende Anforderungen als letztes zu kümmern, um nicht abgelenkt zu werden.

Auch bei der Aufteilung der Arbeitsschritte empfiehlt Konmari ein anderes Vorgehen als das meistens anzutreffende. Statt sich von einem Ort zum nächsten vorzuarbeiten entsprechen die Arbeitsphasen verschiedenen Kategorien. Bezogen auf das Produktmanagement bedeutet das, dass nicht zuerst Jira, dann Salesforce und dann  HP-ALM abgearbeitet werden sondern z.B. erst toolübergreifend alle Innovationsvorhaben, dann die Servicetasks und dann die Bug-Tickets.

Während des Aufräumens sollte Ordnung unmittelbar entstehen. Statt neue Haufen zu bilden, die dann (hoffentlich) später sortiert werden sollte alles sofort an den (nach aktuellem Kenntnisstand) finalen Ort wandern. Um Agile-Buzzwords zu benutzen: jedes Aufräum-Incement sollte eine Definition of Done erfüllen und unmittelbaren Mehrwert stiften.

Über dem gesamten Prozess sollte im klassischen Konmari das Leitmotiv des Erzeugens von "Sparking Joy" stehen, also des Verstrahlens von Freude. Als Gegenstück im Produktmanagement würde sich das weit verbreitete "Delighting Customers" anbieten. Im Hinterkopf sollte demnach während des ganzen Aufräumvorganges stehen, dass das Endergebnis den höchstmöglichen Kundennutzen zum Ziel haben sollte.

In diesem Sinne - ab zum Aufräumen.


Nachtrag 04.02.:

Donnerstag, 10. Januar 2019

Keine Entschuldigungen im Review

FS
Bild: Pixabay / Geralt - CC0 1.0
Egal ob im Sprint Review, in einem Stakeholder-Meeting oder bei einer wie auch immer gearteten Ergebnispräsentation - jedes agil arbeitende Team sollte in regelmässigen Abständen seinen Kunden, Sponsoren und Auftraggebern Ergebnisse zeigen. Bestenfalls sollten in diesem oder in einem anderen Rahmen auch Zieldaten und Forecasts kommuniziert werden, um Umsatzplanungen, Kommunikationsstrategien und ähnliches möglich zu machen. Und da der Mensch als solcher nun mal fehlbar und die Realität nicht vorhersehbar ist werden nicht immer alle Ergebnisse zum angedachten Zeitpunkt fertig sein. Was jetzt?

Ein häufiges Verhalten vieler Teams ist es, in solchen Situationen umfangreiche Erklärungen und Begründungen abzugeben. Mitunter in erstaunlichem Detaillierungsgrad wird dargelegt warum man sich in den Aufwandsschätzungen vertan hat, wie es dazu kommen konnte, dass die Planungen zu optimistisch waren oder welche Faktoren dazu geführt haben, dass das ursprünglich realistische Ziel wider Erwarten doch nicht erreicht werden konnte.

Verbunden damit ist in der Regel guter Willen. Transparenz ist bekanntlich einer der Grundprinzipien agilen Arbeitens, es ist also scheinbar nur folgerichtig sie auch in diesem Fall anzuwenden und für jeden nachvollziehbar zu machen warum alles so gekommen ist wie es ist. Zielführend ist dieses Vorgehen allerdings nur selten. Häufiger führt es zu Befremdung und Skepsis bei den Zuhörern, also zum Gegenteil des eigentlich erhofften Ergebnisses.

Zunächst wirken Erklärungen und Begründungen schnell wie Ausreden und Fingerpointing, und zwar auch dann wenn sie explizit nicht so gemeint sind. "Wir wollten ja, aber ..." hinterlässt selten einen guten Eindruck, erst recht nicht wenn es mehrfach geschieht. Und dass es immer wieder geschehen wird ist unvermeidbar, siehe menschliche Fehlbarkeit und Unvorhersehbarkeit der Realität. Besser sind Aussagen wie "Wir sind nicht ganz fertig geworden, arbeiten aber weiter daran." oder "Dieser Lösungs-Ansatz war leider der falsche, basierend auf dem was wir daraus gelernt haben arbeiten wir jetzt an einem besseren."

Des Weiteren sind derartige Themen für die meisten Kunden, Sponsoren und Auftraggeber schlicht uninteressant. Negative (und übrigens auch positive) Implementierungsdetails sind nicht der Grund dafür, dass man sich mit einem Umsetzungsteam trifft. Normalerweise kommen die Teilnehmer solcher Veranstaltungen weil sie Ergebnisse sehen, ausprobieren und Feedback geben wollen und nicht um zu hören wo es Probleme gab die sie weder beurteilen noch beheben können.

Zuletzt fressen Erklärungen und Begründungen Zeit weg die deutlich besser und gewinnbringender genutzt werden könnte. Jede Nacherzählung unerwarteter Hindernisse könnte ersetzt werden durch Hands on-Demonstrationen, Zufriedenheitsmessungen, Verbesserungsvorschläge oder die Vorstellung und Abstimmung von nächsten Schritten. Gerade vor dem Hintergrund, dass in agilen Teams Meetings meistens timeboxed sind ein nicht zu unterschätzender Faktor.

Das Alles heisst übrigens nicht, dass Fragen nach den nicht gelieferten Ergebnissen nicht beantwortet werden sollen. Das sollten sie auf jeden Fall. Aber nur dann wenn sie gestellt werden und ohne zu viele Details. Die will niemand hören.

Montag, 7. Januar 2019

Process, Tribe and Comfort Zone

FS
Ich bin nicht sicher ob Emily Phillips hier wirklich über Agile Leadership spricht oder nicht doch eher darüber wie sie mit den Unwägbarkeiten des eigenen Lebens umgeht. Interessant ist es aber so oder so.

Donnerstag, 3. Januar 2019

Investitionsstaus

FS
Bild: Wikimedia Commons / Caliva - CC BY-SA 4.0
Es war eine der letzten Meldungen des Jahres: im Jahr 2018 wurden Investitionsmittel von insgesamt 25 Milliarden Euro nicht abgerufen. Wohlgemerkt, es handelte sich dabei um bereits freigegebene Summen, es gab nichts mehr zu beantragen und genehmigen, man hätte direkt mit dem Ausgeben anfangen können. Dass das nicht geschehen ist ist keine Besonderheit der staatlichen Verwaltung, auch in vielen grossen Firmen gibt es dieses Phänomen - und es hat Gründe.

Am Anfang steht wie so oft das Dilemma, dass die Zukunft nicht vorhersehbar ist und die Realität sich anders entwickelt als geplant. Im besten Fall führt das dazu, dass Vorhaben schneller (und damit billiger) umgesetzt werden können als vorgesehen. Das gibt es, es ist aber selten. Häufiger ist das absolute Gegenteil: weil die Planung an der Realität vorbeiging muss neu geplant werden, die Umsetzung beginnt dann deutlich später oder muss sogar ins nächste Jahr verschoben werden.1

Beide Fälle führen dazu, dass in den jeweiligen Organisationen Stillstand einkehrt. Denn um neue Vorhaben zu beginnen müssten diese eine genehmigte Finanzierung für das laufende Jahr haben, was aber bei grösseren Summen einen monatelangen bürokratischen Prozess erfordern kann. Bis dieser abgeschlossen ist kann mit der Arbeit nicht begonnen werden, und wenn er bis Jahresende nicht beendet wurde bleibt das Geld ungenutzt. Stattdessen das bereits freigegebene Budget derjenigen Vorhaben zu nehmen die nicht starten konnten geht auch nicht - derartige Mittel sind in der Regel zweckgebunden.

Letztendlich können derartige Zustände mehrfach schädlich sein. Zum Einen sorgen sie dafür, dass sich Arbeiten unnötig verzögern (→ Cost of Delay), des Weiteren wurden ggf. bereits Lizenzen oder Geräte gekauft, können aber nicht benutzt werden, wodurch sie zwar Geld kosten aber keines erwirtschaften (→ Totes Kapital), schlimmstenfalls führt der Versuch das vorhandene Geld irgendwie doch einzusetzen zu unnötigen Erweiterungen bereits fertiger Ergebnisse, wodurch diese unübersichtlicher, instabiler und wartungsintensiver werden (→ Bloatware/Feature Creep).

Alles das ist für alle Beteiligten relativ klar zu erkennen sobald es einmal eingetreten ist, es wird also versucht Gegenmassnahmen zu ergreifen. Der in vielen Fällen eingeschlagene Lösungsweg macht aber alles nur noch schlimmer: er besteht daraus, strukturell mehr Vorhaben zu beantragen und genehmigen zu lassen als durchgeführt werden können. Stellt sich jetzt eines als nicht durchführbar heraus kann man einfach das nächste beginnen, man ist also in jedem Fall ausgelastet. Problem gelöst?

Auch hier tritt wieder das Problem der nicht vorhersehbaren Zukunft auf: wenn wider Erwarten alle Vorhaben wie geplant begonnen und durchgeführt werden können, dann ist es nicht mehr möglich diejenigen umzusetzen die "auf Vorrat" beantragt worden sind. Für sie wird also eine fehlende Machbarkeit gemeldet, wodurch ihr Budget wieder zur allgemeinen Verfügung steht. Abgerufen werden kann es wegen der genannten bürokratischer Prozesse dann nicht mehr rechtzeitig. Siehe oben.

Das Bemerkenswerte ist, dass es auch andere Lösungen gäbe, durch die Inverstitionsstaus vermieden werden könnten: man könnte Genehmigungsprozesse beschleunigen, die Zweckbindung von Finanzierungen aufheben oder die Organisation vom Push- auf das Pull-Prinzip umstellen. Jede dieser Optionen würde aber tiefgreifende Änderungen der Organisations- und Genehmigungsstrukturen erfordern, wovor dann doch zurückgeschreckt wird. Und dann bleibt es dabei, dass immer wieder Geld nicht abgerufen wird.

Nachtrag:
Um auf Feedback zu reagieren: ja, in diesem Beitrag geht es hautptsächlich darum was falsch läuft und nur wenig darum wie es besser gehen würde. Das hat seinen Grund darin, dass das besser Machen aus einer Umstellung, bzw. einem Rückbau bestehender Organisationsformen bestehen muss. Da die aber von Fall zu Fall unterschiedlich sind ist es kaum möglich eine generelle Handlungsempfehlung abzugeben. Wie so oft: es kommt darauf an.

Nachtrag II:
Passend zum Thema geht es in einer der ersten Meldungen des Jahres weiter: Investitionsstau in Städten und Kommunen erreicht Rekordniveau.


1Natürlich gibt es auch die Fälle in denen die Umsetzung zum geplanten Zeitpunkt beginnt und endet oder in denen sie
zum geplanten Zeitpunkt beginnt und verspätet endet, aber die sind in diesem Zusammenhang nicht von Bedeutung
Powered by Blogger.