Project Management: teoria del controllo

Published on October 25, 2016

Introduzione

Il giusto approccio, un modello quantitativo e un metodo elastico possono aiutare l'arte del Project Management a evitare percorsi inutilmente contorti.

La teoria del controllo della gestione dei progetti, qui presentata, si basa sulla teoria della misura e degli errori e su un modello quantitativo descritto nell'articolo "Project Management: concetti di base" che a sua volta si basa su concetti statistici più generali.

Riassunto del modello quantitativo

Nel precedente 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) occorrano 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) occorrono 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;

Inoltre avevamo dedotto che:

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.

Misura del controllo

Potremmo affermare che il rapporto fra il punto di massima distanza dal percorso ideale (curvatura) e la lunghezza del percorso ideale (minima) del progetto ci fornisce un numero (ε, errore), il cui reciproco (1/ε) dovrebbe essere proporzionale all'indice di controllo del processo.

La misura corretta dell'indice di controllo è proporzionale all'integrale ∑ = ∫ |ε(x)| dx calcolato per in [0, √2] ovvero la superficie compresa fra il percorso fatto e quello ideale. Inoltre il rapporto (divisione) si fa fra unità coerenti quindi l'area di riferimento sarà il quadrato costruito sul percorso ideale (√2) come lato.

Si noti che se questa misura (∑, errore) fosse nulla avremmo un controllo infinito quindi anche questo indicatore ci suggerisce che il percorso (√2) ideale non è accessibile.

Con un po' di arrangiamenti algebrici arriviamo a questa formula per Ic dove <|ε|> è l'errore in valore assoluto medio sulla distanza √2 e quindi:

1/Ic = ∑ / (√2)² = (<|ε|> · √2) ÷ 2 perciò Ic ~ 1 / <|ε|>

e per ε << 1 si può approssimare <|ε|> con √<ε²> che è il reciproco della varianza

Ic ~ 1 / √<ε²> ~ 1 / σ ↔ Ici(σ) ~ σ attenzione!!! (vedere più sotto, please)

Questo lo chiamiamo indice di controllo istantaneo perché, sebbene l'andamento sia lo stesso [¹] vogliamo differenziare fra il controllo del progetto (management) che mira a raggiungere determinati risultati e il controllo del singolo evento (micro management).

Il costo del controllo

Nel precedente articolo abbiamo visto l'andamento della qualità del progetto in funzione del tempo di sviluppo S = σ(t) ma lo stesso andamento può essere presentato in termini di funzione inversa $ ~ T(σ) per rappresentare il costo del controllo: ogni azione di controllo ci costa in funzione $ = $(σ) di quanto preciso risulti essere il controllo.

Ad esempio, un'azione di controllo con una precisione di 1σ costa $16, di 2σ costa $39, di 3σ costa $74 e di 4σ costa $120 e per completare una in Pareto di 1.3σ costa $20.

Dov'è che rischiamo di fare confusione?

Nella modalità in cui interpretiamo la qualità σ e la distribuzione degli errori σ²:

in un caso σ = σ(t) ~ √t, essa esprima la quantità di casi inclusi nella soluzione;
in un altro caso σ²(ε) ~ <ε²> essa esprime una misura dell'errore.

Data la distribuzione degli errori P = p(σ²) e decisa la tolleranza T = t(σ) abbiamo che la copertura è una percentuale che viene espressa in termini di σ della distribuzione data e indica quanti casi sono inclusi nella tolleranza. Più sarà concentrata la distribuzione degli errori σ² (piccolo) e maggiore saranno i casi inclusi σ (grande).

Se consideriamo le funzioni inverse di queste due, otteniamo:

$ ~ T ~ (σ(t))²: il tempo è denaro ma il denaro non sempre può comprare il tempo;
l'εrrore in % = ±½·(1 - Pc(σ)): la parte dei casi non coperta dalla nostra qualità in σ.

In questo senso è corretto dire che σ(t) ~ 1/√<ε²> perché con il tempo riduciamo gli errori e quindi aumentiamo il numero di casi inclusi nella nostra tolleranza (qualità).

L'indice di controllo istantaneo Ici(σ) ~ σ che abbiamo visto sopra ci dice quanto siamo efficienti nel condizionare la distribuzione degli errori al fine di farla convergere al nostro risultato obbiettivo quindi esso è proporzionale ai benefici del controllo.

Chiariti i concetti fondamentali e le loro sfumature possiamo approcciare il problema in un modo diverso che sia più affine allo scopo di questo articolo.

Convenienza del controllo

La domanda è: ci conviene fare controllo o un controllo fine sul progetto?

Lo scopo è quello di determinare quale sia il controllo (unità di misura in σ) ottimale che dobbiamo esercitare sullo sviluppo di un progetto per raggiungere la qualità (u.d.m. in σ) obbiettivo nel minor tempo possibile cioè in modo efficiente. Dobbiamo perciò avere chiara la differenza fra ciò che è l'obbiettivo e quello che il mezzo sebbene entrambi siano misurati con metriche che hanno la stessa natura.

L'idea non ovvia è che controllo e qualità non siano sempre necessariamente correlati dal semplice rapporto 1:1 perché ridurre al minimo gli scarti (o errori di sviluppo) non significa necessariamente ridurre al minino il costo del processo nella sua totalità (bilancio fra valore del controllo e costo del controllo).

Se ho un costo mi aspetto che esso generi un valore. Quanto valore aggiunge passare da un controllo 1σ ad uno più fine 1σ+dσ oppure quanto valore perdo a ridurre il controllo da 1σ a 1σ-dσ in proporzione alla variazione di costo ±d$? Se facessimo la derivata di quella funzione otterremmo una bella retta che ci farebbe pensare che più controllo genera più valore. Falso! Non tutti i benefici sono maggiori dei costi.

Esempio pratico

Si potrebbe supporre che per avere un progetto in 4σ devo applicare azioni di controllo a 4σ. Falso! E' necessario almeno un'azione di controllo a 4σ ma non necessariamente tutte a 4σ. Infatti se volessimo arrivare a Milano all'indirizzo Y partendo da Genova, la precisione di arrivo sarebbe di 10 metri su 150 Km ovvero 4σ ma possiamo percorre l'A7 attraverso i Giovi oppure prendere la variante di Voltri e la distanza massima fra i due percorsi è di circa 20Km su 150Km ovvero un 1σ. L'importante è che quando guidiamo rimaniamo all'interno di ±1 corsia. Se viaggiamo alla velocità di 100Km/h (quindi 28m/s) una corsia è ampia 2.8m abbiamo bisogno di mantenere la precisione della traiettoria a 2σ, in media. Ciò non significa che non si abbia bisogno di manovre di precisione a 3σ ma in generale non servono e servono significa che stiamo guidando in modo imprudente e anche molto costoso (2.5 volte più costoso). Se guidiamo sempre con la massima attenzione siamo al sicuro e questo vale il costo. Sbagliato: un'attenzione eccessiva stanca e la stanchezza porta a fare errori oppure al colpo di sonno.

Figura 1: due modi diversi di procedere

Difetto ed eccesso di controllo

U.T.: unità di tempo e U.L.: unità di lavoro, U.C.: unità di controllo, $: unità di budget

Se lavoriamo in Pareto (1.3σ) per 4 U.T. potremmo generare 1 U.L. a 3σ (99.84%) sulla nostra linea di sviluppo ma questa potrebbe aver deviato dalla rotta di progetto e su quella saremmo all'80% quindi la nostra U.L. è a 1.3σ sulla linea di progetto: abbiamo speso $80 per una cosa che ne potrebbe valere solo $20. Pessimo!

Questo è un esempio di come applicare un metodo in modo sbagliato porti rogna!

Se invece lavoriamo a 3σ (99,8%) per 2 U.T. per generare 2 U.L. a 3σ, potremmo aver deviato ed essere a 2σ sulla linea di progetto. Quindi avremmo speso $148 per qualcosa che ne potrebbe valere solo $74. Insufficiente. Se aggiungiamo 1 U.T. per fare una 1 U.C. a 3σ allora abbiamo speso $222 per qualcosa che ne vale $148. Buono, Re ~ 67%.

Quest'ultimo progetto avrebbe dovuto finire a con un rendimento di (π/2)² = 2.47 ed infatti si è concluso con un rendimento non superiore a √2 / 0.67 = 2.11 perché la linea di progetto ideale sulla quale andiamo a proiettare i risultati è quella diagonale di √2.

Il ciclo di controllo è di ordine n-1 mentre quelli di sviluppo sono di ordine n, dove per n intendiamo il numero di task/step in cui abbiamo suddiviso l'intero progetto/percorso.

Controllo rilassato (ottimale)

Oppure potremmo lavorare in 1.3σ per 4 U.T. per generare 2 U.L. a 2σ (96%) e usare 1 U.T. per fare 1 U.C. a 1.3σ e portarci sulla linea di progetto con 2 U.L. a 2σ. Così avremmo speso $100 per una cosa che ne vale 2 x $39 = $78. Ottimo,Re ~ 78%.

Poi potremmo lavorare in 2σ per 4 U.T. per generare altre 2 U.L. a 3σ e usare 1 U.T. per fare 1 U.C. a 2σ e portarci sulla linea di progetto con 4 U.L. a 3σ. Così avremmo speso $100+$195 = $295 per una cosa che ne vale 4 x $76 = $304. Impossibile!?, Re ~ 103%

Poiché vogliamo la garanzia a 3σ dobbiamo sostituire l'ultimo controllo da 2σ a 3σ, il costo totale sarà di $330 per una cosa che ne vale $304. Eccellente! Re ~ 92%

Questo progetto avrebbe dovuto terminare con rendimento π/2 = 1.58 ed infatti è terminato con un rendimento non superiore a √2 / 0.92 =1.54.

Perché non provare ancora con 1000 U.L.? Il risultato sarà ancora più efficiente. Falso! Questo è il modello di sviluppo Water Fall e sappiamo che non funziona bene. Perché?Possiamo correggere piccoli errori facilmente ma non è sempre possibile correggere grandi errori nemmeno con grandi risorse: il denaro non sempre può comprare il tempo.

Se lavoriamo in 1.3σ la nostra distanza dal percorso ideale sarà del ±10% e se abbiamo percorso un tratto breve allora possiamo usare 1 U.C. a 1.3σ per ridurre lo scarto a ±2% quindi arrivare alla confidenza di 2σ (96%). Teniamo presente che è abbastanza improbabile che in un processo di sviluppo condotto da persone qualificate gli errori si accumulino tutti in una stessa direzione +20% oppure -20%. Però anche queste ipotesi contano nel teorico del valore prodotto (cfr. Impossibile!?).

Prima della verifica a 3σ il valore di $304 non era certo a 3σ maera certo a 2σ quindi il bilancio diventa: $304 · 0.96% = $292 < $295. Re ~ 99%. Ci stiamo prendendo in giro?

Confidenza di un affermazione

Ogni affermazione (misura) ha una sua confidenza (σ). Perciò possiamo dire che:

abbiamo un prodotto in 2σ con confidenza 3σ che significa che il prodotto ha una percentuale di soddisfazione del 96% e questa affermazione è confermata al 99.7% perciò garantiremo ai nostri clienti un'affidabilità del 95.7% ± 0.3% quindi 95%;
abbiamo un prodotto in 3σ con confidenza 2σ che significa che il prodotto ha una percentuale di copertura del 99.7% e questa affermazione è confermata al 96% perciò garantiremo ai nostri clienti un'affidabilità [²] del 96% ± 4% quindi del 92%.

Il primo metodo è quello giusto per fare una certificazione mentre il secondo è il metodo ottimale per lavorare in sviluppo e ricerca. La ragione è che ai nostri clienti dobbiamo garantire un certo livello di soddisfazione mentre agli sviluppatori dobbiamo garantire un certo livello di copertura. Questo è il "segreto" per il quale il metodo di progressione in Pareto produce un'ottimo rendimento se abbinato a un controllo rilassato perché rinforza le sinergie del parallelismo.

Anticipare l'integrazione

Il fatto che il componente in sviluppo non sia ultimato, "finito" nel senso di essere garantito a 3σ con confidenza 3σ, ha molta meno importanza rispetto al fatto che gli altri possano già cominciare ad usarlo per sviluppare i loro. Diversamente l'efficacia del parallelismo si ridurrebbe e i progetti progressivamente si allungherebbero in modo esponenziale al crescere della complessità.

La critica a questo pensiero più comune è: "se integriamo componenti in stadio precoce di sviluppo otteniamo un'instabilità del sistema". Dipende dalla percezione di precoce che poi è un altro modo di intendere il concetto di controllo (quanto controllo è utile).

Il parallelismo e il suo lato oscuro

Un altro modo di esprimere il concetto sopra è quello di dire che il parallelismo nella lavorazione dei task rende le dimensioni del progetto meno indipendenti l'una dall'altra ed infatti lo sviluppo di un componente influenza quello degli altri perché gli N componenti sono sviluppati insieme.

Se fossero sviluppati in sequenza la dipendenza esisterebbe comunque ma sarebbe di tipo Water Fall: a metà del mio sviluppo mi rendo conto che il componente "finito" non è in realtà adeguato alle esigenze anche se rispettasse le specifiche al 100%, le specifiche possono essere state sbagliate.

C'è poi un altro aspetto devastante in termini di controllo dello sviluppo quando si lavora in parallelo su diversi componenti: quello per il quale tutti rilasciano secondo la stessa scadenza prefissata (e.g. il giovedì) perché in pratica si inietta nel progetto N componenti modificati che come N sassi tirati nello stagno nello stesso momento creano N sorgenti d'onda che si sovrappongono con tutta la "bellezza" della teoria ondulatoria unita a quella del caos per la quale la sommatoria sincrona di tanti piccoli effetti può generare un'urgano mentre due cicloni di rotazione opposta si annullerebbero.

Conclusione

La teoria del controllo si basa sulla teoria della misura la quale non entra nel merito della misura ma delle tolleranza (±ε, errori) e della distribuzione degli errori che non è necessariamente detto che sia correttamente rappresentata da gaussiana in tutti i casi.

L'elemento principale è la confidenza di un'affermazione. A prima lettura parrebbe discutere di dettagli di second'ordine (chi controlla il controllore) ma considerando che sia in termini decisionali e sia in termini di scarto di qualità dobbiamo sempre considerare che la misura è spesso un processo complesso nel quale subentrano più componenti. In particolare quando vogliamo garantire l'affidabilità di un prodotto o di un servizio dobbiamo non solo misurare la sua conformità (copertura) ma anche con quale grado di confidenza siamo in grado di fare un'affermazione di minimo accettabile.

Nel prossimo articolo proveremo a dare una risposta alla domanda è: ci conviene fare controllo o un controllo fine? - Andando a investigare l'efficienza del controllo come bilancio fra costi e benefici.

Riepilogo

In questo articolo abbiamo visto:

un riassunto del precedente articolo
la misura del controllo in funzione degli errori (scarti)
l'andamento del costo del controllo come funzione inversa della qualità
la distinzione dell'uso della σ come copertura oppure come reciproco degli scarti
il concetto di confidenza di una misura (o di un'affermazione)

Curiosità

Nel precedente articolo abbiamo considerato il quarto di cerchio come la curva ottimale per la minimizzazione degli errori. Siamo certi che sia la curva migliore?

Ebbene la risposta è no. Infatti la curva migliore sarebbe la catenaria in quanto essa minimizza l'energia potenziale E = ∫ m·h(x) dx il cui calcolo è equivalente all'area sottesa alla curva che abbiamo visto in questo articolo essere proporzionale all'errore.

Ebbene quella in figura, disegnata in blu è una catenaria mentre quella in rosso è il quarto di circonferenza usato per fare i calcoli. Il tratto orizzontale (in verde) è il segmento del percorso ottimale √2. La differenza è davvero minima e non avrebbe giustificato l'uso di un coseno iperbolico per una misura (errori) per la quale non sono di alcuna utilità i contributi di secondo ordine.

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

[¹] Sarebbe assurdo che due fenomeni aventi la stessa natura avessero andamenti diversi. L'approssimazione dei piccoli intorni è equivalente a dire che non ci interessa ∑ in termini assoluti ma siamo interessati all'azione (impegno, sforzo istantaneo) d∑/dt che dobbiamo fare per controllare l'andamento di ∑ = ∑(x(t)) = ∫ |ε(x(t)) dx(t)/dt| dt. Dove i passaggi algebrici e l'approssimazione dei piccoli intorni sono un trucco notazionale utile per passare in modo intuitivo da un integrale sullo spazio a un integrale sul tempo. Infatti si può portare l'area di riferimento dentro l'integrale e ottenere direttamente che per Ic = ∫ |ε(x)/((√2)²)| dx =∫ |ε(x)/2| dx. Se il nostro punto di percorso dista più di un ε(x) = ½√2 siamo fuori dall'area di controllo del progetto mentre per εmax = ¼√2 l'errore di approssimazione è inferiore al 5% (4.69%) perciò normalmente lavoriamo in un intorno dove l'errore di approssimazione è 0.1%. Infine dobbiamo notare che parliamo di errori di approssimazioni sulla funzione errore di percorso: come a dire che siamo in grado di valutare l'errore sulla correzione dell'errore a 1 su mille!

[²] Per quanto detto si può calcolare l'affidabilità(%) = copertura(%) · confidenza(%)^2 e se usiamo questa formula per calcolare A(cp:3σ, cf:3σ) = (99.7%)³ = 99.2% = 2.65σ che corrisponde al 3° ciclo di Pareto e per A(cp:5σ, cf:5σ) = 4.79σ dove l'8° ciclo di pareto è in 4.70σ. Quest'ultima affidabilità è equivalente a meno di 3 parti su milione che compatibile con il metodo di produzione industriale "six sigma".