La migliore alternativa ad Asana per un project management office: sette compiti da assolvere

Quando un PMO supera Asana

Vale la pena essere precisi su cosa Asana fa bene, perché un PMO che diagnostica male il problema compra il sostituto sbagliato. Asana dà ai team un luogo condiviso per attività, responsabili, date, commenti e file. Si impara in fretta, non richiede un amministratore e le persone lo usano volontariamente, il che è un’asticella più alta di quella che supera la maggior parte del software aziendale. Per coordinare il lavoro all’interno di un team sono le proprietà giuste, e un confronto capacità per capacità nel confronto tra FlexiProject e Asana mostra dove i due strumenti davvero divergono.

Il punto di svolta arriva quando cambia la produzione stessa del PMO. Coordinare il lavoro risponde alla domanda di chi fa cosa ed entro quando. Governare un portafoglio, che nella maggior parte delle organizzazioni è il ruolo centrale del PMO, risponde ad altre domande: l’organizzazione sta finanziando le iniziative giuste, ciascuna ha ancora la sua giustificazione, il denaro e le persone impegnate su di esse sono disponibili, e cosa dire alla direzione. Queste domande non sono versioni più difficili della prima. Hanno bisogno di altri dati sotto, e uno strumento costruito attorno alle attività non li contiene.

La conseguenza è che il PMO diventa lo strato di compensazione. Ogni capacità che lo strumento non ha è coperta da una persona: qualcuno costruisce la vista di portafoglio, qualcuno nota il progetto che ha saltato la revisione, qualcuno riconcilia il budget con il sistema contabile. Nulla di ciò appare come costo di licenza, così spesso va avanti per anni prima che qualcuno lo conti, ed è per questo che un tracker di attività non basta a un PMO.

La settimana prima della revisione di portafoglio

La forma riconoscibile del problema è la settimana che precede la riunione di direzione. Qualcuno apre trenta o quaranta spazi di progetto uno per uno, copia uno stato dall’uno e una percentuale dall’altro e li incolla in una presentazione già obsoleta prima ancora che la riunione inizi. Gli stati stessi dipendono dal fatto che i project manager si ricordino di aggiornarli, così la vista di direzione non è mai più aggiornata dell’ultima persona che l’ha toccata.

Una governance che qualcuno deve sorvegliare a mano

La seconda metà del compito è l’applicazione. Un PMO non si limita a osservare i progetti, li tiene dentro un processo: un business case prima del finanziamento, una revisione prima della fase successiva, una modifica approvata prima che il perimetro cresca. I campi personalizzati e le regole di automazione possono registrare che un punto di controllo è avvenuto, ma nulla valuta se sarebbe già dovuto avvenire, così qualcuno deve notare il progetto passato in esecuzione senza una carta approvata. Su cinque progetti è una conversazione; su quaranta, distribuiti su più reparti, è un ruolo amministrativo a tempo pieno, ed è la prima cosa ad essere abbandonata quando il PMO è sovraccarico. A parte analizziamo che cos’è un vero controllo del budget di progetto.

Cosa deve fare un’alternativa ad Asana per un PMO

Una volta chiara la diagnosi, l’elenco dei requisiti si accorcia. Questi sette criteri sono quelli che separano un sistema di portafoglio da uno strumento di attività con una dashboard sopra, e ciascuno corrisponde a qualcosa che un PMO produce anziché a una categoria di funzionalità.

Insieme descrivono cosa un software per PMO deve coprire prima di poter portare la governance di portafoglio. Il resto dell’articolo li prende uno per uno, nell’ordine in cui un PMO li incontra nel corso di un anno. Vediamo anche cosa cercare quando si valutano app come Asana.

Ammissione: decidere quali progetti entrano

La prima cosa di cui un PMO è responsabile è la decisione su cosa entra nel portafoglio. Nella maggior parte delle organizzazioni questa decisione si prende con un misto di strategia, precedente e chi ha argomentato con più insistenza, e si difende dopo anziché prima. Uno strumento di attività non ha nulla da offrire qui, perché l’ammissione avviene prima che ci sia un progetto da seguire.

FlexiProject risolve questo con un modulo di punteggio dei progetti costruito sul modello proprio dell’organizzazione. Definisci i criteri che contano, che sia l’aderenza alla strategia, il rendimento atteso, l’esposizione al rischio o la disponibilità di risorse, assegni pesi e stabilisci la precisione richiesta delle risposte. Le idee vengono poi valutate sulla stessa base, e il PMO ha una classifica che può portare a un comitato di controllo senza affidarsi alla persuasione.

Due dettagli fanno la differenza tra un modello di punteggio che viene usato e uno abbandonato. Il primo è che ogni domanda di punteggio può essere indirizzata al proprio gruppo di valutatori. Le domande sulla complessità tecnica vanno agli architetti, quelle sulla redditività al controllo di gestione, quelle sull’esposizione legale all’ufficio legale, e il punteggio finale aggrega più pareri informati anziché una persona che tira a indovinare fuori dal proprio ambito. Il secondo è che il punteggio non si limita all’avvio. Un progetto può essere rivalutato durante l’esecuzione man mano che arrivano nuove informazioni, il che dà al PMO un meccanismo che spesso gli manca: un modo strutturato di fermare un’iniziativa che non merita più il suo budget, prima che consumi altri due trimestri.

Report di stato senza costruire slide

Report progettati una volta, aggiornati da lì in poi

FlexiProject divide questo in due meccanismi. Le revisioni di progetto automatizzate raccolgono lo stato dai project manager a una cadenza definita, così l’input arriva senza un giro di solleciti. Il generatore di report compone poi l’output da dati in tempo reale: qualsiasi report può essere progettato in un costruttore e copre progetti, attività, milestone, voci di budget, rischi, deliverable o modifiche al piano, filtrati secondo i criteri che la domanda richiede.

L’effetto pratico si vede sulle richieste estemporanee. Quando un membro della direzione chiede ogni progetto sopra un certo budget la cui milestone è slittata in questo trimestre, la risposta attuale è spesso un pomeriggio di export da più posti. Progettata una volta nel costruttore di report, quella domanda diventa un report permanente disponibile subito con dati aggiornati, e la prossima volta che la pongono non c’è lavoro. Un PMO che lo fa da un anno dispone di una libreria che copre gran parte di ciò che la direzione chiede regolarmente, che è il modo pratico di riportare lo stato dei progetti in modo più efficace senza aggiungere una riunione.

Quando il PMO smette di essere il collo di bottiglia del reporting

Il secondo cambiamento è strutturale. Nella maggior parte delle organizzazioni, ogni reparto chiede al PMO il proprio taglio dei dati: la finanza vuole i costi per categoria, fornitore e periodo, l’ufficio legale vuole i rischi legali riuniti da tutto il portafoglio, una divisione di produzione vuole solo i propri progetti. Ogni richiesta è un lavoro a parte, e il PMO diventa una coda.

Poiché i report sono progettati anziché compilati, ogni reparto può avere il proprio set. Il PMO li costruisce una volta e restano disponibili con dati aggiornati, esportabili in Excel per chi vuole continuare a lavorare sui numeri. La finanza legge i propri report, l’ufficio legale la propria lista di rischi, e il PMO smette di arbitrare l’accesso a informazioni che non gli appartengono.

Revisioni di portafoglio che vanno oltre i tre minuti per progetto

La revisione di portafoglio è dove la governance o avviene o va in scena. Una riunione di due ore che copre quaranta progetti, quindici dei quali con problemi reali, dà a ciascuno tre minuti. Non è una revisione. È una carrellata di slide con il quorum, e tutti nella stanza lo sanno.

Il meccanismo che corregge questo è la sintesi prima del dettaglio. Il software di portafoglio progetti presenta il portafoglio su un solo schermo: stato delle milestone, salute del progetto, scostamento di budget, avanzamento rispetto al piano. La direzione o il comitato di controllo individua in pochi secondi quali progetti hanno bisogno di una discussione vera, e quei progetti ricevono un formato più approfondito con tempo dedicato, mentre quelli in linea con il piano passano in un minuto. La riunione smette di essere una sequenza di report e diventa una sequenza di decisioni, e poiché il modulo di revisioni dei progetti pianifica la cadenza e attinge il materiale dai progetti stessi, la preparazione sparisce con essa.

Gate di fase e modifiche al piano che lasciano traccia

Un piano approvato a gennaio e un piano in vigore a giugno raramente sono lo stesso piano, e la differenza tra un portafoglio governato e uno che non lo è sta nel fatto che qualcuno possa dire come è cambiato. In uno strumento di attività, il piano diventa semplicemente ciò che è nell’istante, e il ragionamento vive nelle e-mail.

FlexiProject tratta una modifica al piano come un oggetto formale. Qualsiasi modifica significativa di date, budget o perimetro può essere sollevata come richiesta di modifica con una giustificazione di business, e la richiesta mostra il piano attuale e quello proposto uno accanto all’altro, incluso il diagramma di Gantt nel modulo di cronoprogramma del progetto, così il decisore vede l’entità di ciò che approva anziché leggerne una descrizione. La richiesta passa poi per un percorso di approvazione e, una volta approvata, diventa la nuova versione del piano. Ogni richiesta è archiviata, il che significa che il PMO può ricostruire anni dopo come un progetto si è evoluto e perché, che è esattamente ciò di cui un audit o un esercizio di lessons learned ha bisogno e quasi mai possiede. A parte spieghiamo come affrontare la pianificazione dei progetti che il sistema mantiene da sé.

La capacità delle risorse che il PMO può difendere

FlexiProject lo affronta come software di gestione delle risorse: modella la disponibilità per persona e per giorno, ferie e assenze incluse, e segnala quando il carico pianificato supera ciò che è disponibile in un dato periodo. È questo che recupera la situazione nota in cui uno specialista compare contemporaneamente nei piani di dieci progetti, ogni piano ragionevole preso singolarmente e la somma impossibile. Il carico è visibile direttamente dal diagramma di Gantt, così spostare un’attività nel tempo mostra subito l’effetto sulla capacità, il che rende la pianificazione una simulazione che il project manager esegue prima di approvare il piano.

Sopra il singolo progetto, il PMO ottiene una vista di tutte le risorse di progetto nei mesi successivi, suddivisa per struttura organizzativa. È questa vista che permette al PMO di dare una risposta difendibile a due domande che gli vengono poste regolarmente e a cui di solito risponde a istinto: impegnarsi o no sull’opportunità che è sul tavolo, e quando le assunzioni devono iniziare per gli impegni già presi. Per un PMO in un’organizzazione i cui ricavi dipendono dai progetti, questa vista è uno strumento commerciale, non una comodità di pianificazione.

Denaro e rischio sopra il singolo progetto

Due cose sono visibili a livello di portafoglio e invisibili progetto per progetto. Entrambe sono di solito responsabilità del PMO e nessuna delle due entra in uno strumento di attività.

Scostamento di budget con previsione a finire

Un campo con una cifra di budget non è gestione del budget. Gestire il budget di un progetto significa sapere, per riga, cosa era pianificato, cosa è stato speso e cosa dovrà ancora essere speso prima della chiusura del progetto. Il modulo di budget del progetto mostra questi tre valori con lo scostamento risultante, sul lato costi e sul lato ricavi, così per i progetti che generano ricavi il PMO vede il risultato finanziario previsto e non solo le spese.

Un registro dei rischi che il portafoglio può leggere

Un rischio in uno strumento di attività è un’attività con un’etichetta. In un sistema di portafoglio è un registro con valutazioni, responsabili, piani di risposta e storico, e ha un livello sopra il progetto. Il registro dei rischi di FlexiProject ha un livello di portafoglio: ogni portafoglio ha una propria scheda dei rischi che raccoglie i rischi di tutti i suoi progetti in un solo posto.

Ciò che questo fa emergere è la duplicazione. Tre project manager che gestiscono in modo indipendente lo stesso rischio fornitore impiegano il triplo dello sforzo e arrivano a tre conclusioni diverse, e nessuno lo vede perché ogni registro è completo nei propri termini. A livello di portafoglio, quel rischio riceve un responsabile e una risposta. I report sui rischi funzionano anche nell’altro verso: un team che avvia un nuovo progetto può estrarre i rischi registrati su progetti simili e partire dall’esperienza dell’organizzazione anziché da un registro vuoto e un’ora di immaginazione. Mostriamo inoltre come funziona la gestione dei rischi di progetto nella pratica.

Portare il tuo standard di PMO, non quello del fornitore

Una carta e una matrice dei rischi che si adattano a ciò che usi già

Il modulo di carta del progetto è assemblato da componenti senza programmazione, così il documento riflette la disposizione che l’organizzazione usa già. Più di uno standard di carta può esistere contemporaneamente: progetti di sviluppo con campi rilevanti per la R&S, progetti di marketing con differenziatori di mercato e canali, progetti di investimento con campi di tecnologia e ritorno, mentre un insieme di campi aziendali resta comune a tutti. I reparti non sono costretti a un documento di compromesso che non va bene per nessuno, cosa che di solito uccide la standardizzazione.

La matrice dei rischi funziona allo stesso modo. Le sue dimensioni si configurano durante l’implementazione, così un’organizzazione che lavora da anni con una valutazione tre per tre non è obbligata a passare a cinque per cinque solo perché il software lo presume. Le carte sono versionate e approvate elettronicamente, e una parte di ciascuna si compila da sola dal cronoprogramma e dal registro dei rischi, così il documento resta coerente con i dati sottostanti anziché invecchiare dal giorno della firma.

Percorsi di approvazione per area di lavoro

Le regole di approvazione sono raramente uniformi in un’organizzazione, e quasi mai in un gruppo di aziende. FlexiProject consente percorsi di approvazione dedicati per area di lavoro: un percorso di approvazione del budget distinto in una divisione di produzione, un percorso condiviso dove la condivisione ha senso, un percorso breve per i progetti operativi e uno più lungo per quelli strategici. Il PMO codifica le regole che esistono anziché negoziarle al ribasso verso un unico percorso che tutti tollerano.

C’è un beneficio secondario che i responsabili di PMO notano entro un anno. Quando la carta, i modelli, i percorsi di approvazione e i formati di revisione vivono tutti nel sistema, la metodologia smette di vivere nella testa di colleghi esperti. Un nuovo membro del PMO impara lo standard dell’organizzazione imparando lo strumento, e l’inserimento che prima richiedeva mesi si riduce notevolmente.

Rollout: livelli di licenza, lingue e hosting

Il primo è il modello di licenza. Il sistema di gestione dei progetti FlexiProject addebita l’accesso per ruolo anziché a testa. La maggior parte dei sistemi addebita una tariffa comparabile a tutti, il che significa che l’organizzazione paga una postazione intera per persone che aprono lo strumento per aggiornare le proprie attività e controllare uno stato. Offre tre livelli adeguati al ruolo reale: una licenza completa per project manager, membri del PMO, sponsor e decisori, una licenza standard per i partecipanti attivi che riportano l’avanzamento e collaborano alle attività, e una licenza gratuita per chi ha bisogno solo di visibilità sul proprio lavoro. Il PMO decide il mix, il che rende la copertura dell’organizzazione più ampia proporzionata anziché una negoziazione di budget.

Il secondo è la lingua. L’interfaccia è disponibile in 28 lingue e la documentazione utente in 11, il che conta per un PMO in un gruppo con controllate in più paesi. Uno standard e un sistema, con ciascuno che lavora nella propria lingua, spesso è la differenza tra un’adozione reale e un uso cortese ma nullo nelle sedi più piccole.

Il terzo è l’hosting. FlexiProject è disponibile on-premise accanto al cloud. Per le organizzazioni nei settori regolamentati, o con una policy interna su dove risiedano i dati, non è una preferenza ma la condizione per essere anche solo valutato.

Quando non è la risposta giusta per il tuo PMO

Un PMO che segue tre o quattro progetti senza budget formale e senza impegni esterni sulle date non ha ancora bisogno di governance di portafoglio, e introdurla aggiungerà processo senza aggiungere controllo. La raccomandazione onesta lì è tenere lo strumento di attività e tornare alla domanda quando il portafoglio crescerà.

E se il compito centrale del PMO è modellare budget di investimento e prevedere risorse su migliaia di persone in un contesto di investimento di capitale fortemente regolamentato, le piattaforme pesanti costruite esattamente per questo giustificheranno il loro costo di implementazione. L’argomento a favore di FlexiProject è più forte dove il PMO ha bisogno di governance, visibilità di portafoglio e reporting automatizzato senza un progetto di configurazione di più trimestri.

Come verificarlo in due settimane

Ricostruisci tre progetti reali, non progetti di esempio. Prendi un progetto grande con dipendenze, un piccolo progetto operativo e uno che è in difficoltà proprio ora, con i loro cronoprogrammi, persone e budget reali. L’attrito che incontri è l’attrito che incontrerai ogni settimana, e serve anche da formazione, perché chi impara il sistema sui propri progetti ricorda più di chi svolge un esercizio su dati inventati.

Poi esegui quattro test che puntano alla produzione stessa del PMO. Produci il report che costruisci di solito a mano e cronometralo. Tieni una revisione di portafoglio usando solo ciò che è sullo schermo, senza una presentazione preparata. Spingi una modifica al piano attraverso un percorso di approvazione e verifica che la traccia mostri poi cosa è cambiato e chi l’ha approvato. Assegna una persona già impegnata altrove e guarda se il sistema ti avvisa prima dell’approvazione del piano. Uno strumento che gestisce questi quattro gestirà il resto; uno strumento che li fallisce non sarà salvato dai campi personalizzati.

Domande frequenti

Asana è uno strumento di gestione del portafoglio progetti?

Non nel senso di cui un PMO ha bisogno. Asana è gestione del lavoro costruita attorno ad attività, progetti e collaborazione, con viste di portafoglio e obiettivi ai suoi livelli superiori. Quelle viste riassumono l’attività delle attività anziché governare un portafoglio rispetto a strategia, budget e gate di controllo, e dipendono dal fatto che i project manager tengano gli stati aggiornati a mano. Un sistema di portafoglio dedicato legge lo stato del portafoglio dai dati sottostanti.

Di cosa ha bisogno un PMO che uno strumento di attività non fornisce?

Sette cose in pratica: un punteggio di ammissione oggettivo, reporting su dati in tempo reale, una sintesi di portafoglio su uno schermo, gate e gestione delle modifiche applicabili, capacità a livello di tutta l’organizzazione, consolidamento finanziario e dei rischi sopra il progetto, e uno standard configurabile. Uno strumento di attività può avvicinarsi ad alcune con campi personalizzati, ma l’approssimazione è mantenuta dal PMO, non dal sistema.

I project manager possono continuare a lavorare come adesso?

In gran parte sì, ed è il principale fattore che determina il successo di un rollout. Il cronoprogramma è disponibile come lista di attività, diagramma di Gantt e board Kanban sugli stessi dati, così un project manager che lavora su una board può continuare a lavorare su una board mentre il livello di portafoglio resta coerente. Ciò che cambia è che l’avanzamento è riportato sulle attività e consolidato automaticamente, anziché digitato come percentuale a livello di fase.

Tutta l’organizzazione ha bisogno di una licenza a pagamento?

No. Sono disponibili tre livelli di licenza, e il livello gratuito copre le persone che hanno bisogno di visibilità sul proprio lavoro e di informazioni di base sul progetto. Nella maggior parte delle organizzazioni questa è una grande quota di utenti, il che mantiene il costo di coprire il team più ampio proporzionale a ciò che quelle persone ne ricavano.

Possiamo mantenere la nostra carta e la nostra matrice dei rischi attuali?

Sì, e vale la pena insistervi. La carta è costruita da componenti, con più standard di carta che possono coesistere per diversi tipi di progetto, e le dimensioni della matrice dei rischi si configurano durante l’implementazione. Un PMO non deve abbandonare una scala di valutazione che l’organizzazione comprende per adottare il sistema.

La ricerca della migliore alternativa ad Asana per un project management office comincia di solito come un confronto tra strumenti e si risolve in una domanda sul carico di lavoro dello stesso PMO. Se l’ufficio passa il mese a mettere insieme informazioni che esistono già, a sorvegliare gate a mano e a difendere decisioni sulle risorse a istinto, la capacità di cui ha bisogno non è una board di attività migliore. Sono un punteggio di ammissione che può portare a un comitato, report progettati una volta e aggiornati da lì, un portafoglio che legge in pochi secondi, modifiche che lasciano traccia, una capacità che può difendere, e tutto ciò che porta lo standard che l’organizzazione ha già affinato anziché la versione di un fornitore. Il modo affidabile di sapere se è la tua situazione è prendere due settimane, tre progetti reali e il report che temi di costruire, e guardare quanto il sistema ne produce senza di te.