Lo sponsor vuole partire con una piattaforma di analytics “entro 4 settimane” per cogliere un’opportunità. Requisiti vaghi, budget e benefici stimati ad alto livello. Cosa fai?

• Avvio un team ridotto per produrre risultati visibili e definiremo i dettagli durante l’esecuzione.
• Elaboro e faccio approvare un Project Charter con obiettivi SMART, ambito alto livello, business case/benefici, assunzioni, rischi iniziali, governance e stakeholder map prima di impegnare spese sostanziali.
• Time-box di 2 sprint di discovery con sponsor e stakeholder per ridurre l’incertezza, poi rientro con Charter e piano realistico validato.
• Chiedo un contratto forfettario al fornitore e definiremo i deliverable strada facendo.

A metà progetto il cliente chiede un’integrazione “indispensabile” non prevista. Planning e budget sono stretti. Come procedi?

• Accetto la richiesta per mantenere alto il rapporto: la assorbo nei buffer e recupero dopo se possibile.
• Apro una Change Request, analizzo impatti su ambito/tempo/costi/qualità/rischi, valuto alternative, porto al CCB; se approvata, aggiorno le baseline (WBS, schedule, budget) e comunico le variazioni.
• Sposto in silenzio altre attività fuori dalle priorità e inserisco la feature senza toccare il piano ufficiale.
• Inserisco nel backlog prioritizzato e negozio i trade-off con lo sponsor; se rientra nelle riserve di gestione lo pianifico nella prossima release, altrimenti CR formale.

Milestone critica tra 3 settimane. EVM indica SPI 0,82 e CPI 0,98. La critical path include due attività lunghe e dipendenti. Cosa fai per recuperare?

• Introduco straordinari generalizzati finché gli indicatori non tornano nei target.
• Analizzo la critical path, attuo crashing mirato sulle attività critiche con miglior rapporto costo/tempo, valuto fast-tracking dove il rischio è accettabile, rimuovo vincoli superflui, riequilibro risorse, aggiorno forecast (EAC/tempo) e comunico il piano di recupero al comitato di progetto.
• Richiedo subito una rebaseline per non risultare “in ritardo” nei report ufficiali.
• Aggiungo risorse su attività non critiche: più mani velocizzano sempre il completamento globale.

Il progetto introduce una tecnologia poco provata con scadenza rigida. Le incognite sono elevate. Qual è l’approccio corretto ai rischi?

• Aggiungo un buffer del 30% a tutte le attività: meglio abbondare che sforare.
• Creo un Risk Register con probabilità/impatto, piani di risposta (evitare/mitigare/trasferire/accettare), owner e trigger; eseguo spike/PoC come mitigazione, definisco riserve di contingenza e management, programmo risk review periodiche e, se utile, analisi Monte Carlo sulla schedule.
• Procedo e affronto i problemi quando si presentano: pianificare i rischi fa perdere tempo prezioso.
• Trasferisco tutto il rischio al fornitore con penali; non servono altre azioni interne.

Il DPO segnala rischi GDPR per il tracciamento utenti; il Product Owner spinge per andare live. Come gestisci l’allineamento degli stakeholder?

• Minimizzando la portata del problema: sarà affrontato in una fase successiva se necessario.
• Aggiorno lo Stakeholder Register e l’analisi potere/interesse, definisco un Engagement Plan, integro i requisiti privacy/security in DoD e backlog, tengo un decision log e negozio opzioni di valore/conformità; CR se impatta su ambito/tempi/costi.
• Escalo direttamente al CEO perché decida a fronte delle due posizioni opposte.
• Lascio al fornitore la responsabilità di conformarsi e non coinvolgo altri stakeholder interni.

Fornitore del modulo SSO in contratto fixed price con SLA 99,9% è in ritardo di 4 settimane e consegna con bug. Come reagisci come PM responsabile del contratto e del risultato?

• Applico subito penali e minaccio la risoluzione: serve una scossa immediata per rimetterli in riga.
• Avvio performance review formale con KPI contrattuali, emetto cure notice e ottengo un piano di recupero; verifico scope creep per eventuale change order, gestione claim e, se non recupera, attivo clausole SLA/exit; integro controlli qualità e acceptance criteria.
• Accetto un piccolo sconto sul canone in cambio di più tempo, senza ulteriori azioni strutturate.
• Riscrivo internamente il modulo senza informare il fornitore per rispettare la data di go-live.

In UAT il tasso di difetti cresce e molti bug sfuggono a test precedenti. Le prove sono concentrate a fine ciclo. Qual è la migliore linea d’azione?

• Aggiungo tester manuali nelle ultime due settimane per aumentare la copertura di UAT.
• Implemento un Quality Management Plan: criteri di accettazione e DoD chiari, test shift-left, automazione, analisi statica, peer review, pipeline CI/CD con gate di qualità, triage RCA e limiti al rework WIP prima del rilascio.
• Ridimensiono lo scope per rispettare la data e sistemo i difetti in una patch post go-live senza cambiare processo di qualità.
• Posticipo UAT finché non avremo “zero bug conosciuti” in pre-produzione.

Programma interfunzionale con scadenze legali fisse. I team sono agili. Come garantisci controllo e valore senza snaturare l’agilità?

• Passo a waterfall completo: solo un piano Gantt centralizzato garantisce il rispetto delle date fisse.
• Adotto un approccio ibrido: backlog/iterazioni, milestone e roadmap integrate, dependency board, risk-based governance, reporting con burn-up/burndown + EVM agile e gate di release per la compliance alle scadenze legali.
• Lascio totale autonomia ai team senza milestone: l’autorganizzazione troverà la via per rispettare le date.
• Passo tutto a Kanban senza definire obiettivi temporali: il flusso continuo è più efficiente delle scadenze.

Lo sponsor lamenta “sorprese” su ritardi e rischi. I team dicono che tutto è tracciato nel tool. Cosa cambi concretamente?

• Inizio a inviare email giornaliere a tutti con l’elenco attività in corso e percentuali di avanzamento manuali.
• Definisco un Piano di Comunicazione con stakeholder map, cadenze e formati; dashboard KPI (scope/schedule/costi/riski), report RAG con criteri espliciti, gestione issue/escalation e minute d’azione; sincronizzo i meeting decisionali con i momenti chiave del piano.
• Mantengo tutto nel tool di progetto: chi è interessato può controllare lo stato in autonomia quando vuole.
• Comunico solo quando il ritardo supera due settimane: evitare allarmismi inutili.

Dopo il go-live l’adozione è bassa e l’Operations è colta di sorpresa; arrivano molte segnalazioni. Come avresti dovuto impostare la transizione per prevenire questo esito?

• Pianifico Service/Operational Readiness e OCM: stakeholder e sponsor, comunicazione, formazione, readiness checklist, runbook/handover, Early Life Support, metriche di adozione e Benefits Realisation Plan con owner e target.
• Mi focalizzo sulla consegna tecnica: l’adozione si sistema da sola una volta in produzione.
• Programmo formazione su richiesta dopo il rilascio: inutile investire prima senza sapere chi userà davvero il sistema.
• Allungo la timeline di due settimane: più tempo risolve la maggior parte dei problemi di adozione.