Zu viele Baustellen, zu wenig Leute: Wie eine kleine kommunale IT sinnvoll priorisiert
Wenn Security, Lifecycle, Fachverfahren, Support und neue Projekte gleichzeitig drängen, braucht es keine weitere Wunschliste, sondern eine einfache Reihenfolge nach Risiko, Wirkung und Betriebsfähigkeit.
Praxisnotiz · von Christian Hoberg · veröffentlicht 23.09.2026 · 9 Min. Lesezeit
PriorisierungKommunal-ITBetriebRoadmap
FrageWas zuerst angehen, wenn gefühlt alles gleichzeitig wichtig ist?
ProblemTagesgeschäft, Altlasten und Projekte konkurrieren um dieselben wenigen Personen. Lautstärke gewinnt dann schnell gegen tatsächliches Betriebsrisiko.
Erster SchrittAlle offenen Vorhaben in einer 90-Minuten-Runde nach Ausfallwirkung, Sicherheitsrisiko, gesetztem Termin und realer Teamkapazität sortieren.
ZielDrei bis fünf belastbare Vorhaben für die nächsten 90 Tage statt einer unendlichen Maßnahmenliste.
Nicht nach Lautstärke priorisieren
In kleinen IT-Teams kommt die nächste Priorität oft aus dem lautesten Ticket, dem nächsten Audit oder einer neuen Produktidee. Das ist verständlich, erzeugt aber eine Roadmap aus Unterbrechungen. Besser ist eine feste Sicht auf Ausfallwirkung, Sicherheitsrisiko, Lifecycle-Druck und den tatsächlichen Aufwand für Einführung und Betrieb.
Kritische Betriebsrisiken zuerst sichtbar machen
Feste externe Termine getrennt kennzeichnen
Nice-to-have-Projekte nicht mit Pflichtmaßnahmen vermischen
Betriebsfähigkeit ist ein Auswahlkriterium
Ein technisch gutes Vorhaben kann zur falschen Zeit trotzdem die falsche Entscheidung sein. Wenn niemand Patchen, Monitoring, Backup, Berechtigungen und Störungen übernehmen kann, entsteht aus einem Projekt schnell die nächste technische Schuld.
Owner vor Projektstart benennen
Betriebsaufwand nach dem Go-live mitbewerten
Abhängigkeiten zu Identität, Netzwerk, Backup und Support notieren
90 Tage statt Drei-Jahres-Wunschliste
Für die operative Steuerung reichen wenige konkrete Vorhaben pro Quartal. Eine längere strategische Liste darf bestehen, aber nur die nächsten drei bis fünf Themen bekommen einen echten Owner, einen Scope und ein überprüfbares Ergebnis.
Ein Risiko reduzieren
Einen wiederkehrenden Aufwand beseitigen
Einen kritischen Service messbar stabiler machen
Woran eine gute Priorisierung erkennbar ist
Die Reihenfolge muss auch dann nachvollziehbar bleiben, wenn ein anderes Produkt bevorzugt wird oder ein Projekt verschoben werden muss. Entscheidend ist nicht die perfekte Punktzahl, sondern dass Team und Leitung erklären können, warum genau diese wenigen Vorhaben jetzt dran sind.
In vier Wochen entsteht kein perfektes CMDB-Projekt, aber eine belastbare Sicht auf kritische Services, Systeme, Owner, Abhängigkeiten, Backup/Restore, Monitoring und die wichtigsten offenen Risiken.
Statt noch mehr Hostchecks aufzubauen, werden zehn wichtige Verwaltungsservices mit Abhängigkeiten, Nutzerwirkung, Alarmweg und einem echten Fehlerfall als End-to-End-Monitoring modelliert.
Nicht jede alte Plattform ist automatisch ein Notfall. Kritisch wird technische Schuld dort, wo Wissen, Wiederherstellung, Support oder sichere Änderungen nicht mehr belastbar funktionieren.
Backups allein machen eine Kommune noch nicht handlungsfähig. Entscheidend ist, welche Verwaltungsleistungen zuerst zurückkommen, wie Teams ohne Standard-IT kommunizieren und wer den Wiederanlauf steuert.