Basisplan und Soll-Ist-Vergleich

Der Soll-Ist-Vergleich wird gern als Kontrollinstrument erklärt. Er ist aber zuerst ein Gedächtnis: Er hält fest, was einmal vereinbart war, damit man später sagen kann, was sich geändert hat — und ob absichtlich.

Das Beispiel ist die Entwicklung eines Kundenportals, 1. Oktober 2026 bis 19. Januar 2027, vier Phasen von Konzept über Entwicklung und Test bis zur Einführung.

Schritt 1: Der Stand, gegen den gemessen wird

#

Bild 1 von 4 — Der Ausgangspunkt. Der Basisplan friert den Stand ein, gegen den später gerechnet wird — vier Phasen von Konzept über Entwicklung und Test bis zur Einführung, gebunden an fünf Meilensteine. Solange sich danach nichts ändert, bleibt jeder Vergleich leer; genau deshalb steht am Anfang das Einfrieren und nicht das Bild.

Solange danach nichts passiert, bleibt jeder Vergleich leer — und ein leeres Formular erklärt nichts. Deshalb braucht die Vorführung einen zweiten Schritt: eine Änderung, die jemand aus einem Grund vornimmt.

Schritt 2: Der Grund für die Änderung

#

Bild 2 von 4 — Der Befund, der die Änderung begründet: Am 8. Dezember beginnen zwei Testvorgänge gleichzeitig — Integrationstest und Last- und Sicherheitstest, je acht Personentage mit zwei Testanalysten. Vier gefragt gegen drei verfügbare, vier Tage lang, Unterdeckung −4. Beide Vorgänge sind unkritisch und tragen je 168 Stunden Puffer. Das ist keine Katastrophe, sondern genau die Sorte Konflikt, die man mit einer Terminverschiebung auflöst.

Schritt 3: Die Änderung

#

Bild 3 von 4 — Die Planänderung, um die es geht: Der Last- und Sicherheitstest beginnt am 15. statt am 8. Dezember. Mehr war nicht nötig — der Bedarf sinkt von 4 auf 2, die Spalte Unterdeckung bleibt leer, und im Diagramm liegen die blauen Balken wieder unter der grünen Linie. Vierzehn Tage wären übrigens nicht gegangen: Dann hätte ein Zwangstermin wandern müssen, und die Terminierung bricht mit einem Konflikt ab, statt ihn zu verstecken.

Schritt 4: Was der Vergleich daraus macht

#

Bild 4 von 4 — Und hier zahlt sich der Basisplan aus. Die Verschiebung war eine bewusste Entscheidung — der Vergleich hält sie fest, ohne dass jemand mitschreiben muss: eine Zeile mit +7 Tagen, alle anderen leer. Auch der Endtermin der Phase steht unverändert auf dem 28. Dezember, weil die Verschiebung im Puffer blieb. So unterscheidet man später eine gewollte Änderung von einem Verzug — und kann beides belegen.

Warum diese Reihenfolge nicht beliebig ist

#

Drei Fehler kann man beim Soll-Ist-Vergleich machen, und zwei davon fallen erst Monate später auf:

1. Kein Basisplan. Dann gibt es keine Soll-Seite, und die Ansicht zeigt Gedankenstriche. Kein Vergleich, nur eine Liste.
2. Basisplan zu spät. Wer ihn erst anlegt, nachdem schon umgeplant wurde, friert eine Änderung als Vereinbarung ein. Der Vergleich sieht danach sauber aus und ist wertlos.
3. Änderung ohne Begründung. Eine Verschiebung, die niemand erklären kann, ist im Vergleich nicht von einem Verzug zu unterscheiden. Hier steht die Begründung im Bild daneben: Sie hat einen Kapazitätskonflikt aufgelöst.

Was passiert, wenn nicht geplant, sondern gerechnet wird — Stichtag, Fortschritt, Verzug —, steht auf Fortschritt und Stichtag. Das ist die andere Hälfte derselben Funktion und bewusst ein anderes Bild.

Was passiert, wenn ein Vorgang erst nach dem Einfrieren entsteht — ein Strich statt eines Solltermins —, und wie der dynamische Basisplan das auffängt, steht unter Dynamischer Basisplan.

Wie Rillsoft Project Soll und Ist gegeneinander führt, steht auf der Produktseite zum Projektcontrolling in der Rillsoft Cloud. Zurück zur Übersicht IT-Dienstleister.