eXtreme Project Management  
 

A cura della redazione di www.xpm.it  

::  Modulo 5 ::

XPM - Concetti di base (2)

Nella prima parte di questo quarto modulo abbiamo preso in esame alcuni concetti base dell'XPM. Ricapitolando, essi erano:

• Utilizzo di Metodologie leggere

• Predisposizione ad accettare il cambiamento

• Differenziazione fra Contesto e Contenuto

• Project management a Vita-Intera

• Ruolo del Project Manager come facilitatore!

• No sponsor, no start.

Esaminiamo adesso altri concetti base dell'XPM.

Che tipo di Piano?

Per anni ho sostenuto, e lo sostengo ancora, che una buona pianificazione è alla base del successo nella gestione di un progetto. Sopratutto parlando di "controllo", il TPM afferma con forza che esso è tale solo se nasce da un adeguato confronto fra dati pianificati (baseline) e dati effettivi (actual). Tutto ciò è inconfutabilmente vero laddove il progetto parte con obiettivi chiari e con modesti cambiamenti in corso d'opera. 

Purtroppo molti project manager, con un approccio che DeCarlo definisce "newtoniano", hanno a volte  creduto troppo nella possibilità di descrivere la realtà attraverso modelli e regole fisse ed immutabili. Hanno, per tornare nel nostro campo, creduto fosse possibile mettere a punto dei "piani infallibili" e, a sostegno di ciò, si sono poi ostinati a seguirli anche quando la realtà del progetto andava discostandosi sensibilmente dalle previsioni. In molti casi, anche da me vissuti, si è cercato di piegare la realtà al piano e non, come evidentemente sarebbe stato più opportuno, viceversa. 

Quanto sopra non deve stupire più di tanto se si pensa che per decenni, o meglio per secoli, in ambito militare (in cui, non casualmente, il project management nasce!) le guerre si sono condotte approntando invincibili piani strategici presso comandi generali situati a decine, quando non a decine di migliaia, di chilometri di distanza dal fronte di battaglia (Vietnam). Le conseguenze dovute alla rigidità e lentezza di tali piani rispetto ai repentini cambiamenti nell'evolversi delle battaglie e, ancor più, delle guerriglie, ha spesso comportato disfatte clamorose rimaste nella storia. Nella sua autobiografia, It Doesn't Take A Hero, il generale Schwarzkopf (1992) ha definito come datato tale approccio, raccontando come la campagna Desert Storm contro l'Iraq sia stata condotta in modo totalmente diverso perchè "...la tempestività è tutto in battaglia e se non avessimo corretto in tempo reale il piano avremmo perso l’attimo giusto". 

Alcuni studiosi hanno, a proposito di pianificazione real-time, sviluppato una teoria detta "scenario planning" come metodo strategico di pianificazione, sostenendo che la pianificazione strategica lineare tradizionale non è più rilevante nell'odierno ambiente turbolento del business.

RAP

Da diverso tempo nel settore informatico viene utilizzata una tecnica per l'analisi ed il disegno di sistemi informatici che deriva dalla metodica FAST, sperimentata fin dagli anni 80 da AT&T. Da questo nuovo approccio è derivato, sempre in area sistemi informatici, il Rapid Application Development (RAD). Si tratta, fra l'altro, di organizzare "brainstorming" intensivi (solitamente meno di cinque giorni) in cui clienti chiave ed analisti di sistema esperti definiscono il disegno del sistema e, fino a quando non si è finito,...non si esce!.

Tra le nuove tecniche indicate dal'XPM (che è in sostanza più un nuovo approccio "filosofico" al project management che un tentativo di definire nuovi e algoritmici tecnicismi) viene proposto un metodo simile ad Rad, chiamato, per assonanza, RAP - Rapid Planning. Proprio per eliminare le lungaggini che spesso si hanno nella fase di pianificazione, a causa del ping-pong negoziale fra project manager e singoli stakeholder, e sopratutto per favorire il dialogo "laterale" ed extra-funzione fra i componenti del team di progetto, il RAP propone un'unica sessione di pianificazione a cui partecipino, oltre al project manager, tutti gli stakeholder chiave. Il RAP, che deve seguire degli step precisi di planning, deve essere un processo rapido ma, al contempo, altamente partecipavo, in cui si cerca una linea di accordo comune prima che la baseline venga "congelata". Non possiamo qui, per brevità, esaminare tali passi di planning di una riunione RAP, anche perchè tale aspetto verrà trattato specificatamente in un successivo modulo.  Possiamo invece sottolienare che il RAP dovrebbe focalizzarsi solo su ciò che è al momento prevedibile, pianificando quindi in dettaglio le attività, le milestone, i deliverable, ecc., che ricadono in una finestra temporale molto limitata (dalle 2 settimane ai 2/3 mesi, a seconda delle dimensioni e delle criticità del progetto). 

Anche le riunioni di avanzamento dovranno seguire la logica della rapidità e pragmaticità degli argomenti trattati, prendendo come esempio gli incontri mattutini, quasi giornalieri, che si svolgono nei grandi studi legali  e che, come me, avrete sicuramente visto essere rappresentati in molti telefilm americani. A tale proposito si potrebbe pensare a dei meeting di "colazione", in cui, fra un dolcetto ed un tea, si esaminano le ultime "news dal progetto", ma in ambienti in cui, non certo casualmente, ...... manchino le sedie. E' ciò che si definisce uno stand-up meeting, unico modo affinché le persone, stanche di stare in piedi, siano rapide e concise.

Certo la sola gestione dei meeting (organizzazione, convocazione, svolgimento) per project manager che seguono contemporaneamente più progetti, come un mio giovane amico operante nell'area telefonia mobile che ha in linea (...è proprio il caso di dirlo..) più di 15 progetti, diventa un problema di non poco conto. Inoltre, se tali project manager applicassero la tecnica dello stand-up meeting mattutino con colazione, sopra accennata, per tutti i progetti di competenza, si verrebbe a creare un grave pericolo per la loro.... dieta!! 

Team Virtuali

Spesso alle problematiche insite in un progetto estremo se ne aggiungono altre che, se ciò è possibile, ne peggiorano ancora di più la situazione. 

In questi anni la natura delle organizzazioni è cambiata ed i team di progetto sono cambiati di conseguenza. Oggi in un team possono essere presenti molti stakeholder e esperti non co-locati, spesso consulenti o appaltatori che lavorano per le organizzazioni esterne. Uno dei grossi problemi che molti project management stanno incontrando nella gestione dei loro progetti è la sempre più rapida trasformazione dei team di progetto da team tradizionali a Team virtuali. Il concetto di team virtaule si differenzia molto dalla problematica, se pur cogente, dei team remoti. Un team affiatato e composto di persone che si conoscono e si stimano da tempo, può lavorare benissimo anche se per un certo periodo i componenti di tale "squadra" non sono ubicati fisicamente nello stesso luogo. Sappiamo tutti, infatti, quanti strumenti sono oggi messi a nostra disposizione dalla tecnologia per affrontare il problema della comunicazione a distanza e quanto Internet/Intranet abbia mutato i nostro modo di relazionarci. Grazie a 'e-mail, video conferenze, web forum, chat, ed ai pià anziani ma pur sempre validi telefono e fax, i team remoti possono comunque cercare di "restare uniti". 

Diverso è invece il problema dei team virtuali, team nei quali, sicuramente anche a causa di un scarsa frequentazione, possono, insorgere le seguenti dinamiche [Thomsett2002]:

• Nessuna amicizia fra i membri del team

• Poca esperienza comune

• Poca visione comune

• Fiducia fra i membri del team limitata alle sole abilità professionali

• Differenti sistemi di valori 

• Poca o nessuna lealtà al team

Inoltre, sempre più spesso, i membri del team sono impegnati part-time e l'unico membro del team a tempo pieno sul progetto finisce per essere il project manager; ma anche questo per alcuni project manager purtroppo non è più vero.

Stime e fattore umano

I piano temporale di un progetto è il risultato di una schedulazione più o meno supportata da tecniche di programmazione automatica (Pert, Cpm). Le informazioni di base, rispetto alle quali si sviluppa un programma temporale, sono le stime delle attività di progetto in termini di tempo (durate) e di impegni (risorse necessarie/disponibili). Se un progetto finisce molto più tardi di quanto preventivato, la motivazione più banale che spesso in azienda si da è che "si sono sbagliate le stime". Per assurdo, però, se un progetto dovesse finire prima del previsto, il project manager potrebbe essere accusato, con riferimento alle stime, di averle "gonfiate". 

Sono invece più che convinto che solitamente i project manager, nonostante le innumerevoli difficoltà nel formulare le stime (es. non sapere ancora con precisione cosa si deve fare!), non prendano "svarioni" tali da giustificare dei ritardi che, come abbiamo detto in precedenti paragrafi, possono arrivare al superare il 200% dei tempi pianificati.

Molti studiosi di XPM addebitano tali notevoli discrepanze fra pianificato ed effettivo, oltre che alla onnipresente legge di Murphy [1], ad una serie di fattori derivanti dalla nostra natura umana e, comunque, da come nelle realtà aziendali si tende ad organizzare il nostro lavoro. Elencandoli solo brevemente, tali fattori umani sono:

• Fattore di contingency presente nelle stime. Solitamente si tende ad inserire nella stima (es. una durata) un fattore di sicurezza che, in alcuni casi, può arrivare ad essere un buon 50% di ciò che realmente valutiamo necessitare ad una attività, da un punto di lista tecnico. Ora, ciò non è di per se errato; è errato invece nascondere tale valore affogandolo nella durata totale e non evidenziandolo a parte.

• Sindrome dello Studente. Quando un genitore sgrida il figlio dicendo: "Ma perché ti sei ridotto a fare all'ultimo momento i compiti che l'insegnate ti aveva assegnato diversi giorni fa?", allora quel figlio è affetto dalla sindrome dello studente. Tale sindrome, dobbiamo ammetterlo, molti di noi (..io ho scritto tale modulo ieri sera!) se la portano dietro tutta la vita. La conseguenza di tale atteggiamento psicologico ha un forte impatto sui progetti in quanto alcuni margini di sicurezza (es: i total float tipici del CPM) rischiano di essere irrimediabilmente compromessi, aumentando la criticità del progetto e, in caso di contrattempi (....che Murphy definirebbe "certezze"), portando ad inevitabili ritardi.

• Legge di Parkinson, ovvero, "Il lavoro si espande in misura del tempo assegnato”. Chi come me ha lavorato con giovani programmatori "creativi", la legge di Parkinson l'ha sperimentata sulla propria pelle. Se si dice ad un programmatore che per fare una attività è previsto un range temporale di 10 giorni, lui lavorerà 80 ore; se invece gli si dice che di giorni ne sono stati previsti 20, lui lavorerà 160 ore. E, questo, sempre per fare, specie dal punto di vista del cliente, la stessa cosa! Con ciò non voglio dire che il programmatore da 160 ore ha perso tempo o ha "gonfiato" i suoi fogli-presenza, ma semplicemente che egli ha inconsciamente "cadenzato" il proprio lavoro, sopratutto in termini di qualità, sulla base del tempo a disposizione. Avendo più tempo a disposizione ha inserito meglio le "remmature", ha fatto qualche test in più, ha scritto (...miracolo!) un pò di documentazione tecnica. Anche in questo caso certi margini che il project manager aveva considerato per maggior sicurezza (es. date di fine al più presto contro date di fine al più tardi) vengono vanificati, in quanto tali ammortizzatori vengono totalmente saturati dalla legge in oggetto. 

• Multi-tasking. Mi piacerebbe tanto trovare qualcuno, parlando di progetti, che oggi non lavori in un ambiente di multi-progetto e, quindi, di multi-tasking. Sovente ci tocca infatti interrompere una attività in corso per poterne completare un'altra di un altro progetto, in funzione dell'ultimo capo che ha alzato la voce, dell'ultimo cliente che ha telefonato, dell'ultimo amministrativo che deve fatturare, ecc...ecc... Alcune delle "emergenze" appena elencate sono ovviamente inevitabili, ma il danno che il multi-tasking comporta ai progetti è enorme, sia per un evidente calo nella capacità produttiva delle persone sia per un aumento generalizzato della criticità del sistema, in quanto il meccanismo del multitasking fa saltare eventuali scelte sulla prioritizzazione dei progetti e li porta tutti ad assumere eguale livello di criticità. Ammetto che in questo ultimo paragrafo non mi sono spiegato granché, ma meglio di così, in due parole, non ci riesco: ne riparleremo con più calma affrontando, in un modulo ad-hoc, la metodologia  Critical Chain (vedi di seguito).

Theory  Of  Constraints: "Una catena si spezzerà sempre nel suo punto di maggior debolezza".

• Critical Chain. Nel suo libro di successo “Critical Chain”, lo studioso Goldratt indica una variante alla tecnica tradizionale CPM (Critical Path Method). La tecnica Critical Chain diriva da teorie più ampie e complesse fra cui la TOC - Theory Of Constraints. Il Critical Chain Management (CCM) cerca di tener conto e di contrastare tutti quei fattori umani ed di organizzazione del lavoro che vanno così pesantemente ad incidere sul rispetto della pianificazione di progetto. E' una tecnica, come vedremo in seguito, estremamente semplice e sicuramente meno algoritmica del Critical Path Management (come lo definisce Goldratt), ma al contempo, come succede spesso nell'XPM, quel poco che si deve fare deve essere fatto "senza compromessi", individuando da una parte un' unica possibile schedulazione (al più tardi) e dall'altra ampi periodi di "assorbimento" per eventuali ritardi (Buffer).

-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-

Ma queste ed altre cose le esamineremo in dettaglio nei prossimi articoli.

Xtremato ma...felice  ;-)

Eugenio Rambaldi

[1] Si veda, a tale proposito, la ri-trascrizione delle famose Leggi di Murphy da me operata con riferimento al project management: www.xpm.it/legge_murphy.htm 

Acronimi utilizzati nel documento:

CCM - Critical Chain Management

CPM - Critical Path Method

PM   - Project Manager

RAP  - Rapid Planning

TOC - Theory Of Constraints

TPM - Traditional Project Management

XPM - eXtreme Project Management

©Copyright 2003 NexTarget s.a.s. Tutti i diritti riservati.
Per informazioni, suggerimenti o “critiche feroci”  contattaci alla e-mail redazione @ xpm.it  
o scrivi un tuo messaggio nel nostro Forum dedicato all'XPM

 N.B. Tulle le immagini e le citazioni presenti nel documento sono copyright dei rispettivi proprietari