Böse Deadline! Wie man zu einer realistischen & flexiblen Planung kommt

Jedes Projekt, jedes Release, jede geplante Funktion ruft eine Frage hervor: Wann ist das fertig? Viele Teams, die Produktmanager eingeschlossen, empfinden diese ständig wiederkehrende Frage als Schikane.

Dabei liegt es in der Natur des Menschen wissen zu wollen, wann eine angefangene Tätigkeit ihren Abschluss findet. Vor allem dann, wenn eine andere Person aktiv werden muss sobald die erste Tätigkeit abgeschlossen ist. Das gilt z.B. für Marketing-Kollegen, die erst dann mit der Vermarktung anfangen können, wenn das Release fertiggestellt ist. Oder für das Management, das erst wenn die aktuelle Projektphase durch ist darüber nachdenken kann, welchen wichtigen Aufgaben das Team sich dann annehmen könnte.

nicht_agil

In vielen „agilen“ Firmen hat sich rund um diese „Wann fertig“-Frage eine Art Schutzbehauptung der Produktorganisation etabliert: Projektplanung wiederspricht der Agilität. Fertig ist etwas dann, wenn es eben fertig ist. Man könnte auch sagen, es ist die freundliche Version von „F**k off!“

Dabei wiederspricht eine gut gemachte Planung in keinster Weise agilen Werten & Prinzipien. Wichtig ist allerdings, dass die Planungshoheit beim Produktmanager und dem Team und nicht beim Management liegt. Und es darf erst nach einer gewissen Zeit (z.B. drei Sprints oder 6 Wochen) überhaupt mit der Planung begonnen werden. Vorher liegen für eine verlässliche Planung einfach zu wenige Erfahrungswerte vor.

Beachtet man diese beiden Punkte, kann der eigentliche Planungsvorgang das Team sogar neu fokussieren und motivieren. „Stimmt, das ist ja jetzt gar nicht mehr so viel!“ oder „Genau, wenn wir das so lösen, ist das deutlich weniger aufwendig und wir sind in zwei Wochen dann auch endlich mal fertig!“. Sätze, die ich so oder so ähnlich am Ende einer Planungssession oft höre.

Aber wie kommt man zu einer realistischen und flexiblen Planung?

1. Die Frage akzeptieren – Widerstand abbauen

Wer akzeptiert, dass die „Wann ist das fertig“-Frage so normal ist wie die „Wann sind wir endlich da?“-Frage bei Familienausflügen, der ist einen echten Schritt weiter. Und eigentlich ist sie auch genau so zu behandeln.

Erst reagiert man mit einem „wir sind doch gerade erst losgefahren“, dann mit einem beschwichtigenden „bald“, dann mit einem kleinen Ablenkungsmanöver (z.B. dem McDonalds Besuch) und schließlich sagt man „in 20 Minuten. Das ist so lange wie eine Bob der Baumeister Folge.“

Dabei gilt es aber immer ein Gespür für die Zielgruppe zu haben: Wieviel Information braucht der Fragende? Wann kann man vertrösten und wann braucht es eine konkretere Angabe?

Auf unsere Arbeitswelt übertragen kann man sagen: Kurz nach dem Entwicklungsstart für ein größeres Release oder Projekt kann man noch gar keine Aussage machen, da wir im agilen Umfeld ja mit „yesterday’s wheather“ planen wollen. Also erklären wir genau diesen Mechanismus. Anschließend sollte man aber zumindest mit einer groben Planung beginnen.

Sicher ist aber: die Frage geht nicht weg. Also gilt es das einfach zu akzeptieren und sich dafür zu rüsten. Denn wer nur eine Antwort im Repertoire hat, wird zurecht irgendwann in Frage gestellt (aka. genervt).

Wichtig ist außerdem, dem Team diese Tatsache vor Augen zu führen und für Verständnis zu werben. So baut man Vorbehalte ab und ist überhaupt in der Lage gemeinsam zu planen.

2. Verfügbarkeit einschätzen

Dieser Teil ist wahnsinnig wichtig und wird oft nicht oder nur lieblos gemacht: Die realistische Einschätzung der Team-Verfügbarkeit.

Wie viele netto Arbeitstage liegen überhaupt vor uns?

Einige Unternehmen arbeiten hier mit Erfahrungswerten aus vergangenen Quartalen. Im ersten Quartal sind zu Beginn noch viele in Urlaub, später kommen dann wieder einige Feiertage. Im dritten Quartal liegt die eigentliche Urlaubssaison.

Ich finde diesen Ansatz jedoch zu ungenau. Denn meist liegen einem alle Information für eine genaue Berechnung vor. Man muss die Leute nur fragen.

rechnung

Die Genaue Planung geht so:

  • Anzahl echter Arbeitstage in einem bestimmten Zeitraum (z.B. Quartal) zählen. Für Hamburg und Q3 2016 sind das 66 Tage. Bei einem Team von 6 Personen landen wir bei 396 Arbeitstagen.
  • Davon zieht man evtl. Krankheitstage ab. Ich verwende hier einfach einen Durchschnittswert. Statista sagt, Arbeitnehmer waren in 2015 im Schnitt 17,4 Tage krank. Das bricht man einfach aufs Quartal runter und multipliziert es mit der Anzahl Teammitglieder. Für unser Beispiel landen wir bei 26 Tagen voraussichtlicher Krankheit.
  • Was die Urlaubstage angeht, kann man das Team einfach fragen. Wer bereits sicher Tage verplant hat = super. Ansonsten einfach einen Durchschnittswert annehmen.
  • meetingsDie Zeit für Fortbildung und Konferenzen nicht vergessen. Im Herbst sind z.B. viele Konferenzen und das schlägt manchmal ganz schön ins Kontor.
  • Schließlich zieht man noch die Zeit für nicht direkt Projektrelevante Meetings ab. Dabei gilt es abzuwägen, welche Meetings in welches Bucket fallen. Das muss man einfach einmal besprechen und beschließen. Ist das Architekturmeeting direkt Produktrelevant?

Am Ende bleiben in unserem Beispiel von fast 400 Arbeitstagen nur ca. 250 Tage übrig.

Hätte man einfach mit den 400 Tagen geplant, wäre man deutlich später fertig geworden als ursprünglich angepeilt. Hier also ruhig sehr genau sein!

3. Storymap oder Backlog vorbereiten

Wer planen will, muss wissen was gemacht werden soll. Dabei geht es nicht darum, alle Backlogitems für die nächsten drei Monate parat zu haben. Es geht eher darum schlüssig erklären zu können, welche Themen aus welchen Gründen anstehen.

Das erfordert einiges an Vorarbeit durch den Produktmanager oder das „Konzeptionsteam“ (z.B. bestehend aus Interaktionsdesigner, Produktmanager, Entwickler): Abstimmung mit allen Stakeholdern, Kundenfeedback sichten und sortieren, Deadline und Abhängigkeiten aufdecken. Alle konkurrierenden Themen müssen sinnvoll priorisiert werden. Wie das geht, habe ich in einem anderen Artikel beschrieben.

storymapp3

Festhalten kann man die Ergebnisse dann z.B. in einem Prototyp, der grob die geplanten Veränderungen aufzeigt. Oder in einer Storymap, die die Kundenbedürfnisse festhält und in eine Reihenfolge bringt. Außerdem werden Outcome-Roadmaps (Video ab Minute 42) für diesen Zweck immer beliebter: was ändert sich für den Kunden in der geplanten Zeit wirklich?

Wichtig ist: man muss als Produktmanager flüssig und schlüssig erklären können, was man vorhat. Am besten, man übt das sogar. Ich erkläre meinen Plan oft erst mal einem Kollegen, dann einem ersten Teammitglied und arbeite dann nochmal deren Anmerkungen ein. Denn es gibt immer mir völlig klare Schlussfolgerungen, die ich dann beim Erklären nicht auf den Punkt bringe. Also: üben, verbessern, üben und erst, wenn alles sitzt damit zum ganzen Team.

4. Schätzen

Schätzungen für ein ganzes Quartal? Das macht doch keinen Sinn! Ich finde schon.

Die Schätzungen sind dabei aber nur eine sehr temporäre Größe für den einen Moment. Sie dienen in erster Linie dazu zu sehen, ob das Team ein Thema so gut durchdrungen hat (bzw. ob es mir gelungen ist, das Thema so gut zu erklären), dass sich mehrere Personen auf eine Schätzung einigen können.

Ich bevorzuge dazu eine 90-Minuten Estimation Game Session. Anschließend kennen alle die anstehenden Themen, haben sich einmal hinreichend tiefgreifend damit beschäftigt und es gibt ein gemeinsames Gefühl für die Menge an Arbeit.

5. Alles zusammenfügen – und zwar nicht alleine

Mal sehen was wir jetzt haben: wir wissen, wie viele Netto Arbeitstage vor uns liegen, welche Themen demnächst anstehen, welche der Themen zu einem bestimmten Datum fertig sein müssen und wir wissen wie „groß“ die eigentlichen Arbeitspakete sind.

Ich versuche jetzt, meist mit dem Team, eine Post-it Version einer Roadmap zu erstellen und die Arbeitspakete in eine Reihenfolge zu bringen. Und wir hängen Karten so lange hin und her, bis wir ein gutes Gefühl haben. Es ist nie perfekt. Es kann nur „so gut wie möglich“ sein.

trichter

Meist müssen an diesem Punkt nochmal 1-2 Themen gestrichen werden, weil sie einfach nicht ins Quartal passen. Dieser Schritt ist sehr wichtig, aber auch sehr unpopulär. Trotzdem: da muss man durch. Wir wollen ja einen realistischen Plan machen. Also traut euch und killt alles, was ihr für total unrealistisch haltet.

Im Anschluss verfasse ich oft schon mal eine Art „Pressemitteilung“ um zu sehen ob auch wirklich was Kommunizierbares dabei rauskommt. Denn ein Quartal an Dingen zu arbeiten, die dann für den Kunden keinen wirklichen Unterschied machen, ist total sinnbefreit. Es muss schon eine Veränderung spürbar sein.

6.Verkünden

Der Plan steht. Jetzt muss er verkündet werden. Also ab damit ins Management-Meeting, zu den Produkt-Kollegen, den Marketing- und PR-Experten und vielleicht sogar zu den Kunden.

Wichtig hierbei: Wenn euch die Leute hier euren Plan auseinandernehmen, habt ihr bei den vorherigen Schritten zu wenig mit eben diesen Personen gesprochen. Das macht ihr dann einfach im nächsten Quartal besser. Eigentlich darf es jetzt aber keine Änderungen mehr geben. Alle sollten zustimmend nicken und euch auf die Schulter klopfen.

7. Dabei bleiben

Die nächsten Wochen gilt es, jetzt den Plan vor dauernden Änderungen zu schützen. Und das solltet ihr auf jeden Fall tun. Denn ihr habt alle einbezogen, alles abgewägt, priorisiert und berücksichtigt. Also ist der Plan gut. Es gilt, ihm einfach zu folgen.

Um das aber zu können müsst ihr Änderungswünschen in verschiedene Kategorien unterscheiden:

  • irrelevante Änderungswünsche: Hat die Änderung eine Auswirkung auf eure Pressemitteilung, also auf den echten Outcome für den Kunden? Nein? Dann ist das Thema entweder nicht wichtig oder ihr könnt es, wenn Zeit ist, mit aufnehmen. Sonst parkt es bis zum nächsten Quartal.
  • aufwandsneutrale Änderungswünsche: Plötzlich ist ein anderes Thema ganz „hot“, dafür kann aber eines der ursprünglichen Themen noch bis zum nächsten Quartal warten? Ein guter Ausgangspunkt für Verhandlungen. In dem Fall gilt: schätzen, Plan ändern und den neuen Plan wieder in alle Richtungen kommunizieren. Auch sehr klar (!!!) darauf hinweisen, welches Thema gestrichen bzw. verschoben wurde.
  • „Das muss unbedingt auch noch zusätzlich rein“-Änderungswünsche: hier gilt, es den Planungsprozess in all seinen Details nochmals zu erklären und zu betonen wie viel Aufwand betrieben wurde um allen Anforderungen gerecht zu werden. Anschließend lädt man die Person ein, in der nächsten Planungsphase direkt teilzunehmen. Und man atmet nochmal tief ein und aus… denn irgendeiner kommt immer mit so einem Wunsch ums Eck.

Ein weiterer Punkt beim „dabei bleiben“ ist es, mit dem Team eine Streichliste zusammenzustellen: welche Meetings, Aktivitäten, etc. könnte man ggf. streichen, wenn es eng wird mit dem Plan und der Zeit? Idealerweise macht man das in „Friedenszeiten“. Also wenn noch keine Zeitknappheit in Sicht und das Quartal noch lang ist.

Damit unterstreicht man aber gemeinsam nochmal den Wunsch, den Plan auch Realität werden zu lassen.

Der erste Schritt

Das sind euch zu viele Tipps und Schritte? Kein Problem. Dann fangt einfach mit der realistischen Planung der Netto Arbeitstage an. Hier liegt meist der größte Hebel für eine bessere Planung.

Meine Persönliche Meinung zum Schluss

Ich glaube fest an die Gültigkeit des Parkinsonschen Gesetzes: „Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“

Genau darum glaube ich auch, dass es für jede Art von Tätigkeit wichtig ist, sich eine Deadline vorzunehmen und auch einiges daran zu setzen diese einzuhalten.

Dennoch gilt aber auch, was im agilen Manifest steht „Responding to change over following a plan“.

agil_ist

Produktmanager sollten also wissen, wie sie einen guten, belastbaren Plan machen. Sie sollten sich mit agilen Werten, Prinzipien und Entscheidungstechniken auskennen und sie sollten wissen, wann sie an einem Plan festhalten und wann sie Änderungen zulassen. Dafür gilt es ein Gefühl zu entwickeln. Das klappt nicht beim ersten Mal. Aber man wird jedes Mal besser.

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Merken

Über Petra Wille

Petra Wille studierte Informationstechnik (Dipl.-Ing. (BA)) und war zuletzt, nach Stationen bei SAP, Hubert Burda Media und der XING AG bei der tolingo GmbH in Hamburg als „Managing Director“ tätig. Seit 2013 ist Petra Wille freiberufliche Produktmanagerin und arbeitet für Ihre Kunden an neuen Produktideen: immer mit agilen Projektmethoden und meist in internationalen, auch verteilten Entwicklungsteams. Außerdem berät und coacht sie Produktmanager und vermittelt Methoden und Handwerkszeug für ein professionelles, dynamisches Produktmanagement. Neben Ihrer freiberuflichen Tätigkeit ist Petra Wille begeisterte Kitesurferin und schreibt für produktbezogen.de

6 Kommentare

  1. Jens

    Hallo Petra,
    da hast Du einen sehr guten und nebenbei unterhaltsamen Beitrag geschrieben der zeigt wie Ernst Du Auftraggeber und Stakeholder nimmst und gute Wege findest deren Anforderungen gemeinsam mit Deinen Teams zu erfüllen. Ich kann Deine Vorgehensweise nur als konstruktiv und angenehm undogmatisch bestätigen. Toll.
    Beste Grüße von Jens

  2. Gert

    Gespür mit H, Wiederstand statt Widerstand, hat da mal einer Korrektur gelesen?
    Und wenn ja – wer?

  3. Petra Wille Artikelautor

    @Jens: Danke für die Blumen. Freut mich, dass dir der Artikel gefallen hat!
    @Gregor: Danke für die nette Ergänzung durch deinen Link.
    @Gert: Haben die Fehler behoben. Wolltest du dich für die Schlussredaktion aller Artikel bewerben?

  4. Gert

    Hallo Petra,

    die Schlussredaktion kann ich gegen Honorar gerne übernehmen. Ich bin ein guter Korrektor und finde sogar doppelte Leerzeichen im Fließtext.
    Ich habe mal für eine Werbeagentur gearbeitet, in der man mich fertige Druckprodukte nicht mehr angucken ließ, weil ich immer noch Fehler fand.

    Bei Interesse bitte ich um Rückmeldung.
    Viele Grüße
    Gert

  5. Hark Thormählen

    Hallo Petra,

    um zu einen realistischen Plan zu kommen, ist es mit Sicherheit sinnvoll, genug Luft einzukalkulieren. Neben Krankheit, Schulung, Urlaub und reinen Verwaltungstätigkeiten spielt es eine Rolle, wie groß der Neuheitsgrad im Projekt ist. Unbekannte Tätigkeiten und Risiken sind schwerer abzuschätzen als Tätigkeiten, die nur wiederholt werden und deren Schwierigkeitsgrad sich nicht verändert hat.

    Mit Blick auf den „cone of uncertainty“ ist eine iterative Anpassung und Aktualisierung des Plans sinnvoll. Mit Blick auf neue Erkenntnisse im Rahmen der Fortentwicklung im Projekt oder aufgrund geänderter Kundenanforderungen bietet sich ein Plan ohnehin an, diesen zu erstellen und auch zu aktualisieren.

    Ich denke, mit der Erwartung, dass ein Plan in Stein gemeißelt ist und sich so zu erfüllen hat, muss eine klassische Projektplanung mit einem agilen Vorgehen in Konflikt geraten. Dennoch hat ein Projekt meist ein Start und ein Ende, welches in Iterationen zu erreichen ist. Damit lässt sich ein klassischer Projektablauf mit einem agilen Vorgehen kombinieren oder besser gesagt optimieren.

    Meiner Meinung nach geht es beim Plan nicht darum, ihn genau, wie zu Beginn erstellt, zu erfüllen, sondern eine Orientierung zu haben, wo alle Beteiligten im Projekt stehen. Wenn die Lage sich ändert, ist der Plan wiederum anzupassen, um die Marschrichtung im Projekt zwecks Zielerreichung zu korrigieren. Anhand des Plans werden Abweichungen zur Realität sichtbar und zeigen Stellen auf, die nachgebessert werden müssen. Freilich kann sich die Realität schneller ändern als ein Plan aktualisiert werden kann.

    Damit ein Plan realistisch ist, nicht zu oft angepasst werden muss, bleibt nur das Planen mit Puffern, die groß genug sind. Mit Blick auf Scrum geht es jedoch auch um konstante Randbedingungen, die zumindest für das Erreichen von sinnvollen Zwischenzielen erforderlich sind. Oft funktioniert das Abwehren aller Wünsche nicht und die Prioritäten und Änderungen vollziehen sich schneller als das Abarbeiten einst geplanter Aufgaben erledigt ist. Mangelnde Konstanz und Konsequenz beim Umsetzen kann durchaus der Sargnagel für jeden Plan sein.

    Eine Deadline kann in dem Sinne positiv gesehen werden, weil Menschen oft einen Termin benötigen, um Druck zum Handeln zu verspüren. Meist muss das Kind erst in den Brunnen fallen, um gerettet zu werden, während es schwieriger ist, rechtzeitig so zu handeln, dass das Unglück vermieden wird.

    Eine hohe Kunst liegt sicher darin, sich eigene Deadlines in der Produktentwicklung zu schaffen, die dann ohne Druck von außen eingehalten werden. Das sorgt in der Entwicklung für genug Zeit, die Entwicklungen sauber umzusetzen. Der Druck von außen kommt dann, wenn mit einem existierenden Produkt die Kundenanforderungen nicht aus dem Regal bedient werden können. Statt die Features dem Markt hinterher zu entwickeln, muss das Produktmanagement eigentlich seiner Zeit voraus sein, so dass an den Anforderungen für morgen gearbeitet wird und nicht an denen für gestern.

    Ich denke, dass das Wichtigste ist, sich zunächst einen Grundstock zu schaffen. Ein erstes Produkt zu haben und damit Zeit zu gewinnen, um die nächste bessere Version des Produkts zu entwickeln. Wenn Zeit und Ressourcen knapp sind, kann die beste Vorgehensmethode schnell an den Realitäten scheitern. Ich schätze, wenn ein völlig neues Produkt aus dem Boden gestampft wird, sind mehr initiale Investitionen notwendig bis sich die Ausgaben rentieren oder das finale Scheitern endgültig feststeht.

    Es muss doch recht viel gut zusammenwirken, damit es am Ende gut klappt. Es kann helfen, sich der Komplexität des Projekts bewusst zu werden, um daraus die Notwendigkeit eines Plans und seiner Anpassung abzuleiten.

    Viele Grüße
    Hark

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.