Projekt‑Governance und RACI etablieren

Ziel ist es, die „Spielregeln“ eines FM-Projekts so festzulegen, dass Verantwortung, Entscheidung und Kommunikation konsistent zusammenpassen: Wer entscheidet was (und wann), wer liefert welche Ergebnisse, wer muss verbindlich eingebunden werden und wer wird in welcher Frequenz informiert. Die Methode schafft damit die Basis für nachvollziehbare Steuerung, Planbarkeit und kontrollierte Änderungen (Change Control) über den gesamten Projektlebenszyklus hinweg—einschließlich definierter Entscheidungspunkte und Gates, wie sie in ISO 21502 als modernisierte Projektmanagement-Praxis explizit hervorgehoben werden.

Ein weiterer Kernnutzen ist die Verknüpfung von Rollenklärung mit Kommunikationsdesign: RACI ist nicht nur „Organigramm-Logik“, sondern wirkt als operationalisierbarer Kommunikationsstandard. In der PMI-Praxisliteratur wird RACI explizit als Baseline für den Kommunikationsplan beschrieben (wer erhält welche Information, wie häufig, in welcher Detailtiefe). Dadurch wird Governance in den Alltag übersetzt und nicht nur als „Gremium“ verstanden.

Die Methode ist grundsätzlich für alle Projektarten geeignet, weil ISO 21502 projektmanagementbezogene Leitlinien als organisations- und projektartenunabhängig beschreibt (unabhängig von Zweck, Delivery Approach, Größe, Dauer, Komplexität). Damit ist sie sowohl in klassischen (predictive) FM-Projekten als auch in iterativen/hybriden Vorhaben anwendbar.

Im FM-Kontext eignet sie sich insbesondere für Vorhaben mit vielen internen und externen Stakeholdern, z. B. bei Modernisierung/Umnutzung im Bestand, Betriebs- und Betreiberorganisationen, Service-Desk- und Ticketing-Design, CAFM/CMMS/IWMS-Einführungen, sowie bei strategischem Sourcing/Outsourcing und der Entwicklung von Leistungs- und Vertragswerken. ISO 41012 betont dafür die Bedeutung strukturierter Vereinbarungen (Typen von Agreements, Aufbau/Inhalte), um Wert zu schaffen und Betriebskosten zu optimieren—was ohne klare Governance und klare Rollen-/Entscheidungslogik typischerweise nicht stabil gelingt.

• Typische Auslöser sind wiederkehrende Unklarheiten im Tagesgeschäft oder in Transformationen: „Wer genehmigt Änderungen?“, „Wer priorisiert?“, „Wer trägt das Risiko?“, „Wer ist für Abnahme/Übergabe verantwortlich?“—insbesondere dann, wenn FM-Projekte an der Schnittstelle zwischen Betrieb (Operations) und Projekt (Change/Build) liegen. ISO 21502 hebt genau diesen erweiterten Blick auf projektbezogene Oversight-/Direction-Aktivitäten der sponsoring organization sowie auf Entscheidungspunkte/Gates und Change-Control-Aspekte als zentrale Weiterentwicklung hervor.

• Häufig verstärken FM-spezifische Rahmenbedingungen die Problematik: mehrere Gewerke und Servicepartner, reale Sicherheits- und Compliance-Risiken, hohe Erwartung an „Betrieb darf nicht stehen“, sowie die Notwendigkeit, Stakeholder-Bedürfnisse und Anforderungen konsistent zu erfüllen (ISO 41001). Zusätzlich spielen Risikologiken eine Rolle: ISO 31000 beschreibt Risiko-Management als organisationsweite Praxis von Identifikation bis Kommunikation/Monitoring und betont die Einbettung in Governance, Strategie und Reporting—genau dort, wo Projekt-Governance und RACI strukturell andocken.

Damit die Methode nicht nur dokumentiert, sondern tatsächlich gelebt werden kann, braucht sie einen klaren Startpunkt (Autorisation), definierte Steuerungsmechanismen und ein Mindestmaß an Organisationsdisziplin. Die folgenden Voraussetzungen orientieren sich an den in ISO 21502 beschriebenen Governance-/Rollenbegriffen (z. B. Sponsor, Project governance) sowie an bewährter RACI-Logik zur eindeutigen Verantwortungszuordnung.

• Klarer Projektauftrag inkl. Zielbild, Scope-Grenzen und Erfolgskriterien (als Governance-Referenz und Entscheidungsmesslatte).

• Benannter Sponsor mit Ressourcen- und Entscheidungsfähigkeit (Rollenverankerung auf Führungsebene).

• Festgelegtes Governance-Modell (Gremien, Entscheidungsrechte, Eskalationswege, Kadenz).

• Zustimmung der betroffenen Linien-/Betriebsorganisation (weil FM Betrieb, Sicherheit und Nutzererlebnis kontinuierlich sicherstellen muss).

• Definierte Informations- und Dokumentationsführung (Single Source of Truth für Governance-Artefakte).

• Mindeststandard für Änderungskontrolle (Change Requests, Genehmigungslogik, Dokumentation).

• Bereitschaft zur gemeinsamen Rollenklärung (Workshops, Konfliktlösung, verbindliche Entscheidungen).

• Toolseitige Ablage-/Kommunikationsfähigkeit (z. B. Kollaboration, Ticketing, Reporting).

Die Methode ist datenarm im Sinne von „wenig Spezialdaten“, aber datenpräzise im Sinne von „die richtigen Referenzen zur richtigen Zeit“. Die benötigten Daten leiten sich vor allem aus Stakeholder-/Rollenklärung, Agreement-/Anforderungslogik (ISO 41012) sowie aus Governance-, Reporting- und Risikoanforderungen (ISO 21502/ISO 31000) ab.

• Organisationsstruktur, relevante Linienfunktionen und Entscheidungsinstanzen (inkl. Schnittstellen zu IT, Einkauf, HSE, Finance).

• Stakeholderliste inkl. Betroffenheit/Einfluss und Kommunikationsbedarfen.

• Projektziele, Scope-Abgrenzung, Erfolgs-/Abnahmekriterien und (falls vorhanden) Business Case.

• Deliverables/Leistungsgegenstände (z. B. Betriebskonzept, SLA/XLA-Änderungen, Systemkonfiguration, Übergabeunterlagen).

• Bestehende Agreements/Verträge und geplante Sourcing-Entscheidungen (intern/extern).

• Anforderungsquellen: regulatorische/vertragliche Anforderungen, interne Standards/Policies, Stakeholder-Bedürfnisse.

• Risiko-/Issue-Überblick (Top-Risiken, Abhängigkeiten, Betriebsauswirkungen).

• Reporting-/Steuerungsanforderungen (Status, KPIs, Eskalationsschwellen, Meeting-Kadenz).

Im Kern folgt die Rollenarchitektur dem Prinzip: Es gibt eine klare letztverantwortliche Instanz (Sponsor/Accountable auf Governance-Ebene), eine operative Führungsrolle (Projektleitung) und definierte Assurance-/Support-Mechanismen. ISO 21502 definiert u. a. Sponsor und Project Assurance als eigenständige Rollenbegriffe; PMI konkretisiert Sponsor-Verantwortung (u. a. Business-Nutzen, Eskalationen, Go/No-Go, Governance-Struktur).

• Sponsor (A auf Projektebene): Stellt Ressourcen/Entscheidungen sicher, verantwortet Nutzen und ist Eskalationsinstanz für Entscheidungen außerhalb der Projektleitung.

• Lenkungsausschuss/Steering Committee (kollektive Governance): Richtet Projekt an Strategie aus, trifft/validiert Schlüsselentscheidungen und überwacht Fortschritt/Abweichungen.

• Projektleitung/Project Manager (R für Steuerung, Lieferung sicherstellen): Plant und steuert Umsetzung, koordiniert Teams/Dienstleister, betreibt Reporting, führt Logs (Risiken/Issues/Changes).

• FM-Projekt-Owner bzw. FM-Lead (Accountable für FM-Fit): Stellt sicher, dass Deliverables betrieblich integrierbar sind (Betrieb, Nutzer, Servicequalität).

• Technisches FM / Betreibervertretung (Consulted/Responsible je nach Deliverable): Bringt Betreiberpflichten, technische Risiken, Instandhaltungs- und Übergabethemen ein.

• HSE/Compliance (Consulted/Approval-Gates): Bewertet Risiken, Compliance-/Sicherheitsanforderungen und Kontrollmechanismen.

• Einkauf/Procurement (Responsible für Sourcing/Agreements): Steuert Vergabe, Vertrags-/SLA-Struktur und Lieferanteninterfaces.

• Finance/Controlling (Consulted/Approval bei Budget/Business Case): Stellt finanzielle Transparenz, Budgetlogik und KPI-Fähigkeit sicher.

• IT/CAFM/IWMS-Owner (Responsible für System-Umsetzung, Consulted für Prozessdesign): Sichert Rollen-/Berechtigungslogik, Integrationen und produktionsfähigen Betrieb.

• Dienstleister/Service Provider (Responsible für vertraglich definierte Arbeitspakete): Liefert Leistungen nach vereinbarter Governance (Abnahme, Reporting, Eskalation).

• Project Assurance / PMO (unabhängige Qualitätssicherung): Schafft Vertrauen in Zielerreichung durch geplante/systematische Maßnahmen (Assurance) und unterstützt Standardisierung.

Die Vorgehensstruktur ist so gestaltet, dass Governance nicht „zusätzlich“ wirkt, sondern als Betriebssystem des Projekts: Sie definiert Entscheidungsrechte (Project governance), operationalisiert Rollen über RACI und verbindet das Ganze mit Kommunikations- und Dokumentationspraktiken (Reporting, Information & Documentation Management).

• Projekt authorisieren und Governance-Zielbild festlegen: Sponsor bestätigen, Projektauftrag schärfen, success criteria und Entscheidungsbedarfe (z. B. Budgets, Scope, Termine, Betriebsrisiken) definieren.

• Stakeholder identifizieren und Governance-Reichweite abgrenzen: Stakeholderliste erstellen, Betroffenheit/Einfluss bewerten und festlegen, welche Themen zwingend governancepflichtig sind.

• Governance-Struktur designen: Gremienmodell (Steering, Working Groups), Entscheidungsrechte, Eskalationswege, Entscheidungsrhythmus und Gate-Logik definieren (inkl. Go/No-Go).

• Governance-Artefakte und Steuerungsmechanismen definieren: Mindestset festlegen (Entscheidungslog, Risk/Issue/Change-Logs, Reporting-Template, Dokumentationsablage, Meeting-Formate).

• RACI für Kernprozesse und Deliverables erstellen: Aufgaben/Deliverables auflisten, Rollen spaltenweise definieren, pro Aufgabe genau eine „A“-Instanz sicherstellen, „R“/„C“ pragmatisch begrenzen und „I“ zielgerichtet setzen.

• RACI und Governance mit Realitätstest validieren: Workshop mit Linien, FM, Dienstleistern; Konflikte (z. B. Doppel-Accountable, fehlende Entscheidungsrechte) lösen und verbindlich dokumentieren.

• In Agreements, SLAs und Betriebsmodelle integrieren: RACI-relevante Pflichten/Entscheidungen in Vereinbarungen abbilden (z. B. Abnahme, Reporting, Eskalation, Change Control), damit Verantwortlichkeit auch außerhalb des Projektteams wirksam ist.

• Einführen, kommunizieren, befähigen: RACI als Kommunikationsbaseline nutzen, Zugänglichkeit sicherstellen (Repository), Rollen briefen und Kadenz starten (Status/Steering/Change).

• Operate & Improve: Governance regelmäßig prüfen (Bottlenecks, Entscheidungszeiten), RACI bei Scope-/Organisationsänderungen aktualisieren und Lessons Learned systematisch sichern.

Erwartet werden erstens klare, dokumentierte Governance-Bausteine (Gremienstruktur, Entscheidungsrechte, Eskalationspfade, Gate-Logik) und zweitens eine operationalisierte Rollen-/Verantwortungslandkarte in Form der RACI-Matrix. Diese Ergebnisse sind nicht nur „Papier“, sondern werden als Arbeitsgrundlage für Steuerung, Kommunikation und Auditierbarkeit genutzt—im Sinne von Project Governance als Autorisierungs- und Lenkungsrahmen.

Darüber hinaus entsteht ein konsistentes Set an Steuerungsartefakten, das für FM-Projekte besonders wertvoll ist: transparente Logs (Risiken/Issues/Changes), definierte Reporting-Routinen und eine belastbare Übergabe-/Abnahmelogik Richtung Betrieb. Diese Anschlussfähigkeit ist zentral, weil FM die Funktionalität, Sicherheit und Effizienz der gebauten Umgebung dauerhaft sicherstellen muss und ISO 41001 die konsistente Erfüllung von Stakeholder-Bedürfnissen und anwendbaren Anforderungen adressiert.

Die Methode reduziert Reibungsverluste an Schnittstellen, weil sie Rollen- und Entscheidungslogik explizit macht: RACI erhöht Klarheit, bündelt Kommunikation und steigert Accountability; zugleich minimiert sie Überschneidungen und Unklarheiten, die in komplexen Projekten besonders häufig auftreten.

Für FM entsteht ein zusätzlicher, strategischer Vorteil: Governance/RACI verknüpfen Projektarbeit mit Betriebsrealität (Betriebsrisiken, Compliance, Servicequalität) und helfen, Entscheidungen nachvollziehbar zu treffen und Risiken strukturiert zu handhaben. Das passt zur ISO-Logik, Risiko-Management in Governance/Reporting einzubetten (ISO 31000) und FM-Leistung wirksam/effizient sowie stakeholderorientiert zu erbringen (ISO 41001).

• RACI und Governance können überformalisiert werden: Zu viele „C“-Beteiligte verlangsamen Entscheidungen, zu viele Governance-Ebenen erzeugen Meeting-Overhead, und eine zu detaillierte Matrix wird schwer wartbar. Atlassian weist zudem darauf hin, dass RACI zwar Zuständigkeiten klärt, aber nicht beschreibt, wie eine Aufgabe fachlich auszuführen ist—ohne ergänzende Prozessdokumentation können Interpretationsunterschiede bleiben.

• Ein weiteres Risiko ist die Scheingenauigkeit: Wenn die Organisation die Rolle „A“ nicht mit echter Entscheidungsmacht und Ressourcen unterlegt, bleibt die Matrix formal korrekt, aber wirkungslos. Deshalb ist Sponsor-Commitment entscheidend—PMI betont Sponsorverantwortung u. a. für Governance-Struktur, Eskalation, Reviews und Go/No-Go-Entscheidungen.

Ein klassischer Einsatzbereich ist die Einführung oder Neuausrichtung eines zentralen FM-Service-Desks (Ticketing, Entstörungs- und Koordinationsprozesse). Gerade hier ist Rollen- und Schnittstellenklarheit entscheidend, weil ein Service Desk als Kommunikationszentrale dient und Systemzugriffe/Prozessketten über mehrere Disziplinen hinweg bündelt.

Ebenso typisch sind FM-Digitalisierungs- und Systemprojekte (CAFM/CMMS/IWMS), bei denen Rollen-/Berechtigungskonzepte, Daten-Governance und Integrationen zentrale Erfolgsfaktoren sind—und Governance/RACI als verbindliche Klammer zwischen Fachbereich, IT und externen Partnern wirken.

Ein drittes Feld sind strategische Sourcing- und Vertrags-/SLA-Projekte: ISO 41012 adressiert die strukturierte Entwicklung von Agreements und zielt auf Wertbeitrag und Kostenoptimierung—was in der Praxis ohne klare Verantwortungs- und Eskalationslogik (RACI + Governance) oft nicht stabil in den Betrieb übergeht.

Die Methode lässt sich besonders robust aufsetzen, wenn sie auf etablierte Standards und Frameworks referenziert: Projektgovernance- und Rollenbegriffe (ISO 21502), FM-Systemlogik (ISO 41001), Agreement-/Sourcing-Guidance (ISO 41012) sowie risikobasierte Steuerung (ISO 31000) liefern hierfür bewährte Bezugspunkte.

• ISO 21502:2020 Leitfaden für Projektmanagement

• ISO 41001:2018 Facility Management — Managementsysteme

• ISO 41012:2017 Facility Management — Strategische Beschaffung und Entwicklung von FM-Vereinbarungen

• ISO 31000:2018 Risikomanagement — Leitlinien

• ISO 55001 Asset Management — Managementsysteme — Anforderungen

• ISO 9001 Qualitätsmanagementsysteme

• ISO 45001 Managementsysteme für Sicherheit und Gesundheit bei der Arbeit

• EN 15221 (Reihe) Facility Management

• PMBOK Guide (Project Management Institute) Leitfaden zum Projektmanagement

• GEFMA-Richtlinien (z. B. zu Controlling, IT und Dokumentation, je nach Anwendungsfall)

Tools sind nicht Selbstzweck, aber ein wesentlicher Verstärker: Sie machen Governance sichtbar (Transparenz), RACI zugänglich (Single Source of Truth) und ermöglichen verbindliche Workflows (Ticketing, Change, Freigaben, Reporting). Atlassian beschreibt z. B. die Nutzung von RACI als Bestandteil der Projektplanung sowie Best Practices (u. a. ein Accountable pro Aufgabe, begrenzte Responsible/Consulted), während FM-spezifische Service-Desk-Ansätze die Rolle als Kommunikationszentrale und Systemdrehscheibe betonen.

• Projekt-Governance-Canvas/Charter-Template (z. B. als Standarddokument im Projekt-Repository).

• RACI-Matrix-Template (Spreadsheet) inkl. Review-/Versionierungslogik.

• Projektmanagement-Tooling (Backlog/Meilensteine/Abhängigkeiten) inkl. Verknüpfung zu Governance-Gates.

• Kollaborations- und Dokumentationsplattform (Governance-Artefakte, Versionierung, Entscheidungen).

• Risk-/Issue-/Change-Register inkl. Workflows und Eskalationsregeln.

• Reporting- und KPI-Dashboarding für Steuerung/Transparenz.

• Service-Desk/Ticket-System zur operativen Integration (Requests, Incidents, Entstörung, Routings).

• Sourcing-/Contract-Management-Unterstützung (Agreement-Struktur, SLA-Logik, Lieferantensteuerung).

• FM-Connect.com Network GmbH Tools/Leistungsbausteine (wo passend): FM-Audit/Analysen, Service-Desk/Customer-Counter-Konzeption, CAFM-Consulting, Controlling-/KPI-Cockpit, sowie methodische Inhalte zu Verträgen/Vereinbarungen.