L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)
-
Upload
pragma-management-systems-srl -
Category
Technology
-
view
72 -
download
1
description
Transcript of L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)
1
Oltre ogni aspettativa di successo – la TOC
2
Oltre ogni aspettativa di successo – la TOC
La Teoria Agile Project Management
Ing. Claudio Vettor & Ing. Michela Rea
3
Oltre ogni aspettativa di successo – la TOC
COME E PERCHE’
IMPRESA AGILE
4
Oltre ogni aspettativa di successo – la TOC
AGENDA DELLA GIORNATA
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
I processi possono insegnare qualcosa ai progetti?
AGILE O FRAGILE?
7
Oltre ogni aspettativa di successo – la TOC
Dal processo al progetto:
una storia sistemica
• È 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
Dal processo al progetto: dal flow chart al Gantt
Dal processo al progetto
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
Lista processi
Mappatura del singolo processo
Foglio risorse
Indicatori
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
Organizzazione e BPM
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
Dal processo al progetto: il continuum
• 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?
• 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
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»
• 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
• 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
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?
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?
Perché i progetti falliscono?
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
• 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
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
• 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
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
• 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
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
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à
Sviluppo nuovo prodotto, modello
organizzativo e framework «Agile»:
un’introduzione
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
• Queste fasi hanno validità quasi universale
Stage gate
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»
Le forme organizzative
Differenze, vantaggi e svantaggi
• 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
• 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
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
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?
Cercate produttività? Agile non fa
per voi!
Agile è per:
• apportare facilmente
cambiamenti
• creare velocemente valore
• aumentare la trasparenza
Agile quando?
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
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
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
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à»
The Agile Manifesto
• 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
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à
Subito qualcosa di funzionante/stabile: test driven development cycle
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»
Iterazione e visione di insieme
• No al micro- management, team che si auto-organizzano
• Logica della “staffetta”
• Utilizzo funzionale del tempo delle persone coinvolte
Una diversa cultura dell’HR
• 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
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
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
I principi generali della Lean nel PM
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
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
• 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
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
• 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
Misura del commitment
• raggiungimento degli obiettivi
• team building e grande apprendimento
• motivazione e entusiasmo (you guys made a believer out of me!)
Vantaggi
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
• 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
• 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
La direzione della soluzione - TOC
Che strada seguire?
• 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
€
• 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
€
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
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
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
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
• 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
Catena critica e tempo
Soluzione delle contese (level load )
Percorso critico
_ste deve contemporaneamente
svolgere 2 lavori
_alex deve contemporaneamente
svolgere 2 lavori
Il cammino critico
La catena critica
Solo dopo lo step «level load» può essere definita la Catena Critica
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
Ha quasi sempre un
costo
Schedule Crashing
Richiede elevata
sincronizzazione e
grande capacità di
scomporre
logicamente le attività
Schedule fast tracking
Ipotizzabile in contesti molto stabili con progetti ripetitivi,
tendenzialmente ambienti multi- project
Schedule resource leveling
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
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 sufficientementebre
ve
- 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à
•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
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
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
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
•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
• 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à
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
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
GRAZIE!
Per informazioni:
Dott.ssa Gaia Scapini
Ufficio Marketing
Pragma Management Systems