Project Management e tecniche di relazione con il cliente

di Ferdinando Cermelli

14 Maggio 2008 09:30

Per guadagnarsi piena fiducia da parte del cliente, ecco la guida base per i project manager che si apprestano a svolgere un progetto IT: come raggiungere gli obiettivi e rendere efficaci i rapporti con il committente

Quando si instaura una relazione con un nuovo committente, è necessario affrontare alcuni aspetti chiave del nuovo rapporto, finalizzati al superamento della diffidenza iniziale e miranti al raggiungimento degli obiettivi esplicitati come richieste dall’interlocutore, formalizzati nel contratto d’ordine ed organizzati durante la pianificazione.
Questo vale in ogni momento del rapporto, fin dalla fase che precede la contrattazione, ossia quella della reciproca conoscenza, in cui “ci si prende le misure”.

In questa fase, infatti, è necessario porre molta attenzione alla tipologia di cliente con cui ci si relaziona. Esistono persone che dispongono di una cultura coerente con l’ambito tecnologico a cui riferisce i contesto tecnologico del prodotto richiesto e che ci si propone di realizzare ma, più frequentemente, si incontrano utenti la cui competenza è circoscritta all’ambito dell’attività aziendale e, conseguentemente, lontano da competenze tecnologiche.

Questo comporta la necessità di utilizzare meccanismi di comunicazione molto attenti e mirati in modo da risultare comprensibili indipendentemente dal livello culturale del committente ovvero dal grado di comprensione tecnico o tecnologico che il progetto necessita e che caratterizza le modalità di soddisfacimento delle delle esigenze espresse dal committente. È necessario quindi, porre molta attenzione ad alcuni aspetti che definiremo di interrelazione e in particolare a due di questi: il linguaggio scelto per presentarsi e per illustrare il progetto, la descrizione dei contenuti tecnologici che caratterizzano il prodotto risultante.

Non è infrequente assistere a dialoghi in cui il professionista di turno ritiene di dimostrare la propria competenza utilizzando un gergo molto stringente e specifico o sbandierando strumenti (ignoti a chi non opera nel settore) che vengono presentati come “innovativi”, “all’avanguardia o di “ultima frontiera” tecnologica.
Vero o falso che sia, ritengo sia di gran lunga preferibile l’utilizzo di terminologia semplice ma comprensibile ad una esasperazione del logos tecnologico. Allo stesso modo risulta spesso controproducente scendere in dettagli tecnici che, se pure hanno una valenza con un interlocutore competente, molto spesso offrono il fianco ad una interpretazione negativa del tipo “questa persona mi vende del fumo”, oltre a causare confusione e provocare dubbi.

Nell’ambito dello sviluppo di applicazioni software, ad esempio, se viene richiesto lo sviluppo di un prodotto che consente di gestire i rapporti con i clienti si sentono utilizzare termini quali “Internet application” e “customer relationship management” rischiando di millantare competenza e professionalità costruendo invece un muro di incomprensione, che potrebbe invalidare qualsiasi possibilità di comunicazione e rendere fallimentare la proposta, indipendentemente dalla bontà intrinseca del prodotto in promozione.
Molto meglio descrivere funzioni e servizi in termini comprensibili e lasciare la terminologia di settore alla documentazione contrattuale che, giocoforza, deve essere formale.

Superato questo scoglio, non si è affatto giunti alla fine dei problemi in quanto diventa necessario strutturare un’offerta altrettanto comprensibile. Ma nemmeno questa è la fine delle travagliato iter. I maggiori problemi di relazione tendono a presentarsi durante la realizzazione del progetto e in particolare nel momento in cui il committente inizia ad avere visibilità del prodotto o di parte di esso.

Esistono due correnti di pensiero: una prima che consiglia di estromettere il cliente durante tutta la fase di realizzazione del progetto, mentre un secondo approccio suggerisce un totale coinvolgimento. Entrambe le scelte non sono scevre da aspetti positivi e negativi.

Nel primo caso il rischio maggiore è quello di ritrovarsi con un committente che non valida il prodotto realizzato in quanto lontano dalle sue aspettative e questo con tutte le conseguenze sul piano professionale e contabile che si possono facilmente immaginare e questo in cambio di una fase realizzativa affrancata da interruzioni, variazioni e rifacimenti. D’altro canto è ovvio che il continuo coinvolgimento comporta l’insorgere di nuove idee, di diverse soluzioni, di scelte alternative a quanto contrattualizzato in prima istanza. Questo secondo approccio è a mio avviso da preferirsi, anche se è obbligatoriamente necessario mettere dei paletti all’invadenza, per certi versi scontata, del committente.

Attraverso la metodologia di project management nota con l’acronimo di Prince2 (PRojects IN Controlled Environments) è possibile individuare una soluzione all’increscioso problema. Va detto innanzitutto che tale metodologia presuppone il continuo coinvolgimento dell’interlocutore commerciale e che quindi affronta direttamente tale aspetto.

Non disponendo di metodologie spesso ci si ritrova a dibattersi tra due scelte, come efficacemente indicato nell’articolo “La gestione delle change request” di Alessia Valentini: rispondere sì ad ogni richiesta, oppure rispondere no ad ogni richiesta.
Nel primo caso si rischia di compromettere tanta fatica andando a inficiare i rapporti con il proprio team che vede continuamente modificati i requisiti per i quali già si è lavorato, vanificando i risultati conseguiti; peggio: nel momento in cui ci si trova a dover rifiutare una richiesta l’interlocutore ne riceve una pessima impressione.

Soffermiamoci un momento con una digressione sul ruolo del Project Manager.
Tra le funzioni proprie del capo progetto vi è quella di gestire i conflitti interni al gruppo, e il rifacimento di attività già concluse è sicuramente uno degli aspetti maggiormente frustranti e primaria causa di stress nei rapporti interpersonali.

L’essere in grado di gestire correttamente il rapporto con il committente si riflette pertanto direttamente sul clima che si vive all’interno del team di sviluppo.
Quando poi le richieste del committente non riguardano esclusivamente modifiche ma nuovi servizi, nuove implementazioni che però il cliente richiede esplicitamente non causino variazioni sui prezzi concordati si rischia di apparire decisamente poco professionali in quanto si ammette implicitamente di aver sovrastimato il progetto iniziale oltre ad intaccare pericolosamente l’aspetto finanziario in termini di accrescimento dei costi di progetto.

È altresì evidente che fornire continue risposte negative a qualsiasi richiesta spiana la strada ad una triste fine dei rapporti in essere, poiché il committente di fronte a tanta costante indisponibilità finirà per sentirsi non capito nelle sue esigenze imprenditoriali; analogamente negativo è il rimarcare la necessità di un adeguamento dei prezzi convenuti a fronte delle variazioni richieste: è solo un modo differente di dire “NO”.

Una possibile soluzione la si può trovare nella prima fase di pianificazione, ovvero nella definizione corretta delle WBS (Work Breakdown Structure) ciascuna delle quali ha i requisiti per divenire un momento che deve essere validato dal cliente e che rappresenta quindi un adeguato momento di coinvolgimento orientato ad ottenere il via libera in termini di servizio erogato nella specifica funzionalità.
Il coinvolgimento del cliente diviene cadenzato e associato alla disponibilità di funzionalità portate a compimento.
In questo modo si ottiene da un lato l’accettazione progressiva del prodotto da parte del cliente finale mentre nel contempo si inserisce una fase di test effettuata già in campo mentre la realizzazione è ancora in corso d’opera.

Oltre a ciò si offre al cliente un esplicita presa visione costante dello stato di avanzamento dei lavori.
Sicuramente questo approccio non azzera le richieste di variazione al capitolato del progetto così com’è stato definito all’atto della contrattualizzazione, tuttavia ne riduce fortemente il perimetro di azione, consentendo di giungere alla consegna del prodotto finale con un cliente soddisfatto del prodotto, in grado di utilizzarlo da subito e senza un particolare sforzo da parte nostra in fase di realizzazione dei test.

Alla fine entrambi gli aspetti trattati investono un aspetto che è fulcro del rapporto con il committente, in potenza o in atto che sia, ovvero la comunicazione.