Comuni Errori di Schedulazione

Spesso anche i grandi Project Manager sbagliano. Alcuni errori sono molto comuni, pur essendo banali, con un pizzico di umiltà si potrebbero evitare. Una volta commesso l'errore si entra in una spirale pericolosa, anche perché non tutti sono disposti ad ammettere di aver sbagliato. Spero che questi pochi consigli aiutino almeno  i Project Manager certificati.

 

Per la maggior parte dei Project Manager il compito più importante è la gestione della schedulazione. Alcuni addirittura pensano che gestire un progetto sia realizzare un diagramma di Gantt con barre  di colore (intonato alle cravatte del project manager stesso). In realtà, i colori dovrebbero essere l’ultima delle preoccupazioni di un Project Manager.

Senza una schedulazione condivisa con il team di progetto non è facile gestire un progetto. E’ un peccato rinviare chiarimenti che potrebbero essere forniti a inizio progetto.

Gli errori più comuni che un Project Manager certificato non commette sono:

  1. Dimenticarsi di definire le milestone. Una milestone è il momento in cui si concludono alcune attività collegate o una fase del progetto. Di solito, una milestone è legata ad una deliverable o ad una decisione di go/nogo della fase successiva. E’ anche il momento in cui lo sponsor del progetto rinnova o conferma il mandato al project manager. Le milestone vanno definite con cura per la corretta prosecuzione del progetto e la verifica continua dell'impegno dello sponsor sul progetto.

  2. Ignorare delle dipendenze tra attività. Le attività di un progetto possiamo immaginarle come un'unica sequenza dalla prima all’ultima, dove alcune attività devono avvenire per forza prima di altre, mentre alcune altre conviene eseguirle in un certo ordine per nostra convenienza. Diciamo che le dipendenze si dividono in obbligatorie e facoltative. Dimenticare o non riconoscere una dipendenza obbligatoria è un errore madornale. Significa non aver compreso l’ambito del progetto o il prodotto da realizzare. Le dipendenze facoltative vengono definite per opportunità e convenienza del progetto, allo stesso modo del parallelismo delle attività. Ignorare una dipendenza facoltativa può comportare uno spreco di energie nell’eseguire un’attività il cui risultato viene superato o annullato da un’attività successiva. Basta invertire l’ordine delle attività interessate per risparmiare tempo e denaro. Anche questo è indice di non aver compreso l’ambito del progetto.

  3. Non coinvolgere il team di progetto. Lo sviluppo della schedulazione dovrebbe essere  sempre un lavoro corale tra project manager e team di progetto per due motivi: 1) coinvolgere immediatamente il team  nell’avventura che li aspetta; 2) raccogliere stime e considerazioni degli addetti ai lavori. Il project manager che sviluppa la schedulazione da solo, resterà da solo anche quando affioreranno problemi di scadenze non rispettate. Anche se il project manager sarebbe in grado di sviluppare da solo tutta la schedulazione del progetto, è preferibile che chieda il supporto del suo team, approfittandone per raccogliere le loro osservazioni, appianare eventuali divergenze sulle stime, trasferire immediatamente la conoscenza dell'ambito del progetto, rendendo più facili le assegnazioni delle attività in corso d'opera. In questo modo si ottiene una schedulazione più realistica;  le persone si aprono e propongono le loro migliori stime; restando coinvolte nelle scelte condivise con il project manager. Qualora quelle stime risultassero sbagliate, il team di progetto non se ne può lavare le mani.

  4. Non gestire le modifiche alla schedulazione. E’ praticamente impossibile che non vi siano cambiamenti ad una schedulazione, vuoi per le richieste di modifiche all’ambito, vuoi per la disponibilità delle risorse critiche, vuoi per condizionamenti esterni. La schedulazione non è per sempre!  Bisogna rilevare questi fenomeni, anche piccoli, e trasferirli dettagliatamente in una nuova versione della schedulazione. Tale revisione della schedulazione richiede anche un processo di approvazione se le variazioni impattano le date di rilascio delle deliverable. In ogni caso, per essere uno strumento di lavoro efficace per tutto il team, la schedulazione deve restare sempre allineata con la realtà del progetto, altrimenti diventa solo un documento storico del progetto.

  5. Non definire la baseline. La baseline di progetto è l’insieme di documenti di partenza del progetto a cui far riferimento successivamente fino alla sua conclusione. Ovviamente al primo cambiamento la baseline iniziale diventa obsoleta, pertanto bisogna gestirne gli aggiornamenti. Ciò è molto semplice se si imposta un sistema di “versioning” dove la versione con il numero più alto è la versione corrente. In questo modo si possono apportare le modifiche separatamente alle varie baseline (budget, schedulazione, ambito, etc), creando la storicità dei cambiamenti. Senza una rigida definizione della "baseline corrente" si rischia il disallineamento dei riferimenti con inutili conflitti dovuti semplicemente alla disinformazione.

Purtroppo anche gli "esperti di lunga data" hanno commesso questi ed altri errori, ma noi siamo convinti che almeno questi  banali errori, con molta probabilità, non li commetterà più un Project Manager certificato.

 

Vito Madaio - esperto di project management di lunga data - Già Service Manager alla Camera dei deputati per Cap Gemini;  Direttore Sistemi Informativi del Gruppo Skandia e Architetto di Sistemi di IBM Italia. Attualmente, da circa 10 anni Responsabile di TenStep Italia  e  REP del PMI, si occupa principalmente di Certificazioni PMP, CAPM Agile PMI-ACP,  oltre a diffondere l’adozione della Metodologia di Project Management TenStep.

 

TenStep Italia dispone di servizi di formazione  che possono soddisfare ogni tua esigenza nell'ambito del project management e relative certificazioni.

    Clicca qui e comunicaci la tua esigenza