Softwareprojekte: Warum der erste Preis selten der letzte ist

Die Entscheidung ist gefallen — das Unbekannte beginnt jetzt

Wer ein Softwareprojekt beauftragt, hat sich die Entscheidung meist nicht leicht gemacht. Es gab Gespräche, Angebote, vielleicht Präsentationen mehrerer Anbieter. Irgendwann gibt es einen Preis, einen Zeitplan und die Unterschrift unter einem Vertrag. Das Gefühl in diesem Moment: die schwere Entscheidung liegt hinter einem.

In Wirklichkeit markiert dieser Moment etwas anderes. Er ist der Beginn eines Prozesses, in dem vieles sichtbar wird, das vorher nicht sichtbar war — nicht weil schlecht geplant wurde, sondern weil Software eine Eigenschaft hat, die sie von fast allen anderen Aufträgen unterscheidet.

Was sich verändert, während gebaut wird

Das Bild entsteht erst beim Bauen

Am Anfang eines Softwareprojekts beschreibt man etwas, das noch nicht existiert. Man beschreibt Prozesse, die man kennt, und stellt sich vor, wie sie in einer Anwendung aussehen sollen. Das gelingt erstaunlich gut — und erstaunlich unvollständig.

Wenn erste Versionen sichtbar werden, entstehen Fragen, die vorher nicht formulierbar waren. Nicht weil die ursprüngliche Beschreibung falsch war. Sondern weil Lücken erst erkennbar sind, wenn man etwas Konkretes vor sich hat.

Ein Beispiel: Ein Verwaltungsunternehmen beschreibt, wie Mieteranfragen bearbeitet werden sollen — Eingang, Prüfung, Weiterleitung, Antwort. Die Beschreibung wirkt vollständig. Dann entsteht das System, und man stellt fest: Ein Ausnahmefall, der im Alltag selbstverständlich war, wurde nie aufgeschrieben. Er muss abgebildet werden. Das kostet Zeit.

Diese Erkenntnis ist unvermeidlich. Sie entsteht nicht durch Unvorsichtigkeit. Sie entsteht, weil Vorstellungen und fertige Systeme zwei verschiedene Dinge sind.

Was andere Systeme damit anfangen sollen

Kaum ein Softwareprojekt steht für sich allein. Die neue Anwendung soll mit der Buchhaltung sprechen. Mit dem Kalender. Mit dem Portal eines Anbieters. Mit dem System, das vor acht Jahren eingeführt wurde und bis heute läuft.

Was dabei zutage kommt, ist selten das, was man erwartet hat. Das andere System liefert Daten in einem Format, das niemand vollständig dokumentiert hat. Die Übergabe zwischen den Systemen funktioniert — aber nur wenn bestimmte Bedingungen erfüllt sind, die vorher niemand kannte. Was wie eine Randbemerkung klingt, hat direkte Auswirkungen auf Aufwand und Zeit.

Das ist kein Fehler des Entwicklungsteams. Es ist die normale Beschaffenheit gewachsener IT-Umgebungen, wie sie sich in fast jedem mittelständischen Unternehmen finden.

Was nach der Einführung bleibt

Das Projekt ist abgeschlossen. Das System ist in Betrieb. Wer jetzt glaubt, die Kosten seien damit abgeschlossen, erlebt in den meisten Fällen eine Überraschung.

Laufende Veränderungen, die niemand eingerechnet hat

Software, die produktiv genutzt wird, verändert sich — auch wenn man nichts Neues will. Browser und Betriebssysteme werden aktualisiert. Sicherheitslücken werden bekannt und müssen geschlossen werden. Anforderungen an Datenschutz und rechtliche Absicherung ändern sich, und damit ändert sich, was ein System leisten muss.

Das ist keine Fehlerquote. Es ist der normale Lebenszyklus einer Anwendung. Wer ein Gebäude kauft, rechnet mit Heizung, Strom und Instandhaltung. Bei Software ist dieses Bewusstsein seltener — obwohl die Mechanik ähnlich funktioniert.

Hinzu kommt: Software, die gut genutzt wird, weckt Erwartungen. Die Mitarbeiterin, die das System täglich verwendet, hat nach drei Monaten genaue Vorstellungen davon, was fehlt. Der Inhaber, der die Auswertungen sieht, möchte eine weitere Ansicht. Diese Wünsche sind legitim. Sie gehören nicht zum ursprünglichen Auftrag.

Was der Alltag zeigt, den die Planung nicht kannte

Manchmal stellt sich nach einigen Monaten heraus, dass ein Teil des Systems anders genutzt wird als geplant. Nicht weil das System schlecht gebaut wurde. Weil reale Arbeit und modellierte Prozesse nie vollständig deckungsgleich sind.

Eine Mitarbeiterin nutzt einen Umweg, weil der direkte Weg in einem bestimmten Fall nicht funktioniert. Jemand führt eine Tabelle parallel, weil das System eine Auswertung nicht liefert, die im Alltag gebraucht wird. Diese Momente sind kein Zeichen von schlechter Software. Sie sind Zeichen davon, dass Arbeitswirklichkeit und Planung zwei verschiedene Dinge sind.

Wer das früh erkennt, passt an. Wer es nicht erkennt, arbeitet dauerhaft um das System herum — was langfristig mehr kostet als die Anpassung selbst.

Warum Schätzungen strukturell unvollständig sind

Es gibt einen Grund, warum Softwareprojekte anders verlaufen als andere Vorhaben. Ein Handwerker baut etwas Greifbares. Man sieht beim Richtfest, wie weit er ist. Man geht durch die Räume.

Software entsteht anders. Lange sieht man nichts — dann sieht man etwas, das noch nicht fertig ist und trotzdem schon Entscheidungen verlangt. Diese Eigenart macht Schätzungen grundsätzlich schwierig. Nicht weil die beteiligten Menschen unzuverlässig wären. Sondern weil das Medium es nicht anders zulässt.

Eine Kalkulation zu Beginn eines Projekts schätzt etwas, das noch nicht vollständig bekannt ist. Das ist keine Schwäche — es ist die Natur der Sache. Wer das versteht, führt andere Gespräche: nicht nur über den Preis, sondern darüber, was passiert, wenn etwas hinzukommt. Wer dann entscheidet. Wie bewertet wird, was nötig ist und was nicht.

Was technische Schulden mit Ihrem Budget zu tun haben

Es gibt einen Begriff, den Entwicklerteams untereinander verwenden und der selten nach außen dringt: technische Schulden. Gemeint sind damit Entscheidungen, die beim Bauen bewusst oder unbewusst getroffen werden — Abkürzungen, die zu einem bestimmten Zeitpunkt sinnvoll waren und später teurer werden.

Das klingt wie ein internes Problem. Es ist keins. Technische Schulden zahlt am Ende derjenige, der das System besitzt. Nicht in einer Rechnung, die diesen Namen trägt. Sondern in Form von Änderungen, die länger dauern als erwartet. In Form von Fehlern, die auftauchen, wenn man eigentlich etwas anderes anfassen wollte. In Form von Aussagen wie: „Das geht leider nicht so einfach."

Diese Sätze haben eine Vorgeschichte. Man bekommt sie selten erklärt.

Teams, die offen über solche Entscheidungen sprechen — die sagen, welche Abkürzungen sie warum genommen haben und was das später bedeutet —, sind in der Regel zuverlässiger als solche, die immer sagen, was man hören möchte. Wer im Gespräch mit einem Softwarehaus wie Innosirius hört, dass ein Vorhaben Risiken trägt, ist näher an der Wahrheit als jemand, dem alles reibungslos versprochen wird.

Die Frage hinter der Zahl

Wenn jemand fragt, was eine bestimmte Software kostet, ist das eine verständliche Frage. Sie hat keine vollständige Antwort — nicht weil niemand ehrlich rechnen will, sondern weil die Frage unvollständig ist.

Was kostet eine Software? Der Bau. Die Einführung. Die Anpassungen, die sich erst zeigen, wenn das System im Betrieb ist. Der Betrieb selbst. Die Weiterentwicklung, wenn sich der Markt oder das eigene Unternehmen verändert. Die Zeit, die Mitarbeitende brauchen, um sich einzuarbeiten und das zu finden, was im Alltag tatsächlich funktioniert.

Keiner dieser Posten ist versteckt. Keiner ist unehrlich. Sie entstehen, weil Software kein Produkt ist, das man kauft und einlagert. Es ist ein System, das sich verändert — solange man es nutzt.

Welche Fragen am Anfang zählen

Unternehmen, die solche Projekte gut durchlaufen, stellen am Anfang andere Fragen. Nicht nur: Was kostet der Bau? Sondern: Was fällt nach dem ersten Jahr an? Was passiert, wenn sich die Anforderungen ändern? Wer ist zuständig, wenn etwas nicht mehr funktioniert — und was bedeutet das konkret für den Betrieb?

Diese Fragen können unbequem sein. Sie können dazu führen, dass ein Angebot auf einmal anders aussieht als im ersten Gespräch. Das ist kein schlechtes Zeichen. Es ist ein ehrliches.

Wer solche Antworten vor der Unterschrift hat, ist in einer anderen Position — unabhängig davon, wie das Projekt am Ende verläuft.