Nel capitolo 13 abbiamo visto come organizzare le riunioni del team. Il corso identifica poi tre tipologie base di riunioni di progetto, con scopi e strutture diverse:
Le riunioni giornaliere servono per monitorare lo stato di avanzamento dei task del progetto:
Gli stati possibili che ogni responsabile può riportare sono quattro:
Quattro situazioni. Per ciascuna scegli lo stato che il responsabile del task riporta.
I problemi non devono essere risolti nelle riunioni giornaliere, ma in riunioni specifiche. In queste riunioni per la risoluzione di un problema:
Rispetto al problem solving di Couger (capitolo 13), la problem resolution meeting ne è la messa in opera: l'owner è il passo 1, la soluzione emerge dai passi 3–4, e «come e quando stabilire che è risolto» è la verifica finale — concordata in anticipo, non a posteriori.
Queste riunioni sono eventi formali, che si tengono in concomitanza con il raggiungimento di una milestone. Durante questi eventi:
La War Room è uno spazio dedicato alle riunioni necessarie durante il progetto. Il corso la introduce con tre aspetti da considerare:
L'idea è quella di uno spazio sempre pronto, dove il team può riunirsi senza preparativi: la sala «di guerra» del progetto. Il corso ne elenca gli aspetti (layout, soluzioni, uso operativo) senza dettagliarne un layout specifico — la scelta dipende dalle esigenze del progetto.
La gestione dei cambiamenti di scope è uno dei processi centrali del Launching. Il corso ne presenta il processo tipico, in cui una richiesta di cambiamento attraversa più revisioni prima di essere approvata:
Segui il percorso di una richiesta di cambiamento attraverso il processo del corso.
La richiesta di cambiamento viene formalizzata nella Scope Change Request Form, che il corso presenta come template con i seguenti campi:
| Campo del template | Contenuto |
|---|---|
| Project Name | Il nome del progetto a cui la richiesta si riferisce. |
| Change Requested By | Chi richiede il cambiamento. |
| Date Change Requested | La data della richiesta. |
| Description of Change | La descrizione del cambiamento richiesto. |
| Business Justification | La giustificazione di business della richiesta. |
| Action | La sezione in cui la richiesta viene valutata. |
| Approved By / Date | Chi approva e quando. |
La form è il documento che entra nel processo della sezione 6: la richiesta parte con i primi cinque campi compilati, e i campi Action e Approved By si completano durante le revisioni — fino all'approvazione per l'implementazione.
Il Project Impact Statement è un documento preparato dal project manager, con la collaborazione del team, per definire l'impatto del cambiamento di scope sul progetto. Deve rispondere alle seguenti domande:
Quattro situazioni. Per ciascuna scegli la domanda del Project Impact Statement a cui corrisponde.
La definizione dell'impatto del cambiamento può avere i seguenti esiti:
Quattro situazioni. Per ciascuna scegli l'esito più coerente tra quelli del corso.
Il cambiamento può essere dovuto a cambiamenti esterni (del mercato, delle tecnologie, etc.) oppure alla scoperta di nuovi bisogni/requisiti durante il progetto, che non erano emersi nella fase di scoping. Il corso indica la strada per accompagnare il cliente:
Il cliente non viene «respinto»: le richieste si mettono in conto, si analizzano, si trasformano in alternative e si scelgono insieme. È il processo della sezione 6 letto dal lato della relazione con il committente.
Bisogna gestire una «riserva»:
Daily status meetings (monitorare lo stato dei task), problem resolution meetings (risolvere i problemi), project review meetings (eventi formali in concomitanza con le milestone).
Durata breve (~15 minuti), anche senza sala riunioni; si parla solo dei task aperti; ogni responsabile riporta lo stato: «sono in schedula», «in ritardo di x ore ma rientro entro y giorni (1–2)», «in ritardo di x ore e ho bisogno di aiuto», «in anticipo di x ore e posso aiutare».
Partecipa solo chi è coinvolto; si determina l'owner del problema; si identifica la soluzione; si determina come e quando potremo stabilire che il problema è risolto.
Eventi formali in concomitanza con le milestone: presentazione e revisione critica dello stato; partecipano PM, senior management, committente, sponsor, stakeholders e tecnici esperti; si presentano le performance e si possono proporre azioni correttive.
Uno spazio dedicato alle riunioni necessarie durante il progetto, considerato sotto tre aspetti: layout fisico, soluzioni possibili, uso operativo.
Submit change request → review (reject → rework & resubmit, oppure avanti) → request impact study → review impact study (reject → rework & resubmit, oppure avanti) → change approved for implementation.
Project Name; Change Requested By; Date Change Requested; Description of Change; Business Justification; Action; Approved By / Date.
Beneficio atteso; impatto su costi, schedula, qualità e allocazione delle risorse; possibilità di rimandare il cambiamento a uno stadio successivo o a una prossima versione; rischio che il cambiamento destabilizzi la soluzione.
Applicabile entro risorse e tempi; applicabile con estensione della schedula; applicabile entro la schedula ma con risorse aggiuntive; applicabile con risorse aggiuntive ed estensione; applicabile con strategia «multiple release»; non applicabile senza modifiche sostanziali del progetto.
Mettendo sempre in conto le richieste; analizzando l'impatto sull'intero progetto; definendo nel project impact statement tutte le alternative; scegliendo l'alternativa assieme al committente; ristrutturando il piano e informando il committente.
La riserva è una percentuale della durata del progetto (tipicamente 5–10%) accantonata come tempo aggiuntivo per le richieste di cambiamento. La Scope Bank è un «deposito» di requisiti non ancora integrati nella soluzione, a cui si assegna una priorità.