50 PROJEKTMANAGEMENT AKTUELL · 37. Jahrgang · 03/ 2026 DOI 10.24053/ PM-37-0046 Zwei ICB4.0 Kompetenzelemente im Fokus Spielregeln und Machtspiele Oliver Steeger Zwei Kompetenzelemente der ICB4 werden im Projektalltag oft unterschätzt: „Macht und Interessen" sowie „Compliance, Standards und Regularien". Dabei können Versäumnisse in diesen Bereichen ein Projekt zum Abbruch zwingen. Dr. Martin Backhaus leitet ein umfangreiches IT-Programm bei öffentlich-rechtlichen Rundfunkanstalten und kennt viele Fallstricke aus eigener Erfahrung. Im Interview erklärt er, wie Projektmanager Regularien im Projekt verankern, warum politisches Geschick unverzichtbar ist -- und wie man Einfluss gewinnt, ohne disziplinarische Macht zu haben. Herr Dr. Backhaus, zwei ICB-Kompetenzelemente stehen manchmal im Schatten der anderen. Zum einen ist dies das Element “Macht und Interessen”, zum anderen “Compliance, Standards und Regularien”. Zu Unrecht! An Versäumnissen bei den internen und externen Regeln leiden viele Projekte. Gleiches gilt für machtvolle Interessen, die ihrem Projekt entgegenstehen-… Dr. Martin Backhaus: Ich würde sogar einen Schritt weitergehen: Im Extremfall können Versäumnisse in diesen Bereichen zum Projektabbruch führen. Auch wenn man die besten Ziele, den besten Zeitplan, das beste Team hat- - Fehler bei der Compliance oder falsch erkannte Machtverhältnisse können zum Showstopper werden. Machen wir die beiden Kompetenzelemente greifbarer-- und fangen mit “Compliance, Standards und Regularien” an. Was ist damit gemeint? Backhaus: Die Durchführung des Projekts und sein Ergebnis sollen rechts- und regelsicher sein. Darum geht es im Kern. Um dies anschaulich zu machen: Bei den Sendeanstalten des öffentlich-rechtlichen Rundfunks leite ich derzeit ein umfangreiches IT-Programm. Wichtige Themen sind dabei beispielsweise die IT-Sicherheit oder die Barrierefreiheit- - also alles Themen, die mit Standards und Regularien zusammenhängen. Wir müssen bei unserer Arbeit im Projekt und mit dem Ergebnis des Projekts bestimmte Regeln befolgen-… Zur Person Dr. Martin Backhaus, studierter Wirtschaftsinformatiker und Kaufmann, arbeitet seit über 20 Jahren als Ingenieur und Projektmanager für den Mitteldeutschen Rundfunk (MDR). Als zertifizierter Change Manager und Project Director (IPMA Level A) leitete er das Gesamtprojektmanagement des ARD-Strukturprojekts SAP Prozessharmonisierung für 11 öffentlich-rechtliche Rundfunkanstalten. Derzeit verantwortet er Aufbau und Leitung einer zentralen Geschäftsprozessorganisation digitale Verwaltung für ARD und Deutschlandradio. Sein Wissen und seine Erfahrungen gibt er mit Lehraufträgen zu Projekt- und Change Management an die Studierenden der Hochschule für Technik, Wirtschaft und Kultur Leipzig weiter. Dr. Martin Backhaus © privat Aus den DACH-Verbänden | GPM intern | Spielregeln und Machtspiele 51 PROJEKTMANAGEMENT AKTUELL · 37. Jahrgang · 03/ 2026 DOI 10.24053/ PM-37-0046 Zum Beispiel den Datenschutz… Richtig. Die Gesetze, in diesem Fall unter anderem die DSGVO, sind zu befolgen. Das ist für mich die Compliance. Darüber hinaus gibt es in jeder Organisation interne Standards und Regularien, die beachtet werden müssen. Nochmals zu dem Programm bei den Sendeanstalten: Die elf beteiligten Rundfunkanstalten haben eine Finanzordnung, jede für sich. Ein anderes Beispiel ist die Beschaffungsordnung, also Regeln, wann und wie man eine Ausschreibung macht. Oder wann man wie einen Verwaltungsrat fragen muss, um die Genehmigung für ein Budget zu kommen- - was ja durchaus auch Vorlaufzeiten von drei oder vier Monaten haben kann. Es geht also um die Bündel der Normen, die im Projekt berücksichtigt werden müssen. Dies alles können wir auch den Arbeitsrahmen nennen, in dem wir uns im Projekt bewegen. Das Problem ist manchmal: Aus Unwissenheit werden in Projekten diese Normen verletzt. Wie können Projektmanager die Normen recherchieren, die für ihr Projekt gelten? Vieles ergibt sich bei der ersten Stakeholderanalyse. Man wird bei den Gesprächen mit Stakeholdern darauf aufmerksam, welche Anforderungen es hinsichtlich der Normen gibt. Man nimmt dabei schnell wahr, welches Regel-Set im Projekt berücksichtigt werden muss. Dies muss man sich meistens nicht selbst erarbeiten. Diese Normen sind in der Linienarbeit gang und gäbe. In Projekten werden sie nicht immer gerne gesehen. Projekte führt man bekanntlich durch, um Ziele flexibel und zügig zu erreichen. Manches Team nimmt gerade die internen Regeln als Bremsklotz wahr, vielleicht sogar als unzulässige Einmischung. Wie gehen Sie damit um? Als Programmleiter vermittle ich meinen Projektleitern und deren Teams, dass Regularien und Standards schlichtweg dazugehören. Sie sind Teil des Projekts -- formuliert von wichtigen Stakeholdern. Die Erwartungen und Anforderungen etwa von Datenschutzbeauftragten sind ebenso wichtig wie die etwa von IT-Leitern. Ich mache in meinem Programm immer wieder klar, dass Datenschutzbeauftragte ebenso professionell arbeiten wollen wie wir. Es ist nicht ihre Absicht, uns Steine in den Weg zu legen. Ihnen geht es darum, dass eine rechtlich einwandfreie, juristisch unanfechtbare IT-Lösung entsteht. Ja. Wir müssen uns klarwerden: Die Konformität mit Regularien und Standards trägt heute genauso zum Projekterfolg bei wie beispielsweise Ingenieurstätigkeiten. Angenommen, einer Ihrer Projektleiter benötigt dringend einen bestimmten externen Spezialisten in seinem Team. Es muss schnell gehen. Er hat sogar schon eine Liste mit konkreten Namen, die er noch heute anrufen kann… Genau dies würde in unserem Programm nicht funktionieren. Wir brauchen als öffentlich-rechtliche Rundfunkanstalten dafür eine Ausschreibung. Dafür muss ich Verständnis wecken-- und auch Übersetzungsarbeit in beide Richtungen leisten. Ich mache nach innen deutlich, weshalb wir eine Ausschreibung brauchen und was dies erfordert. In Richtung unserer Beschaffungsabteilung übersetze ich den Bedarf des Projekts -- und suche nach Wegen, vielleicht Ermessensspielräume auszuschöpfen. Ich muss also Einfluss in beide Richtungen ausüben. Einfluss ausüben-- mit diesem Stichwort sind wir beim zweiten Kompetenzelement, über das wir sprechen wollen. Nun sind es nicht mehr die Regeln. Jetzt geht um das Thema “Macht und Interessen”. Dies erinnert mich an einen Projektmanager, der vor vielen Jahren geklagt hat, er selbst habe gar keine Macht-… …-Macht im disziplinarischen Sinne-… Ja, richtig. Die hat er vielleicht nicht. Aber ein Projektmanager hat andere Formen der Macht. Diese sollte er taktisch geschickt nutzen, um mit starken Stakeholdergruppen zu guten Kompromissen zu finden. Aha? Was ist das für eine Macht, die der Projektmanager hat? Ich bekomme Macht nicht durch meine Position. Diejenigen, mit denen ich zu tun habe, sind oft in höheren Positionen. Aber ich gewinne Einfluss, indem ich beispielsweise bestimmte Personen oder Gruppen hinter mich schare. Oder: Ich gewinne Macht, indem ich mein Wissen und meine Informationen geschickt bündele. Viele Projektmanager sehen sich nicht als “Machtmensch”… Ich persönlich sehe mich ebenfalls nicht als “Machtmensch”, wie Sie dies nennen. Ich bin Programm-Manager und führe ein Programm. Aber vielleicht unbewusst schaffe ich es dabei immer wieder, diejenigen zu überzeugen und mitzunehmen, die Einfluss haben in der Organisation. Ich würde dies Überzeugungsmacht nennen. Viele Projektmanager können meiner Ansicht nach diese Überzeugungsmacht nutzen. Dafür muss man zunächst wissen, wer Macht hat, seine Interessen durchzusetzen. Wie erkennen Sie systematisch, wer in Ihrem Umfeld Macht hat? Wenn Sie in der Stakeholderanalyse Personen oder Gruppen einordnen, dann bekommen Sie dafür schon ein erstes Gefühl. Sie erkennen diejenigen, die positiv oder negativ auf Ihr Projekt Einfluss nehmen können. Dann geht es darum zu erkennen, wie groß der Einfluss dieser Personen oder Grup- Aus den DACH-Verbänden | GPM intern | Spielregeln und Machtspiele 52 PROJEKTMANAGEMENT AKTUELL · 37. Jahrgang · 03/ 2026 DOI 10.24053/ PM-37-0046 pen ist und welche Interessen sie haben. Angenommen, eine Gruppe hat große Macht sowie Interessen, die einem Projekt zuwiderlaufen-- dann steht das Projekt vor großen Herausforderungen. Es muss politisch klug vorgehen. Politisch klug vorgehen-- was ist damit gemeint? Ein Beispiel. Angenommen, ich präsentiere vor einem Gremium und will einen bestimmten Beschluss erreichen. Ich muss dafür vorher wissen, ob ich die Mehrheit hinter meinem Projekt habe. Wenn ja, prima. Wenn nicht? Dann ist es vielleicht besser, dem Gremium den Beschluss noch nicht vorzulegen. Denn die Mehrheit wird vermutlich fehlen. Ich kann versuchen, Vorgespräche mit Mitgliedern dieses Gremiums zu führen. Dabei kann ich ihre Interessen besser verstehen und Möglichkeiten für Kompromisse erkennen. Dieses politische Agieren ist ja nicht nur für Programm- Manager ein Thema, sondern auch für Projektmanager. Es reicht ja nicht, im Projekt gute technische Ideen zu haben. Die Ideen müssen auch bewilligt werden. Dafür brauchen Projektmanager beispielsweise die Mehrheit in Gremien. Manchmal brauchen sie sogar Konsens im Gremium. Erst danach können sie die gute Idee umsetzen. An diesem Punkt wird dieses Kompetenzelement “Macht und Interessen” sehr interessant für die Praxis. Ihrem persönlichen Eindruck nach-- kann man es lernen, mit den Themen “Macht und Interessen” sowie “Compliance, Standards und Regularien” richtig umzugehen? So, wie man es lernt, beispielsweise ein Projektdesign zu entwickeln? Ich denke, dass man diese Kompetenzen entwickeln kann. Selbstverständlich braucht man dafür Wissen, Erfahrung und Übung. Aber es geht. Aus der Praxis heraus betrachtet-- welche konkreten Fähigkeiten gehören aus Ihrer Sicht dazu? Aus meiner Sicht ist die Fähigkeit zum strukturierten Arbeiten grundlegend. Projektmanager haben es vor allem bei Compliance-Themen mit Menschen zu tun, die selbst sorgfältig und strukturiert an ihre Aufgaben herangehen. Wer diese Fähigkeit hat, wird mit diesen Menschen leichter kommunizieren und zusammenarbeiten können. Aus meiner Erfahrung ist zudem ein an der Sache orientiertes Vorgehen sinnvoll. Man muss Emotionen auch einmal zurückstellen können. Dies können vor allem Menschen, die beispielsweise gelernt haben, Anforderungen sachlich aufzunehmen, gut für das Projekt zu übersetzen und dann richtig in die Projektorganisation zu kommunizieren. Sie sagten vorhin, dass man in beide Richtungen übersetzen muss -- in das Projekt hinein und aus dem Projekt hinaus. Wie darf ich mir dies in der Praxis vorstellen? Jedes Unternehmen hat ja einen Ordnungsrahmen. Wird spiegelbildlich ein solcher Rahmen auch im Projekt entwickelt, der mit dem Rahmen der Organisation korrespondiert? Ihr Gedanke geht in die richtige Richtung. Man baut sich einen Arbeitsrahmen auf, der dem Ordnungsrahmen der Organisation entspricht. Aus meiner Sicht geht es darum, diese Aspekte auch strukturell in dem Projekt zu verankern. Inwiefern strukturell? Wir verwalten die Finanzdaten von elf Rundfunkanstalten. Dies berührt unter anderem Fragen von Datenschutz und IT-Sicherheit. Wir haben es beispielsweise mit elf Datenschutzbeauftragten, elf IT-Sicherheitsbeauftragten und elf Personalräten zu tun, die mitreden wollen und müssen. Mein Programm umfasst 37 Einzelprojekte. Dies macht diese Themen sehr komplex. Deshalb haben wir das Projekt „Compliance“ aufgesetzt. Dieses Projekt ist in unserem Programm für das Thema Compliance, Standards und Regularien zuständig. Wir haben dieses Thema dort zentralisiert. Das Projekt selbst habe ich einem Projektleiter übergeben, der Compliance versteht und Erfahrung mit diesem Thema hat. Er ist zu diesen Themen Ansprechpartner für die anderen Projektleiter und Teilprojektleiter. Dies dürfte den Vorteil haben, dass die anderen Teams nicht jedes Mal das Rad neu erfinden müssen, um beispielsweise eine Ausschreibung auf den Weg zu bringen. Richtig. Sie haben eine Stelle, die sie unterstützt, ihnen Rückversicherung bietet und dabei auch die Qualität sicherstellt. Zudem hat dieses Compliance-Projekt einen zweiten großen Vorteil: Es ist der Ansprechpartner nach außen, also beispielsweise für unsere Stakeholder. Wir bitten sie, mit dem Projekt Kontakt aufzunehmen -- und nicht direkt auf einzelne Projektleiter zuzugehen. Aha? Weshalb? Weil die einzelnen Projektleiter möglicherweise nicht die Sprache dieser Stakeholder sprechen. Das Compliance-Projekt vermittelt und übersetzt in beide Richtungen. Also Fachsprache in die Rechts- und Regelsprache-- und wieder zurück. Dadurch entstehen viel weniger Missverstände, die sich vielleicht zu Konflikten hochschaukeln. Ein Beispiel: Angenommen, ein Datenschutzbeauftragter fordert direkt beim zuständigen Projektleiter eine zusätzliche Protokollierung der Lesezugriffe sensibler Daten. Für den Beauftragten ist es wichtig, die Nachvollziehbarkeit der Dateneinsicht sicherzustellen, um Rechtskonformität zu erlangen. Aber der Projektleiter hält diese Anforderung aus seiner praktischen Sicht für vernachlässigbar, da schon durch das Rollenkonzept ein unbefugter Zugriff auf die Daten ausgeschlossen ist. Da ist das Projekt Compliance manchmal eine Art “Mittelsmann”-- nicht im Sinne eines Schiedsrichters, doch sensibilisiert genug für beide Perspektiven, um eine gute Lösung für beide zu finden. Aus den DACH-Verbänden | GPM intern | Spielregeln und Machtspiele 53 PROJEKTMANAGEMENT AKTUELL · 37. Jahrgang · 03/ 2026 DOI 10.24053/ PM-37-0046 Damit sind wir wieder auf dem politischen Spielfeld, beim Thema “Macht und Interessen”. Angenommen, Sie haben nicht nur einen Datenschutzbeauftragten, sondern mehrere. Einige favorisieren das Rollenkonzept, andere eine zusätzliche Aufzeichnung der Lesezugriffe. Die Interessen liegen auseinander, es fehlt in der machtvollen Stakeholdergruppe „Datenschutzbeauftragte“ an Einigkeit. Wie gehen Sie vor, um die Anforderungen zu harmonisieren? Man muss die Stakeholder zusammenbringen und dafür sorgen, dass sie eine Sprache sprechen. Das haben wir in unserem Programm auch geschafft. Wir haben sie Gruppen bilden lassen. Aha? Manchmal sind in der Gruppe der Datenschutzbeauftragten nur wenige wirklich IT-affin. Der Rest interessiert sich wenig für Software, soll sie nun aber bewerten. Wir haben die Gruppe überzeugt, dass ihre IT-Affinen eine Art Vorprüfgruppe zu bilden. Plötzlich haben nicht mehr alle mitgeredet… …- und wir haben Geschwindigkeit in den Prozess gebracht. Es kommt immer darauf an, dass die Stakeholder der Lösung vertrauen. Vertrauen ist ein gutes Stichwort. Manchmal fehlt es. Dann wenden sich argwöhnische Stakeholder bei leisesten Verdachtsmomenten an ihre Vorsetzten. Plötzlich zieht ein Konflikt Kreise. Dann wird es knifflig. Wie bereiten Sie sich darauf vor? In meinem Programm habe ich klar definierte Eskalationsinstanzen geschaffen. Dafür muss ich natürlich auch die Eskalationsinstanzen auf der Seite der Stakeholder im Blick haben. Wer ist der Vorgesetzte, an den sich ein Stakeholder wendet? Diese Gruppen muss ich dann in meine Kommunikation einbeziehen und auch bei ihnen Vertrauen aufbauen. Allgemein gefragt-- welche Fehler beobachten Sie häufig beim Umgang mit Macht und Interessen? Manchmal wird versäumt zu verstehen, was hinter den Interessen der Stakeholder steht. Man nimmt nur die Anforderungen eines Stakeholders zur Kenntnis. Man versucht nicht tiefer zu verstehen, was diese Anforderungen auslöst. Zum Beispiel: Ein Stakeholder hat Macht. Tiefer verstehen würde bedeuten, weitere Fragen anzuschließen: Was, wenn er seine Macht verliert-- oder noch mehr Macht gewinnt? Ja. Wer gewinnt durch das Projekt- - und ist ein Unterstützer? Es ist aus meiner Sicht wichtig, auch mit den Unterstützern regelmäßig zu kommunizieren-- und nicht nur dann, wenn man sie plötzlich braucht. Es geht dabei auch um emotionale Intelligenz. Als Leiter eines Programms muss ich andere Menschen einschätzen können-- entweder selbst oder mit Hilfe anderer. Inwiefern mit Hilfe anderer? Ich bearbeite als Programmleiter ja nicht das Stakeholdermanagement selbst. Wir haben in unserem Programm gut 60 Stakeholdergruppen, von denen ich fünf selbst betreue. Als meine Aufgabe sehe ich eher die Arbeit am Prozess- - und nicht im Prozess. Ich strukturiere und organisiere die Prozesse so, dass wir die Ziele wir hinsichtlich der Elemente “Macht und Interessen” sowie “Compliance, Standards und Regularien” erreichen und dabei einen ausreichend guten Reifegrad damit erzielen. Gestatten Sie mir bitte eine Abschlussfrage. Ich habe den Eindruck, dass vor zehn oder fünfzehn Jahren die Standards und Regularien überschaubar waren. In der Zwischenzeit sind die internen und externen Regelwerke enorm gewachsen-- nahezu explodiert. Liege ich falsch damit? In den vergangenen zwanzig Jahren ist man in viele Bereiche tiefer eingedrungen. Die Anforderungen sind präzisier geworden- - und deshalb müssen wir heute auch mehr beachten und prüfen. Früher hat ein Projektleiter seinen Auftraggeber nach den fünf wichtigsten Risiken etwa beim Datenschutz gefragt. Heute ist dies andersherum. Oft kommt der Projektleiter mit einem langen Katalog von Risiken und versucht sich gemeinsam mit seinem Auftraggeber einen Weg durch die Regeln zu bahnen und die Relevanten zu implementieren. Als wir unser Programm gestartet haben, stand die DSGVO in den Startlöchern. Heute kann es sein, dass sogar interne Datenschützer eine DSGVO-gerechte Umsetzung nicht mehr bewerten können-- obwohl sie dafür verantwortlich sind. Wir haben in unserem Programm dafür oft eine externe Wirtschaftsberatungsgesellschaft beauftragt, die uns die regelgerechte Umsetzung mit ihrem Stempel bescheinigt hat. Compliance und Stakeholderpolitik sind heute keine Zusatzaufgaben, die man irgendwann erledigt. Sie gehören von Anfang an ins Programm -- sonst holen sie einen am Ende ein. Eingangsabbildung: © iStock.com/ okskaz