Il capitolo 8 apre il cuore operativo del corso: il Planning Process Group. Il primo concetto che Wysocki mette sul tavolo è la cosiddetta pain curve — letteralmente «la curva del dolore».
La curva non dice «pianificate per non soffrire»: dice quando soffrire. La pianificazione sposta il dolore all'inizio del progetto, dove le modifiche costano poco e si possono ancora correggere le decisioni.
Il corso riassume i benefici della pianificazione in tre voci, tutte in forma di verbo:
| Beneficio | Che cosa significa in pratica |
|---|---|
| Riduce l'incertezza (Reduces Uncertainty) | Le domande sulle attività, le dipendenze e le risorse vengono poste e risolte prima che diventino emergenze durante l'esecuzione. |
| Aumenta la comprensione (Increases Understanding) | Il piano costringe tutti — committente, team e management — a guardare lo stesso progetto nello stesso modo. È la stessa logica già vista con i diagrammi nel capitolo 7: disegnare rende visibile ciò che a parole resta implicito. |
| Migliora l'efficienza (Improves Efficiency) | Le risorse vengono allocate prima, le dipendenze vengono dichiarate e le attività possono essere organizzate per ridurre attese e sprechi. |
Collegate le tre voci alla pain curve: la comprensione e la riduzione dell'incertezza sono il meccanismo che tiene bassa la curva del dolore; l'efficienza è il vantaggio che si misura a fine progetto.
Sul mercato esistono numerosi software di supporto alla pianificazione, anche in forma di soluzioni cloud. Alcuni risolvono solo alcuni aspetti, altri cercano di coprire l'intero insieme dei processi di un progetto di sviluppo software. Ma il corso ricorda che gli strumenti di pianificazione per eccellenza restano molto più umili — e molto più potenti di quanto sembri:
Sticky notes (memo in colori assortiti); marking pens (pennarelli in colori assortiti); plenty of whiteboard space (molta lavagna a disposizione).
Sullo sticky note, ES, EF, LS, LF e Critical Path sono valori calcolati, non dati iniziali: si scrivono quando il diagramma delle dipendenze è stato costruito, non prima. Chi li scrive a caso sta falsificando il piano.
Wysocki fornisce alcune stime dei tempi di pianificazione, «una buona guida per comprendere l'ordine di grandezza»:
| Dimensione del progetto | Tempo di pianificazione |
|---|---|
| Molto piccoli | < ½ giornata |
| Piccoli | < 1 giorno |
| Medi | 2 giorni |
| Grandi | 3–4 giorni |
| Molto grandi | ??? |
La conclusione di Wysocki è spiazzante e onesta insieme: «it all depends!» — dipende. E c'è una seconda osservazione: per i modelli di gestione non tradizionali la pianificazione è svolta iterativamente durante l'intera durata del progetto (over the time), non in un'unica sessione iniziale.
Scegli la dimensione del progetto: il widget riporta l'ordine di grandezza suggerito da Wysocki.
Il «???» dei progetti molto grandi è voluto: oltre una certa dimensione la pianificazione non è più una sessione, è un sottoprogetto. E nei modelli iterativi e adattivi non si può rispondere affatto in anticipo — si pianifica per piccoli incrementi, lungo tutto il progetto.
Tutte le attività di pianificazione vengono svolte durante sessioni di lavoro denominate Joint Project Planning Sessions (JPPS). Durante le JPPS il personale coinvolto nel progetto definisce le attività che devono essere svolte per soddisfare i requisiti espressi dal committente — requisiti che dovrebbero soddisfare i suoi bisogni — entro i vincoli di tempo, budget e risorse disponibili.
La JPPS è il luogo in cui requisiti, vincoli e risorse vengono tradotti in un piano. È «joint» perché ci sono insieme committente e fornitore, «planning» perché produce il piano, «session» perché è un evento di lavoro con una sua agenda e dei suoi deliverable.
Gli attendees della JPPS sono molti, e ognuno ha un motivo preciso per essere lì:
| Attendee | Ruolo e responsabilità |
|---|---|
| Facilitator | Esperto nella conduzione della JPPS; teoricamente un mediatore imparziale tra chi gestirà e svilupperà il progetto e il committente. Senza un facilitatore esperto la sessione difficilmente riesce. |
| Project manager | Responsabile del completamento con successo del progetto; si concentra sulla fattibilità del piano e negozia un piano che fornisca il business value atteso rispettando tempo, budget e risorse. |
| Another project manager | Può rappresentare il committente per verificare il lavoro del project manager; se manca un facilitatore, è opportuno che un secondo project manager imparziale non sia lo stesso del primo. |
| JPP consultant | Necessario quando il project manager e l'organizzazione non hanno ancora esperienza sufficiente con la metodologia che si intende impiegare. |
| Technographer | Professionista con ottime competenze di project management e di software di supporto: si occupa della rendicontazione digitale delle decisioni assunte in pianificazione, dando una buona visione del piano via via che prende forma. |
| Core project team | La partecipazione è fondamentale: chi eseguirà il progetto è il contributo migliore per stimare durate e prevedere le risorse. |
| Client representative | Non sempre il cliente è disposto a «investire» risorse nella pianificazione, ma la sua partecipazione è fortemente consigliata: quando arriveranno i cambiamenti (solitamente attesi), sarà più facile negoziare le modifiche a quanto pianificato. |
| Resource managers | Determinanti per la corretta allocazione delle risorse: hanno visione completa di tutti i progetti attivi e della effettiva disponibilità nel tempo delle risorse dell'organizzazione. |
| Functional managers | Responsabili di aree che forniscono input o ricevono output dai deliverable: garantiscono la corretta integrazione della soluzione nei processi aziendali. |
| Process owner | «Detiene» i processi da supportare con la soluzione: vale quanto detto per i functional manager, in termini di integrazione. |
| Project champion | «A person who fights or argues for a cause or on behalf of someone else»: una persona carismatica, con ottime competenze tecniche e/o organizzative, che «vende» il progetto al senior management. Non va confuso con il project sponsor, che ha un coinvolgimento formale. |
Champion ≠ Sponsor: il champion «vende» il progetto (coinvolgimento informale, carismatico); lo sponsor ha un coinvolgimento formale e l'autorità. E facilitator ≠ project manager: il facilitatore è un mediatore imparziale, idealmente non coinvolto nella gestione del progetto.
Abbina ogni attendee al suo compito. Usa i menu a tendina; il widget valuta le risposte.
Facility ed equipment sono indispensabili per le JPPS, e alcuni aspetti sono «spesso trascurati»:
| Componente | Che cosa valutare |
|---|---|
| Facility (sale riunioni) | Comode, confortevoli; lontane dalle occasioni di interruzione (offsite oppure onsite); considerare l'uso di breakout rooms per i lavori di gruppo. |
| Equipment | Breakout group work areas (tavoli, sedie, flip charts); lavagne (whiteboards); proiettori. |
Il corso insiste sulle interruzioni: una JPPS interrotta perde il filo del lavoro comune, e il «filo» è proprio il valore della sessione. La lontananza dalle interruzioni è un requisito, non un lusso.
Lo schema di agenda tipo per le JPPS prevede una Sessione #1 composta da due parti: il Kick-off e la Working session. Chi è coinvolto in ogni fase? «Sessione #1: Project Manager, Project Team (anche al completo), Client (raccomandato)».
La parte di avvio serve a mettere in comune il contesto, non a pianificare:
La parte di lavoro produce il piano, nell'ordine:
Guardate l'ordine della working session: requisiti prima, WBS poi, stime dopo, dipendenze e critical path infine. È lo stesso ordine dei prossimi capitoli (9, 10 e 11): la JPPS non è un evento, è il protocollo del Planning Process Group.
I deliverables della JPPS potrebbero essere i seguenti:
Il PDS è una versione «estesa» del POS, vista però dalla prospettiva del planning team. Contiene le stesse 5 sezioni del POS (Problem/opportunity, Project goal, Project objectives, Success criteria, Assumptions/Risks/Obstacles), ma con una definizione del progetto più dettagliata, destinata al team, e può essere composto da diverse pagine. Si usa per assicurarsi che il team abbia una visione comune sul progetto e su cosa consiste.
Nel capitolo 7 il PDS era apparso come il «cassetto» degli elementi troppo dettagliati per il POS. Qui si completa il quadro: il PDS non è solo il contenitore degli scarti — è il documento di lavoro del team, costruito e validato nella JPPS. POS e PDS condividono la struttura; cambiano destinatario e livello di dettaglio.
Tra i deliverable figura anche la proposta di progetto, che il corso enumera con una struttura precisa (la ritroveremo nel capitolo 11):
| Sezione | Contenuto |
|---|---|
| Background | Il contesto da cui nasce il progetto. |
| Objective | L'obiettivo della proposta. |
| Overview of approach to be taken | L'approccio che si intende seguire. |
| Detailed statement of work | Il lavoro nel dettaglio. |
| Time and cost summary | Il riepilogo di tempi e costi. |
| Appendices | Gli allegati. |
Il committente ha un suo rappresentante che deve essere presente alla JPPS, e il suo ruolo è tutto fuorché decorativo:
«Il coinvolgimento del committente deve essere significativo.» Un piano costruito senza il committente è un piano che il committente non riconosce come suo — e al primo cambiamento lo contesterà, proprio nel momento in cui la negoziazione sarebbe più costosa.
L'approccio MoSCoW è un metodo di prioritizzazione/classificazione dei requisiti:
| Classe | Significato |
|---|---|
| Must | Requisiti che devono essere soddisfatti nella soluzione finale per considerare il progetto concluso con successo. |
| Should | Requisiti che dovrebbero essere inclusi nella soluzione se possibile. Di solito sono requisiti critici che, in caso di necessità, possono essere sostituiti con requisiti alternativi. |
| Could | Requisiti che potrebbero essere inclusi ma non sono necessari: si considerano solo se tempo e risorse lo permettono. |
| Would (Won't) | Requisiti che sarebbero da includere, ma gli stakeholder hanno acconsentito a rinviare l'implementazione a una futura release. Per sottolineare questa scelta, a volte «Would» è sostituito da «Won't». |
Should e Could si assomigliano ma non sono la stessa cosa: i Should sono critici (sostituibili solo con alternative), i Could non sono necessari (si fanno se avanza tempo). E il Won't è una decisione consapevole e condivisa di rinvio, non un dimenticatoio.
Sei requisiti per il caso PDQ (capitolo 4). Assegna ciascuno alla classe giusta; poi verifica.
La curva del dolore lungo la vita del progetto: con una buona pianificazione il dolore è concentrato all'inizio e poi resta basso; con una pianificazione scadente il dolore sale presto e resta alto. Sul grafico originale è segnata la fascia 18–36%, l'ordine di grandezza che Wysocki associa alla quota del progetto dedicata alla pianificazione.
Riduce l'incertezza (le domande vengono poste e risolte prima), aumenta la comprensione (tutti guardano lo stesso progetto nello stesso modo) e migliora l'efficienza (risorse e dipendenze organizzate in anticipo).
Sticky notes (un memo per attività: ID, nome, descrizione, responsabile, risorse, effort, durata; poi i valori calcolati ES, EF, LS, LF e il critical path); marking pens (relazioni di dipendenza e critical path); lavagna (i documenti vivi: POS, WBS, diagramma delle dipendenze, initial/final schedule, resource schedule, issues log, updated schedule).
Molto piccoli < ½ giornata; piccoli < 1 giorno; medi 2 giorni; grandi 3–4 giorni; molto grandi «???». La conclusione è «it all depends!». Inoltre, per i modelli non tradizionali la pianificazione è svolta iterativamente durante l'intera durata del progetto, non in un'unica sessione.
La Joint Project Planning Session è la sessione di lavoro in cui il personale coinvolto definisce le attività per soddisfare i requisiti del committente entro i vincoli di tempo, budget e risorse. I sei components: Attendees, Facilities, Equipment, Agenda, Deliverables, Project Proposal.
Il champion è «a person who fights or argues for a cause or on behalf of someone else»: una persona carismatica con ottime competenze tecniche e/o organizzative che «vende» il progetto al senior management. Lo sponsor ha un coinvolgimento formale nel progetto. Il champion non va confuso con lo sponsor.
È un professionista con ottime competenze di project management e di software di supporto che si occupa della rendicontazione digitale delle decisioni assunte in pianificazione. Il software ad hoc consente di avere una buona visione del piano via via che viene elaborato.
Una Sessione #1 in due parti: Kick-off (introduzione di sponsor, co-project manager del committente e dell'IT, core team, planning facilitation team) e Working session (validazione e prioritizzazione dei requisiti, panoramica sull'approccio, generazione e validazione della WBS, stime, diagramma delle dipendenze, critical path e date, compressione se necessaria, rischi e mitigazioni, consenso di tutti, aggiornamento).
Il Project Definition Statement è una versione «estesa» del POS vista dalla prospettiva del planning team: stesse 5 sezioni, ma più dettagliate e destinate al team, possibilmente su più pagine. Serve ad assicurare che il team abbia una visione comune del progetto. Nel capitolo 7 era il contenitore dei dettagli esclusi dal POS; qui è un deliverable della JPPS.
Il suo rappresentante deve essere presente; valida requisiti e POS; prioritizza i requisiti (es. MoSCoW); genera e valida la WBS; impegna risorse; si accorda sulla pianificazione; deve avere «possesso» del piano. Il coinvolgimento deve essere significativo.
Must: necessari al successo. Should: critici ma sostituibili con alternative se necessario. Could: non necessari, si fanno se tempo e risorse lo permettono. Would/Won't: rinviati consapevolmente a una futura release dagli stakeholder.
Project Definition Statement (PDS), Work Breakdown Structure (WBS), risorse necessarie e assegnamento, stima della durata delle attività, project network schedule e schedulazione, Project Notebook e project proposal.