Image source: https://flic.kr/p/s7aUff, Creative Commons License
Die Zukunft ist nicht vorhersagbar
Im Geschäftsleben wollen Manager normalerweise vorab wissen, wie lange ein Projekt dauern wird und was es kosten wird. Im Grunde müssen wir dafür die Zukunft vorhersagen. Als Menschen mögen wir es, wenn unsere Umgebung vorhersagbar erscheint. Wir fühlen uns dadurch sicher. Aber wie schon John Lennon sagte: das Leben ist das was passiert, während man damit beschäftigt ist, andere Pläne zu schmieden.
Wenn wir für ein Projekt eine detaillierte Aufwandschätzung machen, wollen wir die exakten Anforderungen und Parameter wissen. Typischerweise haben wir diese aber nicht. Stakeholdern können ihre Meinung ändern, wir bekommen unvollständige und inkonsistente Spezifikationen, Teammitglieder verlassen das Projekt, die wirtschaftlichen Rahmenbedingungen ändern sich, es gibt unvorhergesehene Probleme und vieles mehr.
Wie gut sind Sie im Schätzen? Versuchen Sie unser interaktives Quiz: How Good Are Your Estimation Skills?
Agiles Management
Agiles Management ist eine Strategie für komplexe Projekte mit sich ändernden Anforderungen. Große Vorabinvestitionen werden vermieden, stattdessen wird ein iterativer, inkrementeller Ansatz gewählt.
Bekannte Frameworks für agiles Management sind Scrum und Kanban. Wir haben für time cockpit mit Scrum gestartet, sind später aber auf Kanban umgestiegen, da es besser zu unserer Arbeitsweise gepasst hat.
Wollen Sie wissen, warum wir von Scrum auf Kanban umgestiegen sind? Lesen Sie dazu unseren Artikel Warum wir für time cockpit nicht Scrum verwenden
Iterativ = nicht planbar?
Stakeholder haben oft ihre Probleme mit den agilen Ansatz da er chaotisch und risikoreich wirkt. Sie wissen nicht genau was sie bekommen und wann das Projekt fertig wird. Stakeholder bevorzugen daher oft das Wasserfall Modell, da es Berechenbarkeit verspricht. Agile Projekte dagegen scheinen nicht plan- und managebar.
Wenn Sie sich aber die unzähligen Faktoren ansehen, von denen große Projekte abhängen, dann wissen Sie, dass die Vorhersagbarkeit von Wasserfall-Projekten Sie in falscher Sicherheit wiegt. Agile Methoden haben dagegen Mechanismen, um auf Änderungen zu reagieren.
Agil muss nicht gleich Chaos und Blindflug bedeuten. Für time cockpit haben wir einige Best Practices zum Umgang mit agilen Projekten entwickelt. In diese Artikel fasse ich die wichtigsten Aspekte für Sie zusammen.
Mehr Infos, wie wir für unsere Stakeholder Projektreporting abwickeln, finden Sie in unserem Artikel Projekt Reporting in agilen Projekten.
Starten Sie mit den Extremfällen
Wenn wir Aufwand und Kosten für ein neues Projekt planen, starten wir damit, über die Extremfälle nachzudenken. Wir wollen einen soliden Launch Status Check, versuchen aber den Aufwand auf ein Minimum zu reduzieren. Hier sind die Fragen, die wir uns und unseren Stakeholdern stellen:
Zeit
Welche harten Deadlines gibt es?
Beispiel: bei einer Messe soll eine erste Version eines neuen Produkts vorgestellt werden, Präsentationstermine bei Venture Capitalists, ...
Wenn man Kunden nach Deadlines fragt bekommt man oft die Antwort "kommt darauf an" oder "wir sind flexible". Meine Strategie für solche Situationen ist es, mit total schwachsinnigen Annahmen zu antworten. "Dann ist es in Ordnung, wenn das Projekt fünf Jahre dauert." Ersetzen Sie "fünf" mit einer Zahl, die für Ihr Projekt lächerlich ist. Natürlich wird der Kunde protestieren. "Dann gibt es also doch eine Deadline, oder?" Das bringt die Diskussion vorwärts.
Features
Was sind die absolut minimalen Features, die wir für diese Deadline brauchen?
Finden Sie mehr dazu unter Minimum Viable Product aka MVP.
Fragen Sie Stakeholder nicht nach detaillierten Spezifikationen. Ein kurzer, gut durchdachter Überblick ist oft mehr Wert als hunderte Seiten von Details, die sich während des Projekts ändern werden.
Es ist wichtig die minimalen Features zu kennen, von denen nichts mehr weggelassen werden kann. Fragen Sie Dinge wie: "Das Projekt macht also keinen Sinn mehr, wenn wir Feature X nicht liefern können?" Wenn Stakeholder zögern, den Funktionsumfang vorerst zu reduzieren, machen Sie ihnen klar, dass der Scope des Projektes erweitert werden kann, sobald klar ist, dass das Projekt den Zeit- und Budgetplan einhalten kann.
Budget
Was ist das maximale Budget an Ressourcen, das wir haben?
Beispiele: Budget, Anzahl Teammitglieder, Anzahl Spezialisten für spezielle technische Bereiche, ...
Dieser Punkt ist schwierig, weil er Vertrauen zwischen den Stakeholdern und dem Projektteam voraussetzt. Betonen Sie, dass eine offene Kommunikation wichtig für den Erfolg eines Projekts ist.
Stakeholder wollen oft das maximale Budget geheim halten. Das ist in Ordnung. Wenn es aber darum geht, die Aufwandschätzung abzusegnen (siehe nächster Punkt), muss zumindest offengelegt werden, ob die Schätzung innerhalb des zur Verfügung stehenden Budgets liegt.
Wenn Stakeholder in ihren Aussagen zum Budget wage bleiben, nutzen Sie die oben genannte Strategie: provozieren Sie mit überzogenen Forderungen. "Wenn Geld nicht der Engpass ist, ist es dann in Ordnung, wenn wir ein Dutzend neuer Entwickler anstellen und zwei Millionen Euro verbrachen werden?"
Schätzung
Wie viele Resources und welche Durchlaufzeit werden wir für das Minimum Viable Product brauchen?
Arbeiten Sie nicht mit Punktschätzungen sondern verwenden Sie stattdessen Intervalle!
Die Schätzung besteht aus einer Unter- und einer Obergrenze:
- Untergrenze: Wie viele Ressourcen und welche Durchlaufzeit brauchen Sie mindestens für das MVP? Das ist die Zeit die Sie brauchen, wenn wirklich alles perfekt läuft.
- Obergrenze: Wie viele Ressourcen und welche Durchlaufzeit brauchen Sie um sehr sicher zu sein, dass Sie das MVP liefern können (90% Konfidenz, Details dazu finden Sie unter How Good Are Your Estimation Skills?)?
Natürlich teilen wir große Projekte in kleinere Arbeitspakete auf. Wir versuchen uns nicht in zu vielen Details zu verlieren. Die Anzahl der Arbeitspakete hängt von der Größe der Projekte ab. Große Projekte (in unserem Fall zwischen 100 und 150 Personentagen) haben typischerweise 10 bis 15 Arbeitspakete. Eine detaillierter Planung erfolgt dann erst während des Projekts (z.B. bei der Sprint Planung in Scrum).
Status Check
Abhängig von den Antworten auf die diese Fragen diskutieren wir, ob es Sinn macht das Projekt zu starten. Hier sind einige Bespiele für Dinge die passieren können:
- Wir bitten den Stakeholder das Projekt zu überdenken (z.B. Funktionsumfang reduzieren, Deadlines verschieben, ...), wenn …
- … die minimale Durchlaufzeit zeigt, dass wir die Deadlines nicht einhalten können
- … die minimal benötigen Ressourcen bereits das Budgetlimit überschreiten
- Wir fragen den Stakeholder ob er bereit ist das Risiko zu übernehmen, wenn ...
- … die minimale Durchlaufzeit in Ordnung wäre, wir mit der maximalen Durchlaufzeit aber die Deadlines nicht einhalten können
- … die minimalen Ressourcen abgedeckt sind, die maximalen Ressourcen aber das Budgetlimit überschreiten
- Wir geben dem Stakeholder grünes Licht, wenn …
- … selbst die maximalen Ressourcen und die maximale Durchlaufzeit das Budget und Deadlines nicht gefährden.
In großen, komplexen Projekten führen wir solche Status Checks mehrmals durch. Wir wiederholen sie vor dem Start von neuen, großen Modulen. Wir überprüfen damit die Machbarkeit von großen Features. Es hilft uns den Scope von neuen Releases zu überdenken.
Tracking Heartbeat definieren
Wenn wir entscheiden ein Projekt zu starten, definieren wir einen Aufwands- und Kosten-Tracking Heartbeat. In Scrum entspricht dieser Rhythmus der Sprintlänge. Wir finden, es ist wichtig ein regelmäßiges Intervall für die Überwachung von Aufwand und Kosten zu etablieren. Das bringt Stabilität und Planbarkeit in agile Projekte.
In unseren Kundenprojekten variiert der Tracking Heartbeat zwischen einer Woche und einem Monat (unser Verrechnungsintervall) abhängig von der Projektphase, der Projektgesundheit und den Kundenwünschen.
Regelmäßiger Health Check
KPIs
Unser Artikel Projekt Reporting in Agilen Projekten enthält ein Excel Template das zeigt, wie wir den Projektfortschritt strukturieren.
Zu jedem Tracking Heartbeat erheben wir folgenden KPIs:
- Vergangene Zeit in %
(z.B. sechs Wochen sind bereits vergangen, zehn Wochen haben wir noch bis zur Deadline, das ergibt 37.5%)
- Pro Arbeitspaket ermitteln wir:
- Minimum und Maximum Schätzung
- Fertigstellungsgrad in %
(geschätzt von mehreren Teammitgliedern und Stakeholdern, mehr dazu unter Scrum Planning Poker) - Erwarteter Projektfortschritt = Aufwandschätzung * Fertigstellungsgrad
- Effektiver Projektfortschritt
Der letzte Punkt ist ein wichtiger Grund, warum Zeiterfassung auch in agilen Projekten wichtig ist. Lesen Sie mehr darüber in unserem Artikel Sechs Gründe für Zeiterfassung in Agilen Projekten.
Health Check
Basierend auf den ermittelten KPIs, machen wir einen Gesundheitscheck des Projekts. Wir überprüfen ...
- … ob unser gewichteter Durchschnitt des Fertigstellungsgrades nicht hinter die bereits vergangene Projektzeit zurückfällt. Wenn doch, besteht das Risiko nicht mehr zur Deadline fertig zu werden.
- … ob unser effektiver Aufwand innerhalb der geschätzten Unter- und Obergrenzen liegt. Wenn nicht besteht die Gefahr, dass wir das Projektbudget überschreiten.
Diese harten Fakten ergänzen wir noch mit einer kurzen Beschreibung der wichtigsten Risiken, die im Moment im Raum stehen.
Stakeholder: Anpassungen vornehmen, wenn notwendig
Der regelmäßige Health Check hilft den Stakeholdern das Projekt zu adaptieren, wann immer es nötig wird. In Projektmeetings verwende ich oft das mentale Bild eines echten Herzes. Ist das Herz unseres Projekts gesund, oder haben wir einen kranken Patienten? Hier sind einige Beispiele:
- wir sind schneller und effizienter als wir dachten
- der Projekt-Scope kann erweitert werden (wir können mehr als das MVP liefern) oder
- Ressourcen können zu einem anderen Projekt verschoben werden oder
- die Fertigstellung erfolgt früher als geplant
- wir kommen wegen Ressourcenmangels langsamer voran als geplant
- Projekt stoppen oder
- blockierende Faktoren entfernen oder
- mehr Ressourcen beschaffen oder
- Projekt-Scope verkleinern oder
- Deadlines verschieben
- der Fortschritt ist in Ordnung aber wir verbrauchen zu viele Ressourcen
- Projekt stoppen oder
- Budget aufstocken oder
- effizienter werden
- der Fortschritt ist wie erwartet und der Aufwand liegt innerhalb der geschätzten Grenzen
- weitermachen wie bisher oder
- Team coachen um noch effizienter zu werden
Wir prognostizieren nichts, wir überwachen die Entwicklung
Wir versuchen nicht, die Zukunft vorherzusagen. Das ist nicht möglich und daher eine Zeitverschwendung. Stattdessen versuchen wir mit minimalen Ressourcen abzuschätzen, ob ein Projekt mit den zur Verfügung stehenden Ressourcen bis zu einer bestimmten Deadline abgewickelt werden kann. Während des Projekts behalten wir den Fortschritt im Auge und kommunizieren offen und ehrlich mit den Stakeholdern. Das stärkt das Vertrauen zwischen allen involvierten Parteien.
Alles in Allem versuchen wir den administrativen Aufwand zu reduzieren und Micro-management und Big Design Upfront zu vermeiden.
comments powered by 