Gestione dei progetti

SCOPE CREEP.

Lo scope creep rappresenta un cambiamento non controllato nello scope del progetto.

Inizialmente, si parte da un punto A con un progetto che ha budget, tempo e qualità target. In

questo caso, le specifiche tecniche prevedevano il trasporto di 11 persone ad una velocità

elevata. Tuttavia, quando si modifica a un certo punto le specifiche del progetto, si genera uno

scope creep determinato da una richiesta del cliente. Tale richiesta crea una serie di

conseguenze, come la necessità di munizioni in caso di aggiunta del cannone, comportando la

perdita di una parte dello scope del progetto, ovvero la capacità di trasportare persone. Ciò

porta a una modifica della qualità e, verosimilmente, della durata e del budget del progetto. La

durata cambia perché, pur mantenendola fissa, si perde tempo tra la prima e la seconda

progettazione; inoltre, se si accetta l'aggiunta del cannone, il veicolo potrebbe essere

percepito dal nemico non come un mezzo di trasporto, ma come un veicolo ostile, con il

rischio di essere attaccato per primo.

Di conseguenza, si rende necessario rinforzare le paratie. Inizialmente, per garantire la

velocità del veicolo, le paratie erano realizzate in alluminio, materiale leggero ma poco

resistente. Successivamente, si opta per l'acciaio, un materiale opposto in termini di peso e

resistenza. Pertanto, con questo adattamento, si raggiunge una qualità pari a 2, poiché,

rispetto alla qualità 1 iniziale, si è eliminata la capacità di trasportare persone e si è sacrificata

la velocità.

Successivamente, la richiesta di collocare i missili sopra comporta ulteriori modifiche, con la

rimozione di ulteriori posti per le persone. Inoltre, avendo i missili sopra, si limita la capacità

di salire e scendere rapidamente, portando il progetto ad una qualità 3.

In altre parole, ogni modifica alle specifiche influisce sulla durata e sul budget, portando alla

realizzazione di un prodotto diverso da quello inizialmente concepito; questo fenomeno è

conosciuto come SCOPE CREEP, un'estensione o variazione dello scope del progetto non

pianificata.

Questo approccio non è auspicabile, poiché le modifiche allo scope devono essere

attentamente valutate, approvate e dichiarate. Quando avvio il progetto, valuto le performance

su un budget, una durata e una qualità inizialmente stabiliti. Qualsiasi variazione comporta

una durata finale, un budget e una qualità differenti. Di conseguenza, se si valuta l'operato

dell'intero project manager, si potrebbe considerare il progetto come un disastro.

L’unica possibilità è quella di dichiarare uno scope change che deve essere accettato dal

cliente per permettere al progetto di continuare. Tuttavia, non è possibile apportare modifiche

illimitate allo scope. Questo non implica l'abbandono della parte precedente, ma significa

ridefinire lo scope. Tuttavia, persistere con continue ridefinizioni dello scope comporta il

rischio che il progetto cambi in modo continuo e non giunga mai a conclusione. L'aspetto

fondamentale è che ogni modifica debba essere formalizzata.

Pertanto, lo scope creep è una situazione da evitare. Tipicamente, il cliente presenta richieste

di aggiunte al progetto, e anche se queste sono retribuite, richiedono autorizzazioni e

variazioni di progetto. Tuttavia, è comune che il cliente non tolleri estensioni temporali. Di

conseguenza, è essenziale effettuare una valutazione accurata per determinare se si è in grado

di aggiungere la nuova caratteristica entro i tempi stabiliti, ottenendo un maggiore guadagno.

Una volta completata la valutazione, viene presentata al cliente una proposta e, se accettata, si

procede con la firma della variazione contrattuale.

Ogni richiesta deve essere valutata accuratamente, specialmente considerando che la durata

del progetto è un elemento critico e che aggiunte minime possono facilmente prolungare il

periodo necessario per il completamento. Di conseguenza, è fondamentale una corretta

valutazione di ciascuna richiesta.

Quindi, le cause di fallimento di un progetto possono riguardare:

1) Mancanza di chiarezza su obiettivi minimi di progetto



2) Disallineamento tra progetto e strategia aziendale se un progetto è disallineato dalla

strategia aziendale, risulta poco interessante e può generare un effetto a cascata di

disattenzione e scarso coinvolgimento a livello organizzativo



3) Shifting requirements spostamento dei requisiti tecnici



4) Complessità tecnica l’acquisizione di un progetto troppo complesso per le capacità

aziendali può portare al fallimento



5) Pianificazione irrealistica promettere risultati che non possono essere realizzati,

come completare un progetto in un periodo di tempo troppo breve, può portare al

fallimento 

6) Mancanza di revisione a cadenze prefissate della pianificazione la mancanza di

reattività nella pianificazione porta al fallimento

1.7 Possibili soluzioni al fallimento

L'obiettivo generale è il successo del progetto; a tal fine, le strategie da adottare per aumentare

la probabilità di successo in un progetto sono:

 Gestire la strategia e gli stakeholder in primo luogo, è necessario gestire un progetto

allineandolo a livello strategico e gestire opportunamente i portatori di interesse.

È essenziale avere:

obiettivi chiari,

- un business case ben definito (ovvero un documento che autorizza l'avvio di un

- progetto, riportante il motivo, i portatori di interesse, l'obiettivo tecnico minimo, la

durata, il budget e, eventualmente, un'analisi di investimento) che viene prodotto dallo

sponsor di progetto per ottenere l'approvazione della direzione generale e ciò vale sia

per progetti in risposta a una richiesta di offerta sia per progetti di ricerca e sviluppo;

allineamento con i principali portatori di interesse;

- un project scope minimo stabile;

- un rapporto robusto con fornitori e cliente con chiare responsabilità, poiché molte

- volte il fallimento di un progettoè determinato da ritardi nelle forniture o

incomprensioni, specialmente in progetti che coinvolgono diverse imprese;

supporto da parte degli executive.

-

 Padroneggiare tecnologia e contenuti utilizzare tecnologie comprovate e coinvolgere gli

utenti nella definizione tecnica della soluzione.

 Costruire il team e le capacitàdotarsi di un project manager con esperienza, un team

qualificato e motivato ed un mix sostenibile di risorse interne ed esterne.

Quando si considera l'esternalizzazione, è opportuno valutare attentamente le attività che

l'azienda è già in grado di gestire internamente, ma dalle quali potrebbe beneficiare di un

apprendimento aggiuntivo attraverso l’esternalizzazione da fornitori più esperti. Questo

processo di esternalizzazione con finalità di apprendimento è particolarmente vantaggioso

per le attività core dell'azienda. D'altra parte, per le attività non core, è giusto

esternalizzarle senza un focus specifico sull'apprendimento interno. È importante notare

che l'esternalizzazione di attività in cui si desidera apprendere da fornitori più esperti

comporta inevitabilmente dei costi, ma tali costi sono finalizzati alla crescita e allo

sviluppo delle capacità aziendali nel lungo termine

 Eccellere nelle pratiche di project management utilizzare stime e piani affidabili,

garantire adeguata trasparenza sullo stato del progetto e adottare metodologie e strumenti

collaudati.

1.8 Project, Program e Portfolio



PROGRAM PROJECT

Il programma differisce dal progetto, anche se talvolta vengono utilizzati come sinonimi. Le

logiche di programma sono diverse da quelle di progetti, in quanto un programma rappresenta

un insieme di progetti correlati, gestiti in modo integrato e coordinato; mentre il portafoglio

costituisce una raccolta di programmi e progetti.

Generalmente, il PROGRAMMA si configura come un’iniziativa di lungo periodo che include in

sé diversi progetti e ragiona a livello di beneficio complessivo. L'aggregazione di progetti

all'interno di un programma può avvenire sulla base di logiche di condivisione di risorse,

logiche temporali o di competenza.

Ad esempio, considerando lo sviluppo di software per la creazione di un sistema di gestione

dei magazzini, indirizzato a quattro clienti distinti, si avranno quattro differenti progetti,

ognuno dei quali presenta logiche di gestione magazzino, durata e budget specifici. Tuttavia, il

software di base e le personalizzazioni possono risultare simili in termini di moduli software

da sviluppare. Se un programmatore sta lavorando su un modulo (ad esempio, modulo A), il

risultato ottenuto può essere proposto su tutti e quattro i progetti. Non significa

necessariamente che il programmatore lavori in parallelo su tutti i progetti, ma che ciò che è in

fase di sviluppo è spendibile su tutti e quattro i progetti.

Questo approccio consente di ottenere quattro risultati mediante un unico lavoro, ma

coordinare tale sforzo può risultare complesso, e questa responsabilità è oltre le competenze

del project manager, il quale gestisce solamente il suo progetto.

Esiste dunque il PROGRAM MANAGER, il quale non si occupa della gestione diretta di singoli

progetti, bensì del coordinamento tra progetti omogenei in termini di competenze, attraverso

la gestione di risorse umane ed esperienze che vengono spostate da un progetto all'altro.

Il vantaggio viene valutato in termini di beneficio complessivo derivante dai quattro progetti.

Se uno di essi presenta esiti negativi e tre risultano molto positivi, l'analisi complessiva è

positiva, rendendo efficace il programma.

Un programma può anche essere osservato con una prospettiva longitudinale, dove il cliente

richiede un primo prodotto e si impegna a ripetere la stessa commessa per diversi anni. In

questo contesto, potrebbe verificarsi che il primo progetto comporti perdite, ma la ripetizione

nel tempo per lo stesso cliente può portare al recupero delle spese. Questa situazione rientra

anch'essa nella definizione di programma. Il vantaggio non va misurato esclusivamente sul

primo progetto che risulterà essere in perdita, in quanto non si riusciranno a recuperare i

costi di ricerca e sviluppo, ma sui successivi che saranno più avanzati tecnologicamente.

Pertanto, i progetti all'interno del programma sono tra loro collegati.

Nel caso di un progetto di ricerca e sviluppo per prodotti complessi, si definiscono anche le

modalità di costruzione, manutenzione e dismissione. Pertanto, si delineano un progetto di

R&S, uno di costruzione degli impianti, uno industriale, uno manutentivo e uno di d