“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.

PMP vs. Agile

Anche di recente mi sono ritrovato coinvolto in una discussione in cui le metodologie Agile sono state definite come destrutturate e prive delle caratteristiche necessarie al raggiungimento di un obiettivo. Diciamo come una piuma la vento, che si fa trasportare in tutta leggerezza e svolazza senza meta. Dall’altro lato qualcuno ha descritto le dottrine PMI come qualcosa di farraginoso e talmente strutturato da fornire alibi a chiunque per il mancato raggiungimento degli obiettivi. Credo che per entrambe le posizioni la verità sta nel giusto equilibrio.

La gestione dei progetto con metodologie tradizionali si presta bene quando c’è una buona conoscenza del dominio applicativo oggetto del progetto. Se devo asfaltare una strada, con tutte le difficoltà che posso incontrare il perimetro è ben definito e la conoscenza è ben consolidata. Una delle prime lezioni del PMBOK, il libro che descrive i processi PMI, dice che è compito del PM con il team di progetto individuare quali di tutti i processi sono necessari per il progetto e con quale livello di implementarli. Ad esempio per un progetto privo di rischi (o pochi e noti) non predispongo un registro dei rischi. Per usare una metafora, la gestione progetti tradizionale è come una vacanza in macchina, pianifico le tappe, le soste, gli alberghi. Posso ri-pianificare se un posto non mi piace e voglio scappare, avrò da affrontare degli imprevisti, una gomma bucata, lo sciopero dei benzinai, ma in un modo o nell’altro riuscirò a visitare i posti che mi sono prefissato.

Agile si applica quando l’incertezza è tale da richiedere costanti variazioni a piani di progetto con eventuale rivisitazione del perimetro. Di fatto è come separare il progetto in tanti piccoli progetti di poche settimane (sprint) che consentono di verificare costantemente se si procede nella direzione giusta mantenendo sotto controllo i tempi. In ogni sprint ho tutte le fasi tipiche gestione progetti tradizionle, compresse nel tempo e quindi con formalismi più snelli. Mi azzardo a dire, irritando i puristi) che per alcuni versi “Agile” è più strutturato delle metodologie PM tradizionali, direi che si aggiunge alle metodologie tradizionali come un add-on. Anche usando metodologie Agile posso avere un piano dei rischi un registro degli stakeholder o qualsiasi altro strumento PM che ritengo utile. Sempre usando una metafora, “Agile” è come una vacanza in barca a vela, quando sono in navigazione devo fare il punto nave ogni due ore per correggere la rotta e se il vento e corrente non sono favorevoli rispetto a dove voglio arrivare, può essere che debba cambiare destinazione. Ma la cambusa devo averla pianificata bene secondo un approccio “tradizionale”.

Riassumo:

  • se ho un vincolo forte sul perimento di progetto ma posso variare i tempi e costi di progetto adotterò un approccio tradizionale.
  • se ho un vincolo forte sui tempi ma ho la possibilità di variare il perimetro e i costi adotterò un approccio agile. (Questo approccio è tipico delle newco e dei progetti innovativi perché essendo “nuovi” è molto improbabile riuscire a definire a priori il dettaglio delle caratteristiche)

L’ultima osservazione, nel mondo ideale esiste un progetto che rispetta tempi, costi, perimetro e qualità, nel mondo reale non ne ho mai visti. Ma ho visto molti progetti di successo, sono quelli che soddisfano le aspettative del cliente.

Essere Agile con Agile

Spesso si parla di “Agile”, metodologie, approcci, strumenti, che dir si voglia. I maggiori estimatori ritengono che l'”Agile” deve essere adottato in tutti i sui aspetti per essere efficace, diversamente non si ottengono i risultati attesi.

Credo che occorre essere “Agile” anche nel “Agile”, ho letto quest’articolo che condivido appieno Being Agile with Agile.