Agile Project ManagementIng. Roberto Chiavaccinigià 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 scientifico-razionale 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 ?È forse un caso ?

Di chi è questo marchio ?

Porsche Consulting Porsche Consulting (Core Mission)(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

42

Da ISO 9000: 2000

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)

● SSet-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 Set-up 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”

Requisiti definiti in modo insufficiente (?)

Grossi Cambiamenti nei Requisiti (?)

Carenti considerazioni sui problemi a valle (produzione, ..)

Troppe riunioni *!&$%

Eccesso di Progettazione, sindrome “primo della classe”

Sovraccarico da e-mail. La valanga delle e-mail

Trade off fra Efficienza eSoddisfazione del Cliente

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)

Siamo quiSiamo qui Vorremmo Vorremmo andare quiandare qui

Territorio Territorio conosciutoconosciuto

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 quiSiamo qui Vorremmo Vorremmo andare quiandare qui

Futuro - Territorio Futuro - Territorio ignotoignoto

??Hic sunt leonesHic sunt leones

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 (razional- predittivo), 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 !

(600 km)

Un aiutino

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)

TaskBacklog

(Drill Down)

To Do(i successivi task da fare)

Ongoing Done

XXX

XXX 2 XXX 1XXX 3 XXX 4

XXX 5

YYYYYY 1YYY 2 YYY 3

ZZZ

Workflow

ZZZ 1

ZZZ 3

ZZZ 2

Ma c'è uno strumento ancora più Lean, magari utilizzabile anche individualmente, per pianificare le attività senza utilizzare gli Sprint?

Ma certo: il Kanban Board !

ItemTask

Backlog(Drill Down)

To Do(3)

Ongoing(2)

Done

XXX

XXX 2 XXX 1XXX 3 XXX 4

XXX 5

YYYYYY 1YYY 2 YYY 3

ZZZ

Workflow

ZZZ 1

LimitiLimiti

Kanban

ZZZ 3

ZZZ 2

(tutti quelli possibili)

Bibliografia essenziale

● PMBOK5● Lean Thinking, J. P. Womack e D. T. Jones,

Guerini e Associati ● Essential Scrum, K. S. Rubin, Addison-

Wesley Series● Agile Estimating and Planning, M. Cohn,

Prentice Hall

r.chiavaccini@gmail.com

roberto.chiavaccini@unipi.it