---

In Blue, dedichiamo molto tempo a riflettere sul project management. È fondamentale per ciò che facciamo e per il successo di ciò che offriamo ai nostri clienti. Senza una solida comprensione del project management, come possiamo mai costruire software di project management?

Ogni volta che iniziamo un nuovo progetto, che si tratti di una nuova funzionalità, un aggiornamento dell'ingegneria backend, una campagna di marketing o una campagna di reclutamento, iniziamo analizzando il progetto stesso e come viene gestito. Pertanto, avendo una grande esperienza e intuizioni, abbiamo deciso di iniziare a formalizzare alcuni principi fondamentali del project management.

Sebbene sia comune (e accettabile) navigare un progetto utilizzando un approccio più informale e basato sull'istinto, è difficilmente un approccio scalabile — e non privo di svantaggi.

Un Progetto

Iniziamo definendo un progetto.

Un progetto è un'iniziativa temporanea con un inizio e una fine definiti per produrre un prodotto, un servizio o un risultato unico. Questo è come la maggior parte delle persone pensa ai progetti. Ma ci sono anche alcune altre proprietà più formali dei progetti che è importante considerare:

• Un progetto ha risorse finite (tempo, denaro, persone);
• Un progetto viene intrapreso per raggiungere obiettivi specifici;
• Un progetto ha un ambito definito (quindi ci sono chiaramente cose che non farà);
• Un progetto è soggetto a incertezze e rischi.

Ora che abbiamo una migliore comprensione di cosa sia un progetto, possiamo passare ai principi fondamentali — i blocchi costitutivi che un progetto richiede per avere successo. Questi includono:

• Un project manager;
• Un obiettivo;
• Un elenco di cose da fare — questo è spesso chiamato piano;
• Qualcuno assegnato a ciascuna cosa;
• Tempistiche per ciascuna cosa;
• Una strategia di comunicazione con una cadenza regolare di aggiornamenti e riunioni, e un piano per dove verranno memorizzate le informazioni.

Abbiamo scoperto che queste cose si applicano tipicamente a tutti i progetti e, se fatte bene, rimuovono il 99% di tutti i problemi all'interno dei progetti.

Un Project Manager

La prima cosa di cui un progetto ha bisogno è qualcuno responsabile del suo completamento con successo. Questo potrebbe sembrare un'affermazione ovvia, ma vale la pena sottolinearlo.

Questa persona è il project manager. È responsabile di garantire che gli obiettivi del progetto siano raggiunti e che il progetto venga completato in tempo, entro il budget e secondo gli standard di qualità richiesti. Spesso, molti di noi diventano project manager de facto senza essere un project manager formato. Se sei tu, allora sei fortunato, abbiamo scritto una guida per questo!

Vale la pena considerare cosa dovrebbe e non dovrebbe fare un project manager. Dopotutto, hanno molta responsabilità e devono prendere sul serio questa responsabilità.

Spesso, il project management può rappresentare una parte significativa del budget di un progetto — tipicamente tra il 2% e il 10%, a seconda di quanto sia rischioso il progetto. Maggiore è il rischio, maggiore è il project management necessario per garantire che le cose rimangano in carreggiata e il progetto non fallisca.

Poiché sono un manager, il project manager dovrebbe concentrarsi su come raggiungere gli obiettivi attraverso altre persone. Devono garantire che il team di progetto sia efficace e che stia lavorando insieme in modo armonioso verso l'obiettivo comune. Il project manager è colui che deve assicurarsi che tutti stiano facendo il proprio lavoro e che lo stiano facendo bene.

Il project manager è anche responsabile della comunicazione con gli stakeholder del progetto e di tenerli aggiornati sui progressi.

Proprio come abbiamo discusso in Prioritizzazione per i Leader, i project manager dovrebbero essere costantemente concentrati sul punto di vincolo. Se ottenere l'approvazione degli stakeholder richiede troppo tempo, allora devono concentrarsi intensamente su quel impegno. Devono costantemente chiedersi: “Cosa ci sta bloccando dal completare gli obiettivi del progetto e come posso sbloccare il problema il più rapidamente possibile?”

In un certo senso, il project management è sinonimo di comunicazione. Scrivere idee dettagliate è una competenza preziosa per un project manager, poiché riduce drasticamente il numero di riunioni richieste — i membri del team possono auto-servire le informazioni necessarie.

Un Obiettivo

Un altro blocco costitutivo fondamentale di un progetto è che il progetto ha bisogno di un obiettivo chiaro e misurabile. Una volta che il progetto è terminato, dovrebbe essere banale guardare i risultati e sapere se il progetto ha raggiunto i suoi obiettivi o ha fallito.

Gli obiettivi dovrebbero essere pubblicati in modo che ogni membro del team abbia accesso a essi. Questo è importante perché significa che il processo decisionale può essere distribuito e decentralizzato, poiché ogni membro del team può guardare al proprio piccolo pezzo di lavoro e collegarlo agli obiettivi generali del progetto. Poi, possono sollevare questioni se c'è un disallineamento o cambiare il loro approccio nella loro piccola area del progetto per servire al meglio gli obiettivi più ampi.

Gli obiettivi di un progetto dovrebbero essere SMART:

• Specifici. I progetti spesso hanno obiettivi di alto livello che suonano più come dichiarazioni di missione o visione. Un esempio di un obiettivo poco chiaro è “migliorare il supporto clienti”. Questo non è abbastanza specifico. Qualcosa come “Miriamo a rispondere via email al 90% dei clienti entro 30 minuti entro la fine del Q4” è molto più specifico.
• Misurabili. Quando si impostano obiettivi specifici, si risolve generalmente il problema della misurazione contemporaneamente, perché è facile valutare se l'obiettivo è stato raggiunto.
• Raggiungibili. Gli obiettivi hanno senso solo se possono essere raggiunti. Ma questo non è un pretesto per creare obiettivi facili. Un buon obiettivo dovrebbe avere un elemento di sfida — abbastanza impegnativo da poter essere raggiunto, ma non impossibile o altamente improbabile.
• Rilevanti. Questo potrebbe sembrare altamente ovvio, ma rimarrai sorpreso da quanto spesso ciò accade. Gli obiettivi del progetto dovrebbero essere raggiungibili attraverso il lavoro del progetto. Non puoi impostare obiettivi che non possono essere controllati dal team di progetto che sta svolgendo il lavoro specifico del progetto. Ad esempio, i team che lavorano nella divisione di produzione di una corporazione potrebbero non influenzare l'esperienza di acquisto in negozio dei clienti.
• Temporizzati. Buoni obiettivi devono avere un qualche tipo di tempistica associata. Questo può essere difficile, specialmente con i progetti software moderni in cui il lavoro da svolgere non è sempre chiaro, quindi le tempistiche possono essere estremamente difficili da stimare. A volte puoi essere lontano di molteplici fattori, e non è colpa di nessuno in particolare. Detto ciò, avere tempistiche assicura che l'ambito complessivo del progetto rimanga entro certi limiti. Se hai un mese per risolvere un problema rispetto a un anno, arriverai a soluzioni molto diverse.

Gli obiettivi devono essere ripetuti a tutti i membri del team ad nauseam: dovrebbero essere (figurativamente) stanchi di sentire il project manager discutere costantemente degli obiettivi. Alcuni dashboard in tempo reale (o il più vicino possibile al tempo reale) che tracciano i progressi possono anche essere inestimabili per garantire che tutti siano allineati verso gli obiettivi e sappiano come sta procedendo il progetto.

Un Elenco di Cose da Fare

Suggeriamo vivamente di chiamare un piano “un elenco di cose da fare”, poiché demistifica il processo di pianificazione.

I piani sono spesso supposizioni, ma sono comunque utili. Questo perché il processo di pianificazione stesso aiuta a far luce su ciò che sappiamo e su ciò che non sappiamo ancora.

Non pianificare significa pianificare di fallire.

L'essenza di un piano è ottenere un elenco dettagliato di tutti i passaggi per passare dall'inizio del progetto al suo completamento con successo. Alcune azioni richiederanno che i passaggi precedenti siano completati, e quindi potresti finire con una serie di attività collegate, spesso chiamate dipendenze. Altre azioni possono essere svolte in parallelo e non si bloccano a vicenda.

Il project manager dovrebbe sempre concentrarsi sulle azioni più importanti che bloccano altre azioni, poiché questo definisce ciò che è noto come il percorso critico del progetto. Cioè, il minor tempo possibile in cui il progetto può essere completato se tutte le dipendenze sono allineate una dopo l'altra.

Lavorare sul piano da entrambe le estremità del progetto può aiutare enormemente a costruire un piano efficace. Questo significa che inizi dall'inizio e vai fino alla fine, ma poi inizi anche dalla fine e lavori a ritroso per capire cosa è necessario per completare il progetto e raggiungere gli obiettivi.

Quest'ultima parte di inversione del processo di pianificazione porterà generalmente alla luce attività trascurate.

Ma, il processo di pianificazione non è completo fino a quando non comprendiamo chi è responsabile di ciascun compito e quanto tempo richiederà ciascun compito per essere completato.

Questi punti dovrebbero essere coperti simultaneamente perché sono così strettamente collegati. Non puoi creare stime per il lavoro senza coinvolgere gli esperti che conoscono i dettagli di quel compito, e anche in quel caso, devi comunque tenere d'occhio le tue risorse. Un individuo può raramente lavorare efficacemente su più cose contemporaneamente, quindi devi capire se il piano di progetto è probabile che abbia colli di bottiglia. Questo è quando una persona non può completare tutti i compiti assegnati perché semplicemente non ha abbastanza tempo disponibile.

Qualcuno Assegnato a Fare Ciascuna Cosa

Ogni compito in un progetto deve avere un individuo specifico a cui viene data la responsabilità di completare quel compito. Se scopri di aver bisogno di più persone assegnate allo stesso compito, spesso non sei andato a un livello sufficientemente granulare per distinguere i compiti.

Ad esempio, in molte industrie, ci saranno fasi di progettazione e costruzione; questo potrebbe essere nella produzione, costruzione o persino software. Dovresti suddividere questo in modo da poter assegnare i compiti specifici del designer e i compiti specifici del costruttore. Spesso troverai un andirivieni tra le due discipline, che puoi considerare. Un esempio potrebbe apparire così:

1. Fase di Progettazione 1 da parte dei Designer
2. Controllo di Fattibilità 1 da parte dei Costruttori
3. Fase di Progettazione 2 da parte dei Designer
4. Controllo di Fattibilità 2 da parte dei Costruttori
5. Revisione da parte di un Stakeholder Senior
6. Finalizzazione del Design da parte dei Designer
7. Controlli Finali da parte dei Costruttori
8. Approvazione da parte degli Stakeholder

Questo mostra un realistico andirivieni tra le diverse parti coinvolte, invece di avere una “Fase di Progettazione” assegnata solo al team di design fino al completamento della fase di design.

Tempistiche per Ciascuna Cosa

Questa potrebbe essere la parte più difficile della creazione di un piano — come misuriamo quanto tempo richiederà ciascuna cosa? Come discusso in precedenza, le tempistiche non dovrebbero essere fatte dall'alto verso il basso, ma dal basso verso l'alto. Questo significa che ogni elemento è stimato dalla persona che andrà a svolgere il lavoro (o almeno da un collega esperto) e che tutte queste stime vengono aggiunte e calcolate in una tempistica complessiva.

Detto ciò, è utile avere una tempistica generale di alto livello prima che vengano fatte le stime dettagliate, perché stimare quanto tempo richiederà qualcosa e decidere l'approccio specifico per risolvere il compito sono essenzialmente la stessa cosa.

Quindi, se un progetto ha tempistiche generose di alto livello, allora gli esperti individuali possono tenerne conto nelle loro stime e cercare di ottimizzare le soluzioni a lungo termine invece di tagliare angoli per garantire che le tempistiche siano rispettate. Se il progetto ha una tempistica affrettata, allora ogni esperto sa che potrebbe dover fare compromessi.

Una cosa spesso dimenticata durante la creazione dei piani di progetto è che gli stakeholder dovranno rivedere i progressi e confermare le decisioni che devono essere considerate. Il modo migliore per farlo è guardare al progetto precedente che include lo stesso insieme di stakeholder e capire quale sia un tempo di risposta tipico per fornire feedback.

Un altro pericolo qui è che se ci sono riunioni mensili del comitato di direzione con gli stakeholder chiave, cosa succede se un deliverable del progetto non può essere presentato in tempo per una di quelle riunioni? Il progetto va in pausa fino al mese successivo quando gli stakeholder si incontrano di nuovo, o verrà gestito e approvato (o restituito con feedback) nel frattempo tra i comitati di direzione mensili?

Una Strategia di Comunicazione

Quando sorgono problemi come questo, confermano che l'approccio alla comunicazione all'interno di un progetto è di massima importanza.

Di solito, il problema non è che ci sia una cattiva strategia, ma che non ci sia affatto una strategia. Così i canali di comunicazione si aprono in modo informale e ad hoc, e “abbastanza buono” diventa lo standard.

Il problema con questo è che le cose non vanno sempre secondo i piani. Le persone cambiano, le conoscenze si perdono, e man mano che il progetto cresce e sempre più persone si uniscono, il sovraccarico di comunicazione può esplodere rapidamente.

Quindi, chiaramente, gli strumenti stessi non sono così importanti; è solo un dato di fatto che, man mano che si scala oltre un numero non banale di persone (diciamo, 10), il lavoro di squadra diventa sempre più difficile.

Questo perché la comunicazione del team non scala in modo lineare rispetto al numero di persone nel team.

Ad esempio, se hai un team di 2 persone, c'è un filo di comunicazione (tra i due individui). Aggiungi un'altra persona; ora hai tre fili di comunicazione. Quindi, mentre la dimensione del team è aumentata del 50%, i fili di comunicazione sono aumentati del 300%.

Vediamo come cresce:

• 2 membri del team = 1 filo di comunicazione
• 3 membri del team = 3 fili di comunicazione
• 5 membri del team = 10 fili di comunicazione
• 8 membri del team = 28 fili di comunicazione
• 10 membri del team = 45 fili di comunicazione
• 15 membri del team = 105 fili di comunicazione
• 20 membri del team = 190 fili di comunicazione
• 30 membri del team = 435 fili di comunicazione
• 50 membri del team = 1.225 fili di comunicazione
• 100 membri del team = 4.950 fili di comunicazione

Questo può essere espresso dalla seguente equazione:

n(n-1)/2

Dove n è il numero di persone che devono essere coinvolte nel progetto.

Come puoi vedere, questo numero cresce esponenzialmente man mano che aumenta la dimensione del team. Se hai un team di 10 persone, ci sono 45 potenziali fili di comunicazione da gestire. Ma se hai un team di 50 persone, ci sono 1.225 potenziali fili di comunicazione — che è 27 volte di più! E se hai un team di 100 persone, ci sono 4.950 possibili fili di comunicazione — che è 110 volte di più!

È importante notare che questo non è solo un problema con team più grandi, ma con qualsiasi team in cui gli individui non si trovano nella stessa posizione. Questo perché il numero di potenziali fili di comunicazione non è limitato dalla prossimità fisica dei membri del team.

Ad esempio, hai un team di 10 persone, ma si trovano tutte in diverse parti del mondo. In questo caso, ci sono comunque 45 potenziali fili di comunicazione da gestire — anche se i membri del team non sono fisicamente vicini tra loro.

E può peggiorare. Il calcolo sopra presuppone solo un metodo di comunicazione. Se vogliamo tenere conto di diversi metodi di comunicazione, dovremmo riscrivere l'equazione nel seguente modo:

n(n-1)/2

Dove n è il numero di canali di comunicazione.

Ritorniamo al numero di fili di comunicazione sopra, ma questa volta assumiamo che n sia composto da:

• Email
• Chat di Gruppo
• Chat Personale
• Commenti in un sistema di gestione progetti
• Chiamate
• Note/Commenti nei documenti

Inserendo i numeri, ecco cosa otteniamo:

• 2 membri del team = 6 fili di comunicazione
• 3 membri del team = 18 fili di comunicazione
• 5 membri del team = 60 fili di comunicazione
• 8 membri del team = 168 fili di comunicazione
• 10 membri del team = 270 fili di comunicazione
• 15 membri del team = 630 fili di comunicazione
• 20 membri del team = 1.140 fili di comunicazione
• 30 membri del team = 2.610 fili di comunicazione
• 50 membri del team = 7.350 fili di comunicazione
• 100 membri del team = 29.700 fili di comunicazione

È spaventoso quanto rapidamente cresca il numero di fili di comunicazione — e se il lavoro remoto consente più facilmente riunioni più grandi che non sarebbero pratiche nella vita reale, allora è una lama a doppio taglio.

Quindi, in breve, una strategia è cruciale per evitare l'esplosione comunicativa che può verificarsi anche con un numero relativamente ridotto di membri del team.

E mentre l'idea di una “strategia di comunicazione” può sembrare complessa e grandiosa, non deve esserlo. La cosa chiave è stabilire alcuni principi, dichiarare i canali di comunicazione chiave e forse anche dire alle persone cosa non fare.

Al alcuni principi fondamentali da considerare:

• Mantieni le informazioni aperte. Assumi che tutto debba essere facilmente reperibile e condivisibile mesi/anni da ora. Assicurati che tutti i membri del team di progetto abbiano accesso a tutte le informazioni necessarie e fai attenzione a nominare file e documenti tenendo conto di questo.
• Sii chiaro. Immagina che qualcuno di nuovo si unisca al team di progetto. Documenta le informazioni in modo chiaro e conciso per garantire che possano comprendere facilmente le decisioni critiche.
• Tieni i verbali delle riunioni. Assicurati che tutte le riunioni significative siano registrate e facilmente reperibili.

In termini di canali di comunicazione, meno ce ne sono, meglio è. Suggeriremmo di ridurli ai seguenti:

• Un software di gestione progetti per avere discussioni specifiche sui compiti.
• Riunioni (di persona o remote) con verbali e un luogo dove trovare tutti i verbali delle riunioni di progetto in un unico posto.
• Documenti: questo potrebbe includere commenti e discussioni all'interno di Google Docs o strumenti specifici (ad es. Figma per il design UX) che consentono commenti.

È anche accettabile aggiungere chat di gruppo a questo elenco — ma deve essere gestita con attenzione poiché può diventare una riunione enorme che dura tutto il giorno (e ogni giorno!) senza un obiettivo o un'agenda chiara.

Il project manager deve stabilire queste regole chiaramente e fungere da esempio luminoso su come collaborare, utilizzando occasionalmente un bastone (metaforico, non letterale!) per riportare i membri del team di progetto a comunicare correttamente.

Considerazioni Finali

Indipendentemente dal livello di esperienza, è sempre utile fare un passo indietro e vedere un argomento o un processo a livello fondamentale. Quindi, approfondendo il tema del project management, abbiamo identificato i principali principi fondamentali richiesti per eseguire con successo un progetto.

Ogni progetto dovrebbe avere un project manager: garantiscono che il progetto abbia obiettivi chiari, che vengono suddivisi in compiti da completare per raggiungere l'obiettivo finale. Il project manager deve quindi assegnare un membro del team a ciascun compito. Insieme, il team può identificare le tempistiche per ciascun compito individuale e per l'intero progetto.

Spesso sono le cose apparentemente ovvie a causare problemi, piuttosto che argomenti avanzati, che tendono a ricevere più attenzione — ad esempio, la comunicazione. Questo è il motivo per cui dovrebbe esserci una strategia di comunicazione ben definita sia all'interno del team di progetto che esternamente, con gli stakeholder.

Il project management è un argomento complesso, quindi questa non è affatto una guida esaustiva. Ci sono ancora alcuni fattori da considerare che non abbiamo coperto in questa panoramica iniziale, come budget, metodi per risolvere conflitti tra opzioni e fino a che punto portare la delega all'interno di un progetto.