UDA 13 - Scope management - 13.1 Lo Scope management

21 Novembre 2014

di Maria Pia Accogli

13.1 Lo Scope management

Lo Scope Management è una attività che parte dalla pianificazione di progetto con la definizione della lista di obiettivi specifici del progetto, dei deliverable, delle attività, dei costi e delle scadenze. L’insieme di questi elementi è definito come ambito del progetto. Definire dettagliatamente e documentare lo scope di un progetto è un elemento fondamentale, occorre descrivere i confini del progetto, stabilire le responsabilità di ciascun membro del team e stabilire le procedure di verifica e di approvazione di un lavoro completato. Nel corso di un progetto, questa documentazione aiuta il team di progetto a rimanere concentrato sulle attività e fornisce al team le linee guida per prendere delle decisioni inerenti le numerose richieste di modifica “Change Request” che solitamente si verificano. Per i grandi progetti è naturale avere dei cambiamenti durante il ciclo di vita del progetto, quindi è importante che lo scopo del progetto venga definito puntualmente all’inizio in modo che il team di progetto sia in grado di gestire i cambiamenti. Nel documentare lo scopo del progetto, le parti interessate (committente e fornitore di servizi) devono essere puntuali il più possibileper evitare situazioni in cui una o più parti del progetto possano finire col richiedere più di quanto non sia stato definito e concordato. Lo scopo di un progetto non può essere definito in modo generico o per grandi linee, una scarsa pianificazione con obiettivi di tipo generale e scarsamente definiti o una comunicazione poco efficiente solitamente portano un progetto al fallimento. Per una gestione efficace del progetto è fondamentale che tutti i membri del team conoscano chiaramente lo scopo del progetto. Durante un progetto arrivano spesso suggerimenti finalizzati a possibili miglioramenti dei tempi, delle prestazioni e delle caratteristiche degli output di progetto, il più delle volte questi suggerimenti sono validi ed opportuni. Il problema è che questi suggerimenti spesso fanno saltare tutti i parametri di pianificazione e rischiano di far fallire il progetto; questo processo è detto scope creep, dove creep sta per subdolo, furtivo, strisciante, improvviso, cioè piccoli cambiamenti ma non governati dello scope del progetto. Se non viene affrontato e gestito adeguatamente lo scope creep può portare vari tipi di difficoltà:

• se il suggerimento viene accettato allora nel progetto si possono aggiungere compiti inizialmente non pianificati che possono portare al superamento dei tempi, all’aumento dei costi oppure a uno scadimento della qualità tecnica degli output;
• se il suggerimento non viene accettato l’azienda può rischiare di perdere delle vere ed importanti opportunità.

Queste situazioni, apparentemente senza soluzione, si affrontano con un apposito progetto di scope management che permette di aggiornare il piano di progetto con le dovute conseguenze in termini di tempi, costi o qualità. Al momento di avvio di un progetto di scope management occorre fare attenzione perché solitamente in questi casi si creano delle situazioni che rischiano di rendere il progetto di scope management inefficace, per esempio:

• tutti gli utenti, ognuno secondo le proprie esigenze e preferenze, hanno sempre un lungo elenco di esigenze aggiuntive da presentare per migliorare gli output; molte di tali richieste possono essere interessanti e spesso in grado di apportare effettivi benefici all’azienda;
• in alcuni casi possono intervenire delle esigenze di tipo normativo, a volte indispensabili, che richiedono una interruzione del progetto necessaria per ripianificare e riprogettare;
• i fornitori esterni tendono a indirizzare le soluzioni a seconda della loro convenienza:
  • - se sono sicuri dell’affidamento delle attività, in fase di progettazione, tendono a massimizzare i tempi e le caratteristiche tecniche per generare il massimo profitto per loro;
  • - se hanno delle soluzioni già pronte spingono in direzione di queste;
  • - se non hanno il personale disponibile tendono a minimizzare le opportunità evidenziandone gli aspetti negativi.
• i componenti del team spesso si impegnano oltre il necessario sviluppando soluzioni che vanno oltre le esigenze per l’utente; solitamente adottano questi atteggiamenti per dimostrare la loro competenza ed l’importanza del loro ruolo nel progetto;
• gli utenti richiedono l’inserimento nel progetto di appositi prodotti finali o intermedi, per esempio richiedono consegne particolari in coincidenza con eventi importanti;
• spesso vengono prodotti modelli dimostrativi di output che non sono stai pianificati e che richiedono impegno aggiuntivo e altro tipo di risorse.

Un progetto per avere successo deve saper accogliere il cambiamento, apportare piccole modifiche e soddisfare delle esigenze come quelle sopra esposte. A volte questo può essere più conveniente per l’azienda soddisfare tali richieste piuttosto che avviare un nuovo progetto. Altre volte però gli effetti del cambiamento possono essere destabilizzanti in varie direzioni. Per esempio la soluzione può richiedere al progetto dei cambi in modo non perfettamente controllato oppure le persone impegnate nel progetto si ritrovano ad operare in situazioni di incertezza.

Tutte queste situazioni hanno in comune il fatto che, a un certo punto del progetto, gli obiettivi possono non coincidere più con quelli riportati nel PID ed il progetto non riesce più a restare negli ambiti previsti. Un attento processo di controllo delle modifiche è fondamentale, però il processo dello scope control necessità di operare in modo integrato con altri processi di controllo che si concentrano sulle modalità di gestione dello scopo del progetto e sull’impatto di tali modifiche, come il processo di risk management che verrà trattato nella unità didattica seguente del libro.

Un metodo pratico ma efficace di monitorare e gestire le iniziative di scope management per il project manager è quello di delegare compiti e responsabilità ad altri membri del team definendone gli ambiti di intervento. I membri del team, non potendo approvare interventi che vanno oltre gli ambiti definiti, tendono a mantenere tali attività entro i limiti loro consentiti evitando al progetto di dover assorbire impatti di portata eccessiva.

Un esempio di progetto discope management

Un classico esempio di scope management, nei progetti di innovazione tecnologica che riguardano la Pubblica Amministrazione Locale (PAL), consiste negli adeguamenti di progetto che riguardano innovazioni normative che avvengono in corso d’opera. Un classico esempio è quello di esigenza di modifica della modulistica che è uno degli elementi fondamentali per la definizione, standardizzazione ed automazione dei processi della PAL. Uno dei settori attualmente più interessati in questi tempi a queste problematiche è quello dell’edilizia dove è in corso un processo di rinnovamento che ha interessato prima il livello regionale ed ora si propone a livello nazionale. L’introduzione anche di piccole variazioni normative in questi settori che interessano sia i processi che la modulistica impongono:

a.       adeguamenti tecnici a livello di automazione:

• interfacce di inserimento dati per la gestione dei nuovi modelli;
• banche dati per l’inserimento di nuove informazioni;
• workflow dei processi di gestione;

b.      attività di avvio a livello organizzativo:

• integrazione delle banche dati;
• formazione del personale;
• riorganizzazione dei compiti del personale (revisione dei processi interni aziendali).

Tutte queste attività richiedono dei sotto progetti completi di tutte le fasi di: pianificazione, progettazione, realizzazione e avvio. Chiaramente se le richieste dimodifica, dei precedenti punti a. e b., intervengono durate la realizzazione del progetto prima che le attività siano eseguite allora si ha sicuramente un impatto minore rispetto al caso in cui le attività siano già state eseguite. È di fondamentale importanza valutare l’impatto sul progetto prima di tutto in termini di tempo e costi e poi per decidere in che modo intervenire, se all’interno del progetto stesso o con un altro progetto esterno.

Le conseguenze sul progetto in questi casi possono essere decisive anche per il risultato globale dello stesso.

• < Prec
• Succ >