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

Open Innovation: Le persone giuste al posto giusto

Quando rientro la sera dall’ufficio di Cernusco passo davanti a magazzino di Amazon a Segrate e non posso fare a meno di riflettere sulla crescita esponenziale che ha avuto. Da negozio di libri, alla vendita online, ai lettori per libri, al marketplace, logistica, servizi in cloud. Tutto merito di Jeff Bezos? In realtà no. La riflessione che faccio è che il successo di Amazon è stato guidato da Bezos, ma ciò che ha fatto la differenza è la capacità di esecuzione di ogni singolo dipendente. Per progettare e costruire la rete logistica di Amazon occorrono capacità fuori dal comune ma soprattutto sinergia e collaborazione a tutti i livelli. Ad esempio, la decisione di Amazon di espandersi nel cloud computing non fu solo una mossa strategica di Jeff Bezos, ma anche il risultato della cultura di innovazione e sperimentazione che permea l’intera azienda.

In alcune aziende il management delega ogni attività di implementazione della strategia ai propri riporti e così via, fino ad arrivare alle persone più operative, sovraccariche di lavoro e piene di responsabilità che non apparterrebbero al ruolo ricoperto. Questo è segno di manager con poca capacità decisionale e scarse competenze in materia. In altre aziende succede l’opposto, il management è scollato dai gruppi operativi al punto che le strategie aziendali sono note a una piccola enclave di manager. Questo è un segno di un management incapace di coinvolgere e delegare, forse anche di poca fiducia e confidenza delle proprie idee e delle capacità dei collaboratori. Se Amazon avesse avuto una cultura afferente a uno di questi due modelli non sarebbe diventata quello che è diventata. In Amazon, ogni dipendente, dal magazziniere all’ingegnere software, è una tessera cruciale nel mosaico del successo, ognuno con il proprio ruolo unico e indispensabile.

La differenza l’ha fatta proprio Bezos, perché la cultura aziendale di Amazon è quella trasmessa da Bezos ai sui riporti, ai riporti dei riporti e così via, fino a permeare in tutta l’azienda. Open Innovation è anche questo, una cultura aziendale in cui la comunicazione è trasparente, la strategia è condivisa e tutti sono focalizzati su un obiettivo comune. Questo passa necessariamente dalla persona giusta nel posto giusto, affinché ciascuno possieda le competenze necessarie per assumersi le responsabilità del proprio ruolo.

In definitiva, la storia di Amazon ci insegna che il vero motore del successo aziendale risiede nella sinergia tra una visione chiara e la capacità di ogni singolo individuo di contribuire a questa visione. Jeff Bezos ha saputo creare una cultura in cui l’innovazione e l’eccellenza non sono solo aspettative, ma realtà vissute quotidianamente. Questo ci porta a riflettere: quanto potrebbe essere diverso il panorama aziendale se ogni organizzazione adottasse un approccio simile? In un mondo in costante evoluzione, la lezione di Amazon è chiara: non è sufficiente avere le persone giuste; è fondamentale metterle nel posto giusto, fornendo loro gli strumenti e la fiducia per eccellere.

Pubblicato il

Evoluzione della Gestione dei Progetti nell’Era di GPT

Nell’ambiente lavorativo in rapida evoluzione di oggi, la gestione dei progetti non rimane indenne dal progresso tecnologico e organizzativo che comprende Intelligenza Artificiale Gestione Remota e Data Drive Decision Making.

È una realtà ineludibile: chi non si aggiorna perde inevitabilmente competitività. Non solo cambiano gli strumenti a disposizione, ma anche l’approccio alla progettualità deve evolversi. La capacità di adattarsi alle nuove tecnologie non è più un’opzione, ma una necessità per rimanere rilevanti e efficienti nel mercato.

L’intelligenza artificiale (AI), il decision making basato sui dati (data-driven decision making) e la gestione dei progetti a distanza (remote project management) stanno emergendo come pilastri fondamentali nell’evoluzione della gestione dei progetti. Questi strumenti rivoluzionari e modalità di operare offrono sistemi innovativi di interpretare e gestire i progetti, permettendo una maggiore flessibilità e precisione nelle decisioni. L’AI, in particolare, apre nuove frontiere nella simulazione di scenari complessi, nell’analisi predittiva e nell’ottimizzazione delle risorse.

L’AI si sta affermando come uno strumento versatile per supportare la gestione dei progetti. Può fungere da Subject Matter Expert (SME) consultabile a richiesta, offrendo consulenza e insight preziosi in tempo reale. Inoltre, un Project Management Office (PMO) potenziato dall’AI può analizzare in modo più efficace la coerenza delle informazioni e identificare i rischi di progetto. Un altro aspetto fondamentale è il supporto nell’intelligenza emozionale, cruciale nella gestione delle relazioni con gli stakeholder. L’AI può infatti aiutare a interpretare le dinamiche umane e migliorare la comunicazione, aspetto vitale soprattutto in un contesto di lavoro remoto. La gestione remota dei progetti richiede un’enfasi maggiore sull’intelligenza emozionale e i manager devono essere sensibili alle varie dinamiche emotive e culturali all’interno di un team distribuito.

La tracciatura dettagliata degli eventi e delle attività dei progetti è essenziale per un approccio data-driven efficace. Questo permette una migliore comprensione e previsione delle dinamiche di progetto. Inoltre, la governance dei progetti da remoto sta cambiando l’approccio alla progettazione, sia in metodologie tradizionali (waterfall) sia in quelle agili.

Conclusioni

L’evoluzione della gestione dei progetti nell’era delle tecnologie moderne richiede un ripensamento globale degli strumenti e delle strategie utilizzate. L’adozione di AI, data-driven decision making e remote project management non è solo una tendenza, ma una necessità per rimanere competitivi ed efficienti. La capacità di integrare questi nuovi strumenti con un approccio umano, considerando l’importanza dell’intelligenza emozionale, sarà determinante per il successo dei progetti futuri. Questa evoluzione rappresenta una sfida importante per i professionisti del settore, che sono chiamati a ridefinire i contorni del proprio lavoro in un mondo sempre più interconnesso e tecnologicamente avanzato.

Ecco alcuni link che potrebbero interessare

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.

WP to LinkedIn Auto Publish Powered By : XYZScripts.com