Planung ohne Daten ist Glücksspiel

Vom Albtraum zur Methode

Manchmal merkt man erst mittendrin, wie weit man vom Kurs abgekommen ist. Im Oktober 2022 startete ich ein Projekt, das im November 2023 abgeschlossen sein sollte. Doch was als überschaubares Unterfangen begann, entwickelte sich rasch zu einem echten Albtraum. Bis Mai 2023 waren erst 30 % erledigt, und die Erkenntnis traf mich wie ein Blitz. Mit wöchentlichen 80-Stunden-Schichten kämpften wir uns voran, um den Start der Inbetriebnahme Anfang September 2023 zu retten. Die fehlende Dokumentation und nicht vorhandene Tests führten zu einem Marathon aus Bugfixes, der uns auch in den folgenden Wochen bei konstanten 80 Stunden bis zur Abnahme im November begleitete. Nur mit Ach und Krach haben wir es noch rechtzeitig geschafft und am Ende fast doppelt so viele Stunden wie geplant aufgewendet. Diese Stunden fehlten dann natürlich woanders. Die Nachwehen spürten wir demnach noch bis Mitte 2024. Am Boden der Fehlplanung angekommen und trotz massivem Workload in anderen Projekten führten wir gleich im Anschluss ein umfangreiches Zeittracking- und Planungstool ein. Die Einführung dauerte im Wesentlichen nur zwei Monate, Dezember 2023 und Jänner 2024, und war eine der besten Entscheidungen, die wir bei AutoLab jemals getroffen haben.

Alles, was ihr im Folgenden seht, wurde im Wesentlichen von meiner Frau und mir an acht Wochenenden aufgebaut. Es braucht also keinen riesigen organisatorischen Kraftakt, um enorme Verbesserungen zu erzielen.

Lange Rede, kurzer Sinn: Schauen wir uns an, wie uns das gelungen ist und wie auch ihr es umsetzen könnt.

Einführung von Tools und Methoden

Da wir ohnehin bereits die Atlassian-Produkte verwendeten

• Confluence als Wissensdatenbank
• Jira für die Projektplanung
• und Bitbucket für unsere Codeverwaltung

lag es für uns auf der Hand, diese Tools zu nutzen. Leider hatten wir Jira bis dahin nur rudimentär verwendet, mehrheitlich lediglich zum Zuweisen von Aufgaben. Was komplett fehlte, war eine schnelle Möglichkeit, SOLL-IST-Vergleiche zwischen geplanten und bereits gebuchten Stunden innerhalb von Projekten durchzuführen. Ebenso gab es keinerlei Übersicht über die Gesamtauslastung und Kapazität. Noch kritischer war, dass sich die geplante Auslastung pro Mitarbeiter nicht per Knopfdruck abrufen ließ.

Ich wollte ein System, welches mir folgende Dinge per Knopfdruck liefert:

• Wie viele Stunden wurden insgesamt im angefragten Zeitabschnitt für Kundenprojekte aufgebracht? Kundenprojekte sind dabei Projekte, die wir zu einem Fixpreis verkauft haben. Mehraufwand bedeutet daher unmittelbaren wirtschaftlichen Verlust.
• Wie viele Stunden wurden pro Projekt aufgebracht?
• Wie viele Stunden wurden für Beratung, Dienstleistung oder Support aufgebracht? Das sind Leistungen, die uns der Kunde stundenbasiert bezahlt.
• Die Auflistung dieser Dienstleistungsstunden muss per Knopfdruck inklusive Detailbeschreibung exportiert werden können, sodass man sie 100 % transparent an den Kunden weitergeben kann.
• Wie viele Stunden wurden für interne Entwicklungen wie Libraries oder Prototypen verwendet? Das sind Stunden, die langfristig wertvolle Entwicklungen für den Unternehmenserfolg darstellen, jedoch intern getragen werden müssen. Der Klassiker ist hier Forschung und Entwicklung.
• Wie viele Stunden wurden für allgemeine Tätigkeiten „verschwendet“?
• Wie unterteilen sich diese allgemeinen Stunden konkret? Also wie viel wurde für Marketing, Mitarbeitersuche, Projektanfragen etc. aufgebracht?

Wir unterteilten demnach alle Buchungen auf folgende Kategorien:

• Projekte
  • Projekt A
  • Projekt B
  • …
• Dienstleistungen
  • Für Kunde A
  • Für Kunde B
  • …
• Allgemeine Stunden
  • Allgemeine Aufgaben
  • Mitarbeitersuche
  • Marketing
  • Projektanfragen
  • Vertrieb
  • Schulung anderer
  • Schulungen & Onboarding
• Eigenentwicklungen
  • Internes Projekt A
  • Internes Projekt B
  • …

Somit haben wir vier Hauptkategorien mit jeweils mehreren Unterkategorien.

Die Frage, die sich jetzt noch stellt: Wie setzen wir das nun geeignet in Jira um?

Erstellung eines Project-Templates

In Jira verwenden wir Scrum-Projekte (siehe Space templates/Software development/Scrum):

Ich kann an dieser Stelle nur jedem empfehlen, sich meinen Post Perfektionismus als Gift durchzulesen und zudem meiner Buchempfehlung zu folgen und sich das Buch “Scrum: The Art of Doing Twice the Work in Half the Time” von Jeff Sutherland und J.J. Sutherland zu holen. Dieser Artikel wird ohnehin eine beträchtliche Länge erreichen, dementsprechend werde ich nicht detaillierter auf Scrum eingehen. Die anschließende Buchungsanalyse mittels Tempo würde ohnehin auch mit anderen Projektarten in Jira funktionieren.

Wenn man sich spezielle Workflows wünscht, empfiehlt es sich, ein eigenes Template für die Projekte zu erstellen. Wir verwenden etwa statt

• TODO
• In Progress
• DONE

die Arbeitsschritte

• TODO
• In Progress
• In Review
• DONE

Solche und weitere Einstellungen befinden sich bei uns im Projekt ProjectTemplate. Beim Erstellen eines neuen Jira Projekts „erben“ wir von diesem:

Und schon ist ein neues Projekt mit unseren gewünschten Standardeinstellungen erstellt.

Stunden richtig zuordnen

Ein konkretes Projekt muss nun nur noch einer unserer vier Hauptkategorien zugeordnet werden. Dazu gehen wir im jeweiligen Project, bzw. mittlerweile in Jira auch Space genannt, auf die “Space Settings” und weisen dem Projekt eine unserer vier Hauptkategorien zu:

Das war dann auch schon der ganze Zauber. Später können wir nach unseren Projektkategorien filtern und so Auswertungen erstellen.

Bei den allgemeinen Stunden machen wir es uns noch leichter und realisieren die Unterteilung mittels Epics in einem Projekt „Allgemeine Stunden“.

Im Anschluss muss man sich noch im Atlassian Marketplace die Applikation Tempo holen, und schon kann die Planung losgehen.

Zeit und Kapazität planen

Natürlich muss man im Anschluss auch in Tempo noch einige Einstellungen treffen. So muss man etwa die gesetzlichen Feiertage je nach Verwendungsland eintragen sowie die jeweiligen Arbeitszeitmodelle der Mitarbeiter definieren. In unserem Fall haben wir derzeit etwa zwei verschiedene Teilzeitmodelle für die Studenten, alle anderen sind im Vollzeitmodell. Ich gehe hier nicht näher darauf ein, da meine Frau und ich uns damals mithilfe der Unterlagen und Guides von Tempo sehr gut zurechtgefunden haben. Man muss diese einfach “abarbeiten”.

Nachdem die Applikation erfolgreich eingerichtet ist, kann man mit der Planung beginnen. Dazu geht man einfach ins jeweilige Projektboard und legt dort Epics und Issues an:

Diesen Issues muss man dann drei Dinge zuweisen, damit Tempo sie auch übernimmt:

1. Wer erledigt die Aufgabe?
2. Bis wann muss die Aufgabe erledigt werden?
3. Wie viele Stunden werden dafür geschätzt?

Hier ein Beispiel, wie ich mir selbst für die erste Grobplanung einen Zeitblocker zugewiesen habe:

Später muss das natürlich in eine Feinplanung übergehen. Meiner Meinung nach liegt die Maximalgrenze für einen einzelnen Task bei 80 h. Ich würde jedoch eher 40 h empfehlen.

Hat man diese drei Dinge erledigt, kann man das Ganze auch bereits in Tempo importieren:

Macht man das konsequent für alle Projekte, ist die Kapazitätsplanung ein Kinderspiel. Man geht in Tempo einfach auf „Reports“ und wählt dort „Planned Time“ aus:

Anschließend wählt man noch den gewünschten Beobachtungszeitraum, und fertig ist der Bericht:

Da ich die allgemeinen Stunden nie extra plane, ist meine Empfehlung, die Auslastung grundsätzlich nie über 80 % zu planen. Aufgrund eines Ausfalls durch einen Krankenhausaufenthalt wurden den meisten Mitarbeitern in diesem Monat mehr Stunden eingeplant, als ihre Kapazität zulässt. Das soll natürlich die Ausnahme bleiben. Dank Tempo erkennt man das aber frühzeitig und kann gezielt darauf reagieren.

Detailliertes Reporting

Hat man den Workflow erst einmal aufgesetzt, ist alles andere nur noch einen Knopfdruck entfernt. Nun kann man die Früchte der Arbeit ernten und erhält ein detailliertes Reporting.

Was früher mehrere Stunden und viele manuelle Schritte gebraucht hat, passiert heute mit einem einzigen Klick: Alle vier Kategorien und ihre Stundenbuchungen werden automatisiert und übersichtlich dargestellt:

Mit einem weiteren Knopfdruck exportiere ich diese nach Excel und übertrage sie mit einem Skript automatisch in meinen jeweiligen Monatsabschluss, den ich in PowerPoint aufbereite.

Anmerkung: Die y-Achse zeigt bewusst keine Absolutwerte, da ich diese nicht unbedingt teilen möchte und sie für den Artikel keine Rolle spielen.

Früher basierten meine Entscheidungen oftmals auf Gefühl, jetzt basieren sie auf klaren Fakten und Daten. Was ich hier auf jeden Fall zur Kenntnis nehmen musste:

Mein subjektives Bauchgefühl deckt sich oft nicht mit den tatsächlichen Daten. Da wir ein sehr kleines technisches Team sind und viel organisatorischer Overhead von der PMT Holding übernommen wird, zu der AutoLab gehört, hatte ich etwa den Eindruck, dass allgemeine Stunden nicht so viel Zeit in Anspruch nehmen. Zu meiner großen Überraschung musste ich aber feststellen, dass sie im Geschäftsjahr 24/25 sage und schreibe 22,7 % aller Stunden ausmachten. Meiner Meinung nach war das viel zu viel und es musste sich etwas ändern. Im Anschluss haben wir uns etwa angesehen, welche Marketingtätigkeiten wirklich Reichweite bringen oder auch, wie wir das Onboarding besser in bestehende Projekte einbinden können. Viele kleine Stellschrauben wurden gestellt. Das Ergebnis kann sich sehen lassen. Den Anteil der allgemeinen Stunden an der Gesamtstundenanzahl konnten wir von 22,7 % auf 14,3 % senken.

Aufgrund der Daten konnten wir eine weitere Schwachstelle identifizieren: Teilweise verbrachten wir zu viele Stunden mit Projektanfragen. Vor allem in der Bildverarbeitung hat man oft Anfragen in einer sehr frühen Phase, in der noch kein Lastenheft steht und es eigentlich nur um einen ersten PoC geht. Die möglichen Projekte sind demnach Kleinstprojekte mit geringem Umsatz. Wenn man dann bereits für die Bearbeitung der Anfrage mehrere Tage investiert, macht man sogar Verlust, selbst wenn man den Auftrag bekommt. Hier brauchte es also auch eine Änderung.

Folgende Stellschrauben wurden gesetzt:

• Definieren eines standardisierten Anfrageprozesses, um früh das jeweilige Potenzial erkennen zu können
• Ausarbeiten von Fragenkatalogen, um schneller gemeinsam mit dem Kunden zu sauberen Requirements zu kommen
• Schnellere Schätzungen auf Basis von Erfahrungswerten (dank Jira/Tempo)

Mit diesen Ansätzen konnten wir die Bearbeitungszeit pro Projektanfrage um 60,2% reduzieren!

In meinem Jahresbericht finden sich natürlich noch zahlreiche andere Beispiele und Analysen. Die beiden genannten Beispiele sind aber sicher die eindrucksvollsten und jene, bei denen wir uns im wahrsten Sinne Zeit und Geld sparen.

Warum wir alle schlecht planen – und was wirklich hilft

Wie eingangs erwähnt, war die Intention hinter unserer Zeitbuchung und dem Tracking, realistischere Einschätzungen zu bekommen. Die zuvor gezeigten Analysetools haben ebenfalls einen enormen Mehrwert, aber eine zielgerichtete Planung kann entscheidend für den Fortbestand eines Unternehmens sein. Wenn man sich bei einem großen Projekt komplett verkalkuliert, können die wirtschaftlichen Schäden enorm sein.

Wieder einmal darf ich an dieser Stelle auf mein absolutes Lieblingsbuch “Schnelles Denken, langsames Denken” verweisen. Darin wird eindrucksvoll gezeigt, wie unglaublich schlecht wir in Schätzungen und Planungen sind. Meine persönliche Erfahrung aus dem eingangs erwähnten Projekt deckt sich somit auch mit der wissenschaftlichen Lehrmeinung. Einige Beispiele aus dem Buch (aus dem Kapitel 23, Die Außensicht):

• Beim Bau des schottischen Parlaments wurde ursprünglich mit rund 40 Millionen Pfund gerechnet. Über mehrere „finale“ Schätzungen hinweg stiegen die Kosten Schritt für Schritt an – am Ende lag man bei über 400 Millionen Pfund.
• Eine Analyse von Bahnprojekten über mehrere Jahrzehnte zeigt: In über 90 % der Fälle wurden die Passagierzahlen zu hoch eingeschätzt. Im Schnitt lagen die Prognosen mehr als doppelt über der Realität, während die Kosten im Durchschnitt rund 45 % über Plan lagen.
• Selbst bei privaten Projekten zeigt sich das gleiche Muster: US-Hausbesitzer schätzten ihre Küchenrenovierungen im Schnitt auf etwa 19.000 Dollar – tatsächlich ausgegeben wurden rund 39.000 Dollar.

Wie sich zeigt, unterschätzen wir Menschen systematisch den Aufwand von Projekten. Genauso ging es mir anfangs bei AutoLab.

Glücklicherweise wird in “Schnelles Denken, langsames Denken” und auch im Folgebuch “Noise” beschrieben, wie man sich vor solchen Fehleinschätzungen schützen kann. Das Thema ist ein eigenes Rabbit Hole – man kann problemlos Tage damit verbringen. Ich halte es daher kurz und konzentriere mich auf die aus meiner Sicht effektivste Methode: Schätzen anhand von Basisraten.

Die Idee ist simpel: Statt „aus dem Bauch heraus“ zu schätzen, orientiert man sich an realen Daten aus vergleichbaren Projekten. Beispielsweise nimmt man die durchschnittlichen Kosten oder Aufwände ähnlicher Bahnprojekte und passt diese anschließend leicht an die eigenen Rahmenbedingungen an.

Genau so gehen wir heute auch bei Projektaufwänden vor. Dank unserer minutengenauen Zeiterfassung haben wir mittlerweile eine hervorragende Datenbasis.

Wenn wir heute eine Anfrage für eine 3D-Vermessung mit zwei Laserprofilern bekommen, schauen wir uns ein bereits abgeschlossenes, vergleichbares Projekt an. Angenommen, dieses hat 240 Stunden benötigt. Anschließend bewerten wir die Unterschiede – etwa die geometrische Komplexität des Bauteils. Ist das neue Teil komplexer, kalkulieren wir beispielsweise 25 % Aufschlag und landen bei rund 300 Stunden.

In der Praxis zeigt sich seitdem sehr deutlich, dass sich mehrere Vorteile ergeben:

• Die Schätzungen sind deutlich genauer als früher
• Der Aufwand für Projektanfragen ist massiv gesunken (wie bereits gezeigt auch klar in den Daten sichtbar)
• Unsere Kunden erhalten schneller belastbare Angebote

Ich kann jedem nur empfehlen, seine Schätzungen auf diese Weise datenbasiert aufzubauen.

Projektmonitoring

Ein weiteres Phänomen, das man in Projekten immer wieder beobachtet, ist das sogenannte Parkinsonsche Gesetz:

Arbeit dehnt sich genau in dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.

Oder ganz praktisch: Wenn ich für eine Aufgabe 100 Stunden einplane, wird sie mit hoher Wahrscheinlichkeit auch 100 Stunden dauern – selbst wenn sie theoretisch in 70 Stunden erledigt werden könnte.

Die Gründe dafür sind wenig überraschend:

• Man arbeitet weniger fokussiert, weil kein echter Zeitdruck besteht
• Aufgaben werden unnötig komplex („Overengineering“)
• Perfektionismus schleicht sich ein
• Entscheidungen werden hinausgezögert

Genau hier wird gutes Projektmonitoring entscheidend. Früher war das bei uns im Wesentlichen ein Blindflug. Einmal geplant, hat man gehofft, dass es irgendwie passt. Wenn es nicht gepasst hat, hat man es meist zu spät gemerkt.

Heute ist das komplett anders. Dank Jira und Tempo haben wir jederzeit einen Echtzeit-SOLL-IST-Vergleich auf allen Ebenen. Ich sehe zu jedem Zeitpunkt:

• Wie viele Stunden waren geplant?
• Wie viele wurden bereits gebucht?
• Wo laufen wir aus dem Ruder?

Das Entscheidende ist aber nicht die Transparenz allein, sondern was man daraus macht. Sobald wir sehen, dass ein Task beginnt, aus dem Rahmen zu laufen, greifen wir aktiv ein. Das kann bedeuten:

• Scope reduzieren
• Aufgaben neu schneiden
• Bewusst eine „Good enough“-Lösung akzeptieren
• Oder im Zweifel frühzeitig nachschärfen

Wir korrigieren also kontinuierlich in Richtung Plan, statt am Ende überrascht zu werden.

In Kombination mit kürzer geschnittenen Tasks (ideal < 40 h) entsteht dadurch ein sehr robuster Regelkreis: planen → umsetzen → messen → nachjustieren.

Und genau das verhindert in der Praxis, dass sich Arbeit unkontrolliert „aufbläht“.

Mehr als nur intern: Der direkte Kundennutzen

Ein oft unterschätzter Punkt ist der direkte Mehrwert für den Kunden.

Da wir ohnehin jede Arbeit einem Issue zuweisen müssen und Tempo so eingestellt ist, dass ohne Kommentar keine Zeit gebucht werden kann, entsteht automatisch eine lückenlose, minutengenaue Dokumentation.

Diese kann per Knopfdruck exportiert und dem Kunden vollständig transparent zur Verfügung gestellt werden.

Gerade bei Beratungsleistungen, Supportverträgen oder klassischen Stundenpaketen ist das aus meiner Sicht die fairste und sauberste Lösung. Der Kunde sieht exakt, wofür Zeit aufgewendet wurde, ohne Interpretationsspielraum.

Ein weiterer Vorteil ergibt sich im laufenden Projekt. Wenn ein Kunde beispielsweise ein 100h-Consulting-Paket bucht, sind darin meist mehrere Themen enthalten. In der Praxis zeigt sich oft, dass einzelne Punkte aufgrund unklarer Anforderungen oder fehlender Informationen deutlich mehr Aufwand benötigen als ursprünglich angenommen.

Dank unseres Monitorings erkennen wir solche Entwicklungen sehr früh und kommunizieren sie proaktiv.

Das wird von unseren Kunden durchwegs sehr positiv aufgenommen, weil unser internes Projektmonitoring damit indirekt auch ihnen hilft, ihre eigenen Themen besser zu steuern.

Fazit und Ausblick

Am Ende des Tages lässt sich festhalten, dass unser Time-Monitoring mehrere klare positive Effekte hat:

• Deutlich bessere Projektplanungen und wesentlich weniger negative Überraschungen
• Schnellere Angebotserstellung und damit ein spürbar besserer Kundenservice
• Ein engmaschiges, datenbasiertes Projektmonitoring

All das führt in Summe zu erheblichen Zeit- und Kostenersparnissen. Selbst bei einem kleinen Team wie AutoLab sprechen wir hier schnell von niedrigen sechsstelligen Beträgen an eingesparten internen Kosten pro Jahr.

Und das ist aus meiner Sicht erst der Anfang. Je mehr Daten wir sammeln, desto besser werden unsere Entscheidungen – und desto stärker wird dieser Effekt.