Stellen Sie sich ein typisches Status-Meeting am Montag vor. Ihr Team hat Dutzende Tickets in Redmine, und jedes davon hat einen Verantwortlichen und ein Fälligkeitsdatum.

.

Trotzdem lautet die ehrliche Antwort auf die Frage des Auftraggebers, ob das Release noch im Plan liegt: „Kommt darauf an.“ Die Aufgabenverfolgung zeigt, woran jede einzelne Person arbeitet. Sie zeigt nicht, ob das Projekt als Ganzes pünktlich fertig wird.

Aufgabenverfolgung vs. Projektplanung in Redmine

Die erste Aufgabe erledigt Redmine sehr gut. Tickets werden zugewiesen, Status ändern sich, Zeit wird erfasst, und jeder sieht, wer wofür verantwortlich ist. Für ein kleines Team mit kurzem Planungshorizont reicht das oft aus.

Wenn Projekte wachsen, kommen jedoch andere Fragen auf, die eine Ticketliste nicht beantworten kann:

  • Liegen wir tatsächlich im Zeitplan?
  • Welche Aufgaben blockieren den Fortschritt?
  • Was passiert, wenn ein Teammitglied eine Frist verpasst?
  • Wirkt sich diese Verzögerung auf das finale Release aus?
  • Halten wir uns noch an den ursprünglichen Projektplan?

Bei jeder dieser Fragen geht es um Zusammenhänge: Was wartet auf eine verspätete Aufgabe, wie viel Puffer hat der restliche Plan, und wie weit hat sich der Zeitplan von der Version entfernt, auf die sich alle geeinigt haben? Die Fortschrittsverfolgung über den Ticketstatus zeigt, was erledigt ist. Erst die Projektplanung macht daraus einen Liefertermin, den Sie vertreten können. Die folgenden Abschnitte gehen die Fragen der Reihe nach durch.

Redmine für die Projektplanung: was Sie standardmäßig bekommen

Bevor Sie etwas ergänzen, lohnt sich ein klarer Blick darauf, was eine Standardinstallation von Redmine bereits bietet. Das ist mehr, als viele Teams nutzen:

  • Termine und Schätzungen für jedes Ticket, mit über- und untergeordneten Aufgaben zur Strukturierung der Arbeit.
  • Beziehungen zwischen Tickets. Vorgänger- und Nachfolger-Beziehungen legen fest, dass eine Aufgabe erst beginnen kann, wenn eine andere abgeschlossen ist; zusätzlich lässt sich ein Versatz angeben. Verschiebt sich das frühere Ticket nach hinten, schiebt Redmine das nachfolgende mit.
  • Versionen mit Fälligkeitsdaten, die als Release-Meilensteine dienen und den Fortschritt in der Roadmap zeigen.
  • Das Gantt-Diagramm, das Tickets und Versionen auf einer Zeitachse darstellt und die Beziehungen als Pfeile anzeigt.
  • Gespeicherte Abfragen und CSV-Export, die für Statusberichte und eine manuelle Kopie des Plans genügen.

Für ein kleines Team funktioniert das bereits als Redmine für die Projektplanung. Die Lücken zeigen sich, wenn der Zeitplan wächst. Redmine berechnet keinen kritischen Pfad (eine Anfrage, ihn im Gantt-Diagramm anzuzeigen, ist auf redmine.org seit 2013 offen), es gibt keine integrierte Möglichkeit, den genehmigten Plan neben dem aktuellen festzuhalten, und jede Terminänderung läuft über das Ticketformular.

Wo das Redmine Gantt-Diagramm an seine Grenzen stößt

Das Gantt-Diagramm ist das Herzstück dieses Werkzeugkastens, und ein Gantt-Diagramm für die Projektplanung muss mehr leisten, als Termine anzuzeigen.

Das Standard-Gantt-Diagramm bietet einen nützlichen Überblick über Tickets, Termine und Beziehungen. Es ist jedoch kein interaktiver Planungsarbeitsplatz: Um Termine zu ändern, müssen Tickets bearbeitet werden, und die weiteren Auswirkungen einer geplanten Änderung zu verstehen, kostet zusätzlichen Aufwand. Ein Projektmanager, der einen Meilenstein um eine Woche verschiebt, öffnet am Ende ein Dutzend Tickets, und Abhängigkeiten in einer langen Aufgabenliste nachzuvollziehen, braucht Zeit. Zwei Fragen bleiben zudem offen: Welche Aufgaben bestimmen den Endtermin, und wie verhält sich der heutige Zeitplan zum genehmigten?

Das ist der Unterschied zwischen dem Betrachten eines Zeitplans und seiner Steuerung. Betrachten ist eine Frage der Darstellung. Steuern heißt, den Plan ändern, die Folgen der Änderung sehen und sie mit dem Team abstimmen zu können. Planner bringt die Bearbeitung des Zeitplans, sichtbare Abhängigkeiten und die Prüfung von Änderungen direkt ins Diagramm. Genau um diese Art von Redmine Gantt-Alternative geht es in diesem Artikel: ein Diagramm, das in Redmine bleibt, sich aber bearbeiten lässt – kein separates Tool.

Alles beginnt mit einem guten Überblick. Wenn Verantwortliche, Termine und Dauern auf einer gemeinsamen Projektzeitachse liegen, erfassen Sie das Projekt auf einen Blick, statt es aus Ticketlisten zu rekonstruieren. Hier ist ein Release-Plan mit zehn Aufgaben in RedmineUP Planner, dem Plugin, auf das wir später in diesem Artikel zurückkommen.

Redmine Gantt-Diagramm mit Projektzeitachse, Aufgaben und zugewiesenen Teammitgliedern

Behalten Sie Zeitplan, Aufgaben und Verantwortlichkeiten Ihres Projekts in einem Redmine Gantt-Diagramm im Blick.

Aufgabenabhängigkeiten: wie eine Verzögerung das ganze Projekt verschiebt

Die meisten Projektverzögerungen entstehen nicht durch einen spektakulären Fehlschlag. Sie entstehen durch einen kleinen Verzug bei einer Aufgabe, von der andere Aufgaben stillschweigend abhängen.

Nehmen wir ein typisches Software-Release: Backend-Entwicklung → Integration → QA-Tests → Release. Die Backend-Arbeit war für zwei Wochen geplant und dauert drei. Die Integration kann erst beginnen, wenn das Backend fertig ist, also verschiebt sie sich. QA kann erst starten, wenn die Integration abgeschlossen ist, also verschiebt sich auch QA. Der Release-Termin, der einem Kunden letzten Monat zugesagt wurde, verschiebt sich mit. Nach dem ersten Verzug hat niemand einen Fehler gemacht. Der Zeitplan hat einfach getan, was Abhängigkeiten nun einmal bewirken.

Am größten ist der Schaden, wenn der Verzug spät entdeckt wird. Erfahren Sie erst dann, dass die Integration blockiert ist, wenn der Backend-Entwickler mit einer Woche Verspätung „fertig“ meldet, sind Ihre Optionen begrenzt. Sehen Sie die Kette im Voraus, können Sie eine Person hinzunehmen, den Umfang kürzen oder Erwartungen neu setzen, solange das noch wenig kostet.

Deshalb sollte ein Projektmanager Abhängigkeiten verstehen, bevor er eine Frist ändert oder eine Lieferzusage macht. Fragen Sie bei jeder Terminverschiebung: „Was wartet auf diese Aufgabe?“ Mit den Beziehungen in Redmine halten Sie die Antwort fest, und ein visuelles Diagramm macht sie schnell lesbar.

Im Screenshot unten verbinden Pfeile jede Aufgabe mit den Aufgaben, die von ihr abhängen. Einer davon ist rot dargestellt. Hier sind die Frontend-Screens so terminiert, dass sie mit der nachfolgenden Integrationsaufgabe kollidieren. Ein solcher Konflikt geht in einer Liste leicht unter, ist auf einer Zeitachse aber offensichtlich – so lässt er sich im Planungsmeeting beheben, statt erst im Test aufzufallen.

Redmine Gantt-Diagramm zur Projektplanung mit Aufgabenabhängigkeiten und Terminkonflikten

Verstehen Sie, wie Aufgaben voneinander abhängen, und erkennen Sie Terminkonflikte, bevor sie die Projektlieferung gefährden.

Kritischer Pfad in Redmine: welche Aufgaben den Endtermin bestimmen

Sobald Sie Abhängigkeiten sehen, stellt sich eine zweite Frage: Wenn alles miteinander verbunden ist, welche Verzögerungen sind dann am wichtigsten?

Die Antwort liefert die Methode des kritischen Pfads (Critical Path Method, CPM), ein Standardverfahren der Terminplanung. Der kritische Pfad ist die Folge abhängiger Aufgaben mit der längsten Gesamtdauer, die den frühestmöglichen Projektabschluss bestimmt. Aufgaben auf diesem Pfad haben einen Gesamtpuffer von null: Verzögert sich eine von ihnen, verschiebt sich das Projektende, sofern das Team die Zeit nicht an anderer Stelle aufholt. Aufgaben außerhalb des Pfads haben etwas Spielraum.

Dieser Spielraum heißt Puffer (Float), und es gibt ihn in zwei Formen:

  • Gesamtpuffer (Total float) gibt an, wie lange sich eine Aufgabe verzögern darf, ohne den Endtermin des Projekts zu verschieben.
  • Freier Puffer (Free float) gibt an, wie lange sich eine Aufgabe verzögern darf, ohne den Start der nachfolgenden Aufgabe zu verschieben.

Puffer wird in Arbeitstagen gezählt. Eine Aufgabe mit 12 Tagen Gesamtpuffer kann sich um 12 Arbeitstage verzögern, bevor der Endtermin betroffen ist – vorausgesetzt, sonst verschiebt sich nichts in ihrer Kette. Ein negativer Wert bedeutet, dass der Plan in seiner aktuellen Terminierung den Endtermin nicht halten kann oder dass eine Abhängigkeit verletzt ist, etwa wenn eine Aufgabe später endet, als ihr Nachfolger es zulässt.

Deshalb verändert das die Prioritäten. Stellen Sie sich zwei Tickets vor, beide in Redmine mit „Hoch“ markiert. Das eine ist die Integrationsarbeit auf dem kritischen Pfad. Das andere ist die Einrichtung einer Staging-Umgebung, von der nichts Dringendes abhängt. Verzögert sich die Integration um zwei Tage, verschiebt sich das Release um zwei Tage, es sei denn, das Team holt die Zeit anderswo auf. Verzögert sich die Staging-Umgebung um eine Woche, ändert sich der Release-Termin nicht. Prioritätslabels können Ihnen das nicht sagen, der kritische Pfad schon. Ohne ihn setzen Teams ihre besten Leute oft auf die lautesten Aufgaben oder auf die mit dem nächsten Fälligkeitsdatum statt auf jene, die die Lieferung tatsächlich steuern.

Standard-Redmine enthält keine Analyse des kritischen Pfads, deshalb verzichten viele Teams entweder darauf oder pflegen sie in einem separaten Tool, das schnell veraltet. Im Screenshot ist die kritische Kette rot hervorgehoben, und jede Aufgabe trägt einen Pufferwert. Backend, Integration, QA und Release stehen bei null. Die Staging-Umgebung und das Kunden-Webinar haben 12 Arbeitstage Puffer. Die Frontend-Screens zeigen einen negativen Wert: Sie enden später, als die nachfolgende Aufgabe es zulässt – derselbe Konflikt, der schon im vorherigen Screenshot markiert war, und er erfordert Aufmerksamkeit.

Redmine Gantt-Diagramm mit hervorgehobenem kritischem Pfad und Aufgabenpuffer

Erkennen Sie die kritischen Aufgaben, die Ihren Projektabschluss direkt beeinflussen, und konzentrieren Sie die Kräfte des Teams dort, wo es darauf ankommt.

Projekt-Baselines: die Planausführung messbar halten

Auch ein gut aufgebauter Plan hat ein Haltbarkeitsdatum. Anforderungen ändern sich, Mitarbeitende werden für andere Arbeit abgezogen, ein Lieferant ist spät dran. Jede Änderung ist klein und nachvollziehbar, und jede wird in einem eigenen Ticket an einem eigenen Tag vorgenommen.

Nach ein paar Monaten ist der ursprüngliche Plan verschwunden. Niemand erinnert sich an die genehmigten Termine, und die Beurteilung der Planausführung wird zur Ansichtssache. Die eine sagt, das Projekt liege „etwa eine Woche zurück“, der andere sagt „zwei“, und ein Manager, der einem Kunden erklären muss, warum sich der Liefertermin verschoben hat, kann nicht klar zeigen, wo die Zeit geblieben ist.

Eine Projekt-Baseline (Basisplan) löst dieses Problem. Eine Baseline ist ein gespeicherter Schnappschuss des genehmigten Zeitplans. Sie hält die geplanten Start- und Fälligkeitsdaten fest, nicht Schätzungen, Zuständigkeiten oder andere Ticketeigenschaften. Sie bleibt unverändert, und Sie können den aktuellen Zeitplan jederzeit mit ihr vergleichen. Statt eines vagen Gefühls, dass etwas aus dem Ruder läuft, erhalten Sie konkrete Informationen: welche Aufgaben sich verschoben haben, in welche Richtung und um wie viele Tage.

Das bringt drei Dinge, die Teams meist fehlen:

  • Verbindlichkeit. Der Plan, auf den sich alle verpflichtet haben, ist dokumentiert und kann nicht stillschweigend umgeschrieben werden.
  • Realistische Prognosen. Ein Muster kleiner Verzögerungen in einem Bereich ist ein frühes Warnsignal – und ehrlicher, als am Ende einfach „Puffer“ draufzuschlagen.
  • Transparente Kommunikation. „Das Release liegt vier Tage hinter dem genehmigten Plan, und hier sind die drei Aufgaben, die das verursacht haben“ ist ein besseres Gespräch mit dem Auftraggeber als „Wir hatten ein paar Probleme“.

Im Screenshot hat das Team beim Kickoff eine Baseline namens „Initial plan“ gespeichert. Eine dünne Linie unter jedem Balken markiert die ursprünglich geplante Position, und eine Spalte zeigt, um wie viele Arbeitstage sich jede Aufgabe verschoben hat. Die Staging-Umgebung liegt genau dort, wo sie geplant war. Die Landingpage liegt fünf Arbeitstage zurück, die Frontend-Screens sechs und der Release-Rollout vier. Das ist der tatsächliche Stand des Projekts, in Zahlen, bevor irgendjemand raten muss.

Redmine Projekt-Baseline-Vergleich mit geplantem und aktuellem Aufgabenzeitplan

Vergleichen Sie Ihren aktuellen Projektzeitplan mit dem ursprünglichen Plan und erkennen Sie Verzögerungen, bevor sie zu größeren Problemen werden.

Gemeinsame Projektplanung: Änderungen prüfen, bevor sie übernommen werden

Planung ist nichts, was ein Projektmanager allein erledigt, so aufgeräumt das Diagramm auch aussehen mag. Eine Terminänderung ist selten eine private Angelegenheit. Wenn sich eine Aufgabe verschiebt, betrifft das den verantwortlichen Entwickler, aber auch die Person, die von ihr abhängt, den Tester, der auf den Build wartet, und die Teamleitung, die Leute für diese Woche eingeplant hat.

Dennoch passieren Terminänderungen in vielen Teams als unangekündigte Bearbeitungen. Jemand passt die Termine an, die Benachrichtigungen gehen raus, und alle anderen erfahren vom neuen Plan aus ihrem Posteingang. Das ist kein guter Weg, eine Entscheidung zu treffen, die mehrere Personen betrifft.

Eine gesündere Arbeitsweise besteht aus vier Schritten:

  1. Eine Änderung wird vorgeschlagen, nicht einfach übernommen.
  2. Die Betroffenen sehen genau, was sich ändern würde, einschließlich der Folgewirkungen auf andere Aufgaben.
  3. Der Projektmanager prüft die Konsequenzen, bevor er zustimmt.
  4. Erst dann wird der neue Zeitplan zum gültigen Arbeitsplan.

Teams, die so arbeiten, verbringen weniger Zeit mit Korrekturen und überraschenden Umplanungen. Außerdem entsteht ein gemeinsames Verständnis des aktuellen Plans – viel wert, wenn Menschen in unterschiedlichen Zeitzonen oder an verschiedenen Projekten arbeiten.

Der Screenshot zeigt diese Idee in der Praxis. Planner zeichnet Abhängigkeitspfeile und hebt Terminverletzungen hervor. Wirkt sich eine vorgeschlagene Änderung auf Nachfolger-Tickets aus, zeigt die Review-Tabelle die daraus resultierenden Terminänderungen, bevor sie in Redmine übernommen werden. Hier wartet eine vorgeschlagene Änderung an den Frontend-Screens in einem gemeinsamen Draft, mit alten und neuen Terminen nebeneinander und dem Namen des Autors. Der Dialog weist außerdem darauf hin, dass Redmine die Integrationsaufgabe dadurch ans Monatsende verschieben würde. In die echten Tickets wurde noch nichts geschrieben, und das Team kann entscheiden, was übernommen wird.

Redmine Planner mit gemeinsamem Draft zur Prüfung von Änderungen am Projektzeitplan

Prüfen Sie vorgeschlagene Terminänderungen und deren Auswirkungen, bevor Sie sie in Ihr Redmine-Projekt übernehmen.

RedmineUP Planner: eine Redmine Gantt-Alternative für die Projektplanung

All das lässt sich auch mit Disziplin, Tabellen und viel Geduld umsetzen. RedmineUP Planner ist eine Projektplanungssoftware, die diese Praktiken in einem Workflow direkt in Redmine zusammenführt – auf Basis der Tickets, mit denen Ihr Team ohnehin arbeitet. Sie planen in einem bearbeitbaren Gantt-Diagramm, in dem Abhängigkeiten als Pfeile dargestellt und Verletzungen markiert werden. Vorgeschlagene Änderungen warten in einem gemeinsamen Draft, bis jemand sie prüft und übernimmt, und kritischer Pfad, Baselines und Versionsmeilensteine liegen im selben Diagramm.

Der praktische Nutzen liegt nicht in einer einzelnen Funktion. Terminänderungen lassen sich an einem Ort leichter besprechen, prüfen und steuern, und Redmine bleibt die maßgebliche Quelle für die eigentliche Arbeit.

Planner verbindet das bearbeitbare Gantt-Diagramm, den gemeinsamen Draft mit Review und Apply, Abhängigkeiten und Undo/Redo mit erweiterten Planungsfunktionen: Analyse des kritischen Pfads mit Gesamt- und freiem Puffer, Baselines mit Abweichungsspalte, Gruppierung, zusätzliche Abfragespalten, Balkenfarben und Versionsmeilensteine. Details finden Sie auf der Planner-Seite und in der Dokumentation.

Planner arbeitet auch mit dem übrigen RedmineUP-Stack zusammen. Teams, die in Sprints arbeiten, können ihre Boards im Agile-Plugin führen, und Manager, die Mitarbeitende projektübergreifend auslasten müssen, können das Resources-Plugin ergänzen. Einen breiteren Überblick über die Möglichkeiten bietet unser Leitfaden zu den besten Redmine-Plugins für das Projektmanagement, oder stöbern Sie im vollständigen Verzeichnis der Redmine-Plugins.

Machen Sie Gantt-Projektplanung zum Teil Ihres Redmine-Workflows

In Redmine organisiert Ihr Team bereits seine Arbeit. Mit besseren Planungspraktiken kann Redmine auch der Ort sein, an dem Sie den Zeitplan planen, Abhängigkeiten verstehen und die Planausführung verfolgen – ohne den Plan in ein separates Tool auszulagern, das niemand aktualisiert.

Wenn Sie ohne Installation starten möchten, beginnen Sie mit einer kleinen Gewohnheit. Wählen Sie ein laufendes Projekt und stellen Sie die fünf Fragen vom Anfang dieses Artikels. Jede Frage, die Sie mit Ihrem aktuellen Setup nicht beantworten können, zeigt eine Lücke in Ihrer Projektplanung. Diese Liste ist ein guter Ausgangspunkt für das Gespräch darüber, was Ihr Team als Nächstes braucht.

Für Teams, die über die reine Aufgabenverfolgung hinausgehen wollen, ist RedmineUP Planner der nächste Schritt. Öffnen Sie die Live-Demo, wählen Sie Planner und testen Sie den kritischen Pfad, Baselines und die Draft-Prüfung mit Beispieldaten. Wenn Sie so weit sind, installieren Sie Planner in Ihrem eigenen Redmine (5.0 bis 7.0).

RedmineUP Planner erhalten