Non fare nulla senza uno scopo chiaro
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.