Neues von knütt un kant

Warum Planung und operative Arbeit zusammen gedacht werden müssen

In rein agilen Setups ist die Tool-Landschaft oft strukturell erstaunlich einfach. Ein gemeinsames Backlog, ein Ticket-System, klare Iterationslogik – Planung und operative Arbeit sind eng gekoppelt. Die zeitliche Struktur entsteht über Timeboxes und nicht über langfristige Terminabhängigkeiten. Systeme wie z.B. Jira, Trello oder GitLab bilden genau diese Logik ab: Arbeit wird in Tickets zerlegt, priorisiert, in ein Board gezogen und innerhalb einer Iteration abgeschlossen.

Die eigentliche Komplexität beginnt häufig dann, wenn Organisationen klassische (prädiktive) oder hybride Projektmodelle einsetzen. Also dann, wenn langfristige Meilensteine, projektübergreifende Abhängigkeiten und geteilte Ressourcen berücksichtigt werden müssen. Gleichzeitig soll die operative Arbeit möglichst nah am Team bleiben.

Hier entscheidet die Tool-Architektur darüber, wie stark Planung und Ausführung miteinander verbunden sind.

Standalone-Planungstools wie Microsoft Project haben eine klare Stärke: Sie modellieren Terminlogik, Abhängigkeiten und kritische Pfade sehr präzise. In klassischen, stark deterministischen Umgebungen kann das sinnvoll sein. Problematisch wird es, wenn das Planungssystem organisatorisch vom Ort der tatsächlichen Arbeit getrennt ist. Der Plan lebt im Planungstool, während die Realität im Ticketsystem, im Code-Repository oder im Labor entsteht. Ohne disziplinierte Synchronisation entstehen zwangsläufig Abweichungen.

Ticket-basierte Systeme sind in dieser Hinsicht oft robuster. Sie koppeln Planung und operative Arbeit enger. Statusänderungen entstehen dort, wo Arbeit tatsächlich stattfindet. Die Terminlogik ist häufig weniger ausgeprägt, dafür ist die Rückkopplung zur Realität direkter.

ERP-integrierte PM-Module wie z.B. SAP Project System innerhalb von SAP ERP sind besonders stark in der Integration von Termin-, Kosten- und Ressourcenlogik mit bestehenden Unternehmensprozessen. In entsprechend strukturierten Organisationen können sie durchaus auch operativ genutzt werden. Die entscheidende Frage ist jedoch, wo die tägliche Entwicklungsarbeit tatsächlich stattfindet – und wie eng Planung und operative Realität technisch gekoppelt sind.

All diese Werkzeuge sind legitim. Sie optimieren jedoch unterschiedliche Prozesse.

In prädiktiven oder hybriden Umgebungen entsteht die eigentliche Herausforderung genau hier: Terminlogik, Ressourcenplanung, Portfolio-Sicht und operative Kopplung sollen gleichzeitig erfüllt werden. Wer nicht klar priorisiert, wofür das System in erster Linie da ist, baut sich eine Tool-Landschaft, die viel kann – aber wenig wirklich gut.

Wenn man akzeptiert, dass nicht jedes System alles optimieren kann, wird die Frage nach bewusst reduzierten Lösungen legitim. Ein Beispiel ist Redmine. Ursprünglich als Issue-Tracking-System konzipiert, lässt es sich mit Bordmitteln um Meilensteine, Vorgänger-/Nachfolger-Beziehungen mit Verzögerungen und Gantt-Darstellungen erweitern. Es bleibt dabei eng am ticketbasierten Arbeiten und verzichtet bewusst auf umfassende Portfolio-Optimierung oder tief integrierte ERP-Logik. 

Für viele Engineering-Organisationen kann gerade diese Reduktion ein Vorteil sein. Redmine ist Open Source, selbst hostbar und technisch transparent. Es zwingt nicht in ein komplexes Lizenz- oder ERP-Ökosystem. Gleichzeitig bleibt es näher an der operativen Arbeit als reine Terminplanungssoftware. Wer zusätzliche Funktionen oder kommerziellen Support benötigt, findet im Redmine-Ökosystem sowohl Erweiterungen als auch kommerzielle und gehostete Varianten (z.B. AlphaNodes, Easy Redmine, Planio oder OpenProject).

Tool-Architektur ist keine reine Softwareentscheidung. Sie ist Ausdruck dessen, wie eine Organisation Projekte strukturiert, priorisiert und steuert. Wer Terminlogik, operative Arbeit und finanzielle Transparenz gleichzeitig optimieren will, muss zunächst klären, welche Prozesse geschäftskritisch sind und welche Komplexität wirklich notwendig ist.

Ein begleitendes Video zu diesem Beitrag zeigt exemplarisch, wie ein Redmine-Setup sowohl klassische als auch agile Projektstrukturen abbilden kann – bewusst schlank, aber strukturell konsistent. Es soll keine Idealarchitektur darstellen, sondern eine mögliche Antwort auf die Frage, wie Planung und operative Arbeit enger zusammengeführt werden können. Wer Interesse an einer ausführlicheren Demonstration oder einem fachlichen Austausch hat, kann sich gerne direkt melden.

Wenn Sie Ihre eigene Tool-Landschaft oder Projektstruktur strategisch hinterfragen möchten, unterstützen wir Sie im Rahmen unserer Projektmanagement-Beratung gerne bei der Analyse und Weiterentwicklung Ihrer Prozesse.

Am Ende bleibt immer die gleiche Grundfrage: Es geht nicht darum, welches Tool am meisten kann, sondern welches Ihre Arbeitsweise am sinnvollsten unterstützt.