Project Management: concetti di base

Published on October 19, 2016

Introduzione

Alcuni concetti elementari del Project Management proposti con un modello semplice ma quantitativo utile per un approccio generale alla gestione delle stime di sviluppo.

Il principio di Pareto, la regola del 20 : 80

Il principio di Pareto ci dice che, nel fare un lavoro, il 20% del tempo produce l'80% dei risultati. Si potrebbe quindi supporre che il restante 20% del lavoro richieda l'80% del tempo. Questo sarebbe vero se ogni lavoro avesse un tempo predeterminato per essere svolto, ma non è così.

Possiamo applicare il principio di Pareto in modo ricorsivo

Nelle prime 20 unità di lavoro (ad esempio, giorni lavorativi) si produce l'80% del lavoro. Quindi rimane un 20% di lavoro da fare. Su quest'altra parte applichiamo ancora il principio di Pareto e con altre 20 U.L. otteniamo l'80% del 20% che si va ad aggiungere a quello già effettuato, quindi si arriva al 96%. Per arrivare al 99,8% servono in totale 80 U.L.

Stimare un task (grande è la mia stima per te, prode task)

Se a un ingegnere chiediamo quanto tempo ci vuole per completare un task ed egli/ella ritiene corretta una stima di 80 U.L., ad esempio equivalenti a quattro mesi di calendario, aggiungerà il 20-25% per gli imprevisti e ancora un 20-25% perché sa già che dovrà negoziare al ribasso oppure fare gli straordinari. Perciò ci dirà sei mesi di calendario e poi concorderà per cinque mesi: quindi 100 U.L.

Approccio al lavoro (ben iniziare è già metà dell'opera)

Ci sono due opposti modi di cominciare un lavoro:

top-down: delineare il progetto focalizzandosi sugli elementi principali e quindi le prime 20 U.L. produrranno l'80% del lavoro percepito (ad esempio per un sito web sarebbe disegnare l'interfaccia utente ma senza contenuti e senza business logic);
bottom-up: preparare le parti fondamentali e poi occuparsi di fare l'integrazione. In questo caso le prime 60 U.L. Questo è un lavoro che ha poca visibilità (ad esempio la business logic), le successive 20 U.L. produrranno la percezione dell'80% del lavoro (ad esempio interfaccia utente) e infine le restanti 20 U.L. serviranno per rifinire il progetto (ad esempio adattamento dello stile ai contenuti);

Nella realtà queste due modalità si alternano e generalmente si ripetono per cicli di progettazione e sviluppo in maniera da far convergere entrambi gli approcci.

Per semplicità prendiamo a riferimento la prima modalità perché è quella più incline ad essere immediatamente assimilabile al principio di Pareto.

Avanzamento di progetto (Non progredi est regredi)

Senza svolgere dei test automatici oppure senza un controllo fine della qualità di produzione, effettivamente il lavoro verrà completato in circa 100 U.L. ma quello che a noi interesserebbe sapere è la stima di completamento in termini di deviazioni standard ovvero di copertura effettiva della problematica e/o necessità, usi, casi, etc. [²].

Per il principio di Pareto potremmo dire che per un task, che richieda 100 U.L. e per il quale effettivamente 100 U.L. siano state fatte correttamente, si abbia una copertura della soluzione pari al 99.97% o comunque superiore a i tre sigma che è un risultato ragionevole per un lavoro "finito". Umanamente non percepiamo un reale avanzamento nella parte verde del grafico sopra. In quella parte si vanno a sistemare quei 0.2% di errori e/o corner case che effettivamente avevamo avuto la possibilità di individuare.

Six Sigma (Qualità, qualität für alle menschen)

Se il prodotto o il servizio viene adottato in grandi numeri (milioni di unità o di utenti) allora "finire" il lavoro non basta più ma occorre portarsi a un livello di qualità adeguato che nel caso dell'industria è detto "six sigma" che a prenderlo alla lettera [³] sarebbero sei deviazioni standard ovvero 2 casi insoddisfacenti ogni miliardo di utenze servite o prodotti consegnati.

Perciò un progetto che richieda un mese per essere presentato all'80% di dettaglio richiederebbe circa un anno solare (252 U.L. = 365 gg. di calendario solare) per essere industrializzato, secondo il modello predittivo sopra illustrato.

Fasi di un progetto (shopping list)

In quest'ottica possiamo distinguere quattro stadi principali di un progetto:

architettura di base (1 sigma, 20 U.L., 1 mese)
prototipo e sviluppo (2 sigma, +60 U.L., 4 mesi)
verifica e rifinitura (3 sigma, +20 U.L., 5 mesi)
industrializzazione (6 sigma, +150 U.L., 1 anno)

Gestione di un progetto

Un progetto complesso è generalmente suddiviso in sotto progetti più piccoli, ognuno dei quali è diviso in task. La gestione e l'integrazione dei task e dei progetti non è inclusa nel conteggio sopra e andrebbe considerato come un progetto a se stante almeno grande quanto l'intero progetto: gestione 1 : 1 sviluppo.

Questo [²] significa che serve il doppio delle risorse umane e quasi il doppio del tempo.

Infatti quando parliamo di ricerca e sviluppo (R&D), lavorare in parallelo su diversi task difficilmente è efficace con proporzioni lineari, perché:

i ritardi si accumulano ma non gli anticipi;
al crescere della complessità (dimensionalità), il lavoro cresce più che linearmente.

La complessità va gestita, ma per bene che la si gestisca, non si può mai pretendere che sia priva di impatto. Si possono semplificare le cose complicate (lat.: cum plica = con piega, da spiegare) ma la complessità (lat.: cum plexum = con trama) come la trama di un tessuto non si può sciogliere senza cambiare la natura del problema/soluzione.

Ciclo di sviluppo (in 3 fasi di 2 passi)

Possiamo inizialmente suddividere un progetto in tre fasi di lavorazione ognuna delle composta da due compiti distinti ma complementari:

design e architettura (top-down)
sviluppo e unit test (bottom-up)
integrazione e verifica

Se ci limitassimo a questo avremmo un percorso a due curve piuttosto che una sola curva di percorso. Invece vogliamo dividere il lavoro in due parti ed ognuna delle due parti assoggettarle alla modalità di esecuzione in tre fasi sopra descritta. Allora avremmo un percorso con quattro curve come illustrato in figura [²]:

Potremmo ulteriormente dividere il progetto e avere diversi componenti ognuno dei quali avrebbe due fasi (N=1, 2, 4, ...). La lunghezza del percorso (π/2) è comunque costante a prescindere dal numero di cicli perché, nonostante che al crescere di N il percorso tenda sempre di più ad allinearsi con quello ideale, la tortuosità aumenta.

Qual'è dunque il vantaggio di usare molti cicli di sviluppo (e.g. metodologie Agile, Scrum, etc.) piuttosto che pianificare un'unica complessiva azione (e.g. Water Fall)?

Il vantaggio è che quanto più piccoli sono i cicli di sviluppo, tanto meglio il percorso si allineerà al percorso ideale che non è soltanto quello più breve ma anche quello che conduce alla meta. Altrimenti il rischio è quello di perdere il controllo del progetto.

L'organizzazione (3a dimensione)

L'organizzazione (aziendale, sociale, etc.) è da considerarsi preesistente all'avvio del progetto. Altrimenti il suo sviluppo diventa parte del progetto stesso come la terza dimensione. In questo caso, il calcolo dei tempi segue questa regola:

Non a caso [³] le start-up, le spin-off o più in generale le iniziative imprenditoriali si giudicano a 2 anni (break-even, ritorno dell'investimento) e a 5 anni (consolidamento).

La dimensione di un progetto che parta da zero e che sia gestibile da un numero limitato di persone è quasi una costante. Oppure detto in altro modo: il numero di persone con le quali si può collaborare contemporaneamente è limitato quindi lo è anche la complessità di un progetto che includa lo sviluppo dell'organizzazione da zero. Infatti nel 2007 si è rilevato che il 96% delle start-up non ha più di 5 fondatori e la media dei soci è 2.21 mentre, sempre nello stesso periodo, un'altra statistica indica 2.09.

Parametri di un progetto

Risorse: tempo (in giorni) e persone (in numero)
Sviluppo: percorso (metodo) e organizzazione (struttura)
Risultati: completamento (in percentuale) e qualità (in sigma)

Conclusione

La gestione di un progetto non è altro che l'arte di trasformare efficacemente le risorse assegnate nei risultati previsti attraverso un processo di sviluppo strutturato all'interno di un'organizzazione.

Comic strips

Dilbert: the role of agreement in the task of a task estimation

Dilbert: the role of experience in the task of a task estimation

Articolo seguente

Project Management: teoria del controllo nel quale si andranno a porre alcune basi utili per investigare l'efficienza del controllo di processo. Infatti la qualità del controllo e la qualità del processo, sebbene espresse dalla stessa metrica, sono due fatti distinti.

Riassunto

In questo articolo abbiamo visto:

come applicare in modo ricorsivo il principio di Pareto per ottenere un modello di copertura dei casi in maniera da correlare qualità (sigma) e tempi di progetto;
che per fare 60 unità di lavoro (a 3 sigma) occorrono 100 unità di tempo e che questo rapporto è compatibile con il modello quantitativo: √2 < 1.67 < √3;
che per consegnare a 3 sigma in tempo utile bisogna puntare a 3.6 sigma;
che per fare 60 unità di lavoro (a 6 sigma) occorrano 250 unità di tempo e che questo rapporto (π/2)³ < 4.17 ~ √2·√3·√3 < (√3)³ è compatibile con un modello quantitativo di gestione del progetto a tre parametri: risorse, sviluppo e risultati.

Da questo articolo si può dedurre:

che i parametri di progetto agiscono come dimensioni spaziali ovvero che aumentano i gradi di libertà di gestione ma anche la complessità del progetto;
che in un progetto costituito da N dimensioni, la gestione del progetto rappresenta la dimensione N+1 e con essa possiamo efficientare le altre dimensioni arrivando a un indice di efficienza 1:√3·(√2)ⁿ ma se provassimo ad ottimizzare tutte le dimensioni contemporaneamente otterremmo 1:(π/2)·(π/2)ⁿ che è un risultato peggiore;
che il progetto più semplice (N=1) apparentemente non segue la regola generale sopra descritta e invece risulta ben più efficiente √3 < (√2)² < √2·√3 ma dal modello quantitativo sappiamo che con una gestione perfetta non sarebbe migliore di π/2 e aggiungendo il contributo di gestione avremmo (π/2)² ~ 2.47;
che per il progetto più semplice dotato di una gestione perfetta si avrebbe un'efficienza di (π/2)² ~ √2·√3 che è compatibile con la regola generale sopra;

Gli ultimi 3 punti ci suggeriscono che per un progetto a N+1 dimensioni (N+gestione), le prime N dimensioni non sono completamente indipendenti fra loro e che nel caso più semplice nemmeno la gestione è una dimensione indipendente. Infatti, se investissimo molto tempo per avere una gestione perfetta (indipendenza↔ortogonalità), anche nel caso N=1, il risultato sarebbe coerente con la regola generale e quindi peggiore.

Indice di tutti gli articoli pubblicati

Project Management, Decision Making, Technology Innovation, Leadership & Creativity, Economia, Cultura, Società e Costume, Progetti, Idee e di divulgazione.

Articoli collegati

Project Management: concetti di base (19 ottobre 2016)
Project Management: teoria del controllo (25 ottobre 2016)
Project Management: efficienza del controllo (29 ottobre 2016)
Project Management: gestione dei costi (31 ottobre 2016)
L'opportunità impossibile (PM) (22 marzo 2017)

Note

[¹] Uso delle tabelle dell'integrale della distribuzione normale standardizzata come dalla pagina dell'INFN dell'Università di Roma 1, traduzione di Giulio D'Agostini, anno 2001 del volume "Probabilità e incertezza di misura" scritto da Nikos Drakos, Computer Based Learning Unit, University of Leeds (1993-96) e da Ross Moore, Mathematics Department, Macquarie University, Sydney (1997-99).

[²] La lunghezza della curva (percorso reale, in rosso) è stata calcolata con un approssimazione lineare, come media (1.71) fra il valore di 2 e radice quadrata di 2, arrotondando (1.73) per comodità alla radice quadrata di 3. Come minorante della stima si potrebbe indicare il quarto di cerchio (π/2 = 1.57) e come secondo maggiorante la radice quadrata di pigreco (√π = 1.77). Il rapporto fra il percorso ideale (√2) e quello reale (√3) è poi stato usato nel calcolo successivo (cfr. sezione "L'organizzazione").

[³] Si tenga presente che lo standard di certezza usato del CERN per affermare l'esistenza del bosono di Higgs è stato di 5σ quindi appare improbabile che una produzione industriale possa raggiungere un tale grado di qualità. Infatti il metodo "six sigma" prevede di lavorare intorno ai 4.5σ ovvero a 3 parti per milione (99.9997%).