Detailplanung von Projekten: Schritt-für-Schritt-Anleitung zur effektiven Projektplanung
Detailplanung von Projekten: Schritt-für-Schritt-Anleitung zur effektiven Projektplanung
In den letzten Artikeln ging es darum, wie du durch eine Zieldefinition (Ziele definieren), eine Grobplanung (Grobplanung erstellen) und einen Workshop (Workshop planen) einen guten Überblick darüber erhältst, welche Aufgaben zu erledigen sind. In diesem Artikel erfährst du nun, wie du deine vielen Ideen zusammenfasst und in einen detaillierten Plan überführst.
Das Minimum Viable Product (MVP) verstehen
Bevor wir in die Detailplanung gehen, möchten wir dir das Konzept des Minimum Viable Product (MVP) aus dem Lean Startup vorstellen. Ein MVP ist ein Produkt mit minimalem Funktionsumfang, das dem Nutzer aber bereits einen Mehrwert bietet.
Es dient dazu, die eigenen Ideen schnell zu realisieren und an den Nutzerbedürfnissen zu spiegeln. Behalte diesen Gedanken, einen minimalen Funktionsumfang zu realisieren, im Hinterkopf, wenn es im Folgenden um die Ableitung der Detailplanung geht.
Was wir dir in diesem Artikel vorstellen, ist unsere Herangehensweise und unsere Erfahrungen damit. Wir beginnen bewusst nicht mit den klassischen Methoden, sondern zeigen dir, was für uns gut funktioniert hat. Im besten Fall kannst du viele der Ansätze für dich verwenden oder sie auf deine Bedürfnisse anpassen.
Agiles Arbeiten: Was bedeutet das für uns?
Oft wird Agilität fälschlicherweise damit gleichgesetzt, dass man nicht plant. Im Vergleich zum klassischen Wasserfallmodell mag das vielleicht so erscheinen. Das Zwiebelprinzip ( Grobplanung erstellen ) ist aber nicht ungültig, nur weil man agil arbeitet. Für uns bedeutet agil zu sein, sich schnell an Veränderungen anpassen zu können, viel zu kommunizieren und das Erreichte selbstkritisch zu bewerten.
Was ist das Wasserfallmodell und kann man damit agil sein?
Das Wasserfallmodell bedeutet im klassischen Sinne, dass die Projektschritte linear, also nacheinander, durchgeführt werden. Analog zu einem Prozess geht es erst zum nächsten Schritt, wenn der vorherige abgeschlossen ist. Eine Iteration ist nicht vorgesehen.
Der Projektplan wird einmal erstellt, und nach einer gewissen Zeit sind alle Projektphasen durchlaufen und das Projekt ist beendet. Auf Änderungen wird erst am Ende reagiert, mit einem neuen Projektplan. Du kannst es dir vorstellen wie einen Zug, der auf einer Schiene fährt. Das ist die klassische Sicht, und es gibt natürlich Abwandlungen.
Im Gegensatz dazu bedeutet Agilität, auf Änderungen zu reagieren. Nimmst du also nicht den Zug, sondern das Auto, kannst du flexibel deine Route anpassen und zum Beispiel einen Stau umfahren—im Gegensatz zum Zug, der bei einer blockierten Strecke nicht ausweichen kann.
Ist Agilität immer die bessere Wahl?
Ganz klar: Nein! Die verschiedenen Methoden sind Werkzeuge, um ein Problem zu lösen. So vielfältig wie die Probleme sein können, so vielfältige Lösungen braucht es auch. Wenn dein Ziel und dein Weg unsicher sind, ist eine agile Methode eventuell besser. Wenn du genau weißt, wer was wann zu tun hat und es darum geht, schnell und planbar das Projektziel zu erreichen, verwendest du vielleicht eine Methode, die sich am Wasserfallprinzip orientiert.
Versuche, die Methoden nicht streng zu trennen, sondern stelle dir vielmehr die Prinzipien zusammen, die auf deine Anforderungen passen. Jetzt aber zur Detailplanung.
Den richtigen Planungsumfang wählen
Im letzten Arbeitsschritt hast du sowohl aus dem Brainstorming (Virtuelles Brainstorming durchführen) als auch aus dem Eventstorming (Virtuelles Eventstorming durchführen) viele mögliche und nützliche Features abgeleitet. Überlege dir nun, welche für deine Idee unbedingt notwendig sind. Um das zu realisieren, ist es hilfreich, dein Ziel so weit zu vereinfachen, dass der Kerngedanke gerade noch erhalten bleibt.
Wir zum Beispiel wollen es Menschen erleichtern, Open-Source-Projekte schnell und unkompliziert zu finden. Der Kerngedanke ist das Suchen und Finden von Open-Source-Projekten. Im einfachsten Fall ist das eine Suchleiste auf einer Internetseite (Open Source Search). Kategorisiere nun deine Features danach, welche:
- unbedingt notwendig sind, um das Produkt zu erstellen,
- deinem Nutzer einen Vorteil gegenüber anderen Lösungen bieten,
- tolle Ideen sind, um dein Produkt weiter zu verbessern.
Klar ist, dass du Punkt 1 zuerst umsetzen musst — ohne das gibt es kein Produkt. Bei Punkt 2 ist es wichtig, dass du dir den einen Vorteil gegenüber anderen Produkten heraussuchst, der deinen Nutzern am meisten bringt. Schau dir dafür andere Produkte an, nutze sie, lies Nutzermeinungen und Forendiskussionen. Versuche, ein genaues Bild davon zu bekommen, was deine zukünftigen Nutzer anspricht. Alle anderen Vorteile aus Punkt 2 kannst du in Punkt 3 packen und für später aufheben.
Wenn du dich für das minimale Set an Funktionen entschieden hast, kannst du anfangen, diese Funktionen zu planen.
Effektive Projektplanung: So gehst du vor
Wie würdest du vorgehen, wenn du mehrere Schränke von einem Raum in einen anderen bringen willst? Wenn du allein bist, wahrscheinlich indem du die Schränke ausräumst, zerlegst, transportierst, aufbaust und wieder einräumst. Ähnlich auch hier: Das große Problem musst du portionieren.
Nimm dir eine Funktion aus dem vorgesehenen Funktionsumfang heraus und stelle dir die Frage: Wie lange brauche ich, um diese Funktion zu entwickeln, zu testen und betriebsbereit zu bekommen? Wenn du noch keine gute Schätzung abgeben kannst, zeigt das, dass die Aufgabe noch zu groß ist. Überlege dir, welche Teilschritte du benötigst.
Möchtest du beispielsweise ein Gartenhaus aufbauen, dann überlege, welche Schritte dafür notwendig sind: Zeichnung erstellen, Material planen und einkaufen, Bretter zurechtsägen usw. Bei jedem Arbeitsschritt versuchst du wieder, den Aufwand zu schätzen. Fällt es dir leicht, dann hast du wahrscheinlich die richtige Planungstiefe erreicht.
Der Sinn hinter dem Abschätzen des Aufwands ist, dass du dir die Arbeit konkret vorstellen kannst. Um zu schätzen, wie lange eine Tätigkeit dauert, musst du wissen, was dafür alles zu tun ist.
Wir bei WeValCo vereinfachen an dieser Stelle etwas. Anstelle einer genauen Zeitabschätzung bewerten wir den Aufwand nach vorher definierten Kriterien. Für uns haben sich die folgenden Zeiteinheiten bewährt:
- Ein paar Stunden (1 Punkt)
- Ein paar Tage (7 Punkte)
- Mehr als eine Woche, aber weniger als zwei Wochen (20 Punkte)
Alles, was über zwei Wochen hinausgeht, zerteilen wir in weitere Unteraufgaben. Wichtig ist auch, dass wir nicht den gesamten Funktionsumfang bereits zu Beginn in Arbeitspakete aufteilen.
Im ersten Schritt bringen wir die einzelnen Funktionen in eine logische Reihenfolge, sofern es eine gibt. Als Beispiel: Die Fenster einzusetzen, bevor eine Wand des Gartenhauses fertiggestellt wurde, ist nicht möglich. Es muss diese logische Reihenfolge nicht immer geben, und gerade in der Softwareentwicklung können viele Aufgaben parallel abgearbeitet werden. Überlege dir aber, welche Bereiche sinnvollerweise vor anderen entwickelt werden sollten.
Im zweiten Schritt beginnen wir, eine der Funktionen in Arbeitspakete zu zerlegen, wie oben beschrieben. Lasten die entsprechenden Arbeitspakete uns bereits für die kommenden Wochen aus, beenden wir die Planung. Wenn nicht, nehmen wir uns eine weitere Funktion und zerlegen diese. Für uns ist es ausreichend, Arbeitspakete für die nächsten 4–6 Wochen zu erstellen.
Bedenke: Je weiter du in die Zukunft planst, desto wahrscheinlicher ist es, dass du die Planung wieder anpassen musst. Je weniger du planst, desto weniger Zusammenhänge zwischen den Arbeitspaketen fallen dir auf und du musst die Implementierung ggf. anpassen. Versuche, für dich einen passenden Planungshorizont festzulegen.
Der Sprint: Agile Planung in der Praxis
Wenn du eine grobe Reihenfolge der Funktionen gefunden und genug Arbeitspakete erarbeitet hast, kannst du eigentlich anfangen. Es macht aber Sinn, dir einen Zeitraum zu setzen, nach dessen Ende du zurückblickst und das Geschaffte reflektierst. Wir machen das in sogenannten Sprints, die eine Dauer von zwei Wochen haben.
Zu Beginn eines Sprints legen wir fest, wer welche Arbeitspakete bearbeitet. Jedes Arbeitspaket ist in einer Aufwandsklasse, und jede Aufwandsklasse hat Punkte. Pro zwei Wochen Sprint schaffen wir pro Person ca. 20–25 Punkte. Dementsprechend viele Arbeitspakete nimmt sich jeder am Anfang eines Sprints.
Am Ende eines Sprints kannst du reflektieren, ob du deine gesteckten Ziele gut erfüllt hast oder nicht. Überlege dir auch, warum etwas gut oder weniger gut funktioniert hat. Sind die Arbeitspakete noch zu groß oder warst du zu optimistisch, wie viele Arbeitspakete du in deinem gesteckten Zeitraum schaffst? Iteriere dich an ein für dich passendes System.
Die Reflexion am Ende eines Sprints ist essenziell. Nur durch Reflexion wirst du besser in deiner Planung und effizienter in deiner Arbeitsweise. Frag dich immer:
- Was lief gut und warum?
- Was lief schlecht und warum?
Sei selbstkritisch, aber sei auch stolz auf das, was du geschafft hast! Deine Erfahrungen mit dem aktuellen Sprint kannst du dann in die Planung des folgenden Sprints einfließen lassen.
Am Ende jedes Sprints prüfen wir, ob noch genug Arbeitspakete geplant sind und planen ggf. neue. Dann füllen wir den folgenden Sprint wieder mit Arbeitspaketen, und der Zyklus beginnt von Neuem.
Für die Nachverfolgung unserer Aufgaben verwenden wir Kanban. Auf einem Kanban-Board siehst du zum Beispiel, welche Aufgaben du für den aktuellen Sprint geplant hast, an welchen gerade gearbeitet wird, welche fertig sind und welche komplett abgeschlossen sind. Kostenfreie Kanban-Lösungen findest du in unserer Open-Source-Suche.
Den aktuellen Fortschritt der Aufgaben besprechen wir in kurzen, täglichen Besprechungen von wenigen Minuten. So behält jeder den Überblick über die Aufgaben der anderen und kann sich schnell Rückmeldung bei Problemen holen. Beachte aber, dass es wirklich ein kurzer Austausch bleibt! Ausführliche Diskussionen können im Nachgang und im kleineren Kreis geführt werden.
Praxisbeispiel: Mias Projektplanung im Detail
Auch Mia, Peter und Zou haben in den letzten Artikeln Ideen zu ihrem Funktionsumfang erarbeitet. Zunächst möchten sie die wirklich notwendigen Funktionen beschreiben und sich auf ein besonderes Feature einigen.
Für den Videochat braucht es auf jeden Fall eine Video- und Audioübertragung von mindestens zwei Teilnehmern. Einer der Teilnehmer muss die Möglichkeit haben, einen anderen einzuladen, und der andere Teilnehmer muss die Möglichkeit haben, die Einladung anzunehmen oder abzulehnen. Alle Arbeitspakete, die mit diesem grundlegenden Funktionsumfang zu tun haben, kategorisieren die drei als „unbedingt notwendig“.
Über das eine herausragende Feature diskutieren sie ausführlich. Zou findet eine Kontaktliste wichtig, Peter möchte Benachrichtigungen auf das Handy bekommen, und Mia möchte Video-Chaträume mit vorgegebenen Themen. Da die drei sich nicht sofort einig werden, lesen sie Foreneinträge und fragen in ihrem Freundeskreis nach. Dabei wird ihnen klar, dass ihr Alleinstellungsmerkmal darin besteht, dass ihr Videochat Open Source ist und jeder ihn einfach auf einem Server installieren und betreiben kann. Sie entscheiden sich daher, alle drei Ideen für später aufzuheben und sich auf die notwendigen Funktionen zu fokussieren.
Durch das Eventstorming (Virtuelles Eventstorming durchführen) haben die drei schon ein gutes Verständnis davon, wie ihr Videochat aussehen könnte. Sie spiegeln die Oberfläche an dem festgelegten Funktionsumfang und entfernen alle Interaktionsmöglichkeiten, die dafür nicht benötigt werden. Die Funktionen bringen sie in eine logische Reihenfolge.
Sie wollen mit Marketing und Backend-Entwicklung zeitgleich beginnen. Für diese Bereiche beginnen sie, die Dauer der Umsetzung abzuschätzen. Der Videochat soll als Webanwendung laufen. Dafür braucht es ein Grundgerüst der Weboberfläche, das sie später erstellen werden. Um die Weboberfläche aufzusetzen, braucht es einen Testserver und entsprechende Möglichkeiten, Anwendungen zu starten. So denken sie sich Schritt für Schritt durch, bis sie bei planbaren Arbeitspaketen für den Backend-Bereich angekommen sind.
Für den Bereich Marketing will Zou mehr über ihre Zielgruppe in Erfahrung bringen. Sie möchte die Methode „Personas“ anwenden (dazu in einem späteren Artikel mehr), und dafür ist eine Recherche notwendig. Zou kann den Aufwand bereits abschätzen. In wenigen Tagen sollte sie genug Statistiken gesammelt und bewertet haben. Sie vergibt dem Arbeitspaket damit 7 Punkte.
In diesem Sinne arbeiten die drei sich durch die Bereiche Backend-Entwicklung und Marketing. Für sie sind drei Dinge dabei immer wichtig:
- Den minimalen Funktionsumfang immer im Auge zu behalten,
- einen groben Plan für die nächsten Monate aufzustellen,
- nur so viele der Arbeitspakete zu detaillieren, dass die nächsten 4–6 Wochen gefüllt sind.
Sie legen fest, was jeder in den kommenden zwei Wochen bearbeiten wird. Über den Arbeitsfortschritt möchten sie sich alle zwei Tage kurz austauschen. Damit beginnen die drei ihren ersten Sprint.
Hinweis: Dieser Artikel ist Teil unserer Serie über effektive Projektplanung. Schaue dir auch unsere anderen Beiträge an, um mehr über agiles Arbeiten, Projektmanagement und Selbstorganisation zu erfahren.
Hast du Fragen zur Detailplanung oder möchtest du deine Erfahrungen teilen? Hinterlasse einen Kommentar oder diskutiere mit uns auf X oder LinkedIn!