La legge di Murphy

 sul Project Management

Libero adattamento per XPM.it

Parte prima

di E. Rambaldi

Maggio 2000

"Se un progetto può andare male, lo farà". Così avrebbe sentenziato il capitano dell'aviazione americana Ed Murphy ai nostri giorni. Quelle che seguono sono alcune delle sue famose leggi, raccolte da Arthur Bloch nel libro di grande successo: "La legge di Murphy" - ed. Longanesi & C.

Ovviamente tali leggi sono state liberamente adattate alle problematiche del Project Management. Rispetto alle leggi originarie sono stati inseriti o modificati alcuni termini. 

********

Legge di Murphy

Se un progetto può andare male, lo farà

Corollari

1. Nessun progetto è facile come sembra
2. Tutti i progetti richiedono più tempo di quanto si pensi.
3. Se c'è la possibilità che varie attività vadano male, quella che causa il danno maggiore sarà la prima a farlo.
4. Se si prevedono quattro possibili modi in cui un progetto può andar male, e si prevengono, immediatamente se ne rivelerà un quinto.
5. Lasciati a se stessi i progetti tendono ad andare di male in peggio.
6. Non ci si può mettere a fare una attività senza che qualcun'atra non vada fatta prima.
7. Ogni soluzione del project manager genera nuovi problemi.
8. I cretini sono sempre più ingegnosi delle precauzioni che i project manager prendono per impedirgli di nuocere.
9. Se in un progetto vi è una pecca, madre natura riuscirà sempre a scovarla. 
10. Madre natura è una puttana.

La filosofia di Murphy

Sorridi, project manager….domani sarà peggio

Costante di Murphy

I progetti vengono danneggiati in proporzione al loro valore.

Versione relativistica della legge di Murphy

Tutto va male, in un progetto, nello stesso tempo

Chiosa di O'Toole alla legge di Murphy

Murphy era un ottimista

Settima variante di Zymurgy alla legge di Murphy

Quando piove su un progetto, diluvia.

Postulato di Boling

Se sei un project manager e sei di buon umore, non ti preoccupare. Ti passerà. 

Terza legge di Chisholm

Le proposte sono sempre capite dal team in maniera diversa da come le concepisce il project manager.

Corollari

1. Se si spiegano le cose al Team di progetto in maniera tale che nessuno possa non capire, qualcuno non capirà.

2. Se si fa qualcosa con l'assoluta certezza dell'approvazione del Team, a qualcuno non piacerà.

3. Se si vuol mettere il responsabile di una attività di fronte al fatto compiuto, il fatto non si verificherà. 

Prima legge di Scott

Qualsiasi cosa vada male in un progetto, avrà probabilmente l'aria di andare benissimo.

Prima legge di Finaglie

Se un progetto è nei tempi, qualcosa è andato male

Prima legge di Sodd

Quando qualcuno cerca di raggiungere un obiettivo del progetto, sarà sempre ostacolato dall'involontario intervento di qualche altra presenza (animata o inanimata). Tuttavia, ci sono obiettivi che vengono raggiunti, in quanto la presenza che interviene cerca a sua volta di raggiungere un obiettivo ed è, naturalmente, soggetta a interferenze.

Seconda legge di Sodd

Prima o poi, la peggiore combinazione possibile di attività è destinata a prodursi.

Legge di Simon

Qualsiasi struttura (WBS) prima o poi cade a pezzi.

Legge di Rudin

In casi di crisi che obblighino il team di progetto a scegliere tra varie linee di condotta, la maggioranza sceglierà la peggiore possibile.

Teorema di Ginsberg (per chi crede che gestire un progetto sia una sfida) 

1. Non puoi vincere.

2. Non puoi pareggiare.

3. Non puoi nemmeno abbandonare.

Seconda legge di Everit sulla termodinamica dei progetti

La confusione nel progetto è sempre in aumento. Solo l'enorme sforzo del project manager può limitare tale confusione in un'area circoscritta. Tuttavia, questo sforzo porterà a un aumento della confusione totale del progetto. 

Legge di Pudder

Il progetto che ben comincia, finisce male.
Il progetto che comincia male, finisce peggio.

Teorema di Stockmayer

Se il progetto sembra facile, è dura.
Se il progetto sembra difficile, è fottutamente impossibile.

Legge di Howe

Ogni project manager ha un piano che non funzionerà.

Assioma di Bramati

Tutti i project manager sudano

Legge univoca delle premesse

In un progetto, premesse negative portano a risultati negativi.
Premesse positive portano a risultati negativi.

Quattordicesimo corollario di Atwood

Non si perde mai nessun libro di project management prestandolo, ad eccezione di quelli cui si tiene particolarmente.

Terza legge di Johnson

Se si perde un documento prelevato da XPM.it, sarà il documento che si era tanto desiderosi di leggere

Corollario

Tutti gli amici l'avranno perso, smarrito o gettato.

Legge degli oggetti smarriti

L'unica maniera per ritrovare un documento di XPM.itche si era stampato è ristamparlo di nuovo.

Leggi complementari di Richard sulla proprietà

1. Se si tiene un articolo di XPM.it abbastanza a lungo lo si potrà buttare.

2. Qualsiasi articolo di XPM.it si butti, servirà non appena non sarà più disponibile.

Legge di Boob

Si troverà sempre un articolo di XPM.it nell'ultimo posto in cui lo si cerca.

Legge di Osborn

In un progetto le variabili non mutano mai, le costanti sì.

Prima legge delle modifiche

Qualsiasi informazione che comporti un cambiamento nel progetto sarà trasmessa al PM dopo - e soltanto dopo - che tutte le attività sono state completate (Meglio conosciuta col nome di Legge dell' "Adesso me lo dicono!")

Corollario

In progetti semplici, che presentino una pianificazione ovviamente giusta e una ovviamente sbagliata, è spesso più saggio scegliere quella sbagliata, in modo da avere già pronta la conseguente modifica. 

Seconda legge delle modifiche

Quanto più innocua sembrerà una modifica, tanto più le sue conseguenze si estenderanno e maggiore sarà il numero delle attività che dovranno essere ripianificate.

Legge del centimetro perso.

Nel definire il costo di un progetto, nessun totale potrà essere calcolato esattamente dopo le 16.40 di venerdì.

Corollario

Il totale corretto risulterà evidente alle 9.01 di lunedì.

Leggi di Gilb sull'inaffidabilità (dei sw di PM)

1. I software di PM sono inaffidabili, ma gli uomini ancora di più

2. Qualsiasi sistema di PM che dipende dall'affidabilità umana è inaffidabile

3. Gli errori di schedulazione che non si trovano hanno un'infinità varietà, mentre invece quelli che si trovano sono per definizione finiti.

4. I costi degli investimenti sull'affidabilità del sw di PM aumentano fino a superare quelli degli eventuali errori, o finché qualcuno non insisterà ché si faccia qualcosa di produttivo.

Leggi di Golub

1. Le idee fumose di un PM servono a evitare di stimare gli eventuali costi di una loro realizzazione.

2. La realizzazione di un progetto mal pianificato richiede il triplo del tempo previsto; quella di un progetto pianificato con la massima attenzione solo il doppio.

Principio si Shaw

Realizza un report di PM che anche un idiota può leggere, e soltanto un idiota vorrà leggerlo.

Legge di Paul

Non si può cadere dal pavimento.

Corollario di XPM.i

I project manager, da piccoli, ci impiegano un anno in più degli altri bimbi per capirlo.

Legge del lavoro accurato

Quando si lavora alla soluzione di un problema (es. quando costa il progetto?), fa sempre comodo sapere la risposta.

Legge di Hoare sui grandi problemi

In un progetto, dentro un grande problema ce n'è uno più piccolo che sta lottando per venir fuori.

Prima legge di Wyszkowski

Nessun progetto è riproducibile.

Legge della futilità

Nessun progetto è mai completamente fallito: può sempre servire da esempio negativo.

Legge di Cooper

Se non capite una parola in un brano del PMBok, ignoratela. Il brano ne potrà benissimo fare a meno.

Legge di Brooke

Quando un sistema di PM arriva a essere completamente definito, qualche maledetto idiota scopre qualcosa che annulla il sistema o che lo espande fino a renderlo irriconoscibile.

 

 

 

.......continua