Das Schätzen von Softwareprojekten war lange eine unbefriedigende Angelegenheit. Planning Poker gespielt, T-Shirt-Größen vergeben, Punkte geklebt. Die Ergebnisse waren selten belastbar genug, um daraus ein Kundenangebot abzuleiten.
Nach 15 Jahren Projektarbeit mit Kunden wie der ERGO, der Deutschen Post und der Deutschen Bahn ist die Überzeugung gereift: Schätzungen sind nicht das Problem. Unstrukturierte Schätzungen sind das Problem. Und der Verzicht auf Schätzungen ist das größte Risiko von allen.
Warum Schätzungen kein Overhead sind
„Aufwandsschätzungen sind Zeitverschwendung.“ Diese Position taucht regelmäßig auf, von Entwicklern und Projektverantwortlichen gleichermaßen. Schätzungen werden entweder übersprungen oder pflichtmäßig durchgeführt, weil es im Prozess vorgesehen ist. In beiden Fällen geht der eigentliche Wert verloren.
Denn der Wert einer Schätzung entsteht nicht erst mit dem Ergebnis. Er entsteht bereits während des Schätzprozesses:
Die Fachlichkeit wird tiefer durchdrungen, als es eine reine Anforderungslektüre ermöglicht. Entwickler setzen sich aktiv damit auseinander, was die Software leisten soll. Kritische Rückfragen decken Lücken in den Anforderungen auf, die sonst erst während der Implementierung sichtbar würden. Der Fachbereich wird gezwungen, vage Formulierungen zu konkretisieren.
Ein Feature, das nach einer kritischen Rückfrage komplett neu gedacht wird, kostet 1 bis 2 Stunden Diskussion. Das gleiche Feature ohne Rückfragen implementieren und dann im Benutzertest feststellen, dass die Grundannahme falsch war, kostet ein Vielfaches.
Das Coastline Paradox und seine Parallele zur Softwareschätzung
1967 stellte der Mathematiker Benoît Mandelbrot eine Frage, die auf den ersten Blick trivial wirkt: Wie lang ist die Küste von Großbritannien?
Die Antwort hängt vom Maßstab ab. In 100-km-Schritten gemessen sind es etwa 2.800 km. In 10-km-Schritten etwa 5.500 km. In 1-km-Schritten etwa 17.800 km. Je feiner der Maßstab, desto mehr Buchten, Fjorde und Felsen werden erfasst. Mandelbrot nannte das „Coastline Paradox“.
Die Parallele zur Softwareschätzung ist aufschlussreich. Je tiefer man in die Anforderungen eines Projekts einsteigt, desto mehr Komplexität wird sichtbar: Edge Cases, Integrationsanforderungen, Migrationspfade, Fehlerbehandlung. Jede Analyseebene offenbart neue Details.
Aber es gibt einen entscheidenden Unterschied: Eine Küste ist geometrisch fix. Die Details waren immer da, man sieht sie nur bei höherer Auflösung. Software-Anforderungen dagegen sind emergent. Sie verändern sich, während man sie analysiert. Neue Fragen führen zu neuen Anforderungen. Das Verständnis des Problems verändert das Problem selbst.
Bedeutet das, dass Schätzungen sinnlos sind? Im Gegenteil. Wer ernsthaft schätzt, muss Anforderungen durchdenken. Muss Fragen stellen, die sonst erst in der Implementierung auftauchen. Muss Abhängigkeiten erkennen, bevor sie zu Blockern werden. Und das Geschäft braucht eine Grundlage: Ohne belastbare Aufwandsindikation ist keine sinnvolle Entscheidung über Invest versus Mehrwert möglich.
Das Problem mit Bauchgefühl-Schätzungen
Bauchgefühl-Schätzungen sind die häufigste Methode und gleichzeitig die unzuverlässigste. Das typische Szenario läuft so ab: Ein Meeting, jemand wirft eine Zahl in den Raum, die Runde nickt. Ohne strukturierte Analyse, ohne historische Daten, ohne Risikobewertung.
Selbst erfahrene Software-Teams mit bewährten Verfahren und historischen Vergleichswerten liegen regelmäßig daneben. Softwareentwicklung ist komplex und schwer planbar. Wenn Experten mit strukturierten Methoden daneben liegen, ist die Erwartung, dass eine Schätzung aus dem Bauch heraus zuverlässig sein könnte, unrealistisch.
Die Konsequenzen sind vorhersehbar. Entweder endet das Projekt als Minimal-Version, die den eigentlichen Bedarf nicht deckt, oder es folgen Monate der Nachfinanzierung und Diskussionen. Das Vertrauen aller Beteiligten leidet, das Team steht unter Dauerdruck und das Projekt wird zum Negativbeispiel, das bei der nächsten Investitionsentscheidung als Argument dient.
Story-Points im Projektgeschäft
In der agilen Community hat die Ablehnung stundenbasierter Schätzungen zugunsten von Story-Points fast dogmatische Züge angenommen. Für langlaufende Produktentwicklungsteams, die ihre Velocity kennen und pflegen, ist relatives Schätzen ein sinnvoller Ansatz.
Im Projektgeschäft, also bei individueller Softwareentwicklung für externe Kunden, bricht dieses Modell an einer konkreten Stelle zusammen: Am Ende des Schätzprozesses muss ein Angebot stehen. Und ein Angebot wird in Euro formuliert, nicht in Story-Points.
Der Umweg über abstrakte Größen erzeugt eine Scheinpräzision: Die Story-Points müssen am Ende in einen Geldwert umgerechnet werden. Und diese Umrechnung basiert auf Erfahrungswerten, Teamkosten und letztlich auf Zeiteinheiten. Wenn am Ende ohnehin eine Arbeitseinheit stehen muss, stellt sich die Frage, was der Zwischenschritt über abstrakte Größen bringt.
Für die interne Sprint-Planung und Priorisierung haben Story-Points ihren Platz. Für die externe Angebotserstellung im Projektgeschäft sind sie ein unnötiger Umweg. Die Stunde als Basis ist etabliert, nachvollziehbar und für den Kunden transparent.
Was KI beim Schätzen leisten kann und was nicht
KI-Werkzeuge liefern bei der Konzeption neuer Projekte brauchbare Ergebnisse: Lösungsarchitektur, technische Recherche, erste Entwürfe. Dabei spucken sie auch Aufwandsschätzungen aus. Die Beobachtung nach mehreren Monaten Nutzung: KI schätzt fast immer deutlich höher als die Einschätzung aus 25 Jahren Projekterfahrung.
Die Erklärung liegt vermutlich in den Trainingsdaten: Wenn die Datenbasis überwiegend aus Projekten besteht, die über Budget gelaufen sind (was für einen Großteil aller Softwareprojekte zutrifft), tendiert die KI zu konservativen Schätzungen.
Das ist nicht grundsätzlich falsch. Möglicherweise bildet die KI ab, was Projekte tatsächlich kosten, inklusive aller versteckten Aufwände, die bei menschlichen Schätzungen gerne kleingerechnet werden. Das Problem entsteht, wenn Entscheider diese Zahlen unreflektiert übernehmen: Sinnvolle Projekte werden nicht gestartet, weil sie „zu teuer“ erscheinen, oder Budgets werden aufgebläht.
Aufwandsschätzungen gehören zu den Aufgaben, die Erfahrung, Kontext und Verantwortungsbewusstsein erfordern. KI-Schätzungen dienen als zweite Meinung und als Benchmark, nicht als Entscheidungsgrundlage.
Der Schätzsheet-Ansatz
Aus den beschriebenen Erfahrungen hat sich ein strukturierter Schätzprozess entwickelt, den wir intern „Schätzsheet“ nennen. Das Grundprinzip ist einfach, die Wirkung liegt in der Konsequenz der Anwendung:
Aufgaben herunterbrechen: Das Projekt wird in kleine, schätzbare Einheiten gegliedert: User Stories („Login“, „Passwort vergessen“) und technische Aufgaben („Datenimport“, „Schnittstelle ABC“). Kleine Einheiten sind zuverlässiger zu schätzen als große Blöcke, weil sie weniger versteckte Komplexität enthalten.
Vergessene Aufwände einplanen: Projektmanagement, Qualitätssicherung, Framework-Updates, Test-Support, Installation und Deployment. Diese Posten werden in der Schätzung häufig übersehen, obwohl sie in der Praxis 20 bis 30 Prozent des Gesamtaufwands ausmachen
können. Das Schätzsheet enthält diese Posten als Standardpositionen, die bewusst bewertet und nicht versehentlich vergessen werden.
Risikofaktoren berücksichtigen: Externe Schnittstellen? Unerfahrenes Team? Hohes erwartetes Nutzeraufkommen? Unscharfe Anforderungen? Diese Faktoren fließen als Aufschläge in die Kalkulation ein. Das macht die Schätzung transparenter und die Diskussion über Risiken explizit.
Ergebnis nachvollziehbar machen: Das Endergebnis ist keine einzelne Zahl, sondern eine aufgeschlüsselte Kalkulation. Der Kunde sieht, welches Feature welchen Aufwand verursacht, wo die Risikozuschläge liegen und wo Einsparpotenzial besteht. Diese Transparenz schafft Vertrauen und ermöglicht informierte Entscheidungen1.
Schätzsheet Download
Fazit
Jede Softwareschätzung ist mit Unsicherheit behaftet. Das ist kein Defekt des Verfahrens, sondern die Natur der Sache. Die Aufgabe ist nicht, diese Unsicherheit zu eliminieren, sondern sie zu beherrschen.
Drei Prinzipien haben sich über 15 Jahre bewährt. Erstens mehr Zeit in die initiale Analyse investieren, weil die Stunden am Anfang ein Vielfaches am Ende sparen. Zweitens ehrliche Spannen kommunizieren, statt Punktlandungen zu versprechen, weil eine Schätzung eine fundierte Annahme ist und keine Garantie. Drittens ein Umfeld schaffen, in dem Anpassungen Professionalität bedeuten und nicht Scheitern, weil sich Projekte verändern und die Schätzung das abbilden muss.
„So wie die alte Software.“ Fünf Worte, die nach klaren Anforderungen klingen. In der Praxis sind sie der Beginn eines Projekts, das fast immer teurer und langwieriger wird als geplant. Wer Legacy Software ablösen will, stößt nach dutzenden solcher Projekte auf dieselbe Erkenntnis: Diese fünf Worte sind keine Anforderungsspezifikation. Sie sind eine Falle.
Die unsichtbare Komplexität
Bestandssoftware, die über Jahre oder Jahrzehnte gewachsen ist, enthält weit mehr Funktionalität, als auf den ersten Blick sichtbar ist. Das liegt in der Natur gewachsener Systeme.
Da ist der Jahresreport, an den gerade niemand denkt, weil er nur einmal im Jahr läuft. Die 47 Sonderfälle, die über die Jahre eingebaut wurden, ohne dass sie je dokumentiert wurden. Die Schnittstelle zu einem Drittsystem, die ein Kollege vor fünf Jahren eingerichtet hat und die seitdem „einfach läuft“. Die Berechtigungslogik, die so komplex ist, dass niemand mehr erklären kann, warum bestimmte Nutzergruppen bestimmte Funktionen sehen und andere nicht.
All das ist funktionale Komplexität, die im Alltagsbetrieb unsichtbar bleibt. Sie taucht nicht in der Benutzeroberfläche auf, nicht in der Schulungsunterlage und meistens nicht in der Dokumentation. Sie wird erst sichtbar, wenn jemand versucht, das System nachzubauen, und feststellt, dass die sichtbaren 70% der Funktionalität vielleicht 40% des tatsächlichen Aufwands ausmachen.
Für die Projektplanung bedeutet das: Eine Aufwandsschätzung, die auf dem basiert, was Nutzer sehen und beschreiben können, unterschätzt den tatsächlichen Umfang systematisch. Die unsichtbare Komplexität taucht erst während der Umsetzung auf, in Form von Rückfragen, Nachspezifikationen und Korrekturen.
Die falsche Frage: „Genau das Gleiche nochmal“
Die zweite Falle liegt in der Annahme, dass die alte Software den heutigen Bedarf korrekt abbildet. In den meisten Fällen tut sie das nicht.
Hat sich die Welt in den letzten 10 Jahren nicht verändert? Neue Prozesse, neue gesetzliche Vorgaben, neue Anforderungen aus dem Markt? Funktionen, die vor 10 Jahren wichtig waren, werden heute möglicherweise gar nicht mehr genutzt. Und Funktionen, die heute gebraucht werden, existieren in der alten Software nicht, weil sie nie eingeplant waren.
„So wie bisher“ ist oft nicht die durchdachte Anforderung, als die sie erscheint. Es ist die bequemste Antwort, weil sie niemandem abverlangt, wirklich nachzudenken. Es ist einfacher zu sagen „mach es wie vorher“ als sich hinzusetzen und zu analysieren, was heute tatsächlich gebraucht wird.
Das Ergebnis: Eine neue Software, die alte Probleme originalgetreu reproduziert. Inklusive der Workarounds, die Nutzer über die Jahre entwickelt haben, weil die Software ihren eigentlichen Bedarf nicht abgedeckt hat.
Was stattdessen funktioniert
Ablöseprojekte, die gut laufen, behandeln die alte Software als Informationsquelle, nicht als Blaupause. Der Unterschied liegt im Vorgehen.
Anforderungen neu definieren, nicht kopieren: Statt die alte Software Feature für Feature nachzubauen, wird gefragt: Was brauchen die Nutzer heute? Welche Geschäftsprozesse soll die Software unterstützen? Welche Probleme soll sie lösen? Die alte Software liefert dabei wertvolle Hinweise, welche Funktionen tatsächlich genutzt werden. Aber sie definiert nicht, was die neue Software können muss.
Funktionsnutzung analysieren: Welche Funktionen werden täglich genutzt? Welche monatlich? Welche seit drei Jahren nicht mehr? Diese Analyse liefert ein realistisches Bild des tatsächlichen Bedarfs. In fast jedem Ablöseprojekt stellt sich heraus, dass 30 bis 40% der Funktionen der alten Software nicht mehr oder kaum noch genutzt werden. Diese Funktionen nicht nachzubauen, spart erheblichen Aufwand, ohne dass jemand etwas vermisst.
Unsichtbare Komplexität aktiv suchen: Vor dem Projektstart gezielt nach den Dingen fragen, die nicht offensichtlich sind: Welche Reports gibt es? Welche Schnittstellen? Welche Sonderfälle? Welche zeitgesteuerten Prozesse? Welche Berechtigungsregeln? Diese Erhebung kostet Zeit am Anfang, spart aber ein Vielfaches an Überraschungen während der Umsetzung.
Die Ablösung als Chance nutzen: Ein Ablöseprojekt ist der ideale Zeitpunkt, um Prozesse zu hinterfragen. Nicht nur die Software wechselt, auch die Abläufe können verbessert werden. Unternehmen, die diese Chance nutzen, bekommen am Ende nicht nur eine neue Software, sondern auch bessere Prozesse.
Warum „schnell ablösen“ selten funktioniert
In vielen Ablöseprojekten herrscht Zeitdruck. Die alte Software wird abgekündigt, der Support läuft aus, die Technologie ist veraltet. Die Versuchung ist groß, die Analysephase abzukürzen: „Wir wissen doch, was die Software macht. Einfach nachbauen.“
Diese Abkürzung rächt sich fast immer. Die ersten Monate laufen scheinbar gut. Dann tauchen die Sonderfälle auf, die niemand dokumentiert hatte. Die Buchhaltung meldet sich, weil der Jahresabschluss-Report fehlt. Die Fachabteilung stellt fest, dass eine Funktion, die als unwichtig eingestuft wurde, doch geschäftskritisch ist.
Jede dieser Nachforderungen kostet mehr, als eine gründliche Analyse am Anfang gekostet hätte. Nicht weil die Analyse teuer ist, sondern weil Änderungen während der Umsetzung um ein Vielfaches aufwändiger sind als Klärungen vor dem Start.
Realistische Erwartungen setzen
Ein Ablöseprojekt ist kein einfacher Technologietausch. Es ist ein Neubauprojekt mit dem zusätzlichen Anspruch, die Erfahrungen aus dem Altsystem zu berücksichtigen. Das macht es nicht einfacher als ein Neuprojekt, sondern in manchen Aspekten komplexer, weil die Erwartungshaltung durch die bestehende Software geprägt ist.
Realistische Erwartungen sehen so aus. Die neue Software wird in der ersten Version nicht alles können, was die alte konnte. Das ist kein Scheitern, das ist der normale Verlauf. Die alte Software hatte Jahre, um zu dem zu werden, was sie ist. Die neue Software deckt in der ersten Version die 80 Prozent ab, die 95 Prozent des Geschäftswerts ausmachen. Die restlichen Funktionen folgen iterativ, priorisiert nach tatsächlichem Bedarf.
Fazit
„So wie die alte Software“ klingt nach einer einfachen Anforderung. In der Praxis unterschätzt sie die unsichtbare Komplexität gewachsener Systeme und verhindert, dass die Ablösung als Chance für Verbesserungen genutzt wird. Ablöseprojekte gelingen, wenn Anforderungen neu gedacht werden, statt alte Funktionslisten zu kopieren. Die alte Software ist eine wertvolle Informationsquelle. Aber sie ist keine Blaupause für die Zukunft.
In Softwareprojekten treffen zwei Welten aufeinander: Auftraggeber, die eine Lösung für ihr Geschäftsproblem suchen, und Entwicklerteams, die diese Lösung technisch umsetzen. Beide Seiten bringen eigene Erfahrungen, Erwartungen und Annahmen mit. Und genau an dieser Schnittstelle entstehen die meisten Reibungsverluste.
Woher die unterschiedlichen Erwartungen kommen
Viele Auftraggeber bringen technisches Vorwissen mit. Sie haben bereits Softwareprojekte begleitet, Artikel über Technologietrends gelesen oder selbst mit Tools gearbeitet. Dieses Wissen ist wertvoll, denn es erleichtert die Kommunikation und hilft, Anforderungen präziser zu formulieren.
Gleichzeitig entsteht daraus eine Herausforderung: Erfahrungen aus einem Kontext lassen sich nicht immer direkt auf einen anderen übertragen. Ein CRM-Projekt mit klar definierten Standardprozessen hat andere Rahmenbedingungen als eine Individualentwicklung mit komplexen Schnittstellenanforderungen. Wer in dem einen Kontext gelernt hat, dass „so etwas in zwei Wochen geht“, hat damit in jenem Kontext recht gehabt. Die Schlussfolgerung, dass es im neuen Kontext genauso schnell gehen muss, führt aber oft zu Diskussionen.
Das ist kein Vorwurf. Es ist ein Strukturproblem. Softwarekomplexität ist von außen schwer einzuschätzen, weil die meisten Aufwandstreiber unsichtbar sind.
Warum Aufwände schwer einzuschätzen sind
Ein Beispiel. „Wir brauchen noch ein Feld im Formular.“ Aus Anwendersicht ist das eine Kleinigkeit. Aus technischer Sicht kann es bedeuten, dass das Datenbank-Schema angepasst, ein Migrationsskript geschrieben, die Validierungslogik ergänzt, der API-Endpunkt erweitert, das Berechtigungskonzept geprüft, die Tests aktualisiert und die Dokumentation nachgezogen werden müssen. Je nach System und Architektur sind das zwei Stunden oder zwei Tage.
Die Diskrepanz zwischen gefühltem und tatsächlichem Aufwand ist einer der häufigsten Konfliktherde in Softwareprojekten. Nicht weil eine Seite die Wahrheit verbiegt, sondern weil beide Seiten von unterschiedlichen mentalen Modellen ausgehen.
Der Auftraggeber denkt in Funktionalität: „Ein Feld mehr, das muss doch schnell gehen.“ Der Entwickler denkt in Systemzusammenhängen: „Ein Feld mehr betrifft sechs Schichten der Anwendung.“ Beide haben aus ihrer Perspektive recht.
Ähnlich verhält es sich mit Technologievorschlägen. „Warum nehmt ihr nicht einfach Tool X?“ ist eine berechtigte Frage. Die Antwort erfordert aber oft eine längere technische Erklärung: Tool X löst ein verwandtes, aber anderes Problem. Es skaliert nicht für den konkreten Anwendungsfall. Es bietet keine Schnittstelle zum vorhandenen ERP-System. Diese Zusammenhänge sind ohne tiefes Wissen über die bestehende Systemlandschaft schwer nachvollziehbar.
Was in der Praxis hilft
Der Schlüssel liegt in transparenter Kommunikation. Nicht als Floskel, sondern als konkretes Vorgehen.
Aufwände aufschlüsseln statt zusammenfassen: Statt „Das dauert 40 Stunden“ besser erklären, woraus sich diese 40 Stunden zusammensetzen. Wenn ein Auftraggeber sieht, dass 8 Stunden auf die Schnittstellenanpassung und 6 Stunden auf die Migrationsskripte entfallen, wird die Zahl nachvollziehbar. Die Gesamtzahl allein wirkt oft willkürlich. Die Aufschlüsselung schafft Vertrauen.
Analogien aus der physischen Welt nutzen: Technische Zusammenhänge werden greifbarer, wenn man sie in bekannte Kontexte übersetzt. „Das ist wie beim Hausbau: Eine zusätzliche Steckdose klingt einfach. Aber wenn die Wand schon verputzt ist, muss aufgestemmt, Kabel gezogen, neu verputzt und gestrichen werden. Die Steckdose selbst ist trivial. Der Kontext macht sie aufwändig.“
Früh und oft abstimmen: Die meisten Erwartungsprobleme entstehen nicht durch bösen Willen, sondern durch zu lange Kommunikationspausen. Wenn der Auftraggeber den Fortschritt regelmäßig sieht, beispielsweise in zweiwöchentlichen Demos, baut sich ein realistisches Gefühl für Komplexität auf. Die Frage „Warum hat das so lange gedauert?“ kommt deutlich seltener, wenn man den Prozess mitverfolgen kann.
Vorwissen als Ressource nutzen statt als Störfaktor behandeln: Auftraggeber, die technische Fragen stellen und Aufwände hinterfragen, sind engagierte Auftraggeber. Sie wollen verstehen, was passiert. Das ist keine Behinderung des Projekts, sondern ein Zeichen dafür, dass ihnen das Ergebnis wichtig ist. Teams, die diese Energie konstruktiv einbinden, statt sie abzuwehren, haben langfristig die besseren Projektbeziehungen.
Die gemeinsame Sprache finden
Die Herausforderung in Softwareprojekten ist selten die Technik. Es ist die Kommunikation zwischen Fachlichkeit und Technik. Beide Seiten müssen investieren: Entwickler müssen lernen, technische Entscheidungen verständlich zu erklären. Auftraggeber müssen bereit sein, der technischen Einschätzung zu vertrauen, auch wenn sie dem eigenen Bauchgefühl widerspricht.
Das funktioniert am besten in einer Projektkultur, in der Fragen willkommen sind. Wo „Warum dauert das so lange?“ nicht als Angriff verstanden wird, sondern als Einladung zur Erklärung. Und wo „Das ist technisch komplexer als erwartet“ nicht als Ausrede abgetan wird, sondern als Information, die beide Seiten für bessere Entscheidungen nutzen.
Fazit
Unterschiedliche Erwartungen in Softwareprojekten sind normal und unvermeidbar. Sie entstehen nicht durch mangelnde Kompetenz auf einer Seite, sondern durch die grundsätzlich verschiedenen Perspektiven, die Auftraggeber und Entwicklungsteams mitbringen. Transparente Aufwandsdarstellung, regelmäßige Abstimmung und der gegenseitige Respekt für die jeweils andere Perspektive sind die Werkzeuge, die aus Reibung produktive Zusammenarbeit machen.
„Sollte das Feature nicht schon vor zwei Monaten fertig sein?“ Diese Frage taucht in Softwareprojekten mit bemerkenswerter Regelmäßigkeit auf. Anforderungen lagen vor, Schätzungen wurden gemacht, das Team hat gearbeitet, und trotzdem stimmt der Zeitplan nicht. Die Ursache liegt fast nie in der Umsetzung. Sie liegt im Start.
Wo die Verzögerung tatsächlich entsteht
Die intuitive Annahme lautet: Das Team hat zu langsam gearbeitet. In den meisten Fällen stimmt das nicht. Verzögerungen entstehen deutlich früher im Prozess, oft bevor die erste Zeile Code geschrieben wird.
Unklare Anforderungen: „Das Feature soll wie bei Amazon funktionieren“ ist kein Anforderungsdokument. Es ist ein Wunsch. Und zwischen einem Wunsch und einer spezifizierten Anforderung liegen erhebliche Klärungsaufwände. Wenn diese Klärung nicht vor dem Entwicklungsstart stattfindet, findet sie währenddessen statt, in Form von Rückfragen, Missverständnissen und Korrekturen. Das kostet mehr Zeit als eine gründliche Analysephase.
Fehlende Abnahmekriterien: Wenn nicht vor dem Start definiert ist, wann ein Feature „fertig“ ist, wird es faktisch nie fertig. Jede Demo produziert neue Wünsche, jedes Review neue Anforderungen. Das ist kein böser Wille, es ist die natürliche Folge von fehlendem Scope-Management. Wer keine Abnahmekriterien hat, kann weder Fortschritt messen noch das Ende definieren.
Unterschätzte Abhängigkeiten: Das Feature selbst ist vielleicht einfach. Aber es braucht eine Schnittstelle zu einem System, das gerade migriert wird. Oder Testdaten, die noch nicht existieren. Oder eine Fachbereichsfreigabe, die zwei Wochen dauert. Diese Abhängigkeiten werden am Anfang übersehen, weil sie nicht im direkten Scope des Features liegen. Und am Ende werden sie zum Showstopper.
Zu optimistische Schätzungen: Jede Schätzung hat eine implizite Annahme: „Wenn alles glatt läuft.“ In der Praxis läuft selten alles glatt. Es gibt Rückfragen, unerwartete technische Hürden, kranke Teammitglieder, parallele Projekte, die Kapazität binden. Wer den Best Case schätzt, wird im Regelfall überzogen.
Vier Maßnahmen, die den Unterschied machen
Aus 15 Jahren Projektarbeit mit Kunden unterschiedlicher Größe und Branche haben sich vier Maßnahmen als besonders wirksam erwiesen.
Anforderungen durchdringen, nicht nur erfassen: Das klingt nach einer Selbstverständlichkeit, ist es aber in der Praxis oft nicht. „Durchdringen“ bedeutet: Nicht nur aufschreiben, was der Auftraggeber sagt, sondern verstehen, warum er es braucht. Was ist der Geschäftskontext? Wer nutzt das Feature? Was passiert, wenn es nicht oder anders funktioniert? Wenn das Entwicklungsteam den Geschäftszweck nicht versteht, baut es mit hoher Wahrscheinlichkeit das Falsche, auch wenn es technisch korrekt arbeitet.
Lücken aktiv suchen: Jedes Anforderungsdokument hat blinde Flecken. Das ist unvermeidlich, weil Anforderungen von Menschen geschrieben werden, die bestimmte Dinge als selbstverständlich voraussetzen. Die Aufgabe des Entwicklungsteams ist, diese blinden Flecken vor dem Start zu identifizieren. Was steht nicht im Dokument? Welche Fragen hat niemand gestellt? Wo gibt es implizite Annahmen, die nicht überprüft wurden? Eine Stunde kritisches Hinterfragen am Anfang spart leicht zwanzig Stunden Korrekturen am Ende.
Abhängigkeiten vor dem Start klären: Alle externen Abhängigkeiten müssen identifiziert und zeitlich eingeplant sein, bevor die Entwicklung beginnt. Welche Systeme sind betroffen? Welche Teams müssen zuliefern? Gibt es Freigabeprozesse, die den Zeitplan beeinflussen? Ein Feature, das technisch in drei Wochen umsetzbar ist, kann durch eine sechswöchige Wartezeit auf eine Schnittstellendokumentation zum Zwei-Monats-Projekt werden.
Realistisch statt optimistisch schätzen: Das bedeutet nicht, großzügig Puffer aufzuschlagen. Es bedeutet, den wahrscheinlichen Fall zu schätzen statt den Best Case. Rückfragen werden auftreten. Unvorhergesehene Komplexität wird es geben. Parallele Projekte werden Kapazität binden. Eine Schätzung, die das berücksichtigt, ist unbequem, weil sie größer ausfällt. Aber sie ist ehrlich. Und eine ehrliche Schätzung, die am Ende stimmt, baut mehr Vertrauen auf als eine optimistische, die am Ende gerissen wird.
Warum der Start die meiste Aufmerksamkeit verdient
Diese vier Maßnahmen haben einen gemeinsamen Nenner. Sie investieren Zeit am Anfang des Projekts. Eine Woche Analyse und Klärung vor dem Entwicklungsstart fühlt sich wie Verzögerung an. Tatsächlich ist es das Gegenteil.
Projekte, die mit einem gründlich vorbereiteten Start beginnen, haben weniger Korrekturen während der Umsetzung, weniger Scope-Änderungen und weniger Überraschungen am Ende. Die Investition am Anfang spart ein Vielfaches dessen, was sie kostet.
Das ist keine Garantie, dass alles nach Plan läuft. Software-Projekte sind komplex, und Überraschungen gehören dazu. Aber es ist ein erheblicher Unterschied, ob das Team auf einer soliden Grundlage arbeitet und auf Überraschungen reagiert, oder ob es von Anfang an auf unsicherem Boden steht und von einer Klärung zur nächsten springt.
Fazit
Ein Feature, das zwei Monate zu spät kommt, ist selten ein Umsetzungsproblem. Es ist ein Startproblem: Anforderungen, die nicht gründlich genug geklärt wurden. Abhängigkeiten, die niemand identifiziert hat. Schätzungen, die den Best Case als Regelfall angenommen haben. Die Maßnahmen dagegen sind nicht spektakulär, sie bestehen aus sorgfältiger Vorbereitung, kritischem Hinterfragen und ehrlicher Planung. Aber sie machen den Unterschied zwischen Projekten, die im Zeitplan liegen, und solchen, die es nicht tun.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
