Warum klassische PM-Tools nicht für technisch komplexe Projekte gebaut wurden

Kategorie: Vergleiche & Kategorie-Abgrenzung

Das Datenmodell, mit dem die meisten Projektmanagement-Tools heute arbeiten, stammt aus dem Jahr 1984: Vorgang, Dauer, Abhängigkeit, Ressource, Kalender. Die erste kommerzielle Version von Microsoft Project erschien damals für DOS und rechnete den kritischen Pfad nach der Critical Path Method (Wikipedia: Microsoft Project). Ein Sondermaschinenprojekt bringt jedoch drei Dinge mit, die in diesem Modell schlicht nicht vorkommen: eine Systemstruktur, eine Stückliste und Reifegrade.

Woher kommt das Datenmodell klassischer PM-Tools?

Klassische PM-Tools sind aus der Terminplanung entstanden, nicht aus dem Engineering. Die Ahnenlinie ist gut dokumentiert: Gantt-Diagramm, Netzplantechnik, Critical Path Method. Microsoft Project 1.0 von 1984 richtete sich an Anwender, die vorher keine Projektsoftware genutzt hatten, und war auf Ressourcen, Terminplanung und Kosten ausgelegt (WinWorld: Microsoft Project 1.0 for DOS). Die Kernobjekte sind bis heute dieselben: Vorgänge, Teilvorgänge, verknüpfte Aktivitäten, Meilensteine, dazu Ressourcen wie Personal, Equipment oder Material, die Vorgängen zugewiesen werden (Wikipedia: Microsoft Project).

Das ist eine saubere Abstraktion. Sie beantwortet exakt eine Frage: Wann passiert was, und wer macht es. Für Bauprojekte, Rollouts, Organisationsvorhaben und klassische Auftragsabwicklung reicht das.

Der Markt hat sich seitdem in zwei Richtungen weiterentwickelt, ohne diesen Kern anzutasten. Gartner führt heute zwei getrennte Märkte: Adaptive Project Management and Reporting für Methodenvielfalt und Ausführung, Strategic Portfolio Management für Priorisierung, Nutzenrealisierung und Ressourcenstrategie (Gartner Peer Insights: Adaptive Project Management and Reporting). Beide Märkte beschreiben, wie Arbeit organisiert und berichtet wird. Keiner der beiden beschreibt, was gebaut wird.

Genau da beginnt die Fehlpassung. In einem Sondermaschinen- oder Anlagenprojekt ist das, was gebaut wird, der eigentliche Treiber des Zeitplans. Nicht die Vorgangsliste.

Was braucht ein technisch komplexes Projekt zusätzlich?

Fünf Datenobjekte, die im klassischen Modell fehlen.

Systemstruktur. Eine Anlage ist ein hierarchischer Baum: Anlage, Linie, Station, Baugruppe, Komponente. Dieser Baum ist nicht identisch mit dem Projektstrukturplan. Der PSP gliedert Arbeit, die Systemstruktur gliedert Technik. Wer beide in dieselbe WBS presst, verliert entweder die Arbeitssicht oder die technische Sicht. In der Praxis verliert man die technische Sicht, weil der Terminplan das führende System ist.

Stückliste und Material. Die Stückliste ist im Maschinen- und Anlagenbau das zentrale Element für Planung, Produktion und Instandhaltung und die Grundlage für Kalkulation, Beschaffung und Fertigung (Cideon: Stücklistenmanagement). Sie ist zugleich der härteste Terminrestriktionsgeber: Eine Position mit 22 Wochen Lieferzeit bestimmt den Meilenstein, nicht die Kapazität der Montage. Im klassischen PM-Tool ist Material eine Ressource mit Menge und Kostensatz, nicht ein Objekt mit Spezifikation, Variante, Bestand, Bestellung und Einbauort.

Reifegrade. Entwicklungsanteile laufen nicht binär von offen auf fertig. Der Technology Readiness Level beschreibt auf einer Skala von 1 bis 9 den Entwicklungsstand einer Technologie und stammt ursprünglich von der NASA (CMP Financial Engineers: Technology Readiness Level). Ein Vorgang, der zu 60 Prozent fertig gemeldet wird, sagt nichts über Reife aus. Ein Prototyp auf TRL 5 sagt alles.

Schnittstellen. In der Systemintegration liegt das Risiko nicht in den Komponenten, sondern zwischen ihnen: Mechanik zu Steuerung, Steuerung zu MES, Kundenseite zu Lieferantenseite. Schnittstellen haben Verantwortliche auf beiden Seiten, einen Freigabestand und ein eigenes Risikoprofil. Als Vorgang modelliert verschwindet diese Information.

Gates. Der Stage-Gate-Prozess trennt Phasen durch Entscheidungspunkte, an denen geprüft wird, ob ein Vorhaben die Kriterien für den Weiterlauf erfüllt (Ignite Group: Technology Readiness Level). Ein Gate ist kein Meilenstein. Ein Meilenstein ist ein Zeitpunkt, ein Gate ist eine Bedingung mit Kriterienliste, Entscheider und zwei möglichen Ausgängen.

Warum lösen Add-ons und Custom Fields das Problem nicht?

Der übliche Weg ist bekannt: benutzerdefinierte Felder, eine zusätzliche Spalte für die Baugruppennummer, ein Freitextfeld für den Reifegrad, ein Excel-Anhang für die Stückliste, ein Add-on für das Risikomanagement. Das funktioniert eine Weile. Dann läuft es aus drei Gründen auf.

Erstens: Ein Feld ist keine Relation. Eine Spalte „Baugruppe" am Vorgang macht aus dem Vorgang keine Verbindung zu einem Strukturknoten. Sie können nicht abfragen, welche offenen Aufgaben, Risiken, Bestellungen und Issues an Station 40 hängen. Sie können nur Strings filtern. Rückverfolgbarkeit von einer Bestellung zum Einbauort ist über Freitextfelder nicht herstellbar.

Zweitens: Auswertung stirbt an der Kardinalität. Ein Vorgang kann fünfzehn Materialpositionen betreffen, eine Materialposition kann in acht Vorgängen verbaut sein. Custom Fields sind 1:1. Sobald Sie n:m brauchen, landet die Wahrheit in einer Nebendatei. Die techconsult-Untersuchung PPI zeigt die Folge: 42 Prozent der Befragten kennen das Problem veraltender Pläne [Beleg ergänzen]. Veraltet ist meist nicht der Plan, sondern die Nebendatei, die ihn hätte korrigieren müssen.

Drittens: Jedes Add-on erzeugt eine neue Wahrheit. Risiken im Add-on, Material in Excel, Reifegrade im PLM, Termine im PM-Tool. Die Zahl der Systeme wächst, nicht die Zahl der belastbaren Aussagen. Klassische Stücklisten sind den heutigen Anforderungen an interdisziplinäre Konstruktion und Echtzeit-Zusammenarbeit nicht mehr gewachsen (Cideon: Stücklistenmanagement) — über eine Tabellenkopie in einem PM-Tool gilt das umso mehr.

Die Konsequenz ist messbar. Formstack berichtet, dass 55 Prozent der Manager mindestens acht Stunden pro Woche für administrative Aufgaben aufwenden (Formstack, State of Workflow Automation 2018). In technisch komplexen Projekten ist ein großer Teil dieser Zeit reines Nachpflegen zwischen Systemen, die dasselbe Projekt unterschiedlich abbilden.

Welche Kriterien entscheiden, ob ein Tool technische Projekte tragen kann?

Prüfen Sie ein Werkzeug entlang dieser acht Punkte. Jeder Punkt ist eine Frage an das Datenmodell, nicht an die Oberfläche.

1. Zweite Struktur. Gibt es neben dem Projektstrukturplan eine eigene technische Struktur als rekursiven Baum, oder muss die Anlage in die WBS gefaltet werden?
2. Material als Objekt. Sind Güter, Varianten, Spezifikationen, Bestand und Lagerbewegungen eigene Entitäten mit Beziehungen, oder ist Material eine Ressource mit Menge?
3. Beschaffung aus der Struktur. Entsteht der Bedarf aus dem, was verbaut werden soll, oder wird er separat gepflegt?
4. Rückverfolgbarkeit. Kommen Sie von einer Bestellung zum Einbauort und zurück, ohne eine Nebendatei zu öffnen?
5. Gates mit Kriterien. Ist ein Gate ein eigener Objekttyp mit Kriterien und Entscheidung, oder ein umbenannter Meilenstein?
6. Reifegrade und Zustände. Lassen sich Reife, Freigabestände und Ticketzustände getrennt von Fertigstellungsgrad führen?
7. Terminrechnung mit Materialrestriktion. Berücksichtigt die Terminplanung Lieferzeiten und Materialverfügbarkeit, oder nur Dauern, Abhängigkeiten und Personalkapazität?
8. Portfolio über technische Projekte. Wird über mehrere Projekte hinweg gerechnet, mit Priorisierung, Ressourcenkonflikten und gemeinsamer Materialsicht?

Wie unterscheidet sich das klassische Datenmodell vom technischen Projekt?

Wie sieht der Gegenentwurf bei Aligia konkret aus?

Aligia führt fünf Datenstränge in einem System, statt einen Strang zu führen und vier anzuhängen.

Der Arbeitsplan reicht von Portfolio über Programm, Projekt, Segment und Arbeitspaket bis zu Aufgabe und Teilaufgabe, mit Meilensteinen, Gates, Ereignissen, Abhängigkeiten, kritischem Pfad, Gantt, Baseline-Vergleich und Multi-Gantt. Das ist die klassische Disziplin, vollständig vorhanden.

Der zweite Strang ist der Unterschied. Das Engineering-Modul von Aligia bildet die Anlage als rekursiven Baum aus Nodes ab, jeder Knoten trägt seine benötigten Güter samt Spezifikationen. Das Spec-Matching gleicht diese Spezifikationen gegen die Materialdatenbank ab. Die Beschaffung entsteht aus der Struktur, nicht neben ihr. Eine Bestellung bleibt bis zum Einbauort rückverfolgbar.

Menschen und Zeit laufen als dritter Strang: Mitarbeitende, Skills inklusive Zertifizierungspflicht, geplante Stunden, Buchungen, Zeiterfassung, Arbeitskalender, Abwesenheiten, Skill-Matching von Soll gegen Ist. Geld als vierter: Budget, Kostenpositionen, Kosten-, Nutzen- und Erlös-Occurrences, Budgetanfragen, Plan-Ist, NPV und ROI über die Nutzenerfassung. Aligia ist dabei kein Buchhaltungssystem; Geld dient der Planung und Steuerung, nicht der Fakturierung. Material als fünfter: Güterkatalog, Varianten, Bestand, Lagerbewegungen, Beschaffungsanfragen, Materialeinsatz auf Aufgaben, Equipment.

Weil alle fünf Stränge im selben Modell liegen, kann der KI-Terminoptimierer von Aligia den Zeitplan aus Vorgangsdauern, Abhängigkeiten, Gates, Ressourcen und Materialbedarf gemeinsam berechnen, und zwar für bis zu 50 Projekte in einem Lauf, aufgesetzt auf die Portfolio-Priorisierung. Das Ergebnis kommt als Entwurf mit vier Ansichten: Projekte, Ressourcen-Heatmap, Material- und Beschaffungstermine sowie Zeitplan-Gantt mit Ghost-Overlay gegen den aktuellen Stand. Einzelne Ergebnisse lassen sich pinnen und befördern. Angewendet wird manuell durch eine Admin-Rolle, ein Rücksetzen der Phase rollt zurück.

Governance sitzt auf demselben Modell: Risiken und Chancen mit Wahrscheinlichkeit mal Wirkung und Reaktionsmanagement, Portfolio-Risikofaktoren, strategische Portfolio-Bewertung, Projektpriorisierung, Entscheidungen, Statusberichte mit RAG-Logik, die weiterhin Menschen verfassen, Lessons Learned und berechnete Live-Dashboards.

Was heißt das in einem konkreten Projekt?

Eine Sondermaschinenbaufirma mit 140 Mitarbeitenden liefert eine Montagelinie für 4,2 Millionen Euro, Laufzeit 14 Monate, 9 parallele Projekte im Portfolio. Der Terminplan steht im klassischen Tool mit 480 Vorgängen. Die Stückliste liegt im PLM, die Bestellungen im ERP, der Reifegrad der Steuerungssoftware in einer Excel-Liste des Softwareleiters.

In Woche 19 ändert die Konstruktion die Greiferbaugruppe an Station 40. Im klassischen Modell ist das eine Änderung im PLM. Der Terminplan erfährt davon, wenn jemand es meldet. Die betroffene Position mit 16 Wochen Lieferzeit fällt auf, wenn der Einkauf die geänderte Stückliste sieht. Zwischen Änderung und Terminwirkung liegen erfahrungsgemäß Wochen. McKinsey und die Universität Oxford haben für große Technologieprojekte einen Durchschnitt von 45 Prozent Budgetüberschreitung und 56 Prozent weniger realisiertem Wert gemessen (McKinsey: Delivering large-scale IT projects on time, on budget, and on value).

Im Aligia-Modell hängt die Greiferbaugruppe als Node in der technischen Struktur. Die Änderung ändert die benötigten Güter an diesem Knoten. Der Materialbedarf ändert sich damit im selben Datenbestand, in dem der Terminoptimierer rechnet. Ein Optimizer-Lauf zeigt als Entwurf, welcher Meilenstein kippt, welche Ressourcen frei werden und welche Beschaffungstermine sich verschieben, inklusive Wirkung auf die acht Parallelprojekte. Die Entscheidung trifft weiterhin ein Mensch, die Anwendung ist manuell.

Wann bleibt ein klassisches PM-Tool die bessere Wahl?

In drei Fällen deutlich.

Wenn Ihre Projekte terminlastig, aber technisch flach sind. Rollouts, Bau, Migrationen, Organisationsprojekte: Hier ist das Vorgang-Ressource-Kalender-Modell nicht zu schlagen. Es ist ausgereift, jeder Projektleiter kennt es, die Ausbildung dafür ist Standard, und die Werkzeuge sind seit Jahrzehnten stabil.

Wenn Ihre technische Struktur bereits sauber im PLM lebt und dort auch gesteuert wird. Ein starkes PLM mit belastbarem Stücklistenmanagement plus ein klassischer Terminplan ist eine funktionierende Kombination, solange die Änderungsfrequenz niedrig ist und eine Person die Kopplung sauber hält.

Wenn die Organisation die Datendisziplin nicht mitbringt. Ein Modell mit Systemstruktur, Spezifikationen und Reifegraden verlangt gepflegte Daten. Wer heute den Terminplan nur zum Kick-off aktualisiert, gewinnt durch ein tieferes Modell zunächst nichts. Der Reifegrad der Organisation entscheidet mit.

Fair gesagt: Klassische PM-Tools sind stark bei Terminlogik, Verbreitung und Ausbildungsstand. Aligia ist stark bei technischer Struktur, Material und gemeinsamer Rechnung über alle Datenstränge. Für Ihren Fall entscheidet, ob der Treiber Ihres Zeitplans der Terminplan ist oder die Anlage.

Fazit

Die Fehlpassung zwischen Standard-PM und technischen Projekten ist kein Funktionsdefizit, das sich mit Feldern und Add-ons schließen lässt. Sie steckt im Datenmodell, das 1984 für Vorgänge und Ressourcen entworfen wurde und seitdem sauber gepflegt, aber nicht erweitert wurde. Wer Anlagen baut, braucht zwei Strukturen, Material als Objekt und Reife als eigene Größe, oder er pflegt dauerhaft die Differenz zwischen Plan und Anlage von Hand nach.

Weiterführend: Technische Systemintegration: warum Standard-PM hier an Grenzen stößt · PM-Tool mit KI: Worauf Sie bei der Auswahl wirklich achten sollten

Zeigen Sie uns Ihre Anlagenstruktur, wir zeigen Ihnen in 10 Minuten, wie Termin, Material und Beschaffung daraus entstehen. Demo anfragen · Kostenlos · Unverbindlich · Persönlich

Quellen

1. Microsoft Project, Wikipedia — https://en.m.wikipedia.org/wiki/Microsoft_Project (abgerufen 2026-09)
2. WinWorld: Microsoft Project 1.0 for DOS — https://winworldpc.com/product/project/10-for-dos (abgerufen 2026-09)
3. Gartner Peer Insights: Adaptive Project Management and Reporting — https://www.gartner.com/reviews/market/adaptive-project-management-and-reporting (abgerufen 2026-09)
4. Cideon: Stücklistenmanagement optimieren mit PLM-Lösungen — https://www.cideon.de/loesungen/plm-pdm/stuecklistenmanagement/ (abgerufen 2026-09)
5. CMP Financial Engineers: Technology Readiness Level (TRL) — https://cmp-fe.de/de/blogbeitrag/technologiereifegrad (abgerufen 2026-09)
6. Ignite Group: Der Technology Readiness Level — TRL und wozu er gut ist — https://ignite-group.com/de/nachricht/der-technology-readiness-level-trl-und-wozu-er-gut-ist/ (abgerufen 2026-09)
7. Formstack, State of Workflow Automation 2018 — https://www.formstack.com/blog/workflow-automation-statistics (abgerufen 2026-09)
8. McKinsey / University of Oxford: Delivering large-scale IT projects on time, on budget, and on value — https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value (abgerufen 2026-09)
9. techconsult, Projektmanagement Performance Index (PPI) — [Beleg ergänzen]