Intervento dell'Ing.Rea durante l'evento L'IMPRESA AGILE & MOBILE 2.0, svoltosi il 9 e 10 ottobre presso l'Hotel Caesius Thermae & Spa Resort, Bardolino (Vr).

1. 1
Oltre ogni aspettativa di successo – la TOC

2. 2
Oltre ogni aspettativa di successo – la TOC
La Teoria Agile Project Management
Ing. Claudio Vettor & Ing. Michela Rea

3. 3
Oltre ogni aspettativa di successo – la TOC
COME E PERCHE’
IMPRESA AGILE

4. 4
Oltre ogni aspettativa di successo – la TOC
AGENDA DELLA GIORNATA

5. 5
Oltre ogni aspettativa di successo – la TOC
AGENDA DELLA GIORNATA
AGILE PROJECT MANAGEMENT
Processo e progetto : due facce della stessa medaglia
Progetti:
Definizioni
Approccio tradizionale
Il super problema: il governo della variabilità
Le lezioni apprese dal process management (LEAN)
Il framework AGILE
Il conflitto insoluto.. one step ahead
AGILI E ROBUSTI: L’approccio TOC

6. I processi possono insegnare qualcosa ai progetti?
AGILE O FRAGILE?

7. 7
Oltre ogni aspettativa di successo – la TOC
Dal processo al progetto:
una storia sistemica

8. •È più facile partire dall’esistente, soprattutto nell’ottica del miglioramento (migliorare un modello è difficile)
•Se è nuovo per me non è detto che sia nuovo in assoluto
•Solo pensando in termini sistemici è possibile comprendere i diversi livelli di gestione dei progetti (program management (contenuti e requisiti)/portfolio management (priorità e investimenti)/project management/ team management (day by day, dimensionamento)
I vantaggi del pensare in termini di processo

9. Dal processo al progetto: dal flow chart al Gantt

10. Dal processo al progetto

11. C’è un modo di guardare al processo che facilita un project management delle attività in senso lato e, ove opportuno, anche in senso stretto Questo modalità richiede due step preparatori:
-Inquadrare il processo nel sistema e sottosistema, concettualmente e operativamente
-Dettagliare il processo in termini di tempistiche e risorse
La transizione da processo a progetto:
uno sforzo di disegno organizzativo

12. Lista processi

13. Mappatura del singolo processo

14. Foglio risorse

15. Indicatori

16. Progetti:
Definizioni
Approccio tradizionale
Il super problema: il governo della variabilità
Le lezioni apprese dal process management (LEAN)
Il framework AGILE
Il conflitto insoluto.. one step ahead
AGILI E ROBUSTI: L’approccio TOC

17. Organizzazione e BPM

18. Project management è l’applicazione di conoscenze, attitudini , tecniche e strumenti alle attività di un progetto al fine di conseguirne gli obiettivi Un progetto è uno sforzo temporaneo intrapreso allo scopo di creare un prodotto, un servizio o un risultato unici Caratteristiche di un progetto:
• Un solo punto di fine attività
• Almeno due attività collegate da un rapporto di dipendenza
• Difficoltà intrinseca di prevedere la durata (dell’insieme) delle attività
Definizioni utili

19. Dal processo al progetto: il continuum

20. • Rispetto dei tempi, costi, qualità del prodotto/performance del servizio -> maggiori ricavi, margini, clienti più soddisfatti
• Un piano di attività stabile ->utilizzo più produttivo delle risorse
• Misure semplici e obiettive dell’avanzamento del progetto -> riunioni più brevi, stakeholder meglio informati
• Indicazioni più chiare se intraprendere o meno azioni correttive -> AC più mirate e meno sprechi
• Indicazioni di miglioramento -> progetti futuri con migliori ricavi, margini e clienti più soddisfatti
Cosa ci aspettiamo dal PM?

21. •Il PMI è un organismo indipendente che opera come ente di certificazione/accreditamento, scuola di formazione, ente di normazione
•Prince2 è stato sviluppato dal governo inglese, inizialmente come standard di PM per l’informatica
Scuole di PM

22. PMI-PMBOK
PRINCE 2
Approccio
Checklist
Metodologia
Modalità di pianificazione
Tutta all’inizio
Stage gate
Dimensioni del progetto
Ambito, qualità, costi, tempo
Ambito, qualità, costi, tempo, rischi, benefici
Figure decisionali
Project manager e project sponsor
Project manager, executive, utilizzatore senior, fornitore senior
Focus su
Stato di avanzamento
Requisiti e loro tolleranze
Scuole del PM «tradizionale»

23. •Più si riesce ad anticipare e risolvere i problemi in fase progettuale minore è il costo che l’organizzazione sostiene e maggiore è la probabilità di raggiungere gli obiettivi del progetto
Aspettative e PM tradizionale: le fasi della progettazione

24. •Queste sono le attività di planning secondo il PMBOK
In questa fase viene pianificato nel dettaglio:
-Lo scopo- i prodotti
-La tempistica-schedulazione
-Il budget
-L’organizzazione delle risorse umane
-La comunicazione con gli stakeholder
-La gestione della qualità
-Il risk management
-Approvvigionamento
Aspettative e PM tradizionale: i processi di dettaglio

25. In teoria
In pratica
Rispetto di tempi, costi, qualità
Una lotta continua per metter d’accordo tempi, costi e obiettivi
Piano di attività stabile
Continue ripianificazioni
Misure semplici e obiettive del’avanzamento del progetto
Chiarezza all’inizio e poi nebbia: aggiustamenti soggettivi
Indicazioni chiare se intraprendere o meno azioni correttive
Interventi eccessivi troppo presto o correzioni troppo leggere troppo tardi
Indicazioni di miglioramento
“faremo dei miglioramenti quando avremo tempo”
Qual è la nostra esperienza reale del PM?

26. I progetti gestiti con metodi tradizionali evidenziano che:
• i progetti completati nei tempi sono il 44% del totale
• mediamente il completamento dei progetti avviene in tempi uguali al 220% del tempo pianificato
• mediamente il completamento di un progetto avviene con il 190% del costo pianificato
• il 30% dei progetti non si conclude
• il 70% dei progetti (che si concludono) si conclude con un risultato inferiore alle aspettative Il 30% del tempo di progetto viene speso per:
• Attività burocratiche
• Cattiva gestione delle risorse condivise
• Scarsa definizione delle priorità sulle attività
Il PM è cos’ che funziona?

27. Perché i progetti falliscono?

28. Spesso abbiamo difficoltà a finire i progetti in tempo
Spesso abbiamo difficoltà
a rispettare il budget di progetto
Spesso le finalità e
le specifiche dei progetti
vengono ridimensionate
per cercare
di rimanere nel budget e
di rispettare la data di consegna
Incertezza nei progetti ?
Legame tra tempo, costo e specifiche

29. •Guardiamo più da vicino il problema dell’incertezza e in particolare il modo in cui calcoliamo le date di conclusione.
•Quale data di conclusione stimerete per una determinata attività di progetto?
A
B
C
probabilità
tempo
50%
30%
Stime e misura delle prestazioni

30. Il nostro capo ci chiede quando sarà pronta una determinata attività di progetto
SE…
Il nostro capo
si aspetta che
manteniamo ciò
che promettiamo
E…
Ci sentiamo impegnati da ciò che promettiamo
E…
Sappiamo che c’è sempre qualcosa che non va mentre si realizza l’attività
E…
Siamo pieni di lavoro (multitasking)
E…
La stima della durata dell’attività sarà conservativa
ALLORA…
Stime e misura delle prestazioni

31. • Gli studi comportamentali parlano chiaro, nei primi due terzi dell’intervallo di tempo allocato viene svolto circa 1/3 del quantitativo di lavoro
•Se aggiungiamo effetti come la “paralisi decisionale da troppe alternative” e la legge di Murphy abbiamo un quadro completo di come, anche con stime conservative, un singolo task possa andare in ritardo
Milestone e sindrome dello studente

32. una unità di
Throughput
una unità di Throughput
una unità di
Throughput
Tre unità di Throughput
Task A
Task B
Task C
Task C
Task B
Task A
Multitasking

33. • Quale sarà l’impatto sull’intero progetto se il task A è completato in soli 3 giorni?
• Cosa succede se il task C richiede 8 giorni?
• Cosa succede se i task A,B e C sono completati tutti e tre in soli 2 giorni? Il task D sarà pronto a partire con 3 giorni di anticipo? I ritardi si propagano. Le variazioni positive (anticipi) vengono filtrate e perse
Task D 10 giorni
Task C
5 8 giorni
Task B 5 giorni
Task A 5 3 giorni
Dipendenza dei task

34. 100%
100%
100%
100%
100%
100%
75%
Il completamento della maggioranza delle attività sui rami del percorso non critico non significa che il progetto sia a buon punto
€
€
Inoltre inserire dei milestone (ai quali magari è legato una parte del compenso) incentiva distorsioni della realtà
Misura erronea dello stato di avanzamento

35. Diverse risposte in funzione del grado di complessità / variabilità / numero di interdipendenze (tra task e/o persone) dei progetti Team dedicati a un progetto Team condivisi tra progetti Variabilità interna (risorse, competenze, priorità (valore, tput) Variabilità esterna (comprensione dei bisogni del cliente, auto consapevolezza del cliente sui propri processi
Modello organizzativo e gestione della variabilità

36. Sviluppo nuovo prodotto, modello organizzativo e framework «Agile»: un’introduzione

37. Il processo di sviluppo nuovo prodotto viene diviso in fasi e monitorato con dei punti di controllo:
-Gli Stage sono delle sequenze di attività suddivise secondo una logica temporale e di argomento
-I Gate sono dei momenti di controllo in corrispondenza dei quali vengono definiti e valutati dei deliverable. Sulla base di questa valutazione si può verificare un avanzamento, un blocco, un ciclo ricorsivo o anche un abbandono del progetto
Tecniche tradizionali di pianificazione del nuovo prodotto: stage gate

38. •Queste fasi hanno validità quasi universale
Stage gate

39. PMI-PMBOK
PRINCE 2
Approccio
Checklist
Metodologia
Modalità di pianificazione
Tutta all’inizio
Stage gate
Dimensioni del progetto
Ambito, qualità, costi, tempo
Ambito, qualità, costi, tempo, rischi, benefici
Figure decisionali
Project manager e project sponsor
Project manager, executive, utilizzatore senior, fornitore senior
Focus su
Stato di avanzamento
Requisiti e loro tolleranze
Scuole del PM «tradizionale»

40. Le forme organizzative

41. Differenze, vantaggi e svantaggi

42. •Sponsor (in fase preliminare fornisce i requisiti, si occupa di trovare fondi e supporto, conferisce autorità al PM…, in fase operativa approva i cambiamenti, aiuta a scegliere tra le diverse opzioni etc)
•Project manager
•Team (è particolarmente coinvolto nella creazione della WBS, nel risk management, nella qualità)
•Responsabile di area/manager funzionale (“presta” le risorse, è interpellato su questioni specifiche, condivide la documentazione)
I ruoli secondo il PMI

43. •Top management o Program management
•Project Board (ruolo simile allo sponsor ma meglio definito e piu’ sfaccettato)
•Project manager
•Team manager o team
I ruoli secondo Prince 2

44. Ambiente di lavoro caotico
Priorità non chiare
Barriere funzionali alla comunicazione
Requisiti di prodotto mal definiti
Mancanza di risorse
Cambiamenti di specifica
Problemi di producibilità non anticipati
Paralisi progettuale (gold plating)
Troppe riunioni e email
I problemi principali: verso l’Agile Framework

45. Progetti Complessi
Persone
Mercato e Requisiti dinamici
Controllare il Progetto
Motivare il Team
Prodotti/Servizi di Qualita’ e Valore
A G I L E !
Agile quando?

46. Cercate produttività? Agile non fa per voi! Agile è per:
• apportare facilmente cambiamenti
• creare velocemente valore
• aumentare la trasparenza
Agile quando?

47. AGILE NON E’
AGILE E’
Poca o nessuna documentazione
Uno specchio della realtà
Requisiti di massima
Un processo guidato dal valore
Nessuna pianificazione
Un continuo adattamento agli input esterni con lo scopo di massimizzare il valore globale dell’output
Fare e poi pensare
Un waterfall interattivo
Nessun controllo di progetto
Agile cosa

48. Che bisogni ha il cliente? Come lavora il cliente? Cosa vede il cliente? Come comunicare con lui? Quali aspettative ha?
1.Lavorare a stretto contatto con il cliente
2.Respirare la stessa aria
3.Avere le stesse aspettative Fa superare più facilmente la conflittualità intrinseca dei contratti
Coinvolgere il cliente

49. Cos’ è per il cliente il valore?
•Un servizio/prodotto che apporta valore al proprio business
•Aumenta la competitività
•Riduce i costi
•Aumenta i ricavi
•Aumenta la penetrazione di mercato
•Alza le barriere all’ingresso ai competitor
•Crea nuovi mercati
•ecc
Creare valore

50. L’Agilità è la capacità di tenere insieme:
•Stabilità e flessibilità
•Ordine e caos
•Pianificazione ed esecuzione
•Ottimizzazione e capacità di sperimentare
•Controllo e velocità
L’ « Agilità»

51. The Agile Manifesto

52. •Produrre valore il prima possibile ( e confrontarsi subito con il cliente)
•Accogliere il cambiamento e pianificare in modo iterativo
•Team che si auto-organizza e modello partecipativo
•Semplicità e sostenibilità tecnica e nelle modalità di lavoro
•Vediamo una panoramica di alcune idee chiave dal mondo AGILE
I principi sottesi

53. Value= attività a valore aggiunto
Type 1 = attività non a valore aggiunto ma necessaria
Type 2 = attività non a valore aggiunto e non necessaria
Semplicità e gestione delle priorità

54. Subito qualcosa di funzionante/stabile: test driven development cycle

55. I requisiti vengono espressi in termini di “storie” associate alla “persona” e ogni iterazione implementa un certo numero di storie
Oltre il requisito: l’ «Agile Persona» e le «storie»

56. Iterazione e visione di insieme

57. •No al micro- management, team che si auto-organizzano
•Logica della “staffetta”
•Utilizzo funzionale del tempo delle persone coinvolte
Una diversa cultura dell’HR

58. •Questa lista viene progressivamente aggiornata per evidenziare il reale stato di avanzamento e la variabilità che comporta lavoro non pianificato
Semplici strumenti visuali di PM: un esempio di action list

59. Le pull card colorate contrassegnano le azioni e il colore ne evidenzia la priorità o il tipo
Semplici strumenti visuali di PM: un esempio di Wall Gantt

60. MODALITA’
VANTAGGI
Le riunioni di coordinamento con tutto il team devono durare solo 15 minuti ed essere tenute in piedi di fronte alla lavagna
Spostano il focus sulle urgenze, l’esecuzione e costringono alla sintesi e selezione
Sviluppare un piano di lavoro per ogni componente del team
Permettono di correggere in corsa e riallocare le risorse
Tutte le altre questione sono rinviate a riunioni separate, se necessario
Evitano l’effetto accumulo che causa ritardi
Il coordinamento del team

61. I principi generali della Lean nel PM

62. La prima critica lean al PM tradizionale è organizzativa:
-Una rigida divisione funzionale (es: centralizzare la funzione di controllo o quella di preventivazione) è considerata una delle cause principali di errori nella pianificazione e successive ottimizzazioni locali/competizione per le risorse che causano sprechi e ritardi
- Il suggerimento è che tutti i team di manager e tecnici portino avanti tutte le tipologia di attività (stima, preventivazione, contrattazione/negoziazione ed esecuzione). Se il progetto è molto grande con più team coinvolti ha senso che per ognuna delle 4 core competencies citate in precedenza ci sia un project leader
- Viene definita organizzazione a “work cells” con i project leader che si pongono come dei facilitatori e mettono la loro competenza a servizio dei team
Anche la lean è sistemica

63. Una pianificazione estremamente dettagliata che gestisca in modo rigido le date illudendosi di poter operare una perfetta sincronizzazione a priori è molto più soggetta agli effetti dirompenti della variabilità perche li amplifica nella misura in cui:
• non permette di capitalizzare sugli anticipi e sulle risorse effettivamente, non teoricamente, disponibili
• disperde le energie su più fronti, facendo anche partire la maggioranza dei sottofiloni di progetto troppo presto (tanto poi si bloccano)
• è basato sull’illusione che tenendo le persone impegnate su più fronti e facendo girare molte materie prime, attrezzature e semilavorati questo massimizzi l’efficienza
Pianificare….il giusto

64. • il suggerimento non è di non pianificare nulla affidandosi al fato
• è molto importante dedicare del tempo alla pianificazione “logica” del progetto capendo bene quali sono i prerequisiti e le condizioni al contorno che rendono possibile e efficace lavorare su un sottogruppo di attività, indicando anche un orizzonte temporale
• è invece inutile e controproducente riempire il progetto di milestone dettagliati (tutti i livelli WBS) tentando una sincronizzazione millimetrica a livello di pianificazione (sono ammessi dei milestone per la fase)
• i team devono abituarsi a pensare in termini di riconciliare una pianificazione quotidiana pragmatica con una visione logica del progetto come sistema e dei macro-obiettivi. E’ fondamentale l’idea del Quality Assignment
• il “chase up” è stigmatizzato in quanto non serve e disturba (suggerito il controllo statistico di processo sull’affidabilità ove possibile)
Pianificare….il giusto 2

65. La pianificazione del breve nasce dall’accordo su cosa ottimizza complessivamente il progetto e dall’evitare logiche di competizione. Viene dato il via libera solo se c’è evidenza del fatto che il lavoro potrà procedere SENZA INTERRUZIONI
Pianificare….il giusto 3

66. • ridurre la variabilità e eseguire diligentemente il lavoro come se fosse una linea produttiva
• a quel punto aumentare la velocità
• deviazioni dal flusso concordato sono considerate alla stregua di difetti su cui intervenire subito
Esecuzione dei chunk-lean allo stato puro

67. Misura del commitment

68. • raggiungimento degli obiettivi
• team building e grande apprendimento
• motivazione e entusiasmo (you guys made a believer out of me!)
Vantaggi

69. Avere e dare visibilità su tempi, risorse,budget specifiche
B
Progettare tutto subito
D
Progettare solo quando i requisiti sono certi (progettare step by step)
D’
Gestire la variabilità e avere flessibilità interna
C
La nuvola di conflitto
•Il budget
Gestione del progetto efficace ed efficiente
A
• La durata di un progetto non è banalmente la somma delle durate delle singole attività (percorso critico), così come è molto difficile essere affidabili sul budget se non si consolida
• Soprattutto se lavoriamo in un contesto multiproject o dobbiamo coinvolgere delle risorse temporary dobbiamo sapere quando
•Rispetto alle specifiche se gestite individualmente c’è un alto rischio di perderne per strada o di gold plating
• Una progettazione a corto raggio mi consente di minimizzare la probabilità di lavorare su requisiti che poi decadono
• Nella progettazione tradizionale c’è sempre una forte probabilità di non avere a disposizione gli input che servono per procedere al momento giusto
• Progettando “all’ultimo” ho sempre un numero di informazioni maggiore e un numero di rischi inferiore
• Dare visibilità è considerato sinonimo di qualità da parte del cliente
•Soprattutto se lavoriamo in ambiente multiproject dobbiamo avere ben chiari gli impatti complessivi per essere efficienti
•La variabilità non gestita minaccia seriamente l’efficacia e l’efficienza

70. • La lunghezza e la complessità del progetto non è influente
• la variabilità non è ipotizzabile a priori né controllabile in corso d’opera
•Il modo in cui (non) coinvolgiamo il cliente è l’unico possibile
•Non esistono metodologie intermedie tra il tradizionale e l’Agile
•Le metodologie si escludono a vicenda e utilizzano strumenti completamente diversi
•Il clima umano e le dinamiche organizzative non influenzano la gestione della variabilità
• Non è realmente possibile fare risk management
assunti D-D’
Progettare tutto subito
Progettare solo quando i requisiti sono certi (progettare step by step)
• La durata di un progetto non è banalmente la somma delle durate delle singole attività (percorso critico), così come è molto difficile essere affidabili sul budget se non si consolida
• Soprattutto se lavoriamo in un contesto multiproject o dobbiamo coinvolgere delle risorse temporary dobbiamo sapere quando
•Rispetto alle specifiche se gestite individualmente c’è un alto rischio di perderne per strada o di gold plating
• Una progettazione a corto raggio mi consente di minimizzare la probabilità di lavorare su requisiti che poi decadono
• Nella progettazione tradizionale c’è sempre una forte probabilità di non avere a disposizione gli input che servono per procedere al momento giusto
• Progettando “all’ultimo” ho sempre un numero di informazioni maggiore e un numero di rischi inferiore
La nuvola di conflitto

71. • La scelta della metodologia dipende prima di tutto dal livello di variabilità. Sono elementi importanti anche la lunghezza del progetto, il clima organizzativo e la relazione con il cliente, nonché il particolare ramo o chunk di progetto su cui si sta lavorando
• La lunghezza e la complessità del progetto non è influente
• la variabilità non è ipotizzabile a priori né controllabile in corso d’opera
•Il modo in cui (non) coinvolgiamo il cliente è l’unico possibile
•Non esistono metodologie intermedie tra il tradizionale e l’Agile
•Le metodologie si escludono a vicenda e utilizzano strumenti completamente diversi
•Il clima umano e le dinamiche organizzative non influenzano la gestione della variabilità
• Non è realmente possibile fare risk management
La nuvola di conflitto

72. La direzione della soluzione - TOC Che strada seguire?

73. •Tutti gli algoritmi hanno in comune due elementi
•fondamentali:
l’idea di subordinazione ad una, ben definita, risorsa finita
il meccanismo di controllo sulla corretta esecuzione dell’algoritmo
Gli algoritmi

74. €
•Per massimizzare la velocità di generazione di valore da parte di
•un vincolo di thruput è necessario:
Identificare: determinare il vincolo
Sfruttare: far lavorare il vincolo a pieno ritmo e sul giusto mix di prodotti
Subordinare: costruire il sistema intorno al vincolo
Gestione della risorsa finita

75. €
istante in cui il vincolo dovrebbe cominciare a processare
€
tempo
tempo di buffer ovvero anticipo con cui il materiale deve essere pronto davanti al vincolo
carta di controllo del buffer
Il meccanismo di controllo: buffer management

76. Cos’è un progetto:
•un insieme di azioni necessario per soddisfare
•delle specifiche stabilite da un committente,
•in un tempo stabilito e all’interno di un budget definito
Gestione di progetto e la genesi di catena critica

77. Schedulazione
Fase di pianificazione
Fase di realizzazione
• lista attività
• durate
• foglio risorse
• sequenze
• calendari risorse
• data di consegna
1.Eventuale Risoluzione contesa di risorse e Identificazione catena critica
2.Possibile Fast tracking/schedule crashing
3.Dimensionamento e inserimento dei buffer
• aggiornamento delle attività
• costruzione delle carte di controllo/buffer management
Schedulazioni individuali: le fasi

78. Creazione del network:
•Elencare le attività o tasks di progetto
•Mettere le attività in sequenza evidenziandone le dipendenze logiche
Capacità finita: tempistica e risorse
•Stimare la durata di ogni singola attività, ipotizzando che la o le risorse associate lavorino sul task in modo dedicato, senza multitasking
•Valutare la disponibilità temporale delle risorse
•Data di consegna
Gestione sistemica di progetto: quali input

79. •Chiamiamo Catena Critica la sequenza più lunga di eventi dipendenti considerando l’utilizzo di risorse comuni.
•Questa sequenza determina la lunghezza del progetto.
•Essa è il fattore limitante (constraint) del progetto.
La catena critica

80. Catena critica e tempo

81. Soluzione delle contese (level load )
Percorso critico
_ste deve contemporaneamente svolgere 2 lavori
_alex deve contemporaneamente svolgere 2 lavori

82. Il cammino critico
La catena critica
Solo dopo lo step «level load» può essere definita la Catena Critica

83. Una volta schedulato un progetto può risultare troppo lungo rispetto alla data di consegna richiesta dal cliente o internamente.
Ci sono essenzialmente due metodi di compressione che presentano benefici ma anche costi/rischi
Metodi di compressione della catena critica

84. Ha quasi sempre un costo
Schedule Crashing

85. Richiede elevata sincronizzazione e grande capacità di scomporre logicamente le attività
Schedule fast tracking

86. Ipotizzabile in contesti molto stabili con progetti ripetitivi, tendenzialmente ambienti multi- project
Schedule resource leveling

87. aggiungere protezione alle attività
non aggiungere protezione alle attività
completare il progetto in tempo
D
D’
C
A
promettere al cliente un lead time breve
gestire un progetto con successo
B
Per…
Dobbiamo…
e quindi…
dobbiamo…
e quindi…
Il vincolo mentale del project management

88. D
D’
C
A
B
rispettare le scadenze è importante per il cliente
il cliente non affida un progetto a chi non è in grado di garantire un lead time sufficientementebreve
- ci sono fluttuazioni statistiche ed eventi imprevedibili che non possono essere anticipati - la protezione ci permette di gestire l’incertezza
aggiungere protezione aumenta considerevolmente il lead time
tutti i task hanno bisogno di protezione
gestire un progetto con successo
completare il progetto in tempo
promettere al cliente un lead time breve
aggiungere protezione alle attività
non aggiungere protezione alle attività

89. •Il project buffer realizza questa injection “aggiungere protezione solo sulla sequenza di task che determina la lunghezza del progetto”. invece di proteggere ogni singolo task della catena critica la protezione viene cumulata alla fine di questa in un buffer unico, il project buffer.
L’injection è il project buffer

90. D
D’
C
A
B
Il ramo non critico ha una funzione di supporto
Una gestione efficace passa anche attraverso il contenimento dell’inventory
- prima parto più cose faccio
- ritardi sul ramo non critico impattano sulla catena critica
Se finisco prima automaticamente nel sistema si crea dell’inventory di wip non necessaria
La partenza determina il tempo di completamento del progetto
gestire con successo il ramo non critico
finire in tempo e non minacciare la catena critica
risparmiare i costi del tenere inventory
Partire il prima possibile
Partire all’ultimo momento
Conflitto early start vs late start

91. I rami non critici del progetto che impattano sulla catena critica sono controllati e protetti da un altro buffer detto feeding.
L’injection è partire solo un buffer di tempo prima: il feeding buffer

92. Schedulazione
Fase di pianificazione
Fase di realizzazione
• aggiornamento delle attività
• costruzione delle carte di controllo/buffer management
fatto
fatto
Siamo pronti ad andate in produzione
• lista attività
• durate
• foglio risorse
• sequenze
• calendari risorse
• data di consegna
1.Risoluzione contesa di risorse
2.Identificazione catena critica
3.Dimensionamento dei buffer
4.Inserimento dei buffer

93. •No multitasking – quando si inizia un’attività si prosegue finchè è conclusa
•Ogni attività inizia non appena le risorse sono disponibili e i prerequisiti soddisfatti
• Le attività finiscono nel più breve tempo possibile
• Anticipi sulla critical chain anticipano la fine dell’intero progetto
• Anticipi sulle feeding chain aumentano la protezione della critical chain
Questi tre principi insieme si definiscono lo stile del roadrunner
L’esatto contrario del multitasking

94. •Un sistema è stabile se produce risultati prevedibili.
•La capacità di prevedere è la vera essenza del Management
•La domanda alla base di qualsiasi valutazione e successivo
intervento è: il sistema è stabile?
•Un meccanismo semplice e potente è in grado di rispondere a
questa domanda. Questo meccanismo si chiama buffer management.
Buffer management e variabilità

95. istante in cui il vincolo dovrebbe cominciare a processare
€
tempo
carta di controllo del buffer
•Se i processi che influiscono sul buffer non sono stabili, non siamo in grado di definire la quantità di protezione (dimensionamento del buffer).
•Il buffer assume una funzione di controllo solo se i processi del sistema sono in controllo e l’oscillazione del consumo del buffer è stabile con limite superiore inferiore all’ampiezza massima del buffer.
Dalla protezione al controllo

96. I progetti gestiti con il metodo CCPM evidenziano:
• una riduzione media del lead time del 69%
• una riduzione media del cycle time del 66%
• miglioramento del rispetto delle scadenze del 60%
• riduzione del magazzino del 50%
• aumento del throughput/ritorni del 68%
I risultati del PM CC

97. GRAZIE!
Per informazioni: Dott.ssa Gaia Scapini Ufficio Marketing Pragma Management Systems gaia.scapini@pragmams.it