IT-Projekte brauchen eine gute Zeitplanung. Leider führt uns die menschliche Psyche beim Zeit schätzen aber an der Nase herum. Hier erfährst du 5 Tipps wie du das korrigieren und deine Zeit besser einschätzen kannst.
Software-Projekte überziehen ihren Zeitplan im Durchschnitt um 33%, selbst wenn Features weggelassen und zusätzliche finanzielle Mittel ins Projekt gepumpt werden [1].
Wieso ist es so schwierig die Projektdauer richtig einzuschätzen? 🧠🧠🧠💥🤔
«Planungsirrtum» überwinden 💆🏻♀️
Verspätungen im Projekt haben viele Ursachen: Bugs, Personalausfälle, unklare Ziele und so weiter. Am wichtigsten sind aber psychologische Gründe. Die meisten von uns rollen die Zeitschätzung «von innen» auf [2]. Wir betrachten die einzelnen Teile des Problems, und versuchen so den Gesamtzeitaufwand herauszufinden. Das verleitet aber zu optimistischen Schätzungen. Wir nehmen keine Rücksicht darauf, wie lange ähnliche, frühere Aufgaben gedauert haben und nehmen an, dass es keine Verspätungen geben wird – obwohl wir es besser wissen müssten. Neuropsycholog*innen nennen das den Planungsirrtum (planning fallacy) [3].
Was hilft?🙏
Effizienter wäre es das Projekt «von aussen» zu schätzen, also es als nur eine Arbeit unter vielen zu betrachten [4]. Dabei stützt man sich auf die Zeitverteilung ähnlicher, früherer Projekte, um den Zeitrahmen des aktuellen Vorhabens abzuschätzen [3, 4]. Allerdings hat man in der Praxis kaum Daten von 100+ Projekten wie sie für diese Referenzklassen-Prognose (reference class forecasting) nötig wären. Zum Glück kann man die Planung auch mit einfachen Kniffen in die richtige Richtung stupsen.
5 Tipps für besseres Schätzen 🎯
-
Lass jemand anderen deine Arbeit schätzen. 🙋
Der Planungsirrtum betrifft nur unsere eigenen Aufgaben. Projekte von anderen sehen wir hingegen in einem pessimistischeren Licht und werden eher auf mögliche Hindernisse aufmerksam [5].
-
Lass das Worst-Case Szenario in die Schätzung einfliessen. 🤬
Schätze die schlechtestmögliche (P), die wahrscheinlichste (W) und die bestmögliche Projektdauer (O) und verwende den gewichteten Durchschnitt (= (P + 4 x W + O) / 6) daraus. Das soll nicht nur zu realistischeren Zahlen führen, sondern auch anregen über mögliche Risiken nachzudenken.
Beim „3-Point Estimate“ fliessen der best- und worst-case in die Berechnung ein. (S. Müller)
-
Erfasse deine Arbeitszeiten. ⏲
Time Tracker wie Toggl unterstützen Dich dabei. Es ist wichtig auch unproduktive Zeit mitzumessen, z.B. Unterbrechungen oder wenn Projektzeit kurzfristig für etwas anderes aufgewendet wurde. Über die Zeit baust du Dir so deine eigene Datenbank auf mit der du deine Schätzungen überprüfen kannst. Schätzt du konsequent zu hoch oder zu tief kannst du deine Werte mit Deinem persönlichen «fudge factor» multiplizieren.
-
Mach eine Monte-Carlo Simulation. 📈
Das Evidence-Based Scheduling stützt sich auf diese Methode [6]. Das Grundprinzip ist einfach: Für jede Projektaufgabe zieht man zufällig einen Wert aus den Zeiten vergangener Projekte. Für ein Projekt mit 45 Aufgaben werden also 45 Zufallswerte gezogen und die Gesamtzeit berechnet. Wiederholt man das 100mal, kann man aus der entstehenden Zeitverteilung ableiten wie lange das Projekt wahrscheinlich dauern wird.
-
Plane mit natürlichen Zeitabschnitten. ☕
Soll der Aufwand in Stunden eruiert werden, kann es nützlich sein, Tasks als 90 Minuten Blöcke zu schätzen [2]. Diese Dauer entspricht dem menschlichen Rest-Activity Zyklus [7]. Pro Arbeitstag plant man 4 solche Blöcke ein, zwei am Morgen (vor und nach Kaffeepause) und zwei am Nachmittag (dito). Das macht die Schätzung greifbarer und schliesst jeden Tag einige Stunden Pufferzeit für andere Tätigkeiten ein.
Der Arbeitstag wird zum Schätzen in 4 Blöcke à 90 min unterteilt. (S. Müller)
#NoEstimates als Alternative 🙅🏻♀️
Wenn es mit dem Schätzen trotzdem nicht klappt, braucht man nicht zu verzweifeln. Die #NoEstimates-Bewegung findet das Schätzen der Aufgabendauer auf alle Fälle nicht essenziell. Sie schlägt vor Zeitschätzungen beiseite zu legen und stattdessen z.B. die Anzahl der pro Sprint erledigten User Stories vorauszusagen [8, 9].
Weiterführende Literatur
- Bloch, M. & Blumberg, S. & Laartz, J., Delivering large-scale IT projects on time, on budget, and on value. McKinsey Quarterly. (2012) 27: 2-7.
- Linders., B., Better estimations using techniques from psychology, Interview mit Joseph Pelrine, PhD. InfoQ, Blog Post (2017).
- Kahneman, D., Tversky, A., Intuitive prediction: Biases and corrective procedures. Technical Report PTR 1042-77-6, Decision Research (1977).
- Flyvbjerg, B., Curbing Optimism Bias and Strategic Misrepresentation in Planning: Reference Class Forecasting in Practice. European Planning Studies. (2008) 16. 3-21.
- Buehler, R., Griffin, D., Ross M., It’s about time: Optimistic predictions in work and love. European Review of Social Psychology. (1995) 6: 1–32.
- Splonsky, J., Evidence Based Scheduling, Blog Post (2007).
- Kleitman N., Sleep and Wakefulness. University of Chicago Press, Chicago, IL (1963).
- Ageling, W.J., The logic of ‚#NoEstimates‘, Serious Scrum, Blog Post (2012).
- Magennis, T., Focused Objective, Github Repository
