Fast fertig!

„Ich bin fast fertig!“

Aus dem Kinderzimmer klingt es überzeugt und ein wenig genervt zugleich. „Ich brauche noch drei Minuten, dann habe ich das Level erreicht und komme zum Essen“, ruft der Sohn. Aus drei Minuten werden zehn, dann zwanzig. Am Ende ist eine halbe Stunde vergangen.

Viele Eltern kennen diese Situation. Und viele Menschen kennen sie auch aus ihrem Berufsalltag:

• „Wir sind fast fertig mit dem Feature.“
• „Die Präsentation braucht nur noch einen kurzen Feinschliff.“
• „Das Angebot ist praktisch raus. Es fehlt nur noch die Unterschrift der Geschäftsleitung.“

„Fast fertig“ klingt nach Sicherheit. Die Erfahrung zeigt allerdings, dass die Aussage oft nicht belastbar ist. Sie beschreibt eher ein Gefühl: Bin praktisch durch und komme gleich zum Abendessen. Kannst schon mal die Screenshots für die Doku des neuen Features machen.

Genau dort beginnt das Problem. Der verbleibende Rest, so klein er auch wirken mag, wird schnell zu einem großen Berg. Im Computerspiel taucht kurz vor Schluss noch ein neues Monster auf. Im Büro ist die Geschäftsführung im Meeting, danach kommen mehr Rückfragen als gedacht, und aus einem letzten Schritt wird eine neue Schleife.

So wird „fast fertig“ zu einer heiklen Phase bei einer Tätigkeit, einem Vorhaben oder einem Projekt. Nicht, weil Menschen systematisch täuschen wollen (außer vielleicht der Sohn), sondern weil am Ende oft das steckt, was vorher wenig sichtbar war: Abstimmung, Abnahme, Tests, Randfälle und viele Details.

Wenn wir Fortschritt verlässlicher einschätzen wollen, reicht ein Gefühl nicht aus. Es braucht Klarheit darüber, was „fertig“ wirklich bedeutet. Und es braucht Methoden, die den Restaufwand sichtbar machen, bevor aus den letzten zehn Prozent die längste Phase wird.

Wenn die letzten 10 Prozent alles verändern

Wer professionell Projekte durchführt und Produkte entwickelt, wird sein Miteinander nicht über eine „Fast fertig“-Aussage koordinieren. Unternehmen planen Budgets, priorisieren Arbeitspakete, steuern Vorhaben und berichten an Stakeholder. Dafür brauchen sie Orientierung. Und deshalb arbeiten viele Organisationen mit definierten Fortschrittsgraden.

• Eine Spezifikation ist zu 50 Prozent formuliert.
• Ein Projekt ist zu 70 Prozent realisiert.
• Ein Feature ist zu 90 Prozent finalisiert.

Prozentwerte schaffen Struktur. Sie ermöglichen Vergleichbarkeit. Und sie vermitteln Kontrolle.

Das Problem beginnt dort, wo diese Zahlen eine Genauigkeit suggerieren, die faktisch nicht existiert. 90 Prozent klingt präzise. Tatsächlich verbirgt sich dahinter oft eine subjektive Einschätzung. Aus einem Gefühl wird eine Kennzahl. Und genau hier entsteht eine systematische Verzerrung.

Diese Verzerrung ist nicht nur ein theoretisches Problem. Sie zeigt sich fast immer dort, wo es weh tut: kurz vor dem Ziel. Denn je näher etwas dem Abschluss kommt, desto eher werden Prozentwerte zu einer Art Beruhigung. Und desto häufiger werden die verbleibenden 10 Prozent unterschätzt.

Genau dieses Muster wird als 90-Prozent-Syndrom bezeichnet.

Es beschreibt die systematische Tendenz, den verbleibenden Restaufwand zu unterschätzen. Die wesentlichen Schritte scheinen erledigt, die größten Hürden genommen. Die verbleibenden 10 Prozent wirken klein, überschaubar und schnell erledigt.

In der Praxis zeigt sich jedoch häufig das Gegenteil. Gerade in der Schlussphase kommt vieles zusammen. Die Integration eines Features klappt nicht reibungslos. Was auf dem Rechner des Entwicklers funktioniert, wirft in der Testumgebung plötzlich Fehlermeldungen. Unklare Akzeptanzkriterien müssen präzisiert werden. Abnahmen bringen Detaildiskussionen mit sich.

Gleichzeitig wächst der Aufwand für Tätigkeiten, die lange nach Routine klingen und doch Zeit fressen: Tests, Dokumentation, Übergaben, letzte Abstimmungen. Manchmal ist die technische Dokumentation eines Features deutlich umfangreicher als bei vergleichbaren Features zuvor, weil neue Randfälle, neue Abhängigkeiten oder neue Konfigurationspfade hinzugekommen sind. Und plötzlich wird sichtbar, dass die letzten 10 Prozent sehr aufwändig sein können.

Die Folgen sind in vielen Organisationen bekannt. Termine geraten ins Wanken, weil nachgelagerte Arbeitspakete nicht starten können. Puffer werden aufgebraucht, ohne dass es im Reporting zunächst dramatisch aussieht. Manchmal beginnen Teams mit Folgearbeiten, weil scheinbar nur noch Kleinigkeiten fehlen. Ändern sich diese Details später, entsteht zusätzlicher Aufwand durch Nacharbeit.

Und nicht zuletzt leidet die Glaubwürdigkeit. Wer wiederholt zu optimistisch schätzt, verliert Vertrauen, auch wenn die Einschätzung nicht aus Nachlässigkeit entstand, sondern aus einer verzerrten Wahrnehmung des Restaufwands.

Das 90-Prozent-Syndrom beschreibt damit kein individuelles Versagen. Es beschreibt ein strukturelles Muster.

Eine pointierte Zuspitzung dieses Musters liefert die sogenannte 90-90-Regel. Sie wird häufig dem Informatiker Tom Cargill zugeschrieben und bringt die Erfahrung vieler Teams auf den Punkt:

• Die ersten 90 Prozent der Arbeit beanspruchen 90 Prozent der Zeit.
• Die verbleibenden 10 Prozent beanspruchen die anderen 90 Prozent.

Was zunächst überzeichnet klingt, beschreibt ein wiederkehrendes Phänomen. Der sichtbare Fortschritt entsteht früh. Der eigentliche Aufwand steckt im Stabilisieren, Integrieren, Testen, Dokumentieren und Absichern.

Die letzten 10 Prozent sind selten der kleine Rest. Sie sind nicht der schwierigste Teil, aber der, bei dem wir uns am häufigsten verschätzen.

Subjektivität und der Versuch der Vereinheitlichung

Warum verschätzen wir uns bei Aufwand und Fortschritt so häufig?

Ein wesentlicher Grund liegt in der Art, wie wir Fortschritt überhaupt bestimmen. Fortschritt ist kein Messwert wie Temperatur oder Gewicht. Er entsteht durch Einschätzung. Und jede Einschätzung ist subjektiv. Was für die eine Person nach 80 Prozent klingt, wirkt für die andere eher wie 60. Manche orientieren sich am bereits investierten Aufwand. Andere am gefühlten Schwierigkeitsgrad. Und einige daran, was noch sichtbar vor ihnen liegt.

Solange Fortschritt auf individuellen Bewertungen basiert, sind Ungenauigkeiten unvermeidlich. Und genau deshalb versuchen Organisationen, diese Subjektivität durch vereinheitlichte Ansätze zu begrenzen. Ein Beispiel dafür ist die 0/100-Methode.

Die Idee der 0/100-Methode ist ebenso einfach wie konsequent: Eine Aufgabe ist entweder nicht erledigt oder erledigt. Dazwischen gibt es keinen prozentualen Zwischenstand. Solange ein Arbeitspaket nicht abgeschlossen ist, hat es einen Fertigstellungsgrad von 0 Prozent. Erst wenn es tatsächlich fertig ist, wird es mit 100 Prozent bewertet.

Der zentrale Effekt dieser Methode liegt nicht in der Genauigkeit, sondern in der Vermeidung von Überoptimismus. Sie verhindert, dass durch Zwischenstände eine zu positive Aussage über den Projektfortschritt entsteht. Es gibt kein 70 Prozent und kein 90 Prozent, das Erwartungen erzeugt, die später nicht gehalten werden.

Genau deshalb gilt die 0/100-Methode vielen als konservativ und sicher. Sie reduziert das Risiko, sich kurz vor Schluss selbst zu beruhigen oder andere zu beruhigen. Gleichzeitig wirkt sie in der Beurteilung des Fortschritts oft pessimistisch, weil sie bereits geleistete Arbeit nicht sichtbar macht, solange das Ergebnis noch nicht vollständig vorliegt. Damit macht die Methode einen klaren Trade-off: weniger gefühlter Fortschritt, dafür weniger Illusion.

Wer dieses Trade-off abmildern will, landet schnell bei einer Variante, die zumindest den Start einer Tätigkeit sichtbar macht: die 20/80-Methode. [1] Sobald ein Arbeitspaket begonnen wurde, gehen 20 Prozent in den Fertigstellungswert ein. Begonnene Arbeit verschwindet nicht komplett im Schatten von 0 Prozent. Gleichzeitig bleibt der Großteil des Fortschritts an etwas gebunden, das wirklich zählt: ein akzeptiertes Ergebnis. Erst mit der Abnahme des Ergebnisses werden die restlichen 80 Prozent zugerechnet.

Das macht die Methode anschlussfähig für die Praxis. Sie wirkt weniger pessimistisch als 0/100, ohne sofort in die nächste Prozentillusion zu rutschen. Allerdings hat diese Entspannung einen Preis. Wenn schon der Beginn den Fertigstellungswert erhöht, entsteht ein Anreiz zur Kosmetik. Wer Fortschritt gut aussehen lassen will, erklärt viele Arbeitspakete als „begonnen“. Der Fortschrittsgrad steigt, der tatsächliche Abschluss rückt jedoch nicht näher.

Noch ein Stück weniger konservativ ist die 50/50-Methode. [2] Sie setzt den Start noch stärker ins Gewicht. Sobald mit einer Aufgabe begonnen wurde, erhält sie 50 Prozent. Erst bei Abschluss wird sie mit 100 Prozent bewertet. Das wirkt deutlich weniger pessimistisch als 0/100. Und es ist für viele leichter zu kommunizieren: begonnen heißt, es passiert etwas. 50 Prozent ist ein sichtbares Signal.

Der Haken liegt auch hier in der Pauschale. 50 Prozent sagt nichts darüber aus, wie viel Arbeit tatsächlich geleistet wurde oder wie viel noch aussteht. Die Methode schafft Orientierung, kann aber leicht eine trügerische Sicherheit erzeugen, wenn „begonnen“ mit „halb fertig“ verwechselt wird.

Hinzu kommt ein Effekt, der das Problem der 20/80-Methode noch verstärken kann. Wenn viele Arbeitspakete parallel begonnen werden, steigt der ausgewiesene Fortschritt schnell an. In der Summe sieht das Vorhaben plötzlich weit fortgeschritten aus, obwohl ein Großteil der Ergebnisse noch lange nicht realisiert sind.

Fortschritt im Vergleich

Alle drei Ansätze verfolgen dasselbe Ziel: Sie wollen subjektive Einschätzungen durch einfache Regeln ersetzen. Doch sie tun dies mit unterschiedlichen Gewichtungen. Je nachdem, wie stark begonnene Arbeit berücksichtigt wird, verändert sich das Bild des Projektfortschritts erheblich. Die Unterschiede sind nicht nur theoretischer Natur. Sie wirken sich unmittelbar auf Reporting, Erwartungsmanagement und Steuerung aus.

Beispiel:

Stellen Sie sich sechs Arbeitspakete (A, B, C, D, E, F) vor. Jedes hat einen geplanten Aufwand in Personentagen (PT), jedes hat einen mittels Zeiterfassung dokumentierten IST-Aufwand. Aus der Differenz ergibt sich der Restaufwand. Wie fällt der Fortschritt im Vergleich der Methoden aus?

Wenn Sie die summierten Personentage der einzelnen Methoden ins Verhältnis zum gesamten Plan-Aufwand setzen, dann bedeutet dies:

• Nach der 0/100-Methode ist das Projekt zu 25 Prozent realisiert. Es steht also scheinbar noch relativ am Anfang.
• Nach der 20/80-Methode ist das Projekt zu 40 Prozent realisiert. Es nähert sich also scheinbar bereits der Halbzeit.
• Und nach der 50/50-Methode ist das Projekt zu 62,5 % realisiert. Es wirkt damit deutlich fortgeschritten, obwohl ein erheblicher Teil der Arbeitspakete noch nicht abgeschlossen sind.

Beeindruckend, wie unterschiedlich diese Zahlen klingen und welche Schlussfolgerungen sie nahelegen, oder?

Und wenn Sie jetzt auf den kumulierten Plan- und Ist-Aufwand schauen, können Sie sehen, dass bereits 66 Prozent des Plan-Aufwands geleistet wurde. Aber was sagt dies über den Projektfortschritt? [3]

Fest steht: Je höher der Anteil begonnener Arbeit gewichtet wird, desto stärker steigt der ausgewiesene Fortschritt. Nicht, weil mehr abgeschlossen wurde, sondern weil Aktivität als Ergebnis gewertet wird. Und genau hier entscheidet sich, welche Methode zu Ihrer Steuerungslogik passt. Die entscheidende Frage lautet daher nicht, welche Zahl „richtig“ ist. Die entscheidende Frage lautet, welche Information Sie für Steuerung und Entscheidungen in Ihrem Kontext wirklich benötigen.

Fortschritt steuern heißt mehr als Prozent zählen

Welche Information für Steuerung und Entscheidungen benötigt wird, hängt vom jeweiligen Kontext ab. Genau deshalb unterscheiden sich die Methoden nicht nur technisch, sondern auch in ihrer Wirkung.

• Die 0/100-Methode priorisiert Verlässlichkeit. Sie zeigt ausschließlich abgeschlossene Ergebnisse. Das erzeugt ein konservatives, belastbares Bild.
• Die 20/80-Methode schafft einen Mittelweg. Sie macht begonnenen Fortschritt sichtbar, hält aber den Großteil des Werts an den tatsächlichen Abschluss gebunden.
• Die 50/50-Methode signalisiert früh Bewegung. Sie macht Aktivität schnell sichtbar, erhöht jedoch das Risiko, dass Fortschritt überschätzt wird.

Die Methoden unterscheiden sich also nicht nur in Zahlen, sondern in ihrer Steuerungslogik. Wer hohe Planungssicherheit benötigt, wird eher konservative Ansätze wählen. Wer frühe Sichtbarkeit von Aktivität braucht, entscheidet sich möglicherweise für eine weniger strikte Logik. Und wer stark aggregiert berichtet, muss sich der Verzerrung bewusst sein, die begonnene Arbeit erzeugt.

Damit ist die Methodenfrage aber noch nicht das ganze Bild.

Methoden zur Ermittlung des Fertigstellungsgrads schaffen Orientierung. Sie legen fest, wie Fortschritt ausgewiesen wird. Sie managen jedoch kein Projekt. Sie ersetzen keine Priorisierung, keine Koordination von Abhängigkeiten und keine Klärung dessen, was „fertig“ konkret bedeutet.

Ob eine Methode in der Praxis trägt oder nur ein gut aussehendes Reporting erzeugt, entscheidet sich daher an anderen Stellen.

Hebel 1: Arbeitspakete so schneiden, dass Fortschritt beobachtbar wird

Große, unscharf abgegrenzte Arbeitspakete sind ein Nährboden für falsche Fortschrittsbilder. Je größer die Einheit, desto stärker wird Fortschritt zur Interpretation.

Kleine, klar definierte Arbeitspakete reduzieren diesen Interpretationsspielraum. Sie zwingen zu konkreten Zusagen, machen Blockaden früher sichtbar und verhindern, dass ein einzelnes „riesiges Paket“ wochenlang bei einem gefühlten Zwischenstand hängen bleibt.

Genau hier entfalten Prozentmethoden ihre Wirkung. Denn ob 0/100, 20/80 oder 50/50: Sie funktionieren deutlich besser, wenn das, was bewertet wird, überschaubar und klar abgegrenzt ist.

Hebel 2: Definition of Done, damit „fertig“ nicht verhandelbar bleibt

Einer der häufigsten Gründe für teure Schleifen ist nicht fehlende Leistung, sondern fehlende Eindeutigkeit. „Fertig“ klingt klar. Ist es aber selten.

• Für die eine Person bedeutet fertig: Code geschrieben.
• Für die andere: integriert.
• Für die nächste: getestet.
• Und für diejenige, die abnimmt: dokumentiert, überprüft, nutzbar, freigegeben.

Eine Definition of Done schafft hier einen gemeinsamen Referenzpunkt. Sie macht transparent, welche Kriterien erfüllt sein müssen, damit ein Arbeitspaket als abgeschlossen gilt. Damit wird „fast fertig“ weniger zur Perspektive und stärker zu einem überprüfbaren Zustand.

Nebenbei stabilisiert sie auch die Methodenlogik. Denn egal ob 0/100 oder 20/80: Ohne Klarheit darüber, was als Abschluss zählt, wird jede Prozentzahl wieder zur Verhandlung.

Hebel 3: Abhängigkeiten sichtbar machen, bevor sie am Ende explodieren

Die Schlussphase ist so oft teuer, weil dort viele Abhängigkeiten zusammenlaufen. Schnittstellen, externe Zuarbeit, Freigaben, Infrastruktur, Testumgebungen, Security-Prüfungen, Stakeholder-Feedback.

Wenn diese Abhängigkeiten nicht sichtbar sind, wirkt Fortschritt stabil, bis er plötzlich ins Stocken gerät. Dann entsteht genau das Muster aus dem ersten Kapitel: Die letzten 10 Prozent sind nicht schwierig, aber sie sind voller Rückkopplungen.

Ein praktischer Unterschied ist deshalb, ob Projekte Abhängigkeiten als Randthema behandeln oder als integralen Bestandteil der Steuerung. Wer sie früh klärt, schützt sich vor Überraschungen am Ende.

Hebel 4: Nicht nach Prozent fragen, sondern nach Restarbeit

Die Frage „Wie weit seid ihr?“ lädt zu Prozentzahlen ein. Und Prozentzahlen laden zu Optimismus ein.

Eine robustere Frage lautet: „Was fehlt noch konkret, bis es wirklich fertig ist?“ Diese Frage zwingt zu Substanz. Sie macht Restaufwand sichtbar, bevor er zur Überraschung wird. Und sie verändert die Kommunikation im Team, weil sie nicht auf ein Gefühl zielt, sondern auf eine Liste offener Punkte.

Hier zeigt sich das Zusammenspiel von Methode und Praxis: Prozentwerte strukturieren die Darstellung. Die konkrete Restarbeit strukturiert die Steuerung. Erst wenn beides zusammenkommt, wird aus Fortschrittszahlen eine belastbare Grundlage für Entscheidungen.

Von fast fertig zu wirklich fertig

„Fast fertig“ ist ein Ausdruck, den wir vermutlich alle schon oft benutzt haben. Im privaten Kontext mag das bisweilen nachvollziehbar sein. Im beruflichen Kontext ist es jedoch ungenau. Da individuelle Schätzungen zwangsläufig subjektiv sind, versuchen Unternehmen, Fortschritt bei Arbeitspaketen, Vorhaben oder Projekten zu vereinheitlichen. Sie nutzen Methoden wie 0/100, 20/80 oder 50/50.

Diese Ansätze setzen unterschiedliche Schwerpunkte. Die 0/100-Methode priorisiert Verlässlichkeit, wirkt dafür häufig konservativ. Die 20/80-Methode bildet begonnenen Fortschritt ab, bindet den Großteil des Werts aber an ein akzeptiertes Ergebnis. Die 50/50-Methode macht Aktivität früh sichtbar, verstärkt jedoch den Effekt, dass viele begonnene Pakete in Summe ein optimistisches Gesamtbild erzeugen können.

Natürlich nutzen auch viele Organisationen eigene Methoden oder angepasste Regeln, um genau die Informationen zu aggregieren, die in ihrem Kontext für Steuerung und Entscheidungen hilfreich sind.

Wichtig ist dabei: Methoden schaffen Orientierung, aber sie steuern kein Projekt. Tragfähig wird Fortschrittssteuerung erst durch ergänzende Hebel. Klar geschnittene Arbeitspakete, eine eindeutige Definition of Done, sichtbar gemachte Abhängigkeiten und die konsequente Frage nach konkreter Restarbeit reduzieren die Lücke zwischen Zahl und Realität.

Und falls doch kurz vor Schluss ein neues Monster auftaucht, wird das Abendessen für den Sohn eben kalt.

Hinweise:

[1] Hier finden Sie weitere Details zur 20/80-Methode.
[2] Hier finden Sie weitere Details zur 50/50-Methode.
[3] Da Aufwand ungleich Fortschritt ist, lassen sich einige Aussagen NICHT exakt aus den Werten ableiten: Wir wissen nicht, ob das Projekt zu 66 % fertig ist, ob noch 34 % der Arbeit fehlen oder ob das Projekt im Plan liegt. Nur wenn der Arbeitsfortschritt proportional zum Aufwand wäre, könnte man sagen: Das Projekt ist zu 66 % abgeschlossen.

Hier finden Sie Informationen über steigende oder sinkende Fertigstellungsgrade.

Und hier finden Sie einen interessanten Artikel über Slicing Work als essentielle Fähigkeit für Agilität. Sehr lesenswert.

Wollen Sie als Multiplikatorin oder Meinungsführer über Fortschrittsgrade in Vorhaben oder Projekten diskutieren? Dann teilen Sie diesen Beitrag in Ihren Netzwerken.

Michael Schenkel hat weitere Beiträge im t2informatik Blog veröffentlicht, u. a.: