PO, SP, BM e PM: i quattro ruoli PM² che non bisogna confondere

Quinto articolo della serie “Imparare PM² attraverso un progetto”

Nel modello di governance PM², quattro ruoli formano il nucleo del Project Steering Committee:

Project Owner (PO);
Solution Provider (SP);
Business Manager (BM);
Project Manager (PM).

Le differenze sembrano evidenti finché le responsabilità non vengono inserite in un caso concreto. Chi approva il Project Charter? Chi mobilita gli sviluppatori? Chi prepara gli utenti? Chi gestisce i rischi ogni giorno? Chi risponde del successo complessivo?

Per distinguerli senza imparare elenchi isolati, conviene usare due assi:

	Lato requestor/business	Lato provider/solution
Direzione	Project Owner	Solution Provider
Gestione quotidiana	Business Manager	Project Manager

Questa matrice è la chiave dell’intero articolo.

La formula da ricordare

PO vuole il valore. SP rende possibile la soluzione. BM prepara il business. PM governa la delivery.

È una semplificazione utile, non una definizione completa. Vediamo ora cosa significa davvero.

Project Owner: accountable per il successo

Il Project Owner rappresenta il lato richiedente al Directing Layer. È lo sponsor del progetto ed è accountable per il suo successo complessivo.

Le sue responsabilità principali comprendono:

sostenere e promuovere il progetto;
definire direzione e priorità di alto livello;
assicurare l’allineamento con gli obiettivi business;
mobilitare budget e risorse del lato requestor;
possedere i principali rischi business;
approvare gli artefatti manageriali chiave;
monitorare l’avanzamento ad alto livello;
presiedere normalmente il Project Steering Committee;
assicurare che gli outcome attesi siano coerenti con gli obiettivi dell’organizzazione.

Nel progetto Prenotazioni Smart

Il PO decide che ridurre il lavoro manuale delle palestre e migliorare l’occupazione dei corsi è una priorità strategica. Autorizza l’investimento, approva gli obiettivi principali e valuta le modifiche che incidono sensibilmente su valore, budget o scadenze.

Il PO non è il PM

Il PO non aggiorna necessariamente il piano, non coordina gli sviluppatori e non gestisce ogni issue. Delega la gestione quotidiana, ma non delega l’accountability finale per il successo.

Parole-indizio: sponsor, business success, strategic direction, budget, approve, business risks.

Solution Provider: accountable per la capacità di delivery

Il Solution Provider rappresenta il lato della soluzione al Directing Layer. Garantisce che il progetto disponga delle risorse e delle competenze necessarie per produrre deliverable di qualità.

Le sue responsabilità principali comprendono:

rappresentare l’organizzazione o l’unità che fornisce la soluzione;
mobilitare risorse tecniche e specialistiche;
nominare o sostenere la nomina del Project Manager;
assicurare la capacità di delivery e la qualità complessiva della soluzione;
contribuire a Business Case e obiettivi con la prospettiva del provider;
gestire a livello direttivo fornitori, competenze e vincoli tecnici;
sostenere l’integrazione, l’esercizio e la manutenzione quando pertinenti.

Nel progetto Prenotazioni Smart

Lo SP assicura la disponibilità di sviluppatori React e React Native, competenze backend, testing e infrastruttura. Se il team non dispone della capacità necessaria per rispettare la roadmap, è lo SP che deve contribuire a risolvere il problema a livello di risorse.

Lo SP non è il responsabile dei benefici

Lo SP deve fornire una soluzione adeguata, ma non può garantire da solo che le palestre la adottino. L’adozione e i benefici appartengono principalmente alla linea business.

Parole-indizio: provider, technical resources, delivery capacity, solution quality, appoint PM.

Business Manager: responsible per outcome e adozione

Il Business Manager opera al Managing Layer sul lato requestor. Agisce quotidianamente per conto del Project Owner e trasforma gli obiettivi business in esigenze, cambiamenti organizzativi e attività di adozione.

Le sue responsabilità principali comprendono:

contribuire alla definizione di obiettivi e requisiti business;
coordinare gli User Representatives;
elaborare il Business Case sotto l’accountability del PO;
pianificare e guidare la Business Implementation;
coordinare il Business Implementation Group;
preparare processi, utenti e organizzazione;
sostenere transizione, formazione e comunicazione;
assicurare che gli output generino outcome e benefici.

Nel progetto Prenotazioni Smart

Il BM coinvolge le palestre pilota, definisce come cambierà la gestione delle prenotazioni, organizza formazione e comunicazione e verifica che la funzione venga realmente adottata.

Il BM non gestisce la costruzione tecnica

Il BM chiarisce bisogni e priorità e collabora strettamente con il PM, ma non coordina direttamente lo sviluppo quotidiano del prodotto: questa è responsabilità del PM.

Parole-indizio: business needs, users, adoption, business implementation, outcomes, benefits.

Project Manager: responsible per la gestione quotidiana

Il Project Manager opera al Managing Layer sul lato provider. È responsabile della gestione quotidiana e del coordinamento del lavoro necessario a produrre i deliverable entro i vincoli concordati.

Le sue responsabilità principali comprendono:

proporre e attuare i piani approvati;
coordinare il Project Core Team;
gestire scope, tempi, costi e qualità;
gestire rischi, issue, modifiche e comunicazioni;
produrre e mantenere gli artefatti manageriali;
monitorare avanzamento e performance;
assicurare l’integrazione dei deliverable;
riferire al Project Steering Committee;
facilitare decisioni ed escalation.

Nel progetto Prenotazioni Smart

Il PM costruisce il Project Work Plan, coordina analisi, sviluppo e test, monitora rischi e dipendenze, gestisce le richieste di modifica e comunica l’avanzamento al PSC.

Il PM non è il proprietario del progetto

Il PM può essere responsabile della delivery e della maggior parte delle attività manageriali, ma non sostituisce il PO nell’accountability per il successo business né decide autonomamente cambiamenti che superano la propria autorità.

Parole-indizio: day-to-day, plans, coordination, PCT, scope, time, cost, quality, reporting.

Il confronto completo

Dimensione	PO	SP	BM	PM
Lato	Requestor	Provider	Requestor	Provider
Livello	Directing	Directing	Managing	Managing
Focus	Successo e valore	Capacità e qualità della soluzione	Outcome, benefici e adozione	Deliverable e vincoli
Orizzonte	Strategico/direzionale	Strategico/direzionale	Quotidiano business	Quotidiano delivery
Gruppo guidato	PSC, normalmente	Risorse provider a livello direttivo	BIG e User Representatives	PCT
Domanda tipica	Stiamo finanziando il progetto giusto?	Possiamo fornire la soluzione adeguata?	Il business è pronto a usarla?	Possiamo consegnarla correttamente?

Le quattro coppie che generano più errori

PO o BM?

Entrambi rappresentano il lato business.

il PO dirige, sponsorizza e approva;
il BM gestisce quotidianamente esigenze, utenti e implementazione business.

Se la domanda parla di approvazione, sponsorship o accountability complessiva, pensa al PO. Se parla di adozione, User Representatives o Business Implementation, pensa al BM.

SP o PM?

Entrambi rappresentano il lato provider.

lo SP assicura capacità, risorse e qualità a livello direttivo;
il PM pianifica, coordina e controlla la delivery quotidiana.

Se manca uno sviluppatore chiave e occorre mobilitare capacità organizzativa, pensa allo SP. Se bisogna ripianificare le attività del team, pensa al PM.

PO o PM?

La somiglianza dei nomi è una trappola frequente.

il Project Owner possiede l’accountability del successo;
il Project Manager possiede la responsabilità della gestione quotidiana.

Il PM propone e gestisce. Il PO approva e risponde del risultato business.

BM o PM?

Sono i due ruoli che devono collaborare più frequentemente.

il BM massimizza efficacia, outcome e adozione;
il PM massimizza efficienza della delivery entro scope, tempo, costo e qualità.

Il progetto fallisce se uno dei due lavora bene e l’altro no: si può avere una buona soluzione non adottata oppure un business motivato senza una soluzione consegnabile.

Chi fa cosa in cinque situazioni

1. Una palestra richiede una nuova funzione

BM chiarisce bisogno e valore con gli utenti;
PM analizza impatto su scope, tempi, costi e qualità;
PO e/o PSC approvano se la modifica supera le soglie delegate;
SP verifica la capacità tecnica necessaria.

2. Manca uno sviluppatore mobile

PM evidenzia rischio e impatto;
SP mobilita o procura la capacità necessaria;
PSC decide eventuali compromessi rilevanti;
PO valuta l’impatto sulle priorità business.

3. Le palestre non utilizzano la funzione pilota

BM indaga ostacoli e coordina azioni di adozione;
BIG interviene su formazione, processi e comunicazione;
PM supporta le modifiche necessarie alla soluzione;
PO verifica se i benefici restano raggiungibili.

4. Il progetto supera la tolleranza di budget

PM misura, segnala ed elabora opzioni;
PSC valuta le alternative;
PO sostiene la decisione dal punto di vista business;
AGB viene coinvolto se la decisione supera l’autorità del progetto.

5. Un deliverable non supera i test

PM coordina correzione e ripianificazione;
PCT esegue il lavoro tecnico;
SP assicura qualità e risorse del provider;
BM e utenti verificano che la soluzione corretta soddisfi il bisogno.

Approvare non significa produrre

Un errore comune è attribuire un artefatto a chi lo approva invece che a chi lo prepara.

Per esempio, nel Business Case:

il PO è Accountable;
il BM è Responsible;
SP e PM possono fornire supporto;
altri stakeholder possono essere consultati o informati.

La domanda “chi approva?” può avere una risposta diversa da “chi prepara?”. È necessario leggere il verbo con precisione.

Da non confondere

Se la domanda parla di…	Ruolo più probabile
successo complessivo, sponsorship, approvazione	PO
risorse tecniche, capacità di delivery, qualità della soluzione	SP
utenti, adozione, benefici, Business Implementation	BM
piano, coordinamento, controllo, reporting, PCT	PM

Questa tabella è un aiuto, non una sostituzione del contesto: una decisione complessa può coinvolgere tutti e quattro.

Verifica ciò che ricordi

Quali ruoli appartengono al lato requestor e quali al provider?
Chi è accountable per il successo complessivo?
Chi mobilita principalmente le risorse tecniche?
Chi guida la Business Implementation?
Chi coordina il Project Core Team?

Risposte

Requestor: PO e BM. Provider: SP e PM.
Il Project Owner.
Il Solution Provider.
Il Business Manager.
Il Project Manager.

Flashcard

D: PO e BM appartengono a quali livelli?
R: PO al Directing Layer; BM al Managing Layer.

D: SP e PM appartengono a quali livelli?
R: SP al Directing Layer; PM al Managing Layer.

D: Chi è orientato principalmente agli outcome?
R: Il Business Manager, sotto la direzione e accountability del Project Owner.

D: Chi è orientato principalmente agli output?
R: Il Project Manager, con capacità e direzione fornite dal Solution Provider.

D: Chi normalmente presiede il PSC?
R: Il Project Owner.

Domanda in stile esame

Durante un progetto, gli utenti non sono pronti ad adottare la nuova soluzione. Chi dovrebbe assumere la responsabilità principale di coordinare le attività necessarie a preparare l’organizzazione?

A. Project Owner.
B. Solution Provider.
C. Business Manager.
D. Project Manager.

Risposta corretta: C. Il Business Manager guida la Business Implementation e coordina le attività necessarie a trasformare gli output del progetto in outcome e benefici.

Nel prossimo articolo

Nel prossimo articolo completeremo la mappa dei ruoli con AGB, PSC, BIG, PCT, PST e User Representatives, chiarendo funzione, composizione e rapporti con i quattro ruoli centrali.

Fonti essenziali

European Commission, PM² Project Management Methodology – Highlights, 2025 Edition.
European Commission, The PM² Governance Model.