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

gaia.scapini@pragmams.it