Kennst du das? Dein Chef kommt zu dir und bittet dich die Projektlaufzeit, bzw. Zeit/Kosten für das Projekt zu schätzen zu dem es noch nicht mal ein Grobkonzept gibt, und welches eine grob geschätzte Implementierungszeit von einem halben Jahr aufweist? Falls nein: Super. Falls doch: Weiterlesen.
Zeiten schätzen ist immer schwer. Und wir alle wissen, dass es umso schwerer ist dies gut und korrekt zu tun. Doch es gibt ein paar Tipps, die einem das Leben leichter machen können.
- Es gibt verschiedene „Stufen“ einer Schätzung. Du solltest diese Schritt für Schritt durchlaufen und jeweils kommunizieren, um welche Art der Schätzung (also wie grob diese ausfällt) es sich handelt. So kannst du sicher gehen, dass sich später niemand über eine „falsche“ Schätzung beschwert, oder dir noch ein Jahr später deinen ersten Wert unter die Nase hält (der mittlerweile anderthalb mal so groß ist):
Planung ist alles - ROM (Rough Order of Magnitude) Estimate: Hier wird mit einer Toleranz von -25% bis +75% geschätzt. Dies ist dein erster Anlaufpunkt, hier geht es los. Genauer wird es dann beim:
- Budget Estimate: -10% bis +25% Fehlertoleranz sind hier akzeptabel.
- Definitive Estimate: Hier wird es sehr spezifisch. Du solltest Abweichungen innerhalb der -5% bis +10% Grenzen halten.
- Schau dir vergleichbare Projekte an. Du sollst die SEO-Analyse für eine große Firma durchführen? Vielleicht hast du ja letztens etwas Ähnliches für eine mittelgroße Firma durchgeführt und kannst die Aufwände skalieren? Hier kannst du einen Komplexitätsfaktor zur Multiplikation anlegen.
- Erstelle einen Plan und pflege ihn. Natürlich hilft dir ein Projektplan, in dem du die Aufgaben heruntergebrochen hast. Aber auch ein fortlaufend gepflegtes, formloses Dokument kann dir helfen Schritt für Schritt besser zu schätzen. Du siehst schnell welche Aufgaben, oder vielleicht auch Kollegen du falsch eingeschätzt hast und kannst zukünftige Punkte akkurater einschätzen.
- Frag einen Experten. Du bekommst den Auftrag eine Website in Drupal umzusetzen, hast bisher aber nur mit WordPress gearbeitet? Dann ist es sicher sinnvoll sich mit jemandem zu unterhalten der das neue System kennt. Im Idealfall sogar beide, um dir sagen zu können, welche Stolpersteine du beim Umstieg vorfinden wirst.
- Beginne mit einem Top-Down Ansatz. Hier stellst du von oben nach unten dar, was zu tun ist. Möchtest du bspw. eine neue Homepage implementieren steht ganz oben vielleicht nur „Homepage“ und du teilst die verschiedenen Aufgaben darunter in einer Baumstruktur auf. Hier könnten „Design“, „Konzeption“, „Implementierung“,… etc. stehen. Für jede dieser Aufgaben kannst du nun grob schätzen, welche Aufwände entstehen. Oft genutzt wird dieses Vorgehen bei der ROM-Schätzung.
- Konkret wird es mit der Bottom-Up Methode. Hier liegen dir die Aufgaben einzeln heruntergebrochen vor. Es sind also klar definierte Arbeitspakete, welche in überschaubarer Zeit von einer einzelnen Person zu erledigen sind. Liegen dir diese Schätzungen vor hast du schon sehr genau geplant und viel Zeit in die Analyse der Aufwände gesteckt. Dementsprechend wird dies meist für die endgültige Schätzung genutzt. Hier steht dann nicht mehr „Implementierung der Homepage“, sondern bspw. „Einbinden von Web Analytics“.
- Kommuniziere klare Anforderungen. Bleiben wir doch mal beim Beispiel Web Analytics. Wenn ich als Projektmanager einem Developer sage er soll sich bitte darum kümmern die Besucherzahlen zu tracken, dann denke ich vielleicht an eine Integration von etracker, während der Developer an Google Analytics denkt (und der Praktikant seinen eigenen JavaScript Counter einbaut!?). Solche Missverständnisse kosten doppelt Zeit, weil zu einem späteren Zeitpunkt nicht nur die korrekte Anforderung umgesetzt, sondern auch der Fehler korrigiert werden muss.
- Pass deine Zahlen nicht ans Budget an. Natürlich ist es reizvoll zu sagen: Wir haben ein Budget von X €, also dürfen wir nur Y Tage für das Projekt brauchen. Klar, das kann eine konkrete Anforderung sein. Aber wenn du hier bewusst Zahlen gering hälst wirst du am Ende minderwertige Qualität abliefern oder zugeben müssen falsch geplant zu haben. Manchmal muss man eben schon zu Beginn der Projekte feststellen, ob die Dinge so umzusetzen sind, wie man es sich vorstellt. Das ist zwar auch manchmal unangenehm, tut aber weniger weh, als wenn das Projekt nach 75% abgebrochen wird, weil definitiv kein Geld mehr da ist.
- Rechne Dinge ein, die leicht zu übersehen sind. Meetings zum Beispiel. Die kosten schnell mal sechs Leute einen ganzen Tag. Das wären fast 50 Stunden. Oder das Warten auf Feedback. Wenn du an einem bestimmten Punkt nicht ohne Feedback/Abnahme weiterarbeiten kannst, so solltest du dies unbedingt frühzeitig feststellen und einplanen.
- Denk immer ans Risiko. Kein Projekt ohne Risiko. Vielleicht kannst du das Risiko sehr gut einschätzen, weil du ähnliche Projekte schon oft durchgeführt hast. Vielleicht arbeitest du aber das erste Mal mit einem neuen CMS, arbeitest neue Mitarbeiter ein, oder lebst in einer Erdbeben-reichen Gegend? Risikobewertung ist ein riesen Thema. Wichtig nur, dass du es nicht übersiehst.
- Führe nach Projekten eine Retrospektive durch. Egal ob du es so nennst, oder vielleicht „Lessons Learned“, oder wie auch immer. Hauptsache du überlegst, was gut und was schlecht gelaufen ist, wie und wo du dich verschätzt hast und wie du dies in Zukunft vermeiden kannst.
Du hast noch weitere gute Tipps? Ich freue mich immer über Kommentare.
Schreibe einen Kommentar