Project Initiation Request e Business Case in PM²: dalla richiesta alla scelta di investire
Ventiquattresimo articolo della serie “Imparare PM² attraverso un progetto”
Non ogni idea merita di diventare un progetto. Prima di pianificare attività, assegnare persone o scegliere una soluzione, occorre chiarire due cose: che cosa viene chiesto e perché conviene investire.
In PM², il Project Initiation Request (PIR) registra e struttura la richiesta iniziale. Il Business Case valuta se il progetto è giustificato, confrontando valore atteso, opzioni, costi, rischi e impatti. Sono collegati, ma non sono lo stesso documento.
Due artefatti, due domande
| Artefatto | Domanda centrale | Risultato |
|---|---|---|
| Project Initiation Request (PIR) | Quale problema, opportunità o esigenza merita di essere esaminata? | Una richiesta iniziale descritta e sufficientemente chiara per avviare la valutazione. |
| Business Case | Vale la pena investire in questa iniziativa rispetto alle alternative? | Una giustificazione documentata per decidere se autorizzare il progetto e la pianificazione. |
Il PIR può partire da un utente, un dirigente, un audit, un obbligo normativo, un’opportunità o un problema operativo. Il Business Case trasforma quell’intuizione in una decisione informata.
Il Project Initiation Request: chiarire il punto di partenza
Il PIR non è un progetto in miniatura e non dovrebbe contenere un piano dettagliato. Serve a non iniziare una discussione dalla soluzione preferita.
Un PIR utile chiarisce almeno:
| Elemento | Esempio di domanda |
|---|---|
| Esigenza o opportunità | Quale problema esiste oggi e per chi? |
| Obiettivi iniziali | Che miglioramento si cerca? |
| Benefici attesi | Quale valore potrebbe produrre? |
| Urgenza e driver | C’è una scadenza normativa, un costo, un rischio o un’opportunità? |
| Scope iniziale e confini | Quale area si vuole esplorare, senza fingere che sia già definita? |
| Stakeholder e sponsor | Chi richiede, chi è impattato, chi può autorizzare? |
| Assunzioni e vincoli | Quali dati mancano, limiti tecnologici, budget indicativo o dipendenze esistono? |
Un PIR ben fatto non dice “sviluppiamo una nuova app”. Dice, per esempio: “le cancellazioni tardive lasciano posti vuoti nelle lezioni; vogliamo ridurre i no-show e rendere visibile la disponibilità”. La soluzione rimane una domanda aperta finché non si analizzano opzioni e fattibilità.
Il Business Case: giustificare la scelta
Il Business Case deve consentire alla governance di decidere se procedere, modificare l’idea, rinviare o non investire. Non è un documento che deve dimostrare a tutti i costi che l’idea iniziale è corretta.
Una struttura pratica comprende:
| Sezione | Cosa chiarisce |
|---|---|
| Contesto e problema | Situazione attuale, cause ed effetti del problema. |
| Obiettivi, outcome e benefici | Quale cambiamento si vuole ottenere e come misurarlo. |
| Opzioni | Almeno l’opzione “non fare nulla” o continuare con lo status quo, più alternative realistiche. |
| Valutazione comparativa | Valore, costi, effort, tempi, rischi, impatti e fattibilità delle opzioni. |
| Opzione raccomandata | La soluzione proposta e il perché della raccomandazione. |
| Stima iniziale | Ordine di grandezza di risorse, costi, calendario e dipendenze. |
| Rischi e assunzioni | Ciò che può invalidare o condizionare la scelta. |
| Governance richiesta | Decisione, sponsor, owner e condizioni per procedere. |
La precisione deve essere proporzionata allo stadio iniziale. Una stima preliminare non va presentata come un impegno definitivo; servirà a decidere se investire nella pianificazione che produrrà dati più affidabili.
Opzioni: il Business Case non è un confronto tra “fare” e “non fare” soltanto
L’opzione “do nothing” non significa necessariamente passività irresponsabile. Rende visibile il costo dello status quo: inefficienza, rischio, opportunità perdute, disservizi o non conformità.
| Opzione | Quando può essere utile valutarla |
|---|---|
| Non fare / mantenere lo status quo | Per capire il costo reale dell’inerzia. |
| Migliorare il processo senza nuova soluzione | Quando il problema è soprattutto organizzativo. |
| Acquistare o configurare una soluzione esistente | Quando velocità, standardizzazione o costo totale sono vantaggiosi. |
| Sviluppare o estendere una soluzione esistente | Quando serve integrazione o un adattamento distintivo. |
| Progetto pilota / proof of concept | Quando esistono incertezze rilevanti da ridurre prima di un investimento maggiore. |
Una buona raccomandazione esplicita anche ciò a cui si rinuncia: non esiste scelta senza trade-off.
Il caso Annotatio: Prenotazioni Smart
PIR
La richiesta iniziale può essere formulata così:
Nelle palestre che usano Annotatio, cancellazioni tardive e prenotazioni gestite via telefono o WhatsApp generano posti vuoti, lavoro manuale e dati incoerenti. Si chiede di valutare un modo per rendere prenotazioni e lista d’attesa più affidabili.
Il PIR indica bisogno, utenti impattati, valore potenziale e contesto. Non decide ancora se serva una nuova app, un modulo web, un processo diverso o un’integrazione esterna.
Business Case: opzioni semplificate
| Opzione | Valore | Costo / rischio | Valutazione |
|---|---|---|---|
| Continuare con WhatsApp e telefono | Nessun costo immediato. | No-show e lavoro manuale restano; nessuna tracciabilità affidabile. | Non raccomandata, ma utile come baseline. |
| Regole operative senza sviluppo | Può ridurre parte del disordine. | Adozione fragile; nessuna lista d’attesa automatica. | Possibile misura temporanea. |
| Estendere Annotatio con prenotazioni e lista d’attesa | Integra dati, ruoli e esperienza utente esistenti. | Effort di sviluppo, test, supporto e adozione. | Raccomandata se benefici e capacità lo giustificano. |
| Acquistare servizio esterno | Potenziale velocità iniziale. | Integrazione, dati, costi ricorrenti e dipendenza dal fornitore. | Da confrontare se il time-to-market è prioritario. |
La decisione non è “la funzione è utile?”. È “quale opzione produce il miglior rapporto tra benefici, costi, tempi, rischi e sostenibilità?”.
Dal Business Case alla decisione di gate
Il Business Case alimenta il gate RfP — Ready for Planning. L’approvazione non certifica che ogni dettaglio sia definito: autorizza a investire nella fase di Planning, con le condizioni eventualmente decise dalla governance.
| Esito possibile | Significato |
|---|---|
| Approvare | Passare alla pianificazione. |
| Approvare con condizioni | Pianificare, ma chiudere specifiche incertezze entro date e owner definiti. |
| Rinviare | Servono ulteriori dati, analisi o priorità più chiare. |
| Respingere / interrompere | L’investimento non è giustificato o non è prioritario. |
Un “no” o un rinvio possono essere ottimi esiti di governance: evitano di consumare risorse su un progetto non sufficientemente giustificato.
Da non confondere
| Affermazione | Correzione |
|---|---|
| “Il PIR decide la soluzione.” | Descrive la richiesta e il bisogno iniziale; le soluzioni vanno valutate. |
| “Il Business Case serve a far approvare un’idea già scelta.” | Deve permettere una scelta informata anche fra alternative e status quo. |
| “Se il beneficio è alto, il progetto va fatto.” | Vanno considerati anche fattibilità, costi, rischi, priorità e capacità disponibili. |
| “La stima iniziale è il budget definitivo.” | È una base preliminare, da affinare durante Planning. |
Tre domande per fissarlo
- Quale problema o opportunità descrive il PIR senza presupporre una soluzione?
- Quali opzioni reali confronta il Business Case, incluso lo status quo?
- Quali assunzioni potrebbero cambiare la raccomandazione?
Flashcard
D: A cosa serve il Project Initiation Request?
R: A registrare e chiarire una richiesta iniziale, il bisogno, il contesto, gli stakeholder e i benefici potenziali prima della valutazione dettagliata.
D: A cosa serve il Business Case?
R: A giustificare o meno l’investimento confrontando opzioni, benefici, costi, rischi, tempi e fattibilità.
D: Perché includere l’opzione “do nothing”?
R: Per rendere visibile il costo e il rischio dello status quo e confrontarlo con le alternative.
Domanda in stile esame
Uno sponsor richiede un nuovo portale e presenta un Business Case che descrive solo la soluzione proposta e i suoi vantaggi. Non include alternative, costo dello status quo o rischi di implementazione.
Qual è la lacuna principale?
Risposta: il documento non consente una decisione informata. Un Business Case deve confrontare opzioni realistiche — incluso il non fare o mantenere lo status quo — e valutarne benefici, costi, rischi, fattibilità e impatti prima di formulare una raccomandazione.
Fonte
Project Initiation Request, Business Case e gate RfP sono descritti nella PM² Methodology Guide 3.1 della Commissione europea.
Nel prossimo articolo: Project Charter, il documento che trasforma una buona idea approvata in un mandato di progetto chiaro.