Appunti Uni

07. Planning Process Group

14 minuti

Planning Process Group

Slide PDF: 7 - Planning Process Group - Ver.4.8

Indice

Importanza della Pianificazione

Definizione

La pianificazione e’ l’insieme delle attivita’ con cui il team definisce cosa fare, con quali risorse, in quali tempi e con quali costi prima di passare all’esecuzione del progetto.

In pratica: pianificare significa ridurre il numero di decisioni improvvisate durante il progetto. Secondo la pain curve descritta da Wysocki, una buona pianificazione genera un maggiore sforzo iniziale, ma riduce il dolore nelle fasi successive; una pianificazione povera lascia crescere i problemi nel tempo.

La pianificazione consente di:

  • ridurre l’incertezza, perche’ chiarisce vincoli, attivita’, dipendenze e rischi;
  • aumentare la comprensione, perche’ allinea project manager, team e committente;
  • migliorare l’efficienza, perche’ rende piu’ chiaro l’uso di tempo, budget e risorse.

Note

Nei modelli non tradizionali la pianificazione non e’ concentrata solo all’inizio: viene svolta iterativamente durante l’intera durata del progetto.

Tools Template e Processi

Definizione

Gli strumenti di pianificazione supportano la costruzione del piano di progetto, dalla definizione delle attivita’ alla schedulazione, fino al controllo di costi e risorse.

In pratica: oltre ai software di project management, le slide insistono su strumenti semplici ma efficaci nelle sessioni collaborative: sticky notes, pennarelli e lavagne.

Gli sticky notes possono contenere:

  • Task ID;
  • nome univoco dell’attivita’;
  • descrizione dell’attivita’;
  • responsabile;
  • risorse richieste;
  • effort;
  • durata;
  • valori calcolati: ES, EF, LS, LF;
  • indicazione del critical path.

I pennarelli servono soprattutto per definire le dipendenze e identificare il critical path. La lavagna puo’ contenere POS, WBS, diagramma delle dipendenze, schedula iniziale e finale, resource schedule, issues log e updated project schedule.

Esempio pratico

In una JPPS, ogni task puo’ essere scritto su un post-it e poi spostato sulla lavagna per costruire il diagramma delle dipendenze in modo visibile a tutti.

Secondo le stime riportate da Wysocki, la pianificazione puo’ richiedere meno di mezza giornata per progetti molto piccoli, meno di un giorno per progetti piccoli, circa due giorni per progetti medi e tre-quattro giorni per progetti grandi. La conclusione rimane pero’: it all depends.

Joint Project Planning Session JPPS

Definizione

Le Joint Project Planning Sessions (JPPS) sono sessioni di lavoro in cui il personale coinvolto nel progetto definisce le attivita’ necessarie a soddisfare i requisiti del committente entro vincoli di tempo, budget e risorse.

In pratica: la JPPS e’ il momento in cui project manager, team e committente costruiscono una visione condivisa del piano. Non e’ solo una riunione informativa: produce deliverable concreti per autorizzare e guidare l’esecuzione.

I componenti principali della JPPS sono:

  • attendees;
  • facilities;
  • equipment;
  • agenda;
  • deliverables;
  • project proposal.

Partecipanti alla JPPS

Note

Il valore della JPPS dipende dalla presenza delle persone giuste: chi conosce i requisiti, chi dovra’ realizzare il progetto e chi puo’ assegnare o confermare le risorse.

Ruoli indicati nelle slide:

  • Facilitator: mediatore imparziale che aiuta a condurre la sessione.
  • Project manager: responsabile della fattibilita’ del piano e del completamento del progetto.
  • Another project manager: puo’ rappresentare il committente o svolgere un ruolo imparziale se manca il facilitatore.
  • JPP consultant: utile quando project manager o organizzazione non hanno sufficiente esperienza con la metodologia adottata.
  • Technographer: registra digitalmente decisioni e piano usando competenze di project management e strumenti software.
  • Core project team: contribuisce soprattutto alle stime di durata e risorse.
  • Client representative: valida requisiti, POS, WBS e aiuta la negoziazione dei cambiamenti.
  • Resource managers: hanno visione della disponibilita’ effettiva delle risorse nell’organizzazione.
  • Functional managers e process owner: garantiscono coerenza con aree funzionali e processi aziendali.
  • Project champion: sostiene e promuove il progetto verso il senior management; non va confuso con il project sponsor.

Agenda e Deliverable

Una possibile agenda della prima sessione include:

  • Planning kick-off: introduzione dello sponsor, panoramica sul progetto, presentazione dei co-project manager, del core project team e del planning facilitation team.
  • Working session: validazione e prioritizzazione dei requisiti, generazione della WBS, stime di effort, durata e risorse, diagramma delle dipendenze, critical path, compressione della schedula se necessaria, rischi e consenso sul piano.

I deliverable della JPPS possono includere:

  • Project Definition Statement (PDS);
  • Work Breakdown Structure (WBS);
  • risorse necessarie;
  • assegnamento delle risorse;
  • stima della durata delle attivita’;
  • project network schedule;
  • schedulazione delle attivita’;
  • project notebook;
  • project proposal.

Project Definition Statement PDS

Definizione

Il Project Definition Statement (PDS) e’ una versione estesa del POS vista dalla prospettiva del planning team.

Il PDS contiene le stesse cinque sezioni del POS:

  • problem/opportunity;
  • project goal;
  • project objectives;
  • success criteria;
  • assumptions/risks/obstacles.

In pratica: il PDS serve ad assicurare che il team abbia una visione comune del progetto e di cio’ che deve essere realizzato. Puo’ essere composto da diverse pagine.

Ruolo del committente

Il committente dovrebbe partecipare in modo significativo: valida requisiti e POS, prioritizza i requisiti, contribuisce alla WBS, impegna risorse e deve sentire il piano come proprio.

La prioritizzazione puo’ seguire l’approccio MoSCoW:

  • Must: requisiti indispensabili per considerare il progetto concluso con successo.
  • Should: requisiti che dovrebbero essere inclusi se possibile.
  • Could: requisiti possibili ma non necessari, considerati se tempo e risorse lo permettono.
  • Would/Won’t: requisiti rinviati a una futura release con consenso degli stakeholder.

Work Breakdown Structure WBS

Definizione

La Work Breakdown Structure (WBS) e’ una descrizione gerarchica di tutto il lavoro che deve essere svolto nel progetto per soddisfare i bisogni del committente.

In pratica: la WBS traduce i requisiti in lavoro da eseguire. Se viene derivata direttamente dalla RBS, mantiene un collegamento piu’ forte con i criteri di successo del progetto.

La WBS ha quattro impieghi fondamentali:

  • thought process tool, per visualizzare mentalmente il lavoro da definire e gestire;
  • architectural design tool, per rappresentare le relazioni tra attivita’;
  • planning tool, per stimare effort, durata e risorse al livello di massimo dettaglio;
  • project status reporting tool, per monitorare il completamento risalendo dai task di basso livello alle attivita’ superiori.

Punto essenziale

La WBS deve rimanere coerente con POS e RBS. Se emergono incongruenze di scope o soluzione durante la pianificazione, vanno affrontate subito: modificarle ora costa meno che farlo in seguito.

Generazione della WBS

Uno degli approcci piu’ efficaci consiste nel convertire la RBS in WBS:

  • si parte dagli elementi di livello piu’ basso della RBS;
  • ogni elemento viene decomposto nelle attivita’ necessarie per implementare il requisito;
  • la decomposizione si ferma quando il livello e’ adeguato per stimare tempo, costi e risorse;
  • non bisogna eccedere nel dettaglio, perche’ il lavoro di gestione diventerebbe eccessivo.

Quando la WBS e’ completa, le slide distinguono tra:

  • activity: attivita’ generica nella decomposizione;
  • task: attivita’ di massimo dettaglio per cui stimare tempi, costi e risorse.

Approcci organizzativi per costruirla:

  • Team Approach: tutto il team lavora insieme sull’intera WBS.
  • Subteam Approach: il team si divide in gruppi, poi integra i contributi in una WBS complessiva.

Criteri di Completezza

I sei criteri per stabilire quando una WBS e’ completa sono:

  • stato e completamento misurabili, ad esempio tramite definizione del done;
  • attivita’ ben delimitate, con inizio e fine chiari;
  • attivita’ associate a un deliverable;
  • tempi e costi facilmente stimabili;
  • durata entro un limite accettabile;
  • task considerabili come attivita’ senza interruzioni e indipendenti da altri task.

Il settimo criterio riguarda il giudizio del project manager:

  • il cliente non ha partecipato quanto atteso;
  • il project manager non e’ convinto che sia tutto chiaro;
  • il project manager ritiene probabili modifiche anche rilevanti dello scope.

WBS instabile

In alcuni casi la WBS puo’ essere ancora instabile e incompleta, ma non si puo’ ottenere di meglio al momento. In queste situazioni occorre scegliere modelli PMLC adatti a gestire cambiamenti e incertezza.

Sono possibili eccezioni ai criteri, ad esempio in progetti brevi, attivita’ difficilmente stimabili, attivita’ ad alto rischio o con alta varianza della durata. L’importante e’ essere consapevoli dei criteri non soddisfatti e accettarne i rischi.

Approcci e Template

Approcci per costruire la WBS:

  • noun-type approaches: componenti fisici o funzionali;
  • verb-type approaches: design-build-test-implement oppure obiettivi;
  • organizational approaches: geografico, dipartimentale o per processo di business.

I template aiutano a risparmiare tempo, standardizzare pianificazione e gestione, riutilizzare esperienze passate, raccogliere dati su durate e costi stimati e misurati, e migliorare la qualita’ dei processi.

Progetti ricorrenti

I template sono particolarmente efficaci per distribuire nuove release software, installare reti in uffici, aggiornare applicazioni con nuove funzionalita’ o creare materiale di training.

Stima di Durata Effort e Risorse

Durata ed Effort

Definizione

La durata misura il tempo di calendario necessario a completare un task, mentre l’effort misura la quantita’ di lavoro richiesta.

In pratica: la durata serve per costruire la schedula e capire quando milestone e progetto saranno completati; l’effort serve per valutare costi e assegnare risorse.

Relazione non lineare

La durata di un task dipende da effort e risorse assegnate, ma la relazione non e’ lineare. Aggiungere persone non riduce automaticamente il tempo in modo proporzionale.

Cause che possono influire sulla durata:

  • diversi livelli di esperienza e competenza;
  • eventi inattesi;
  • uso non efficiente del tempo di lavoro;
  • errori e fraintendimenti;
  • variabilita’ naturale dei processi.

Tecniche di Stima

Metodi citati per stimare la durata di un task:

  • estrapolazioni basate su attivita’ simili;
  • analisi di dati storici;
  • giudizio di un esperto;
  • tecniche consensus-based.

Tra le tecniche consensus-based:

  • Delphi technique: esperti stimano in piu’ round; un facilitatore sintetizza stime e motivazioni; il gap tra stime dovrebbe ridursi fino a un valore condiviso.
  • Three-point technique: usa stima ottimistica, piu’ probabile e pessimistica.
  • Wide-band Delphi technique.

Formula della three-point technique:

E = (O + 4M + P) / 6

Dove:

  • O = optimistic;
  • M = most likely;
  • P = pessimistic;
  • E = expected estimate.

Negli approcci agili, come Scrum, sono usate tecniche come il planning poker. Scrum stima la complessita’ di sviluppo delle user story tramite story point, non direttamente il lavoro in giorni/uomo. Gli story point possono essere numerici, ad esempio Fibonacci, o non numerici, come le taglie T-shirt.

Note

Le stime hanno un ciclo di vita: secondo la frase riportata nelle slide, “You will be smarter tomorrow than you are today”. Con il tempo il range di incertezza dovrebbe ridursi.

Risorse Necessarie

Definizione

Le risorse sono gli elementi necessari all’esecuzione dei task e influenzano durata, costo e rischi.

Le risorse citate sono:

  • people;
  • facilities;
  • equipment;
  • money;
  • materials.

Per assegnare membri dello staff alle attivita’ bisogna considerare rischio, business value, criticita’ e skill necessari. Un approccio efficace e’ combinare:

  • matrice skill-need per le attivita’;
  • matrice skill-inventory per i membri dello staff.

Le slide mostrano anche strutture organizzative diverse che incidono sull’allocazione: functional organization, project organization e matrix organization.

Stima e Gestione dei Costi

Definizione

La stima dei costi serve a prevedere le risorse economiche necessarie al progetto e a controllarle durante l’esecuzione.

Tipologie di stima citate:

  • order of magnitude estimate;
  • budget estimate;
  • definitive estimate.

Per gestire i costi occorre:

  • assegnare i costi ai task nella WBS tramite cost budgeting;
  • monitorare i costi reali tramite cost control;
  • usare weekly reports;
  • confrontare baseline e actual costs.

Cash Flow Management

Definizione

Il cash flow del progetto puo’ essere visto come la differenza tra entrate e uscite di denaro nel tempo, lungo l’orizzonte temporale del progetto.

In pratica: non basta sapere se il progetto genera utile alla fine. Bisogna verificare se, in ogni momento, l’azienda ha liquidita’ sufficiente per pagare stipendi, servizi, costi generali e altri esborsi.

Durante la pianificazione bisogna definire:

  • importi e date degli incassi;
  • importi e date dei pagamenti;
  • eventuali modifiche alla schedula per correggere il cash flow;
  • condizioni contrattuali per ottenere gli incassi.

Condizioni di incasso possibili:

  • anticipo alla firma del contratto;
  • rilascio all’accettazione di una parte del deliverable;
  • milestone al raggiungimento di un obiettivo intermedio;
  • saldo a chiusura del progetto.

Rischio di liquidita'

Ritardare un pagamento viola un contratto, anche se talvolta e’ tollerato. Richiedere finanziamenti ha un costo e non sempre e’ possibile.

Pianificazione e Contratto

La pianificazione deve tenere conto del tipo di contratto con il committente:

  • fixed-price: il committente paga un prezzo predeterminato al termine del progetto o degli incrementi/rilasci previsti, indipendentemente dai costi reali;
  • time and materials: il committente paga in base al lavoro effettivamente svolto, al termine o periodicamente.

Contratto a corpo

Nei progetti fixed-price il fornitore rischia che il costo sia sottostimato e che prezzo o budget non coprano i costi effettivi. Per questo la pianificazione e’ fondamentale.

Se l’approccio e’ iterativo e i costi non sono stimabili in modo attendibile, le slide indicano che l’azienda dovrebbe scegliere un contratto time and materials. Se non e’ possibile, il rischio per chi sviluppa cresce con la scarsa attendibilita’ delle stime.

Project Network Diagram

Definizione

Il Project Network Diagram rappresenta le dipendenze tra task e permette di derivare la schedula del progetto, da cui si costruisce il Gantt Chart.

Le slide presentano due formati:

  • task on the arrow;
  • task on the node.

Nel task node compaiono:

  • ID: Task ID;
  • E: durata attesa;
  • ES: earliest start;
  • EF: earliest finish;
  • LS: latest start;
  • LF: latest finish;
  • Slack: ritardo massimo che non causa un ritardo nel completamento del progetto.

Dipendenze e Vincoli

Tipi di dipendenza:

  • Finish-to-Start (FS): B puo’ partire solo quando A e’ terminata; e’ la dipendenza classica e consigliata in una prima pianificazione.
  • Finish-to-Finish (FF): B non puo’ finire prima che A sia finita.
  • Start-to-Start (SS): B non puo’ iniziare prima che A sia iniziata.
  • Start-to-Finish (SF): B non puo’ finire prima che A sia partita.

Le dipendenze possono includere un lag, cioe’ un ritardo prestabilito, ad esempio una relazione SS con ritardo.

Vincoli citati:

  • technical constraints;
  • discretionary constraints;
  • logical constraints;
  • best practice constraints;
  • unique requirements constraints;
  • management constraints;
  • inter-project constraints;
  • date constraints;
  • lag variables.

Passi per costruire un initial dependency diagram:

  • scrivere per ogni task ID, nome e durata sul post-it;
  • posizionare i post-it a destra della lavagna;
  • mettere lo start node a sinistra;
  • spostare a sinistra i task senza predecessori e collegarli allo start node;
  • spostare a sinistra i task i cui predecessori sono gia’ a sinistra;
  • ripetere finche’ tutti i task sono stati spostati.

Forward Pass Backward Pass e Critical Path

Definizione

Il critical path identifica i task che determinano la durata del progetto: ogni loro ritardo si ripercuote immediatamente sulla durata complessiva.

Il forward pass procede da sinistra a destra e determina early start ed early finish:

ES + duration - 1 = EF

Il backward pass procede da destra a sinistra e determina latest start e latest finish:

LF - duration + 1 = LS

Lo slack o float e’ il ritardo massimo che un task puo’ subire senza impattare sull’inizio del task successivo e/o sulla durata dell’intero progetto.

Tipi di slack:

  • total slack / total float: ritardo che non impatta sull’early schedule del progetto;
  • free slack / free float: ritardo che non impatta sull’early schedule del task successivo.

Warning

Le slide riportano esplicitamente: “Do Not Plan to Use Slack to Bail Out the Project!“. Lo slack non va pianificato come scusa per salvare il progetto.

Compressione della Schedula e Management Reserve

Tecniche di schedule compression citate:

  • sostituire dipendenze FS con SS;
  • sostituire un membro del team con uno piu’ esperto;
  • aggiungere risorse spostandole da task non nel critical path a task nel critical path;
  • spostare risorse da altri progetti verso task critici, ad alto rischio o con alta varianza della durata.

Compressione non gratuita

Comprimere la schedula non riduce l’effort. Modificare precedenze puo’ aumentare lavoro, costi, rischi e complessita’.

La management reserve serve a prevenire ritardi:

  • non bisogna gonfiare la durata dei singoli task;
  • si puo’ prevedere una riserva pari a una percentuale della durata complessiva, ad esempio 5-10%;
  • la riserva puo’ essere rappresentata da un task dummy finale;
  • quando un ritardo impatta sulla durata del progetto, si sottrae quel ritardo alla riserva;
  • riserva e uso della riserva devono essere visibili e gestiti correttamente.

Proposta e Approvazione

Definizione

La project proposal raccoglie gli elementi necessari a presentare il progetto e richiedere l’approvazione per procedere alla fase di esecuzione.

Contenuto della proposta di progetto:

  • executive summary;
  • background;
  • objective;
  • overview of the approach to be taken;
  • detailed statement of work;
  • time and cost summary;
  • appendices.

L’approvazione della pianificazione e il passaggio alla fase di esecuzione possono essere negati se:

  • costi/benefici non sono ritenuti sufficienti;
  • rischi di fallimento troppo alti;
  • costi totali previsti superiori ai fondi disponibili;
  • altri progetti competono per le stesse risorse.

Tip

Una pianificazione solida riduce la probabilita’ di questi blocchi perche’ rende piu’ espliciti benefici, rischi, costi, risorse e vincoli prima dell’esecuzione.

Prossimi Argomenti

Continueremo con:

Note

Non viene collegato un modulo 08 perche’ tra i PDF disponibili non risulta presente.

Vista grafico

Link entranti