Die unterschätzte Transformation des Webmarkts
Die Renaissance des Technischen Projektmanagers
Jürgen Michael Kindler | 19.10.2025 | aktualisiert am 06.04.2026
Lange wirkte es, als wäre der Technische Projektmanager (TPM) eine auslaufende Rolle. Agile Frameworks machten ihn scheinbar überflüssig, Verantwortung wurde ins Entwicklungsteam verlagert, und dieses Modell funktionierte – solange Budgets üppig waren, Zeitpuffer existierten und technische Entscheidungen wenig formale Konsequenzen hatten.
Heute haben sich die Rahmenbedingungen spürbar verändert. Webprojekte sind komplexer geworden, Budgets enger kalkuliert und Anforderungen verbindlicher. In diesem Umfeld zeigt sich nicht nur, dass technische, wirtschaftliche und organisatorische Verantwortung wieder stärker zusammengeführt werden müssen – sondern auch, dass dies nur funktioniert, wenn entsprechende Rollen mit einem klaren Mandat ausgestattet sind. Genau hier beginnt die eigentliche Renaissance des Technischen Projektmanagers.
Der TPM verschwindet nicht
Moderne Webprojekte sind keine isolierten Umsetzungen mehr, sondern komplexe Systeme. Deployment, Security, Accessibility, SEO, Designsysteme und Integrationen greifen ineinander. Gleichzeitig erwarten Auftraggeber belastbare Aussagen zu Aufwand, Risiken und Zeit.
Unter diesen Bedingungen reicht es nicht aus, Anforderungen zu verwalten oder Umsetzung zu koordinieren. Entscheidend ist die Fähigkeit, technische Optionen zu bewerten und deren Auswirkungen auf Kosten, Risiken und langfristige Tragfähigkeit einzuordnen.
Lange wirkte es dennoch so, als würde der Technische Projektmanager (TPM) verschwinden. Agile Methoden, verteilte Verantwortung und spezialisierte Rollen schienen ihn überflüssig zu machen. Diese Interpretation greift zu kurz.
Was tatsächlich passiert ist: Die Rolle ist nicht verschwunden – sie hat sich aufgespalten.
Vier Rollen statt einer
In vielen Projekten lassen sich heute vier unterschiedliche Ausprägungen beobachten, die oft unter dem gleichen Begriff laufen, in der Praxis aber völlig unterschiedlich funktionieren.
Diese vier Felder entstehen nicht zufällig. Sie ergeben sich aus zwei einfachen Fragen:
- Arbeitet die Rolle eher im Projekt oder am System?
- Hat sie Entscheidungskompetenz oder übernimmt sie vor allem Koordination?
Die vier Rollen – Koordination (Abstimmung), Delivery (Technische Steuerung), System Owner (Systemverantwortung) und Reality Check (Bewertung) – lassen sich entlang zweier Achsen einordnen:
Projekt vs. System sowie Koordination vs. Entscheidung. Genau aus dieser Kombination ergeben sich unterschiedliche Rollenbilder, die heute häufig unter dem Begriff TPM zusammengefasst werden, obwohl sie in Verantwortung, Wirkung und Zeithorizont deutlich voneinander abweichen:
Die häufigste Ausprägung – vor allem in Agenturen. Im Fokus stehen Abstimmung, Organisation und Kommunikation zwischen Teams und Stakeholdern.
- Abstimmung zwischen Teams
- Organisation von Sprints
- Kommunikation mit Stakeholdern
Die Rolle sorgt dafür, dass alle miteinander arbeiten können. Technische Entscheidungen liegen jedoch meist außerhalb ihres Einflussbereichs, wodurch eine hohe Aktivität bei gleichzeitig begrenzter Steuerungswirkung entsteht.
Die klassische Form des Technischen Projektmanagers. Im Fokus stehen Umsetzungssteuerung, Risikomanagement und die Vorbereitung belastbarer technischer Entscheidungen.
- Steuerung der Umsetzung
- Vorbereitung technischer Entscheidungen
- Bewertung von Risiken und Abhängigkeiten
Hier entsteht echte technische Führung im Projekt. Die Rolle bleibt jedoch meist auf ein konkretes Vorhaben begrenzt und endet häufig mit dessen Abschluss.
Diese Rolle tritt häufig unter anderen Bezeichnungen auf, etwa als Web Manager, Platform Owner oder Head of Web. Der Fokus liegt nicht auf einzelnen Projekten, sondern auf dem System als Ganzes.
- langfristige Systemverantwortung
- Architekturentscheidungen
- Steuerung externer Dienstleister
Im Mittelpunkt stehen Stabilität, Wartbarkeit und wirtschaftliche Tragfähigkeit der Plattform. Typisch wird diese Rolle dort, wo Systeme über Jahre betrieben und kontinuierlich weiterentwickelt werden müssen.
Eine Rolle, die selten benannt wird, aber zunehmend entsteht. Im Fokus steht die Bewertung technischer Optionen und deren Auswirkungen.
- Einordnung technischer Optionen
- Bewertung von Risiken und Nebenwirkungen
- Übersetzung von Ideen in tragfähige Entscheidungen
Diese Rolle macht sichtbar, was Entscheidungen tatsächlich bedeuten – technisch, organisatorisch und wirtschaftlich. Sie hat oft wenig formale Macht, aber großen Einfluss auf die Qualität der Entscheidungen.
Warum diese Unterscheidung entscheidend ist
Viele Organisationen gehen davon aus, dass sie einen Technischen Projektmanager haben. Tatsächlich besetzen sie jedoch häufig nur einen Teil dieses Spektrums – meist die Koordination.
Die Folge ist eine strukturelle Lücke:
- Entscheidungen werden vertagt oder verteilt
- Architektur entsteht implizit statt bewusst
- Verantwortung ist vorhanden, aber nicht wirksam
Der TPM „funktioniert nicht“ – obwohl in Wahrheit das Mandat fehlt. Entscheidend ist also nicht die Bezeichnung der Rolle, sondern ob Verantwortung und Entscheidungskompetenz tatsächlich zusammenfallen.
Und wo bleibt Scrum?
Scrum hat weiterhin seine Berechtigung – insbesondere dort, wo Ziele zu Beginn bewusst offen sind und Lösungswege iterativ entstehen. In solchen Kontexten ist es sinnvoll, Verantwortung im Team zu verankern und Entscheidungen möglichst nah an der Umsetzung zu treffen.
Sobald jedoch ein konkretes Ergebnis erwartet wird – mit definiertem Budget, klaren Rahmenbedingungen und belastbaren Zusagen – verschieben sich die Anforderungen. Planbarkeit wird wichtiger, technische Entscheidungen müssen früh getroffen werden und Risiken aktiv gesteuert werden.
In genau diesen Situationen reicht es nicht aus, Verantwortung zu verteilen oder Entscheidungen emergent entstehen zu lassen. Gefragt ist eine Rolle, die technische, wirtschaftliche und organisatorische Perspektiven zusammenführt und daraus tragfähige Entscheidungen ableitet.
Genau hier entfaltet der Technische Projektmanager seine Stärke.
Der blinde Fleck vieler Organisationen
Die Renaissance des Technischen Projektmanagers scheitert in der Praxis häufig an einem einfachen Punkt: Verantwortung und Entscheidungskompetenz werden nicht zusammengeführt.
Rollen werden benannt, Aufgaben verteilt und Prozesse definiert – aber das Mandat, technische Entscheidungen tatsächlich zu treffen und zu verantworten, bleibt unklar oder liegt außerhalb der Rolle.
Die Folge ist ein strukturelles Muster:
- Verantwortung ist vorhanden, aber nicht wirksam
- Entscheidungen werden vertagt oder informell getroffen
- Architektur entsteht implizit statt bewusst
In solchen Konstellationen wird der Technische Projektmanager zur koordinierenden Instanz ohne echte Steuerungswirkung. Die Rolle ist besetzt, aber nicht funktionsfähig.
Das Problem liegt nicht in der Rolle selbst – sondern in der fehlenden Kopplung von Verantwortung und Entscheidungskompetenz.
Fazit
Der Technische Projektmanager gewinnt nicht aus nostalgischen Gründen wieder an Bedeutung. Er wird dort relevant, wo technische Komplexität und wirtschaftlicher Druck zusammenkommen – und Entscheidungen nicht nur umgesetzt, sondern bewusst getroffen werden müssen.
Die eigentliche Veränderung liegt nicht in der Existenz der Rolle, sondern in ihrer Ausprägung. Zwischen Koordination, Delivery, Systemverantwortung und Reality Check entstehen unterschiedliche Rollenbilder mit klar unterscheidbarer Wirkung.
Entscheidend ist dabei nicht die Bezeichnung, sondern das Mandat: Nur wenn Verantwortung und Entscheidungskompetenz zusammenfallen, kann technische Steuerung wirksam werden. Die entscheidende Frage ist daher nicht nur, welches Vorgehensmodell verwendet wird, sondern wie Verantwortung und Entscheidungskompetenz im Projekt oder System tatsächlich verankert sind.
Der TPM verschwindet nicht. Er verändert seine Funktion.