Diagramma di Ishikawa
Il diagramma di Ishikawa è una tecnica manageriale utilizzata nel settore industriale e nei servizi per individuare la/le causa/e più probabile/i di un effetto (problema). Sono anche chiamati diagrammi causa-effetto o a lisca di pesce.Questo tipo di diagrammi causa-effetto vennero messi a punto in Giappone nel 1943 da Kaoru Ishikawa, guru della qualità totale. Sostanzialmente si tratta di una rappresentazione grafica di tutte le possibili cause relative ad un problema. La rappresentazione grafica assume la forma di una lisca di pesce.
Brainstorming
Nel corso di una o più sessioni di brainstorming si esaminano i problemi e le loro possibili cause. Entrambe si rappresentano in uno o più diagrammi in quattro macrogruppi: Macchine, Manodopera, Metodi, Materiali. Ogni causa può essere a sua volta effetto di altre cause. Ad esempio:
- il guasto delle macchine può essere effetto di una carente progettazione
- la manodopera poco efficiente può essere effetto di una cattiva gestione delle risorse umane
- i metodi non sufficientemente qualificati possono essere effetto di una carente qualità della progettazione, delle specifiche o della Norma tecnica di riferimento.
- i materiali possono essere effetto di carenti controlli della qualità, difetti, o lotti di materiali non conformi.
Analisi statistica
- 1 Dopo il brain storming, si costruiscono uno o più diagrammi causa-effetto dove vengono elencate tutte le possibili cause a fronte di ogni problema e raggruppate nei quattro macrogruppi sopraelencati;
- 2. Utilizzando il principio di Pareto si procede alla analisi delle cause e alla scelta della/e causa/e più frequente/probabile;
- 3. Le prime due o tre cause sono quelle che hanno la maggiore influenza sui vari problemi.
PERT/CPM
Da Wikipedia, l'enciclopedia libera.PERT/CPM è un sistema di metodologie di gestione progetti, derivante dalla fusione delle tecniche PERT e CPM.
Già alla loro nascita (seconda metà anni cinquanta) queste erano molto simili; oggi sono considerate ed utilizzate come unico sistema.
PERT
PERT, acronimo dalla lingua inglese che sta per Program Evaluation and Review Technique.
È una tecnica (formalismo grafico) di project management sviluppata nel 1958 dalla Booz, Allen & Hamilton, Inc. (una ditta di consulenza ingegneristica), per l'ufficio Progetti Speciali della Marina degli Stati Uniti. L’obiettivo era quello di ridurre i tempi ed i costi per la progettazione e la costruzione dei sottomarini nucleari armati con i missili Polaris, coordinando nel contempo diverse migliaia di fornitori e di subappaltatori.
Con questa tecnica si tengono sotto controllo le attività di un progetto utilizzando una rappresentazione reticolare che tiene conto della interdipendenza tra tutte le attività necessarie al completamento del progetto.
Si noti che l'algoritmo PERT non schedula (cioè non elabora una sequenza temporizzata delle attività stesse), perché non tiene conto della disponibilità delle risorse; considera cioè che le risorse siano a disponibilità infinita.
Varianti del PERT:
- L'algoritmo PERT-Tempi Semplice calcola i tempi minimi e massimi per la realizzazione di ogni attività.
- L'algoritmo Full PERT-Tempi è lo stesso del PERT Semplice, ma considera la durata delle attività in forma probabilistica.
- PERT Costi e CPM consentono di effettuare analisi considerando anche i costi associati alle attività.
CPM è l'acronimo di Critical Path Method, ovvero "metodo del percorso critico".
È uno strumento di gestione progetti sviluppato nel 1957 dalla Catalytic Construction Company per la manutenzione degli impianti della Du Pont de Nemours.
Si tratta di una tecnica usata per individuare, nell'ambito di un diagramma a rete (del tipo PERT), la sequenza di attività più critica (massima durata) ai fini della realizzazione di un progetto. Individuato il percorso critico si tengono sotto stretto controllo le attività che lo compongono, in quanto un ritardo (maggiore durata del previsto) di una qualsiasi di queste comporta inevitabilmente un ritardo dell'intero progetto.
È una tecnica molto nota e utilizzata nelle imprese di costruzione (strade, ponti, gallerie, grandi infrastrutture, ecc.).
PERT/CPM a supporto della gestione dei progetti
La rappresentazione del progetto
Un progetto consiste, essenzialmente, di una serie di attività interdipendenti che devono essere eseguite con una precisa sequenza.
Con la tecnica PERT/CPM si rappresenta il flusso logico delle attività mediante un reticolo. Il tipo di reticolo più adottato è quello cosiddetto "ad arco" ed formato da:
- frecce, che rappresentano le attività
- nodi, punti di inizio/fine delle attività, che rappresentano eventi nel tempo
Questo tipo di reticolo è molto adatto ad essere trattato con soluzioni informatiche. I nodi possono essere identificati con un numero e le attività con la coppia dei numeri corrispondenti ai nodi di inizio e fine. Naturalmente a queste informazioni vengono collegate le descrizioni e, nel caso delle attività, anche le durate.
I percorsi sono identificati mediante la lista dei nodi attraversati ed assumono, come durata (minima - intermedie - massima) la somma dei tempi delle attività comprese nel percorso.
Le fasi tipiche di gestione PERT/CPM
- Pianificazione e costruzione del modello (reticolo) di dettaglio. Ciascun responsabile esecutivo elenca le attività necessarie; l'insieme delle attività viene legato e messo in sequenza secondo la logica de "l'attività può iniziare solo se ....
- Stime dei tempi e analisi dei percorsi. Ad ogni attività viene attribuita una stima della durata prevista. In passato si tendeva a fornire più di un valore, del tipo probabile, pessimistica, ottimistica. Negli anni ci si è resi conto che tale consuetudine di fatto non migliorava l'attendibilità complessiva del PERT/CPM, ma allungava solo i tempi di discussione e la complessità dei calcoli. Con l'analisi dei percorsi si entra nella fase più importante, quella in cui si calcola la durata (stimata) del progetto e si identificano i percorsi critici (tempi più lunghi). L'importanza non è data dal calcolo in se stesso, ma dal fatto che sulla base dei risultati inizia il lavoro di ottimizzazione dell'intero progetto. Vengono rianalizzate le singole attività, cercate nuove soluzioni tecniche, ecc. È la prima fase di ottimizzazione; Ne derivano, di conseguenza, continue revisioni e riedizioni del modello nel suo complesso.
- Programmazione operativa. Sulla base dei risultati ottenuti dall'analisi dei percorsi inizia il lavoro di definizione di risorse da impiegare. Vengono analizzati impegni di manodopera, carico degli impianti, ecc. È la seconda fase di ottimizzazione, a volte risolta in termini di compromesso tra spendere di più e finire prima. Anche in questo caso ne derivano revisioni e riedizioni del modello in generale.
- Controllo delle operazioni sul progetto in corso d'opera. Il progetto parte ed è necessario controllare che lo svolgersi delle attività sia quello previsto, in sequenza, tempi e risorse impiegate. Variazioni in corso d'opera (anticipi, ritardi, ecc.) vengono gestiti anche rivedendo (da un dato momento in avanti), il modello PERT/CPM.
In conclusione va sottolineato che la gestione PERT/CPM, ovviamente completamente supportata da sistemi software dedicati, ha un costo non insignificante e impone una impostazione organizzativa che spesso non sono alla portata delle piccole aziende.
Nozioni di base sulle tecniche reticolari
Il PERT, assieme alle tecniche che sono state sviluppate successivamente per l'analisi del percorso critico, per l'evidenza dei costi e per il trattamento delle risorse, formano la tecnica della "programmazione reticolare", della quale si riassumono di seguito gli elementi fondamentali.
I componenti
I componenti principali di un reticolo sono le attività, i vincoli, le date prefissate ed il calendario.
Le attività rappresentano i lavori da svolgere per il compimento del progetto. L'attributo principale dell'attività, oltre la descrizione, è la durata prevista. Alcune attività particolari, che rappresentano importanti traguardi intermedi nell'ambito del progetto, vengono denominate Milestone.
I vincoli (o legami) rappresentano le relazioni tra le attività. Il vincolo più utilizzato è quello Fine-Inizio, che significa che l'attività seguente non può iniziare se quella precedente non è finita. Con lo stesso concetto esistono i vincoli Fine-Fine, Inizio-Inizio, Inizio-Fine. I vincoli, oltre che all'inizio o alla fine di una attività, possono attestarsi anche ad una percentuale di completamento della stessa. Ai vincoli può essere assegnata anche una durata, nel caso in cui tra una attività e l'altra debba intercorrere un certo tempo che però non si vuole rappresentare tramite una attività.
Agli eventi di inizio e fine attività possono venire assegnate dalle date prefissate, del tipo data-fissa, non-prima-di, non-dopo-di, in modo da influenzare il calcolo, ove si conoscano a priori restrizioni di questo tipo.
Bisogna fornire inoltre la specificazione del calendario da utilizzare, cioè quali sono i giorni lavorativi, le festività infrasettimanali ed i periodi di non lavoro, per permettere al sistema di calcolo di riportare sul calendario effettivo i risultati ottenuti.
La rappresentazione della rete (o reticolo)
Ci sono due tipi di rappresentazione.
Nel primo tipo le attività sono rappresentate da frecce, e gli eventi di inizio e fine attività rappresentano i nodi della rete. È la rappresentazione iniziale del Pert, che ha effettivamente l'aspetto di un reticolo, ma è difficoltosa da utilizzare in quanto costringe ad impiegare numerose attività fittizie per riuscire ad esprimere tutti i collegamenti tra le attività.
Nel secondo tipo le attività sono rappresentate da rettangoli ed i vincoli tra le attività sono rappresentati da frecce. È il sistema più comodo, detto "a precedenze", che permette di raffigurare tutti i tipi di vincolo senza dover ricorrere ad artifizi.
Il calcolo della tempificazione
Semplificando, si eseguono due passate di calcolo.
La prima in avanti, partendo dall'inizio del progetto. In questa fase si determinano le date al-più-presto dell'inizio e della fine delle varie attività, e la data di fine progetto (se non è stata prefissata).
Una seconda passata all'indietro, partendo dalla fine del progetto. In questa fase si determinano le date al-più-tardi dell'inizio e fine delle attività.
Dalla differenza tra le date al-più-tardi e quelle al-più-presto si ricava lo slittamento ammesso, che è di due tipi: lo slittamento libero, cioè il lasso di tempo addizionale di cui può disporre una singola attività senza incidere sulle altre attività, e lo slittamento totale, cioè quello di cui può disporre l'intera catena di cui l'attività fa parte, senza andare ad influenzare la data di fine progetto. Se non è stata prefissata la data di fine progetto, la attività che si trovano sul percorso critico hanno slittamento pari a zero.
A valle della tempificazione, viene identificato il cammino critico, composto da quelle attività per le quali un ritardo/anticipo non può essere compensato con le attività successive e, quindi, comporta una variazione certa della data finale dell'intero progetto.
Tecniche di analisi reticolare permettono di ottimizzare la tempificazione, parallelizzando alcune attività, nel rispetto dei vincoli di precedenza indicati costruendo il reticolo. Eulero elaborò una serie di proprietà e regole utili per l'analisi reticolare.
Le risorse
Ad ogni attività possono essere associati anche il tipo, la quantità ed il profilo di utilizzo delle risorse necessarie ad eseguirla.
Sommando le risorse necessarie in base alle date al più presto (o al più tardi) si ottengono degli istogrammi di carico che rappresentano la semplice aggregazione delle risorse, cioè una programmazione a capacità infinita, cioè senza porre dei limiti alle quantità di risorse disponibili nel tempo.
Se invece si fornisce un profilo di capacità, cioè di risorse disponibili nel tempo, si può tentare una allocazione delle risorse, cioè una programmazione a capacità finita. Il processo di allocazione tenta di eliminare i sovraccarichi di risorse spostando le attività sfruttando il loro slittamento disponibile.
L'aggiornamento in corso d'opera
Si fa indicando quando sono iniziate le attività, quando sono finite, e la percentuale di avanzamento (o la durata restante) per quelle iniziate e non finite. Spesso bisogna rivedere anche i vincoli per adeguare il modello alla effettiva realizzazione.
L'esposizione dei risultati
I risultati del calcolo possono essere forniti in forma tabellare, di diagramma di Gantt, di rappresentazione del reticolo tempificato, di istogrammi e di altri tipi di grafico.
L'evoluzione
Nei decenni successivi alla ideazione delle tecniche reticolari, si è assistito ad una progressiva sofisticazione degli algoritmi di calcolo, dei tipi di vincoli, e delle funzionalità connesse.
Con l'avvento delle interfacce grafiche, si tende invece a semplificare di molto gli algoritmi di calcolo e ad aumentare invece l'interazione con l'uomo per addivenire ad un programma più soddisfacente.
Work Breakdown Structure
Con l'espressione inglese Work Breakdown Structure (WBS, Struttura Analitica di Progetto) si intende l'elenco di tutte le attività di un progetto. Le WBS sono usate nella pratica del Project management e coadiuvano il project manager nell'organizzazione delle attività di cui è responsabile.Molto spesso i progetti sono composti da migliaia di attività: per facilitare il lavoro di organizzazione delle varie attività esistono delle WBS-tipo che elencano tutte le possibili attività (generiche) per i progetti del rispettivo ambito. L'insieme delle attività può quindi essere confrontata con una check-list.
La Work Breakdown Structure è un albero gerarchico orientato al prodotto (o deliverable) che viene suddiviso nel materiale, nel software, nei servizi, nei dati e nelle attrezzature che lo compongono. L'albero viene strutturato in base all'ingegneria di sistema che è sviluppata nella fase iniziale dell'apertura del progetto. La WBS definisce il prodotto, o i prodotti, da sviluppare o da produrre. Essa mette in relazione con il prodotto finale e fra di loro gli elementi di lavoro che sono necessari alla sua realizzazione. La WBS può articolarsi in un numero qualsiasi di livelli.
Principi alla base della WBS
Regola del 100%
Uno dei più importanti principi alla base della WBS è noto come Regola del 100%. La Practice Standard for Work Breakdown Structures (Second Edition), edita dal Project Management Institute (PMI - http://www.pmi.org) definisce questa regola così:
- La regola del 100%... precisa che la WBS debba includere il 100% del lavoro definito dal progetto e includere TUTTO il necessario - interno, esterno e appaltato - alla realizzazione del progetto, inclusa la gestione del progetto stesso. La regola del 100% è una delle più importanti linee guida per lo sviluppo, la decomposizione e la valutazione della WBS. La regola si applica a tutti i livelli della gerarchia: la somma del lavoro dei livelli "figli" deve essere uguale al 100% del lavoro rappresentato dal loro "padre" e la WBS non dovrebbe includere alcun lavoro al di fuori dai limiti del progetto, ovvero non può includere più del 100% del lavoro. È importante ricordare che la regola del 100% si applica anche al livello di attività, Il lavoro rappresentato dalle attività in ciascun pacchetto di lavoro deve dare, sommato, il 100% del lavoro necessario per completare il pacchetto." (p. 8)
Se il progettista della WBS tenta di comprendervi ogni dettaglio relativo alle azioni, probabilmente includerà troppe azioni, o troppo poche. Troppe azioni eccederanno il 100% dei limiti del nodo superiore, mentre troppo poche non arriveranno a quella percentuale. Il modo migliore di seguire la regola del 100% è di definire gli elementi della WBS in termini di risultati. Questo assicura che la WBS non dia raccomandazioni eccessive riguardo ai metodi, dando più spazio al pensiero creativo dei partecipanti al progetto. Per i nuovi progetti di sviluppo, la tecnica più comune per assicurare una WBS rivolta ai risultati è di utilizzare una product breakdown structure. Eventualmente la WBS può risultare dal confronto di PBS e ABS, dove ABS è un Activity Breakdown Structure. Progetti software feature driven possono utilizzare una tecnica simile, che impiega una feature breakdown structure. Quando un progetto fornisce servizi professionali, una tecnica di uso comune è di comprendere tutti i prodotti rilasciabili per creare una WBS orientata al prodotto. Le WBS che suddividono il lavoro in fasi di progetto (per esempio, fase di progetto preliminare, fase di progetto esecutivo) devono assicurare che le fasi siano chiaramente separate da qualcosa che definisca anche i criteri di delimitazione delle fasi stesse (per esempio, l'approvazione del progetto preliminare o del progetto esecutivo) che comunemente vengono denominati milestone.
Elementi reciprocamente esclusivi
In aggiunta alla regola del 100%, è importante che non ci siano sovrapposizioni nella definizione dei limiti tra due elementi della WBS. Tale ambiguità potrebbe infatti portare a raddoppiamenti di lavoro e fraintendimenti circa responsabilità e autorità. Allo stesso modo, la sovrapposizione causerebbe probabilmente confusione riguardo alla gestione delle spese di progetto. Se i nomi degli elementi sono ambigui, un dizionario interno alla WBS torna utile per chiarire le distinzioni tra di essi. Il dizionario descrive ogni componente con milestone, prodotti, attività, limiti e talvolta date, risorse, costi, qualità, ecc.
Livello di dettaglio (granularità) ed elaborazione progressiva
Un quesito fondamentale da porsi durante la progettazione di ogni WBS è quando smettere di dividere il lavoro in elementi più piccoli. Se gli elementi terminali sono troppo ampi, infatti, potrebbe risultare impossibile tenere traccia in modo efficiente delle prestazioni progettuali, se al contrario gli elementi sono troppo piccoli e quindi troppo numerosi, diventerà difficile tenerne traccia, specialmente se il lavoro è pianificato in un futuro piuttosto distante. Un compromesso soddisfacente può essere trovato facendo ricorso alla tecnica dell'elaborazione progressiva, che permette ai dettagli della WBS di essere progressivamente ridefiniti prima che il lavoro inizi su ogni singolo elemento. Una forma di elaborazione progressiva, nei grossi progetti, è nota come rolling wave planning (pianificazione ad aggiornamento costante) che stabilisce una pianificazione su una base temporale regolare per l'elaborazione progressiva. Nella pratica, un limite effettivo della granularità della WBS può considerarsi raggiunto quando non è più possibile definire risultati di progetto pianificati, e i soli dettagli rimanenti sono azioni; a meno che queste azioni non possano essere ridefinite per conformarsi alla "regola del 100%", la WBS non dovrebbe essere ulteriormente suddivisa.
Schema di codifica
È di uso piuttosto comune numerare gli elementi della WBS in ordine sequenziale per metterne in risalto la struttura gerarchica. Per esempio,
1.3.2 Ruota Posteriore identifica l'oggetto come elemento di livello 3, poiché ci sono tre numeri separati da un punto decimale. Inoltre, lo schema di codifica aiuta a riconoscere gli elementi del WBS in ogni contesto scritto.Esempio di costruzione di una WBS
Talvolta, lo schema di codifica WBS include un carattere di sottolineatura ("_") al termine del nome per identificare gli elementi terminali. Si tratta di un sistema utile poiché le attività pianificate ("installare la camera d'aria e lo pneumatico", per esempio) saranno assegnate agli elementi terminali invece che ai nodi superiori.
Incidentalmente, questo metodo quantitativo è collegato alla tecnica Earned Value Management.
È raccomandabile che il progetto sia iniziato con un software interattivo, per esempio un foglio elettronico, in grado di sommare automaticamente i punteggi assegnati. Un'altra pratica raccomandata è discutere la stima dei punteggi con gli altri membri del project team, questa tecnica collaborativa aumenta la conoscenza della definizione dei limiti degli elementi e dei presupposti, e per una buona gestione del progetto il consenso circa il livello di granularità è necessario.
Errori e malintesi comuni
Una WBS non è una lista completa di lavori, bensì una classificazione degli scopi del progetto.
Una WBS non è una pianificazione del progetto e non è una lista in ordine cronologico. È sconsigliabile e considerato controproducente pianificare un progetto (per esempio usando un project management software) prima di progettare una WBS appropriata, sarebbe simile al voler pianificare le attività di un cantiere edile prima ancora di completare il progetto dell'edificio. Senza concentrarsi sui risultati del progetto, è molto difficile seguire la regola del 100% a ogni livello della gerarchia della WBS. Non è possibile recuperare una WBS con definizioni improprie senza rifarla dal principio, per cui vale sempre la pena di completarla prima di iniziare qualunque altra pianificazione.
Una WBS non è una gerarchia organizzativa. Talvolta, i principianti commettono l'errore di creare una WBS fedele alla struttura organizzativa, mentre è piuttosto comune che la responsabilità sia assegnata a elementi organizzativi, una WBS che ne rispecchi la struttura non è descrittiva del progetto e non è orientata ai risultati. Allo scopo, si veda anche: matrice di assegnazione responsabilità.
La capacità della memoria a breve termine non dovrebbe influenzare la dimensione della struttura ad albero di una WBS. Alcune fonti di documentazione suggeriscono che ogni livello sia limitato a 5/9 elementi perché questo è il limite teorico della memoria umana. Tuttavia, è da ritenersi che questo consiglio sia un'applicazione errata delle teorie sui principi cognitivi (si veda: The Magical Number Seven, Plus or Minus Two), poiché gli elementi di una WBS non sono dati interconnessi casualmente. La documentazione definitiva riguardo alle WBS non contengono questa raccomandazione. È molto più importante costruire un raggruppamento logico di risultati pianificati che preoccuparsi dei limiti della memoria umana a breve termine.
In questo senso può essere utile realizzare una mappa mentale prima della WBS: essendo uno strumento di creatività aiuta a sviscerare alcuni aspetti che potrebbero rimanere reconditi con un approccio esclusivamente logico-razionale. La realizzazione potrebbe essere affidata al singolo come al gruppo di lavoro; in ogni caso è importante tenere a mente il principio secondo cui "la mappa non è il territorio", per cui... la mappa mentale potrà descrivere in modo molto parziale l'articolazione del discorso e avrà invece soprattutto lo scopo di focalizzare l'attenzione sulla preparazione delle attività. Si noti che, benché la WBS abbia uno scopo più denotativo, anche per essa vale il principio del dualismo mappa-territorio.
Al di là della progressiva elaborazione dei dettagli, gli aggiornamenti della WBS richiede un controllo formale dei cambiamenti. Questo è un altro motivo per cui una WBS dovrebbe essere orientata alla produzione di risultati (deliverable oriented) e non alle prescrizioni di metodi: i metodi possono cambiare rapidamente, e lo fanno, ma le modifiche nei risultati pianificati richiedono un maggiore grado di formalità. Se i risultati e le azioni si confondono a vicenda, il controllo dei cambiamenti può essere troppo rigido per le azioni e troppo informale per i risultati.