Executing in PM²: consegnare la soluzione e renderla adottabile

Undicesimo articolo della serie “Imparare PM² attraverso un progetto”

La fase di Executing è il momento in cui il progetto produce i deliverable previsti e realizza le attività necessarie perché la soluzione possa essere trasferita e utilizzata.

Non coincide con il solo sviluppo tecnico.

Executing risponde a: “Stiamo consegnando i risultati concordati e preparando l’organizzazione a usarli?”

I due risultati della fase

Ogni progetto deve presidiare due risultati collegati:

Il PCT produce la soluzione; il BIG prepara il cambiamento business. Il PM coordina la delivery; il BM presidia adozione e benefici. Se uno dei due lati manca, il progetto può completare un output senza generare outcome.

Delivery: realizzare quanto è stato pianificato

Durante Executing, il Project Core Team svolge il lavoro definito nel Project Work Plan. A seconda del progetto può comprendere sviluppo, configurazione, integrazione, test, acquisizione di servizi, migrazione dati, documentazione tecnica e preparazione al rilascio.

Il Project Manager deve:

• coordinare attività, risorse e dipendenze;
• confrontare avanzamento reale e baseline;
• gestire rischi, issue, modifiche e decisioni;
• mantenere aggiornati piani, log e report;
• assicurare qualità e integrazione dei deliverable;
• gestire escalation e decisioni oltre la propria autorità.

Nel progetto Prenotazioni Smart, il PCT realizza configurazione corsi, prenotazioni, cancellazioni, lista d’attesa e notifiche su web e mobile. Il PM coordina l’integrazione tra backend, app, test e pilota.

Accettazione dei deliverable: “finito” non basta

Un deliverable non è completo soltanto perché il team ritiene di averlo terminato. Deve essere verificato rispetto a criteri di accettazione concordati.

L’attività Manage Deliverables Acceptance richiede di:

• identificare ciò che deve essere accettato;
• definire criteri e evidenze richieste;
• organizzare revisione, test e sign-off;
• registrare non conformità e azioni correttive;
• conservare la decisione di accettazione.

L’accettazione protegge sia il business sia il provider: rende esplicito che il risultato è stato valutato contro criteri noti, non contro impressioni successive.

Gestire non conformità e rilavorazioni

Se un deliverable non soddisfa i criteri, non deve essere accettato “con riserva” senza una decisione chiara.

Occorre registrare la non conformità, valutarne severità e impatto, assegnare azioni, pianificare la verifica successiva e comunicare la decisione ai ruoli coinvolti.

Nel progetto Prenotazioni Smart, se la notifica di un posto liberato arriva con ritardo incompatibile con i requisiti, il problema può impedire l’accettazione della funzione. Il PCT corregge; il PM ripianifica; gli utenti o i ruoli designati rieseguono la verifica.

Transizione: passare dalla consegna all’operatività

La transizione organizza il passaggio della soluzione verso l’esercizio, il supporto e la manutenzione.

Può includere:

• migrazione o preparazione dei dati;
• configurazione degli ambienti;
• documentazione operativa e tecnica;
• definizione di supporto, monitoraggio e ownership;
• handover a operations;
• procedure di rilascio e rollback;
• verifica della readiness.

Il Transition Plan, preparato durante Planning e aggiornato in Executing, evita che la consegna al business sia un passaggio informale e fragile.

Per Annotatio, la transizione comprende disponibilità dell’infrastruttura, gestione degli errori delle notifiche, istruzioni di supporto e assegnazione chiara di chi interviene dopo il rilascio.

Business Implementation: rendere possibile l’adozione

La Business Implementation è il lavoro necessario affinché l’organizzazione modifichi comportamenti, processi e competenze per usare il nuovo risultato.

Può comprendere:

• aggiornamento dei processi;
• formazione;
• comunicazione;
• pilot e raccolta feedback;
• materiali per utenti e supporto;
• gestione della resistenza al cambiamento;
• misurazione iniziale dell’adozione;
• azioni correttive sull’esperienza d’uso.

Il Business Manager guida queste attività con il BIG.

Nel progetto Prenotazioni Smart, una palestra deve sapere come configurare un corso, come gestire assenze e liste d’attesa e come assistere un cliente. Rilasciare una funzione senza preparare queste attività produce software disponibile, non un cambiamento adottato.

Monitor & Control durante Executing

Executing concentra una grande parte del lavoro, ma il controllo resta continuo. Il ciclo è:

1. osservare stato, qualità, costi e rischi;
2. confrontarli con baseline e obiettivi;
3. decidere azioni correttive, preventive o modifiche;
4. aggiornare log, piani e report;
5. escalare le decisioni secondo la governance.

Un ritardo non è automaticamente un fallimento: diventa un problema di governance se viene ignorato, nascosto o corretto modificando informalmente la baseline.

Preparare RfC – Ready for Closing

Il Gate RfC non verifica solo che “il team abbia finito di sviluppare”. Verifica che il progetto possa entrare nel Closing in modo responsabile.

Le domande chiave sono:

• i deliverable previsti sono completati e accettati?
• non conformità, issue e azioni residue sono chiuse o gestite con una decisione esplicita?
• transizione e handover sono completi al livello concordato?
• Business Implementation, formazione e supporto iniziale sono stati eseguiti?
• documenti, log e report sono aggiornati?
• esistono azioni post-progetto da assegnare all’operatività?

Un progetto può avere una release in produzione e non essere ancora RfC-ready.

Caso pratico: la release è online, ma il progetto non può chiudere

Prenotazioni Smart è disponibile nell’app. Tuttavia:

• due palestre pilota non sono state formate;
• il supporto non ha una procedura per le notifiche fallite;
• un difetto critico della lista d’attesa è ancora aperto;
• il sign-off dell’utente non è stato raccolto.

Il rilascio è avvenuto, ma la chiusura non è pronta. Il PM, BM, PCT e BIG devono completare o formalmente gestire questi elementi prima di proporre RfC.

Da non confondere

Verifica ciò che ricordi

1. Quali sono i due risultati che Executing deve presidiare?
2. Perché un deliverable completato non è automaticamente accettato?
3. Che cosa prepara la transizione?
4. Chi guida la Business Implementation?
5. Che cosa verifica il Gate RfC?

Risposte

1. Delivery e Business Implementation.
2. Perché deve essere verificato contro criteri di accettazione concordati.
3. Handover verso esercizio, supporto e manutenzione.
4. Il Business Manager, con il BIG.
5. Che il progetto sia pronto a entrare nel Closing con deliverable, transizione e attività residue gestiti.

Flashcard

D: Chi produce normalmente i deliverable?
R: Il Project Core Team.

D: Chi guida la Business Implementation?
R: Il Business Manager.

D: Che cosa rende un deliverable accettabile?
R: Verifica e sign-off rispetto a criteri concordati.

D: Che cosa prepara il Transition Plan?
R: Handover e integrazione della soluzione nell’operatività.

D: Che cosa autorizza RfC?
R: L’ingresso nella fase di Closing.

Domanda in stile esame

Quale situazione impedisce più chiaramente il passaggio a RfC?

A. Il team ha aggiornato il Project Work Plan con l’avanzamento reale.
B. Tutti i deliverable sono accettati e le azioni residue sono assegnate all’operatività.
C. Il software è rilasciato, ma un deliverable critico non è accettato e la transizione non è completata.
D. Il PSC ha ricevuto il Project Status Report.

Risposta corretta: C. Una release tecnica non compensa l’assenza di accettazione e transizione necessarie per una chiusura responsabile.

Nel prossimo articolo

Nel prossimo articolo affronteremo Closing in PM²: Project-End Report, Lessons Learned, raccomandazioni e differenza tra chiusura del progetto e vita del prodotto.

Fonti essenziali

• European Commission, PM² Project Management Methodology Guide v3.1.
• European Commission, PM² Project Management Methodology – Highlights, 2025 Edition.