Dezentraler Iterationsprozess statt "ein Vorgehensmodell"

So vielfältig wie die ungelösten gesellschaftlichen Probleme sind, so vielfältig sind die potentiellen Lösungsansätze. Open Government muss dazu ermutigen und befähigen, Problemlösungen zu entwickeln und zu erproben; dezentral, offen, transparent.

Machen statt modellieren!

OpenGov erfordert Mut und einen Kulturwandel - keine weiteren Vorgehensmodelle. Diese Konsultation war doch wohl auch kein "Hexenwerk" - oder?

Zuständigkeiten ergänzen

Jeder Akteur sollte die Zuständigkeiten der anderen kennen - und auch seine eigene. Die Zuständigkeit sollte sich aus der Kompetenz ableiten.

Taten statt Vorgehensmodell

Es scheint als müsse gerade die deutsche Regierung und Verwaltung "Open Government" neu erfinden und in einem DIN-Standart definieren. Das ist falsch und führt nicht zum Ziel. Ich wünsche mir mehr Mut zum Experiment. Wir brauchen keine Modelle für Offenheit, Transparenz und Beteiligung sondern politischen Willen diese in der Praxis umzusetzen. Keep it simple.

Overengineering birgt die Gefahr der Bürokratisierung von Bürgerbeteiligung - das lähmt Kreativität und Offenheit

Die Vorgabe genau beschriebener Vorgehensmodelle klingt sehr deutsch und sehr bürokratisch und sehr wenig nach Offenheit und nach Betaphase. Aber Internet ist Beta und Open Government wird auch mit Beta arbeiten müssen. Perfektion gibt es nicht, aber lernende Systeme. Wenn wir aber Prozessböxchen malen für Open Government, dann kann es sein, dass wir damit die Kreativität killen bevor sie sich entwickeln konnte. Preussische Herangehensweisen passen einfach nicht zur neuen Open Government Kultur.

Überzeugende Lösungen

Schon zu Beginn „überzeugende Lösungen“ anzubieten wäre übertrieben für den Beginn. Ablauf, Methoden, Gestaltung, Schritte und Ziele sollen während der Entwicklung geprüft und gegebenenfalls angepasst werden. Nur durch diesen Kreislauf kann auf Dauer ein Lerneffekt eintreten.

Vorghensmodell oder doch eGovernment reloaded?

Ein starres Vorghensmodell zu entwickeln oder pauschal vorzugeben scheint kaum möglich oder sinnvoll - dennoch birgt xtreme-vorgehen bzw. ausschließliches Drauf-Verlassen, dass die "crowd" schon eine gute Idee haben wird, auch das Risiko, eine weitere Wüste mit 1001 online gestellten Services bzw. Datenangeboten zu haben, die keinen interessiert. Ist auch in seinem Fokus auf die technische Bereitstellung aus meiner Sicht zu einseitig. Dadurch werden die möglichen Vorteile, die sich im Sinne von Kooperationspotenzial, Prozessverbesserung, backoffice-Reorganisation etc. ergeben, eher nicht erkannt und genutzt.
Flexible Konzepte wie Pattern-Ansätze können aus meiner Sicht geeignete Hilfestellung geben, um Organisation und Technik im Kontext zu sehen, aber gleichzeitig nicht zu starr zu werden, dass man lieber gar nicht erst anfängt.

Programmsätze helfen leider nichts

Sorry, aber hier beginnen jetzt Programmsätze (um nicht Worthülsen zu sagen), die auf vielfältigste Vorhaben anzuwenden wären. Ein Eckpunktepapier sollte dagegen eben die Eckpunkte setzen. Ich wünsche (mir von) den Akteuren daher mehr Mut beim Formulieren.

Niemand kennt die Lösung

Der oben stehende Satz hört sich so an, als wäre die Lösungsidee für das Problem schon klar und wir müssten deren Umsetzung nur per Wasserfallmodell erarbeiten.

Dem ist aber nicht so. Kein Mensch und auch keine Agentur weiss im Moment, wie Open Government aussieht. Wir wissen nur, es gibt ein Problem, aber so richtig analysiert ist ja nichtmal das (was genau ist denn "Politikverdrossenheit"?)

Daher müssen wir viel ausprobieren. Wir brauchen also einen Prozess, bei dem man klein beginnt, wo man auch viel ausprobiert und durch eine Community viel ausprobieren lässt. Die Ergebnisse müssen dann analysiert und dann die Projekte verbessert werden. Und dann geht es wieder von vorne los. Wir brauchen also einen langwierigen Prozess, der auch Fehlschläge zulässt. Ich würde vermuten, dass dieser Prozess über Jahre andauern wird, da wir ja nicht nur ein technisches Problem, sondern auch (oder vor allem) ein kulturelles Problem zu lösen haben.

Insgesamt aber bitte keine Phase und Methoden vorgeben, sondern nur einen Iterationszyklus definieren und vor allem die Reflektion in den Mittelpunkt stellen. Da das ja alles auch bundesweit geschehen soll, wäre hier wahrscheinlich auch eher die Koordination das Problem bzw. die Dokumentation/Kommunikation, wenn man davon ausgeht, dass regionale Stakeholder auch ruhig selbständig was ausprobieren dürfen sollen.

Lösungen/Vorgehensmodell

Zwei Anmerkungen:
1. Es gibt Vorgehensmodelle wie Sand am Meer, jede öffentliche Verwaltung hat für ihre Projetvorhaben mindestens eines, (Prince 2, V-Modell .....) Es wird nicht klar, ob bestehende Vorgehensmodelle weiterentwickelt adaptiert oder customized werden sollen oder müssen, oder ob angesterbt wird, ein ganz neues solches zu entwickeln.
2. Bei O.G. geht es ja um Teilhabe, das Wort "Lösungen" klingt hier so, als ob hier etwas fix-fertiges Erzeugnis aus dem Regal genommen und den staunenden Akteuren vorgesetzt wird.
Ich bitte um Überarbeitung

Wir brauchen keine Lösungen

Wir brauchen jetzt keine Lösungen sondern nur die Offenbarung der Daten. Das ist etwas was sehr einfach und billig realisierbar ist und danach können wir immer noch sehen welche Lösungen noch gebraucht werden.

Vorgehensmodell

Ist das Vorgehensmodell immer anzuwenden? Gerade bei der Entwicklung von kleineren Lösungen sollte hier aufgepasst werden, dass nicht mit Kanonen auf Spatzen geschossen wird (ähnlich V-Modell XT, welches für kleine Projekte zu mächtig ist und somit deren Durchführung im schlimmsten Fall behindert). Das Vorgehensmodell sollte somit flexibel anpassbar sein.

Fahrplan vs. Vorgehensmodell

was ist der Unterschied zwischen dem Fahrplan (ein bullet weiter oben) und dem Vorgehensmodell? Die Diskussion um agile Politikgestaltung ist interessant (scrum, extreme programming, etc), wobei nicht klar ist, ob das wirklich auf dieses Thema übertragbar ist. Zielgruppe sind ja Entscheider auf der politischen Ebene in Verwaltung und Politik.

Eher-nicht-dito zu den Xtreme Beiträgen davor

Da eine Verwaltung aus weniger Leuten besteht als sie zu verwalten hat und es bestehende Prozesse gibt ist ein reines Verfahren nach Xtreme Programmieren nicht ganz passend. Es sollte schon weitere Verfahren dabei sein (scrum? Experten als Mediator, Aufteilung in gröbere Arbeitsaufgaben und dessen Unterteilung in Tasks durch die Verwaltung selbst - sie muss dass auch stämmen können)

Dito „Xtreme Verwaltung“

Genau: nicht zu viel schreiben, mehr machen.

100% Zustimmung zum Kommentar "Xtreme Verwaltung"

Die Vorstellung einen solchen Prozess von vorne bis hinten durchplanen zu können und dann zu starten ist anachronistisch und nicht nur in der Softwareentwicklung gescheitert. Diese Erfahrung wurde auch in der öffentlichen Verwaltung hinreichend gemacht. Realität sind Prozesse, dazu gehört auch, dass sich Ziele, angemessene Methoden und Werkzeuge im Laufe der Entwicklung und mit wachsender Erfahrung naturgemäß ändern. Benötigt wird ein agiles Vorgehen, das nach einer initialen Konzeptphase rasch mit Prototypisierung und Experimentieren im besten Sinne beginnt. Ein klassisches, detailliertes Vorgehensmodell ist verbranntes (Steuer)-Geld.

Xtreme Verwalting

Vorgehensmodelle dienen nur der internen Absicherung, am besten ist es loszulegen, und was auszuprobieren, ein Teil der Ansätze wird scheitern, und das ist auch richtig so. Die guten Ansätze werden refaktoriert. Niemand soll dem lieben Herrgott den Tag stehlen mit Vorgehensmodellen. Statt Modellen zum Vorgehen, brauchen wir Fort-Schritt. Viel ausprobieren, viel wegschmeissen, Erfahrungen sammeln.