La gestione delle change request

Mezzi tecnici e metodi per mantenere rapporti proficui con il cliente senza l'obbligo di accettare ogni richiesta

Alessia Valentini - 14 novembre 2007

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.

Leggi tutto su:

project management

4commentiLeggi inserisci un commento

4 risposte a “La gestione delle change request”

Marco Olly scrive:

15 novembre 2007 alle 12:37

Esaustivo come articolo e scritto bene.
Unica cosa, se posso, che avrei citato il nome di qualche “change request management system”.

Rispondi
Vito Madaio scrive:

20 novembre 2007 alle 11:08

Complimenti ad Alessia.
L’articolo è un dell’esempio di gestione delle richieste di modifiche di un progetto. Anche se demonizza troppo il cliente, temendo di sforare i tempi a causa dell’implementazione delle modifiche.
Se posso dare un modesto contributo, direi che le richieste di modifiche sono inevitabili e non essite la facoltà di dire si o no, ma soltanto di dimostrare, come suggerisce Alessia, l’impatto sul progetto in termini di costi, tempi e qualità del progetto. Con questa analisi il Project Manager è tenuto a sottoporre all’approvazione dello Sponsor una soluzione, magari tra più alternative, incluso il rifiuto. L’approvazione non è una questione di campo “approvazione della change request” ma è un processo decisionale che non si può concludere tra team di progetto e cliente inteso come utente. L’approvazione (o il rifiuto) è responsabilità dello Sponsor Committente, esattamente come la firma del contratto iniziale.
L’approvazione può comportare sostanziali modifiche alla baseline di progetto (nuovo budget, nuovi tempi). Una volta ottenuta l’approvazione da parte dello Sponsor del progetto, il project manager deve gestire la nuova schedulazione ed il nuovo budget e l’utente non potrà obiettare nulla in fase di collaudo.
Comprendo il timore delle micro richieste che stressano il project manager, ma in questi casi il trucco è raccoglierne un certo numero, valutarne l’impatto complessivo e sottoporle lo stesso all’esame dello Sponsor. Se il progetto è già critico, sarà interesse dello Sponsor proteggerlo dal disturbo delle micro richeste, rinviandole a momenti successivi (nouvo progetto). La persona più interessata al rispetto dei tempi e del budget di progetto è proprio lo Sponsor e non l’utente che dal suo punto di vista vorrebbe sempre il meglio in ogni caso.
Sulla conclusione, concordo con la necessità di un sistema rigoroso (l’utente direbbe rigido), e aggiungerei che si tratta pur sempre della gestione della comunicazione. Il Poject Manager ha il dovere di comunicare proattivamente le decisioni assunte ad assicurarsi che il cliente-utente le abbia recepite correttamente.
Questi concetti sono alla base della gestione dell’ambito, secondo la metodologia TenStep, che rappresento in Italia.
Cordiali saluti.
Vito Madaio

Rispondi
Alessia scrive:

27 novembre 2007 alle 12:10

gentile Dott. Madaio
la ringrazio per il suo contributo. Vorrei farle una domanda. Nella mia esperienza di PM, lo Sponsor committente e il cliente erano spesso appartenenti alla medesima realtà aziendale. Quindi sia presso società private che in Pubblica Amministrazione, ho avuto dei referenti che controllavano sia la gestione del progetto (lato cliente) sia i diversi deliverable. E’ invece molto frequente che lo Sponsor sia diverso dal Cliente finale?

Rispondi
Vito Madaio scrive:

5 dicembre 2007 alle 14:43

I ruoli degli attori di un progetto a volte tendono a sovrapporsi, ma la letteratura è chiarissima al riguardo.
Lo SPONSOR è colui che finanzia il progettto, ossia il committente per eccellenza. Il REFERENTE è colui che ha qualche interesse nel progetto, ad esempio è colui che rappresnta gli utenti finali del prodotto da realizzare; è operativo e di solito è diverso dal proprietario del progetto (il progetto appartiene allo Sponsor; il project manager è responsabile di raggiungere il risultato, mentre il referente lo controlla).
Quindi Sponsor e Referente, anche se stanno dalla stessa parte hanno ruoli diversi nei confronti del project manager, il quale deve ascoltare le richieste di modifiche del referente, valutarne l’impatto e sottoporre le soluzioni alternative allo sponsor, il quale potrà decidere di accettarle o rifiutarle. Ad esempio, la Direzione di una azienda affida lo sviluppo di un prodotto ad un fornitore sulla base di budget e tempi precisi, nomina un referente del progetto, scelto tra gli utenti finali per i dettagli.
Il referente collabora con il project manager alla realizzazione del prodotto, ma qualsiasi modifica al contenuto deve essere decisa dallo Sponsor e non dal referente.
Però, non va dimenticato che il referente gioca un ruolo fondamentale nella fase di collaudo ed accettazione del prodotto finale.

Rispondi

Chiudi i commenti

Lascia un Commento

Speciale IMU
IMU 2012: guida alla Tassa sulla Casa. I servizi online offerti dai Comuni, le simulazioni di calcolo, gli strumenti messi a disposizione dai Comuni più grandi e le agevolazioni previste. In più si possono trovare tutti i dettagli sulle scadenze delle rate e le modalità di pagamento.

Speciale Riforma del Lavoro 2012
La Riforma del Lavoro 2012 del Ministro Elsa Fornero e del Governo Monti: testo, trattative, news, le opinioni e le proposte delle parti sociali, i nodi su articolo 18 e licenziamenti, i nuovi contratti e tutte le novità sull’iter parlamentare della proposta di Riforma del Governo.

Speciale Modello 730 2012
Modello 730: aggiornamenti, novità sulle detrazioni, scadenze e guida alla compilazione dei modelli di Dichiarazione dei Redditi.

Le News Locali di PMI.it
L'informazione a carattere regionale per il mondo delle imprese: finanziamenti, progetti e opportunità dagli enti locali e dalle camere di commercio.

Speciale Riforma delle Pensioni
Analisi delle misure punto per punto della nuova disciplina: calcolo pensione con sistema contributivo, innalzamento età pensionabile, blocco rivalutazioni, pensioni di vecchiaia, eccezioni e casi particolari.

Speciale Regime dei Minimi 2012
Tutte le novità su riforma, nuovo regime contabile agevolato ed ex minimi: requisiti per nuovi contribuenti minimi e opzioni per ex minimi, esclusione dal regime e vantaggi per imprenditori under 35 e in mobilità, decreti attuativi e chiarimenti dell'Agenzia delle Entrate.

PMI.it e i suoi partner

Oracle Sfruttare in modo efficace le risorse aziendali come hardware, database e sistemi legacy. Accrescere e potenziare i servizi ai clienti. Scopri come, grazie ad Oracle