Log in



Author: Marco

Member Since: 2010-02-18 15:17:53

Posts by Marco:

Scrum applicato in azienda: i ruoli

November 3rd, 2020 by

Prendendo spunto da una attività che mi trovo a fare spesso in azienda, ho registrato questo breve video (10′) per fornire uno spunto su come applicare Scrum, che nasce con un’organizzazione piatta, ai progetti di una struttura organizzativa gerarchica tradizionale. Buona visione!

Un altro aiuto per un mondo di code: shift-left

June 16th, 2020 by

Un altro approccio suggerito da ITIL4 che ci può aiutare nel nostro nuovo mondo fatto di ‘social distancing’ e lunghe code per tutto è quello che va sotto il nome di Shift-left. Di che cosa si tratta?

Shift-left (letteralmente “sposta a sinistra”) si riferisce a un qualunque processo, che di solito è rappresentato in uno schema che procede da sinistra verso destra, e significa spostare un’attività e la relativa responsabilità verso la stazione di processo che è immediatamente a monte nel processo, quindi nello schema l’attività si sposta appunto a sinistra. Questo si rende necessario perché tipicamente la stazione a valle è più lenta, spesso è un collo di bottiglia e si cerca con lo shift-left di rendere più spedito tutto il processo, riducendo quindi i tempi di attesa in coda.

Prendiamo un esempio semplice, che possiamo sperimentare tutti, quello di una coda alla cassa di un supermercato. Una tipica operazione di shift-left è quella di mettere dei lettori di codice a barre a disposizione degli utenti del supermercato e far fare a questi ultimi, mentre sono in coda alla cassa, la lettura dei codici dei prodotti nel carrello, in modo che quando viene il loro turno le operazioni in cassa siano più rapide. L’operatore di cassa deve svolgere solo un controllo visivo sommario sul carrello e gestire il pagamento, con notevole risparmio di tempo alla cassa e conseguente risparmio sui tempi di attesa in coda.

Un altro esempio tipico è quello di far precompilare online agli utenti di un servizio un form con i propri dati, in modo che una volta arrivati allo sportello fisico l’operatore abbia già tutti i dati inseriti e debba solo controllarli, con risparmio di tempi e di code.

Esiste anche un concetto, meno comune, di Shift-right (“sposta a destra”) che significa, questa volta, spostare una attività e la relativa responsabilità verso la stazione di processo che è immediatamente a valle nel processo, quindi nello schema l’attività si sposta a destra.

Tutte le volte che ci viene messa a disposizione un’applicazione per il PC o per lo smartphone che non è stata completamente testata dagli sviluppatori, i quali si affidano ai feedback degli utenti per la messa a punto dell’applicazione, siamo in presenza di un approccio di Shift-right. L’attività di test è stata di fatto delegata agli utenti, che nel processo di sviluppo dell’applicazione stanno a valle.

Anche nel caso dei concetti di Shift-left e Shift-right, come per Swarming si tratta di approcci che si sono sempre utilizzati, ad ITIL4 il merito di averli suggeriti e sistematizzati.

Swarming ovvero un aiuto per un mondo di code

May 5th, 2020 by

Il mondo in cui ci siamo venuti a trovare a causa del COVID-19 è caratterizzato dalle code. Con la necessità del ‘social distancing’, di mantenere la ‘distanza sociale di sicurezza’, si sono create code lunghissime ovunque. Code fisiche, come le code che si formavano fuori dai supermercati i primi giorni dell’emergenza, o code virtuali, ora che progressivamente si sta riaprendo e ci si sta organizzando per gestirle con sistemi di ticketing via app. Ma ormai viviamo di code e sono sempre code lunghe. Quali metodi ci possono aiutare a gestire meglio le code e i servizi che si rinnovano in un mondo che è cambiato?

Prendendo spunto da ITIL4, edizione più recente del framework più noto per la gestione dei servizi non solo IT, mi viene in mente Swarming (letteralmente lo ‘sciame delle api’), un approccio che viene suggerito per aiutare a migliorare la gestione delle code. Di che cosa si tratta?

Swarming è definito come ‘un metodo per gestire il lavoro in cui un gruppo di risorse specialistiche o di stakeholder lavorano su un’attività inizialmente tutti assieme fino a quando non diventa chiaro chi è nella posizione migliore per continuare a svolgere il lavoro e a quel punto gli altri sono lasciati liberi di dedicarsi ad altri compiti’. Proviamo a capire meglio cosa significa in pratica.

L’idea fondamentale di Swarming parte da alcune osservazioni sui  limiti di efficacia dei sistemi classici di gestione delle code:

  • i ticket tipicamente vengono assegnati alle differenti code da parte del primo livello (chi prende in carico la richiesta) e il primo livello spesso non ha le competenze per valutare ne la priorità del ticket né a quale gruppo inoltrare il ticket stesso. Quello che spesso succede è che il ticket viene instradato in maniera non corretta e quindi deve essere riassegnato successivamente a una coda diversa allungando i tempi di evasione della richiesta perché il ticket resta in giro per molto più tempo prima di venire assegnato al gruppo di lavoro che è in grado di risolverlo e di gestirlo correttamente
  • la scarsa comprensione della richiesta porta spesso a fare escalation verso team di specialisti per dei ticket per i quali in realtà non sarebbe necessario, causando così un sovraccarico sulle risorse più specializzate alle quali viene assegnato il ticket e così facendo rallentando il processo e allungando i tempi di evasione della richiesta

Cosa fa quindi Swarming? In realtà fa la cosa più vecchia del mondo, quella che abbiamo sempre visto fare a tutti i ristoratori capaci di gestire l’affollamento dentro e fuori dal proprio locale: qualcuno, di solito il titolare nel locale, non si prende alcun compito preciso ma dedica il suo tempo a verificare se tutte le situazioni nelle quali viene gestita una coda stanno funzionando correttamente e se non stanno funzionando correttamente interviene a supporto. Gli interventi del titolare tipicamente riguardano:

  • la coda all’esterno del locale, dalla quale vengono fatti passare avanti gruppi piccoli , tipicamente di due persone, perché magari all’interno si sono liberati dei tavoli da due
  • Il monitoraggio delle richieste in cucina, per verificare che non ci siano intoppi all’evasione in tempi accettabili
  • il monitoraggio dei tavoli per accertarsi che non ci sia nessun ospite che sta aspettando un tempo eccessivo per ricevere il servizio al tavolo

Questo esempio, che abbiamo tutti sotto gli occhi, ci aiuta a capire quelli che nella sostanza sono i tre tipi di Swarming che vengono suggeriti:

  • Dispatch Swarms: esperti vanno a pescare dalla coda in ingresso al sistema non necessariamente l’attività che si trova in prima posizione e mandano invece avanti quelle attività per le quali vedono la possibilità di essere evase in maniera efficace rapidamente; nel nostro esempio è il titolare del locale (il nostro ‘esperto’) che esce e verifica se ci sono gruppi corrispondenti ai tavoli che si sono liberati all’interno e li manda avanti
  • Backlog Swarms: esperti vanno regolarmente a verificare le attività presenti nelle varie code all’interno del sistema e le evadono o le riassegnano ad altre code senza generare inutili attese; nel nostro esempio è sempre il titolare del locale che verifica regolarmente la coda delle richieste alla cucina o al forno della pizza e riorganizza il lavoro in modo da far procedere più spedita l’evasione delle richieste, eventualmente svolgendo lui stesso il lavoro
  • Drop-in Swarms: esperti monitorano regolarmente il lavoro di altri operatori e intervengono a supporto quando lo ritengono opportuno per accelerare il lavoro; nel nostro esempio è di nuovo il titolare del locale che monitora il lavoro dei camerieri ai tavoli e interviene a loro supporto qualora ritenga che possa essere utile per accelerare e migliorare il servizio

Come si vede bene è un’idea antica, che se applicata in modo sistematico può migliorare di molto la gestione del servizio anche in presenza di lunghe code. L’obiezione principale che viene fatta all’adozione dello Swarming è il fatto che l’impiego di esperti in un ruolo di supporto e quindi in definitiva senza nessun ruolo proprio assegnato, è visto come un uso inefficiente delle risorse aziendali.

L’esempio che ho fatto del nostro ristoratore penso tolga qualunque dubbio: abbiamo sperimentato tutti come i locali in cui il titolare svolge le azioni appena descritte siano nel complesso più efficienti.

Peraltro tali locali sono anche più gradevoli perché il titolare di solito non si limita a fare Swarming ma coinvolge gli avventori in una esperienza umana che poi è la vera ragion d’essere del suo lavoro e del suo servizio. E in questo momento abbiamo bisogno soprattutto di quello, di una migliore esperienza di servizio, nonostante la mascherina sul viso.

Lavoro Meglio mi ha intervistato su Cynefin

April 25th, 2020 by
Ascolta “#126 Puntata speciale [Intervista] Cynefin” su Spreaker.

Ringrazio l’amica e collega Leonarda Vanicelli, podcaster di Lavoro Meglio, che mi ha voluto invitare a fare una chiacchierata su Cynefin, il tema del mio ultimo articolo.

Qui sopra potete ascoltare l’intervista. Auguro veramente a tutti di potersi dedicare ad attività che valorizzino la nostra umanità per fare cose straordinarie assieme.

Capire quale modello applicare per ripartire con il COVID

April 16th, 2020 by

Una delle domande che ci stiamo facendo tutti è come ripartire quando sarà allentato il lockdown che si è reso necessario a causa dell’emergenza COVID. C’è molto fermento a livello politico, sociale e aziendale su ‘cosa fare’, anche se ritengo che sia molto più importante chiedersi prima ‘cosa ha senso fare’ e ‘che modello operativo ha senso applicare’ per procedere e per decidere, perché il rischio che corriamo è quello di interpretare la situazione a seconda di come siamo fatti noi e quindi applicare istintivamente i modelli che ci sono più congeniali o riproporre in modo più o meno consapevole i modelli che siamo abituati ad applicare a un contesto che però è radicalmente cambiato. Per comprendere quale modello operativo/decisionale abbia senso applicare si può utilizzare Cynefin (si pronuncia: /ˈkʌnɨvɪn/), un framework di interpretazione della realtà e di scelta delle strategie per affrontare le diverse situazioni del quale avevo già parlato in un precedente post di qualche anno fa e che nel frattempo ha acquisito popolarità.

Cynefin individua cinque domini rappresentativi della realtà in cui ci troviamo e l’esercizio consiste nel comprendere in quale dominio si trovi ogni situazione da gestire:

  • il dominio Ovvio (Obvious domain) è quello in cui le relazioni causa/effetto dei fenomeni sono appunto ovvie e comprensibili da tutti; in questo tipo di dominio ha senso agire seguendo delle cosiddette Best Practice, secondo schemi noti per cui le decisioni saranno prese secondo un modello del tipo Percepire – Categorizzare – Rispondere (Sense –  Categorise – Respond); per esempio le convenzioni dell’andare per strada sono ovvie e note a tutti e le decisioni saranno prese categorizzando le situazioni che si presentano secondo quello che dice la Best Practice che è il codice della strada; in questo dominio ha senso avere dei vincoli rigidi e gestire le attività stesse seguendo dei processi
  • il dominio  Complicato (Complicated domain) è simile a quello Ovvio, anche se le relazioni causa/effetto dei fenomeni non sono ovvie e comprensibili da tutti ma solo da degli esperti; in questo tipo di dominio ha senso agire seguendo delle Good Practice, soggette a valutazione e interpretazione da un esperto, le decisioni saranno prese secondo un modello del tipo Percepire – Analizzare – Rispondere (Sense – Analyse – Respond); per esempio una malattia nota richiede una conoscenza medica e la conoscenza di un protocollo terapeutico, occorrerà la valutazione di un medico; in questo dominio ha senso avere dei vincoli di governo, nel nostro esempio le prescrizioni generali del protocollo terapeutico, che però dovranno poi essere interpretate e applicate dal medico, che è l’esperto
  • il dominio Complesso (Complex domain) è quello in cui le relazioni causa/effetto dei fenomeni possono essere comprese solo a posteriori, ma non in anticipo;  in questo tipo di dominio si seguono e si plasmano delle Emergent Practice, che sono delle pratiche innovative basate sulla sperimentazione, o delle cosiddette Exaptive Practice, che sono l’adattamento di capacità e abilità già a presenti a nuove esigenze; in entrambi i casi le decisioni saranno prese secondo un modello Esplorare – Percepire – Rispondere (Probe – Sense – Respond); per esempio una malattia nuova richiede necessariamente della sperimentazione e l’adattamento di capacità, abilità e tecniche mediche già note a un nuovo contesto terapeutico e il protocollo terapeutico viene creato, modificato in modo dinamico e continuamente migliorato; in questo dominio ha senso avere solo dei vincoli abilitanti, ovvero delle regole che aiutano il sistema a procedere più spedito, come lo sono per esempio le regole di una metodologia di lavoro agile quale Scrum
  • il dominio Caotico (Chaotic domain) è quello in cui non ci sono relazioni causa/effetto e se ci sono non possono essere comprese; in questo dominio ci sono solo delle Novel Practice, nelle quali le decisioni saranno prese secondo un modello Agire – Percepire – Rispondere (Act – Sense – Respond); queste sono le tipiche situazioni di emergenza, dove si tende ad agire e fare immediatamente qualcosa senza porre limiti o vincoli, salvo poi provare a capire se quello che si è fatto può essere replicabile e cercare di spostarsi verso un dominio diverso, di solito quello Complesso
  • Il quinto dominio, quello del Disordine (Disorder domain) è quello in cui non è chiaro quale sia il modello interpretativo da applicare, è quello in cui ci troviamo la maggior parte del tempo ed è quello più insidioso; in questo dominio infatti la tendenza è a interpretarlo secondo la propria zona di confort o secondo la propria esperienza con il rischio di prendere decisioni secondo un modello errato; se sono una persona metodica e mi trovo a mio agio a gestire processi avrò la tendenza a considerare tutto ovvio e ad applicare processi anche dove i processi non funzionano e non possono funzionare

La tensione del genere umano è da sempre quella spostare quante più situazioni progressivamente dal dominio Caotico verso quello Complesso, poi verso quello Complicato e infine a quello Ovvio. Bisogna però stare attenti a interpretare le situazioni e collocarle nel dominio corretto, vediamo alcuni esempi.

La ipersemplificazione di ciò che semplice non è, per esempio prendere decisioni di tipo medico secondo il modello del dominio Ovvio, può far perdere il controllo della situazione e farci precipitare nel dominio Caotico, in figura rappresentato dal ‘dirupo’ tra il dominio Ovvio e quello Caotico.

Anche mettere troppi vincoli a qualcosa che appartiene correttamente al dominio Ovvio ci potrebbe far precipitare nel dominio Caotico: un limite di velocità troppo basso in autostrada fa precipitare l’autostrada nel caos.

È abbastanza evidente che la sottovalutazione iniziale dell’emergenza COVID che stiamo affrontando, la narrazione del COVID come se fosse una normale influenza, quindi gestendolo nel migliore dei casi secondo lo schema del dominio Complicato, nel peggiore secondo lo schema del dominio Ovvio e non più correttamente secondo lo schema del dominio Complesso come avrebbe dovuto essere, ci ha precipitato verso il dominio Caotico. A quel punto le reazioni sono state quelle corrette, i protocolli terapeutici e le misure di contenimento si sono sviluppati secondo lo schema Agire – Percepire – Rispondere tipiche del dominio Caotico. Progressivamente, man mano che le Novel Practice hanno cominciato a essere individuate, abbiamo quindi cominciato a spostare i protocolli terapeutici e le azioni nel dominio Complesso: i protocolli terapeutici che si stanno consolidando per via sperimentale sono delle Emergent Practice e si sono visti anche esempi di Exaptive Practice, il più mediatico dei quali è sicuramente stato l’adattamento delle maschere da snorkeling per l’ossigenazione dei pazienti in terapia sub-intensiva. Con l’andare del tempo e il consolidamento dell’esperienza e dei protocolli terapeutici ci sposteremo auspicabilmente verso il dominio al quale vogliamo che la medicina appartenga che è il dominio Complicato, anche se come sappiamo c’è sempre una deriva latente verso la medicina fai da te, quindi verso il dominio Ovvio, che però è pericoloso, come anche l’esperienza del COVID ci ha insegnato.

Lascio al lettore l’esercizio di andare più nello specifico ad analizzare alla luce di questo modello di interpretazione i singoli comportamenti che si sono visti nei mesi in cui è esplosa l’emergenza, sia da parte dei cittadini che delle istituzioni ai vari livelli. Non è difficile e il fatto sorprendente è che Cynefin aiuta a mettere in luce in maniera piuttosto lampante le letture corrette o errate che sono state fatte dai vari attori nelle varie situazioni.

Abbiamo parlato fin qui dell’aspetto medico-sanitario, ma avvicinandosi il momento della fine del lockdown e della ripartenza, ci sarà da rileggere tutto il contesto socio-economico-organizzativo e il modello interpretativo di Cynefin può essere di aiuto per non sbagliare l’approccio decisionale ed evitare di precipitare nel dominio Caotico. Alcuni modelli organizzativi apparterranno ai medesimi domini di prima dell’emergenza COVID, altri invece richiederanno un profondo ripensamento. La convivenza con il virus negli ambienti di lavoro richiederà che molte attività che prima erano gestite secondo le logiche tipiche del dominio Ovvio dovranno cominciare a essere gestite secondo logiche più tipiche del dominio Complesso, quindi in modo euristico, sperimentale e agile oppure secondo le logiche del dominio Complicato, quindi con l’aiuto di esperti.

Sul concetto di Velocity di un team agile

April 8th, 2020 by

Chi ha familiarità con le modalità di lavoro agile e i suoi vari framework di riferimento, dovrebbe aver sentito parlare del concetto di Velocity, che è la principale metrica di riferimento che viene utilizzata per misurare quanto lavoro un team di sviluppo può completare con successo nel corso di un intervallo di tempo fisso detto Sprint. Ma sappiamo cosa significa davvero misurare la Velocity di un team?

Il termine, per assonanza, tende a essere sempre tradotto con “velocità” per cui la metrica nella percezione comune diventa la “velocità del team e la sensazione è che il team debba ricercare la propria efficienza, che però per il modo di pensare agile è un controsenso.

In un contesto di lavoro agile infatti, quale per esempio Scrum, quello che importa non è tanto l’efficienza del team quanto la sua capacità di permettere al proprio cliente, in Scrum rappresentato dal ruolo del Product Onwer, di ottenere i risultati che creano valore per il cliente stesso.

Questi risultati che creano  valore in inglese sono detti Outcome e infatti si dice che le metriche per misurare un team agile devono essere Outcome based.

Per fare un esempio semplice ma efficace del concetto appena espresso, in un contesto agile a nessuno importa quanto un team sia efficiente a piantare chiodi o ad avvitare viti, quello che importa è la capacità di appendere quadri nel modo desiderato dal proprio Product Owner entro un tempo ragionevole previsto dal team e utile al Product Owner.

Siamo allora sicuri che “velocità” sia la traduzione corretta per il termine Velocity? Anche perché chiunque conosca un inglese anche elementare sa che normalmente “velocità” si traduce con “speed”. E quindi?

La spiegazione sta in un’altra delle mie passioni sportive, la barca a vela. Perché la parola Velocity in realtà è un termine nautico con un significato ben preciso e tutto mi fa pensare che chi ha adottato questo termine per i team agili abbia voluto utilizzare una metafora sportiva e in particolare velica, che però è risultata talmente sottile che quasi nessuno la ha colta.

La velocità di una barca a vela si misura con due grandezze: la velocità propria della barca nell’acqua (Speed Through Water – STW) che è quella che si percepisce navigando e la velocità effettiva sulla superficie terrestre (Speed Over Ground – SOG) che è quella che ci dice quanto la barca di sta effettivamente spostando. Senza qui addentrarsi in spiegazioni tecniche, le due velocità sono correlate ma non sono quasi mai uguali per via delle dinamiche dell’acqua. Sempre per fare un esempio semplice, si pensi a una barca che naviga contro corrente in un fiume dove c’è una corrente pari alla velocità della barca stessa; la STW sarà positiva, la barca rispetto all’acqua si muove, la SOG sarà nulla, rispetto alla superficie terrestre la barca è ferma.

La STW ci dice quanto rapidamente la barca si muove sull’acqua, quindi ci da un’indicazione di quanto è efficiente il moto della barca, la SOG ci dice quanto rapidamente la barca si muove sulla superfice terrestre, quindi ci da un’indicazione di quanto è efficace il moto della barca. Da notare che entrambe in inglese sono Speed, nessuna delle due è Velocity, che è un concetto ancora diverso. Cosa è la Velocity allora?

Nel disegno ho riportato una spiegazione un po’ semplificata del concetto velico di Velocity.

Una barca non può muoversi contro vento, al massimo può tenere un angolo di circa 45° rispetto alla direzione del vento. Se si vuole quindi raggiungere un obiettivo che sta controvento, occorre bordeggiare, ovvero ‘zigzagare’ come in figura con angoli di 45° rispetto alla direzione del vento e così facendo ci si avvicinerà al punto obiettivo. Quello che ci interessa non è né la STW, né la SOG ma la velocità con cui la barca si avvicina al punto obiettivo, che in inglese viene chiamata appunto Velocity Made good on Course (VMC), che è la componente della SOG che ci sta avvicinando al punto obiettivo.

Quindi il sottinteso di chi ha scelto il termine Velocity è che il team deve misurare la propria capacità relativa di avvicinarsi al punto obiettivo (che fuori di metafora è il risultato che crea valore per il Product Owner) e non tanto la propria efficienza di azione intrinseca (Speed Through Water – STW) ma nemmeno la propria efficacia assoluta (Speed Over Ground – SOG), perché per raggiungere l’obiettivo del Product Owner il team deve saper combinare la propria efficienza ed efficacia con una strategia che permetta di impiegare al meglio gli elementi propulsivi disponibili (il vento) per riuscire a raggiungere l’obiettivo nel tempo più breve possibile, ma senza compromettere il risultato. E chi ha esperienza di navigazione a vela sa bene che questa strategia di impiego degli elementi propulsivi disponibili è l’elemento che fa la differenza tra un buon velista e un principiante ed è più decisiva e importante rispetto a efficienza ed efficacia del mezzo, perché se si sbaglia il percorso o non si capisce come gira il vento e si finisce controvento, la barca si ferma.

Fuori dalla metafora velica, si usa quindi il termine Velocity perché non importa quanto il team agile sia efficiente e nemmeno quanto sia efficace, ma quanto sia complessivamente abile nel progredire il più rapidamente possibile verso gli obiettivi che creano valore per il cliente.

Organizzazione personale con GTD® integrata alla gestione dei progetti con PRINCE2®

February 10th, 2019 by

Utilizzo ormai da qualche anno il metodo GTD – Getting Things Done – per la mia organizzazione personale ed è uno degli strumenti che più mi ha permesso di dare ordine alla mia vita personale e professionale. Per questo ho fatto anche molte riflessioni per riuscire a integrarlo sempre più con PRINCE2 che è da ormai molti anni la mia metodologia di riferimento per la gestione dei progetti aziendali.

Uno degli aspetti che accomuna tutte le metodologie moderne di management, quale che sia il loro campo di applicazione, è l’enfasi sulla necessità di mettere bene a fuoco per ciascuna iniziativa intrapresa quelli che sono i risultati finali (outcome in inglese) e i benefici attesi in termini di valore generato. Ritroviamo concetti simili in PRINCE2 e GTD, ma anche per esempio in AgilePM, ITIL, Praxis Framework, Scrum e, pur se in modo più sfumato, in PMBoK.

Nel corso GTD Mastering Workflow level 2 viene approfondita la gestione dei progetti e viene suggerito un modello, il Natural Planning Model, molto efficace per la rapida e corretta impostazione di un progetto. Il modello consiste nei cinque passi come in figura, che partire dalla definizione dello scopo ultimo dell’iniziativa (purpose – rispondendo alla domanda perché facciamo il progetto?) e dei principi applicabili (principles – i vincoli o le regole irrinunciabili a cui dobbiamo conformarci) ci accompagna fino alla definizione delle prossime azioni visibili (next actions) da svolgere per avvicinarci al nostro risultato finale (outcome).

PRINCE2 dal canto suo prevede un processo di Avvio di un progetto e un processo di Inizio di un progetto che hanno l’obiettivo di permettere la verifica progressivamente più approfondita della giustificazione del progetto, arrivando a definire la direzione e l’estensione del progetto stesso. In particolare il processo di Avvio ha l’obiettivo di verificare se ci sono i prerequisiti per iniziare il progetto, documentati nel Project Brief, mentre il processo di Inizio ha l’obiettivo di stabilire le solide basi, documentate nella Project Initiation Documentation (PID).

Provando a sovrapporre il Natural Planning Model ai due processi di Avvio e Inizio di PRINCE2 si vede bene come il modello di pianificazione suggerito da GTD possa essere un valido supporto per l’efficace impostazione di un progetto condotto con PRINCE2 e per alimentare Project Brief e Project Initiation Documentation con i loro contenuti fondamentali. Viceversa alcune tecniche utilizzate in PRINCE2, in particolare lo sviluppo di Product Breakdown Structure e Product Flow Diagram possono supportare i passi di Brainstorm e Organizing del Natural Planning Model.

Nell’immagine ho indicato per ciascuno dei cinque passi del Natural Planning Model quali sono i capitoli corrispondenti da compilare all’interno dei template di PRINCE2. Il risultato conferma la coerenza tra i due approcci e la possibilità di un loro utilizzo integrato.

Imparare dalle lezioni e migliorare la gestione dei progetti

January 8th, 2019 by
«Io non perdo mai. A volte vinco, altre imparo»
Nelson Mandela
Uno degli aspetti che viene ripreso da tutte le metodologie di gestione dei progetti ma che spesso viene trascurato a livello applicativo è quello della gestione delle cosiddette lezioni apprese. Più o meno in tutti i contesti in cui mi trovo ad operare si fa qualcosa, ma è abbastanza raro trovare chi è disposto a utilizzare un metodo strutturato di apprendimento dall’esperienza. E a mio avviso un metodo strutturato di apprendimento dall’esperienza non può prescindere dal poter disporre di misure sulle performance di progetto.
Una best practice in tal senso la prendo quindi in prestito da ITIL e dal suo approccio CSI – Continual Service Improvement – approccio che mette la giusta enfasi sulla necessità di misurare i risultati di una qualsiasi attività per poter individuare i punti di forza su cui fare leva e i punti di debolezza da migliorare, senza mai perdere di vista il valore che ciascuna attività apporta all’azienda. L’approccio CSI – basato sul ciclo di Shewhart, ripreso da Deming – è stato pensato per il miglioramento dei servizi ma nella mia personale esperienza si può applicare altrettanto efficacemente ai progetti.
 
L’approccio CSI si compone di sei fasi, analizziamole alla luce dell’esigenza di apprendimento dall’esperienza nei progetti:
Fase 1: chiarire la visione, tenendo in considerazione la missione, gli obiettivi di breve e lungo termine, garantendo che tutti ne abbiano una comprensione comune. La visione rappresenta uno stato aziendale desiderato a medio termine e anche le modalità di gestione dei progetti devono contribuire alla sua realizzazione.
Fase 2: valutare la situazione attuale e stabilire una baseline, un punto di riferimento, di dove esattamente si trova attualmente l’organizzazione e, nel nostro specifico, il nostro approccio alla gestione dei progetti. Questa fase richiede delle misure e può essere impegnativa. L’aspetto fondamentale è l’onestà intellettuale, le misure possono essere di tipo qualitativo ma è essenziale essere onesti, non raccontarsela, motivo per cui un supporto esterno può essere utile. Per esempio l’utilizzo di un Modello di Maturità come quello fornito gratuitamente da Praxis Framework può aiutare a effettuare una valutazione sostanzialmente oggettiva.
Fase 3: definire i passaggi verso la visione in base alle priorità di miglioramento e stabilire obiettivi misurabili. Di solito è impossibile, o per lo meno molto difficile, passare direttamente dallo stato attuale a quello desiderato rappresentato dalla visione. Più verosimilmente si porteranno intraprendere azioni di miglioramento che ci faranno fare progressi nella direzione desiderata.
Fase 4: documentare e implementare un piano di miglioramento, facendo riferimento alle best practice per la gestione dei progetti. Ciascuno ha le proprie preferenze, ISO 21500, PMBoK, PRINCE2, AgilePM, Scrum, Praxis Framework sono tutte ricche di spunti e strumenti utilizzabili per il miglioramento. In questa fase è fondamentale mettere in atto azioni concrete di miglioramento a partire dal primo progetto disponibile
Fase 5: monitorare i risultati, utilizzando le misure e le metriche appropriate definite in precedenza. E qui di nuovo il Modello di Maturità di Praxis Framework  ci può fornire una misura oggettiva del miglioramento.
Fase 6: mantenere lo slancio assicurando che i miglioramenti siano integrati e che si vada in cerca di ulteriori opportunità di miglioramento. Per fare questo è importante che l’approccio CSI sia integrato nei processi di gestione dei progetti. Praxis Framework per esempio prevede due momenti in cui tale approccio può essere efficacemente utilizzato, nel Processo di Identificazione del progetto e nel Processo di Chiusura del progetto.
 
Insieme ai colleghi di E-quality abbiamo elaborato un percorso, PM@work, con l’obiettivo di supportare le aziende in questo percorso di miglioramento, in modo molto concreto e operativo.
 

Praxis Framework, un metodo integrato per il project management

January 26th, 2018 by

Ho conosciuto Praxis Framework grazie ai colleghi di E-quality che hanno contribuito alla metodologia sviluppando la sua versione italiana. Ho iniziato ad utilizzarlo circa tre anni fa e ho immediatamente apprezzato l’opportunità di disporre per il mio lavoro di consulenza di uno strumento davvero completo, integrato e disponibile sotto licenza Creative Commons Attribution-ShareAlike 4.0. Questo significa poter liberamente modificare e condividere il materiale prodotto a patto di menzionare adeguatamente la fonte e le modifiche apportate e ricondividere il materiale prodotto con la stessa licenza.

Ho ritrovato in Praxis Framework un po’ tutto quello che ero abituato ad usare nei miei progetti e da allora tendo a basare la mia attività su questa metodologia. Il framework è infatti ampiamente coerente e sovrapponibile con tutte le migliori pratiche di settore come PRINCE2 e PMBoK e ISO21500 e in più ha il pregio di essere stato completamente integrato a comprendere un po’ tutti gli strumenti che possono essere efficacemente impiegati per strutturare in azienda una metodologia di governance e gestione dei progetti.

Al PMExpo tenutosi a Roma lo scorso 27 ottobre sono stato invitato da Luca Gamebtti di E-quality a raccontare in un workshop di AMPG International una mia esperienza di applicazione di Praxis Framework, che poi è stata anche ripresa in un caso di studio ufficiale di APMG (cliccare qui per scaricarlo).

Si tratta dell’applicazione di Praxis in una start-up innovativa, sviluppata nell’ambito di un’agenzia di comunicazione consolidata, che ha la necessità di essere efficace, flessibile ed efficiente per poter operare su progetti di clienti diversi. Abbiamo quindi impostato una metodologia  di tipo agile. Allo stesso tempo, c’è la forte necessità di valutare in modo continuo, in corso di progetto, la giustificazione tecnico-economica e di disporre di governance e controllo gestiti per fasi.

Ho quindi adattato e incorporato i processi di Praxis Framework al modo di lavorare dell’organizzazione e ho utilizzato estensivamente il Canvas Report – Project Brief (stampato in forma di pannello a parete in PVC, come in foto) quale strumento visivo e agile di riferimento. Il Processo di Identificazione per arrivare alla definizione del Canvas Report – Project Brief lo ho impostato in forma di workshop partecipativo di una giornata – uno per ogni progetto – e poi ho utilizzato lo stesso Canvas Report – Project Brief come strumento a forte impatto visivo per continuare a rivalutare e mettere in discussione la giustificazione dei progetti lungo tutto il loro ciclo di vita.

L’implementazione della metodologia ci ha permesso di ottenere un più alto numero di progetti gestiti da parte dei team a parità di risorse, meno rilavorazioni causate da errori di gestione del progetto e maggiore attenzione di tutti alle giuste priorità di business.

Il consolidamento del nuovo approccio di lavoro ci sta ora avvicinando verso l’obiettivo finale di ottenere maggiore soddisfazione del cliente insieme a maggiore efficienza e conseguentemente anche a maggiore marginalità per i progetti in portafoglio.

Perché ITIL® Practitioner crea valore per le piccole aziende

August 4th, 2017 by

Sul blog di AXELOS mi è stato pubblicato un breve articolo in cui racconto come l’utilizzo dell’approccio che viene proposto nell’ambito della certificazione ITIL® Practitioner sia stato di utilità in una mia recente esperienza di consulenza.

ITIL® si porta dietro il pregiudizio di essere qualcosa di utile solo per grandi realtà: la mia esperienza mi ha insegnato che con un opportuno lavoro di “adotta e adatta” lo si può applicare proficuamente anche in realtà aziendali medio piccole e a progetti IT di portata limitata.

Si può leggere l’articolo cliccando qui, buona lettura!