PMBOK 8 e AI: cosa cambia davvero per chi fa project control su grandi opere

Un lunedì mattina, su un cantiere multi-subappalto di grandi dimensioni, arriva la settimana di chiusura SAL. I dati di avanzamento entrano da sei direzioni diverse — produzione, logistica, subappaltatori, ufficio tecnico — e qualcuno deve consolidarli in un report che abbia senso prima della riunione di mercoledì. Fino a qualche anno fa quel “qualcuno” passava il lunedì e il martedì a raccogliere, allineare, correggere. Oggi, in cantieri dove il flusso dati è strutturato, quella fase può durare ore invece di giorni. Il punto non è che il lavoro sparisce: è che si sposta.

Questo è il contesto in cui leggere l’Appendix X3 del PMBOK 8 — l’appendice che introduce l’AI come area tematica strutturata e la tratta come competenza professionale da presidiare. Non un aggiornamento cosmetico del testo, non una concessione alla moda. Una presa di posizione su chi deve capire e governare questi strumenti.

---

Cosa dice davvero il PMBOK 8 sull’AI

Il PMBOK 8 non riscrive la logica di governo del progetto. I 7 domini di performance e i 6 principi restano l’ossatura: stakeholder, team, approccio di sviluppo, pianificazione, incertezza, consegna, performance. Quello che cambia è l’ecosistema in cui quei principi si applicano.

L’Appendix X3 tratta l’AI non come una funzione IT da attivare su richiesta, ma come una competenza che il professionista del project management deve essere in grado di valutare, integrare e, soprattutto, supervisionare. Il cambio di prospettiva è preciso: l’AI non è uno strumento da delegare a chi gestisce i sistemi informativi. È parte del modo in cui si esercita il ruolo.

Per chi lavora nel project control su infrastrutture complesse, questo ha implicazioni dirette. Significa che quando un sistema genera automaticamente una previsione di costo finale — una EAC costruita sui dati di earned value management —, o sintetizza i dati di avanzamento dai SAL dei subappaltatori, il project controller non può limitarsi a ricevere l’output. Deve capire da dove arriva quel numero, su quali assunzioni è costruito, dove il modello può sbagliare.

---

Le tre aree dove l’AI sta già cambiando il lavoro quotidiano

Su cantieri di grandi infrastrutture, l’integrazione di strumenti AI non è più un esperimento. In certi contesti è già operativa, anche se spesso parziale e non sistematica. Le aree dove il cambiamento si sente di più sono tre.

Prima area: il reporting di avanzamento. La sintesi automatica da dati strutturati — output di Primavera P6, feed di contabilità, SAL dei fornitori — può generare una bozza di report in una frazione del tempo che richiedeva la raccolta manuale. Ma “bozza” è la parola giusta. Un report settimanale prodotto in automatico è un punto di partenza, non un output da inoltrare così com’è. Il lavoro del project controller si sposta dal comporre il dato al validarlo: capire se quello che il sistema ha aggregato riflette davvero lo stato del cantiere, o se c’è un’anomalia che i dati strutturati non hanno catturato.

Seconda area: il supporto all’istruttoria delle varianti e al buyout. Su volumi documentali elevati — offerte di subappalto, varianti di contratto, corrispondenza tecnica — l’AI può accelerare la ricerca e la correlazione tra documenti in modo significativo. Questo è utile nella fase istruttoria: trovare i riferimenti contrattuali pertinenti, verificare se una richiesta è già coperta dallo scope esistente, incrociare la documentazione di variante con la baseline. L’accertamento del titolo — cioè il giudizio su se e quanto spetti al subappaltatore secondo contratto — resta una valutazione umana. L’AI velocizza il percorso verso quel giudizio, non lo sostituisce.

Terza area: il monitoraggio delle anomalie nel cost control. Quando i dati di costo sono sufficientemente strutturati e aggiornati con regolarità, un sistema può segnalare scostamenti che sfuggirebbero a un controllo manuale su grandi volumi. Non perché il modello “capisca” il progetto, ma perché confronta pattern su serie temporali che un analista umano faticherebbe a tenere sotto controllo in parallelo. La segnalazione va poi interpretata: spesso un’anomalia nei dati è un problema di imputazione, non un vero scostamento di costo.

---

Il rischio concreto: il ritmo, non la sostituzione

Il rischio non è di sostituzione: è di ritmo.

Il project controller non diventa superfluo. Diventa lento rispetto a chi ha già integrato questi strumenti nel proprio flusso di lavoro. E la distanza si allarga a ogni ciclo di reporting, perché il vantaggio non è lineare — si accumula.

Chi ha già integrato Power BI nel reporting o lavora con Primavera su feed automatizzati capisce il parallelo. Quando questi strumenti sono entrati nei cantieri, il problema non era imparare a usarli: era capire cosa fare con il tempo che liberavano, e come non perdere il contatto con il dato reale nel passaggio alla visualizzazione aggregata. Lo stesso tema si ripropone con l’AI, su una scala più ampia.

Il cost controller lavora su dati che devono essere interrogati, non solo letti. Aggiungere un livello di intelligenza sul dato — oltre alla sola visualizzazione — significa che le domande da porre diventano più complesse, non meno. Perché il sistema può già rispondere a quelle semplici.

---

Come integrare l’AI nel project control senza perdere il controllo del dato

Il punto pratico non è “quale strumento usare” — il mercato cambia troppo velocemente per dare indicazioni stabili. Il punto è il metodo con cui si integra lo strumento nel processo esistente.

Partire dai dati strutturati, non dall’AI. Qualsiasi strumento di sintesi automatica o monitoraggio delle anomalie funziona bene solo se i dati in ingresso sono affidabili e aggiornati con regolarità. Su cantieri dove la contabilità passiva è gestita con logiche diverse tra area e area, o dove i SAL dei subappaltatori arrivano in formati non omogenei, il primo investimento non è nell’AI: è nella struttura del dato. Un sistema intelligente su dati approssimativi produce output approssimativi più velocemente.

Definire chi valida l’output, e con quale metodo. Il passaggio dal comporre al validare il dato non è automatico: richiede che ci sia un processo esplicito di revisione prima che il dato diventi giudizio. Su un report settimanale generato in automatico, questo significa stabilire in anticipo quali soglie di anomalia richiedono verifica manuale, e chi ha l’autorità — e la competenza tecnica — per farlo.

Mantenere la lettura diretta del cantiere. Un rischio reale dell’automazione del reporting è il distacco dalla realtà fisica del lavoro. I dati strutturati catturano quello che è stato imputato, non necessariamente quello che sta succedendo. La presenza in cantiere e il contatto diretto con le squadre restano la fonte primaria di informazione per tutto quello che i dati non codificano: tensioni nei subappalti, ritardi non ancora contabilizzati, problemi che emergono prima di diventare scostamenti.

---

Cosa cambia nel ruolo professionale

Il PMBOK 8, trattando l’AI come competenza professionale, dice implicitamente che non è sufficiente saperla usare come utente. Bisogna saper valutare quando è utile, quando introduce rischi, e come mantenerla sotto supervisione.

Per chi lavora nel project control su infrastrutture complesse, questo si traduce in una capacità concreta: sapere leggere l’output di un sistema automatico con lo stesso spirito critico con cui si legge un SAL di subappaltatore. Non fiducia automatica, non rifiuto automatico. Verifica su cosa c’è dentro, su come è stato costruito, su dove potrebbe essere sbagliato.

La gestione dell’incertezza nel dato di costo richiede già questa capacità. L’AI aggiunge uno strato di complessità: ora oltre all’incertezza del dato c’è anche l’incertezza su come il sistema ha elaborato quel dato.

Il project controller che sa muoversi in questo spazio — validare l’output, interrogare le anomalie, mantenere il giudizio professionale sull’interpretazione — non è quello che viene sostituito. È quello che rimane rilevante.

Stai già usando strumenti AI nel tuo lavoro di project control o quantity surveying? In quale area hai visto il contributo più concreto — e dove invece hai trovato i limiti maggiori?