Die Warteschlange vor dem eigenen Team: 346 Belege, die niemand vermisst hat

Die Warteschlange vor dem eigenen Team ist der teuerste Posten, den keine Kostenstelle ausweist. Eine Aufgabe gilt nicht als gestrichen, sie rückt nur nach hinten, und niemand bucht den Unterschied. Wir schreiben auf, woran wir diesen Aufschub in laufenden Projekten gemessen haben und was danach anders lief.

Was in der Warteschlange vor dem eigenen Team liegen bleibt

Das Bild ist in mittelständischen Unternehmen fast überall dasselbe. Vier bis acht Entwickler halten ein System am Laufen, das den Betrieb trägt. Der Releasekalender ist voll mit Pflichten: Gesetzesänderungen, zugesagte Erweiterungen, Fehler aus dem Support, die Ablösung einer Bibliothek, die niemand mehr pflegt. Alles davon ist begründet, vieles davon ist dringend. Genau deshalb entsteht hinter diesen Pflichten eine zweite Liste.

Auf dieser zweiten Liste stehen erfahrungsgemäß dieselben drei Sorten von Vorhaben: die Anbindung an ein Fremdsystem, ein Zugang für Leute, die nicht am Schreibtisch arbeiten, und eine Auswertung, die heute jemand von Hand zusammenstellt. Keines davon legt den Betrieb still, wenn es fehlt. Deswegen verliert es jede Priorisierung, und zwar nicht einmal, sondern in jeder Runde erneut. Abgelehnt wird es nie.

Der entscheidende Punkt ist, dass ein verschobenes Vorhaben nicht kostenneutral wartet. Solange es wartet, läuft die Umgehung weiter, die es ersetzen sollte: die Tabelle, der händische Export, der Anruf ins Lager. Diese Umgehung kostet jeden Monat Arbeitszeit und produziert jeden Monat Abweichungen. Beides steht in keinem Budget, weil beides schon immer da war und niemand es als Projekt führt.

346 Belege, die im manuellen Export fehlten

Wie groß dieser Posten wird, lässt sich vorher selten schätzen, hinterher aber manchmal nachrechnen. In einem Projekt mit einem Lebensmittelhersteller haben wir die Anbindung an das staatliche E-Rechnungssystem gebaut – ein Vorhaben, das jahrelang auf der zweiten Liste stand. Bis dahin zog die Buchhaltung monatlich einen Export aus ihrer Software. Das funktionierte, und niemand beschwerte sich.

Nach der Anbindung stand die Zahl fest: 3 048 Rechnungen aus dem staatlichen E-Rechnungssystem geholt (Stand 09/2026); beim ersten Abgleich der nachgeholten 2 408 Belege fehlten 346 im manuellen Export. Diese 346 Belege waren nicht falsch verbucht, sie waren im Haus überhaupt nicht vorhanden. Jeder Monat, in dem die Aufgabe gewartet hat, hat seinen Anteil an dieser Zahl beigetragen – rückwirkend feststellbar, vorher unsichtbar.

Hier liegt die ehrliche Grenze dieses Beitrags. Wir konnten diesen Posten vorher nicht beziffern, und in Ihrem Haus könnten wir es ebenso wenig: Vor der Anbindung gab es keine zweite Quelle, gegen die sich der Bestand hätte prüfen lassen. Wer die Kosten eines Rückstaus im Voraus nennt, nennt eine Annahme. Möglich ist vorher nur der kleinere Schritt – eine Stichprobe gegen ein Fremdsystem ziehen und nachsehen, ob die Differenz null ist. In diesem Fall war sie es nicht.

Drei Kostenarten, die der Aufschub erzeugt

Aus Projekten, in denen wir liegengebliebene Vorhaben übernommen haben, lassen sich drei wiederkehrende Posten benennen. Keiner davon taucht in einer Kalkulation auf, solange die Aufgabe wartet.

• Nacharbeit, die mitwächst. Fehlende oder unsaubere Daten sammeln sich weiter an, solange die Umgehung läuft. Wer später anbindet, bindet nicht nur an, sondern räumt auch die Vergangenheit auf. Das ist ein zweites Vorhaben im ersten, und es steht in keiner Schätzung.
• Umgehungen, die sich verfestigen. Eine Tabelle, die zwei Jahre lang gepflegt wird, ist irgendwann eine zweite Wahrheit mit eigenen Regeln. Sie abzulösen heißt dann auch, diese Regeln zu rekonstruieren, denn aufgeschrieben hat sie niemand.
• Ein Ziel, das sich bewegt. Der Kern des Systems bleibt nicht stehen. Eine Schnittstelle, die vor einem Jahr zwei Tabellen berührt hätte, berührt heute fünf. Der Aufwand wächst mit dem Aufschub, nicht mit dem Umfang der ursprünglichen Idee.

Die naheliegende Antwort lautet, das eigene Team zu vergrößern. Sie ist nicht falsch, sie löst den Rückstau nur nicht in der Gegenwart: Die Suche nach einem erfahrenen Entwickler zieht sich über ein halbes Jahr, und danach folgt die Einarbeitung in ein gewachsenes System, das kein Lebenslauf abbildet. Bis dahin läuft die zweite Liste unverändert mit.

Warteschlange vor dem eigenen Team: wie wir sie verkürzen

Wir kommen als zweite Mannschaft an bestehenden Code. Ihre Leute bleiben am Kern, weil sie ihn kennen; wir nehmen einen Schnitt, der sich sauber trennen lässt – eine Schnittstelle, ein Modul, einen zusätzlichen Kanal, eine Auswertung. Getrennt wird dabei nicht nach Bequemlichkeit, sondern nach Prüfbarkeit: Ein Schnitt taugt, wenn sein Ergebnis für sich abgenommen werden kann, ohne dass der halbe Kern mitwandert.

Was daraus vertraglich wird, steht auf der Seite Softwareentwicklung an bestehenden Systemen. Die Abnahmekriterien stehen im Angebot, bevor jemand anfängt; geliefert wird in Teilen; Repository und Zugänge liegen vom ersten Tag an beim Auftraggeber; fachliche Anweisungen laufen über unsere Projektleitung. Mit vollständiger Bezahlung gehen die Nutzungsrechte am eigens erstellten Code auf den Auftraggeber über. Der Zeitrahmen steht im Angebot, nicht in einem Beitrag wie diesem.

Der praktische Effekt ist unspektakulär: Die zweite Liste wird abgearbeitet, während der Releasekalender des Hauses unverändert weiterläuft. Welche Vorhaben sich für diesen Weg eignen und welche im Haus bleiben sollten, klären wir vorher. Die laufende Software-Weiterentwicklung am Kern selbst gehört meistens nicht dazu, weil dort das Wissen der eigenen Mannschaft der Engpass ist und nicht die Menge an Händen.

Und eine Einschränkung, die wir vor jedem Schnitt aussprechen: Nicht jedes wartende Vorhaben ist es wert, vorgezogen zu werden. Bevor wir ein Angebot schreiben, fragen wir nach der Umgehung – wer macht diese Arbeit heute von Hand, wie oft, und was passiert, wenn es niemand mehr tut. Fällt die Antwort dünn aus, bleibt das Vorhaben liegen. Nur diesmal mit einer Begründung statt mit einem Termin, der wieder verschoben wird.