Fallstudie · Softwareentwicklung

Individualsoftware in zwei Wochen – für einen Termin, der nicht verschiebbar war

Im Jahr 2015 erreichte uns an einem Samstagabend gegen 21 Uhr die Anfrage einer deutschen Fluggesellschaft. Bis zu einem offiziellen Besuch der damaligen Bundeskanzlerin musste eine maßgeschneiderte Software laufen. Der bisherige Dienstleister konnte den Termin nicht mehr halten, die angefragten Anbieter in Deutschland und der Schweiz nannten vier bis sechs Monate Entwicklungszeit. Bis zum Termin blieben dreieinhalb Wochen.

2015 Zeitfenster: dreieinhalb Wochen Geliefert nach zwei Wochen Termin nicht verschiebbar

Die Zahlen

Worum es zeitlich ging

2 Wochen
bis die Software fertig war
1,5 Wochen
blieben danach zum Prüfen
4–6 Monate
veranschlagten die angefragten Anbieter
1
Termin, der nicht zu verschieben war

Die Ausgangslage

Ein Anruf am Samstagabend, ein Termin, der feststand

Die meisten Softwareprojekte scheitern nicht an der Technik, sondern am Kalender. Hier war der Kalender das Problem: Der Termin war der offizielle Besuch der damaligen Bundeskanzlerin – gesetzt von außen, nicht von einer IT-Abteilung, und nicht zu verschieben. Die Software musste bis dahin nicht nur existieren, sondern laufen – bedient von Menschen, die sie noch nie gesehen hatten.

Der bisherige Dienstleister hatte abgesagt. Die daraufhin angefragten Softwarehäuser in Deutschland und der Schweiz nannten Entwicklungszeiten von vier bis sechs Monaten. Bis zum Termin waren es dreieinhalb Wochen. Rechnerisch war das Vorhaben damit erledigt, bevor es begann.

Wir haben an diesem Abend nicht zugesagt, weil wir schneller programmieren als andere. Wir haben zugesagt, weil sich der Umfang eingrenzen ließ: Es ging um eine klar umrissene Aufgabe mit einem klar umrissenen Ergebnis. Genau das ist die Bedingung, unter der solche Zeiträume überhaupt machbar sind – und der Grund, warum wir bei unklarem Umfang absagen.

Illustration: eine Anwendung entsteht aus Anforderung, Entwicklung und Prüfung.

Der Auftrag steht unter einer Verschwiegenheitsvereinbarung, die bis heute gilt. Sie deckt Inhalt und Zweck der Anwendung ab: Was die Software konnte und wozu sie diente, steht deshalb nicht auf dieser Seite – und wird es auch nicht.

Das ist keine Koketterie, sondern derselbe Umgang, den Sie von uns bekommen. Zu unseren Kunden gehören Rechtsanwaltskanzleien, Steuerberatungen und Betriebe, deren Abläufe niemanden etwas angehen. Für die wäre eine Fallstudie, in der wir ausgeplaudert hätten, kein Verkaufsargument, sondern ein Warnzeichen.

Was sich sagen lässt, steht hier: der Zeitrahmen, seine Aufteilung und die Bedingungen, unter denen so etwas machbar ist. Grundlage war ein Pflichtenheft, gegen das auch abgenommen wurde – es war kein Zuruf-Projekt. Die Projektunterlagen liegen bei uns und belegen die Zahlen dieser Fallstudie. Vorgelegt werden sie nicht: Sie fallen unter dieselbe Vereinbarung.

Der Ablauf

Dreieinhalb Wochen, aufgeteilt

Die Aufteilung ist der eigentliche Kern dieser Fallstudie: Nicht die ganze Zeit wurde entwickelt. Der größere Teil des Risikos steckt nicht im Programmieren, sondern in allem danach.

  1. Samstagabend, 21 Uhr: Anfrage

    Erstgespräch noch am selben Abend. Zuerst wurde der Umfang festgezurrt – was die Software können muss und was ausdrücklich nicht.

  2. Zwei Wochen: Entwicklung

    Die Software wurde maßgeschneidert gebaut. Keine Plattform, kein Baukasten, der zu 80 Prozent passt – für die verbleibende Zeit wäre das Anpassen teurer gewesen als das Bauen.

  3. Anderthalb Wochen: Prüfung

    Der gesamte Rest der Zeit ging in Tests. Bei einem Termin, der nicht verschiebbar ist, ist eine Software, die zu 95 Prozent läuft, keine Software.

  4. Schulung und Übergabe

    Die Mitarbeiterinnen und Mitarbeiter des Kunden wurden eingewiesen. Wer am Tag X bedient, muss vorher geübt haben – nicht lesen, was in einem Handbuch steht.

  5. Inbetriebnahme vor Ort

    Die Inbetriebnahme haben wir vor Ort begleitet. Nicht per Fernwartung, nicht mit einer Rufnummer für den Notfall.

Woran es lag

Warum dreieinhalb Wochen reichten – und wann sie nicht reichen

Es wäre unredlich, das als Normalfall darzustellen. Solche Zeiträume funktionieren unter Bedingungen, die nicht immer gegeben sind. Diese hier waren gegeben:

  • Der Umfang war klar abgrenzbar. Eine Aufgabe, ein Ergebnis, keine offene Wunschliste. Wo der Umfang während der Entwicklung wächst, hilft kein Tempo.
  • Entscheidungen fielen sofort. Auf beiden Seiten gab es je einen Ansprechpartner, der entscheiden durfte. Rückfragen wurden in Stunden geklärt, nicht in Abstimmungsrunden.
  • Wir entwickeln selbst. Kein Unterauftragnehmer, kein Offshore-Team in einer anderen Zeitzone. Wer den Quelltext geschrieben hat, saß am selben Tisch wie der, der die Anforderung aufgenommen hat.
  • Mehr Zeit für die Prüfung als üblich, nicht weniger. Von dreieinhalb Wochen gingen anderthalb ins Testen. Unter Termindruck wird üblicherweise am Testen gespart – genau das führt dann am Tag X zum Ausfall.
  • Technisch zurückhaltend gebaut. Erprobte Bausteine statt der neuesten. Bei drei Wochen Zeit ist ein unbekanntes Framework kein Fortschritt, sondern ein Risiko.

Zum Vergleich

Was veranschlagt wurde und was gebraucht wurde

Angefragte AnbieterINFONET
Genannte Entwicklungszeit4 bis 6 Monate2 Wochen
Verhältnis zum Zeitfensterdas Fünf- bis Siebenfache der verfügbaren Zeitgut die Hälfte
Zeit für die Qualitätssicherungkeine Angabe dokumentiertanderthalb Wochen, also 43 Prozent der Gesamtzeit
Schulung und Inbetriebnahmekeine Angabe dokumentiertenthalten, vor Ort begleitet
Die Angaben zu den angefragten Anbietern stammen aus den Projektunterlagen des Kunden aus dem Jahr 2015 und beziehen sich auf die damals konkret angefragten Häuser in Deutschland und der Schweiz, nicht auf den Markt insgesamt. Dokumentiert ist dort nur die genannte Entwicklungszeit – zu Qualitätssicherung, Schulung und Inbetriebnahme liegt uns zu diesen Angeboten nichts vor.

Häufige Fragen

Was Interessenten dazu meistens fragen

Was hat die Software denn nun gemacht?

Das dürfen wir nicht sagen. Die Verschwiegenheitsvereinbarung deckt Inhalt und Zweck der Anwendung ab, sie gilt bis heute – und wir halten sie auch dann ein, wenn eine Erwähnung uns nützen würde.

Wenn Sie wissen möchten, ob wir eine Aufgabe wie Ihre lösen können: Beschreiben Sie sie uns. Wir sagen Ihnen dann, was wir Vergleichbares gebaut haben – so weit, wie wir dürfen.

Heißt das, Sie entwickeln jede Software in zwei Wochen?

Nein, und wir würden es auch nicht behaupten. Zwei Wochen waren möglich, weil der Umfang klar abgegrenzt war, die Entscheidungen sofort fielen und wir selbst entwickelt haben. Fehlt eine dieser Bedingungen, dauert es länger – dann sagen wir Ihnen das vorher.

Was diese Fallstudie zeigt, ist nicht Tempo um jeden Preis, sondern was möglich ist, wenn ein Vorhaben eng gefasst und die Abstimmung kurz ist.

Leidet die Qualität, wenn es so schnell gehen muss?

Sie leidet, wenn am Testen gespart wird – und genau das passiert unter Termindruck üblicherweise. Hier ging der größere Teil des Zeitfensters nicht in die Entwicklung, sondern in die Prüfung: zwei Wochen bauen, anderthalb Wochen testen.

Bei einem Termin, der nicht verschiebbar ist, gibt es keinen zweiten Versuch. Deshalb wird die Prüfzeit als Erstes eingeplant und nicht als Letztes.

Warum haben andere Anbieter abgesagt?

Das müssten Sie dort fragen. Vier bis sechs Monate sind für eine Fachanwendung kein unrealistischer Ansatz – wenn man mit einem üblichen Projektaufbau rechnet: Lastenheft, Angebotsphase, Entwicklungsstufen, Abnahmen. Der Zeitplan entsteht dabei oft aus dem Verfahren, nicht aus dem Aufwand.

Wir haben den Umfang so weit eingegrenzt, bis er in die verfügbare Zeit passte – und den Rest ausdrücklich weggelassen.

Machen Sie so etwas noch?

Ja. Kurzfristige Vorhaben mit festem Termin sind bei uns kein Sonderfall. Was wir vorher klären, ist immer dasselbe: Was muss zum Termin laufen, was kann danach kommen, und wer entscheidet auf Ihrer Seite.

Wenn wir zu dem Schluss kommen, dass die Zeit nicht reicht, sagen wir das – vor dem Auftrag, nicht mittendrin.

Um welche Fluggesellschaft ging es?

Kundennamen veröffentlichen wir nur mit ausdrücklicher Zustimmung. Bei konkretem Interesse stellen wir nach Rücksprache gern einen persönlichen Kontakt her.

Hinweis zur Vertraulichkeit

Aus Gründen der Vertraulichkeit veröffentlichen wir Kundennamen und Ansprechpartner nur mit ausdrücklicher Zustimmung. Für dieses Projekt besteht darüber hinaus eine Verschwiegenheitsvereinbarung über Inhalt und Zweck der Anwendung. Die Zeitangaben dieser Fallstudie stammen aus den Projektunterlagen.

Kostenloses Erstgespräch

Ein Termin, der nicht zu verschieben ist?

Sagen Sie uns, was bis wann laufen muss. Wir sagen Ihnen, ob es geht – und wenn nicht, was stattdessen bis dahin machbar wäre.

0221 984300-0Zentrale und Support-Hotline

[email protected]Antwort innerhalb von 4 Stunden an Werktagen

Robert-Perthel-Straße 7250739 Köln – Bilderstöckchen

Mo–Fr 09:00–18:00 UhrNotfallsupport nach Vereinbarung auch außerhalb