La scorsa settimana ho ricevuto questa email da un nostro cliente:
Buongiorno [responsabile commerciale] e Antonio,
vi comunichiamo il nostro disappunto riguardo il vostro comportamento e il lavoro finora svolto.
Riteniamo che le numerose richieste di modifica in corso d’opera che vi stiamo sottoponendo siano la diretta conseguenza del vostro lavoro. Ci riferiamo al fatto che noi vi avevamo chiesto a_b_c e invece voi ci avete proposto d_e_f. Potrete concordare con noi che in questo modo non è stato raggiunto il nostro obiettivo. Ci troviamo ora a dover mettere in linea un prodotto che non è quello che volevamo.
La nostra critica si basa fondamentalmente sulla mancanza di idee e proposte da parte vostra che siete gli esperti del settore e sul vostro atteggiamento di mera esecuzione di ordini a seguito delle nostre richieste, che si basano sull’esperienza nel nostro settore, che a quanto pare non si possono sempre tradurre in campo informatico.
E’ la prima volta che ricevo una missiva del genere: c’è da rimanere sconcertati, vero?
Un messaggio con questo tono non arriva come un fulmine a ciel sereno, ma è una diretta conseguenza a una nostra email in cui, senza tanti complimenti, abbiamo chiesto al cliente di permetterci di chiudere le diverse attività in cantiere senza aggiungerne in continuazione di nuove. Non si fa così. Questo è però solo l’ultimo di una serie di errori che, da una parte e dall’altra, hanno caratterizzato la vita dell’intero progetto.
Prima di cominciare ad analizzare cosa non ha funzionato vale però la pena di inquadrare il progetto nel suo contesto e fornire qualche cifra di riferimento:
- i primi incontri per la definizione del progetto insieme al cliente si svolgono a Giugno 2007, più di un anno fa;
- il progetto prevede la realizzazione di un sito di presentazione, ricerca, prenotazione e di ecommerce non standard, che attinge ad anagrafiche e listini presenti in gestionali usati dal cliente;
- il sito va a sostituire una precedente versione, anche questa realizzata da noi;
- dopo aver raccolto gli elementi utili da più fonti e aver svolto diverse analisi, ad Agosto del 2007 è presentato e motivato al cliente un prototipo funzionante dell’intera applicazione. Prototipo lasciato a disposizione per ogni valutazione;
- l’impegno previsto per la realizzazione del progetto è stimato in circa 350 ore uomo, con data di consegna 15 Febbraio 2008.
Il cliente, anche se non sembrerebbe leggendo l’email, è stato coinvolto in ogni fase del progetto:
- la raccolta di elementi utili per la progettazione del sito è partita da una serie di incontri in cui il cliente ha espresso le proprie esigenze;
- abbiamo presentato un prototipo funzionante dell’applicazione condividendo ogni scelta;
- abbiamo realizzato, in un ambiente accessibile al cliente, circa 5 rilasci intermedi su dati reali per verificare le diverse funzionalità
Sembrerebbero le basi su cui realizzare un prodotto apprezzato. L’email ricevuta non lascia però spazio ad alcun dubbio: il cliente è insoddisfatto, è convinto che questo non sia il prodotto richiesto e manifesta chiari dubbi sulla competenza della società che li ha accompagnati in questo percorso. Come è possibile?
Se analizziamo più approfonditamente quello che è successo nell’arco di questi 12 mesi si capisce che in realtà di errori ne sono stati commessi tanti, troppi, da ambo le parti. Ecco i principali:
- Errore 1: c’è bisogno di un sito nuovo (?) – Tutto comincia quando il cliente manifesta perplessità per alcune problematiche del sito attualmente online. Si tratta di alcuni bug e soprattutto di problemi relativi all’usabilità e non coerenza dell’interfaccia di navigazione. Il cliente viene convinto a riprogettare da capo l’intero sito, promettendo un’applicazione più usabile, più veloce, migliore. Viste le richieste, sarebbe forse stato più semplice sistemare quanto era già online.
- Errore 2: ti costa 100. No 300. Vabbè facciamo 200 – Al cliente è proposto un investimento contenuto, il tutto senza verifiche. Dopo una breve sessione di macroanalisi si evince che l’impegno è invece circa tre volte rispetto quanto promesso. A questo punto inizia il tira-e-molla che porta il prezzo finale a circa il doppio, una via di mezzo che non fa felice nessuna delle due parti.
- Errore 3: un cliente fantasma – Non abbiamo spiegato chiaramente al cliente che avremmo avuto bisogno, per tutta la durata del progetto, del suo apporto. Trovandosi davanti a un prototipo funzionante alcuni clienti sono infatti convinti che sia già stato fatto tutto, che sia sufficiente procedere con l’implementazione e vedersi consegnato il progetto dopo alcuni mesi. Nel documento di progetto va invece quantificato l’impegno richiesto al cliente in termini di verifica funzionalità, test, prove sul campo e supporto per le inevitabili domande che nascono nello sviluppo di tutti i giorni. Il cliente ha inoltre risposto con enorme ritardo ad ogni comunicazione che gli è stata inviata. Alcune email non hanno ricevuto risposta, altre dopo un mese, con casi di risposte dopo ben 5 mesi rispetto alle richieste. Abbiamo più volte sollecitato il cliente, via email e verbalmente, senza alcun risultato apprezzabile.
- Errore 4: referenti aziendali non all’altezza – Punto cardine di un progetto di successo è l’interazione con referenti aziendali competenti e in grado di farsi portavoce delle richieste dei consulenti e dell’azienda per cui lavorano. Così non è stato. Il progetto è stato affidato a un dipendente part-time dell’azienda che non è riuscito a trasmettere dubbi, perplessità, richieste, proposte. Come se non bastasse un altro attore del progetto, che ha seguito la precedente realizzazione del sito, lavora part-time con orario di lavoro non coincidente con quello del referente principale. Non è sempre facile accorgersi della presenza di un referente non motivato, ma quando succede l’azienda va immediatamente informata oppure la situazione, come in questo caso, precipita. E, nella maggior parte dei casi, è il web project manager a dover alzare la mano.
- Errore 5: il software si modifica anche all’ultimo minuto – Il software è un prodotto di ingegneria. Il fatto che un progetto web sia accessibile da un monitor fa sì che il cliente non sempre riesca a valutare, diversamente da altre opere di ingegneria, l’impatto di alcune richieste di modifica. Aver presentato un prototipo funzionante ha lo scopo di confrontare proposte e punti di vista, ma anche di limitare il numero di modifiche in corso d’opera. In realtà nulla è scolpito nella pietra e, come ben sa chi adotta metodologie di sviluppo agile, è impossibile prevedere ogni caratteristica a priori. Il problema in questo caso è ancora una volta legato alla mancanza di feedback da parte del cliente in tempi accettabili. Le richieste di modifica sono pervenute mesi dopo che la funzionalità era stata consegnata per verifica.
- Errore 6: non serve capire chi è il visitatore – Al cliente è stato suggerito, prima ancora di iniziare l’analisi del sito, di compiere alcuni fondamentali studi relativi agli utenti a cui il sito si rivolge, alle loro aspettativi e modalità di ricerca. Per motivi di budget, ma non solo, il cliente si è limitato a indicare alcuni siti concorrenti che presentano, rispetto alla versione attualmente online, alcuni spunti di miglioramento. Questa è una strategia che non paga, perché a sito terminato rimane il dubbio che non tutto sia stato realizzato come si sarebbe dovuto.
- Errore 7: il sito non fa quello che voglio – Il sito non deve fare quello che vuoi tu, ma quello che vuole il tuo utente (vedi punto precedente). Il nostro interlocutore, nel giustificare il nostro pessimo lavoro, parla di sito che non voleva, di sito che non corrisponde alle sue attese. Sbaglia due volte: perché ogni sua indicazione è stata presa in considerazione e perché cerca di mettersi nei panni di un visitatore che in realtà non conosce e si fa ingannare da dettagli e particolarità che sarà l’unico a notare.
Realizzare un progetto che soddisfi ambo le parti, soprattutto un progetto che richiede alcuni mesi di lavoro, è un’attività che il cliente e l’azienda di consulenza devono affrontare sapendo di mettere in campo tutto l’impegno necessario. Referenti non motivati, stime di costo in continua variabilità, scorciatoie di progettazione, tempi non rispettati sono gli elementi che piano piano, giorno dopo giorno, minano la riuscita di un progetto che è apparentemente solido. Esattamente quello che è successo in questo caso.
Questo post è oro.
Io non ho esperienza, perciò ti chiedo: quando si accetta un lavoro del genere, prima di iniziare come ci si accorda con il cliente? Anzi, come ci si dovrebbe accordare, e come invece si usa fare?
Per esempio: nel contratto includete una carta dei requisiti? E il preventivo non va dato solo dopo l’analisi del progetto?
@Laburno. In questo caso le cose sono state fatte a regola d’arte, nel senso che oltre al prototipo è stato realizzato un capitolato di progetto che riporta tutte le mappe del prototipo, commentate e motivate. Un documento di una quarantina di pagine. A questo è stata riferita l’offerta economica.
L’analisi è stata realizzata senza contributo del cliente e questo è certamente un problema perché, speso del tempo per farla, eravamo più vulnerabili in fase di trattativa.
Aziende serie accettano di investire per ottenere un’analisi indipendentemente dal proseguimento dei lavori, e in taluni casi (tra cui un progetto che sto seguendo proprio ora) accade proprio questo.
Un altro errore, come evidenziavo nell’intervento, è stato quello di proporre senza alcuna analisi un primo impegno economico che si è rivelato essere lontano anni luce dalla realtà.
Antonio, io mi sono dolorosamente fumato la societa’ che avevo messo in piedi per non aver imparato da questi errori e per aver perseverato a fornire ai clienti prodotti diversi da quanto il cliente aveva pensato (soprattutto in buonafede) di acquistare dopo gli incontri commerciali. E questo ha portato a progetti infiniti, a creare clienti autorizzati a chiedere assistenza eterna e condizioni economiche da svendita.
La fretta di chiudere una trattativa, l’insicurezza di chi dovrebbe coordinare la squadra, sviluppatori sotto-motivati, la qualita’ del servizio e soluzioni proposte che non sono all’altezza delle richieste.
Io leggo tutto questo dietro la tua analisi perche’ l’ho vissuto sulla mia pelle e penso di poterti confermare che o si impara oppure e’ meglio abbandonare da subito i grossi progetti web magari abbassando il tiro con clienti piu’ piccoli ma redditizi.
Ciao Antonio,
Ottima analisi. Avrei due considerazioni da aggiungere, che in questo contesto corrispondono inevitabilmente a due domande.
La prima, è che a mio avviso manca una conclusione. Cosa fare ora? Come procedere in questi casi? È chiaro che la situazione richiede un intervento, ma in che misura? Quanto inciderà sul tram e quanto sul cliente?
La seconda è il fattore tempo. Hai parlato di consegna a febbraio, ora è settembre. Possibile che non ci sia stato modo di identificare prima una così forte insoddisfazione, chiarendo con il cliente? In questo caso, potrebbe essere mancata qualche fase di controllo o confronto.
un post stupendo, chiarissimo e preciso in ogni dettaglio… ora però ti chiedo: non è che potresti scrivere una piccola guida di 2-3 post su come portare avanti agevolmente un progetto, dall’alto della tua esperienza di project manager, destinata soprattutto a chi, come me, sta per uscire dall’università, con un buon bagaglio di conoscenze teoriche sia di gestione che di sviluppo, ma che non ha fatto esperienza? grazie mille ciao :D
@simone
1) Dici bene, ho lasciato appositamente la porta aperta a questa domanda: cosa fare? Ecco cosa stiamo facendo.
Questo non solo ha permesso di evidenziare gli errori da ambo le parti, ma ha anche permesso di chiarire che espressioni come “mancanza di idee” e “mera esecuzione” erano ben lontane dalla realtà.
Il cliente in realtà si è “lamentato” di un’unica funzionalità la cui modifica è stata prontamente quantificata e sottoposta per approvazione.
I toni in questo momento sono decisamente più pacati e tranquilli, con il cliente intenzionato ad andare online quanto prima.
Va detto comunque che sia io, sia il team abbiamo sofferto di questa situazione, soprattutto perché abbiamo investito molta energia in un progetto in cui tuttora crediamo. In questo caso ho organizzato un incontro con tutti proprio per discutere degli errori commessi, il cui risultato è questo intervento. Già averne discusso i vari aspetti ha permesso da un lato di tranquillizzare tutti, dall’altro di fare buona esperienza per il futuro.
2) Il cliente in realtà non ha manifestato alcuna insoddisfazione fino a qualche giorno fa. I ritardi nella verifica delle diverse funzionalità sono stati giustificati dal cliente con il classico “proprio non ho tempo, a giugno non ci sono, ad agosto siamo pieni di lavoro”. Più volte abbiamo sottolineato al cliente la pericolisità di questa situazione, richiedendo incontri di approfondimento. Incontri pieni di buoni propositi, ma senza risultati apprezzabili. Oltre a questo, dal canto nostro, altri progetti in cantiere partiti nel frattempo hanno assorbito energie nell’attesa di una risposta dall’altra parte.
@flux – potrei scriverla, ma dubito che sarebbe utile. Questo lavoro è fatto di rapporti tra diverse figure, dettagli e sfumature che non è facile raccogliere in un intervento. Come vedi da quello che ho scritto io stesso ho commesso errori che si solito sono il primo a evidenziare. Come si arriva a questo? Per diversi motivi: perché non sappiamo con precisione chi sia il nostro interlocutore, perché nel frattempo sono in cantiere altri progetti, perché c’è sempre qualcosa di nuovo da considerare.
Mi associo agli elogi x l’ottimo articolo, in particolare x me i punti 1 e 7 sono da incorniciare
Domanda (da uno senza esperienza): nel contratto iniziale che generalmente si stipula, se il progetto va fuori tempo massimo non sono previste penali?
Mi associo ai complimenti che altri ti hanno fanno per l’ottimo intervento, è oro per uno che si accinge a fuggire dall’università :)
@davide – Solitamente non sono previste penali, anche se ho lavorato con contratti di questo tipo. Nel caso di penali sono definite le date di consegna delle diverse fasi del progetto ed è anche stabilito il tempo massimo in cui il cliente deve fornire riscontro, pena un corrispondente slittamento della consegna successiva.
Complimenti per il tuo articolo Antonio.
Rispetto alla tua analisi mi preoccupa molto l’errore 3: il cliente fantasma.
Secondo me l’attenzione del cliente è fondamentale per prendere consapevolezza dell’evoluzione del progetto.
Secondo te, nella situazioni che descrivi, come sarebbe stato possibile recuperare l’attenzione del cliente?
Ti ringrazio.
Saluti
@Cyanto – probabilmente parte tutto dalla fase commerciale: spingere un cliente all’accettazione di una proposta di cui non è convinto farà sì che il cliente sia poi irraggiungibile quando c’è bisogno del suo apporto.
Come prima cosa, quindi, va proposto al cliente quello di cui ha bisogno. Stabilite e quantificate le necessità non va poi nascosto al cliente che è necessaria la sua partecipazione attiva. E non averlo fatto notare è al principio dell’errore numero 3. Non dico di spaventarlo, ma va sottolineato che il successo del progetto dipende anche dalla sua partecipazione.
Inoltre, come dicevo nell’errore 4, alle prime avvisaglie che il referente in azienda non è all’altezza, bisogna farlo notare a chi di dovere. Non è facile, è forse antipatico ma – è il caso di dire – o lui o noi. A volte fare notare all’azienda che il suo referente non è indicato fa bene anche allo stesso referente. Mi è capitato una volta di partecipare a una riunione con l’amministratore delegato e il referente di un’azienda che voleva farci notare alcune mancanze. In pochi minuti, senza polemica, è stato facile dimostrare che le mancanze erano del referente, non nostre. A questo punto l’amministratore delegato se ne è uscito verso il referente con un “Si consideri esonerato da questo progetto: si alzi e se ne vada!” (frase sottolineata da un pungo sul tavolo). Avere fatto notare prima che non era la persona indicata avrebbe forse risparmiato al referente questa brutta figura.
Nel caso specifico si sarebbe dovuto, nel corso delle riunioni successive al lancio del progetto, sottolineare – magari con le parole giuste – che qualcosa non andava per il verso giusto con il referente. Ne saremmo usciti tutti più felici.
Per la mia esperienza, il lavoro inizia e finisce con la soddisfazione di ambo le parti quando il referente aziendale è una persona con competenze trasversali, legate in qualche modo al web ed al mktg/comunicazione.
Fino a quando l’interlocutore non ha alcun tipo di competenza sul media il rapporto rischia sempre di essere conflittuale, a causa della grande incomunicabilità tra le parti che lascia ampio spazio al misunderstanding.
Rileggendo con attenzione il post, mi ha colpito un elemento che in prima lettura avevo mal interpretato. Parli di un progetto di 350 ore/uomo (in prima lettura avevo inteso 350 giorni/uomo, ché questa è l’unità di misura che uso abitualmente). Ma 350 ore/uomo sono qualcosa più che 40 gg/uomo. Vuol dire che un progetto, di poco più di un mese di effort, che aveva data di consegna a febbraio, è andato oltre di quasi 6 mesi. Perchè non avete interpretato la cosa come segnale di allarme? Intendo, segnale da “alzare” verso il committente. Vuol dire che non stava “rispondendo” nel modo corretto al vostro lavoro.
Fra l’altro, in un caso del genere, mi sarei aspettato che il cliente alla fine lamentasse i tempi lunghi, non mancanza di “creatività”…
@Cristiano – Dopo i primi rilasci abbiamo capito che il cliente non rispondeva con celerità alle nostre richieste ed è stato più volte informato dei suoi ritardi. E’ chiaro che la cosa è stata presa come segnale di allarme, ma ha senso fermare un progetto per i ritardi del cliente?
Sarebbe ridicolo che il cliente avesse poi lamentato tempi lunghi, essendone la causa.