Die Frage ist alt. Die Antwort ist es nicht mehr.
Ob ein Projektmanager technisches Verständnis für sein Themenfeld benötigen – diese Diskussion ist so alt wie das Projektmanagement selbst. Sie erinnert ein wenig an den Klassiker aus dem Fußball: „Muss der Trainer früher selbst gespielt haben?“ Beide Seiten haben valide Argumente. Und beide liegen ein Stück weit daneben.
Denn in einer Welt, in der KI-Agenten Projektpläne eigenständig anpassen, autonome Systeme Entscheidungen vorbereiten und der Projektmanager weniger Verwalter als Orchestrator ist, stellt sich die Frage fundamentaler: Was macht einen PM überhaupt noch unverzichtbar?
Was ein Projektmanager immer leisten muss
Die Kernaufgaben eines Projektmanagers sind universell – unabhängig von Branche oder Technologie:
- Anforderungsmanagement und Scope-Kontrolle
- Realistische Planung unter Unsicherheit
- Stakeholder-Kommunikation auf mehreren Ebenen
- Risiko- und Change Management
- Führung ohne disziplinarische Autorität
Diese Aufgaben lassen sich aus keinem Projektmanagement-Handbuch streichen – egal ob PRINCE2, PMI oder agile Framework. Sie sind die eigentliche Leistung. Die Frage ist nur: Kann man sie ohne technisches Verständnis wirklich gut erfüllen?
Das Argument für technisches Know-how
Aus meiner Erfahrung in der Leitung globaler IT-Programme – Migrationen über 100 Standorte, Rollouts für bis zu 30.000 Anwender, Budgets im zweistelligen Millionenbereich – lautet die ehrliche Antwort: Technisches Verständnis ist kein Nice-to-have. Es ist ein Qualitätsmarker.
Ein PM, der versteht, wie Systeme zusammenhängen, erkennt Seiteneffekte, bevor sie im Statusbericht auftauchen. Er bewertet, ob eine Schätzung des Entwicklerteams realistisch oder optimistisch ist. Er weiß, was es bedeutet, wenn ein Architekt ausfällt – und was das für den kritischen Pfad bedeutet.
Noch entscheidender: Er versteht die Sprache beider Seiten.
Das Business will wissen: Warum verzögert sich das? Was kostet das? Was ist das Risiko? Das technische Team kommuniziert in Abhängigkeiten, Technologiestacks und Systemgrenzen. Ein PM ohne technisches Verständnis wird zur Stille Post – jede Rückfrage verlängert den Entscheidungsprozess, jedes Missverständnis kostet Vertrauen.
Der neue Kontext: Der PM als Orchestrator im KI-Zeitalter
2026 kommt eine neue Dimension hinzu, die die Debatte grundlegend verschiebt.
KI-Tools übernehmen zunehmend die administrativen Anteile der PM-Arbeit: Statusberichte, Risikoprognosen, Meeting-Protokolle, dynamische Ressourcenplanung. Was bleibt, ist das, was Maschinen nicht können – Urteilsvermögen, Kontext und Vertrauen.
Genau hier wird technisches Know-how zum Differenzierungsmerkmal. Wer verstehen will, welche KI-Empfehlung valide ist und welche auf falschen Annahmen basiert, braucht das inhaltliche Fundament, um die Ausgaben zu bewerten. Ein PM, der blind vertraut, was das System ausspuckt, ist kein Orchestrator – er ist ein Dispatcher.
Die Fähigkeit, AI-Augmented Project Management tatsächlich zu nutzen, setzt voraus, dass man die Domäne versteht, in der die KI agiert.
Die Kehrseite: Technisches Wissen ist kein Freifahrtschein
Hier liegt das größte Risiko für erfahrene PMs mit technischem Hintergrund: Micromanagement.
Wer früher selbst Entwickler, Architekt oder Systemadministrator war, läuft Gefahr, in die Fachrolle zurückzufallen. Das ist toxisch – nicht weil das Wissen fehlt, sondern weil die Rollenvermischung das Team lähmt. Ein PM, der die Architekturentscheidungen seines Lead Architects kommentiert oder gar übergeht, raubt dem Team die Eigenverantwortung und untergräbt das Vertrauen.
Technisches Wissen sollte genau das bleiben, was es ist: ein Werkzeug für bessere Fragen – kein Mandat für eigene Antworten.
Die Aufgabe des PM ist es, den Kontext zu schaffen, in dem das Team exzellente technische Entscheidungen treffen kann. Nicht mehr, nicht weniger.
Was tun, wenn das technische Know-how fehlt?
Nicht jeder PM startet mit einem technischen Hintergrund. Das ist kein Makel. Es bedeutet aber, dass man aktiv investieren muss:
- Zuhören mit System: Nicht nur protokollieren, was gesagt wird – sondern verstehen, warum es gesagt wird.
- Kluge Fragen stellen: „Was passiert, wenn wir diese Abhängigkeit ignorieren?“ zeigt mehr Kompetenz als vorgetäuschtes Verständnis.
- Transparenz als Führungsstil: Wer zugibt, etwas nicht zu verstehen, gewinnt Respekt. Wer so tut als ob, verliert ihn früher oder später.
- Strukturiertes Lernen: Domänenwissen lässt sich aufbauen – durch Zertifizierungen, gezielte Gespräche mit Subject Matter Experts oder schlicht durch Zeit im Feld.
Ein PM, der vorgibt, alles zu verstehen, gefährdet das Projekt. Ein PM, der offen kommuniziert, wo seine Grenzen liegen, stärkt das Team.
Fazit: Es kommt darauf an – aber nicht auf das, was Sie denken
Die klassische Antwort lautet: „Es kommt darauf an.“ Das stimmt – aber die relevante Variable ist nicht, ob technisches Know-how vorhanden ist. Die relevante Variable ist, ob der PM in der Lage ist, Urteilsvermögen von Scheinwissen zu trennen.
Ein PM mit tiefem technischem Hintergrund, der ins Micromanagement abrutscht, ist gefährlicher als ein PM ohne technisches Wissen, der exzellent koordiniert und kommuniziert.
Der beste IT-Projektmanager ist derjenige, der weiß, wie viel er wissen muss – und wann er die Fachleute reden lassen sollte.
Sie stehen vor einem komplexen IT-Projekt und suchen Führung, die sowohl methodisch solide als auch technisch geerdet ist?