Projektplan erstellen: Vorgehen und Beispiele im Überblick

Was ist ein Projektplan?

Der Projektplan ist ein zentrales Dokument im Projektmanagement, das die Ziele, Aufgaben, Zeitpläne und Ressourcen eines Projekts strukturiert festhält. Er ergibt sich aus der Summe aller Teilpläne und dient als Leitfaden für das gesamte Projektteam. Er stellt zudem sicher, dass alle Beteiligten auf dasselbe Ziel hinarbeiten. Ein Projektplan umfasst in der Regel mindestens folgende Elemente:

• Projektziele
• Umfang des Projekts (was eingeschlossen und ausgeschlossen ist)
• Projektstrukturplan
• Zeitplan (mit Meilensteinen und Fristen)
• Ressourcenplan (Personal, Materialien, Budget)
• Risikobewertung

und beantwortet folgende W-Fragen:

• WAS ist zu tun?
• WER kümmert sich darum?
• WANN muss es erledigt werden?
• WIEVIEL Aufwand erfordert es?

Ein gut durchdachter Projektplan ist entscheidend für den Projekterfolg, da er den Rahmen für die Projektsteuerung und das Monitoring bietet. Er ermöglicht es, den Fortschritt regelmäßig zu überprüfen und bei Bedarf Anpassungen vorzunehmen, um das Projektziel termingerecht und im vorgesehenen Budgetrahmen zu erreichen.

Um einen Projektplan zu erstellen und ihn während des Projektablaufs immer wieder anpassen zu können, empfiehlt es sich, eine Projektmanagement-Software wie Allegra einzusetzen. Ein solches Tool stellt sicher, dass alle Stakeholder, das Management und sonstige Projektbeteiligte informiert sind, jeder weiß, was er zu tun hat und der aktuelle Stand des Projekts jederzeit abrufbar ist.

Projektplan vs Projekthandbuch

Ein gut geführtes Projekt hat immer ein Projekthandbuch. Der Zweck des Projekthandbuchs ist es, den projektspezifischen Prozess zu beschreiben. Das Projekthandbuch listet z.B. die Rollen mit ihren Verantwortlichkeiten und Zuständigkeiten, nennt aber nicht die Personen, denen eine Rolle zugewiesen wurde. Das Projekthandbuch legt z.B fest, das es für jede Komponente ein Testprotokoll geben muss. Es benennt aber nicht die verschiedenen Komponenten. Das Projekthandbuch benennt also nur die Klassen der zu erstellenden Artefakte, aber nicht ihre Instanzen. Im Gegensatz dazu wird im Projektplan jede Instanz betrachtet.

Projektplan vs Projektstrukturplan

Der Projektstrukturplan ist eine geordnete Sammlung der Teilaufgaben und Arbeitspakete eines Projekts. Die in ihm enthaltene Information ist nur ein Teil der für einen Projektplan notwendigen Informationen. So berücksichtigt z.B. der Projektstrukturplan keine logischen Abhängigkeiten zwischen Arbeitspaketen und Aufgaben und auch Risiken werden nicht näher betrachtet. Ein Projektstrukturplan kann ein nützlicher Bestandteil eines Projektplans sein, wird in der Praxis aber oft direkt in Form eines Gantt-Diagramms dargestellt.

Projektplan vs Projektmanagementplan

Der PMBOK Guide (Project Management Body of Knowledge) des Project Management Institute (PMI) bezeichnet den Projektplan als Projektmanagementplan. Die beiden Begriffe sind also synonym. Ein weiteres Synonym ist der Begriff "Arbeitsplan".

Schritt 1: Ziele und Anforderungen definieren

Ziele definieren

Mark Twains berühmter Spruch: “Als wir das Ziel aus den Augen verloren hatten, verdoppelten wir unsere Anstrengungen” wird auch heute noch gerne bei der Projektarbeit beherzigt. Vor Beginn eines Projektes muss klar sein, welche Ziele erreicht werden sollen. Jede Unklarheit erhöht das Risiko, am Ende des Projekts etwas anderes zu bekommen, als man sich vorgestellt hat, oder zu einem höheren Preis oder zu einem späteren Termin, oder alles zusammen. Die SMART-Ziele-Methode hilft, zu guten Zielen zu kommen.

Lösungskonzept als Projektziel-Definition

Die Beschreibung des gewünschten Projektergebnisses ist essentielle Grundlage für jeden Projektplan. Sie erfolgt im deutschsprachigen Raum häufig in Form eines Lastenheftes und eines Pflichtenheftes. In der Praxis eignet sich oft ein einziges, gemeinsam von Auftraggeber und Auftragnehmer erstelltes Lösungskonzept bzw. ein Bauplan besser als die rein anforderungsbetonte Sicht in Lasten- und Pflichtenheft.

Die Beschreibung des Projektziels in Form von Anforderungen bzw. eines Lösungskonzepts erfordert vom Autor eine klare innere Vorstellung. Je konkreter und detaillierter diese ist, desto zuverlässiger lässt sich später planen. Ein unerfahrener Autor wird viele Punkte gar nicht bedenken und somit auch nicht für eine Planung vorsehen.

Ziele als High-Level-Anforderungen

Worin unterscheiden sich die Ziele von den Anforderungen? Eine nützliche Ansicht ist: gar nicht! Die Ziele sind die oberste, abstrakteste Ebene der Anforderungen. Die Anforderungen werden im Laufe der Zeit immer detaillierter, während die Ziele sich nicht mehr wesentlich ändern.

Twin-Peaks-Modell praxisbewährt

In der Praxis hat sich für das Erarbeiten der Anforderungen und eines Lösungskonzepts das “Twin-Peaks”-Modell als hilfreich erwiesen. Es macht klar, dass man sich schon beim Schreiben der Anforderungen auch im Lösungsraum bewegen muss und darf, weil man sonst im Problemraum viele offene Fragen gar nicht erkennt. Das zentrale Ergebnis ist ein Lösungskonzept, dass das gewünschte Projektergebnis für Auftraggeber und Auftragnehmer gleichermaßen verständlich in geeigneter Form (Tabellen, Text, Diagramme) beschreibt.

Schritt 2: Projektstrukturplan erstellen

Auf der Basis der Ziele, Anforderungen oder eines Lösungskonzepts erstellen Sie im zweiten Schritt einen Projektstrukturplan (PSP). Der PSP zeigt die gesamte Projektstruktur in hierarchischer Form, indem er das Projekt in Teilprojekte, Teilaufgaben und Arbeitspakete unterteilt. Dadurch wird das Projekt für das Team verständlicher und leichter handhabbar und es gibt eine belastbare Basis für die Ablauf-, Ressourcen- und Kostenplanung.

Sie können sich den Projektstrukturplan als die Übersetzung des Lösungskonzepts oder der Anforderungen in eine hierarchische Baumstruktur vorstellen.

Teilprojekte ermöglichen es, innerhalb eines Gesamtprojekts unterschiedliche Prozessmodelle zu nutzen. So kann es z.B. sinnvoll sein, für die Entwicklung einer Elektronik in einem Teilprojekt eine klassische Wasserfall-Methode zu nutzen und für die zugehörige Softwareentwicklung in einem Teilprojekt mit agilen Methoden zu arbeiten.

Teilaufgaben sind Elemente, die im Projektstrukturplan weiter aufgegliedert werden können.

Arbeitspakete stellen die unterste Ebene eines Projektstrukturplans dar und können im weiteren Planungsprozess in Vorgänge oder Aufgaben gegliedert werden.

Es gibt verschiedene Ansätze zur Strukturierung: objektorientiert (basierend auf physischen Komponenten), funktionsorientiert (nach Aufgabenbereichen) oder phasenorientiert (entlang des Projektablaufs).

Dieses Herunterbrechen in einzelne Arbeitspakete macht das Projekt überschaubar, kalkulierbar und zielgerichtet durchführbar. Zu diesem Zeitpunkt geht es noch nicht um logische Abhängigkeiten, Aufwände und Ressourcen. Eine ausführliche Anleitung zum Erstellen eines Projektstrukturplans finden Sie im Beitrag “Der Projektstrukturplan schafft Ordnung“.

Schritt 3: Aufwände abschätzen

EIn wesentliches Element der Projektplanung ist die Aufwandsschätzung. Es gibt zahlreiche Methoden und Ansätze für Abschätzungen. Leider kann keines dieser Verfahren Erfahrung mit einem ähnlichen Projekt ersetzen. Viele Modelle für Aufwandsschätzungen haben Parameter, die erst kalibriert werden müssen. Ohne Rückgriff auf vorherige Projekte hat man diese Parameter aber nicht und damit haben die Modelle nur geringen Nutzen.

Erfahrungen zusammentragen

Wenn ein Projektplan zu erstellen ist gilt wie nirgendwo anders: Erfahrung ist durch nichts zu ersetzen! Es gibt viele Verfahren zur Aufwandsschätzung, die alle darauf basieren, dass das neue Projekt sich durch ein bestehendes, empirisch gesichertes Modell adäquat beschreiben lässt. Das funktioniert mal besser und mal schlechter. Bei einem Wohnhaus kann man z.B. den umbauten Raum als eine Maßzahl nehmen, bei einer Kirche auch. Hat man genügend Wohnhäuser gebaut, weiß man beim nächsten schon recht gut Bescheid, wie lange es dauern wird und was es kosten wird. Nähme man die gleichen Zahlen für eine Kirche, läge man ziemlich weit daneben.

Gibt es keine Erfahrungen mit ähnlichen Vorhaben, ist die Aufwands- und Terminplanung höchst spekulativ und man sollte mit gravierenden Abweichungen rechnen. “Teurer” und “später” ist die übliche Richtung der Differenz zwischen Planung und Umsetzung, was wahrscheinlich auch daran liegt, dass viele Auftraggeber nicht wissen wollen, wie teuer es wirklich wird und gerne den Zuschlag denen geben, die ihnen erzählen, was sie hören möchten.

Ähnliche Vorgängerprojekte

Die zuverlässigsten Planungen und Abschätzungen stützen sich auf ähnliche Vorgängerprojekte. Sie nehmen nicht an, dass der allgemeine technische Fortschritt beim neuen Projekt den Aufwand merklich reduziert.

Schätzung durch späteren Verantwortlichen

Wichtig ist, dass die Aufwandsschätzung von denen abgegeben werden, die für die Umsetzung verantwortlich sind. Planungen am grünen Tisch enden doch oft mit einem blauen Auge. In manchen Technologiebereichen spielt die Performanz des einzelnen Teammitglieds eine wesentliche Rolle. Insbesondere im Bereich der Wissensarbeit sind Produktivitätsunterschiede von 500% nicht ungewöhnlich. Außer bei sehr großen Teams, wo sich diese Unterschiede ausmitteln, sollten Sie deshalb Ihre Teammitglieder kennen und bei der Aufwandsschätzung mit einbeziehen.

Aufwände nicht herunterhandeln

Handeln Sie den von Ihren Teammitgliedern genannten Aufwand nicht herunter. In der Regel unterschätzen Ihre Mitarbeiter die auftretenden Friktionen und überschätzen ihre Produktivität.

Kategorisieren Sie Vorgänge in Aufwandsklassen

Es kann helfen, Vorgänge in Aufwandskategorien einzuteilen. Im agilen Kontext verwendet man gerne sogenannte “Story Points” mit relativen Aufwänden, die in etwa einer Fibonacci-Reihe entsprechen. Man kann auch einfachere Kategorien festlegen, z.B. gering, mittel, groß.

Einen besonderen Gewinn erzielen Sie, wenn Sie am Ende eines jeden Projekts den Durchschnitt des tatsächlichen Aufwands ermitteln und mit den Durchschnitten vorhergegangener Projekte zu einem neuen Durchschnittswert fusionieren. Bei der nächsten Projektplanung geht es dann nur noch um die Kategorisierung der Vorgänge, während der tatsächliche Aufwand sich aus den Kennzahlen vorangegangener ähnlicher Projekte bestimmt.

Gehen Sie nicht von einem Produktivitätsgewinn aus

Wenn Sie denken, dass es diesmal viel schneller geht als beim letzten Mal, sollten Sie eine nüchterne Begründung haben. Neue Tools und Methoden gehören nicht dazu.

Wenn Sie neue Vorgehensweisen zur Steigerung der Produktivität einführen, rechnen Sie damit, dass der erhoffte Gewinn beim ersten mal durch die Einarbeitungsaufwände und mangelnde Erfahrung aufgezehrt wird.

Abschätzungen mit Planungspoker

Der Planungspoker ist eine interessante Methode zur Projektplanung, um zu belastbaren Aufwandsabschätzungen zu kommen. Dazu treffen sich die Schätzenden unter Leitung eines Moderators. Jeder Schätzende erhält einen identischen Stapel Karten. Solche Karten kannst Du kaufen; ein Anbieter verwendet darauf z.B. die Zahlen 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 sowie ein ? für die Aussage, dass ein Schätzer sich nicht in der Lage fühlt, eine Schätzung abzugeben. Die Zahlen können den Aufwand in Tagen bedeuten, oder in einem anderen, vorher festgelegten konstanten Verhältnis zum realen Aufwand stehen.

Zu Beginn stellt ein Produktmanager die zu liefernden Projektergebnisse vor. Das Team kann nachfragen, wenn ihm etwas unklar erscheint.

Danach legt jedes Teammitglied die Karte mit seiner Schätzung verdeckt vor sich auf den Tisch. Wenn jeder seine Karte abgelegt hat, werden die Karten gleichzeitig herum gedreht.

Den Schätzern mit dem höchsten und dem niedrigsten Schätzwert wird Gelegenheit gegeben, ihre Schätzung zu erläutern und zu begründen. Die Gruppe kann über das Vorgebrachte diskutieren. Die Diskussionszeit kann durch den Moderator oder Projektmanager begrenzt werden.

Der Schätzprozess mit anschließender Diskussion wird solange wiederholt, bis die Gruppe einen Konsens erzielt hat. Der für die Lieferung eines Teilergebnisses zuständige Schätzer hat in diesem Prozess immer ein größeres Gewicht als die anderen Teilnehmer.

Die Nummerierung der Karten berücksichtigt, dass die Schätzungenauigkeit umso größer ist, je größer die Schätzung ausfällt. Der Schätzer kann so bei größeren Werten keine vermeintliche Genauigkeit vorspiegeln, sondern muss sich für einen pessimistischen oder optimistischen Wert entscheiden.

Aufwand und Dauer

Ein häufiger Anlass für Verwirrung sind die Begriffe “Aufwand” und “Dauer”. Die “Dauer” oder auch “Vorgangsdauer” ist die Länge des Zeitintervalls zwischen dem Beginn eines Vorgangs und dessen Ende, abzüglich der arbeitsfreien Zeit gemessen in Arbeitstagen.

Der Aufwand oder auch “Arbeitsaufwand” ist die Arbeitszeit, die insgesamt für den Vorgang von seinem Beginn bis zum Ende aufgewendet werden muss.

Einer Betondecke beim Trocknen zuzusehen kann ein paar Tage dauern, doch ist der Arbeitsaufwand gering.

Schritt 4: Ablauf und Meilensteine planen

Bei der Ablaufplanung werden die Arbeitspakete in eine logische Reihenfolge gebracht. Dabei müssen Sie Abhängigkeiten berücksichtigen, z.B. dass bestimmte Arbeitspakete abgeschlossen sein müssen, bevor andere beginnen können.

Abhängigkeiten ermitteln

Die Ablaufplanung erfolgt mit Hilfe einer Vorgangsliste, in der die Reihenfolge der Arbeitspakete festgelegt wird. Die Vorgangsliste enthält die Arbeitspaketnummer, den Namen des Arbeitspaketes (Vorgangs), die geschätzte Dauer des Vorgangs und eventuell schon die für die Ausführung verantwortliche Person (Ressource).

Meilensteine definieren

Für das spätere Monitoring z.B. mit der Meilenstein-Trend-Analyse und eine bessere Übersicht sollten Sie das Ende wichtiger Arbeitspakete oder Teilaufgaben dadurch hervorheben, dass Sie es mit einem Meilenstein verknüpfen. So können z.B. Projektphasen oder bedeutende Zwischenstände markiert werden.

Schritt 5: Termine und Zeiträume planen

Die meisten Vorgänge benötigen Ressourcen (Bearbeiter), die sich um deren Erledigung kümmern. Diese Ressourcen müssen zwischen dem Anfangstermin und dem Endtermin eines Vorgangs verfügbar sein. Die Terminplanung und die Ressourcen-Planung sind also stark miteinander gekoppelt.

Ob man zuerst die Ressourcen den Vorgängen zuweist und so basierend auf den Aufwänden die Termine erhält oder aufgrund festgelegter Termine die Ressourcen zuweist hängt davon ab, in welcher Richtung man flexibel ist. Wenn man weder an der Ressourcen-Verfügbarkeit noch an den Terminen etwas ändern kann, erhält man keinen funktionierenden Projektplan.

Planung Bottom-up und Top-down

Einen Projektplan zu erstellen ist in vielen Organisationen ein iterativer Prozess, bei dem gewünschte oder erforderliche Termine und Budgets zunächst von oben vorgegeben werden. Diejenigen, die für die Ausführung zuständig sind, stellen ihre eigenen Zeit- und Aufwandsabschätzungen dagegen. In solchen Fällen ist es gut, zwischen den geforderten bzw. Wunschterminen und zur Verfügung stehenden Budgets und den Terminen und Aufwänden, zu denen sich ein Bearbeiter verpflichtet, zu unterscheiden.

Rückwärtsplanung mit Meilensteinen

Oft steht der Liefertermin für das Projektergebnis schon am Anfang fest, z.B. aufgrund von Messe-Terminen, Kundenverpflichtungen oder gesetzlichen Vorgaben. In einem solchen Fall bietet es sich an, rückwärts zu planen, d.h. ausgehend vom letzten Termin die Vorgänge so anordnen, das der Anfangstermin des Projektes in der Zukunft liegt.

Schritt 6: Ressourcen planen und Rollen zuweisen

Ressourcen sind im Projektplan alle Menschen und Gegenstände, die zur Ausführung des Plans benötigt werden. Theoretisch ist es effizienter, wenn jeder Mitarbeiter sich jeweils einem Projekt widmen könnte, ohne immer wieder durch andere Aufgaben in seinem Arbeitsfluss gestört zu werden. Das ist allerdings in vielen Fällen nicht realistisch. Zu beachten ist auch, dass die Mitarbeiter für die eigentliche Projektarbeit typischerweise weniger als 80% ihrer Zeit einsetzen können.

Rollen zuweisen

Wenn geklärt ist, welche Ressourcen und Mitarbeiter für das Projekt zur Verfügung stehen, werden die im Projekthandbuch beschriebenen Rollen mit konkreten Personen besetzt. Daraus ergeben sich für diese Personen Verantwortlichkeiten, die sich nicht unbedingt als Arbeitspakete im Projektstrukturplan wiederfinden.

Projektleiter-Sicht und Teamleiter-Sicht

In vielen Organisationen sind Mitarbeiter in Teams und Abteilungen organisiert und werden von ihren Abteilungen den Projekten zu Verfügung gestellt. Um den Überblick über die Auslastung der Mitarbeiter, die ja oft in mehreren Projekten parallel tätig sind, zu behalten, bedarf es einer Darstellung der Ressourcen aus Sicht der Linienorganisation und aus Sicht der jeweiligen Projektleitung, wie es in der Projektmanagement-Software Allegra realisiert ist.

Schritt 7: Kostenplanung und Budget

Kein Projekt sollte ohne Wirtschaftlichkeitsrechnung begonnen werden. Dazu müssen sämtliche anfallenden Aufwände und Kosten bekantt sein. Die Arbeitsaufwände ergeben sich aus dem Projektstrukturplan, Fremdkosten und Materialaufwände spätestens aus der Ressourcenplanung.

Der Kostenplan basiert damit auf den dem Projektplan zugrunde liegenden Schätzungen. Das unterstreicht die Wichtigkeit von möglichst genauen Aufwandsschätzungen, da sie direkten Einfluss auf das Ergebnis einer Wirtschaftlichkeitsprüfung haben.

Schritt 8: Risikoliste erstellen

Jedes Projekt ist Risiken ausgesetzt, die den Projekterfolg gefährden. Eine Risikoliste hilft potenzielle Probleme frühzeitig zu identifizieren und Maßnahmen zu deren Bewältigung zu planen. Sie ermöglicht dem Projektteam, Risiken systematisch zu überwachen und  präventive hilft sie, das Budget und den Zeitplan zu schützen, da Risiken frühzeitig erkannt und adressiert werden, bevor sie das Projekt gefährden.

Beispielprojekt: Website für kleines Unternehmen

Schritt 1: Ziele formulieren und Anforderungen dokumentieren

Die Ziele sind

1. Entwicklung einer benutzerfreundlichen Website für das Unternehmen.
2. Implementierung eines Online-Shops zur Erweiterung der Verkaufsmöglichkeiten.
3. Optimierung der Website für Suchmaschinen (SEO) und mobile Endgeräte.
4. Sicherstellung eines sicheren Bezahl- und Bestellprozesses.

Die Anforderungen dokumentieren wir in einem eigenen Dokument, dass wir wie das Benutzerhandbuch für unser neues System gestalten. Wir nutzen Mockups für die Bedienschnittstelle und UML Use Case- und Sequenzdiagramme, um unsere Anforderungen zu modellieren.

Schritt 2: Projektstrukturplan (PSP) erstellen:

1. Projektinitiierung (Teil von Schritt 1)

   • Anforderungserhebung
   • Zieldefinition und Budgetplanung
   • Kick-off-Meeting

2. Design und Layout

   • Erstellung von Wireframes und Mockups
   • Auswahl der Farbpalette und des Layouts
   • Feedback und Anpassungen

3. Entwicklung der Website

   • Frontend-Entwicklung (HTML, CSS, JavaScript)
   • Backend-Entwicklung (Datenbank, CMS)
   • Integration von E-Commerce-Funktionen

4. Inhalte und SEO

   • Erstellung und Einpflegen der Inhalte (Texte, Bilder, Videos)
   • SEO-Optimierung (Keywords, Meta-Tags, Seitenstruktur)

5. Tests und Qualitätskontrolle

   • Funktionale Tests (Formulare, Buttons, Links)
   • Browser- und Gerätetests (Desktop, Mobile)
   • Sicherheitstests (Zahlungsverkehr, Datenverschlüsselung)

6. Launch und Wartung

   • Website-Launch und Öffentlichkeitsarbeit
   • Fehlerbehebung nach dem Livegang
   • Laufende Wartung und Updates

In Allegra sieht das dann so aus:

Schritt 3: Aufwände abschätzen

Wir schätzen nun für jedes Arbeitspaket den Aufwand ab. Daran beteiligen wir die wahrscheinlichen Verantwortlichen für diese Pakete, soweit diese bekannt sind oder schauen nach anderen erfahrenen Mitarbeitern, die schon einmal ähnliche Aufgaben bearbeitet haben. In den meisten Fällen nehmen wir an, dass der Aufwand der Dauer eines Vorgangs entspricht, abzüglich der für alle arbeitsfreien Tage.

Schritt 4: Ablauf und Meilensteine planen

In diesem Schritt fügen wir die logischen Abhängigkeiten zwischen den Arbeitspaketen ein und setzen auch ein paar Meilensteine. In Allegra sieht das dann so aus:

Schritt 5: Termine und Zeiträume planen

Jetzt planen wir alle Termine, die nicht durch die logischen Abhängigkeiten vorgegeben sind. Wir können auch bestimmte Termine gegen Verschiebungen fixieren, z.B. wenn diese von außen vorgegeben sind. Klug ist es auch, in den kritischen Pfad Puffer einzubauen, um bei unvorhergesehenen Ereignissen noch reagieren zu können.

Schritt 6: Ressourcen planen und Rollen zuweisen

In diesem Schritt weisen wir den einzelnen Arbeitspaketen Bearbeiter bzw. Verantwortliche zu. Dabei müssen die Projektverantwortlichen sicherstellen, dass die Ressourcen auch die erforderliche freie Kapazität haben. Die zugewiesenen Bearbeiter müssen die schon geschätzten Aufwände prüfen und ggfs. anpassen.

In Allegra sieht das dann so aus:

Schritt 7: Kostenplanung und Budget

Ein Projekt sollte wirtschaftlich sein, d.h. es darf einen zuvor ermittelten Kostenrahmen nicht überschreiten. Wir unterscheiden zwischen dem Budget und dem Planwert. Das Budget ist eine Top-Down-Vorgabe, die z.B. aus strategischen Gesichtspunkten oder Wirtschaftlichkeitsgründen so vom Management vorgegeben wird. Der Projektplanwert basiert auf den geschätzten Kosten für alle Arbeitspakete und sonstigen Ausgaben. Er wird Bottom-Up ermittelt. Das Top-Down vorgegebene Budget sollte nie kleiner sein als die Bottom-Up ermittelten Planwerte für die Kosten.

In Allegra tragen wir das Budget auf der obersten Hierarchieebene ein und die Aufwandsschätzungen übernehmen wir für jedes Arbeitspaket in das Feld für den Planwert.

Schritt 8: Risikoliste erstellen

Hier ist eine Beispielliste für mögliche Risiken:

1. Technische Risiken:

   • Risiko: Unzureichende Kompatibilität der Website mit mobilen Endgeräten.
   • Maßnahme: Durchführung umfangreicher Tests auf verschiedenen Plattformen und Geräten.

2. Zeitplanrisiken:

   • Risiko: Verzögerungen bei der Entwicklung aufgrund unvorhergesehener technischer Probleme.
   • Maßnahme: Pufferzeit in den Zeitplan einbauen und regelmäßige Status-Meetings abhalten.

3. Budgetrisiken:

   • Risiko: Budgetüberschreitung durch zusätzliche Features.
   • Maßnahme: Klare Feature-Liste erstellen und Genehmigung von Änderungen einfordern.

4. Qualitätsrisiken:

   • Risiko: Mangelnde Funktionalität oder Fehler beim Launch.
   • Maßnahme: Detaillierte Tests und Qualitätssicherung vor dem Launch.

5. Sicherheitsrisiken:

   • Risiko: Sicherheitslücken im E-Commerce-System.
   • Maßnahme: Einsatz von sicheren Zahlungssystemen und regelmäßige Sicherheitsüberprüfungen.

In Allegra halten wir die Risiken nicht als eigene Vorgänge, sondern als Dokument. Das macht die Handhabung einfacher. So sieht das dann aus:

Schlussbemerkungen

So wie es verschiedene Ansichten über die  Anzahl von Projektmanagement Phasen gibt, kann man auch bei der Projektplanung unterschiedliche Vorgehensweisen finden. Das hier vorgestellte, aus der Praxis kommende Modell, hat den Anspruch, minimalistisch und vollständig zu sein. Unterstützt durch ein starkes Projektmanagement-Tool wie Allegra werden Sie Ihre Projekte zum erfolgreichen Abschluss bringen. Vorlagen für ein Projekthandbuch, Lastenheft und Pflichtenheft finden Sie auf dieser Vorlagen-Seite.