Freitag, 16:20 Uhr. Der Projektleiter schaut in die Zeiterfassung und stellt fest: Das Team hat 78 von 100 geplanten Stunden verbraucht. Fortschritt laut letztem Statusmeeting: ungefähr 60 Prozent. Ungefähr. Er schließt den Laptop, fährt ins Wochenende und hofft, dass sich das irgendwie ausgeht. Am Montag stellt sich heraus: Es waren keine 60 Prozent. Eher 45.

Solche Momente kennt jeder, der in einer Agentur oder bei einem IT-Dienstleister arbeitet. Die Frage ist nur, ob man sie früh genug bemerkt – oder erst bei der Schlussrechnung.

Die Lücke zwischen Bauchgefühl und Realität

McKinsey und die Universität Oxford haben in einer viel zitierten Studie IT-Projekte mit Budgets über 15 Millionen Dollar untersucht. Ergebnis: Im Schnitt lagen die Kosten 45 Prozent über Plan, der Zeitrahmen wurde um 7 Prozent überzogen – und der gelieferte Wert lag 56 Prozent unter den Erwartungen. Jedes sechste Projekt entpuppte sich als finanzieller Black Swan mit über 200 Prozent Kostenüberschreitung.

Jetzt kann man sagen: 15-Millionen-Projekte haben mit einer 20-Personen-Agentur wenig zu tun. Stimmt teilweise. Aber das Muster ist identisch. Die Zahlen skalieren runter, die Mechanik bleibt gleich. Wer 100 Stunden für ein Webprojekt einplant und nach 80 Stunden merkt, dass er bei der Hälfte steht, hat kein anderes Problem als ein Konzern mit Millionenbudget. Nur weniger Puffer.

Projektcontrolling ist der Versuch, diese Lücke zwischen Bauchgefühl und Realität systematisch zu schließen. Kein Hexenwerk. Kein SAP-Projekt. Einfach: regelmäßig hinschauen, vergleichen, nachsteuern.

Warum die Standardmethoden bei Dienstleistern nicht greifen

Die klassische Lehrbuch-Definition von Projektcontrolling – Soll-Ist-Vergleich, Earned Value Analyse, Meilensteintrendanalyse – stammt aus einer Welt von Bauprojekten und Großindustrie. DIN 69901 definiert es als die "Sicherung des Erreichens der Projektziele durch Soll-Ist-Vergleich, Feststellung der Abweichungen, Bewerten der Konsequenzen und Vorschlagen von Korrekturmaßnahmen."

Klingt vernünftig. Ist es auch – im Prinzip.

Das Problem: Agenturen und IT-Dienstleister arbeiten unter Bedingungen, die diese Methoden nicht so richtig vorgesehen haben. Kein fester Scope, weil der Kunde nach dem zweiten Sprint neue Ideen hat. Kein klarer Fertigstellungsgrad, weil Software nicht wie ein Gebäude von unten nach oben wächst. Und kein einzelnes Großprojekt, sondern zwölf parallele Projekte, die sich gegenseitig Ressourcen wegnehmen.

Wer schon mal versucht hat, eine klassische Earned Value Analyse auf ein agiles Webentwicklungsprojekt anzuwenden, weiß, wovon ich rede. Die Methode setzt voraus, dass man den Gesamtumfang kennt und den Fortschritt in Prozent messen kann. Bei einem Festpreis-Relaunch mit wechselnden Anforderungen ist beides Illusion.

Was stattdessen zählt

Für Dienstleister ist Projektcontrolling weniger eine Methode und mehr eine Haltung: Wie viel von meinem Budget ist verbraucht? Wie viel Arbeit ist wirklich erledigt? Und stimmt das Verhältnis?

Das klingt banal. Aber in der Praxis scheitern die meisten nicht an fehlenden Methoden, sondern daran, dass niemand die zwei Fragen regelmäßig stellt. Die Projektzeiterfassung läuft – aber keiner schaut drauf. Das Budget steht im Angebot – aber keiner rechnet mit.

Die Kennzahlen, die bei Dienstleistern wirklich zählen

Vergiss das magische Dreieck aus den Lehrbüchern für einen Moment. Nicht weil es falsch ist, sondern weil es zu abstrakt ist. Hier sind die Zahlen, die bei einer 10- bis 50-Personen-Agentur den Unterschied machen:

Budget Burn Rate

Wie schnell verbrenne ich das Budget im Verhältnis zum Fortschritt? Beispiel: Ein Projekt hat 100 Stunden Budget. Nach zwei Wochen sind 40 Stunden gebucht und das Projekt ist zu 35 Prozent fertig. Die Burn Rate liegt über Plan – aber noch nicht dramatisch. Wäre das Projekt erst zu 20 Prozent fertig, sollten die Alarmglocken längst läuten.

Diese eine Zahl – Stundenverbrauch geteilt durch Fertigstellungsgrad – ist für die meisten Teams informativer als jede Earned-Value-Formel.

Deckungsbeitrag pro Projekt

Was bleibt vom Projekt übrig, wenn man die tatsächlichen Personalkosten abzieht? Viele Agenturen wissen das erst Monate nach Projektabschluss. Oder gar nicht. Wer seine Zeiterfassung mit dem Controlling verknüpft, sieht diese Zahl in Echtzeit. Und stellt manchmal fest: Das Vorzeigeprojekt, auf das alle stolz sind, frisst still und leise die Marge des Quartals.

Forecast-Genauigkeit

Wie nah waren die Schätzungen an der Realität – nicht bei einem einzelnen Projekt, sondern im Durchschnitt über alle Projekte? Diese Meta-Kennzahl zeigt, ob das Schätzproblem systematisch ist. Liegt der Schnitt bei 130 Prozent Überschreitung, schätzt das Team nicht schlecht – es schätzt systematisch zu niedrig. Das ist ein anderes Problem als einzelne Ausreißer.

Projekte mit strukturiertem Controlling erleben laut PMI deutlich weniger Scope Creep. Ohne systematische Überwachung driftet der Scope fast immer – die Frage ist nur, wann man es bemerkt.

Fünf Muster, die Projekte leise töten

Soweit ich das nach fünfzehn Jahren Agentur- und Softwaregeschäft beurteilen kann, sind es selten die großen Katastrophen, die Projekte unrentabel machen. Es sind Muster, die man erst sieht, wenn man regelmäßig hinschaut.

Das erste ist das Freitag-Problem. Stunden werden am Freitagabend nachgetragen, aus dem Gedächtnis. Was Mittwoch drei Stunden gedauert hat, wird zu "ungefähr zwei" – weil sich niemand mehr genau erinnert. Über ein Quartal summiert sich das zu erstaunlichen Differenzen.

Daneben gibt es den Optimismus-Bias im Statusmeeting. "Wir sind fast fertig" ist der gefährlichste Satz im Projektgeschäft. Meistens stimmt er nicht. Nicht weil jemand lügt, sondern weil Menschen den Restaufwand chronisch unterschätzen. Die 90-Prozent-Falle: Die letzten zehn Prozent brauchen genau so lange wie die ersten neunzig.

Dann: Scope Creep ohne Preisschild. Der Kunde fragt, ob man "noch schnell" das Kontaktformular anpassen kann. Klar, kein Problem. Zwei Stunden. Dann werden es vier, weil das CMS nicht mitmacht. Diese Miniänderungen addieren sich – wir haben das bei IT-Projekten analysiert und die Mechanik ist immer dieselbe.

Ein Muster, das fast nie auf dem Radar auftaucht: interne Projekte ohne Budget. Das Redesign der eigenen Website, die Migration des CRM – niemand kontrolliert sie, weil es keine Rechnung gibt. Sie laufen einfach. Manchmal monatelang. Und binden Kapazität, die in Kundenprojekten fehlt.

Und schließlich die Excel-Falle. Das Controlling findet in einer Tabelle statt, die der Projektleiter pflegt, wenn er Zeit hat. Also: nie. Am Ende des Quartals versucht jemand, aus Zeiterfassung, Angeboten und Rechnungen eine Zusammenfassung zu basteln. Das ist kein Controlling. Das ist Archäologie.

Ein pragmatischer Fahrplan: Projektcontrolling in vier Wochen einführen

Ich bin skeptisch gegenüber großen Rollouts. Bei eins+null, meiner früheren Firma, haben wir zweimal versucht, Controlling "richtig" einzuführen – mit Templates, Schulungen, dem ganzen Programm. Beide Male ist es nach sechs Wochen eingeschlafen.

Was funktioniert hat: Klein anfangen und den Nutzen sofort sichtbar machen.

In der ersten Woche reicht eine einzige Zahl pro Projekt. Jeder Projektleiter schaut freitags auf gebuchte Stunden vs. Budget. Keine Analyse, keine Berichte – nur die Zahl. Wer im Multiprojektmanagement steckt, macht das für seine drei bis fünf Projekte. Dauert zehn Minuten.

Ab Woche zwei bauen wir eine Ampel ein. Grün: Stundenverbrauch und Fortschritt passen zusammen. Gelb: Abweichung, aber noch steuerbar. Rot: Ohne Gegenmaßnahme überschreiten wir das Budget. Drei Farben, keine Philosophie.

In der dritten Woche kommt das 15-Minuten-Review dazu – einmal pro Woche sitzt das Team zusammen und geht die roten und gelben Projekte durch. Was ist passiert? Was machen wir? Wer redet mit dem Kunden? Kein Statusmeeting, kein PowerPoint. Stehend wenn nötig.

Nach vier Wochen dann der Rückblick: Was hat sich verändert, seit wir hinschauen? Meistens ist die Antwort: Wir haben Probleme zwei Wochen früher erkannt als vorher. Das reicht als Motivation, um weiterzumachen.

Der Rest – Dashboard-Automatisierung, Deckungsbeitragsrechnung, Forecast-Tracking – kommt, wenn die Basis steht. Nicht vorher.

Die unbequeme Wahrheit über Controlling

Projektcontrolling hat einen Nachteil: Es zeigt dir Dinge, die du vielleicht nicht sehen willst. Dass dein Lieblingsprojekt unrentabel ist. Dass der beste Entwickler im Team – der, auf den alle setzen – ausgerechnet die meisten Stunden auf Projekte bucht, die schon über Budget sind, weil nur er die Probleme reparieren kann. Oder dass die alte Standardschätzung von 80 Stunden für ein Webprojekt seit drei Jahren nicht mehr stimmt, aber niemand hat sie aktualisiert.

Das ist vermutlich der Grund, warum so wenige Dienstleister es konsequent machen. Nicht weil die Tools fehlen oder die Methoden zu kompliziert sind. Sondern weil Nicht-Wissen manchmal bequemer ist als Wissen.

Aber die Zahlen verschwinden nicht, nur weil man nicht hinschaut. Sie tauchen spätestens beim Jahresabschluss wieder auf – und dann ist es für Korrekturen zu spät.

Wir haben Leadtime unter anderem deshalb gebaut, weil wir bei eins+null selbst zu oft erst hinterher wussten, was schiefgelaufen war. Nicht weil wir klüger sind – sondern weil wir es leid waren, immer erst am Ende die Wahrheit zu erfahren.