zeronodipm
Sezione Guida
ZPM-GD-001 · Rev 1.0 · 2026 · Guida operativa per PMI

Gestire piccoli progetti ICT senza perdersi.

Un percorso in otto passi per trasformare un'idea digitale in un progetto controllabile. Obiettivi, ambito, ruoli, fornitori, piano, rischi, SAL e chiusura — con i modelli operativi per iniziare lunedì mattina.

8 passi operativi
6 modelli compilabili
Checklist pronte all'uso
Esempi concreti
Raffaele Piccolo · ICT Project Manager · Bologna · zeronodipm.it
Per chi è questa guida
Per titolari, responsabili operativi e professionisti di PMI che devono seguire un progetto digitale — sito web, CRM, gestionale, migrazione — senza avere un project manager interno. Non serve alcuna formazione PM per usarla: bastano i modelli della seconda parte e la disciplina di compilarli.
Parte prima

Il metodo in otto passi

Ogni passo produce qualcosa di reale: un documento firmato, una decisione tracciata, un accordo scritto. Nulla che non si usi il lunedì mattina.

1
Prima di tutto

Capire il problema prima della soluzione

Il passo più ignorato — e più costoso. Prima di parlare di piattaforme, preventivi o fornitori, occorre chiarire il bisogno aziendale reale. Non il sintomo. Non lo strumento. Il problema.

La domanda fondamentale è semplice: quale problema dobbiamo risolvere, e come sapremo di averlo risolto?

Non «voglio un CRM» — ma «voglio che il team commerciale abbia tutte le informazioni sui clienti in un posto solo, senza usare tre fogli Excel diversi».

Regola scomoda (ma la più utile)
Se non si riesce a scrivere il problema in tre righe chiare, il progetto non è ancora pronto per partire.
Esempio pratico
Un'azienda chiede a un'agenzia web di rinnovare il sito. Dopo due mesi di lavoro, il sito è bello ma le vendite non cambiano. Perché? Il problema vero non era l'estetica — era che il sito non convertiva: niente form di contatto, niente pagine prodotto chiare, niente percorso utente. Se l'azienda avesse descritto il problema prima della soluzione, avrebbe dato istruzioni completamente diverse.
2
Chiarezza sul perimetro

Definire obiettivo e ambito

Un obiettivo scritto bene è già metà del lavoro. Serve sapere cosa è incluso, cosa è escluso e come si verifica il risultato. Senza questa base, le discussioni sono infinite e i cambi di ambito arrivano senza che nessuno se ne accorga.

Come si scrive un obiettivo
Formula utile: «[cosa deve funzionare] per [chi] entro [quando]».

Esempio: «Il CRM è configurato, i contatti sono importati e il team commerciale lo usa in autonomia entro il 30 marzo.»
✓ Incluso nel progetto

Configurazione CRM, importazione contatti esistenti, formazione a 3 utenti, assistenza per le prime due settimane.

✗ Escluso dal progetto

Integrazione con il gestionale, migrazione delle email storiche, supporto alla strategia commerciale.

Scrivere cosa è escluso sembra inutile — finché arriva la prima richiesta extra. A quel punto la frase «questo non era nell'ambito» vale più di qualsiasi contratto.

3
Le persone contano più degli strumenti

Chiarire ruoli e responsabilità

In un piccolo progetto, i ruoli si sovrappongono spesso. Va bene — l'importante è sapere chi decide, chi esegue e chi viene informato. Senza questa chiarezza, ogni blocco si trasforma in una settimana persa ad aspettare risposte.

Decisore strategico

Sponsor

Approva budget, priorità e cambi rilevanti. La sua firma sblocca il progetto — e lo ferma se qualcosa non va.

Potere decisionale alto
Ponte interno

Referente operativo

Raccoglie i bisogni reali degli utenti, coordina disponibilità e valida che quello che viene consegnato corrisponda alle aspettative.

Potere decisionale medio
Regista del progetto

Project Manager

Pianifica, monitora, traccia rischi e decisioni. Non esegue tecnicamente — tiene insieme le persone e i pezzi.

Potere decisionale medio
Chi realizza

Fornitore

Esegue le attività tecniche concordate. Ha competenza tecnica — ma non ha la visione di business. Quella rimane dall'altra parte del tavolo.

Cosa succede senza ruoli chiari
Il fornitore fa una domanda tecnica. Lo sponsor è in riunione. Il referente non sa rispondere. Il progetto si blocca tre giorni per una decisione che richiedeva dieci minuti. Si evita con una sola regola: «Le domande tecniche le gestisce il referente operativo entro 24 ore. Le decisioni di budget le prende la direzione entro 48 ore.» Una riga. Giorni risparmiati — e su un progetto intero, anche settimane.
4
Il piano è una conversazione, non una profezia

Costruire una roadmap semplice

La roadmap non serve a prevedere il futuro — serve a fare in modo che tutti parlino lo stesso linguaggio. Per ogni fase: un responsabile, una data, un output misurabile. Niente di più.

Fase 1
Analisi

Capire requisiti, vincoli e dipendenze. Output: scheda progetto approvata dallo sponsor.

Fase 2
Scelta soluzione e fornitore

Valutare opzioni, raccogliere preventivi, decidere. Output: decisione formalizzata per iscritto.

Fase 3
Configurazione e sviluppo

Il fornitore realizza. Il PM controlla. Il referente valida. Output: ambiente pronto per i test.

Fase 4
Test

Utenti reali, scenari reali, problemi reali. Output: checklist test compilata e firmata.

Fase 5
Formazione

Chi userà il sistema deve saperlo usare prima del go-live. Output: sessione completata, materiale consegnato.

Fase 6
Avvio

Si va live solo con autorizzazione esplicita dello sponsor. Output: go-live (la messa in esercizio) effettuato e documentato.

Fase 7
Supporto iniziale

Le prime settimane di esercizio sono parte del progetto, non un extra. Output: lista problemi chiusa o assegnata.

Strumento consigliato
Non serve un Gantt. Una tabella su Google Sheets con fase, responsabile, data e stato — aggiornata ogni settimana — è sufficiente per il 90% dei piccoli progetti ICT.
5
Il controllo quotidiano

Gestire attività, rischi, decisioni e cambi

Un registro operativo semplice evita di perdere pezzi. Non serve uno strumento costoso — serve la disciplina di aggiornarlo ogni settimana e di consultarlo prima di ogni riunione.

Riunione di avanzamento. Settimanale, breve, sempre con verbale. Se non si produce un verbale, la riunione non è avvenuta.
Stato delle attività. Da fare · In corso · Bloccata · Fatta. Nessun altro stato. L'ambiguità è nemica del controllo.
Decisioni. Sempre scritte, con data e nome del decisore. Una decisione presa a voce non esiste.
Cambi di ambito. Prima di approvare qualsiasi aggiunta: impatto su tempi, costi e rischi. Solo dopo: la decisione dello sponsor.
Documenti. Una cartella condivisa, ordinata e accessibile a tutti. I documenti nelle email non esistono.
Il cambio di ambito silenzioso
Durante una call il cliente chiede: «Potremmo aggiungere anche l'integrazione con il gestionale?» È una richiesta legittima. Ma prima di rispondere «sì», il PM calcola: quanto tempo aggiunge? Quanto costa? Sposta il go-live? Solo dopo quella valutazione, lo sponsor approva o rimanda. Senza questo passaggio il progetto si dilata, i costi salgono e nessuno capisce perché.
6
La riunione che decide

Fare SAL utili

Il SAL — Stato Avanzamento Lavori — è la riunione di avanzamento. Deve durare il minimo indispensabile e produrre sempre tre cose: un quadro dello stato, una lista di blocchi con owner, e i prossimi passi con scadenza.

SAL efficace in 20 minuti
5 minuti: stato a semaforo (verde / giallo / rosso) su tempi, costi, ambito e rischi.
10 minuti: blocchi aperti e decisioni richieste — con owner e data.
5 minuti: prossimi passi. Il verbale si scrive durante la call, non il giorno dopo.
Il test dei tre output
Al termine di ogni SAL, chiediti: c'è qualcuno responsabile di sbloccare qualcosa? C'è almeno una decisione presa o formalmente richiesta? Ci sono prossimi passi con data e nome? Se la risposta è no a tutto, la riunione non ha governato il progetto.
Attenzione
Un SAL senza verbale non è mai avvenuto. Un SAL senza prossimi passi non ha governato niente. Due SAL di fila senza decisioni sono un segnale che il progetto è fermo — anche se nessuno lo dice ad alta voce.
7
Prima del go-live

Testare, avviare e supportare

Un avvio senza controllo trasforma difetti minori in emergenze vere. Nessuna delle voci seguenti deve restare aperta quando si preme il tasto «live».

Il venerdì sera del go-live
Il CRM va live venerdì sera. Lunedì mattina il team commerciale non riesce ad accedere: le credenziali non erano state comunicate. Il supporto del fornitore riprende martedì. Tre giorni persi — e la fiducia nel progetto già incrinata. Tutto questo si evita con una checklist di due pagine, compilata il giovedì prima.
8
La chiusura è un atto professionale

Chiudere senza lasciare sospesi

Molti progetti «finiscono» senza essere mai stati formalmente chiusi. Il risultato: accessi non consegnati, documentazione introvabile, responsabilità post-avvio non chiare. La chiusura non è una formalità — è ciò che separa un progetto riuscito da uno che lascia dipendenze per anni.

Lezioni apprese
Le lezioni apprese non sono un'autocritica. Sono la risposta a una domanda precisa: cosa portiamo con noi nel prossimo progetto? Anche tre righe sincere scritte nell'ora dopo il go-live valgono più di qualsiasi report formale che nessuno riaprirà.
Parte seconda

Modelli operativi

Sei documenti pronti da compilare. Ogni modello è autonomo — si può usare da solo o insieme agli altri. I modelli M-05 e M-06 riprendono in versione completa e firmabile le checklist dei passi 7 e 8. Copiare, adattare, usare.

M1
Modello 01 di 06 · Avvio progetto · ~45 min

Scheda Progetto ICT

Uso: avvio progetto · Compilare con sponsor e referente operativo.

Rischi iniziali tipici (adattare al contesto):

Requisiti poco chiari Prob. mediaImpatto alto
Azione preventiva
Validare obiettivi e ambito prima di partire
Decisioni lente Prob. mediaImpatto medio
Azione preventiva
Definire chi decide e tempi di risposta
Disponibilità utenti bassa Prob. mediaImpatto medio
Azione preventiva
Pianificare test e formazione in anticipo
Dipendenza dal fornitore Prob. mediaImpatto alto
Azione preventiva
Chiarire deliverable, tempi e responsabilità

Approvazione avvio — nome, ruolo, approvazione, data e firma di: Sponsor · Project Manager · Fornitore.

M2
Modello 02 di 06 · Aggiornare ad ogni SAL

Roadmap di Progetto

Uso: pianificazione per fasi, milestone e responsabilità.

Fasi del progetto — per ciascuna: deliverable, owner, inizio e fine.

1 · Analisi
Deliverable
Scheda progetto approvata
2 · Scelta soluzione/fornitore
Deliverable
Decisione formalizzata
3 · Configurazione/sviluppo
Deliverable
Ambiente pronto per test
4 · Test
Deliverable
Checklist test compilata
5 · Formazione
Deliverable
Sessione completata
6 · Avvio
Deliverable
Go-live autorizzato
7 · Supporto iniziale
Deliverable
Lista problemi chiusa

Milestone principali — con data prevista, data effettiva e criterio di completamento:

Avvio
Criterio di completamento
Scheda progetto firmata e approvata
Soluzione scelta
Criterio di completamento
Fornitore/soluzione confermati
Test completati
Criterio di completamento
Nessun problema bloccante aperto
Go-live
Criterio di completamento
Avvio autorizzato dallo sponsor
Chiusura progetto
Criterio di completamento
Consegne e supporto definiti
M3
Modello 03 di 06 · Aggiornare prima e dopo ogni SAL

Registro Attività, Rischi e Decisioni

Uso: controllo operativo settimanale.

Attività — quattro stati e basta: Da fareIn corsoBloccataFatta

Rischi — partire dai quattro classici dei piccoli progetti ICT:

R001 · Requisiti poco chiari MediaAlto
Validare ambito e risultati attesi
R002 · Decisioni lente MediaMedio
Definire chi decide e tempi di risposta
R003 · Disponibilità utenti bassa MediaMedio
Pianificare test e formazione in anticipo
M4
Modello 04 di 06 · Max 30 minuti · Verbale durante la riunione

Verbale SAL

Sintesi stato a semaforo — tocca per impostare:

Tempi
Costi
Ambito
Rischi
M5
Modello 05 di 06 · Nessuna voce critica aperta

Checklist Test e Avvio

Uso: verifica pre go-live · Autorizzazione obbligatoria.

Prerequisiti

Autorizzazione go-live

M6
Modello 06 di 06 · Con sponsor, PM e fornitore

Checklist Chiusura Progetto

Uso: chiusura formale del progetto ICT.

Consegne

Supporto post-avvio

Lezioni apprese

Accettazione formale e chiusura — nome, ruolo, approvazione, data e firma di: Sponsor · Project Manager · Fornitore.