Prompt Engineering per Project Manager: 6 tecniche AI
Sei tecniche di prompt engineering per il Project Manager: metodologia, stakeholder, scope, schedule, rischi e kickoff, con prompt a confronto.
Se chiediamo all'AI senza fornirle le giuste informazioni di contesto, otteniamo risposta da manuale: dipende, valuta Agile, valuta Waterfall, considera l'ibrido.
Un Project Manager può adottare un Prompt Engineering efficace applicando sei tecniche descrittive:
- dare contesto
- mostrare esempi
- specificare i vincoli di output
- spezzare i task complessi in step
- chiedere all'AI di ragionare prima di eseguire
- e definire ruolo, stile o tono.
Sono le sei best practice di Prompting indicate da Anthropic all'interno della competenza Description del framework di AI Fluency.
In questo articolo, le vediamo applicate a sei deliverable che il PM lavora comunemente (metodologia di progetto, registro stakeholder, scope, schedule di alto livello, risk register e slide di kickoff).
Per ognuno di questi deliverable di governo del progetto, vediamo un prompt vago e un prompt efficace messi a confronto.
Guarda il video
Questo articolo nasce da un video del canale YouTube di Augmented Consultant.
Se preferisci la versione parlata, puoi guardarlo qui sotto.
1. Cosa cambia tra un prompt vago e un prompt descritto bene?
La competenza che sta alla base delle sei best practice che vedremo esemplificate tra poco si chiama Description, ed è la seconda delle quattro D del framework di AI Fluency di Anthropic.
Imparare a dominare la competenza Description ci permette di alimentare l'AI con prompt efficaci.
Cosa cambia tra un prompt vago, e uno descritto bene?
In primis, cambia la distanza tra la risposta da manuale e la raccomandazione calata sul nostro progetto: senza contesto e senza vincoli, l'AI può restituirci solo la teoria, e la teoria non si porta in riunione con lo sponsor.
La Description si articola su tre dimensioni:
- la Product description (cosa vogliamo, in termini di output, formato, audience e stile)
- la Process description (come vogliamo che l'AI affronti il lavoro, con istruzioni, passaggi ed esempi)
- e la Performance description (come vogliamo che l'AI si comporti durante la collaborazione, se concisa o dettagliata, se vogliamo che ci assecondi o che ci sfidi nel ragionamento).
Se vuoi il quadro completo delle quattro competenze che costituiscono il framework dell'AI Fluency, lo trovi in questo articolo del blog: Le 4 D dell'AI Fluency per Business Analyst e Project Manager.
Se invece vuoi entrare nel vivo del Prompting efficace per il PM, continua a leggere qui sotto.
Un'avvertenza: il Prompting è un processo iterativo, che si affina attraverso cicli brevi di Description e Discernment.
I prompt che seguono non sono formule da copiare alla lettera, ma template di partenza utili per pensare la comunicazione con l'AI, da cui prendere spunto per le tue prossime interazioni.
Vediamo, per prima cosa, come si configura il cliente fittizio che utilizziamo per esemplificare la competenza descrittiva di Prompt Engineering, nel caso di un Project Manager alle prese con un progetto.
2. Su quale progetto sono calati gli esempi?
Gli esempi sono calati sul cliente fittizio ACME: un ente della Pubblica Amministrazione che introduce Salesforce nell'ambito di un'architettura legacy preesistente.
ACME eroga strumenti finanziari agevolati alle PMI e sta realizzando un nuovo portale autenticato dove le imprese potranno presentare in digitale la domanda di accesso ai prodotti finanziari.
Il portale, che sarà realizzato su tecnologia Salesforce, si appoggia a un'architettura legacy fatta di anagrafica, gestionale, middleware e documentale.
Sul progetto lavorano più fornitori oltre a noi: uno sul portale, uno sul middleware e uno sul gestionale legacy.
Nel progetto, il Project Manager è la persona che governa la delivery: metodologia, perimetro, tempi, persone e rischi.
Per farlo, il Project Manager produce una serie di deliverable, tra cui: registro stakeholder, documento di scope, schedule di alto livello, risk register e materiali di kickoff.
3. Esempi delle sei tecniche di Prompt Engineering per il Project Manager
Vediamo come il Project Manager può utilizzare le best practice di Prompt Engineering per realizzare i deliverable di progetto di cui è responsabile.
a. Come si dà contesto all'AI per scegliere la metodologia di progetto?
Dare contesto significa descrivere il progetto reale, cliente, fornitori, integrazioni, vincoli e tempi, prima di chiedere una raccomandazione: senza queste informazioni l'AI può solo ripetere il manuale.
È la prima best practice ed è anche la più sottovalutata.
Prendiamo la scelta della metodologia, cioè la decisione che condiziona il modo in cui tutto il resto del progetto verrà gestito.
Prompt vago:
"Quale metodologia di progetto mi consigli?"
Se ci rivolgiamo così all'AI, la risposta sarà da manuale: dipende, valuta Agile, valuta Waterfall, considera l'ibrido.
Vero, ma non è quello che ci aspettiamo.
Senza contesto, l'AI non può che restituirci la teoria.
Prompt efficace:
"Devo identificare la metodologia per un progetto di realizzazione di un nuovo portale Salesforce per un ente della Pubblica Amministrazione. Il contesto: il cliente eroga finanziamenti agevolati, ci sono più fornitori coinvolti oltre a noi (uno sul portale, uno sul middleware, uno sul gestionale legacy), il portale si integra con sistemi preesistenti, e ci sono vincoli di compliance tipici della PA. Il kickoff è previsto per settembre. Sulla base di questo contesto, consigliami la metodologia più adatta e spiegami perché, tenendo conto del coordinamento tra fornitori e della rigidità dei vincoli."
La differenza è evidente, e sta in quattro informazioni che nel primo prompt non c'erano: chi è il cliente, chi sono gli altri attori coinvolti, quali vincoli abbiamo, e da quando partiamo.
Con il contesto, la raccomandazione diventa calata su ACME ed è motivata, quindi possiamo discuterla con il team e con lo sponsor invece di limitarci a leggerla.
b. Come si usa un esempio per costruire il registro stakeholder?
Mostrare il formato di una singola riga fa replicare all'AI la stessa struttura su tutti gli stakeholder, invece di restituire una lista piatta di nomi e ruoli.
A volte mostrare è più efficace che spiegare.
L'identificazione degli stakeholder è il caso ideale, perché il valore del registro sta nella classificazione, non nell'elenco.
Prompt vago:
"Elencami gli stakeholder del progetto ACME."
Otteniamo una lista piatta, nomi e ruoli, senza classificazione e senza la struttura che serve a un registro stakeholder.
Prompt efficace:
"Devo costruire il registro stakeholder del progetto ACME. Ti do un esempio del formato che voglio per ogni riga: 'Azienda: ACME: Ruolo di progetto: Executive Sponsor: Job title: Head of Business: Interno o esterno: interno: Livello di coinvolgimento: supportivo'. Seguendo esattamente questo formato, classifica tutti gli stakeholder che ti elenco, distinguendo tra il committente ACME e i fornitori esterni, e assegnando a ciascuno il livello di coinvolgimento più probabile tra: inconsapevole, resistente, neutrale, supportivo, guida."
Con una sola riga di esempio abbiamo eliminato l'ambiguità sulla forma, e possiamo concentrare la revisione sul merito della classificazione invece che sulla formattazione.
c. Come si vincola l'output per definire lo scope di progetto?
Dichiarare la struttura dell'output, liste In Scope e Out of Scope, tabella dei deliverable e marcatura delle voci da validare, evita il paragrafo discorsivo che confonde certezze e ipotesi.
Sullo scope questa tecnica conta il doppio, perché il perimetro è il documento su cui poi si discute con il cliente.
Prompt vago:
"Definiscimi lo scope del progetto Portale."
Con una richiesta così, molto probabilmente il risultato sarà un paragrafo discorsivo che non esplicita al meglio ciò che è dentro e ciò che è fuori dal perimetro di progetto.
Prompt efficace:
"Aiutami a definire lo scope del progetto del nuovo portale ACME. Voglio l'output così strutturato: una lista 'In Scope' con le funzionalità incluse (registrazione imprese, aggiornamento anagrafiche, sottomissione domande, visibilità dell'esito), una lista 'Out of Scope' con ciò che esplicitamente non rientra nella prima versione, e una tabella dei deliverable principali. Regola importante: marca con la dicitura 'da validare con il cliente' ogni voce che non è ancora confermata, così distinguiamo a colpo d'occhio le certezze dalle ipotesi."
Notiamo l'ultima regola, che è quella che vale di più: chiedere di marcare le voci non confermate trasforma un documento che sembra definitivo in un documento onesto, che possiamo portare in riunione senza far passare per acquisita un'ipotesi nostra.
d. Come si spezza in step la costruzione della schedule di progetto?
Quando il compito è articolato, indicare all'AI l'ordine dei passaggi evita la sequenza di date plausibili ma sbagliata sulle dipendenze.
Il piano di alto livello è il caso classico in cui l'output sembra corretto a colpo d'occhio ed è fragile appena si guardano i legami tra le attività.
Prompt vago:
"Fammi il piano di progetto del portale ACME."
L'AI produrrà una sequenza di date e attività apparentemente plausibili, ma magari fallace dal punto di vista delle dipendenze.
Prompt efficace:
"Devo costruire la schedule di alto livello del progetto portale ACME. Procedi per passaggi. Primo: identifica le fasi principali del progetto, dal kickoff alla messa in esercizio. Secondo: per ogni fase elenca i deliverable attesi. Terzo: individua le dipendenze tra le fasi e tra i fornitori coinvolti, segnalando dove il nostro lavoro dipende da quello del fornitore del gestionale o del middleware. Quarto: colloca le milestone principali partendo dal kickoff di settembre. Mostrami prima i passaggi uno, due e tre, poi costruiamo insieme il piano temporale."
La richiesta di vedere i primi tre passaggi prima del piano temporale è la parte che, nella mia esperienza, fa la differenza tra una schedule da rifare e una da rivedere: è il momento in cui possiamo correggere le dipendenze prima che diventino date.
e. Come si chiede all'AI di ragionare prima di stendere il risk register?
Dare spazio al ragionamento prima dell'output migliora la qualità e ci permette di accorgerci subito se l'AI ha frainteso il contesto del progetto.
Anthropic è esplicita su questo punto: lo spazio di pensiero va dato prima dell'esecuzione, perché è lì che la qualità migliora ed è lì che possiamo intercettare una deriva.
Applichiamo questa best practice alla prima versione del risk register, il registro dei rischi che apriamo in avvio e ci accompagna per tutto il progetto.
Prompt vago:
"Creami il risk register del progetto ACME."
L'AI ci darà una lista di rischi generici, quelli che valgono per qualsiasi progetto IT.
Mancano i rischi specifici di ACME, che sono poi quelli che ci interessano davvero.
Prompt efficace:
"Devo stendere la prima versione del risk register del progetto portale ACME. Prima di elencare i rischi, ragiona per categorie: rischi legati al coordinamento tra i diversi fornitori, rischi legati alle integrazioni con i sistemi legacy, rischi legati ai vincoli di compliance della PA, rischi legati alla qualità e disponibilità dei dati anagrafici, rischi legati all'adozione da parte degli utenti impresa. Per ciascuna categoria ragiona su cosa potrebbe andare storto in questo specifico progetto. Solo dopo questo ragionamento, compila il risk register con: descrizione del rischio, categoria, probabilità, impatto e una possibile azione di mitigazione."
Le categorie che indichiamo non sono un vincolo formale, sono il nostro giudizio di PM su dove questo progetto può rompersi.
È il punto in cui la competenza di dominio entra dentro il prompt.
f. Come si assegna un ruolo e uno stile per le slide di kickoff?
Dire all'AI chi essere e a quale audience sta parlando cambia il livello di dettaglio e il tono delle slide, che nel kickoff si rivolgono a interlocutori molto diversi tra loro.
Prompt vago:
"Fammi le slide di kickoff del progetto."
Senza un ruolo e un'audience, l'AI produce slide generiche, con un livello di dettaglio e un tono di cui non sappiamo neanche a chi parlino.
Prompt efficace:
"Comportati come un Project Manager che presenta il kickoff di un progetto Salesforce davanti a un'audience mista: sponsor e referenti di business del cliente, IT del cliente, e i diversi fornitori coinvolti. Lo stile delle slide deve essere chiaro e sintetico, una slide un messaggio, con un tono professionale ma accessibile, adatto a un ente della PA. Prepara il draft delle slide di kickoff coprendo: obiettivi del progetto, perimetro di alto livello, organizzazione e ruoli, approccio metodologico, tappe principali e prossimi passi. Per ogni slide dammi titolo e punti chiave, non testo da leggere a voce."
Assegnando un ruolo e uno stile preciso abbiamo trasformato l'AI da assistente generico in un PM che prepara una presentazione per una sala eterogenea.
E vale la pena notare l'ultima riga: chiedendo titolo e punti chiave invece del testo da leggere otteniamo un draft su cui costruire il racconto, non un copione da recitare.
Le sei pratiche si compongono, cioè si usano contestualmente in fase di stesura del prompt, a seconda dell'esigenza.
4. Checklist finale su Prompt Engineering per Project Manager
Le sei tecniche coprono le tre dimensioni della Description:
- quando diamo contesto o specifichiamo i vincoli di output stiamo facendo Product description, cioè definiamo cosa vogliamo
- quando mostriamo esempi, spezziamo in step o chiediamo di ragionare prima stiamo facendo Process description, cioè guidiamo il come
- quando assegniamo un ruolo e uno stile stiamo facendo Performance description, cioè modelliamo il comportamento.
Se dovessimo portarci a casa una cosa sola, applicabile dal prossimo deliverable su cui mettiamo mano, è questa: prima di premere invio, aggiungiamo due righe di contesto e una riga di vincolo sull'output.
Chi siamo, su cosa stiamo lavorando, e che forma deve avere il risultato.
È un investimento di pochi secondi che ci risparmia molto più tempo altrimenti speso in rilavorazioni.
E quando non sappiamo come formulare una richiesta, c'è quella che Anthropic chiama non a caso l'arma segreta: spiegare a Claude cosa vogliamo ottenere e chiedergli di aiutarci a scrivere il prompt.
5. Domande frequenti
a. Cos'è il Prompt Engineering per un Project Manager?
È l'applicazione di sei tecniche di descrizione (dare contesto, mostrare esempi, vincolare l'output, spezzare in step, far ragionare prima, definire ruolo e stile) alle richieste che il PM fa all'AI sui deliverable di governo del progetto, come metodologia, registro stakeholder, scope, schedule, risk register e slide di kickoff.
b. Posso chiedere all'AI quale metodologia usare sul mio progetto?
Sì, ma solo dopo averle dato il progetto.
Senza contesto su cliente, fornitori coinvolti, integrazioni, vincoli di compliance e tempi, la risposta resta la teoria da manuale.
Con quel contesto la raccomandazione diventa specifica e argomentata, e quindi discutibile con il team.
c. Come si ottiene un risk register specifico e non generico?
Chiedendo all'AI di ragionare per categorie di rischio prima di compilare il registro.
Le categorie le indichiamo noi, perché rappresentano il nostro giudizio su dove quel progetto può rompersi: coordinamento tra fornitori, integrazioni legacy, compliance, qualità dei dati, adozione degli utenti.
d. Serve saper programmare per scrivere prompt AI efficaci?
No.
Le sei tecniche sono competenze di descrizione e di metodo, non di sviluppo: chiedono di esplicitare contesto, formato e processo di lavoro, cioè esattamente quello che un Project Manager fa già quando assegna un'attività a una persona del team.
e. Che differenza c'è tra Product, Process e Performance Description?
La Product description definisce cosa vogliamo (output, formato, audience, stile), la Process description definisce come vogliamo che l'AI affronti il lavoro (istruzioni, passaggi, esempi), la Performance description definisce come vogliamo che si comporti durante la collaborazione (concisa o dettagliata, accondiscendente o critica).
f. Un prompt scritto bene basta al primo colpo?
Quasi mai, ed è normale.
Il prompting è un processo iterativo che si affina con cicli brevi di Description e Discernment: i prompt di questo articolo sono template di partenza, non formule da copiare alla lettera.
Continua il percorso
Su Augmented Consultant condivido, partendo dal mio lavoro reale, strumenti, demo, e risorse per evolvere la professionalità consulenziale con l'AI, per Consulenti, Business Analyst e Project Manager.
Se è un percorso che ti interessa, iscriviti al canale YouTube di Augmented Consultant per non perdere la prossima tappa.
Fonti
- Rick Dakan, Joseph Feller e Anthropic, AI Fluency: Framework & Foundations (2025), licenza CC BY-NC-SA 4.0. Competenza Description, dimensioni Product, Process e Performance, e le sei tecniche di prompting efficace
- Augmented Consultant, Le 4 D dell'AI Fluency per Business Analyst e Project Manager
