Rispondere alle RFI

Arriva in azienda un richiesta di informazioni da parte di un cliente, la classica RFI. La macchina commerciale si mette in motto, account, commerciali, sales, presale, team tecnici si mettono al lavoro per rispondere al cliente e superare il primo scoglio: la qualificazione per arrivare alla gara, la famigerata RFP. Come rispondere? Che taglio dare? Mostrarsi capaci, validi e poco costosi è un must, ma proporre la luna per 4 noccioline ha senso? E’ efficace?

Come funzionano le RFI viste dal cliente? Che obiettivi ha il cliente? In genere una RFI serve al cliente per avere un’idea di massima della fattibilità tecnica, sostenibilità economica di un progetto oltre all’individuazione dei fornitori che parteciperanno a una gara. Se il cliente ha già le idee chiare procede con una gara senza perdere tempo con una RFI. Quindi in genere, sottolineo in genere, l’RFI contiene alcune idee e spunti che il cliente vuole portare avanti e chiede ai fornitori aiuto per dare concrettezza alle idee. Per il cliente un’RFI è un modo veloce per scremare i fornitori e individuare quelli che meglio capiscono le esigenze e che propongono soluzioni fuori dagli schemi. Quest’ultimo punto è secondo fondamentale. Nel ruolo “da cliente” non ho mai proposto RFI su temi già noti. Non ha senso ad esempio inviare ai fornitori un’RFI per un CMS, a meno che il CMS in questone debba avere caratteristiche innovative.

Per il fornitore l’ansia da prestazione può essere forte, soprattutto su clienti nuovi. La tentazione di rispondere in modo affermativo ed esagento a qualsiasi domanda è forte. Partendo dal presupposto che nella tecnologia e in particolare informatica si può fare qualsiasi cosa, la risposta che non sarebbe neanche tanto scorretta. Confezionando le frasi nel modo corretto con ‘si può fare’, ‘la piattaforma è predisposta’, ‘abbiamo esperienza’ si riesce a proporre qualsiasi cosa, anche la luna. Avere una quotazione di massima sensata durante un RFI è quasi impossibile. In genere le informazioni richieste dal cliente sono molto generiche e offrono spazio per diverse proposte di soluzioni. La risposta corretta dovrebbe essere da tanto a poco, con una forbice enorme legata all’assenza di requisiti di dettaglio. stesso per una eventuale pianificazione delle attività.

Ovviamente ognuno risponde a un RFI come meglio ritiene opportuno e ho visto RFI (ma anche RFP) in cui la luna veniva proposta per 4 noccioline e i costi di progetto che lievitano in modo esponenziale. La risposta a un RFI deve contenere gli spunti di innovazione che il fornitore può al cliente, evidenziare in modo chiaro gli asset presenti e idee che devono essere sviluppate insieme (a 4 mani con il cliente), un indicazione di quando può durare e ha senso che costi e duri un’iniziativa progettuale basandosi su esperienze analoghe e senza calare questa valutazione sul contesto specifico perché ovviamente non ha senso per assenza di un requisito chiaro.

Per me l’obiettivo della risposta è fornire elementi al cliente per capire se c’è un match tra le sue idee e l’impostazione del fornitore. Arrivare a partecipare alla gara deve essere la conseguenza del ‘match’ cliente/fornitore, non l’obiettivo della risposta al RFI. E’ una sottile differenza ma molto importante. Rispondere al RFI con l’obiettivo di arrivare alla gara porta il fornitore a proporre la luna per 4 noccioline. La risposta dovrebbe essere chiara e trasparente e basata su ciò che il fornitore è in grado fare e non esclusivamente sulle aspettative del cliente. Aggiungerei anche breve, la risposta deve essere breve. Va sempre ipotizzato che il cliente ha inviato all’RFI a diversi fornitori, più di quelli che partecipano a una gara, a volte anche più di 10. L’obiettivo del cliente è chiarirsi le idee velocemente per definire il contenuto di una gara. Se le risposte sono lunghe e confuse vengono archiviate velocemente.

Aspettative e requisiti

A volte con disappunto il cliente comunica che il risultato non soddisfa le aspettative, eppure tutti i requisiti tracciati nelle fasi preliminari sono stati correttamene implementati e accettati dal cliente.

Quello descritto è un rischio molto concreto dell’approccio tradizionale waterfall su progetti di carattere innovativo. Le macro fasi tipiche waterfall prevedono: analisi, disegno, implementazione e test (più altre non rilavanti per l’argomento). Nella fase di analisi dei requisiti l’interazione cliente/fornitore è molto intensa ed è il momento in cui il cliente trasmette al fornitore le proprie necessità e aspettative. Questa fase inizia con un processo più o meno formale in cui il cliente comunica “cosa” si aspetta che il sistema faccia e termina con un processo formale in cui il fornitori descrive “come” intende implementare le richieste cliente. Il documento che descrive “cosa” si aspetta il cliente, ossia le aspettative del cliente, è il documento dei requisiti. Il documento che descrive “come” viene implementato il requisito è il documento di analisi tecnico-funzionale.

Si arriva alla fine dello sviluppo e l’amara sorpresa per cliente e fornitore è che il sistema sviluppato non soddisfa le aspettative. I costi per risolvere una situazione come questa sono molto alti, occorre mettere in campo numerosi giorni uomo per smontare quanto implementato e implementare in modo diverso. La ricerca delle “responsabilità” diventa quindi una missione per cliente e fornitore.

L’origine di questa situazione è legata a queste due situazioni:

  1. Il cliente non ha espresso i requisiti con sufficiente dettaglio. Il livello di dettaglio dei requisiti è fondamentale e anche nella vita quotidiana e un approccio superficiale può mettere in difficoltà. Immaginate di voler comprare una macchina, descrivete ogni singolo dettaglio vi viene in mente, colore, optional, motorizzazione… ma non esprimete nulla sulla ruota di scorta. Date per scontato che arrivi il kit riparazione e invece arriva il ruotino.
  2. L’analisi non è sufficientemente dettagliata per consentire al cliente di capire gli impatti e le implicazione di quello che verrà implementato. Nel esempio di prima supponiamo che il cliente specifica anche che desidera il kit di riparazione, perché sa che è più pratico. Quando riceve il veicolo scopre che i tagli non possono essere riparati con il kit riparazione, si aspettava di poter risolvere qualsiasi foratura.

Al di là della responsabilità formale, ciò che vorremo è evitare che si presenti una situazione di macato soddisfacimento delle aspettative. Il problema si presenta soprattutto nei progetti waterfall e si accentua se il progetto ha carattere di innovazione per il cliente. L’innovazione infatti non consente al cliente di mettere a fuoco tutti gli aspetti del nuovo sistema, soprattutto gli impatti sui processi interni, ruoli e attività. Il requisito diventa spesso vago e molto generico con repentini cambi di idea e prospettiva. E’ qui che il fornitore dovrebbe intervenire con un approccio Agile, scomponendo il progetto in Sprint, con time frame limitati aiuta focalizzare su singole tematiche più gestibili. Inoltre al termine dello Sprint abbiamo un risultato tangibile da condividere con il cliente.

La principale critica a quest’approccio è la poca visibilità di insieme e il fatto che potrebbero essere necessari numerosi re-work con conseguente aumento dei costi. La seconda critica mossa è la difficoltà se non impossibilità ad avere una stima dei costi complessivi e del tempi necessario. In effetti entrambe le critiche sono corrette in un progetto Waterfall guida lo scope/perimetro, il tempo e i costi ne sono una conseguenza del perimetro. E’ bene ricordare sempre che un approccio Waterfall si applica bene (leggesi: rispetto tempi, costi) solo se il perimetro di progetto è ben definito, dettagliato e con poche variazioni nel tempo.

In un progetto Agile i dati certi sono la durata di uno Sprint e la composizione del team, tutto il resto è flessibile e viene determinato al proseguire delle attività. Questa flessibilità ha il vantaggio di ridurre il rischio di arrivare a fine lavoro e scoprire che la soluzione non soddisfa le aspettative, consente di effettuare cambi di direzione in corsa e rende quasi impossibile una stima del impegno complessivo a inizio lavori.

“Time & material” vs. “A servizio”

Di recente ho assistito come spettatore a una trattativa commerciale a seguito di una gara, per la scelta di un servizio di assistenza. Il cliente mostrava interesse per l’erogazione del servizio in modalità “T&M” per mantenere il controllo in un momento di riorganizzazione, mentre il fornitore insisteva per un contratto di erogazione “A servizio” attraverso un compoetence center. Su questa differenza di impostazione l’accordo si è arenato e, come accade spesso il terzo incomodo ne ha tratto beneficio contrattualizzando un accordo T&M con il cliente.

Vediamo innanzitutto in cosa si differenziano le due tipologie di accordi per l’erogazione di un servizio. Un contratto “T&M” è molto semplice da gestire, si concorda una tariffa giornaliera o a oraria differenziata per figura professionale , un luogo di lavoro se necessario, un rimborso delle spese vive ad esempio se sono previste trasferte o l’acquisto di materiale particolare. Nei contratti “T&M” la responsabilità sul risultato è interamente sul cliente che coordina l’attività delle risorse messe a disposizione dal fornitore. La responsabilità del fornitore si limita alla selezione delle risorse professionali con le competenze necessarie a svolgere il compito. Anche la scelta delle risorse è nelle responsabilità del cliente, che spesso si riserva di valutare con un periodo di prova le risorse proposte dal fornitore.

Un contratto “A servizio” prevede un costo per il servizio erogato e dei livelli di servizio che devono essere mantenuti. Sotto tali livelli si possono applicare delle penali. La natura del contratto è molto più complessa e prevede la necessità di misurare sia la quantità di servizio erogato sia il livello qualitativo del servizio. La misurazione quantitativa è spesso semplice perché si limita ad una quantità, come ad esempio il numero di click su un banner, il numero di pagine o battute scritte, il numero di ticket evasi… Definire i criteri di monitoraggio di livelli di servizio (SLA) è già più complesso. Un primo criterio è spesso legato al orizzonte temporale, che determina la velocità di esecuzione, un secondo criterio altrettanto importante è legato alla qualità, ossia alla quantità di lavoro eseguita senza difetti. Perché va sempre ricordato che velocità e qualità sono nemici giurati, più si va veloci e più la qualità ne risente. In un contratto “A servizio” la responsabilità è tutta in capo al fornitore. Il cliente si limita a godere del servizio, monitorare i KPI che gli consentono di verificare il rispetto del livello di servizio (SLA).

Date queste premesse sembra scontato che il cliente cerchi di spingere verso un contratto “A servizio” mentre il fornitore verso un contratto “T&M”, infatti nel caso “A servizio” la responsabilità e quindi eventuali costi aggiuntivi, è del fornitore mentre nel “T&M” la responabilità è tutta sul cliente. C’è quindi da chiedersi perché i due attori nella trattativa si sono arroccati su posizioni opposte a quello che vorrebbe la logica.

Analiziamo prima la posizione del cliente. Affinché un contratto “A servizio” sia applicabile con soddisfazione occorrono due presupposti, il primo è che i processi e le resposabilità siano ben definte, il secondo presupposto è che il servizio sia misurabile in modo oggettivo. Se viene a mancare uno di questi due requisiti il rischio (che in pratica si verifca sempre) è che il fornitore avanzi richieste di integrazione economica per far fronte alle situazioni imprevviste o alla soggettiva misurazione del servizio. Nella trattativa a cui ho assistito in efetti i processi erano in fase di revisione con coseguente rischio di variazioni volumi e spostamenti di responsabilità.

Il fornitore dal canto suo poteva seguire il cliente e proporre un “T&M”, praticamente privo di rischi e a margine certo. La scelta di proporre un contratto “A servizio” si motiva dalla possibilità di marginare facendo effetto “scala” su un competence center già avviato. Di fatto la proposta competitiva nasceva dal efficenza creata dal centro di competenza. Una proposta “T&M” avrebbe probabilemente comportato un distacco di risorse dal centro di competenza con perdita di competenze ed efficienza del centro stesso.

Burocrazia? No, grazie! Documentazione? Si!

Il confine è spesso labile. Quando si parla di documentazione con chi ha sempre lavorato per tradizione orale si passa per “burocrati”. E quando non si documenta in un azienda che formalizza molto si passa per destrutturati. Ma come stanno le cose?

L’assenza di documentazione ha sicuramente alcuni vantaggi percepiti, una distorsione della realtà. Un po’ come la temperatura percepita nelle previsioni meteorologiche: temperatura 18° gradi, percepita 25°. Sempre 18° gradi sono.  I vantaggi percepiti  sono di una maggior agilità nel raccogliere i requisti e tradurli in codice, salvo poi rendersi conto in fase di manutenzione, magari a distanza di tempo, di non aver la minima idea di cosa succede nel applicativo.

D’altro canto documentare tutto, ma proprio tutto, genera entropia. In una situazione estrema potrei dovermi trovare a dover documentare di aver prodotto la documentazione in una sorta di circolo vizioso autoreferenziale. Sembra una situazione assurda ma è quello che succede tutte le volte che gli scambi di email vengono fatti “per lasciare traccia” di un problema. L’obiettivo diventa formalizzare il problema invece di risolverlo.

Vediamo vantaggi e svantaggi dei vari approcci.

Assenza di documentazione

Ossia situazione di azienda che tende a non raccogliere in modo organizzato e strutturato la documentazione.

  • Vantaggi: sensazione di procedere molto spediti e percezione di “stare sul pezzo” di “prendere il toro per le corna” e di “non perdersi in … (fronzoli)”
  • Svantaggi: difficoltà di manutenzione del software, know-how individuale e non aziendale, aumento dei tempi complessi di implementazione, impossibilità di eseguire dei test, assenza di scalabilità (chi raccogli i requisiti deve scrivere il codice e testare
  • Sintomi: refrattarietà alla documentazione “tanto non serve”.

Burocratizzazione

Situazione di eccesso di documentazione, anche per spostare una sedia l’azienda richiedere di documentare lo spostamento (, metti che chi arriva dopo non trova più la sedia…).

  • Vantaggi: percezione di lavorare secondo le moderne best-practice e metodologie, consapevolezza che se qualcosa va storto non poteva essere evitato perché “abbiamo documentato tutto” (ovviamente mettendo i problemi in secondo piano)
  • Svantaggi: la documentazione è talmente tanta da diventare inutile perché il documento che serve è nascosto tra mille, ansia da “devo documentare” ancora prima che trovare una soluzione o condividere con i colleghi, i documenti prodotti sono spesso obsoleti già appena prodotti perché superati, dispersione di tempo ed energia a scrivere documenti che nessuno legerà mai.
  • Sintomi: E’ inutile cercare nei documenti, tanto non trovi mai quello che serve.alcuni documenti vengono letti solo da chi li ha scritti.

Corretta documentazione

La documentazione viene raccolta costantemente e inserita negli archivi in modo ordinato, l’azienda non sollecita documentazione che viene prodotta spontaneamente in funzione delle necessità.

  • Vantaggi: si trovano facilmente i documenti che servono, il know-how è aziendale (non individuale)  ossia a disposizione di tutta l’azienda. Facilità nei turn-over interni, manutenzione agevolata, consapevolezza della complessità e di quanto c’è in casa.
  • Svantaggi: situazione di equilibrio instabile basta poco per cadere in una delle prime due situazione. Per non cadere nelle situazioni di cui sopra occorre monitorare costantemente i sintomi e contrastarli in modo fermo. Senza però esagerare per non cadere nella situazione opposta. Scoraggiare quindi posizioni tipo: “avito di  scrivere l’analisi così faccio prima” ma non insistere con richieste di formalizzare cose banali e che non arricchiscono l’azienda.

 

 

RACI: Accountable vs. Responsible

Un limite tutto italiano

Una delle digressioni più comuni sulle matrici RACI riguarda la distinzione tra Accountable e Responsible, entrambi termini vengono tradotti in italiano come “responsabile”. Questo spesso genera confusione anche perché non sempre viene fatta chiarezza e nelle discussioni ci si dimentica di usare i termini inglesi durante. L’equivoco è dietro l’angolo e rischia di infiammare gli animi. Basta la domanda o l’affermazione interpretabile: “Sei tu il responsabile dell’attività XYZ?” e la miccia difficile da spegnere è innescata.

Chi ha un minimo di basi sa che una matrice RACI ammette un solo “Accountable”,  la persona con il compito di decidere e approvare il lavoro, e molti “Responsible”, le persone che materialmente eseguono il lavoro. Nel caso di un cantiere edile il capo cantiere è la persona “Accountable”, mentre i muratori sono “Responsible”. Il primo è responsabile per l’esito del lavoro, i secondi sono responsabili nel eseguirlo. Se l’attività non è eseguita correttamente il primo ad accorgersene deve essere l’ “Accountable” ed è la persona che interviene se i “Responsible”, ovvero chi esegue il lavoro non lo fa correttamente.

Ecco, tutto questo in italiano è molto più complesso da esprimere perché mancano i termini adeguati. Il capo cantiere è responsabile, ma lo sono anche i muratori. La sottile differenza tra decisore ed esecutore viene a mancare quando si parla di responsabilità.

Può sembrare una banalità ma questo ha diverse ripercussioni pratiche. L’assenza nel linguaggi di questa distinzione porta i responsabili “Accountable” e i responsabili “Responsible” a sentirsi meno responsabili gli uni per le decisioni da prendere, gli altri nell’esecuzione dell’attività. Di fatto si creano degli alibi. Parlando con chi è accountable ricevo spesso delle risposte “ma sono loro responsabili per l’attività, perché chiedi a me” e dall’altro lato parlando con chi è “Responsible” ricevo come risposta il rovescio della medaglia “perché chiedi a noi è il responsabile dell’attività, noi siamo esecutori facciamo quello che ci viene detto di fare”.

In realtà a ben vedere il limite non è solo linguistico, è un limite mentale, per gli italiani in una RACI il“Responsible” e“Accountable” sono la medesima cosa. Noi italiani prediligiamo il “one man show”, la piccola imprenditoria in italia dilaga anche per questo.

WP to LinkedIn Auto Publish Powered By : XYZScripts.com