# NUPP Principi Quasi Universali dei Progetti [image] Questa è una versione scaricabile del manuale online (https://omimo.org/it/modules/nupp/), generata il 2026‑07‑02. Consulta il sito web per eventuali versioni più recenti. NUPP nasce da OMIMO (https://omimo.org/it/), una famiglia di moduli aperti e minimalisti. Questo manuale può essere utilizzato e distribuito liberamente secondo i termini della licenza Creative Commons Attribution 4.0 International. OMIMO è cofinanziato dall'Unione europea. Le opinioni e i punti di vista espressi sono tuttavia esclusivamente quelli di OMIMO e non riflettono necessariamente quelli dell'Unione europea o di EPOS VZW. Né l'Unione europea né l'autorità che concede il finanziamento possono essere ritenute responsabili per essi. Tradotto da: Cristiano Ottavian, Marco Caressa ## Introduzione NUPP (Nearly Universal Principles of Projects) è un insieme di principi generali da seguire in tutti i progetti, indipendentemente dalle metodologie e dagli approcci utilizzati per massimizzarne il successo. Qualsiasi metodo o risorsa usata per l’esecuzione di progetti presta attenzione a qualcuno di questi principi NUP (Nearly Universal Principles), tuttavia: - di solito non tutti, mentre sarebbe utile per i professionisti considerare tutti i NUP al posto di un loro sottoinsieme, inoltre - i principi di base spesso non sono abbastanza dettagliati riguardo le risorse, così la maggior parte dei professionisti si impegnano in dettagli pratici e tralasciano tali principi. NUPP è compatibile con tutti i principali metodi, sistemi, risorse e framework, come PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP e Scrum. Siccome potrebbe essere considerato non compatibile con alcune interpretazioni di questi sistemi, NUPP cerca di incoraggiare i professionisti a riconsiderarle. Di seguito l’elenco dei NUP: - NUP1 — Preferisci i risultati e la verità rispetto agli schieramenti - NUP2 — Preserva e ottimizza energia e risorse - NUP3 — Sii sempre proattivo - NUP4 — Ricorda che una catena è forte quanto il suo anello più debole - NUP5 — Non fare nulla senza uno scopo chiaro - NUP6 — Utilizzare elementi ripetibili ## NUP1 Preferisci i risultati e la verità rispetto agli schieramenti [image] Abbiamo tutti una naturale tendenza ad appartenere a dei gruppi che spesso va oltre la sua forma generale, creando forti schieramenti e causando problemi. Così perdiamo molto più di quello che guadagniamo. Possiamo diventare esperti più professionali ed efficaci se non limitiamo la nostra identità e le nostre preferenze in funzione solo dell’appartenenza a determinati gruppi. ### Esempio: Agile vs. waterfall Quando nei progetti di sviluppo software la regola era di usare approcci “predittivi”, un gruppo di persone molto determinate ha avuto il coraggio di provare approcci di sviluppo “adattivi”, si è riunito e ha definito questa modalità “Agile”. E’ stata una grande iniziativa per non limitare le scelte a ciò che sembrava scontato. Tuttavia, così come ci sono molte persone entusiaste e concrete, sfortunatamente nella comunità Agile ci sono anche alcune persone che trasformano Agile in una setta e considerano gli estranei come nemici. Questo causa diversi problemi: - Non consente loro di imparare da qualcuno al di fuori del “gruppo” - Scoraggia gli estranei al gruppo ad apprendere da loro. - Rende l’appartenenza al gruppo più importante del vero scopo, cosa che a sua volta impedisce a molti dei loro membri di imparare il vero significato di Agilità. Questo problema può essere ridotto in modo significativo, se non addirittura rimosso, considerando Agile solo come un approccio di sviluppo, piuttosto che una comunità con persone che si considerano creatori, risolutori di problemi e leader. Per tutti costoro Agile dovrebbe essere solo un fattore abilitante, non la loro identità. Non c’è una guerra tra Agile e Waterfall per un vero professionista. ### Esempio: PRINCE2^(®) vs. PMBOK^(®) Guide Nella comunità di professionisti molti hanno come riferimento il PRINCE2^(®) o la Guida PMBOK^(®), di solito per motivi di collocazione geografica o scelta aziendale. Ne conoscono uno, senza conoscere l’altro. Possiamo certamente avere delle preferenze nei riguardi di specifici riferimenti, ma non come elemento distintivo della nostra identità e, ancor più, dovremmo familiarizzare con entrambi per ampliare le nostre prospettive e le nostre scelte. Un vero professionista è aperto a tutte le idee, cercando di conoscerle, apprenderle e utilizzarle in base al bisogno che se ne delinea, senza schierarsi esclusivamente con nessuna di esse. ### Esempio: apprendimento continuo Lo schieramento soddisfa le persone attraverso il senso di appartenenza, non stimola l’apprendimento di cose nuove e lo scoraggia per paura di perdere i propri punti di riferimento. Se sei una persona libera, un esperto che non si annulla in un’idea specifica, hai bisogno di colmare lacune, attraverso l’apprendimento. Un apprendimento continuo. Ciò in cui crediamo oggi non è la verità assoluta. E’ solo la migliore comprensione che abbiamo maturato sino ad ora, che deve essere migliorata man mano che procediamo. C’è qualcosa di sbagliato se le idee di qualcuno sono esattamente le stesse ad alcuni anni di distanza. Questo è anche il caso di NUPP: se dovessi tornare ad interessartene dopo qualche anno e trovassi esattamente le stesse cose, dovresti insospettirti. ### Esempio: apertura mentale Quando ti opponi a qualcuno, assicurati di obiettare l’idea, non la persona. Questo aiuta a prevenire molte tensioni. D’altra parte, se qualcuno ti critica, cerca di non interpretare questo come una guerra nei tuoi confronti, ma come una discussione sulla tua idea e rimani aperto al confronto. Non ascoltare per rispondere, ascolta per comprendere e lavora con l’altra persona per migliorare l’idea. Tuttavia, alcune persone potrebbero intenzionalmente scegliere come obiettivo te, invece della tua idea. In tal caso, aiutali a concentrarsi sull’idea - anziché su di te - prima di procedere e cerca di mantenerti così durante tutta la conversazione. ## NUP2 Preserva e ottimizza energia e risorse [image] Le risorse sono limitate. Le risorse disponibili per un progetto sono limitate, così come le energie mentali a tua disposizione per prendere buone decisioni. Dovresti usarle con parsimonia e ottimizzare queste risorse per te stesso e il progetto, nonché aiutare i membri del team a fare lo stesso. ### Esempio: la regola 80/20 Una gran parte dei possibili benefici della gestione di un progetto viene conseguita con poco sforzo. Nella maggior parte dei casi, assicurarsi il 100% dei possibili benefici è troppo costoso e non giustificabile. Devi considerare questa regola in tutto ciò che fai, incoraggiando gli altri a fare lo stesso. ### Esempio: stanchezza decisionale Usiamo un’unica fonte di energia mentale per prendere ogni tipo di decisione ed esprimere la nostra forza di volontà. Se si utilizza troppa energia per decisioni non necessarie, o non importanti, ne avremo di meno per quelle importanti e potremmo ottenere risultati scadenti. Questo è uno dei motivi per cui dovresti evitare la micro-gestione (o micro management, secondo il principio di “gestione per eccezione” di PRINCE2^(®)). I conflitti che riguardano le idee possono essere utili, ma quelli che riguardano le persone sono di solito dannosi per il progetto e una delle conseguenze di ciò è prosciugare l’energia mentale dei membri del team. Se vedi un tale conflitto, dovresti fare del tuo meglio per trovare la causa alla radice e risolverlo. ### Esempio: prenditi cura di te stesso! Le decisioni che prendi e la forza di volontà che esprimi usano la tua fonte di energia mentale. D’altra parte, questa fonte è abbondante quando dormi e mangi correttamente. Quindi, abbi cura di te stesso: assicurati di dormire a sufficienza, riposati e mangia bene. Se hai abitudini o problemi che danneggiano il tuo sonno, non devi occupartene da solo; ci sono molti specialisti che possono aiutarti a risolvere il problema più facilmente. Può esserti di aiuto anche l’attività fisica, ma gli studi non hanno ancora detto una parola definitiva. Cerca allora di incoraggiare i membri del team a fare la stessa cosa. In primo luogo, assicurati che lavorino con un ritmo sostenibile e senza eccedere con l’impegno sul lavoro. Quindi, se hai la possibilità, prova a offrire cibo, snack e bevande energetiche e sane durante il lavoro. ### Esempio: equilibrio vita-lavoro Molti di noi amano ciò che fanno, ma non è tutto quello che dobbiamo avere nella vita. Così come ottimizzi il tuo lavoro, dovresti pianificare e realizzare i progetti della tua vita personale, in modo da renderla gioiosa e felice. Quando sei più felice, puoi avere più successo anche sul lavoro. Se puoi, prova a incoraggiare i membri del tuo team a fare lo stesso. ### Esempio: motivazione La motivazione è un concetto complesso. Ci sono alcuni riferimenti interessanti e utili sull’argomento e, ancora, molti non scientifici. Tuttavia, dovresti leggere e apprendere elementi sulla motivazione e usarli continuamente, poiché aumenta l’energia mentale della squadra e la possibilità di ottenere risultati migliori nel progetto. Stimolare la motivazione può essere semplice come far sapere alle persone che hai riconosciuto il loro buon lavoro con un sorriso gentile, o un semplice “grazie”. Tuttavia, fai attenzione perché molti dei modi comuni per motivare hanno un effetto negativo, come ad esempio usare esclusivamente le ricompense monetarie. ### Esempio: collaborazione e lavoro di squadra Le persone che collaborano veramente creano risultati migliori, ma soprattutto va tenuto presente che gli esseri umani sono socievoli e sono felici di far parte di un gruppo. Se è possibile rimuovere gli aspetti negativi del lavoro di squadra e creare un ambiente piacevole, ci saranno membri del team più motivati nel progetto. Bisogna tuttavia fare attenzione alle diversità tra gli individui: alcuni hanno bisogno di maggiore calma, di concentrazione e solitudine rispetto ad altri; in generale occorre equilibrio. ### Esempio: cultura “one-team” C’è una tendenza generale, da parte dei diversi membri coinvolti in un progetto, a creare o a considerare sottogruppi, che non mancano di creare tensione con altri gruppi. Ad esempio, tra persone che si concentrano sugli aspetti commerciali del progetto e le persone che stanno producendo il prodotto. Questa tensione consuma molta energia da entrambe le parti, e questo è uno dei motivi per cui dovremmo provare a costruire una cultura di squadra, dove tutti lavorano insieme con un unico obiettivo. ### Esempio: la saggezza collettiva Quando un gran numero di persone con diversità e differenze si riuniscono e lavorano in un ambiente facilitato, si sviluppa il potenziale per ottenere ottimi risultati, idee e soluzioni, che potrebbero essere anche migliori di quelle provenienti da singoli esperti. Se ne hai la possibilità, chiedi regolarmente ai membri del team di aiutarti a risolvere problemi difficili nel progetto. Oltre alla possibilità di ottenere buoni risultati, ciò permette anche ai membri del team di sapere che le loro opinioni sono apprezzate e che svolgono un ruolo importante nel progetto; il che, a sua volta, aumenta il loro livello di energia. L’attività E02 di P3.express è un esempio dell’uso della saggezza collettiva nei progetti. ### Esempio: capo facilitatore del progetto Se sei un project manager, la maggior parte delle cose che fai hanno come obiettivo la facilitazione (o almeno dovrebbero averla). D’altra parte, dovresti riconoscere quali membri del team hanno avuto precedenti brutte esperienze con i project manager, tali esperienze hanno un impatto sul rapporto con te: ne deriva che, invece di fidarsi di te, una parte della loro energia viene spesa per analizzare il tuo comportamento in vista di potenziali minacce. In questi casi potresti modificare il titolo da “project manager” a “Chief Project Facilitator”. Dopotutto, questo è ciò che realmente fai nel progetto. ## NUP3 Sii sempre proattivo [image] In noi c’è una naturale tendenza ad essere reattivi. Questo può aiutarci a preservare le nostre energie evitando di spenderle in questioni non importanti, o potrebbe darci risultati migliori quando abbiamo a che fare con qualcosa in cui siamo completamente incompetenti. Queste situazioni sono diverse dai nostri progetti, dove invece otteniamo risultati migliori essendo proattivi. ### Esempio: pianificazione Se vuoi guidare un’automobile verso una nuova destinazione e sei in ritardo, è possibile iniziare immediatamente a guidare per “risparmiare tempo” e affrontare eventuali problemi quando si presentano. L’approccio proattivo consiste nel prendersi un po’ di anticipo per impostare il navigatore in modo da darti il percorso più veloce, in base al traffico e ai possibili incidenti e code, e solo successivamente cominciare a guidare. Passerà del tempo prima dell’esecuzione, ma eviterai problemi e alla fine risparmierai tempo. Al contrario di quello che qualcuno pensa dei progetti Agili, la pianificazione è sempre necessaria, e la differenza riguarda solo il tipo e il livello di precisione dei piani. Pianificare prima dell’esecuzione è un approccio proattivo. Ricorda la citazione: “dammi sei ore per abbattere un albero e userò le prime quattro ore per affilare l’ascia”. Se si tratta di un progetto predittivo, puoi spendere quattro ore per affilare l’ascia, perché sei sicuro di abbattere un albero. In un progetto Agile, non sei sicuro se abbattere un albero, raccogliere rami spezzati, raccogliere erba, carbone o altro. Tuttavia, è ancora necessario avere una preparazione generale per tutti questi aspetti (sapere dove si trova il negozio di ferramenta più vicino) e avere una preparazione specifica (affilatura) quando ci si concentrerà su una determinata soluzione; questa è pianificazione. ### Esempio: pianificare la pianificazione Pianificare il modo in cui eseguiremo il progetto è un approccio proattivo. Questa proattività può essere estesa anche pianificando il modo in cui pianificheremo l’esecuzione; questo è il concetto del piano di gestione della guida PMBOK^(®), le strategie di gestione di PRINCE2^(®) e gli approcci in DSDM^(®). ### Esempio: pianificazione continua La realtà raramente si presenterà perfettamente come abbiamo pianificato, e questo è accettabile. Dobbiamo adattare continuamente i nostri piani per assicurarci che restino realistici e pratici. Dovremmo farlo non appena l’adattamento è necessario, non quando ci imbattiamo in problemi; questo è un approccio proattivo. ### Esempio: gestione dei rischi L’intero concetto di gestione del rischio si basa sulla proattività: quando si affrontano eventi incerti, invece di aspettare di vedere cosa succede e poi reagire, pensiamo alle probabilità e agli impatti, prendiamo in considerazione alcune azioni e - possibilmente - facciamo qualcosa al riguardo prima che accada. Considera che ciò che facciamo nei progetti è importante e impattante; a volte riguarda le vite delle persone stesse. ### Esempio: definire ruoli e responsabilità Puoi lasciare che i membri del team di progetto lavorino senza ruoli e responsabilità chiare, confidando che prima o poi emergeranno autonomamente in una certa forma, ma è troppo costoso e dopotutto potrebbe non funzionare bene. L’approccio proattivo è definire ruoli e responsabilità in anticipo e adattarli secondo necessità. Ciò rende il lavoro più facile per tutti, permettendo di concentrarsi sulla realizzazione pratica, invece di interrogarsi su chi fa cosa. Il numero e la varietà dei ruoli dipendono dal tipo e dalla dimensione del progetto; può essere una definizione semplice come quella di Scrum, qualcosa di moderato come quello di P3.express, o qualcosa di completo come quelli in DSDM^(®) e PRINCE2^(®). Tuttavia, non dimenticare che la descrizione dei ruoli in questi metodi riguardano solo le attività di gestione e che quindi devi sempre aggiungere la descrizione relativa ai ruoli tecnici. ### Esempio: scelte disponibili Devi chiudere il progetto prematuramente o continuarlo? Raramente ci sono solo due scelte, anche se la domanda lo sottintende. Devi avere un approccio proattivo e prendere in considerazione tutte le opzioni prima di prendere una decisione. Forse puoi salvare il progetto; forse puoi metterlo in pausa fino a quando la situazione diventa chiara; forse puoi cambiare l’approccio al progetto (ad esempio, l’outsourcing), ecc. ### Esempio: pensiero critico Abbiamo tutti molti pregiudizi, che da una parte ci aiutano a sopravvivere e dall’altra ci ingannano facendoci prendere decisioni sbagliate. Quando si tratta di prendere decisioni importanti nel progetto, è meglio fermarsi e considerare tutti i pregiudizi che possono avere un impatto sulla nostra decisione, prima che causino un problema. Come riferimento, puoi usare la lista dei “bias cognitivi” disponibile su Wikipedia. Esistono persino modelli e quadri decisionali che è possibile utilizzare per prendere decisioni migliori. All’inizio può essere fonte di distrazione e persino fastidioso usarli, ma presto ci si abitua e se ne puoi trarre profitto senza troppo sforzo. ### Esempio: trasparenza Non ci piace essere in ritardo nel progetto o avere altri problemi, ma ciò non significa che dovremmo nasconderlo. Sii trasparente e fallo sapere agli stakeholder, perché alcuni di loro potrebbero essere in grado di aiutarti. Prima o poi anche loro verranno a conoscenza dei problemi e relative implicazioni e alcuni Stakeholder potrebbero dover intraprendere azioni tempestive (ad esempio, accettare conseguenze negative). ### Esempio: comunicare efficacemente Possono esserci molti casi in cui si inviano relazioni a varie parti interessate al progetto, senza poi ottenere alcun feedback. Potresti credere che tutto vada bene solo perché non ci sono feedback negativi, anche se potrebbe non essere così. Devi essere proattivo e controllare se hanno realmente ricevuto e compreso le comunicazioni e i report, se hanno raggiunto lo scopo, utilizzando il feedback come input per aggiustare la tua comunicazione. Altrimenti questo problema nascosto potrà causare seri problemi in seguito, quando sarà troppo difficile o troppo tardi per risolverlo. ### Esempio: assumersi le responsabilità E’ facile accusare gli altri dei risultati scadenti. Per esempio, cerchi di ottenere il pieno potere di cambiare tutto nel progetto, ma non te lo concedono e quindi il progetto fallisce. Questo non è un atteggiamento proattivo. L’approccio proattivo è assumersi la responsabilità e fare tutto il possibile entro i limiti. Non puoi aspettarti che l’organizzazione si fidi di te e ti dia tutto con la speranza di ottenere buoni risultati, specialmente quando in passato hanno visto fallire tanti progetti. Quello che devi fare è fare un piccolo miglioramento entro i limiti impostati, usarlo per guadagnare fiducia, un po’ più di risorse e un po’ più di tolleranza ai vincoli, usando questi vantaggi per ottenere un ulteriore miglioramento leggermente più grande, e procedere così fino a raggiungere un risultato ottimale. ## NUP4 Ricorda che una catena è forte quanto il suo anello più debole [image] Ci sono vari domini nei progetti, e tutti hanno bisogno di attenzione; dobbiamo avere una prospettiva olistica per il progetto. Prestare attenzione a un dominio apparentemente importante (ad esempio, il tempo) non è sufficiente, perché tutti i domini interagiscono e non funzionano correttamente a meno che tutti ricevano sufficiente attenzione. ### Esempio: è tutta questione di scadenze! Immagina una situazione in cui stai costruendo qualcosa per i giochi olimpici. Hai una scadenza improrogabile che rende la gestione del tempo molto importante. Sei d’accordo? Che cosa succede se la qualità è così bassa da causarne la rilavorazione? Questo avrà un impatto sul tempo. Questo evidenzia che la qualità è correlata al tempo. Potresti avere un giardino elegante nella definizione originale del progetto ma, se non ci fosse abbastanza tempo, potresti stralciarlo o cambiarlo seminando semplicemente l’erba, purché tu abbia considerato questa possibilità e ti sia preparato a questa eventualità. Quindi, anche la gestione dell’ambito è importante. Si è creata una situazione in cui ambito, tempo e qualità sono al centro dell’attenzione. Hai mai sentito di quel famoso esempio in cui il presidente Kennedy incontra un custode nella NASA e gli chiede cosa fa, e lui risponde: “Sto aiutando a mandare un uomo sulla luna”? Non è forse vero che avere questo tipo di persone nel progetto aiuta a rispettare la scadenza? Man mano che procedi, assicurati che ogni singola area nel progetto contribuisca alla gestione del tempo. Non si può essere sufficientemente sicuri di rispettare la scadenza a meno che non si presti attenzione a tutti i settori. ### Esempio: Cherry Picking (selezionare il meglio) Quando si sperimentano vari approcci e metodi, a volte si selezionano gli elementi migliori fra i diversi riferimenti creando una combinazione di tutto ciò che sembra interessante. Questo generalmente non funziona, perché alcuni elementi non funzionano isolati dal loro riferimento e devono essere resi compatibili tra loro. Qualsiasi aggiunta o modifica a un sistema dovrebbe essere eseguita con una visione olistica. Questo è il motivo per cui a volte vediamo elementi contraddittori in diversi metodi; qualcosa funziona bene in un sistema e il suo contrario funziona bene nell’altro sistema. Ogni elemento non è giusto o sbagliato a priori. L’approccio più sicuro è selezionare una metodologia per la gestione del progetto, personalizzarla e poi aggiungere con cautela nuovi elementi, considerando la coerenza dell’intero sistema. ### Esempio: l’approccio anti-processo Una delle migliori cose che i metodi Agili hanno compiuto è portare l’attenzione sugli aspetti umani. Il manifesto Agile dà più valore ad essi rispetto ai processi e agli strumenti, anche se questi elementi non dovrebbero nemmeno essere comparati l’uno all’altro. Tutti i metodi affermano che gli aspetti umani sono importanti, ma la vera differenza nei metodi Agile è che gli aspetti umani sono parte integrante dei processi, piuttosto che un semplice suggerimento. Quindi, questa non è una competizione tra aspetti umani e processi, ma piuttosto sul modo in cui gli aspetti umani sono visti nel sistema. È risaputo, alcune persone provano a sostituire gli aspetti umani con processi più sofisticati, ma questo è solo un uso improprio. Succede anche il contrario: ci sono persone che cercano di sostituire i processi con aspetti umani, cosa che comunque non funziona bene. ### Esempio: questi sono tutte le aree di competenza di cui hai bisogno Quando pensi alle aree di competenze, devi stare attento a non perderne nessuna. Ma quali sono? Se ti servi delle fonti più affermate riceverai risposte diverse, eppure nessuna di esse è pienamente valida. I temi del PRINCE2^(®) stabiliscono delle aree di competenza, ma sono solo quelle che svolgono un ruolo chiave nella metodologia. Le altre rimangono implicite. La Guida PMBOK^(®) non rappresenta una metodologia vera e propria, ma la si evince bene dallo sviluppo di dieci aree di conoscenza riportate. Tuttavia, queste ultime rimangono interpretazioni basate sulla guida del PMBOK^(®), che non è neutrale (non che sia necessaria una prospettiva neutrale). Cosi, per esempio, gli aspetti umani non ricevono molta attenzione nella Guida. Una buona fonte di riferimento sulle aree di competenza è ICB (IPMA). Tuttavia, non si tratta di settori, ma di competenze richieste nel progetto. Non c’è una relazione diretta con i settori di competenza, anche se aiuta molto nell’identificarli. Non esiste un elenco di settori nemmeno in NUPP, principalmente perché si tratta di un meta-sistema piuttosto che di un sistema, poi perché la categorizzazione dei domini dipende dal tipo di progetto e dal suo ambiente; ad esempio, un progetto di costruzione di routine può richiedere una prospettiva diversa rispetto a un progetto di ricerca creativa. ## NUP5 Non fare nulla senza uno scopo chiaro [image] Non dovresti fare nulla a meno che tu non abbia uno scopo chiaro. Immagina due mondi paralleli dove tutto è uguale tranne per la cosa che stai considerando: quanto sarebbero diversi? La differenza vale il tuo sforzo per fare quella cosa? Se non hai uno scopo preciso in mente e fai qualcosa solo perché tutti gli altri lo stanno facendo, o tutti dicono che è importante farla, allora: - Potrebbe non esserci un reale vantaggio e quindi potresti non ottenere nulla da esso. Oppure - Potrebbe esserci ancora del potenziale beneficio, ma poiché non hai lo scopo chiaro in mente, il tuo modo di farlo potrebbe non essere efficace. ### Esempio: Portfoli e Programmi Se sei coinvolto nella selezione e nell’avvio di progetti, dovresti assicurarti di concentrarti sui benefici e sui problemi che dovrebbero essere risolti prima che il prodotto realizzi queste cose. L’esempio classico è il produttore di ascensori che riceveva lamentele sulla velocità dei loro ascensori e lanciava più progetti per aumentare la velocità, senza mai arrivare ad un successo completo. Così è andato avanti fino a quando non hanno deciso di capire il vero problema (la noia o il disagio della gente), anziché concentrarsi sulla soluzione “naturale” (ascensori più veloci). Il risultato è stato che aggiungendo specchi agli ascensori il problema e stato definitivamente risolto. Ricorda che la gestione del progetto consiste principalmente nel fare le cose bene, mentre la gestione del portafoglio riguarda il fare le cose giuste. Non importa quanto bene gestisci i tuoi progetti, non funzionerà bene se stai facendo progetti sbagliati. Si tratta di avere chiaro lo scopo. ### Esempio: il progetto nell’insieme La flessibilità del prodotto varia nei progetti. In alcuni progetti di sviluppo IT il prodotto è completamente flessibile e la sua forma finale dipende dal feedback che verrà generato dagli incrementi del prodotto durante il progetto, per questo richiede un approccio adattivo (Agile). Questa è praticamente una combinazione del portfolio, del programma e dei livelli del progetto, e richiede la massima attenzione per raggiungere l’obiettivo finale. È una buona idea documentare lo scopo e renderlo accessibile; è uno degli scopi della “visione del prodotto” utilizzata in alcuni tipi di approcci al progetto, come quello Scrum. L’attenzione al valore del business nei progetti Agile è il loro modo di garantire l’allineamento con lo scopo. In altri tipi di progetti, in cui il prodotto è relativamente fisso e vi sono altri meccanismi per garantire che il prodotto identificato soddisfi lo scopo, è possibile che i membri del team di progetto trasferiscano gran parte della loro attenzione dallo scopo al prodotto (da qui il principio “focus on products” di PRINCE2^(®)). E’ richiesta comunque una minima attenzione allo scopo per garantire che ciò che viene costruito soddisferà lo scopo. Il che può essere fatto confrontando i benefici previsti con i benefici attesi (da qui il principio di “giustificazione aziendale continua” e il tema del " business case” in PRINCE2^(®)). Quando il progetto è fatto per i clienti esterni, il cliente può avere il suo scopo nel fare il progetto e la tua azienda può averne uno diverso. Bisogna capire e usare entrambi per avere davvero successo. ### Esempio: monitoraggio di progetto Usare lo scopo finale è fondamentale, ma potrebbe essere troppo astratto per molti usi quotidiani. Ecco perché è necessaria una gerarchia di “elementi guida” per renderla più pratica. In primo luogo, la giustificazione e i benefici del progetto sono definiti in base allo scopo finale, perciò si avranno obiettivi espliciti e impliciti per le variabili del progetto (ad esempio tempo, costi e qualità) per soddisfare la giustificazione, che a sua volta soddisferà lo scopo ultimo. Questi sono obiettivi di livello inferiore che sono utili per molte delle nostre attività quotidiane. Quando si tratta di monitoraggio, il monitoraggio di basso livello del progetto verrà eseguito utilizzando il livello più basso di variabili, perché potrebbe non essere possibile tracciare la correlazione con lo scopo finale. In questo caso, dovresti avere ancora in mente gli scopi: qual è lo scopo del monitoraggio? Una risposta normale e accettabile è vedere se siamo sulla buona strada, altrimenti innescare una certa reazione che ci riporterà in pista o regolerà gli obiettivi e vedremo se può ancora soddisfare lo scopo finale. Pertanto, le nostre misurazioni dovrebbero essere in grado di aiutare, anche con questo scopo di basso livello e opportune misurazioni previsionali, al completamento delle variabili; cioè, quando saremmo in grado di terminare il progetto? Quanti soldi avremmo bisogno per finire il progetto? Eccetera. Tutte le altre misurazioni, ad esempio i valori pianificati e attuali, sono solo valori transitori necessari per calcolare le previsioni, non i valori finali che si utilizzano a fini gestionali. ### Esempio: documenti Indipendentemente dall’approccio di sviluppo utilizzato nel progetto, la pianificazione è sempre necessaria. La questione importante è il livello di dettaglio in ciascuna tipologia di piano. Se non ci sono abbastanza dettagli nel piano, il piano non sarà in grado di contribuire a sufficienza e l’esecuzione del progetto sarà più basata su decisioni ad hoc piuttosto che su quelle olistiche e integrate. D’altro canto, molte persone cercano di essere caute e aggiungere troppi dettagli al loro piano, il che rende troppo difficile la preparazione e la manutenzione, rendendo tutto troppo rigido per le incertezze del progetto. Così, il piano diventa irrealistico e inutile. Il modo migliore per decidere il livello di dettaglio è avere lo scopo in mente o ogni elemento del piano. Ad esempio, se stai considerando l’aggiunta di risorse al piano dovresti avere uno scopo: come le utilizzerai? Come potrebbe aiutare il progetto? Quanto impegno ci vuole? Ne vale la pena? A volte si tratta di decidere se si desidera avere un determinato elemento nei piani e, a volte, come si desidera pianificare o preparare qualcosa. Prendi il Business Case, o il Project Charter, o un report: è ancora necessario chiederti perché stai preparando quel documento e come esso può aiutare il progetto. Cercare di aderire ad un “modello” è l’opposto di fare qualcosa in funzione di uno scopo. ### Esempio: status reporting (resoconto di stato) In molti progetti è comune avere resoconti di stato del progetto davvero lunghi. Basandoci su NUPP, dovremmo chiederci quale sia lo scopo del resoconto e come possiamo raggiungere tale scopo a prescindere da ciò che la maggior parte degli altri potrebbe fare. In molti casi, ciò può indurci a preparare resoconti di una sola pagina, molto semplici, che le parti interessate leggono e comprendono davvero, invece di lunghe relazioni. Questo significa che prestiamo attenzione agli scopi. Tuttavia, se si preparano report di una sola pagina, alcune persone potrebbero obiettare e ritenere che non si disponga di un sistema di monitoraggio “appropriato”. Ciò crea praticamente un secondo scopo (oltre al primo scopo, che aiuta le parti interessate a capire lo stato del progetto). A tal fine puoi semplicemente creare un secondo tipo di resoconto più lungo, che non verrà comunque integrato con il primo perché i due scopi non sono identici. ### Esempio: business case e project charter Preparare documenti come un Business Case e un Project Charter è di solito, per la maggior parte delle persone, un impegno noioso, inutile, burocratico, mentre questi documenti hanno tutti scopi validi che si applicano alla maggior parte dei progetti. Se provi a prendere un “modello” e compilarlo, il lavoro è solo sprecato, puoi invece focalizzarti sullo scopo reale di quei documenti, vedere come e se possono essere utili nel tuo progetto, e quindi preparare il documento in qualsiasi modo tu voglia, solo per soddisfare tali scopi: il risultato sarà il documento giusto. Mentre stai pensando al modo in cui puoi preparare i documenti per soddisfarne gli obiettivi, potresti non pensare ad ogni scenario col rischio di perdere qualcosa. E’ possibile trovare suggerimenti in alcuni riferimenti, quali PRINCE2^(®), PMBOK^(®) Guide, P3.express e DSDM^(®), quindi valutare tali ipotesi in base agli obiettivi. ### Esempio: dopo il progetto Mentre il progetto ha un certo scopo, e lo possiamo considerare durante tutto il progetto, la realizzazione dello scopo finale è valutata principalmente sulla base delle previsioni effettuate durante il progetto, che non dovremmo dimenticare quando il progetto è completato. Questo è importante per verificare la realizzazione degli obiettivi dopo che il progetto è finito, perché: - possiamo vedere come vengono raggiunti gli obiettivi finali e apprendere insegnamenti preziosi per progetti futuri, e - talvolta gli obiettivi vengono raggiunti solo dopo aver aggiunto del lavoro successivo al completamento del progetto, è necessario comprendere la necessità di tali compiti extra durante il monitoraggio. Il monitoraggio post-progetto è un passo necessario per assicurare l’ottenimento dello scopo. Di solito è responsabilità dei sistemi di gestione di programma e di portfolio, ma poiché la maggior parte delle aziende non ha tali livelli di gestione, questo passaggio viene solitamente trascurato. Ecco perché metodi come P3.express e DSDM^(®) aggiungono questo passaggio alle loro metodologie di gestione di progetto. ### Esempio: semplicità Il mondo è complesso e caotico e i nostri modelli sono approssimazioni astratte che riflettono porzioni del mondo, pertanto possono essere semplici. D’altra parte, i sistemi semplici di solito funzionano meglio, perché possiamo concentrarci sull’idea principale. Molti di noi cercano di ottenere risultati migliori aggiungendo complessità ai nostri sistemi, sperando che si abbinino alla complessità del mondo, anche se questo praticamente rende il sistema difficile da operare e in genere impedisce di raggiungere l’obbiettivo. ### Esempio: Tailoring (Adattamento) I progetti non sono identici; un software per lo streaming di musica ha una condizione di funzionamento molto diversa da quella che potrebbe essere utilizzata nelle attrezzature di un ospedale, o da quella di un aereo, in cui la vita delle persone potrebbe dipendere da esso, o da un software utilizzato in un satellite realizzato per funzionare molti anni senza schiantarsi. E tutti questi sono diversi dalla costruzione di una villa estiva, di una stazione antincendio, o di un impianto di processo. Quando hai in mente gli obiettivi, puoi comprendere meglio come personalizzare i sistemi e gli artefatti per i diversi progetti. ## NUP6 Utilizzare elementi ripetibili [image] Un approccio ad hoc per ogni progetto richiede troppe energie e risorse e presenta sempre il rischio di perdere alcuni degli elementi necessari. Il modo migliore per semplificare ciò che deve essere fatto è usare elementi ripetibili e preferibilmente portarli in cicli ripetibili. ### Esempio: checklists (liste di controllo) di qualità Una lista di controllo è un semplice esempio di un elemento potenzialmente ripetibile che molte persone usano nella loro vita personale e professionale. Prendi i criteri di qualità di un deliverable: - In primo luogo, è possibile creare una lista di controllo di tutti i criteri, che è anche una forma di pianificazione. - Quello che NUP6 consiglia è di provare a generalizzarlo: ci sono altri deliverable simili nel progetto? In tal caso, vale la pena di preparare una lista di controllo di qualità generale per quella categoria di prodotti finali, e usarla per tutti quei progetti. Se ci sono alcune varianti, bisogna mantenere l’elenco generico e aggiungi alcuni elementi extra per i singoli deliverable. In questo modo si ottengono elenchi di controllo ripetibili. - Quando si preparano liste di controllo generiche per vari tipi di risultati finali, è possibile trovare elementi che si ripetono tra loro, il che suggerisce per loro una virtuale categoria di livello superiore, diciamo “padre”. In tal caso, invece di ripetere gli articoli per tutte quelle liste di controllo generiche, si possono estrarre e inserire in una checklist principale. Infine, probabilmente si otterrà una sola checklist generica per l’intero progetto. La “Definition of Done” di Scrum è un esempio di checklist a livello di progetto, valida per la qualità, ma anche per altri temi. Ogni deliverable sarà declinato in una gerarchia di categorie, e dovrebbe soddisfare gli elementi visualizzati nelle checklist di tutte le categorie della catena. In questo modo, un elemento nell’elenco di controllo principale diventerà ripetibile per tutti i deliverable sottostanti, risparmiando tempo ed energia nella pianificazione e nell’esecuzione. Ancora più importante, una volta fatto questo per un progetto, è possibile personalizzarlo e utilizzarlo per tutti i futuri progetti simili, così da ottenere una forma ripetibile di pianificazione per più progetti. ### Esempio: processi e flussi di lavoro Alcuni risultati o obiettivi richiedono al loro interno alcuni passaggi che possono diventare standardizzati e ripetibili. Ad esempio, se i deliverable devono essere progettati individualmente e approvati è possibile preparare un flusso di lavoro semplice che renda chiari tutti i passaggi, le persone coinvolte e le durate approssimate, evitando molte difficoltà. Si deve fare attenzione, tuttavia, a non rendere i flussi di lavoro e i processi troppo complicati o richiedenti troppa documentazione, poiché ciò avrebbe conseguenze negative. Tutte le persone coinvolte nel progetto dovrebbero trovare i flussi di lavoro e i processi come qualcosa che supporta il loro lavoro e rende tutto più facile. E non come una documentazione burocratica che blocca il loro vero lavoro. I progetti Agili hanno elementi pratici ripetibili nel loro approccio di sviluppo iterativo, in cui alcuni tipi di attività di sviluppo vengono ripetuti per ogni funzione; per esempio, la routine quotidiana comune in XP (eXtreme Programming): accoppiare, selezionare un elemento, disegnarlo su una lavagna, creare script e codice di test, integrare il codice, ecc. Oltre ai flussi di lavoro ripetibili che possono essere utilizzati per attività tecniche, si possono avere elementi ripetibili anche per le attività di gestione del progetto. I processi nella Guida PMBOK^(®), PRINCE2^(®) e DSDM^(®), le attività in P3.express e gli eventi in Scrum sono esempi di questo concetto. ### Esempio: cicli È utile disporre in modo chiaro gli elementi ripetibili per la gestione del progetto. Ciò può essere reso ancora più semplice inserendoli in cicli ripetibili. Questi cicli semplificano significativamente le attività quotidiane delle persone coinvolte nella gestione e nella leadership del progetto. Esempi di questo concetto sono: i cicli dei gruppi di processi nella Guida PMBOK^(®), quando utilizzati in un progetto con più fasi; le fasi (stages) nella metodologia PRINCE2^(®); i cicli giornalieri, settimanali e mensili in P3.Express; le iterazioni e i timebox in DSDM^(®); gli Sprint in Scrum. Cicli più brevi sono più facili da capire e da usare rispetto a quelli più lunghi; ad esempio, Sprint in Scrum in contrasto con le fasi secondo la Guida PMBOK^(®). Tuttavia, cicli troppo brevi potrebbero non essere sufficienti per supportare determinati tipi di progetto e la soluzione può essere l’uso di più cicli, come in DSDM^(®), in cui si usano cicli di timebox brevi insieme a cicli di iterazione più lunghi, oppure come in P3.express, ove si usano cicli giornalieri, settimanali e mensili. ### Esempio: metodi L’utilizzo di una metodologia o di un framework per l’esecuzione di un progetto è un altro uso di elementi ripetibili. Questo può essere un sistema esistente come PRINCE2^(®), P3.express, DSDM^(®) o Scrum, o uno che hai personalizzato o costruito da solo. Tuttavia, di solito è un’idea migliore iniziare con uno dei metodi esistenti e adattarlo alle proprie esigenze piuttosto che crearlo da zero. Ogni elemento ripetibile è astratto e richiede la personalizzazione per adattarsi al mondo reale. Tuttavia c’è una gamma di necessità di astrazione e di personalizzazione: le checklist di qualità piccole e relativamente concrete si trovano all’estremità della gamma, con la minima quantità di astrazione e necessità di personalizzazione, mentre le metodologie sono dall’altra parte, con il più alto bisogno di adattamento. Si deve sempre analizzare la necessità di adattamento, altrimenti, l’elemento ripetibile non corrisponderà correttamente alle esigenze del caso.