I progetti di successo sono per definizione quelli in cui vengono realizzati i risultati voluti, alla data stabilita. Questo da un punto di vista tecnico. Tuttavia una buona gestione progettuale non può prescindere dalla soddisfazione del cliente finale che influenza in modo determinante l’effettiva chiusura del progetto.
Solitamente un progetto si chiude con l’accettazione formale del collaudo applicativo ma soprattutto all’atto del pagamento da parte dell’azienda cliente per l’intero lavoro svolto. Ebbene è in questa fase finale che si possono avere le sorprese peggiori. Un cliente insoddisfatto può impedire la naturale e si potrebbe dire “salutare” chiusura del progetto, contestando il successo del collaudo fino ad arrivare alla contestazione del pagamento.
Il problema nel rapporto con il cliente
Perchè questo accade? In quali casi? Ammettendo una perfetta e inoppugnabile gestione che avesse conseguito tutti gli obiettivi iniziali nei tempi previsti e indicati formalmente dal gantt di progetto, ci si può trovare nella sgradevole condizione di ritrovarsi un cliente altamente insoddisfatto, che lamenta la mancanza di qualità nel progetto.
I maggiori standard oggi esistenti in materia di Project Management spiegano che, in ogni progetto, parlare di qualità significa parlare di aderenza ai requisiti richiesti dal committente/beneficiario finale del progetto. Tuttavia un generico cliente considera la change request come un requisito da eseguire al pari delle richieste iniziali di progetto. Perciò la mancata gestione delle change request è uno dei motivi di decadimento della qualità progettuale generale.
Secondo le fonti ufficiali di Project Management, in informatica una “change request” è definita formalmente come: «una richiesta di modifica alla configurazione del software». Una change request può riguardare, bug applicativi, nuovi requisiti da implementare, problemi di performance ma anche problemi di usabilità/accessibilità. Quale che sia l’oggetto della change request, il fatto principale rimane: il project manager si trova a dover valutare la richiesta imprevista e potenzialmente complessa effettuata dal cliente.
La change request può riguardare un lavoro già rilasciato dal fornitore, ma è particolarmente critica se presentata durante le fasi di implementazione e di rilascio. In queste fasi infatti la progettazione e la pianificazione di dettaglio delle diverse porzioni del progetto, sono già state effettuate e una richiesta inaspettata genera un indiscutibile aggravio operativo.
A fronte di tali richieste si è portati a pensare che le risposte possibili siano sostanzialmente due: il sì o il no.
Dire sempre si: secondo questa scuola di pensiero, non così rara in molte realtà aziendali dei giorni nostri, si deve sempre accontentare il cliente finale e si accetta qualsiasi richiesta di variazione progettuale come una richiesta lecita e doverosa all’interno del contratto in essere e della relativa valutazione economica generale.
Riportare queste richieste all’interno del gantt di progetto spesso causa un aumento critico delle attività già schedulate, rispetto ai periodi di consegna previsti; tutto questo a causa del semplicistico tentativo di mantenere inalterate le date finali di consegna. Solitamente ciò non avviene mai e ci si ritrova di fronte al rischio e molto spesso alla spiacevole evenienza di non ottemperare le date finali di consegna dei diversi rilasci, con la pericolosa esposizione della commessa alle penali di progetto.
Dire sempre no: in questo secondo caso il “dictat” è non far passare alcuna change request prima della fine prevista di tutti gli step principali di progetto rimandando a dopo il collaudo qualsiasi altra implementazione.
In questo caso è possibile che il progetto non giunga mai a termine, perché una serie consistente di change request volutamente ignorate o peggio immancabilmente rifiutate e rimandate, generano un utente che, profondamente scontento dell’intera qualità progettuale, può arrivare a rifiutare il collaudo positivo compromettendo così il conseguente pagamento dell’intera fornitura.
Come spesso accade la verità è nel mezzo.
Flusso di gestione change request
La soluzione ottimale si realizza mediante una gestione opportuna delle change request, ovvero è necessario prevedere un flusso di controllo delle stesse. Il primo passo è la preparazione di un modulo apposito da condividere con il cliente. Il modulo deve contenere essenzialmente due parti; una compilata in fase di richiesta dal cliente e l’altra compilata in risposta da parte di qualcuno dello staff di progetto.
- Le informazioni principali a carico del cliente:
- Titolo del progetto a cui si riferisce la change request
- Numero della richiesta
- Oggetto della richiesta
- Descrizione approfondita della funzionalità o della parte di applicazione che si desidera venga modificata.
- Le informazioni principali a carico dello staff di progetto:
- Tempo previsto per la chiusura dell’implementazione richiesta
- Impatto sul gantt di progetto (in termini di pianificazione dell’attività)
- Costo risultante per l’intervento richiesto
- Analisi del rischio connesso all’implementazione della change request in relazione all’intero progetto.
Infine è necessario prevedere il campo “approvazione della change request” che viene compilato solo dopo il confronto fra il cliente e il Project Manager. L’accettazione o il rifiuto alla implementazione della change request scaturisce dall’analisi puntuale del tempo/costo stimato per la realizzazione e dall’accettazione da parte del cliente non solo dei costi di realizzazione, ma anche della eventuale ripianificazione delle attività di progetto che possono risultare influenzate come previsto dall’analisi del rischio (punto B4).
Un tipico flusso di gestione della change request è basato sulle attività di:
- Sottomissione di una richiesta, attraverso la compilazione del modulo apposito e l’invio allo staff di progetto,
- Verifica iniziale da parte dell’analista software ed eventuale richiesta di chiarimenti rimandata al cliente,
- Analisi di approfondimento della change request al fine di identificare i costi, il tempo e il rischio di implementazione,
- Aggiornamento del modulo della change request da parte dell’analista software,
- Condivisione dell’analisi fra il cliente e il project manager con conseguente decisione sull’approvazione della change request ,
- Aggiornamento del modulo della change request relativamente al campo “approvazione change request”
- Implementazione della richiesta effettuata.
Strumenti informatici
Per facilitare la gestione del flusso di change request a tutti gli attori coinvolti, sono disponibili sul mercato diversi tool informatici di supporto. Questi software genericamente consentono di memorizzare, tracciare, assegnare, gestire la priorità e le versioni delle change request.
La caratteristica principale di questi software è quella di consentire la gestione di flussi di lavoro e nonostante abbiano il nome generico di “change request management systems” sostanzialmente si tratta di sistemi di workflow management. Alcuni consentono la creazione di un flusso di lavoro, al fine di adeguarlo alle esigenze specifiche del team di lavoro. Altri offrono un flusso di gestione delle change request già pronto, consentendo minime personalizzazioni di configurazione.
Altra caratteristica immancabile è la gestione del modulo di descrizione delle change request. Anche in questo caso si possono avere moduli preformati con la possibilità di lievi modifiche, oppure è disponibile la funzionalità di creazione ex-novo di un modulo che abbia tutte e sole le caratteristiche necessarie al team di lavoro.
Le principali funzionalità disponibili per questi software riguardano:
- Funzionalità di disegno del flusso di gestione delle change request secondo le specifiche esigenze dell’utente e del team di lavoro,
- Gestione di un flusso pre-impostato delle change request che nella configurazione minima prevede: inserimento, analisi, implementazione, chiusura.
- Possibilità di supportare diversi progetti di sviluppo attivi contemporaneamente,
- Gestione univoca degli identificativi di change request con allaccio automatico al progetto di riferimento,
- Gestione delle priorità per ogni change request ,
- Disponibilità di valori di input pre-impostati per il modulo delle change request,
- Protezione dalla modifica per alcune tipologie di campi del modulo delle change request,
- Disponibilità di diverse tipologie di reports per la stampa delle change request,
- Flessibilita’ nella selezione di diversi criteri per la generazione dei report,
- Funzione opzionale di notifica via mail degli stati di avanzamento del flusso delle richieste sia verso il cliente sia verso il team di progetto.
I software possono diversificare in relazione alla architettura. Alcuni sono Client/Server mentre i più comuni prevedono un’architettura Web Based che ha chiaramente il vantaggio di poter essere condivisa fra gli utenti eventualmente decentrati rispetto alle sedi di lavoro di appartenenza.
In conclusione
«Change happens», l’importante è gestire i cambiamenti potenzialmente inattesi e complessi in modo funzionale e collaborativo. La condivisione delle change request realizzata mediante l’ausilio di software appositi, consente una migliore decisionalità sia da parte del cliente sia da parte del team di lavoro che possono così concordare le azioni da seguire. Questa modalità di lavoro consente di preservare ottimi rapporti cliente/fornitore perchè aumenta la percezione della qualità da parte del cliente ma oggettivamente migliora la qualità generale del progetto.
