Projektcontrolling, das nicht beim Projekt endet
In projektbasierten Organisationen entscheidet sich Steuerbarkeit nicht im ERP-System. Sie entscheidet sich an der Frage, ob Projektdaten und Finanzdaten dieselbe Sprache sprechen — und ob jemand die Übersetzung liefert.
Warum Projektcontrolling in projektbasierten Geschäftsmodellen oft ins Leere läuft
Projektbasierte Organisationen — ob im Anlagenbau, in der Infrastruktur, im öffentlichen Sektor oder in der Energiebranche — haben eine gemeinsame Herausforderung: Ihre Wertschöpfung entsteht entlang von Projekten, aber ihre Steuerungslogik ist periodisch aufgebaut.
Das Controlling berichtet monatlich, quartalsweise, jährlich. Das Projekt lebt in Meilensteinen, Arbeitspaketen und Fortschrittsgraden. Zwischen diesen beiden Welten klafft eine Lücke, die in den meisten Organisationen nicht durch Struktur geschlossen wird, sondern durch manuelle Übersetzungsleistung einzelner Personen — wenn überhaupt.
Die Konsequenzen sind immer dieselben. Kosten werden periodisch bewertet statt projektbezogen, was dazu führt, dass Budgetüberschreitungen erst sichtbar werden, wenn es zu spät ist. Forecasts berücksichtigen den Projektfortschritt nicht konsistent, weil die Bewertungslogik zwischen Projekt und Finance nicht abgestimmt ist. Cash-Wirkungen von Projekten werden isoliert betrachtet statt im Portfoliokontext, sodass Liquiditätsrisiken systematisch unterschätzt werden. Und Earned-Value-Kennzahlen, wo sie überhaupt existieren, leben in separaten Tools ohne Rückbindung an die Finanzplanung.
Das Ergebnis: Der CFO sieht eine GuV, der Projektleiter sieht einen Fortschrittsbericht, und niemand sieht das Gesamtbild.
Drei strukturelle Lücken, die fast immer zusammenspielen
Die erste Lücke ist die Bewertungslogik. In den meisten projektbasierten Organisationen gibt es keine verbindliche Regel, wie Projektfortschritt finanziell bewertet wird. Earned Value existiert als Konzept, wird aber nicht durchgängig angewendet — oder nur in einzelnen Projekten, nicht portfolioübergreifend. Das führt dazu, dass CPI und SPI zwar berechnet werden können, aber nicht vergleichbar sind. Ohne eine einheitliche Bewertungslogik kann kein Portfoliomanagement funktionieren.
Die zweite Lücke ist die Datenbrücke zwischen Projekt und Finance. Projektsysteme (SAP PS, SAP PPM, oder externe Tools wie Clarity oder Workfront) und Finanzsysteme (SAP FiCo, S/4HANA) sprechen nicht dieselbe Sprache. Stammdaten sind nicht harmonisiert, Kontierungslogiken weichen voneinander ab, und der Übergang von Projektbudget zu Kostenstellenplanung passiert manuell — oft in Excel, oft mit Brüchen. Jeder, der schon einmal versucht hat, aus SAP PPM einen belastbaren Forecast für das Steering Committee zu erzeugen, kennt das Problem.
Die dritte Lücke ist die Governance. Es gibt in vielen Organisationen keine definierte Instanz, die für die Konsistenz zwischen Projektsteuerung und Finanzsteuerung verantwortlich ist. Das PMO steuert Projekte, das Controlling steuert Kosten, und dazwischen fällt die Frage, ob die Zahlen zusammenpassen, regelmäßig durch. Es fehlt nicht an Daten — es fehlt an einer Rolle, die beide Welten zusammenhält.
Was Projektcontrolling leisten muss, um steuerungsrelevant zu werden
Steuerungsrelevantes Projektcontrolling in projektbasierten Geschäftsmodellen braucht drei Dinge.
Erstens ein durchgängiges Earned-Value-Framework, das nicht nur den Fortschritt einzelner Projekte misst, sondern portfolioübergreifend anwendbar ist. Das bedeutet: einheitliche Regeln für die Fortschrittsbewertung, konsistente Kosten-Baselines, und eine klare Definition, was „fertig“ bedeutet — auf jeder Ebene. Nur so werden CPI und SPI zu echten Steuerungsgrößen statt zu Reportingkosmetik.
Zweitens eine belastbare Datenbrücke zwischen Projekt- und Finanzsystemen. Das ist kein IT-Thema allein — es ist ein Governance-Thema. Es erfordert harmonisierte Stammdaten, abgestimmte Kontierungslogiken und automatisierte Überleitungen, die nicht von einzelnen Personen abhängen. In SAP-Umgebungen (S/4HANA, PPM, SAC) ist das technisch lösbar — aber nur wenn die fachliche Logik vorher steht.
Drittens eine Governance-Struktur, die Projektcontrolling und Finanzsteuerung verbindet. Das kann eine dedizierte Rolle sein — ein Project Finance Controller — oder eine Prozessregel, die sicherstellt, dass Forecast-Updates im Projekt und in der Planung synchron laufen. Entscheidend ist nicht die Organisationsform, sondern dass jemand für die Konsistenz verantwortlich ist.
Meine Rolle in PSB-Mandaten
Ich arbeite seit über 20 Jahren an genau dieser Schnittstelle — zwischen Projektcontrolling, Finance und IT in projektbasierten Organisationen. Meine Mandate haben ein gemeinsames Muster: Es gibt ein SAP- oder ERP-System, es gibt Projekte, und es gibt eine Lücke dazwischen, die niemand systematisch schließt.
Bei Rolls-Royce Power Systems habe ich ein konzernweites Projektmanagement- und Projektcontrolling-Framework auf Basis von SAP PPM und SAC eingeführt — inklusive eines Earned-Value-basierten Steuerungssystems für Kosten, Fortschritt und Zeit. Bei Dataport habe ich im Digitalisierungsprogramm der Senatskanzlei Hamburg ein integriertes Projektcontrolling-Tool konzipiert, das Finanzen, Fortschritt und Risiken in einem System zusammenführt. Bei der Hamburger Hochbahn habe ich die Finance-seitige Begleitung der S/4HANA-Einführung verantwortet und die Planung in SAP Analytics Cloud aufgebaut.
Ich arbeite in Unternehmen ain DACH, remote und vor Ort. Meine Stärke ist nicht das eine oder das andere — es ist die Brücke.
Warum SAP- und Finance-Transformationen an Steuerbarkeit verlieren, nicht an Technik.
Finance Transformation
Warum Steering Committees oft informieren statt zu entscheiden.

