Ruoli e responsabilità nei progetti IT: la matrice RACI per una rapida chiarificazione per i decisori

In molti progetti IT il collo di bottiglia non è la tecnologia, ma la domanda: chi decide cosa – e chi lo realizza? Se ruoli e responsabilità in un progetto IT sono chiariti solo «a sentimento», emergono schemi tipici: i requisiti vengono concordati più volte, i ticket girano in loop, le accettazioni si dilatano e in caso di incidenti non è chiaro chi dia le priorità o comunichi. È proprio qui che la RACI-Matrix è uno strumento pragmatico: rende visibili le responsabilità, riduce gli attriti alle interfacce e accorcia i percorsi decisionali – senza pesante burocrazia di governance.

Il beneficio è particolarmente rilevante in progetti con più aree di business, unità operative, requisiti di Security/Compliance o fornitori esterni. I decisori ottengono un quadro chiaro di dove risiede realmente la responsabilità, e la direzione del progetto così come l’amministrazione IT possono progettare i processi in modo che delivery e operatività non lavorino l’uno contro l’altro. Importante: RACI non è un organigramma né un sostituto della leadership. È un allineamento su compiti, decisioni e obblighi informativi – lungo work package reali, flussi di dati e passaggi.

Perché le responsabilità nei progetti IT spesso sfociano in escalation

Responsabilità non chiare raramente emergono il primo giorno. Diventano evidenti quando la complessità aumenta: più sistemi, dipendenze, requisiti di sicurezza, migrazione dei dati, rilasci paralleli. Allora il «lo facciamo insieme» non basta più. In pratica emergono tre cause particolarmente ricorrenti:

• Interfacce tra team: area di business, IT, operazioni, Security, acquisti e partner esterni perseguono obiettivi diversi e hanno definizioni diverse di «completo».
• Decisioni senza un owner chiaro: se nessuno è formalmente responsabile, si procede per «consenso». Questo costa tempo e spesso porta a decisioni formulate in modo vago.
• Pressione operativa: al più tardi in caso di malfunzionamenti, finestre di Change o preparazione del Go-live bisogna agire rapidamente. In quel momento l’assenza di un percorso di escalation diventa immediatamente costosa.

Proprio in paesaggi aziendali maturi le responsabilità sono distribuite storicamente: un sistema è assegnato funzionalmente alle vendite, tecnicamente all’IT, gestito da un fornitore, le interfacce sono manutenute dal Team A, la qualità dei dati è collocata «da qualche parte». Quando un progetto modernizza o estende questo paesaggio, i gap di responsabilità diventano non solo organizzativi ma concretamente tecnici: chi autorizza una Breaking Change su una REST-interfaccia? Chi assume il rischio in una pulizia dei dati? Chi decide se applicare una patch di sicurezza al di fuori della finestra di manutenzione?

RACI-Matrix in der Praxis: Bedeutung von R, A, C und I

RACI è un modello di ruoli che distingue, per attività (o Deliverable), quattro tipi di coinvolgimento. È importante il significato preciso, altrimenti il modello si diluisce rapidamente:

• R – Responsible (responsabilità di esecuzione): Chi svolge concretamente il compito? Possono essere più persone o più team.
• A – Accountable (responsabilità del risultato): Chi porta la responsabilità finale e decide in caso di dubbio? Per ogni attività dovrebbe esserci esattamente un ruolo accountable, altrimenti sorgono doppie responsabilità.
• C – Consulted (consultato): Chi deve essere coinvolto dal punto di vista funzionale/tecnico prima che si decida o si esegua? La consultazione è uno scambio attivo, non una mail informativa.
• I – Informed (informato): Chi deve essere informato sul risultato, sulla scadenza o sul rischio? Si tratta di informazione unilaterale, non di partecipazione decisionale.

Per i decisori la linea di demarcazione tra Responsible e Accountable è di solito la leva più importante. Nei progetti IT i compiti vengono spesso delegati, ma la responsabilità non viene trasferita in modo chiaro. Così un team può „lavorare“, ma nessuno decide in modo vincolante nei conflitti di obiettivi (scope vs. affidabilità operativa, time-to-market vs. qualità dei dati, richiesta di funzionalità vs. requisiti di sicurezza).

Per cosa la matrice RACI è particolarmente adatta — e per cosa no

RACI funziona bene quando i compiti sono ricorrenti o possono essere descritti come deliverable chiari. Esempi tipici:

• Processi di change e release: approvazione, finestre di manutenzione, decisione di rollback, comunicazione.
• Collaudi e accettazioni: UAT (User Acceptance Test, accettazione funzionale), collaudo tecnico, approvazione security, rilascio in esercizio.
• Integrazione e interfacce: contratti API, versioning, responsabilità di monitoring, escalation degli incidenti.
• Migrazione dei dati: mapping, pulizia dei dati, approvazione delle regole di trasformazione, report di riconciliazione.
• Passaggio in esercizio: runbook (istruzioni operative), monitoring, regole di on-call, ownership nell’operatività quotidiana.

RACI non è ideale quando i compiti sono formulati in modo troppo generico („consegnare il progetto“, „garantire la qualità“) o quando il team usa la matrice come sostituto della vera comunicazione. RACI non sostituisce lo stakeholder management né la leadership; li struttura. Inoltre RACI non è uno strumento per misurare le performance dei singoli; è uno strumento di governance pensato per far fluire il lavoro.

Come creare una matrice RACI in 60–90 minuti

Una buona matrice RACI non si crea alla scrivania, ma in workshop con i ruoli rilevanti. L’obiettivo non è la completezza fino all’ultima attività specialistica, ma chiarezza sui percorsi critici. Un flusso operativo pratico:

1. Definire lo scope: per quale fase vale la matrice (es. progetto fino al go-live, hypercare, esercizio regolare) e per quale catena di processo (es. change fino al release)?
2. Segmentare i compiti: 10–25 compiti sono spesso sufficienti. Formulate i compiti come risultati: „approvare il contratto di interfaccia“, „definire gli allarmi di monitoring“, „finalizzare il data mapping“.
3. Ruoli invece di nomi: usate ruoli (es. IT-Operations, owner del business, Product Owner, Security, fornitore esterno). I nomi cambiano, i ruoli no.
4. R e A prima: assegnate esattamente una A per compito, poi la R. C e I li aggiungete solo quando R/A sono stabili.
5. Risolvere i conflitti apertamente: se due ruoli vogliono essere „A“, si tratta di una questione di governance. Chiarite i diritti decisionali, non solo la partecipazione.

Per la direzione IT e i responsabili di progetto è particolarmente importante che la matrice sia collegata a vere routine di governance: Change Advisory Board (CAB, organismo per l’approvazione dei change), Weekly Steering, Incident-Review, meeting di accettazione. Senza questo ancoraggio la RACI resta un documento che nessuno utilizza.

La matrice RACI come acceleratore decisionale per la direzione e lo steering

Nei gruppi di governo e nelle riunioni di stato spesso si discute sui contenuti, mentre la vera domanda è: chi ha il potere di decidere? Una matrice RACI mantenuta con cura consente tre semplificazioni:

• I percorsi decisionali diventano espliciti: se «A» è chiaro, un tema può essere preparato e quindi deciso, invece di girare in tondo.
• Le escalation diventano oggettive: un’escalation non è allora un fallimento personale, ma un passo definito quando R e A non trovano accordo o quando i rischi riguardano budget/ambito.
• I rischi ricevono un owner: i log dei rischi senza responsabili non hanno valore. RACI obbliga ad assegnare le decisioni sui rischi a un owner accountable.

I decisori traggono particolare beneficio se la RACI è combinata con un breve Decision-Log: cosa è stato deciso, da chi (A), con quali ripercussioni su ambito, operatività e scadenze? Questo riduce le discussioni successive in fase di accettazione o audit, perché risulta tracciabile il motivo della scelta adottata.

Errori tipici nella matrice RACI – e come evitarli

1) Troppi «A» per attività

Più ruoli accountable sono un riflesso frequente per evitare conflitti («decidiamo insieme»). Nella pratica però ciò genera incertezza: se due funzioni sono finalmente responsabili, in caso di dubbio nessuno si sente incaricato. Meglio: un solo A, consultazioni chiare (C) e un percorso di escalation definito nel caso in cui emergano obiezioni da parte di C.

2) «C» diventa co-decisione

Le funzioni consultate sono importanti, per esempio sicurezza, protezione dei dati, architettura o operation. Tuttavia se «C» esercita di fatto un diritto di veto senza assumersi una responsabilità formale, l’equilibrio decisionale si altera. Chiarite quindi contestualmente: quali criteri portano a uno stop? Dove si tratta solo di una raccomandazione? E chi decide in caso di conflitto di obiettivi? Questo è governance, non «politica».

3) Le attività sono troppo generiche o non operazionalizzabili

«Testare» non è una buona attività. Meglio: «approvare l’ambito del regression test», «fornire i dati di test», «spuntare la checklist per il Go-live». Più l’attività è concreta, più semplice è l’assegnazione – e tanto più RACI aiuta nella pratica quotidiana (ticket, approvazioni, passaggi).

4) RACI non viene adattata alla realtà operativa

Molti progetti creano una matrice per la fase di progetto, ma non per il periodo successivo. Proprio in quel momento emergono le lacune note: chi gestisce la nuova interfaccia? Chi aggiorna i certificati? Chi mantiene i ruoli utente? Chi valuta gli alert? Pianificate la RACI almeno per due fasi: progetto fino al Go-live e Hypercare/operatività regolare.

RACI lungo il ciclo di vita: dai requisiti all’esercizio

Per evitare che RACI rimanga solo un artefatto di kickoff, vale la pena esaminare le fasi tipiche di progetto. I decisori possono così verificare in modo mirato se la responsabilità è davvero coperta in modo continuo.

Anforderungen und Scope

Per software aziendale su misura e soluzioni software vicine ai processi, i requisiti raramente sono „completi“; vengono invece concretizzati in modo iterativo. Questo funziona se è chiaro chi è accountable a livello funzionale per la prioritizzazione e chi deve essere consultato (p. es. il reparto operativo per la manutenibilità, la Security per i requisiti di protezione). Compiti tipici: „Priorisierung des Backlogs“, „Abnahme der Akzeptanzkriterien“, „Freigabe von Prozessänderungen“. Se qui non esiste una A, emergono scope creep e in seguito dure discussioni sull’accettazione.

Architektur, Schnittstellen und Datenflüsse

In paesaggi cresciuti nel tempo l’architettura tecnica è spesso distribuita. Una matrice RACI aiuta a chiarire la proprietà e la responsabilità per i contratti di interfaccia e i flussi di dati: chi è accountable per la stabilità di una REST-API? Chi è responsabile delle regole di mapping tra il sistema legacy e la nuova soluzione? Chi decide sulla versioning e sulla deprecation (spegnimento pianificato delle vecchie versioni dell’interfaccia)? Questi punti non sono solo tecnici: determinano se altri sistemi continuano a funzionare in modo affidabile e se operation e support sono in grado di agire in caso di errore.

Test, Abnahme und Freigaben

In molti progetti la pianificazione temporale fallisce a causa delle accettazioni. La causa raramente è „troppi pochi test“, ma responsabilità poco chiare: chi fornisce i dati di test? Chi prioritizza i difetti? Chi decide se un Known Issue (errore noto) è idoneo al go-live? Una RACI chiara rende pianificabili i processi di accettazione, perché si sa quale ruolo deve prendere una decisione e quando – e chi invece viene solo informato.

Go-live, Hypercare und Betriebsübergabe

Al più tardi al Go-live la governance diventa operativa: il Monitoring deve essere attivo, i Runbooks devono essere comprensibili, l’On-Call deve sapere chi contattare per questioni funzionali. RACI struttura questo passaggio. Compiti tipici: „Freigabe Go-live“, „Einrichtung Monitoring und Alarmrouting“, „Betriebsdokumentation abnehmen“, „Übergabe an Service Desk“. Particolarmente importante: definite chi è accountable per la capacità operativa (non solo per la consegna).

RACI in gemischten Setups: intern, extern, Dienstleister

Molte aziende collaborano con partner esterni: per sviluppo, esercizio, infrastruttura o tematiche specialistiche. In questi casi RACI è doppiamente importante, perché i confini contrattuali vengono spesso confusi con i limiti di responsabilità. Un fornitore può essere Responsible per l’implementazione, ma l‘Accountable rimane frequentemente interno, ad esempio al system owner o alla direzione IT. Non è una dichiarazione di sfiducia, ma necessaria per governo, budget e rischio.

Linee guida pratiche per il coinvolgimento esterno:

• Accountable bleibt dort, wo Risiko und Entscheidung liegen: Budget, Priorisierung, Akzeptanz von Risiken, Freigaben.
• Responsible ist dort, wo tatsächlich gearbeitet wird: Implementierung, Konfiguration, Monitoring-Setup – mit klaren Akzeptanzkriterien.
• C und I müssen in Vertrag und Betriebsprozesse passen: Wer muss vor Changes konsultiert werden? Wer wird bei Incidents informiert? Das gehört in die Betriebsvereinbarung, nicht nur in die Projektpräsentation.

Gerade bei Schnittstellen ist eine häufige Falle: Der Anbieter „betreibt“ zwar, aber niemand ist accountable für die Ende-zu-Ende-Kette. RACI sollte daher Aufgaben enthalten wie „Ende-zu-Ende-Monitoring definieren“ oder „Incident-Kommunikation an Stakeholder steuern“ – mit klaren Owners.

RACI trifft Compliance, Security und Datenschutz: klare Mitwirkung statt Blockade

Security und Datenschutz werden in Projekten oft als „Stopper“ erlebt, wenn sie spät eingebunden werden oder wenn Anforderungen nicht in umsetzbare Kriterien übersetzt sind. RACI kann hier entlasten: Security/Datenschutz werden gezielt als Consulted in die relevanten Aufgaben eingebunden, und die accountable Rolle entscheidet auf Basis definierter Kriterien.

Wichtig ist die Unterscheidung zwischen:

• Policy-Anforderungen (z. B. Mindeststandards für Authentifizierung, Protokollierung, Aufbewahrung): Hier sollten klare Prüfpunkte existieren, damit Konsultation planbar ist.
• Risikoentscheidungen (z. B. temporäre Ausnahme, REST-Risiko): Hier muss eine accountable Rolle benannt sein, die das Risiko trägt und dokumentiert.

So bleibt Security wirksam, ohne dass Entscheidungen in diffuse Abstimmungsschleifen geraten. Für den Betrieb ist das essenziell: Auditierbarkeit entsteht nicht durch mehr Meetings, sondern durch klare Verantwortlichkeit und nachvollziehbare Entscheidungen.

Minimal-Template: Welche Aufgaben in eine RACI-Matrix gehören

Als Startpunkt hat sich ein „Minimal-Set“ bewährt, das die kritischen Pfade aBDEckt. Je nach Projekt können Sie ergänzen, aber dieses Set verhindert die typischen Lücken:

• Backlog-/Scope-Priorisierung und Change-Control (Umgang mit neuen Anforderungen)
• Freigabe von Architekturentscheidungen (z. B. Integration, Datenhaltung, Authentifizierung)
• Schnittstellenvertrag und Versionierung (inkl. Deprecation-Plan)
• Datenmigration: Mapping, Bereinigung, Abgleich, Freigabe
• Testdatenbereitstellung, UAT-Planung, Mängelklassifikation und Entscheidung Go/No-Go
• Release- und Change-Freigabe (Wartungsfenster, Rollback, Kommunikation)
• Monitoring/Alerting, Log-Zugriffe, Verantwortlichkeit für Alarmrouting
• Runbooks, Betriebsdokumentation und Übergabe an Service Desk / Betrieb
• Incident-Eskalation und Kommunikationsverantwortung

Questo template è intenzionalmente vicino ai processi. Collega il lavoro di progetto alla realtà operativa: chi in un progetto IT si limita a „consegnare“ senza chiarire chi lo gestirà poi genera costi a valle – nel supporto, nella stabilità e nelle successive fasi di modernizzazione.

Come utilizzare RACI nella pratica: ticket, meeting, passaggi di consegna

Il passo decisivo è l’operazionalizzazione. Tre meccanismi semplici portano RACI dalla teoria alla pratica quotidiana:

Collegare RACI ai processi di ticket e change

Quando viene creato un ticket di change, deve essere chiaro chi, in qualità di accountable, dà l’approvazione e chi deve essere consultato. Questo può essere rappresentato in campi del modulo, checklist o in un workflow di change. In questo modo RACI non viene gestito „di contorno“, ma risiede nel processo.

RACI come slide standard per decisioni critiche

Per temi come modifica di interfacce, pulizia dei dati o decisione di go-live spesso basta una breve rappresentazione: attività, decisione proposta, rischio e assegnazione RACI. Questo disciplina le discussioni: chi decide? chi fornisce input? chi viene informato? In questo modo le riunioni restano brevi e aumenta l’orientamento ai risultati.

Inserire RACI nella documentazione di consegna e operativa

I runbook e i documenti operativi sono efficaci solo se contengono una sezione di ownership: System-Owner (A), team operativo (R), Security/Privacy (C) e stakeholder rilevanti (I). Questo evita che, in caso di turnover del personale o di cambio fornitore, si riapra la stessa discussione sulle responsabilità.

Conclusione: la matrice RACI è piccola, ma efficace nei punti giusti

La matrice RACI non è un framework complesso di project management, ma uno strumento rapido per chiarire ruoli e responsabilità nel progetto IT. Il suo effetto si manifesta dove i progetti tipicamente perdono tempo: nelle decisioni, nelle interfacce, nelle approvazioni e nei passaggi al funzionamento. Chi adatta RACI alle consegne reali, assegna per ogni attività esattamente un ruolo accountable e collega la matrice ai processi di change, ticket e handover, riduce i cicli di coordinamento e rende i rischi gestibili – per IT, linee di business e decisori allo stesso modo.

Se in un progetto in corso desiderate affinare pragmaticamente ruoli, percorsi decisionali o il passaggio in esercizio, vale la pena un breve workshop di allineamento con i ruoli rilevanti. Contattateci volentieri per questo:

Per questo tema sono importanti anche Chiarire le responsabilità e Governance nel progetto. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.

Discutere progetto o iniziativa di modernizzazione con Net-Base.