Agile Project Management Ing. Roberto Chiavaccini già docente Facoltà di Ingegneria di Pisa Seminario del 15 Maggio 2015
Cos'è? Un aiutino: è stato ideato nel 1902 dall'ingegnere tedesco Max Rietz
Quando ero un giovane studente il Regolo calcolatore logaritmico era il simbolo della tecnologia e del calcolo ingegneristico ed era un argomento dell'esame di Analisi 1 Io non lo utilizzo più e voi?
Cos'è?
Un aiutino, per chi non lo conosce È stato ideato nel 1917 dall'ingegnere americano H. Gantt, collaboratore del più famoso ingegnere F. W. Taylor All'Università ve l'hanno insegnato? L'utilizzate?
Il diagramma di Gantt, usato per Pianificare i lavori, è il simbolo del Metodo Predittivo usato dal Project Management classico
Visualizza il Piano dei tempi che, all'epoca del Gantt, era puramente predittivo (in base ad esperienza e buon senso)
Mentre oggi le previsioni sono ulteriormente elaborate con metodo scientifico e razionale, utilizzando gli algoritmi della teoria delle Reti / dei Grafi ed i computer (il precedente diagramma è stato elaborato con Project di Microsoft, uno dei SW più diffusi)
Se il Metodo è scientifico e razionale ed i risultati sono ottenuti tramite algoritmi e computer.. funziona sicuramente bene, potrebbe pensare un giovane ingegnere!
Allora una domanda: nella vostra esperienza di ingegneri quante volte sono rispettate le Previsioni (tempo, costo e persone) riportate in cartelli come il successivo?
?? IMPORTI? COSTI????????????
C'è peraltro da dire che, spesse volte, o perché non si conosce il Project Management o perché si reputa che sia troppo lungo e complesso, si ricorre al Metodo empirico ed i risultati sono anche peggiori!
Taylor e Gantt avevano infatti ragione quando sostenevano che alla base del Management e, quindi, anche del Project Management ci dovesse essere il metodo scientificorazionale e non l'empirismo!
Perché allora oggigiorno, malgrado gli algoritmi di ottimizzazione ed i computer, il Metodo previsionale dà risultati non troppo brillanti?
È ovvio Taylor e Gantt hanno vissuto 100 anni fa in un mondo ben diverso dall'attuale e, se i Princìpi vanno bene, le Tecniche ormai sono... un po' obsolete!
Fortunatamente altri ingegneri (bene o male il Management operativo ha una grossa base ingegneristica ), in particolare i giapponesi Taichi Ohno e Shigeo Shingo (a proposito ve ne hanno mai parlato all'università?), hanno aggiornato nella seconda metà del '900 le soluzioni del Taylor e del Gantt
Gli ingegneri giapponesi hanno sviluppato tali nuove soluzioni manageriali, ancora scientifico-razionali, universalmente conosciute come Lean Thinking, applicandole alla Toyota... con ottimi risultati!
2014 Toyota VW GM
Rispetto al Taylor e al Gantt gli ingegneri giapponesi hanno rivalutato l'importanza delle Persone ovvero la Toyota ha (Ohibò! direbbe un giovane ingegnere appassionato di automazione) reinventato gli operai
Il nostro business non è fare automobili, ma fare soldi (General Motors), utilizzando il metodo razional-tayloristico (n.d.r) Prima di produrre automobili produciamo persone (Toyota), i soldi saranno una conseguenza (n.d.r)
Da notare che anche Volkswagen è riuscita a primeggiare utilizzando (tramite Porsche) la consulenza di... Toyota
È forse un caso? Di chi è questo marchio?
Porsche Consulting (Core Mission) The range of services has five main focuses: Transformation to a lean organization Strategies for functional areas (ie. Production, Logistics, Development, etc.) and administrative areas (i.e. human resources) Reorganization / restructuring Process optimization for one or more value chains Coaching and training of management and staff to achieve a sustainable change in their performance and attitude
Oggi il Lean Thinking, sulla scia di Toyota, è applicato anche alla Progettazione/Sviluppo prodotti e prende vari nomi: Agile Project Managerment è uno di questi
L'Agile Project Management adotta un Metodo non più Predittivo ma Adattivo (iterativo e incrementale), atto a gestire la progettazione e lo sviluppo di prodotti complessi in un mondo altamente dinamico ed imprevedibile dove quindi non ha senso utilizzare delle previsioni
Ed è questo quello che è successo rispetto ai tempi del Taylor e del Gantt: il Mondo è cambiato e sta diventando sempre più dinamico ed imprevedibile e, quindi, il metodo Agile diventa ancor più necessario
Tant'è che, recentemente, il PMI ha introdotto una specifica certificazione (PMI-ACP)SM PMI Agile Certified Practitioner per tutti i progettisti
La progettazione Agile, spesso conosciuta come Scrum, è basata sui princìpi del "Manifesto Agile", pubblicato nel 2001 ad opera di 17 professionisti nello sviluppo SW ed oggi è usato anche nello sviluppo HW
Oltre ad Agile/Scrum altri nomi Lean che potreste sentire sono: Lean Product Development per l'industria manifatturiera Lean Costruction/Last Planner per l'edilizia Lean Government (per la pubblica amministrazione) Lean Healthcare (per la sanità) ---
Il Lean sta infatti diffondendosi a macchia d'olio in tutti i tipi di organizzazione
Di seguito non tratterò gli aspetti teorici e formali del Agile Project Management (per questo vi lascio un po' di bibliografia) ma vi farò toccare con mano, con due esempi, come lavora ed i suoi vantaggi
Gli esempi si basano su due classici Princìpi Lean: Per essere più efficienti (minori tempi e costi) e per ottenere risultati di miglior qualità si devono, per prima cosa, eliminare tutte le attività inutili e costose in ottica del cliente finale ovvero di chi paga
Quando il problema è complesso, come ad esempio nella Pianificazione, si deve cercare di risolverlo in maniera semplice Lean, reinventando. le persone
WIEV Matrix Aumentare efficienza e qualità in progettazione
Preferite essere o apparire?
Preferite essere o apparire?
Se preferite l'apparire considerate inutili i successivi ragionamenti
Se viceversa ritenete razionalmente necessario l'essere vi faccio un'ulteriore domanda: conoscete le problematiche dei Processi organizzativi (all'università o da qualche altra parte le avete studiate)?
Per ISO 9000 infatti la centralità in tutte le organizzazioni, se vogliono effettivamente fare Qualità, sono i Processi
Da ISO 9000: 2000 42
Tutte le organizzazioni lavorano per Processi ovvero svolgono un Macroprocesso (di livello 0) costituito da un insieme olistico = sistemico di Processi / Sottoprocessi / Attività (livelli e sottolivelli)
È allora inevitabile che, se si vogliono raggiungere i desiderati risultati di Efficacia ed Efficienza (in modo che le organizzazioni siano sane e, quindi, oggettivamente certificabili), si debba concentrare l'attenzione, molta attenzione sui loro Processi
Vi faccio quindi un'ulteriore domanda: nelle vostre organizzazioni, prima o in seguito alla certificazione ISO, è cambiato qualcosa nella gestione dei Processi?
I vostri processi sono ben conosciuti e formalizzati, magari disegnati nel dettaglio come fate per i vostri prodotti?
Ad esempio: il Top Management ha obbligato le persone dell'organizzazione a conoscere e migliorare (<curare>) continuamente i Processi perché siano effettivamente di sana e robusta costituzione?
Ovvero, poiché la Customer Satisfaction è il più importante obiettivo della ISO 9000, la principale diagnosi da fare sarebbe: esistono Processi e/o Attività che l'organizzazione svolge ma che non servono alla soddisfazione del Cliente?
Se così fosse la prognosi per il miglioramento sarebbe semplice: vanno eliminati / ridotti
Mettetevi infatti nei panni del cliente di un Progettista: sareste contenti di pagare per qualcuna delle successive attività definite, in gergo Lean, Muda = Waste = Sprechi?
Errori (elaborazioni sbagliate da rifare) Difetti di processo (attività inutili e/o ridondanti ad esempio ricerca di informazioni e di disegni tenuti in disordine, ) Ritardi per code create dal multitasking (il progettista manda in ritardo il vostro lavoro perché ne deve portare avanti molti e tutti insieme)
Set-up mentale (il tempo che un progettista perde per passare con la dovuta attenzione da un progetto a un altro) problema sempre causato dal multitasking Attività di supporto alle altre funzioni aziendali (Produzione, Vendite)
Ci sono poi altre attività Abilitanti, che in generale servono per tutti i progetti e non specificatamente per il vostro e che portano a gran perdite di tempo e di costo
Come clienti riconoscete che sono necessarie, ma preferireste -visto che pagate voi- che fossero un po' più semplici, meno lunghe e costose
riunioni (formali ed informali) attività manageriali (piani, Gantt, relazioni tecniche, ) aggiornamenti sulle Normative e attività di Compliance (comprese le scartoffie varie per le certificazioni ISO) attività di Formazione continua
attività rallentate per l'apertura e la chiusura di ogni nuovo progetto bassa velocità dei progettisti con poca esperienza.
Per riassumere possiamo dire che un'attività è a Valore e, quindi, i clienti sono disponibili a pagarla (seppure a malincuore) solo se fa avanzare il loro progetto
Le attività di Progettazione possono quindi essere: A Valore = Essenziali per l'avanzamento del progetto dei Clienti Abilitanti = Non a Valore (NVA) ma attualmente necessarie per svolgere quelle a Valore Muda = NVA e non necessarie
Se lo Stato Corrente fosse A Valore Abilitanti Muda Nei panni del cliente come vorreste che fosse lo Stato Futuro?
Se lo Stato Corrente fosse A Valore Abilitanti Muda L obiettivo dello Stato Futuro dovrebbe essere Maggior Efficienza, in ottica dei clienti, si ottiene eliminando le attività Muda e minimizzando quelle Abilitanti!
Se siamo d'accordo sulla definizione facciamoci una domanda: quanto incidono in media (in termini di tempo e, quindi, di costo) le attività Non a Valore in aziende che non hanno adeguatamente curato i propri Processi?
Di seguito alcune statistiche americane ma quelle italiane (o le vostre). sono migliori?
Alcune statistiche americane 21% 42% 37%
Per capire cosa fare bisognerebbe allora, per prima cosa, conoscere la situazione reale (As Is) misurando le attività Abilitanti e Muda per legarle poi alle diverse cause
Per farlo si possono compilare le check list di tutte le attività realmente svolte dai progettisti decidendo a priori (in base alla definizione) se sono a Valore / Abilitanti / Muda
Ai progettisti si deve inoltre chiedere di segnalare quante volte in una giornata sono passati da un progetto all'altro perché, come si è detto, questo comporta una gran perdita di tempo a causa del Setup mentale
Se in contemporanea si portano avanti più di tre progetti diversi la produttività, tutte le ricerche lo hanno confermato, scende rapidamente a zero
Qualora i progettisti siano dei dipendenti le risposte dovranno essere anonime per evitare che gli stessi si sentano controllati
Registrando i dati effettivi ed in base alla dimensione dell'inefficienza e alle sue principali cause, si potrà poi decidere se intervenire e come intervenire
Secondo le solite statistiche le principali 10 cause di inefficienza sono quelle riportate di seguito (voi siete immuni?)
Ambiente di lavoro caotico interruzioni costanti Poche Risorse Esistenza (casuale) di Colli di bottiglia Mancanza di chiare Priorità fra Progetti Mancanza Comunicazioni per Barriere Funzionali Trade off fra Requisiti definiti in modo insufficiente (?) Efficienza e Soddisfazione Grossi Cambiamenti nei Requisiti (?) del Cliente Carenti considerazioni sui problemi a valle (produzione,..) Eccesso di Progettazione, sindrome primo della classe Troppe riunioni *!&$% Sovraccarico da e-mail. La valanga delle e-mail
Per aumentare fortemente l'efficienza si dovrebbero utilizzare 8 Regole tattiche e alcune Tecniche operative (se qualcuno all'università ve le avesse insegnate non sarebbe stato meglio?)
Per far perdonare l'università vi regalo una Regola tattica (una sola però, non c'è tempo per le altre!) che potrete utilizzare da subito per migliorare (un po') l'efficienza vostra e del vostro gruppo
Regola tattica Tutti i progettisti devono utilizzare due ore al giorno allo stesso orario (ad esempio tutti i giorni dalle 9 alle 11) per svolgere solamente attività a Valore su un solo progetto
Durante le due ore non si fanno riunioni, non si risponde al telefono o alle email, non si corre a risolvere un problema urgente neanche se il Capo sbraita, si lavora svolgendo attività a valore per un solo progetto e basta
Passiamo ora al secondo esempio
Lean Planning Un Caso
Di seguito vi propongo, tramite un caso esemplificativo, un sistema Lean Planning alternativo al sistema predittivo classico
Un Piano è un insieme di scelte razionali (che bello per degli ingegneri), generalmente organizzate nel tempo (il Gantt ne è un esempio), per conseguire nel futuro un determinato obiettivo
La Pianificazione è, ovviamente, il Processo che porta alla formulazione del Piano
C'è una riflessione da fare: se un territorio è ben conosciuto il percorso per andare da A a B è ragionevolmente pianificabile (definibile e ottimizzabile) a priori, magari con un Gantt (Ops! Con Google Map)
Territorio conosciuto Siamo qui Vorremmo andare qui
Viceversa non possiamo pensare che il percorso sia chiaro e pianificabile quando dobbiamo muoverci in un territorio sconosciuto ed il futuro, per sua natura, è ignoto
Siamo qui Futuro - Territorio ignoto? Hic sunt leones Vorremmo andare qui
Ci sono solo tre cose che possiamo e dobbiamo conoscere con certezza: dove siamo, dove vorremmo essere e quali i mezzi a disposizione per muoverci... in mezzo ai leoni
Ma soprattutto c'è una qualità che sicuramente dobbiamo avere: una grande capacità di adattamento
La capacità di adattamento rappresenta infatti la migliore garanzia per attraversare un territorio ignoto e... per avere un vantaggio competitivo duraturo su chi non ha tale capacità
Ogni piccolo passo deve essere una lesson learned che ci aiuta a riconoscere il prossimo passo e aumenta la nostra conoscenza e capacità di adattamento
Ne consegue, come diceva il famoso Generale prussiano H. Graf Von Moltke (il Vecchio), che: Pianificare è tutto, i Piani sono niente in quanto nessun Piano può sopravvivere al contatto con il nemico (con i leoni)
Perché è importante il pianificare mentre non lo sono i piani?
Perché Pianificare vuol dire sforzarsi in ogni istante di trovare la migliore soluzione data l attuale situazione ed il livello di conoscenza del problema
Un'evidenza: mano a mano che il tempo passa e la conoscenza del problema migliora, la situazione già è cambiata
Cambia inoltre la realtà intorno a noi da cui è necessario: Ripianificare continuamente per decidere cosa fare tenendo conto della nuova conoscenza e della situazione reale cosicché i piani precedenti divengono subito obsoleti
Utilizzare un sistema organizzativo (uomini e mezzi) adattabile per far si che lo stesso possa essere adeguato a piani continuamente variabili
La Ripianificazione continua è molto importante nella Progettazione, tipico processo di ricerca e apprendimento a prova ed errore nello spazio della Conoscenza
La Ripianificazione continua sarebbe ovviamente importante anche nel Management Strategico (tradizionalmente basato invece su rigidi Piani Strategici a 3/5 anni) o nel Management Tattico (tipicamente basato sugli ancora più rigidi piani annuali di tipo economico-finanziario ovvero sui Budget)
La Ripianificazione continua deve essere di tipo Pull e Just in Time (JiT): si ripianifica il prima possibile (JiT) però solo se e quando la situazione lo richiede (Pull)
Qualcuno potrebbe domandare: per pianificare/ripianificare con maggiori possibilità di successo è necessario essere o utilizzare un Project Manager Professionista (PMP)?
Questo punto di vista è rinforzato da un corpo di conoscenze, sempre più complesso, definito Project Management
Male non sarebbe però, per avere successo, è soprattutto necessario che nella Pianificazione / Ripianificazione siano coinvolti in prima persona i membri del Team che realizzerà il Piano (oltre agli operai reinventiamo anche i progettisti!)
È solo la democratizzazione della conoscenza e l autonomia delle scelte, aspetto tipico del Lean, che rende infatti più flessibili e più adattabili le organizzazioni, elemento critico, come detto, per il successo!
Un Piano sviluppato da un PMP, magari con informazioni sollecitate ai membri del Team ed imposto dall alto (Push), è poco motivante, è rigido, è sempre in ritardo e, quindi, è sempre obsoleto
Un Team che, Just in Time, pianifichi se stesso in base gli eventi reali (Pull) e con tutto l'impegno emotivo e buy-in che tale coinvolgimento collaborativo comporta, ha maggior probabilità di raggiungere gli obiettivi
La Vittoria discende da un insieme di episodi locali (sempre Graf Von Moltke) e gli episodi locali sono molto meglio pianificati e gestiti da chi li vive che non da un lontano Generale!
Se un Team costruisce e aggiorna il proprio Piano, lo capisce a fondo e concorda la sua vitalità, le possibilità di raggiungere gli obiettivi aumentano notevolmente
In un mondo perfetto quindi ogni membro di un Team dovrebbe essere un PMP
Nel mondo reale basta che ogni membro del Team abbia un minimo di competenze di Project Management (che sia almeno un ACP) e che sia motivato
Il Caso: un Team di persone (noi) deve andare in auto da Livorno a San Pietroburgo e, quindi, il capo chiede di Pianificare il viaggio (tempi, tappe e costi)
Un Project Manager Tayloristico (razionalpredittivo), per suo abito mentale, pianificherebbe entrando molto nel dettaglio
Definirebbe a priori il percorso, valutando i vari tipi di strade e le velocità ammesse, stabilirebbe dove mangiare, dove dormire, quanti Km fare ogni giorno, dove fare carburante,.
Alla fine riuscirebbe a costruire un Piano preliminare perfetto, dettagliato con tempi e costi, per predisporre le cose da fare ed il budget necessario per il viaggio ed il capo sarebbe contento
Questo piano perfetto, ma costoso (in soldi e tempo), sarà poi rispettato?
Sicuramente no: un incidente, un ristorante chiuso, una strada in rifacimento, la necessità di sgranchirsi le gambe,... faranno si che il piano iniziale sia una bella utopia
Sarebbe necessario che chi viaggia aggiornasse continuamente il PMP, magari rimasto a Livorno, su cosa sta succedendo in modo da fargli fare gli straordinari per ripianificare
Ma allora si deve rinunciare a un accurato Piano generale perché tanto sarà sbagliato e necessiterà di continui aggioramenti?
Certo che no, la pianificazione è importantissima per avere un ordine di grandezza di cosa succederà nel futuro in modo da predisporre i tempi ed i mezzi
Ma se si può farla a costi e tempi ridotti è meglio!
È meglio un buon piano eseguito subito che un piano perfetto eseguito. la prossima settimana (Generale G. S. Patton)
Visto che tanto le cose non avverranno come previsto non ci basterebbe ottenere l'80% dei risultati con il 20% dei costi e dei tempi di pianificazione?
Ordine di grandezza: ce la faremo in due giorni o si deve prevederne di più, quanto si spenderà per il carburante, i ristoranti e gli alberghi,?
Vediamo una Tecnica che, senza bisogno di un Project Manager professionale, potremmo utilizzare per stabilire in poco tempo e a bassi costi un Piano preliminare di massima (si ipotizza di non disporre di Google)
Si parte dalla carta generale dell'europa (nemmeno molto dettagliata) e si pianifica insieme (Nemawashi in gergo Lean) perché. più occhi vedono meglio di due!
Un aiutino ( 600 km)
Cerchiamo di rispondere alle domande base della pianificazione: quanti i Km da percorrere e quante le ore di guida?
Per fare le nostre scelte in modo sistematico ed in comune utilizziamo la sequenza di Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, 6765,...)
Scegliamo dalla precedente tabella i Km e le ore di guida e poi facciamo le medie
L'opinione media è che i Km sono e che ci vorranno. ore
Secondo Google i Km sono 2.774 e ci vogliono 31 ore: se avessimo avuto questi dati molto più precisi cambieremmo il numero dei giorni in cui pianificare il viaggio?
Ovvero, utilizzando una Pianificazione grossolana, abbiamo fatto un errore così grande da impedire un esito positivo del viaggio?
E poi è proprio importante che un PMP stando a Livorno continui a prevedere continuamente, in base alla situazione variabile, dove fermarsi a dormire per essere lui a prenotare un albergo che per qualche motivo non raggiungeremo e/o che raggiungeremo troppo in anticipo perché la strada è libera e scorrevole?
Quello che poi serve è che il Team, meglio ovviamente se composto da persone che abbiano almeno un po' di cultura di Project Management, sia motivato e sappia adattarsi
È ovvio infatti che se il nostro Team è motivato in quanto abbiamo deciso da soli che spenderemo una certa cifra, in quella dovremo rientrare e, quindi, se spenderemo di più per il carburante. andremo a mangiare in posti meno cari!
È allora meglio utilizzare un sistema evoluto e costoso di pianificazione associato a un sistema organizzativo rigido che segue le direttive o pianificare in modo più Lean e utilizzare un sistema organizzativo flessibile ovvero risorse motivate e capaci di adattamento?
Motivazione e capacità di adattamento delle persone si ottengono, per il Lean tramite due routine standardizzate chiamate Kata (ecco perché Toyota inventa gli operai e... gli Ingegneri) in quanto li forma al Kata del Miglioramento continuo -Kaizen- tramite il Kata del Coaching)
Avendo detto che è un po' obsoleto, quale Strumento di Pianificazione Agile si può usare al posto del Gantt?
Lo Scrum Board, tabellone a parete (Visual Planning) per pianificare e controllare le cose da fare (i task) nel corso del successivo Sprint
Utilizzando il metodo Agile i Team, dopo aver fatta una pianificazione globale di massima, si autopianificano operativamente per Sprint ovvero per blocchi standard di tempo (2-4 settimane) per dare regolarità al loro lavoro (Takt Time)
Item (che il Team sceglie per lo Sprint) Task Backlog YYY XXX 3 XXX 2 XXX 5 YYY 3 YYY 2 ZZZ 1 ZZZ Ongoing Done (i successivi (Drill Down) task da fare) XXX 4 XXX To Do ZZZ 2 ZZZ 3 Workflow YYY 1 XXX 1
Ma c'è uno strumento ancora più Lean, magari utilizzabile anche individualmente, per pianificare le attività senza utilizzare gli Sprint?
Ma certo: il Kanban Board!
Item (tutti quelli possibili) Task Backlog (Drill Down) XXX 4 XXX YYY To Do (3) XXX 3 XXX 2 Done XXX 1 XXX 5 YYY 3 YYY 2 ZZZ 1 ZZZ Ongoing (2) ZZZ 2 ZZZ 3 Workflow YYY 1 Limiti Limiti Kanban
Bibliografia essenziale PMBOK5 Lean Thinking, J. P. Womack e D. T. Jones, Guerini e Associati Essential Scrum, K. S. Rubin, AddisonWesley Series Agile Estimating and Planning, M. Cohn, Prentice Hall
r.chiavaccini@gmail.com roberto.chiavaccini@unipi.it