Nella gestione dei progetti, le metodologie principali regnano sovrane, e le metodologie ibride di project management sono spesso considerate una blasfemia. Il tuo team deve essere o predittivo o adattivo (a seconda della "scuola di pensiero"), e non c'è spazio per sfumare le linee, a meno di essere esiliati dal regno delle metodologie pure di gestione dei progetti.
I project manager, e in particolare i project manager digitali, sono sempre stati ossessionati dalle metodologie. Perché fondiamo tutto ciò che facciamo su di esse—e sono davvero così importanti?
In questo articolo voglio analizzare cosa sono le metodologie ibride di project management, i benefici dell’utilizzo di una di esse e perché non sono così sovversive come potrebbero sembrare.
Che cos’è una metodologia ibrida di project management?
Una metodologia ibrida di project management è una combinazione di due (o più) tra i moltissimi approcci diversi alla realizzazione dei progetti. Consiste nel prendere elementi di alcune metodologie di project management (spesso il metodo a cascata o una delle metodologie agili) e adattarle alle esigenze del tuo progetto.
E questa idea di ibridare o personalizzare il proprio approccio progettuale non è affatto così rara o "criminale" come alcuni vogliono far credere. Infatti, uno studio recente di ProjectManager.com ha riportato che il 60% dei professionisti intervistati utilizzava un approccio ibrido o un mix personalizzato di diversi stili.
Ma, prima di andare oltre, allineiamoci sulle basi.
Cosa sono le metodologie di project management?
Le metodologie di progetto sono strutture o sistemi composti da pratiche, tecniche, regole e processi specifici che regolano il tuo progetto e la sua gestione. Generalmente includono attività, principi o standard fondamentali nei diversi stadi del progetto come la fase di avvio, la pianificazione, l’esecuzione, il monitoraggio e la chiusura del progetto.
Esistono apparentemente infinite opzioni quando si tratta di scegliere una metodologia di project management, ma tutte possono essere suddivise, in generale, in due categorie: metodi predittivi come il waterfall e metodi adattivi come l’agile, che comprende diversi rami e framework, tra cui ad esempio Scrum e Lean.
Mi concentrerò sui due grandi protagonisti che vengono nominati continuamente parlando di project management digitale: waterfall, un approccio tradizionale basato sulle dipendenze che funziona meglio quando la prevedibilità è fondamentale, e Scrum agile, il celebre framework a sprint indicato per progetti che richiedono agilità e capacità di navigare nell’incertezza con rapidità.
Perché? Perché, nonostante Scrum sia considerato la scelta più sensata per molti team digitali e il metodo waterfall abbia spesso una cattiva reputazione di essere superato, rigido e irrealistico, la realtà è che entrambe le metodologie agile e waterfall hanno benefici specifici e contesti progettuali per i quali sono particolarmente indicate.
Come potrebbe essere una metodologia ibrida?
La realtà è che molti team di progetto digitali e molte organizzazioni credono di aver adottato una sola metodologia, ma in realtà ne stanno utilizzando una miscela per portare avanti i loro progetti. Per comodità, chiamiamoli “ibridi accidentali”.
Ad esempio, suddividere semplicemente il lavoro in sprint di sviluppo di due settimane e fare un incontro quotidiano di aggiornamento non ti rende automaticamente un team Scrum. In realtà, è più simile a prendere in prestito solo alcuni elementi di Scrum per aumentare la comunicazione, il senso di urgenza e lo spirito di iterazione.
Allo stesso modo, il fatto di avere date di traguardo precise con dipendenze note tra le attività non significa che il waterfall sia l’unica opzione possibile. Molti team Scrum gestiscono il backlog e fanno pianificazione degli sprint per fornire determinati output entro date di scadenza specifiche.
In generale, ci saranno elementi di metodologie diverse che possono risultare vantaggiosi per uno specifico progetto o organizzazione. Ci saranno anche elementi di altre metodologie che invece potrebbero limitare la capacità del progetto di raggiungere i propri obiettivi. È qui che entra in gioco la creazione di una metodologia ibrida o personalizzata.
Ma come si presenta davvero una soluzione di questo tipo?
Per rendere la cosa più concreta, ipotizziamo che il tuo progetto coinvolga organizzazioni partner che richiedono che i requisiti siano completamente definiti e approvati fin dall’inizio prima che possa essere costruito qualsiasi elemento. Nel frattempo, i tuoi stakeholder sono preoccupati di dover attendere la fine del progetto per vedere il risultato finale per la prima volta.
Con un approccio Scrum, potresti placare le preoccupazioni degli stakeholder riguardo alla “scatola nera” attraverso le revisioni di sprint e una cultura di squadra basata sulla realizzazione di un output potenzialmente distribuibile ad ogni sprint. Tuttavia, Scrum in genere non favorisce la raccolta dei requisiti anticipata che è invece necessaria dai tuoi partner.
Con un approccio a cascata, potresti ottenere e far approvare tutti i requisiti all'inizio, e magari pianificare delle demo per gli stakeholder durante lo sviluppo. Tuttavia, non avresti un modo efficace per gestire nuovi requisiti che emergono dai feedback degli stakeholder.
Una possibile opzione potrebbe essere suddividere il progetto in fasi, ciascuna delle quali affronta un componente della soluzione. I requisiti completi di ogni componente verrebbero raccolti preventivamente, approvati e poi sviluppati prima di passare alla fase del componente successivo.
Visivamente, potrebbe apparire così:

Ma potresti anche voler progettare un approccio ibrido che prenda il “meglio” di ciascuna metodologia che stai considerando.
Ad esempio, potresti prendere la raccolta dei requisiti anticipata da un approccio a cascata ed eseguire poi lo sviluppo utilizzando sprint e cerimonie in stile Scrum che permettano agli stakeholder di fornire feedback nel product backlog, dove le organizzazioni partner potrebbero esaminare i nuovi requisiti come richieste di modifica.
Questo potrebbe apparire più come segue:

Metodologie di Gestione Progetti Ibrida come Transizione verso l’Agile
Le metodologie ibride possono essere anche una grande fase intermedia mentre la tua organizzazione o il tuo team si sposta verso una modalità di lavoro agile.
Non sempre è facile implementare subito o completamente gli approcci agili nelle organizzazioni, figuriamoci su larga scala. Implementare l’agile richiede un cambiamento su tutta l’organizzazione sia nelle operazioni che nella cultura, e ci sono molti altri fattori coinvolti. Gli approcci agili non si sposano necessariamente con clienti che vogliono elementi come ambito progetto, budget e tempistiche definiti all’inizio (anche se questo può essere risolto attraverso un contratto agile).
Con le difficoltà nell’implementare le metodologie agili, una transizione diretta e senza attriti verso la delivery agile è molto difficile per molte organizzazioni. Ci sono molti fattori che rendono complicata l’implementazione:
- Un alto livello di coinvolgimento dei clienti può essere d’intralcio al processo agile e interrompere fasi di sviluppo accuratamente pianificate, o lo svolgimento degli sprint
- Una generale mancanza di comprensione di cosa sia l’agile e di come possa essere usato per un dato tipo di progetto
- Potresti avere una storia di utilizzo di un approccio a cascata o di un’altra metodologia predittiva con il cliente, il che potrebbe generare esitazioni per paura di compromettere la relazione
È più semplice effettuare una transizione graduale verso l’adozione dei principi agili o del processo Scrum. Questa situazione richiede un approccio ibrido, che può essere una soluzione più realistica, almeno durante la transizione.
Ecco un esempio su come potresti adattare le tue pratiche di pianificazione dei progetti per essere più agili utilizzando un approccio ibrido.
Supponiamo che tu sia un’agenzia digitale che da decenni serve i clienti usando un approccio a prezzo fisso e in stile cascata. I clienti in genere sapevano sempre cosa aspettarsi, quando e quanto sarebbe costato.
Un giorno, comunichi ai tuoi clienti che stai passando a modalità di lavoro agili per agenzie, facendo subito scattare un campanello d’allarme per timore che dopo 7 sprint non ottengano ciò che volevano, con possibili costi aggiuntivi e sforamenti di tempi.
Per rendere la transizione più fluida, potresti decidere che il tuo prossimo incarico utilizzerà requisiti fissi consegnati tramite sprint in giorni specifici. Magari la raccolta dei requisiti ad alto livello avviene all’inizio, seguita da una pianificazione più dettagliata prima dell’avvio del prossimo sprint.
Dopo, nell'ingaggio successivo, potresti rivedere con loro il processo di gestione delle richieste di modifica e portarli dalla tua parte sull'idea che le modifiche dovrebbero essere integrate nel processo tramite revisioni di sprint e la ri-prioritizzazione del backlog (questo è qualcosa che l’IA nella gestione del backlog può aiutare a fare), riducendo il tempo dedicato alla raccolta completa dei requisiti a monte.
Poi, dopo alcuni altri ingaggi, potresti essere quasi completamente agile, con i tuoi clienti che comprendono il valore dell'acquisto degli sprint come modalità per essere flessibili, ora che si sono allontanati da una mentalità di diffidenza e dal dover avere tutto chiaro all'inizio, abbracciando più una mentalità di promotori del valore e dei risultati insieme al tuo team.
Ma penso che il filo conduttore e l’aspetto più importante in tutti questi esempi sia questo: creare un approccio ibrido è meglio se fatto deliberatamente. Invece di cominciare con un approccio “puro” per poi fare delle eccezioni strada facendo, parti con l’intento di realizzare un approccio su misura o ibrido che sia un abito su misura per il tuo progetto.
Impara a Combinare le Metodologie di Progetto nel Modo Corretto
Scopri il nostro mini corso su Personalizzazione dell’Approccio di Progetto. Otterrai:
- Un approfondimento di 40 minuti sulle metodologie ibride e sul processo di personalizzazione
- Un kit di strumenti per la personalizzazione della metodologia di progetto
- Un modello per documentare il tuo approccio di progetto personalizzato
Quali progetti sono più adatti alle metodologie ibride?
Non si tratta esattamente di una questione legata a particolari tipi di progetto, bensì di determinate situazioni o circostanze attorno ai progetti che potrebbero far sì che il tuo progetto sia adatto a una metodologia ibrida.
Ecco alcune situazioni in cui potresti utilizzare una metodologia ibrida.
- Forse il tuo team di sviluppo software vuole utilizzare gli sprint, ma il cliente non è autorizzato a prendere decisioni al volo durante le cerimonie Scrum, il che rallenta drasticamente il vostro slancio.
- Forse il tuo team si trova a proprio agio con un approccio tradizionale alla gestione progetti come il waterfall, ma il tuo prodotto presenta troppe incognite. Puoi tentare di fare un piano sequenziale perfetto che predica il futuro fino alla data esatta di consegna, ma se stai realizzando qualcosa di molto ambiguo, potresti non conoscere tutti i passaggi e quanto tempo richiederà ciascuno.
- Forse il tuo team vuole lavorare con iterazioni incrementali, ma il progetto ha alcuni requisiti normativi che complicano leggermente la rapidità di rilascio degli incrementi di prodotto a causa di lunghi processi di audit di progetto, o anche solo su scala ridotta.
- Forse il tuo team agile segue Scrum, ma il tuo fornitore opera secondo il Kanban (scopri le differenze tra Kanban e Scrum qui)
- Forse il tuo team di sviluppo ha sprint di tre settimane, ma il tuo team di design ha sprint di due settimane.
Quali sono i vantaggi delle metodologie di gestione progetti ibride?
Perché qualcuno dovrebbe investire tempo per adattare o ibridare il proprio approccio di progetto?
- Può sfruttare e combinare i vantaggi di due metodologie diverse, come ad esempio la velocità e la prevedibilità. Supponiamo tu voglia combinare il mindset di creare prodotti potenzialmente distribuibili in sprint di due settimane, ma hai uno sponsor di progetto che preferisce essere meno coinvolto. Potresti inserire più sprint tra alcune tappe di revisione formali durante il tuo ciclo di vita del progetto.
- Può fornire una base familiare anche in presenza di vincoli speciali. Ad esempio, se il team di progetto è abituato a Kanban, ma hai elementi specifici che devono essere consegnati a date prefissate affinché un ente regolatorio possa esaminarli, potresti aggiungere delle milestone in un flusso altrimenti continuo.
- Può essere usato per costruire fiducia dove c’è incertezza. Per esempio, se il tuo cliente non crede che un approccio agile possa garantire un determinato ambito, potresti prevedere una fase preliminare di discovery per delineare la soluzione prima di immergerti nelle iterazioni agili. Suggerimento: usa queste domande per la sessione di discovery per rendere l’esercizio utile.
- È un ottimo modo per iniziare a esplorare nuovi modi di lavorare come organizzazione. Potresti decidere di avere una metodologia ibrida su misura per categorie o livelli specifici di progetti, o anche semplicemente una metodologia personalizzata di fatto per tutti i progetti dell’organizzazione.
- Quando le persone iniziano a prendere parte a discussioni sulle metodologie di progetto, la loro comprensione di come vengono realizzati i progetti si approfondirà. Forse apprezzeranno anche un po’ di più il tuo ruolo come project manager.
- Una metodologia su misura può diventare un elemento distintivo e competitivo per il tuo team o la tua organizzazione. Se riesci ad adattare con successo il tuo approccio rispondendo ad una nicchia, come ad esempio strumenti digitali per aziende junior di esplorazione mineraria (e per cui puoi utilizzare software di project management per il settore minerario), diventi più attraente rispetto ai tuoi competitor. Semplicemente evolvere il proprio modo di lavorare può già differenziarti da chi adotta approcci più statici.
Sfide nelle Metodologie Ibride
Quando definisci il tuo processo ibrido, ci sono alcune sfide comuni a cui prestare attenzione.
Cultura di Team Sbagliata
Devi assicurare adattabilità all’interno del team e tra gli stakeholder, oltre ad avere un team e un gruppo di stakeholder altamente competenti. Sono persone che sanno fare bene il loro lavoro anche se i parametri cambiano.
Inoltre, devi avere una solida storia di comunicazione efficace con tutte le parti coinvolte. I team lavoreranno in modo nuovo e dovranno collaborare e condividere informazioni in modo efficace per tenere il progetto sulla buona strada.
Cultura Organizzativa Sbagliata
Anche una cultura organizzativa flessibile e pronta a gestire il cambiamento è fondamentale. Tutti devono essere disposti ad accettare un po’ di compromesso metodologico per far sì che il progetto abbia successo. I framework e gli approcci più diffusi hanno ciascuno i propri benefici intrinseci e le proprie efficienze.
Appena inizi a sostituire delle parti, però, inizi anche a compromettere il design originale. È un po’ come modificare il circuito del tuo iPhone per avere un caricabatterie USBC.
Quando i team sono isolati, polarizzati o non hanno esperienza nel lavorare efficacemente fuori dalla loro zona di comfort, questi non sono buoni ingredienti per un approccio di progetto modificato. Inoltre, se il tuo obiettivo è solo accontentare uno stakeholder, forse vale la pena fermarsi un attimo. Cercare di soddisfare chi fa più rumore senza una strategia può compromettere la tua capacità di portare a termine il progetto con successo.
Mancanza di Processo o Struttura
Un approccio ibrido al project management non significa "facciamo come ci pare". Devi comunque fornire delle linee guida al team ed essere strategico su come e perché personalizzi la metodologia.
Invece di seguire qualcosa, si finisce per fare l’esatto contrario e non avere nulla di definito. Il progetto diventa caotico perché manca un metodo di lavoro reale. Se i membri del tuo team non sanno davvero come dovrebbero lavorare, potrebbero partire per la tangente e non concentrarsi su ciò che andrebbe fatto.
D’altro canto, evita di inserire processi solo per il gusto di aggiungere processi. Non occorre inserire documentazione inutile senza ragione. Mantieni il processo snello quanto più possibile.
Il Rischio del "Taglia Unica"
Attenzione all’approccio "taglia unica". L’idea che ciò che ha avuto successo una volta funzioni sempre è pericolosa. Assicurati di considerare ogni progetto come un’entità a sé stante. Deve esserci coesione nei processi a livello organizzativo, ma ogni progetto è diverso e va trattato di conseguenza.
Mancanza di Coinvolgimento del Team
Il tuo team potrebbe pensare che il tuo ibrido sia solo una metodologia che si finge un’altra, come se fosse un’etichetta di marketing più che una reale descrizione. Assicurati di motivare la tua decisione.
Per questo è importante documentare la tua razionalità. Inoltre, ripresenta i vantaggi di ogni approccio nel contesto specifico del tuo progetto. Ciò che conta è fare ciò che è giusto per il team e per il progetto, quindi spiega chiaramente come può essere vantaggioso per loro.
Ad esempio, se non puoi utilizzare un approccio di gestione dei progetti agile, spiega cosa succederebbe se il progetto fosse agile e chiarisci cosa dovrebbe cambiare affinché il progetto possa supportare l’agile.
Come combinare i metodi di project management per creare un approccio ibrido
Ecco i passaggi per creare o scegliere una metodologia di project management ibrida e assicurarti che venga utilizzata in modo efficace.
1. Considera obiettivi e contesto del progetto
Per iniziare, siediti con il tuo team e i principali stakeholder per comprendere, stabilire le priorità e classificare ciò che è più rilevante per il tuo nuovo progetto.
Ecco alcuni esempi (questa non è una lista esaustiva!):
- Velocità: È necessario che questo progetto sia completato rapidamente o in maniera flessibile? Dobbiamo avere la possibilità di cambiare direzione?
- Costo: Vogliamo farlo nel modo più economico e semplice possibile?
- Qualità: Puntiamo a farlo perfetto già al primo tentativo?
- Conformità: Ci sono processi di revisione esterni che influenzeranno il nostro modo di lavorare?
- Coinvolgimento del cliente: Quanto è importante ricevere feedback dagli utenti finali durante il percorso?
- Innovazione: Lo scopo di questo progetto è fare qualcosa di diverso dal solito e innovare? Oppure è più importante avere prevedibilità in termini di date, requisiti e funzionalità fisse?
Dopodiché vale la pena considerare il contesto del progetto. Anche qui, non si tratta di un elenco esaustivo:
- Quanto è complessa la composizione del team? Il gruppo è pronto a lavorare fuori dalla propria zona di comfort?
- Qual è la cultura dei team e delle organizzazioni coinvolte? C’è collaborazione? Sono organizzati a compartimenti stagni? Sono flessibili o rigidi?
- Quanto sono stabili i requisiti? Rimarranno invariati o è molto probabile che cambino?
- Abbiamo requisiti normativi da considerare o altri partner coinvolti?
- La cosa che stiamo realizzando può essere iterata in qualche modo?
- In termini di dipendenze, dipendiamo da altri progetti o altri progetti dipendono da noi?
- Avremo accesso diretto a stakeholder e utenti?
- Quali metodologie sono già state utilizzate con successo in passato?
2. Scegli una metodologia come punto di partenza
Avere un punto di partenza fornisce a tutti una base di riferimento comune. Ma non tutte le metodologie sono uguali.
Ad esempio, Scrum è ottimo per consegnare in iterazioni, coinvolgere il cliente e fallire rapidamente e in anticipo. Se dovessi sviluppare un’app innovativa per un settore emergente, probabilmente prenderei in considerazione Scrum. Tuttavia Scrum non è sempre ideale per settori altamente regolamentati, progetti a scopo fisso, o organizzazioni lente/burocratiche.
La gestione dei progetti di tipo waterfall è eccellente per la prevedibilità e per fissare aspettative su date e risultati specifici. È anche adatta laddove ci siano interdipendenze e per progetti con budget fissi e risultati ben definiti.
Ma la metodologia waterfall non è adatta a gestire cambiamenti in corso d’opera (che manderebbero fuori fase il tuo diagramma di Gantt), a ottenere feedback frequenti e precoci, né all’efficienza in termini di creazione della documentazione. Se quindi lo sponsor non sa esattamente cosa desidera, il metodo waterfall potrebbe non essere la scelta migliore.
Ora che hai creato la tua lista breve, come ridurla a uno o due metodi? Esistono moltissimi strumenti e approcci per farlo. L’importante è che usi gli obiettivi e il contesto del tuo progetto per guidare la decisione.
3. Decisione di squadra
Una volta scelto il punto di partenza, è ora di indossare il cappello del design operativo e iniziare a prendere alcune decisioni insieme al team.
Valuta ciascun componente della metodologia scelta:
- Quali componenti della metodologia funzioneranno e quali no per il tuo progetto specifico.
- Cosa richiede una sostituzione da un’altra metodologia oppure una modifica per adattarsi meglio ai parametri del tuo progetto?
- Cosa manca; cosa occorre aggiungere?
Supponiamo che tu decida che planning poker e burndown chart basati sulla velocità non siano utili per i clienti, quindi li sostituisci con stime più tradizionali in termini di denaro e ore.
Potresti anche decidere che i daily stand-up mettono troppo sotto pressione i team che lavorano su progetti contemporanei, quindi li modifichi facendo sì che avvengano solo una volta a settimana.
Il processo di modifica e sostituzione può diventare rapidamente più complicato, quindi procedi con intenzionalità e cura. Alcune delle domande che dovresti porre al tuo team, ai tuoi stakeholder e a te stesso includono:
- Cosa deve succedere e quando?
- Come devono essere condivise le informazioni tra stakeholder e membri del team?
- Come devono essere consegnate e revisionate le cose?
- In che modo le persone dovranno partecipare e interagire?
- Quali strumenti e template sono appropriati e quali hanno bisogno di essere raffinati?
Successivamente, testa questa soluzione nella pratica. Ecco alcune idee:
- Organizza una sessione di pre-mortem per i team leader in modo che possano trovare criticità nel tuo approccio.
- Organizza una sessione di simulazione di ruolo. Passa insieme attraverso un ciclo di progetto o un incremento per vedere come va.
- Inizia in piccolo, fai una sperimentazione pilota e raccogli feedback continui lungo il percorso.
Durante queste attività, assicurati di definire come misurerai il successo o il fallimento.
Per i progetti a maggiore complessità, documenta la tua logica, traccia il tuo nuovo flusso di lavoro, valuta i rischi legati al cambiamento e crea un outline di un playbook che ti aiuterà ad ottenere buy-in e a formare le persone coinvolte nel tuo progetto.
4. Raduna le persone
La cosa più importante qui è che le persone comprendano il concetto e la logica alla base, e che abbiano a disposizione un documento chiaro e utilizzabile come riferimento.
Inizia creando il playbook e includi un breve riassunto facilmente assimilabile che comunichi il metodo alle persone. Quindi, condividi l’approccio e la logica con i responsabili di team, presentalo al tuo sponsor o al cliente e coinvolgi gli stakeholder chiave. Infine utilizza il documento per supportare l’onboarding del team e dei fornitori.
Tratta il playbook come un documento vivente e monitora le modifiche lungo il percorso per poter condurre un significativo post-mortem del progetto una volta concluso.
5. Misura e migliora
Hai appena creato qualcosa di nuovo. Non è testato sul campo come le metodologie già consolidate, e i parametri del tuo progetto sono abbastanza unici da averti portato a personalizzare un metodo sin dall’inizio.
Come puoi sapere se il tuo metodo ibrido sta funzionando?
- Abitua il team e gli stakeholder a confrontarsi regolarmente per ottenere feedback informali e aneddotici. Come percepiscono l’andamento?
- Affianca a questo dei feedback strutturati tramite sondaggi periodici durante il progetto
- Assicurati di monitorare sempre i tuoi KPI e i criteri di successo
- Organizza una retrospectiva di progetto e documenta le lezioni apprese
Esempi di metodologie ibride per la gestione progetti
Ecco alcuni esempi di modelli ibridi già diffusi nel mondo della gestione progetti, che potresti già conoscere.
- Scrumban, che tipicamente aggiunge incontri di routine e struttura a un flusso in stile Kanban altrimenti continuo.
- Water-Scrum-Fall (o water-agile-fall), in genere un processo iterativo che prevede fasi prevedibili di tipo waterfall all’inizio e alla fine. In altre parole, un sandwich di scrum.
- Wagile (o watergile), che prevede solitamente una fase iniziale di discovery e raccolta requisiti, seguita da una progettazione e sviluppo iterativi.
Cosa succede ora?
Procedi e inizia a personalizzare le tue metodologie! Se vuoi approfondire l’argomento, abbiamo disponibile un workshop nel nostro programma membri, oppure puoi leggere di un’altra metodologia ‘sandwich’ ibrida qui.
