Queste conversazioni sono importanti perché aiutano le persone a comprendere il valore potenziale del nuovo strumento. Ma quando ho iniziato a osservare ciò che doveva realmente accadere per primo, mi sono trovato davanti a qualcosa di interessante. La prima attività dell'implementazione era piuttosto semplice: diversi reparti aziendali dovevano preparare alcuni fogli di calcolo e inviarli al responsabile della nuova applicazione, affinché i dati potessero essere caricati sulla piattaforma.

È stato in quel momento che mi sono reso conto che, nonostante tutte le discussioni sulla tecnologia, alcune domande fondamentali di gestione del progetto erano ancora senza risposta. Chi avrebbe dovuto preparare ciascun file? Entro quando doveva essere pronto? Chi avrebbe verificato i dati prima dell'invio? Il fornitore avrebbe potuto iniziare a lavorare su un file mentre aspettava gli altri? Quanto tempo avrebbe richiesto il caricamento? Chi avrebbe controllato che le informazioni fossero state importate correttamente? E, forse ancora più importante, chi stava aspettando che quei dati fossero disponibili nella nuova applicazione ed entro quale data ne aveva bisogno?

Senza queste risposte, riuscivo a comprendere molte delle possibilità che l'applicazione avrebbe potuto offrire in futuro, ma non avevo ancora informazioni sufficienti per costruire una pianificazione iniziale affidabile o definire una prima versione dell'ambito del progetto. È stato allora che ho iniziato a pensare che, in alcune situazioni, forse stiamo confondendo la conoscenza tecnica con la conoscenza del progetto stesso.

Un Project Manager deve avere competenze tecniche?

Credo di sì, ma forse non nel modo in cui siamo abituati a immaginarlo. Un Project Manager che lavora in ambito tecnologico dovrebbe conoscere sufficientemente il contesto in cui opera per seguire le conversazioni e comprenderne le conseguenze. Se è prevista un'integrazione tra sistemi, dobbiamo capire quali sistemi vengono integrati e perché. Se serve un'API, dobbiamo comprenderne il ruolo all'interno della soluzione. Se è necessaria una migrazione dei dati, dobbiamo sapere da dove provengono quelle informazioni, chi ne è responsabile e cosa potrebbe impedire che la migrazione avvenga secondo quanto pianificato.

Se è necessario sviluppare o rendere disponibile un'API, per esempio, devo capire chi è responsabile di quell'attività, quali altre attività dipendono da essa, quando dovrà essere disponibile e cosa succederà al progetto in caso di ritardo. Allo stesso modo, se un fornitore ha bisogno di ricevere dei fogli di calcolo per caricare informazioni in una nuova applicazione, devo sapere chi preparerà i file, quale formato è richiesto, quando dovranno essere consegnati e chi verificherà il risultato. Per me, è proprio a questo punto che le competenze tecniche iniziano a creare valore nella gestione dei progetti. L'obiettivo non è essere la persona con le maggiori conoscenze tecnologiche durante una riunione, ma comprendere la tecnologia quanto basta per identificarne le conseguenze sul progetto.

Acquistare un software non significa averlo implementato

Questa distinzione diventa particolarmente importante quando un'azienda acquista un'applicazione già esistente invece di sviluppare un nuovo sistema. Il software è già disponibile, il fornitore conosce il prodotto, il contratto potrebbe essere già stato firmato e le licenze potrebbero persino essere già state pagate. Ma questo non significa che il progetto sia vicino alla conclusione. È ancora necessario definire cosa verrà implementato per primo, preparare i dati, verificare le configurazioni, coordinare le attività con il fornitore, preparare gli utenti, organizzare le integrazioni e stabilire cosa rientra nell'implementazione attuale e cosa verrà rimandato a una fase successiva.

In questo tipo di progetto, gran parte della complessità non deriva dallo sviluppo del software, ma dal coordinamento delle attività. Il fornitore ha bisogno di ricevere informazioni dall'azienda, un team interno dipende da un altro, gli utenti aspettano che la piattaforma sia disponibile, il reparto sicurezza potrebbe dover approvare alcuni accessi, un altro sistema potrebbe dover fornire determinate informazioni e un'area di business potrebbe essere chiamata a validare i dati prima del loro utilizzo. Tutte queste sono dipendenze di progetto, anche quando non viene sviluppato alcun software internamente.

Quando le discussioni tecniche iniziano a influenzare l'ambito del progetto

Un'altra difficoltà emerge quando le persone iniziano a esplorare tutto ciò che la nuova piattaforma potrebbe fare. Qualcuno suggerisce di integrarla con un altro sistema, un'altra persona propone di automatizzare un'attività manuale e qualcun altro chiede se lo strumento potrebbe essere utilizzato anche da un altro reparto. In poco tempo, la conversazione smette di riguardare soltanto l'implementazione attuale e comincia a includere possibilità future.

Non c'è nulla di sbagliato nell'esplorare queste opportunità. Il problema nasce quando nessuno distingue queste possibilità dall'ambito effettivamente approvato per il progetto. Un Project Manager deve comprendere se una determinata idea fa parte della fase attuale, se rappresenta un miglioramento futuro oppure se è semplicemente qualcosa di tecnicamente possibile. Altrimenti, l'ambito del progetto rischia di trasformarsi in un insieme di aspettative che nessuno si è formalmente impegnato a soddisfare.

Per questo credo che uno dei contributi più importanti di un Project Manager nei progetti tecnologici sia trasformare le possibilità in impegni chiari. Mentre le discussioni tecniche si concentrano spesso su ciò che si potrebbe fare, la gestione del progetto deve stabilire ciò che verrà effettivamente realizzato.

La pianificazione di un progetto parte dal flusso di lavoro, non dalle date

L'esempio dei fogli di calcolo mi ha fatto riflettere anche su un altro aspetto: la pianificazione di un progetto non dovrebbe iniziare scegliendo delle date, ma comprendendo come il lavoro deve essere svolto. Se devono essere consegnati cinque file, prima devo sapere chi preparerà ciascuno di essi, se potranno essere prodotti contemporaneamente, se qualcuno dovrà verificarli e se il fornitore avrà bisogno di riceverli tutti prima di iniziare.

Successivamente devo capire cosa accadrà. Il fornitore potrà caricare i dati immediatamente? Sarà necessaria un'ulteriore configurazione? Chi controllerà il risultato? Quando gli utenti potranno iniziare a utilizzare il sistema? Soltanto quando questa sequenza sarà chiara, le date inizieranno ad avere un significato concreto. Preparazione dei dati, validazione, invio, caricamento, verifica, preparazione degli utenti e messa in produzione diventano attività collegate tra loro, anziché semplici date isolate all'interno di un calendario.

Comprendere queste relazioni è fondamentale anche per identificare il percorso critico e le dipendenze che possono provocare ritardi in un progetto. Se un'attività può iniziare soltanto dopo che un'altra è stata completata, questa relazione deve essere visibile prima di assumere degli impegni. Senza comprendere la sequenza delle attività, le date inserite nella pianificazione rischiano di essere poco più che ipotesi prive di una base sufficientemente solida.

Competenze tecniche o familiarità con la tecnologia: cosa serve davvero a un Project Manager?

Per questo motivo, quando penso alle competenze di un Project Manager, preferisco parlare di familiarità con il contesto tecnologico piuttosto che di specializzazione tecnica. Per me significa comprendere l'ambiente abbastanza bene da collegare ciò che viene discusso alle conseguenze che può avere sul progetto. Se un'integrazione richiede l'approvazione del reparto sicurezza, devo riconoscere che potrebbe rappresentare una dipendenza. Se il fornitore spiega che una personalizzazione richiesta non fa parte delle funzionalità standard del prodotto, devo comprendere che potremmo introdurre costi aggiuntivi, modifiche all'ambito o nuovi rischi. Se un team non può fornire determinati dati prima che un altro reparto li abbia validati, devo riconoscere non soltanto un vincolo tecnico, ma anche una questione di responsabilità e di pianificazione.

Il dettaglio tecnico è importante perché fornisce il contesto necessario per prendere decisioni di gestione. L'obiettivo non è padroneggiare ogni componente della soluzione, ma comprendere quanto basta per identificare quando una decisione, una limitazione o una dipendenza tecnica può influenzare il progetto e cosa occorre fare di conseguenza. Questa capacità aiuta anche a riconoscere i primi segnali di problemi e ritardi, soprattutto quando vincoli tecnici e dipendenze iniziano a compromettere le stime o le previsioni di consegna. In queste situazioni, può essere utile approfondire anche come individuare la causa radice dei problemi di un progetto, evitando di concentrarsi soltanto sui sintomi.

Quanto deve essere tecnico un Program Manager?

Il livello di conoscenza tecnica necessario comincia a cambiare quando passiamo dalla gestione di un progetto alla gestione di un programma. Un Project Manager normalmente lavora relativamente vicino all'esecuzione, dove i vincoli tecnici possono avere conseguenze immediate su pianificazione, ambito e consegne. Un Program Manager opera a un livello diverso. Il singolo problema tecnico continua ad avere importanza, ma diventa sempre più necessario comprendere come quel problema colleghi progetti, team e risultati differenti.

Immaginiamo che tre progetti diversi dipendano dallo stesso team di integrazione. Per ciascun Project Manager, questa situazione potrebbe sembrare una semplice dipendenza all'interno del proprio progetto. Per il Program Manager, invece, rappresenta qualcosa di più ampio: un vincolo di capacità condivisa che potrebbe compromettere contemporaneamente diverse iniziative. Oppure immaginiamo che un progetto stia sostituendo un'applicazione dalla quale dipendono altri progetti. In questo caso, la decisione tecnologica non riguarda più soltanto una singola iniziativa, ma entra nell'architettura complessiva del programma e può influenzare la sequenza delle attività, i benefici attesi, l'allocazione delle risorse e le consegne di più progetti.

Di conseguenza, un Program Manager potrebbe aver bisogno di conoscere meno dettagli sull'implementazione di ogni singola soluzione, ma dovrebbe possedere una comprensione più ampia di come i diversi componenti tecnologici si relazionano tra loro. L'attenzione si sposta dalle conseguenze della tecnologia all'interno di un progetto alla comprensione di come quelle stesse conseguenze possano influenzare i risultati dell'intero programma.

Quali competenze tecniche servono a un PMO o a un Portfolio Manager?

A livello di PMO, ovvero Project Management Office, e di gestione del portafoglio progetti, le domande diventano ancora più ampie. Un Portfolio Manager probabilmente non ha bisogno di sapere perché una determinata importazione dei dati non sia riuscita o quale API stia impedendo la comunicazione tra due applicazioni. Potrebbe però dover comprendere se diverse iniziative strategiche dipendono dalla stessa piattaforma, se più progetti stanno competendo per gli stessi specialisti tecnici, se diversi reparti aziendali stanno acquistando applicazioni con funzionalità sovrapposte oppure se una decisione tecnologica sta generando rischi per più iniziative importanti.

A questo livello, la conoscenza tecnica diventa sempre più uno strumento per comprendere il business. Le decisioni riguardano investimenti, capacità organizzativa, priorità, benefici e rischi strategici. Una limitazione tecnologica che potrebbe sembrare relativamente piccola se analizzata all'interno di un singolo progetto può assumere un'importanza completamente diversa quando diverse iniziative dipendono dallo stesso sistema, fornitore o gruppo di specialisti.

Forse questa è la distinzione che considero più importante: un Project Manager deve comprendere come la tecnologia influenza le consegne. Un Program Manager deve capire come la tecnologia crea dipendenze tra diverse iniziative. Un PMO o Portfolio Manager deve comprendere come queste dipendenze influenzano investimenti, capacità, rischi e strategia dell'organizzazione.

Man mano che ci spostiamo tra questi diversi livelli di gestione, la necessità di conoscere i dettagli dell'implementazione può diminuire, ma l'importanza di comprenderne le conseguenze rimane. Questo principio è collegato anche al ruolo di un PMO moderno, che dovrebbe aiutare l'organizzazione a capire non soltanto se i propri progetti stanno avanzando, ma se stanno effettivamente generando valore per il business. Ho approfondito questa distinzione anche nell'articolo su come utilizzare l'intelligenza artificiale nella gestione dei progetti per creare un PMO capace di generare valore per l'azienda.

Project Manager e Technical Project Manager: qual è la differenza?

Credo sia importante distinguere anche tra un Project Manager che lavora su iniziative tecnologiche e un Technical Project Manager. La differenza non consiste semplicemente nel fatto che uno comprenda la tecnologia e l'altro no. Qualsiasi professionista responsabile della gestione di un progetto tecnologico dovrebbe possedere conoscenze tecniche sufficienti per gestirlo in modo efficace.

Un Technical Project Manager normalmente opera più vicino alla soluzione tecnologica e potrebbe essere coinvolto più direttamente nelle discussioni su architettura, vincoli ingegneristici, ambienti, integrazioni e decisioni di implementazione. Un Project Manager può invece lavorare a un livello meno dettagliato, affidandosi maggiormente agli specialisti tecnici e concentrandosi sul coordinamento delle attività, sulla gestione delle consegne e sui risultati di business. Il confine preciso dipende sempre dall'organizzazione e dalla natura del progetto, ma il titolo di Project Manager non dovrebbe mai significare che la tecnologia diventi una scatola nera che il professionista non ha bisogno di comprendere.

Quindi, quanto deve essere tecnico un Project Manager?

Forse è necessario riformulare la domanda iniziale. Invece di chiederci soltanto quanto debba essere tecnico un Project Manager, credo che una domanda più utile sia: quanto devo comprendere della tecnologia per prendere le decisioni di gestione che rientrano nelle mie responsabilità?

Un Project Manager dovrebbe comprendere la tecnologia abbastanza bene da riconoscere come decisioni, limitazioni e dipendenze tecniche possano influenzare ambito, pianificazione, costi, rischi e consegne. L'obiettivo non è necessariamente sviluppare una specializzazione tecnica profonda, ma acquisire una familiarità sufficiente con la tecnologia per porre le domande giuste, identificare le conseguenze e trasformare le informazioni tecniche in decisioni di gestione.

Se non riesco a comprendere la tecnologia abbastanza bene da identificare come potrebbe influenzare il progetto, probabilmente ho bisogno di approfondire le mie conoscenze. Allo stesso tempo, se inizio a prendere decisioni architetturali che dovrebbero spettare agli specialisti, potrei aver superato i confini del mio ruolo. L'equilibrio si trova da qualche parte tra questi due estremi: comprendere abbastanza da interpretare le conseguenze, senza assumersi la responsabilità di decisioni che richiedono competenze tecniche più approfondite.

E a volte, soprattutto quando un'azienda sta acquistando una nuova applicazione, le domande più importanti sono molto più semplici. Cosa stiamo implementando esattamente? Chi deve consegnare cosa? Chi sta aspettando il risultato? Quali attività dipendono da quella consegna ed entro quando deve essere completata?

Sono domande che possono sembrare semplici, ma senza queste risposte diventa molto difficile definire un ambito coerente, costruire una pianificazione realistica o comprendere se un progetto stia realmente avanzando.

A presto!

Erik Scaranello