Alternativa ad Asana per la pianificazione dei progetti

Dove la timeline di Asana smette di essere un cronoprogramma

La maggior parte degli articoli su un’alternativa ad Asana per la pianificazione dei progetti apre affermando che Asana non ha un diagramma di Gantt. Non è vero, e partire da una premessa falsa è un pessimo modo di aiutare qualcuno a scegliere uno strumento. Asana ha una vista timeline che disegna barre su un asse orizzontale, le collega con frecce, segna le milestone come rombi e, su richiesta, può evidenziare il percorso critico. Per una campagna, il lancio di un prodotto o un processo di selezione, è un modo perfettamente ragionevole di pianificare.

La domanda onesta è un’altra. Non se il diagramma esista, ma se dietro di esso ci sia un modello di pianificazione, cioè un insieme di regole che il sistema applica quando qualcosa si sposta. Un diagramma senza modello è l’immagine di un piano. Un diagramma con modello è un piano. La differenza si vede solo quando la realtà comincia a spingere contro le date, cosa che di solito succede alla terza settimana, non il giorno in cui il piano viene approvato.

Cosa fa bene Asana

Asana è davvero brava a rendere il lavoro visibile e a far sì che le persone agiscano di conseguenza. Le attività hanno responsabili, commenti e scadenze chiare, la timeline è facile da manipolare e le attività dipendenti si spostano quando il loro predecessore si muove. Le dipendenze sono descritte in un linguaggio che nessuno deve imparare, blocca ed è bloccata da, ed è per questo che i team adottano lo strumento in un pomeriggio. Per dieci persone che portano avanti una campagna di otto settimane, non è un compromesso, è esattamente la giusta quantità di strumento per il compito. Qualsiasi confronto che finga il contrario vende invece di consigliare.

Vale la pena notare dove si paga questa semplicità. Ogni capacità che Asana lascia fuori dalla timeline è una che avrebbe reso il prodotto più difficile da imparare, e per la maggior parte dei suoi utenti è il compromesso giusto. La domanda è cosa succeda ai team per cui non lo è.

Il momento in cui il piano smette di ricalcolarsi da solo

Il punto di svolta arriva in silenzio. Un fornitore conferma la consegna due settimane più tardi del previsto e il project manager sposta un’attività sulla timeline. Il successore immediato la segue, perché quel collegamento è compreso. Poi il manager nota che il collaudo di accettazione previsto dopo un periodo obbligatorio di maturazione di due settimane ora inizia troppo presto, perché l’intervallo tra quelle attività non è mai stato una regola, solo spazio vuoto su un diagramma. L’attività nel progetto vicino che doveva iniziare dopo questa consegna non si sposta affatto, perché i due progetti non sanno l’uno dell’altro. Mezz’ora dopo il manager sta trascinando barre a mano e confrontando le date con un foglio di calcolo.

Quello è il momento in cui un cronoprogramma smette di essere un modello. Il piano non è più qualcosa che il sistema mantiene, è qualcosa che una persona mantiene, e quella persona diventa l’unico punto di guasto. Ogni ripianificazione costa ore, ogni ora di ripianificazione è un’ora non dedicata al problema reale, e dopo la terza o quarta iterazione le persone smettono del tutto di aggiornare il piano perché lo sforzo non ripaga più. Un piano abbandonato è peggio di nessun piano, perché i report continuano a essere generati da esso.

Cinque segnali che hai superato la pianificazione di Asana

Nessuno di questi segnali riguarda la dimensione del team o il budget. Riguardano la forma del lavoro, ed è per questo che un team di ingegneria di dodici persone può incontrarli mentre un reparto marketing di sessanta non lo fa mai. Se due o più descrivono i tuoi progetti, il tuo vincolo è lo strato di pianificazione, non il numero di funzionalità.

Pianifichi in giorni lavorativi, non in giorni di calendario. Un’attività di cinque giorni che inizia giovedì dovrebbe finire il mercoledì successivo, e un giorno festivo nel mezzo dovrebbe spostare la fine di un altro giorno. Se le tue durate includono in silenzio i fine settimana, ogni stima porta un errore incorporato che si accumula lungo un piano di più mesi.

Alcuni intervalli del tuo piano sono fisica, non preferenza. Il calcestruzzo matura, i rivestimenti asciugano, scorre un periodo di validazione, scade un termine di preavviso, un ente ha trenta giorni per rispondere. Non sono attività che qualcuno esegue, sono intervalli che devono trascorrere tra due attività. I team senza un modo per esprimerli inventano attività segnaposto chiamate «in attesa di approvazione», il che inquina l’elenco delle attività e fuorvia ogni report costruito su di esso.

Il cronoprogramma di un progetto guida quello di un altro. Nel momento in cui una consegna nel progetto di infrastruttura condiziona l’avvio del progetto di migrazione, ed entrambi sono gestiti separatamente, qualcuno tiene quella dipendenza nella propria memoria. La memoria non invia notifiche e non sopravvive alle ferie.

Ti viene chiesto di quanto il progetto sia andato alla deriva rispetto al piano originale. Non quali siano le date attuali, ma come si confrontano con ciò che è stato approvato, e perché. Senza una baseline salvata la risposta onesta è che nessuno lo sa, e la versione che circola nella presentazione del comitato direttivo è una ricostruzione.

Il cronoprogramma ha bisogno di più di due livelli. Fasi che contengono tappe che contengono attività, con l’avanzamento che si somma automaticamente verso l’alto e date proprie a ciascun livello. Un elenco piatto con intestazioni di sezione sembra simile sullo schermo e si comporta in modo del tutto diverso quando il piano cambia.

I tipi di dipendenza e perché la loro semantica decide il piano

Una dipendenza non è una linea tracciata tra due barre. È una regola che il sistema applica ogni volta che uno dei due estremi si sposta, e il tipo di relazione è il contenuto di quella regola. È la parte che la maggior parte dei confronti tra strumenti salta, perché una tabella con un segno di spunta accanto a «dipendenze tra attività» nasconde la differenza tra un sistema che ridisegna le frecce e un sistema che ricalcola le date. Sia FlexiProject sia Asana supportano i quattro tipi standard, quindi la domanda interessante è cosa li circonda.

Cogliere bene la semantica non è precisione fine a sé stessa. Decide se un project manager risponde alla domanda «se questo slitta di una settimana, quando finiamo» in tre secondi guardando il diagramma, o in tre ore ricostruendo il piano. Dove più progetti competono per le stesse persone, questa differenza decide se la ripianificazione avvenga del tutto.

FS, SS, FF e SF nella pratica

Fine-inizio è il valore predefinito ovunque e copre la maggior parte del lavoro sequenziale: il muro va costruito prima di essere dipinto. Inizio-inizio descrive un lavoro che corre in parallelo da un trigger comune, per esempio la documentazione che inizia nel momento in cui inizia lo sviluppo e resta più o meno al suo passo. Fine-fine descrive un lavoro che deve concludersi insieme, come la formazione degli utenti che deve essere completa il giorno in cui il sistema va in produzione, indipendentemente da quando è iniziata. Inizio-fine è raro e appare soprattutto nei passaggi di consegne, dove il vecchio sistema può essere spento solo una volta che il nuovo è in funzione.

Chiunque costruisca cronoprogrammi seriamente userà almeno i primi tre, e le organizzazioni di progetto mature usano tutti e quattro per modellare la realtà con precisione invece di forzare tutto in una catena di collegamenti fine-inizio. Se desideri un percorso più approfondito con esempi svolti, abbiamo scritto separatamente sui tipi di dipendenze tra attività in un diagramma di Gantt.

Ritardo fisso: i giorni che devono semplicemente passare

In FlexiProject, ogni relazione può portare un ritardo fisso espresso in giorni. La dipendenza significa allora «inizia questa attività quattro giorni dopo la fine della precedente», e quei quattro giorni fanno parte della regola invece di essere un intervallo stimato a occhio sul diagramma. Quando il predecessore si sposta, il ritardo si sposta con lui, automaticamente e senza che nessuno ricordi che era lì.

L’effetto di business è che i vincoli tecnologici smettono di vivere nella testa delle persone. Un periodo di maturazione, una finestra di revisione normativa, una quarantena obbligatoria tra lotti di produzione o un termine di preavviso contrattuale diventa parte della logica del piano. Nessuno deve creare un’attività finta per tenere aperto lo spazio, nessuno deve spiegare a un collega perché due barre non vanno avvicinate, e nessuna ripianificazione può eliminare in silenzio un vincolo imposto dalla fisica o da un contratto. Nei progetti in cui una sequenza mancata significa rifacimento e non un’email in ritardo, questa è la differenza tra un piano di cui fidarsi e un piano da ricontrollare due volte.

Relazioni rigide: quando il collegamento non deve rompersi

FlexiProject distingue inoltre le relazioni rigide, contrassegnate nel pannello dell’attività da due anelli intrecciati. Una relazione rigida significa che l’elemento collegato non può essere trascinato a mano lontano dal suo predecessore. Il sistema non permetterà a un utente di rompere in silenzio la sequenza spostando una barra sul diagramma, il che suona restrittivo finché non hai visto un cronoprogramma degradarsi nel corso di sei mesi di aggiustamenti manuali ben intenzionati.

Questo conta soprattutto dove un cronoprogramma è un documento condiviso e non il file di una singola persona. In un progetto grande più persone modificano il piano, e ognuna ha un motivo locale per spostare qualcosa. Una relazione rigida codifica la differenza tra una sequenza che è un’ipotesi di pianificazione, e quindi aperta alla discussione, e una sequenza che è un vincolo rigido, e quindi no. Il project manager smette di sorvegliare il piano a mano e comincia ad affidarsi a esso, che è l’intero scopo di un software di pianificazione fin dall’inizio.

Le dipendenze tra progetti: lo strato che Asana non ha

All’interno di un singolo progetto, le dipendenze sono una comodità. Tra progetti, sono la differenza tra un programma e una cartella di piani scollegati. In FlexiProject una relazione può collegare un’attività di un progetto a un’attività di un altro, così che la consegna infrastrutturale che condiziona una migrazione è un collegamento che il sistema conosce e non una nota nel verbale di riunione di qualcuno. Quando la data di un lato si sposta, le attività dipendenti nell’altro progetto vengono ricalcolate e i loro responsabili notificati.

La conseguenza pratica appare nel processo decisionale, non sul diagramma. Prima di approvare una modifica in un progetto, un program manager può vedere come quella modifica si propaghi attraverso i progetti restanti, confrontare il cronoprogramma prima e dopo e giudicare il costo reale di un sì. Senza questo, il costo emerge settimane dopo come una serie di sorprese separate, ognuna delle quali sembra un problema locale e viene trattata come tale. I programmi pluriennali sono esattamente il punto in cui questo si accumula, perché una decisione di due settimane presa con leggerezza al terzo mese può spostare una data di go-live al ventesimo.

Tutte le attività di un programma sono inoltre visibili su un unico diagramma di Gantt condiviso, così che un program manager vede i collegamenti in un solo posto invece di ricostruirli dai report di stato. I team che ne hanno bisogno di solito lo scoprono nel modo duro, dopo aver prima provato a coordinare la stessa cosa con una riunione ricorrente. Se la tua organizzazione va in quella direzione, il nostro software per gestire i programmi di progetto spiega come sono strutturati i programmi.

Il modello sotto il diagramma di Gantt

Le relazioni sono la parte più visibile del modello di pianificazione, ma non sono tutto il modello. Altri quattro meccanismi decidono se un diagramma si comporta come un piano, e sono quelli che separano un software per diagramma di Gantt da un widget di timeline. Nessuno di essi è esotico. Sono tutti di quelle cose che ti mancano solo quando ne hai bisogno.

WBS illimitata e avanzamento che si somma da solo

I progetti di un’organizzazione variano enormemente per scala, da una vittoria rapida di due settimane a un investimento di capitale pluriennale, e un’unica struttura rigida non può servire entrambi. FlexiProject non pone limiti a quanto in profondità arrivi la struttura delle attività, così un progetto può essere suddiviso in fasi, tappe, attività e milestone fino a quanto serve. Un progetto piccolo può restare piatto con una manciata di attività, mentre un progetto di investimento può portare una struttura di scomposizione del lavoro a più livelli, ed entrambi usano la stessa interfaccia.

L’avanzamento si inserisce solo a livello delle singole attività. L’avanzamento di tappa e l’avanzamento complessivo del progetto sono calcolati automaticamente dalle attività sottostanti, così che nessuno debba ricordarsi di aggiornare gli aggregati prima che esca un report. Sembra una piccola comodità ed è in realtà un meccanismo di qualità dei dati: lo stato a livello di portfolio è derivato dagli stessi numeri che il team mantiene ogni giorno, e non da un riepilogo digitato in fretta la sera prima di un comitato direttivo.

Un calendario lavorativo invece di date di calendario grezze

Un cronoprogramma che conta i fine settimana come tempo di lavoro produce date sbagliate dal primo giorno. FlexiProject calcola le durate rispetto a un calendario lavorativo, così che un’attività espressa in giorni lavorativi atterri dove atterra davvero una volta considerati fine settimana e festività. La stessa logica sostiene i modelli riutilizzabili: le attività in un modello portano una durata in giorni lavorativi e un insieme di dipendenze invece di date fisse, così che inserire una data di inizio del progetto genera l’intero cronoprogramma automaticamente.

Per un’organizzazione che esegue progetti simili ripetutamente, è qui che il tempo di pianificazione crolla. Invece di ricostruire un piano da zero e riderivare ogni data, un project manager parte da una struttura approvata e regola ciò che è davvero diverso in questo caso. Il nostro modulo dei modelli di progetto esiste esattamente per questo schema, ed è anche il motivo per cui i modelli costruiti da un PMO esperto mantengono il loro valore per anni.

Baseline e scostamento dal piano

Una volta approvato un piano, FlexiProject lo salva come baseline. Il diagramma di Gantt mostra allora il piano originale accanto al cronoprogramma attuale, così che ogni scostamento è visibile subito invece di essere dedotto. Il sistema prevede anche la data di completamento del progetto rispetto a quella approvata, che di solito è l’unico numero che un consiglio di amministrazione vuole davvero.

Il valore qui riguarda meno la misurazione e più la qualità della conversazione. Un project manager che può mostrare cosa è stato approvato, qual è la situazione ora e quale decisione ha causato lo scarto è in una posizione diversa da chi può solo riferire le date attuali. La discussione si sposta dal se il progetto sia in ritardo al cosa fare della causa specifica, che è l’unica versione di quella conversazione che finisce in una decisione.

Percorso critico e margine

FlexiProject identifica il percorso critico automaticamente e lo segna in rosso sul diagramma di Gantt, così che un project manager sappia subito quali attività meritano attenzione. L’uso pratico è nel triage. Uno slittamento di due giorni su un’attività critica è uno slittamento di due giorni per l’intero progetto, mentre uno slittamento di due giorni su un’attività con dieci giorni di margine è rumore. Senza questa distinzione ogni ritardo viene escalato con la stessa urgenza, il che insegna a tutti a ignorare le escalation.

Con più flussi in parallelo, per esempio i lavori edili che corrono accanto al montaggio e alla documentazione, il percorso critico è ciò che impedisce a un manager di ottimizzare quello sbagliato. Se il concetto è nuovo per il tuo team, abbiamo trattato più a fondo cos’è il percorso critico e come gestirlo.

Le risorse sul diagramma di Gantt: tempo e capacità pianificati insieme

Un cronoprogramma che ignora chi è disponibile è una lista dei desideri. FlexiProject mostra il carico delle risorse direttamente dal diagramma di Gantt, così che un project manager veda a colpo d’occhio quali persone sono sovraccariche in un dato periodo e quali hanno ancora capacità. Le attività possono essere spostate lungo la timeline osservando il carico cambiare, il che trasforma la ripianificazione in una simulazione invece che in un’ipotesi: il piano è ottimizzato prima di essere approvato, non dopo che qualcuno si lamenta.

Questo colma una lacuna che si presenta di continuo nelle organizzazioni che portano avanti più progetti con le stesse persone. Pianificare un nuovo progetto significa sapere se gli specialisti di cui ha bisogno sono già impegnati altrove, e nella maggior parte delle aziende quel controllo avviene a mano, in un foglio di calcolo, con un ritardo abbastanza lungo da rendere la risposta obsoleta. Quando la capacità sta nella stessa vista delle date, il compromesso tra finire prima e sovraccaricare un team smette di essere invisibile finché qualcuno non si dimette.

I ritardi emergono con la stessa schiettezza. Le attività rimaste indietro sono evidenziate in rosso, così che aprire il progetto basta a vedere dove serve un intervento, senza generare prima un report. Per le organizzazioni che vogliono spingersi oltre e gestire la disponibilità sull’intero portfolio, il nostro software di gestione delle risorse gestisce il carico oltre il singolo progetto.

FlexiProject e Asana: le capacità di pianificazione a confronto

La tabella seguente è volutamente stretta. Copre solo la pianificazione e concede ad Asana ogni capacità che possiede davvero, perché un confronto che sottovaluta un concorrente è inutile per chi lo legge. Collaborazione, automazione dei flussi e integrazioni sono un altro discorso, e in diverse di esse Asana è il prodotto più forte.

Leggi la tabella come una descrizione di intenti e non come un punteggio. Asana è costruita perché chiunque possa pianificare senza formazione, e ogni capacità sopra che omette è una che renderebbe il prodotto più difficile da imparare. FlexiProject accetta un avvio un po’ più ripido in cambio di un cronoprogramma che tiene la forma sotto pressione. Quale compromesso sia corretto dipende interamente dal fatto che i tuoi progetti puniscano un piano impreciso.

Portare un cronoprogramma fuori da Asana senza perdere il piano

La parte meccanica di una migrazione richiede meno tempo di quanto la gente si aspetti. Un cronoprogramma si importa da un file Excel o da un file Microsoft Project, portando attività, responsabili, attributi disponibili e, dove presente, la struttura delle dipendenze, così che le organizzazioni sedute su anni di piani storici non debbano riscriverli. Le esportazioni vanno nell’altra direzione verso Excel, Microsoft Project XML, PDF e PNG, il che conta quando un appaltatore o un revisore insiste su un formato specifico.

La parte che merita davvero riflessione è la ristrutturazione. Un piano costruito in Asana è stato costruito sotto i vincoli di Asana, il che significa che i periodi di attesa sono probabilmente attività finte, la sequenza è probabilmente una catena di collegamenti fine-inizio e la struttura di fasi sono probabilmente intestazioni di sezione. Copiarlo fedelmente riproduce la limitazione in un sistema che non ce l’ha più. L’approccio migliore è prendere un progetto rappresentativo, ricostruirne la logica come si deve con i giusti tipi di relazione, ritardi fissi dove gli intervalli sono obbligatori e relazioni rigide dove la sequenza non è negoziabile, e usare il risultato come modello per tutto il resto.

Per il primo passaggio c’è una scorciatoia che vale la pena conoscere. FlexiProject può generare una bozza di cronoprogramma da una descrizione di obiettivi e requisiti del progetto, producendo attività, milestone, dipendenze e un diagramma di Gantt che un project manager poi modifica invece di costruire dal nulla. Non sostituirà il giudizio di un pianificatore esperto, ma elimina il problema della pagina bianca, dove la maggior parte degli sforzi di ripianificazione si arena. Per un percorso strutturato, abbiamo scritto su come costruire un cronoprogramma di progetto passo dopo passo.

Domande frequenti

Asana supporta tutti e quattro i tipi di dipendenza?

Sì. Asana supporta fine-inizio, fine-fine, inizio-inizio e inizio-fine, con fine-inizio come predefinito. Le affermazioni che Asana offra un solo tipo di dipendenza compaiono in vari articoli di confronto e sono superate. Le lacune significative nella pianificazione di Asana sono altrove: nei ritardi fissi, nelle relazioni rigide, nei calendari lavorativi, nelle baseline e nei collegamenti tra progetti.

Si può impostare un tempo di ritardo tra le attività in Asana?

No. Asana non consente di allegare un ritardo fisso a una dipendenza, così un intervallo obbligatorio tra due attività va rappresentato in altro modo, di solito con uno spazio vuoto sulla timeline o un’attività segnaposto. Entrambi gli espedienti si rompono appena il predecessore si sposta, perché nessuno porta con sé il ritardo. In FlexiProject il ritardo è una proprietà della relazione stessa ed è espresso in giorni.

Asana ha una baseline di progetto?

No. Asana non memorizza una versione approvata del cronoprogramma per il confronto, così non c’è modo integrato di vedere di quanto il piano attuale sia andato alla deriva rispetto a quanto concordato all’inizio. I team che ne hanno bisogno di solito tengono un’istantanea in un foglio di calcolo, che risponde alla domanda una volta e poi diventa obsoleta. FlexiProject conserva il piano approvato come baseline e lo mostra accanto al cronoprogramma attuale sul diagramma di Gantt.

Si possono collegare attività di due progetti diversi?

In Asana no. Le dipendenze restano all’interno di un singolo progetto, così una sequenza tra progetti va coordinata dalle persone invece che mantenuta dal sistema. FlexiProject consente una relazione tra attività appartenenti a progetti diversi, ricalcola le date dipendenti quando uno dei lati si sposta e notifica i responsabili interessati, che è il requisito di base per gestire un programma invece di un insieme di progetti paralleli.

FlexiProject è più difficile da usare di Asana?

Chiede di più all’inizio e di meno dopo. Asana è progettata perché qualcuno possa pianificare fin dal primo giorno, in parte lasciando fuori i concetti descritti in questo articolo. FlexiProject si aspetta che un project manager comprenda i tipi di relazione, i calendari lavorativi e le baseline, e in cambio mantiene il piano invece di chiedere a una persona di mantenerlo. I team con progetti semplici troveranno Asana più veloce. I team i cui progetti puniscono un piano inesatto di solito trovano il contrario.

Scegliere un’alternativa ad Asana per la pianificazione dei progetti non è davvero una scelta tra due strumenti. È una decisione su se i tuoi progetti abbiano bisogno di un piano che una persona mantiene o di un piano che un sistema mantiene, e questo dipende da quanto costa quando le date sono sbagliate. Se una data slittata significa una riunione riprogrammata, Asana è una buona risposta e aggiungere macchinari di pianificazione rallenterebbe solo il team. Se una data slittata significa appaltatori fermi, una finestra normativa persa, rifacimenti su una linea di produzione o una clausola di penale, allora il modello sotto il diagramma non è un dettaglio. È il prodotto.

Ciò che cambia con un modello di pianificazione completo è più piccolo di quanto suggerisca un elenco di funzionalità e più grande di quanto sembri. Le relazioni portano ritardi fissi, così che gli intervalli obbligatori fanno parte del piano invece della memoria di qualcuno. Le relazioni rigide reggono sequenze non aperte alla negoziazione. Le dipendenze arrivano tra i progetti, così che un programma si comporta come un programma. Un calendario lavorativo fa sì che le durate significhino ciò che dicono, una baseline rende visibile lo scostamento, e il percorso critico dice quali ritardi contano davvero. Separatamente sembrano rifiniture. Insieme sono la differenza tra ripianificare in minuti e ripianificare in un fine settimana.

Se vuoi vedere i due prodotti fianco a fianco sull’intero perimetro e non solo sul cronoprogramma, inclusi budget, rischi, project charter e governance di portfolio, abbiamo preparato un confronto dettagliato tra FlexiProject e Asana. E se i tuoi progetti stanno già spingendo contro i limiti descritti qui, il passo successivo più utile è prenderne uno, ricostruirne il cronoprogramma come si deve e vedere quanto lavoro manuale sparisce.