Categoria: Project Management

Leggendo il PMBOK e sudiando da Project Manager i processi sembrano naturali  e semplici da affrontare. Si tratta in effetti in molti casi di applicare il buon senso.Se ciascuno facesse esattamente quello che è previsto venga fatto nel interesse del progetto non ci sarebbe bisogno di un project manager.

Il mondo reale è diverso. Nella realtà gli interessi individuali non sempre coincidono con gli interessi di progetto e non sempre le persone coinvolte hanno l’esperienza o le competenze per affrontare le situazioni che si presentano.

Nel mio lavoro di Project Manager e Program Manager mi trovo ad affrontare situazioni reali. Le mie esperienze di project manager, il divario tra teoria e pratica e alcuni suggerimenti per non commettere errori perché ogni progetto fa storia a se, ogni team fa storia a se.

Pubblicato il

Make vs Buy decisione finale

Meglio ‘make’? Maglio ‘Buy’? ho sentito tantissime opinioni a riguardo, ogni approccio ha i pro e i contro. C’è uno e un solo elemento fondamentale per dirimere la scelta. Prima di entrare sul ring è opportuno presentare i due contendenti, prima un excursus sui pro del ‘make’, poi un excursus sui pro del ‘buy’ e infine il match, quando vince uno, quando vince l’altro.

Il Make

I vantaggi dell’approccio ‘make’

  1. Controllo Totale sulla Qualità: Uno dei principali benefici di produrre internamente è il controllo totale sulla qualità. L’azienda ha il potere di definire gli standard di qualità desiderati e di garantire che vengano rispettati in ogni fase del processo di produzione. Questo controllo permette di evitare sorprese legate a prodotti o servizi di bassa qualità che potrebbero derivare da fornitori esterni.
  2. Protezione della Proprietà Intellettuale: La produzione interna consente di proteggere meglio la proprietà intellettuale dell’azienda. I segreti commerciali e le innovazioni possono essere tenuti al sicuro, riducendo il rischio di divulgazione non autorizzata che potrebbe verificarsi quando si condivide la produzione con fornitori esterni.
  3. Maggiore Personalizzazione: La produzione interna consente all’azienda di personalizzare i prodotti o i servizi in base alle esigenze specifiche dei clienti. Questa capacità di adattamento può portare a relazioni più solide con i clienti e a una maggiore fedeltà verso il marchio.
  4. Creazione di Competenze Interne: Il processo di produzione interna implica lo sviluppo di competenze e know-how all’interno dell’organizzazione. Queste competenze diventano un vantaggio competitivo, consentendo all’azienda di essere più autonoma e meno dipendente da fornitori esterni.
  5. Flessibilità di progettazione: Variazioni in corso d’opera di specifiche tecniche possono avvinare con una maggior flessibilità perché viene bypassata la fase di trattativa con il fornitore esterno per le variazioni di specifiche.

Tutto ciò che non è un vantag

In sintesi, l’approccio “make” offre una serie di vantaggi che possono migliorare la competitività e la resilienza di un’azienda. Tuttavia, è importante sottolineare che la decisione di produrre internamente non è sempre la scelta migliore in ogni situazione. È necessario valutare attentamente i costi, i benefici e i rischi associati a questa strategia alla luce delle circostanze specifiche dell’azienda e del mercato in cui opera. La scelta tra “make” e “buy” dovrebbe essere basata su un’analisi completa e mirata.

I falsi miti del ‘make’

  1. Flessibilità Operativa: Spesso sento dire che la produzione interna offre maggiore flessibilità operativa. Un’azienda può adattarsi rapidamente alle mutevoli esigenze del mercato, apportando modifiche ai prodotti o ai processi in tempi brevi. Nella realtà non è così, o è alido solo in alcuni contesti mirati. Se ho una determinata modalità operativa e con l’uso di alcuni strumenti, per cambiare modalità operativa dovrò sostituire gli strumenti (a volte non sempre). La flessibilità potrebbe quindi non essere sempre vera, ve distinta dalla flessibilità di progettazione.
  2. Risparmio a Lungo Termine: Sebbene l’investimento in infrastrutture e risorse per la produzione interna possa sembrare inizialmente costoso, nel lungo termine può portare a notevoli risparmi. Un’azienda può ammortizzare gradualmente questi costi e ridurre le spese associate all’acquisto esterno. Inoltre, evita costi nascosti legati alla gestione dei fornitori, come le negoziazioni contrattuali e le dispute sulla qualità. Questa è la tesi, ma come per la modalità operativa potrei trovare un fornitore maggiormente verticalizzato su prodotto e quindi con consti di produzione molto più bassi di quelli interni.
  3. Miglior Gestione del Rischio: La produzione interna può ridurre il rischio associato a interruzioni nella catena di approvvigionamento. Le situazioni di crisi, come interruzioni delle forniture o cambiamenti nei mercati globali, possono avere un impatto minore quando l’azienda è in grado di controllare direttamente il processo produttivo. Questo è un’altro falso mito, spesso la riduzione del rischio comporta una rosa più ampia di fornitori che sopperiscano ad eventuali carenze ed evitino il vendor lockin.
  4. Efficienza Logistica: Riducendo la dipendenza da fornitori esterni, un’azienda può semplificare la gestione della logistica e delle spedizioni. Questo può portare a una catena di approvvigionamento più efficiente, riducendo tempi di consegna e costi di trasporto. Questa l’ho sentita e dimenticata per poi ricordarmene mentre scrivevo. Questa posizione è valida alcune volte, errata il più delle volte. In genere per produrre un bene occorrono diversi fornitori, acquistare il bene richiede un unico fornitore.

Il Buy

I vantaggi dell’approccio ‘buy’

  1. Riduzione dei Costi Iniziali: Un vantaggio chiave dell’approccio “buy” è la possibilità di evitare costi di investimento iniziali elevati. Le aziende possono risparmiare notevoli somme di denaro non dovendo acquistare o costruire infrastrutture, attrezzature e competenze interne per produrre internamente. Questo può liberare risorse finanziarie per altri scopi, come l’espansione, la ricerca e lo sviluppo o la diversificazione.
  2. Flessibilità nell’Adattarsi alle Fluttuazioni della Domanda: Acquistando da fornitori esterni, le aziende possono adattarsi più facilmente alle variazioni nella domanda. Possono aumentare o ridurre gli ordini in base alle esigenze del momento senza dover gestire il carico di lavoro interno. Questa flessibilità è particolarmente importante in settori con domande stagionali o variabili.
  3. Accesso a Competenze Specializzate: L’acquisto esterno consente alle aziende di accedere a competenze specializzate presenti nei fornitori. Questi ultimi spesso vantano una vasta esperienza e know-how nel loro settore, consentendo all’azienda di beneficiare di migliori pratiche, innovazioni e qualità superiori senza dover sviluppare tali competenze internamente.
  4. Concentrazione sul Core Business: Acquistando beni e servizi da fornitori esterni, le aziende possono concentrarsi maggiormente sul loro core business. Questo significa che possono allocare più tempo ed energia per sviluppare prodotti, servizi e strategie di mercato che generano un vantaggio competitivo reale.
  5. Riduzione del Rischio Operativo: La produzione interna può comportare rischi operativi significativi, come problemi di capacità, costi imprevisti e obsolescenza tecnologica. L’approccio “buy” può ridurre questi rischi, in quanto l’azienda non è direttamente responsabile di tali aspetti e può spesso ottenere contratti con garanzie di servizio.
  6. Velocità di Entrata sul Mercato: L’acquisto esterno può accelerare l’ingresso sul mercato o l’aggiunta di nuovi prodotti o servizi all’offerta dell’azienda. Questa velocità può essere cruciale per sfruttare le opportunità di mercato o per rispondere rapidamente alle richieste dei clienti.
  7. Minore Gestione Operativa: L’acquisto esterno spesso comporta una minore complessità nella gestione delle operazioni quotidiane. L’azienda può concentrarsi sulla supervisione dei fornitori, piuttosto che sulle operazioni dettagliate, riducendo la necessità di gestire una vasta forza lavoro interna.

Gli svantaggi dell’approccio ‘buy’

  1. Dipendenza da Fornitori Esterni: L’acquisto da fornitori esterni può creare una dipendenza da terze parti per il rifornimento di beni o servizi critici. Se il fornitore principale riscontra problemi o non riesce a soddisfare le esigenze dell’azienda, ciò può avere un impatto significativo sulle operazioni. L’approccio ‘buy’ è ad alto rischio di vendor lockin e la gestione dei contratti con i fornitori può richiedere tempo ed energie significative. Errori nella negoziazione o nell’esecuzione dei contratti possono portare a dispute legali o a costi aggiuntivi.
  2. Perdita di Controllo: L’azienda può perdere una certa quantità di controllo sui processi operativi e sulla qualità quando si affida a fornitori esterni.Gli effetti sono :
    • Rischio di Qualità e Affidabilità del Fornitore: L’azienda non ha un controllo diretto sulla qualità e sull’affidabilità dei fornitori. Se un fornitore esterno non rispetta gli standard di qualità o non soddisfa gli accordi contrattuali, possono sorgere problemi di qualità dei prodotti o dei servizi.
    • Perdita di Know-How Interno: L’outsourcing di servizi o produzione può comportare la perdita di competenze e conoscenze interne, rendendo l’azienda più dipendente dai fornitori esterni
    • Perdita del vantaggio competitivo: Se il vantaggio competiti6ov è legato ai prodotti acquistati in ‘buy’ c’è il rischio di perdita di vantaggio competitivo e di divulgazione di informazioni riservate.

I falsi miti del ‘buy’

Riduzione dell’Impatto Ambientale: In tempi recenti, in cui l’impatto ambientale e le tematiche ESG sono rilevanti, ho sentito dire che il buy riduce l’impatto ambientale. In alcuni casi, l’acquisto da fornitori esterni può contribuire a ridurre l’impatto ambientale complessivo dell’azienda. Questo non sempre è vero ed è una specificità del fornitore, non lo citerei come vantaggio del ‘buy’

Non ho trovato altri ‘falsi’ del approccio buy.

Il match Make vs Buy

Vista così sembra una battaglia impari, il buy ha veramente tanti, ma tanti vantaggi in più, il Make è semplicemente più complesso, più costoso.

Quando vince il ‘Make’?

C’è una sola risposta valida che supera ogni altra considerazione (compresi i costi), quando il prodotto su cui si opera la scelta è strategico ed incorpora uno o più elementi differenzianti che costituiscono il vantaggio competitivo dell’azienda.

La domanda che l’azienda deve porsi prima di decidere se optare tra Make e Buy è “quanto vantaggio competitivo risiede nel prodotto’.

in ambito informatico questa scelta può sembrare semplice ma non lo è. Un sistema di CRM può essere elemento differenziante o lo sono i processi che metto in piedi. Il gestionale per le polizze è elemento differenziate per una compagnia assicurativa o lo sono le polizze che vendo. Per entrambe la risposta è la seconda, ossia l’aspetto di business.

Per entrambe vale la pena fare una considerazione che potrebbe ribaltare lo scenario. Nell’ambito del CRM voglio offrire un servizio innovativo in grado di sfruttare un nuovo come le OBU (on board unit). Se adotto una soluzione buy, l’innovazione diventerà subito disponibile anche ai miei concorrenti. In modo similare se voglio creare un nuovo prodotto assicurativo che necessità di logiche applicative e integrazioni specifiche queste logiche diventeranno facilmente disponibili ai concorrenti.

Pubblicato il

Vendor lock-in, un male gestibile

I sintomi

Il vendor lock-in è un male da cui è difficile guarire e colpisce le aziende clienti. I primi segnali evidenti sono un incomprensibile aumento dei costi, per attività che nell’accezione comune richiedono un costo di implementazione molto basso.

La situazione tipica è questa:

Cliente: “Vorrei cambiare l’etichetta da quietanzamento a rinnovo. Riusciamo ad averlo online per Lunedì e quanto costa”

Fornitore: “Certo, il costo è di ca. 5ggu”

Cliente: “5ggu?!?!?! Ma è solo un etichetta”

Fornitore: “Non è così semplice, le etichette sono gestite dal database, ogni volta che tocchiamo il DB dobbiamo chiamare il sistemista che valida gli script, preparare un delta script e farlo girare in ambiente di collaudo, lì facciamo girare un insieme di test di non regressione per essere certi che non abbiamo creato problemi in altre aree dell’applicativo. Prima ovviamente faremo un analisi di impatto”

A questo punto il cliente vorrebbe capire se tutti i passaggi sono necessari, si rivolge a un esperto interno il quale stima: 5 minuti per cambio etichetta, 10 minuti per la creazione di un delta script che si traduce in “update db.labels set label=”rinnovo” where cond AND cond AND label=’quietanzamento'”, 30 minuti per installare lo script sul ambiente di collaudo, 30 minuti di test. Arrotondiamo 1 ora, 30 minuti. Cerchiamo di essere realisti, il primo tentativo fallisce sempre. Raddoppiamo: 3 ore. Vabbé ma sta pausetta caffè, una mail da rispondere? non vogliamo mettercela? 4 ore.

Fatto il passaggio con l’esperto che fiero della propria stima di 4 ore, il cliente torna dal fornitore. Con una contro proposta.

Cliente: “Abbiamo fatto dei ragionamenti interni, possiamo arrivare a riconoscere 1 giornata uomo”

Fornitore “Per quel ‘impegno non possiamo assumerci il rischio, tenete l’etichetta cos’ì com’è. (O al più cambiate solo il primo 20% dei caratteri)”

E’ questo punto il cliente vorrebbe rivolgersi a un altro fornitore, ma non può il contratto prevede che solo l’attuale fornitore può intervenire sul codice, sulle configurazioni, sul database e su qualsiasi altra componente direttamente o indirettamente connessa con l’oggetto del contratto. In quel preciso momento il cliente matura la consapevolezza di essere affatto dal male chiamato “vendor lock-in”.

Parliamoci chiaro, tutti i rapporti cliente/fornitore si trovano in una situazione di questo tipo per quanto riguarda i software proprietari dei sistemi core. Basti pensare che un progetto di migrazione di portafoglio dura mediamente 2-3 anni per rendersi conto degli elevati costi a cui si va incontro per sostituire i software core proprietari. Il punto importante è trovare un modo per rendere sostenibile questo rapporto, per sua natura sbilanciato a favore del fornitore.

Gare

Gare, sempre gare, per ogni attività. Le gare sono come la Tachipirina per il febbricitante. Se ci trova in una situazione di vendor lock-in le gare (per le nuove attività) aiutano a contenerne gli effetti, anche se nel lungo periodo creano assuefazione nel fornitore. La percezione di essere messi in concorrenza, di essere messi alla prova aiuta a calmierare i prezzi del fornitore dominante. Non sempre è possibile fare gare per i contratti che già legano al fornitore dominante, ma occorre sfruttare ogni singolo spiraglio. Se la gara riguarda i sistemi in situazione di vendor lock-in occorre prestare massima attenzione. Non puntare esclusivamente a una gara al ribasso sul progetto di avviamento.

Mi viene in mente il caso delle stampanti, oggi una stampante viene venduta anche a 40€ cartucce incluse, le singole cartucce costano 20€. Possibile che il costo della stampante sia solo 20€? Il fornitore ha semplicemente caricato sulle cartucce il costo delle stampanti. Il una gara al ribasso per un progetto che porta a un vendor lock-in il fornitore sarà disposto a scendere di prezzo fin dove vuole il cliente. Tanto rientrerà di costi in una fase post-rollout. Cercare di ragione sui costi post avviamento durante una gara è pressoché impossibile. Il costi  negli anni post “rollout” dipendono dal numero di adeguamenti  o innalzamenti funzionali richiesti. I business si muove e richiede sempre nuove funzionalità.

In sintesi:

  • Fate sempre gare. Aiuta a calmare i fornitori dominati.
  • Diffidate del cliente che in fase di gara sconta fino ad avere il prezzo più basso. Pagherete tutto dopo con gli interessi composti.

Separazione tra vendor di piattaforma e system-integrator

Ogni piattaforma software installata presso un cliente ha due componenti, una di “prodotto” e una di “personalizzazione”. Con prodotto si intendo il software nudo e crudo come è stato realizzato dalla software-house di riferimento, mentre con personalizzazione sono tutte le configurazioni e implementazioni necessarie alla soluzione software per funzionare correttamente nel ecosistema aziendale (flussi, connettori, integrazione,…). Per molte soluzioni software questa separazione viene naturale. Ad esempio database Microsoft o Oracle, il database Administrator è tipicamente di una società terza. Questa separazione deve essere mantenuta per tutto il software proprietario. Sempre.  I vantaggi sono:

  • possibilità di cambiare system-integrator senza cambiare piattaforma software
  • cambiare piattaforma software preservando il system-integrator e quindi le competenze specifiche legate all’azienda

Avere lo stesso fornitore ha inoltre il grosso svantaggio di rendere opachi sia i difetti di piattaforma che le mancanze nelle varie fasi progettuali.

In sintesi: E’ bene tenere separato il vendor di piattaforma dal system-integrator che gestisce il progetto di avviamento e la manutenzione

Pluralità di fornitori

Forse questo è uno degli elementi più importanti.  Ad alcuni è sicuramente capitato di andare in un negozio per comprare un adattatore per il nuovo dispositivo, considerato il topo della gamma, e di scoprire e che il dispositivo non usa connettori ma proprietari, che costano mediamente 3 volte tanto (ai tempi che fu c’era betamax, oggi capita sui cellulari di alcuni produttori)

Occorre sempre avere diverse alternative per tutte le attività di sviluppo/innalzamento funzionale della soluzione software scelta. Ossia diversi fornitori devono poter intervenire nello sviluppo di nuove funzioni. Affinché questo sia possibile occorre che la soluzione software abbia una caratteristica fondamentale: deve essere progettata a componenti con interfacce di estensione standard.

Esistono una moltitudine di standard (JSON SOAP e XML per integrazione, CMIS per i sistemi documentali, BPMN2 per i processi, OSGi come container,…). Tutti questi protocolli standard consento una facile estensione delle funzionalità. L’attività di system integration deve concentrarsi solo sullo sviluppo di questi connettori. E non cadete nel tranello di pensare che se i connettori vengono sviluppati dal vendor del sistema risparmiate perché il vendor conosce la piattaforma. Il vendor andrà a creare dei connettori talmente avvitati alla piattaforma che ogni attività di manutenzione costerà 3 volte tanto. Meglio spendere qualcosa di più prima che far lievitare a dismisura i costi dopo.

Diffidate inoltre dei fornitori che dichiarano di avere una piattaforma “aperta” o “open” come si dice oggi con tanto di architettura SOA e non fornisce documentazione a riguardo. Per Dichiarare di avere un architettura SOA è sufficiente disporre di web-service, ma ciò che conta è cosa posso farne di questi WS. Se non comprendono le funzionalità che interessano all’azienda avremo costi che lievitano in modo sproporzionato.

In sintesi:

  • Scegliere soluzioni per le quali esistono diversi system-integrator indipendenti in grado di sviluppare i connettori di integrazione
  • Scegliere una soluzione che abbia tutti i connettori necessari pronti e ben documentati (diffidate di chi dichiara di avere la piattaforma aperta e non fornisce l’elenco dei servizi aperti)

Proprietà intellettuale delle personalizzazioni

Ho visto situazioni in cui il cliente chiede delle personalizzazioni sulla soluzione software e quanto viene sviluppato rimane di proprietà intellettuale del fornitore. Perché questo? Motivi contrattuali è la prima risposata, ma qual’era la base di questa scelta? Semplice, ogni personalizzazione richiede espone il fornitore a rendere noti alcuni aspetti implementativi e per tutelare la proprietà intellettuale del proprio software tende a chiedere contrattualmente di mantenere la proprietà intellettuale di quelle che sviluppa. Dall’altro lato il cliente ritiene di non farsene nulla del sorgente e della proprietà intellettuale di quello che viene sviluppato e così il fornitore tira e il cliente cede a fronte di uno sconto che pagherà nei mesi successivi con l’interesse.

Mantenere il controllo delle personalizzazioni consente al cliente di entrare nel merito di quanto è stato realizzato, capirne la qualità e infine di chiedere a terzi di intervenire per correggere problemi. Un mito da sfatare è che “tanto del sorgente non sappiamo cosa farcene”. Basta un team di 2-3 bravi sviluppatori e qualsiasi sorgente viene ribaltato dalla a alla z in poco tempo.

In sintesi: Chiedere sempre la proprietà intellettuale degli sviluppi che vengono fatti e conservare in modo diligente il relativo sorgente compilabile.

Pubblicato il

Compilare una RACI

Compilare una matrice di responsabilità RACI sembra molto semplice ed intuitivo, eppure nasconde alcuni tranelli in cui c’è il rischio di cadere. Una RACI compilata correttamente aiuta a definire le responsabili, quindi gli interlocutori corretti. Una RACI sbagliata crea entropia e fraintendimenti. Alcune regole di base aiutano a definire una RACI in modo tale che la RACI sia di aiuto e supporto alle attività progettuali. L’acronimo sta per:

(R)esponsible: Colui che è responsabile operativamente dell’esecuzione dell’attività, diversi attori possono essere Responsible

(A)ccountable: Colui che ha le leve operative per far si che i (R)esponsible possano portare a termine il lavoro e colui che prende le decisioni in merito all’attività.

(C)onsulted: E’ un soggetto che viene consultato, spesso in qualità di esperto della materia (es: SME – Subject matter expert). Non svolge attività operativa, si limita a dare suggerimenti se interpellato

(I)nformend: E’ un soggetto che DEVE essere informato sul evolversi delle attività. Non ha leve dirette sul progetto, ma la sua influenza può essere di ostacolo o beneficio per il progetto

Regola 1 – Un solo (A)ccountable per attività

Una matrice RACI ha un solo accountable, ed è colui che prende le decisioni in merito all’attività che deve essere portata a termine. Vale sempre la regola di base che la responsabilità di una decisione è personale. Chi deve prendere una decisione può appoggiarsi a un team di esperti, avvalersi di comitati o anche fare delle votazione. La responsabilità della decisione rimane personale indipendentemente dal metodo scelto. (Qui si sarebbe molto da dire in merito alla responsabilità individuale e di come molti sfruttino dei comitati per de-responsabilizzarsi.) A differenza del (A)ccountable, i (R)esponsible possono essere diversi e sono i soggetti che lavorano sull’attività, gli esecutori.

Regole 2 – La giusta granularità di attività

Una matrice RACI viene sempre scritta per uno scopo ben preciso. In funzione dello scopo la RACI può avere un diverso livello di dettaglio delle attività. Esattamente come per le WBS si può rimanere a un livello molto alto o scendere a un livello di dettaglio esasperato. La granularità molto spinta fa si che ogni responsible possa diventare l’ Accauntable del livello inferiore. Pensiamo un team che esegue dei test, avremo un accountable per tutta la parte dei test, ossia colui che prende le decisioni sui test. Avremo più esecutori (R), ossia le persone che eseguono i test. Ciascuno di essi diventa responsabile (A) per la propria attività entrando nel livello di attività che seguono. In questo modo avremo avremo un responsabile (A) per i test funzionali, per i test di integrazione quelli di performance. Il punto delicato è capire a che livello fermarsi nel dettaglio delle attività rappresentate in una RACI. In genere la scelta migliore è sempre il compromesso, una RACI da allegare un contratto tenderà a essere di alto livello. Il project manager ne predisporrà una in cui rappresenta i principali riporti e stakeholder, in queste RACI si trova spesso il nome del team di riferimento più che il nome di una persona, indicavo in questo modo che la responsabilità (A) è in capo al team leader. Ogni team del progetto può predisporre una RACI nominativa per le proprie risorse.

Regola 3 – I soggetti corretti

Come per le attività anche i soggetti presenti nelle RACI possono essere rappresentati a diversi livelli. Nel livello più alto, anche qui usato nei contratti, i soggetti sono le società che partecipano al contratto o al progetto. Ogni società andrà poi a creare una propria RACI in cui rappresenta le responsabilità di diversi team coinvolti nelle attività e ciascun team organizzerà (se occorre) delle RACI in cui i soggetti sono i nomi delle risorse. La scelta della granularità dei soggetti è legata prevalentemente allo scopo per cui viene scritta la RACI. Più si scende di livello nelle attività più i soggetto sono gruppi sempre più ristretti fino ad arrivare al nominativo di una risorsa.

Un esempio sbagliato

Mi è capitato di vedere la matrice qui di seguito riportata come allegato a un contratto:

Il pallino nero indica il fornitore, il pallino rosso indica il cliente. Si tratta quindi di una matrice di alto livello e ha come obiettivo quello di definire le responsabilità delle due società. La matrice contiene diversi errori, il primo errore evidente è che nella colonna accountable in alcuni casi sono presenti due soggetti, sia il cliente che il fornitore. Il doppio accountable è sempre da evitare perché la responsabilità delle decisioni non mai congiunta. Il secondo errore è nella colonna (R), ossia chi esegue operativamente l’attività. In una RACI che definisce le responsabilità cliente/fornitore il fornitore non ha (praticamente mai) leve per far fare al cliente delle attività funzionali al progetto. Il fornitore non può infatti pretendere di avere la disponibilità delle risorse cliente nei momenti in cui servono (es: testing della RACI). Per questo motivo il fornitore non può essere accountable per attività in cui responsible è il cliente. Se si verifica realmente una situazione di questo tipo avremo uno scarso commitment del cliente e un rischio altissimo (quasi certezza) di fallimento del attività. Attenzione, può valere l’opposto, il cliente è accountable per attività di cui è responsible il fornitore. Esempio palese è l’attività time & material. Responsabilità cliente risorse fornitore. Il terzo errore è nell’attribuzione della responsabilità (accountable) errata, ossia il fornitore si assume la responsabilità di attività per le quali non ha alcun tipo di leva operativa, come ad esempio la ‘roll out strategy’.

La RACI che abbiamo appena visto ed allegata ad un contratto porta a dire che il rapporto cliente/fornitore non è chiaro. In particolare l’aspettativa del cliente è che il fornitore si assuma la responsabilità per ogni aspetto progettuale, anche quelli su cui obiettivamente non può intervenire. La stessa RACI ci dice che il fornitore è in una posizione di debolezza ed è disposto ad accertare condizioni inaccettabili pur di aggiudicarsi la commessa. Pessimo presupposto progettuale.

Pubblicato il

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.

Pubblicato il

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.