This is the Trace Id: 89800d4b2ff2c30c53640910b4da6467
Passa a contenuti principali Fai crescere il tuo business Gestisci il tuo business Produttività Tecnologia per il business Suggerimenti per il business

Gestione dei progetti: tradizionale, iterativa o ibrida?

Come la maggior parte dei project manager (e delle organizzazioni), probabilmente fai fatica a scegliere l'approccio ottimale alla realizzazione. La maggior parte di noi riconosce che gli approcci tradizionali non garantiscono una realizzazione di successo ed è sempre in cerca di un modo migliore.

 

Negli ultimi anni, le tecniche di sviluppo agile o iterativo hanno ricevuto molta attenzione positiva come miglioramento significativo, che porta a una realizzazione dei progetti con maggiore successo. Pertanto, come la maggior parte delle organizzazioni di oggi, anche la tua si sta probabilmente chiedendo dove e come usare al meglio queste tecniche di sviluppo agile o iterativo per migliorare la tempestività e il successo della realizzazione dei progetti.  

 

In poche parole, le tecniche di sviluppo iterativo pianificano, sviluppano e implementano le funzionalità del progetto in piccoli blocchi (o iterazioni). La chiave per una realizzazione iterativa di successo è che ogni piccolo blocco opera in modo efficace come un mini-progetto più piccolo nell'ambito del progetto complessivo. Di conseguenza, ogni iterazione del mini-progetto può pianificare meglio l'impegno necessario per realizzare un'iterazione di due settimane rispetto a un piano di due anni. Inoltre, poiché pianifichiamo in incrementi di due settimane, possiamo adattare facilmente il piano delle prossime due settimane per tener conto di eventuali modifiche individuate. 

Case study agile vs. tradizionale

Vorrei fare una breve pausa per descrivere una situazione non tecnica, in cui si è ottenuto più successo usando un approccio agile piuttosto che un piano tradizionale. 

 

Usiamo un esempio di pianificazione delle attività di un'intera giornata: questo è il progetto. Come in un progetto ampio, vi è molta incertezza e rischio in questo: non sappiamo cosa succederà dopo pranzo che potrebbe influire sul nostro piano, ma la tradizione vuole che sviluppiamo un piano completo per quello che faremo ogni ora della giornata, dal risveglio alle 6 di mattina fino a quando andiamo a letto alle 11 di sera.

 

Alle 9:00 siamo in ritardo perché il traffico ci ha rallentati nell’andare al lavoro; alle 10:00 siamo convocati a una riunione d'emergenza e, a mezzogiorno, l'unica attività quotidiana completata è stata arrivare in ufficio, e anche quella era in ritardo sulla pianificazione. 

 

Ora, trattiamolo come un progetto agile in cui pianifichiamo solo la prossima iterazione: prepararci a uscire di casa (quindi le storie sono: doccia, colazione e portare i bambini a scuola). Tutto questo è stato realizzato con successo, nei tempi e nel budget previsti.

 

Quindi, con fiducia, pianifichiamo la prossima iterazione, che è arrivare in ufficio (guidare fino al deposito degli autobus, prendere il treno suburbano fino alla stazione e poi l'autobus urbano per l'ufficio).

 

Questo non funziona molto bene: la prima storia (guidare fino al deposito degli autobus) ha problemi di traffico, quindi modifichiamo la storia in guidare fino all’ufficio e concordiamo che le altre due storie possano essere rimosse dal piano dell'iterazione. All’arrivo, pianifichiamo la prossima iterazione. Ma, a metà del ciclo di pianificazione, viene aggiunta una nuova storia (la riunione d'emergenza), e questa occuperà l'intera iterazione successiva.

 

Infine, dopo pranzo, le cose si calmano e riusciamo a esaminare il backlog e iniziare le attività con la priorità più alta; completiamo con successo due iterazioni che riguardano gli elementi con la priorità più alta nel pomeriggio. 

 

Se fossimo rimasti al piano tradizionale, non avremmo mai completato questi elementi con la priorità più alta, perché sarebbero stati riprogrammati al giorno successivo per via dello slittamento del piano dovuto al tragitto verso l'ufficio. 

Qual’è l'approccio migliore: agile, tradizionale o ibrido?

È in questa flessibilità di adattarsi alle esigenze aziendali in evoluzione che eccellono i metodi agili o iterativi, ed è il motivo per cui molte organizzazioni li stanno adottando. PERÒ, la tua organizzazione è davvero pronta a passare completamente al metodo agile? Per esperienza, spesso vi sono molti ostacoli all'adozione del metodo agile su larga scala, in particolare criteri organizzativi molto consolidati che spesso sono ben poco compatibili con gli approcci agili. 

Criteri come la necessità di un budget definito, di una dichiarazione di realizzazione dei benefici e di una data target prima che un progetto possa essere approvato sono importanti (ma non proprio agili). Analogamente, i criteri organizzativi di implementazione che devono essere seguite per garantire che non vi siano impatti sulle operazioni esistenti sono cruciali (ma decisamente non agili). 

Di conseguenza, molte organizzazioni si stanno sforzando di capire come preservare alcuni “processi tradizionali” chiave, adattandosi al contempo ai metodi iterativi. La risposta è un modello ibrido di realizzazione. Parti del progetto possono essere realizzate usando metodi di gestione tradizionali, altre possono essere iterative. 

Modello ibrido di realizzazione

Il modello ibrido più comune che ho incontrato supporta l'avvio e la pianificazione tradizionali del progetto, seguiti da una serie di iterazioni con pause per le attività di implementazione tradizionali per le consegne, seguite da un'altra serie di iterazioni e dall'implementazione tradizionale. 

 

In questo modello, sviluppo una tradizionale struttura di suddivisione del lavoro (WBS) basata sui risultati finali, che identifica i principali elaborati necessari nell'organizzazione per l'approvazione del progetto, come lo Statuto del progetto (Project Charter), il Piano di gestione del progetto e il Budget del progetto.

Questi elaborati iniziali possono essere sviluppati e gestiti usando metodi tradizionali per mostrare alla dirigenza che questo progetto è appropriato ed è un buon investimento di risorse. 

 

Una volta approvato il progetto, questo può passare a un approccio iterativo in cui si mantiene un backlog di storie, e le storie con la priorità più alta vengono selezionate e sviluppate completamente nell'iterazione successiva. La vista del progetto passa dalla tradizionale visualizzazione del diagramma di Gantt a una scheda interattiva drag-and-drop che consente di assegnare dinamicamente le storie alle iterazioni. 

 

In qualsiasi momento, spesso su base giornaliera, il responsabile del prodotto può aggiungere, eliminare e modificare le storie nel backlog in modo da rispecchiare le esigenze aziendali in evoluzione.

Alla fine di ogni iterazione, ci fermiamo ed eseguiamo una valutazione retrospettiva dei successi e degli insuccessi, quindi apportiamo modifiche per implementare i miglioramenti necessari. Il passo successivo, e più importante, è esaminare il backlog di prodotto e selezionare le storie più importanti come candidate per l'iterazione successiva. Questo approccio garantisce che il progetto si concentri sempre sul lavoro più appropriato e di maggior valore. 

 

All'interno di ogni iterazione, il team può usare principi agili come il confronto giornaliero e discutere lo stato delle storie pianificate per l'iterazione corrente. In questo modo il team ha un controllo totale sul lavoro completato all'interno di un'iterazione, pur garantendo che il progetto complessivo rimanga aggiornato e disponibile per la reportistica aziendale rispetto alla capacità delle risorse e allo stato del portfolio e programma.

Un aspetto chiave per i principi del metodo agile è la possibilità di implementare la soluzione finale in piccoli rilasci. Questo offre il vantaggio di poter usare funzionalità preliminari per ottenere il più rapidamente possibile alcuni dei benefici aziendali previsti.

 

Inoltre, offre il vantaggio di una convalida anticipata della soluzione, in modo da poter includere facilmente eventuali adeguamenti nelle storie rimanenti nel backlog di prodotto. Pertanto, non appena nelle iterazioni sono state completate un numero sufficiente di storie ad alta priorità, il progetto tornerebbe a un ciclo tradizionale ed eseguirebbe le attività standard di implementazione richieste dall'organizzazione. 

Prova Microsoft Project gratuitamente

Prova Gratuitamente Microsoft Project per un mese

Queste attività di rilascio e implementazione saranno pianificate e controllate usando approcci tradizionali e garantiranno che vengano seguiti i processi definiti per ridurre eventuali impatti sulle operazioni esistenti quando vengono implementati nuovi progetti.

 

Una volta completato il primo rilascio, il progetto torna agli approcci agili e inizia a usare un'altra sequenza di iterazioni per continuare lo sviluppo delle storie rimanenti.

 

Sebbene questo approccio “a fasi” per combinare gli approcci agile e tradizionale sia il più comune, è possibile combinare gli approcci per supportare requisiti specifici di realizzazione del progetto. Per esempio, ho gestito un progetto che richiedeva un livello estremamente elevato di conformità e convalida durante l’implementazione di un nuovo prodotto in un settore fortemente regolamentato. Pertanto, la maggior parte del progetto è stata pianificata e controllata usando metodi tradizionali.

 

Tuttavia, vi era una parte di business intelligence del progetto in cui la mia azienda stava analizzando l’ampia quantità di dati sulle prestazioni generati dal sistema; questa parte era supportata al meglio da un approccio agile. Per la componente di business intelligence del progetto (in esecuzione parallelamente al lavoro tradizionale), selezionavamo le storie con priorità più alta - che potevano essere completate in uno sprint di tre settimane - e completavamo un'iterazione.

 

Poiché molte di queste storie avevano natura esplorativa, spesso creavamo nuove storie, per un’ulteriore esplorazione o per realizzare specifici report delle prestazioni. Queste venivano semplicemente aggiunte al backlog per essere prese in considerazione per lo sprint successivo.

 

Con questo approccio, avevo un’unica pianificazione del progetto che garantiva il raggiungimento di tutti i passaggi di reportistica e normativi richiesti, pur consentendo un approccio estremamente flessibile allo sviluppo della componente di reportistica aziendale non regolamentata del progetto.

 

Avere tutto il lavoro in un’unica pianificazione offriva una visione unica di tutto ciò che accadeva in questo progetto:

 

  • Le informazioni che mi servivano per gestire le allocazioni delle risorse alle attività più appropriate (tradizionali o agili) erano immediatamente disponibili
  • La possibilità di creare efficaci report di stato settimanali e mensili avanzati era a disposizione

 

Quello agile è un approccio estremamente potente per la realizzazione dei progetti, che dovrebbe offrire vantaggi significativi al set di strumenti complessivo della tua organizzazione per la realizzazione dei progetti. Può essere usato come soluzione autonoma, come parte di un approccio di realizzazione a fasi, oppure integrato in una struttura di realizzazione ibrida.

 

La chiave è adottare i principi dell’approccio agile che aiuteranno la tua organizzazione a raggiungere il successo nella realizzazione, continuando al contempo a seguire i processi tradizionali che hanno finora contribuito al successo dell’organizzazione stessa.

Steve Caseley ha oltre 35 anni di esperienza in Microsoft Project ed è un utente attivo di Microsoft Project fin dalla sua prima versione. È il curatore di numerosi libri relativi a Microsoft Project e alle procedure consigliate di Gestione dei progetti. È Principal Consultant presso Sensei Project Solutions, dove aiuta le grandi organizzazioni a raggiungere l’eccellenza nella realizzazione dei progetti usando il set di strumenti di Microsoft Project Portfolio Management (PPM).

Inizia a usare Microsoft 365

È l'Office che già conosci, con in più gli strumenti che ti permettono di collaborare e migliorare la produttività, ovunque e in qualsiasi momento.

Contenuti correlati

Gestire la mia azienda

Perché i dirigenti odiano i project manager?

Dati e idee per le aziende non fornisce consulenza fiscale o finanziaria. Devi contattare il tuo consulente per discutere della tua situazione.

Segui Microsoft 365

Italiano (Italia) Privacy per l'integrità dei consumer Riferimenti societari Contatta Microsoft Privacy Gestisci i cookie Condizioni per l'utilizzo Marchi Informazioni sulle inserzioni EU Compliance DoCs