I progetti "estremi"

premetto subito, sebbene si parlerà spesso in queste righe di "progetto estremo", che una definizione condivisa dai vari studiosi non è stata da me trovata in nessuno degli scritti consultati.

Molto intrigante e quella data da Doug DeCarlo, secondo il quale un progetto estremo è “….a complex, self-correcting venture in search of a desired result". In altri termini, un'impresa simile a quella che giornalmente compiono i fatidici "uomini radar" nel tentativo di non perdere mai il contatto con oggetti volanti (ufo?) in continuo spostamento.

L'uso del termine "extreme" rimane però soggetto, a mio avviso, ad interpretazioni differenti e, per certi versi, tutte interessanti.

Se con l'aggettivo "estremo" intendessimo "al limite", per "progetto estremo" potremmo intendere quei progetti che si pongono quasi sulla linea di confine tra il concetto tradizionale di progetto e il suo esatto contrario (non-progetto o ....caos!). Accettando infatti come valida la definizione che Graham [Graham, 1990] ha dato di progetto ("Un insieme di persone e di altre risorse temporaneamente riunite per raggiungere uno specifico obiettivo, di solito con un budget determinato ed entro un periodo stabilito"), un progetto che parta senza chiari obiettivi, con team remoti (o peggio virtuali) e con la quasi matematica certezza di uno sforamento temporale non inferiore al 50%, che cosa è? E' ancora un progetto, per il solo fatto che lo chiamiamo ancora così, o e tutt'altra cosa? Forse, se è un progetto, è un progetto estremo, un progetto "al limite"......delle nostre possibilità!

Per contro, se consideriamo la valenza che noi diamo al termine "estremo" dicendo: "Sto leggendo questo articolo con estremo interesse!", dove per estremo intendiamo, si spera, "grande","molto", allora per progetto estremo potremmo anche intendere un "grande progetto" e, vedendo il progetto come una impresa, come in effetti è, potremmo anche intendere il progetto estremo come una più grande, più difficile, più impegnativa di altre.

Tornando ora alla definizione data da DeCarlo, essa, se pur molto generica ed allargata, evidenzia come la principale differenza fra un tipico progetto (che per comodità definiremo in seguito “tradizionale”) e un progetto estremo riguardi sopratutto il livello di prevedibilità che circonda l'impresa.

In un progetto tradizionale, es. la costruzione di un complesso edilizio, l’oggetto da realizzare è generalmente noto a priori, essendosi di solito già preventivamente conclusa ed approvata la fase di progettazione (design). Il project manager è, in tali progetti, impegnato sopratutto nella pianificazione e controllo delle fasi/attività che, nel rispetto di vincoli temporali, economi e di qualità, consentiranno di raggiungere gli obiettivi prefissati e assegnatigli.
Tali obiettivi potranno, in corso d’opera, subire dei cambiamenti e sarà uno dei compiti del project manager governare anche tale eventualità (change control), ma il cambiamento comunque verrà quasi sempre considerato come una variante “eccezionale” rispetto al contenuto fondamentale, allo "scope" del progetto e al piano definito.
L’obiettivo di un progetto estremo, invece, non è tanto uno specifico “prodotto” da realizzarsi quanto piuttosto la garanzia del raggiungimento di determinati benefici e di un valore aggiunto per il cliente. Ciò non deve mai essere perso di vista dal project manager in quanto è solo su tali parametri che si potrà misurare il successo o il fallimento finale del progetto.

L’ambiente che circonda un project management team tradizionale è solitamente alquanto stabile e, in certi casi, chiuso, in grado comunque di ritrovare sempre un suo equilibrio anche a seguito di turbative e di mutamenti provenienti dall’esterno.
Al contrario, i team dei progetti estremi vivono in ambienti organizzativi e sociali aperti e molto turbolenti: molti cambiamenti, alta velocità e forte incertezza.

Spesso in un progetto estremo i cambiamenti sono all’ordine del giorno e, per assurdo, finiscono per costituirne la norma, l’essenza stessa del progetto, facendo si che sia la stabilità a divenire un’eccezione. I requisiti mutano costantemente durante il progetto, in risposta a fattori ambientali che includono la concorrenza, la tecnologia, i regolamenti e le leggi, le circostanze economiche e, soprattutto, il mutamento dei bisogni di cliente.
Si può inoltre spesso parlare di progetti client-driven, sebbene ciò che il cliente "realmente" desidera potrebbe non essere noto a priori ma delinearsi invece man mano che il progetto procede. Da questo punto di vista ritengo che tra i principali compiti del project manager, e di coloro che lo supportano (sponsor e/o comitato guida), vi sia oggi proprio il rimanere sempre focalizzati e "aggrappati" (ricordate Manolo?) alle effettive esigenze del cliente, aiutandolo per quanto possibile a chiarire e a descrivere a se stesso e a noi, gli obiettivi finali attesi, indipendentemente da fatto che essi siano stabili o fortemente mutabili.

Indubbiamente esistono settori merceologici in cui i progetti hanno una maggiore vocazione a divenire sempre più estremi o, se si vuole, complessi. In generale, la fa da padrone il settore dell’Information Technology ed, in particolare, le aree dello sviluppo software, del web e dell'e-business.

Che i progetti software siano solitamente più complessi di altri certo non deve stupirci se, come indicato da Ed Yourdon, facciamo le seguenti considerazioni:

il software è complesso in quanto si tende a risolvere con esso i problemi più costosi o difficoltosi con altre soluzioni.
il rapporto “progettazione”/“realizzazione” è molto più grande rispetto ad altri progetti (fino al 50% ed oltre).
non esiste un metodo di progettazione del software stabile e riconosciuto e non esistono (o solo in parte) sistemi di protezione e certificazione del SW.
il codice è facilmente modificabile anche da parte di utilizzatori non autorizzati.
il gap fra “da realizzare” e “effettivamente realizzato” è, di media, molto elevato.
gli utenti non riescono inizialmente a valutare bene il risultato finale di un progetto SW.

Ulteriori criticità sono inoltre sempre più crescenti nei progetti di e-business, ed in particolare nelle applicazioni per il web ed il pervasive computing.[1]

Inquietanti, a dir poco, sono i dati statistici che importanti istituti pubblicano annualmente sullo stato di salute dei progetti software:[2]

Più del 30% di tutti i progetti software è cancellato prima del completamento.
Più del 49% di tutti i progetti software non raggiunge le caratteristiche attese.
Mediamente un progetto software assorbe il 189% del budget e il 222% della durata prevista!

La situazione, in fatto di progetti "a rischio", non è molto differente anche in altri settori, soprattutto in quelli in cui si realizzano prodotti/servizio poco materiali e di notevole valore aggiunto per il cliente, in tempi molto brevi e partendo da requisiti iniziali molto poco definiti ed altamente volatili (es: siti web).

Fanno parte di questo range molti progetti ad elevato contenuto intellettivo e creativo, come i progetti di ingegneria/architettura, di ricerca e sviluppo, dello spettacolo, di consulenza ma anche i progetti politici, sportivi, i grandi eventi (es. mega-concerti, parate militari, ecc.), ed altri.

Giunti a questo punto diventa fondamentale porsi una domanda: Possono interessarmi le teorie sull'XPM rispetto alle problematiche derivanti dai progetti di cui solitamente mi occupo?
Ebbene, per poterci dare da soli una risposta, sottoponiamoci con sincerità al seguente test.

Domanda	Si	No
La mia azienda crede, a tutti i livelli organizzativi, nel project management.
La mia organizzazione ha un piano strategico ben definito e stabile.
Ho informazioni chiare e complete sugli obiettivi e sull’ambito del progetto.
Ho un project plan completamente stabile e realistico.
I miei stakeholders sono completamente impegnati nel mio progetto.
Il mio sponsor è sempre a disposizione per un rapido ed efficace supporto.
Il mio team è leale ed è dedicato al progetto.
Si elaborano e gestiscono piani efficaci di risk e quality management.
Posso fare riferimento su un gruppo di project manager esperti.
Ho tutti i tool, la tecnologia e le tecniche di cui ho bisogno.
Il mio progetto e la mia organizzazione non stanno cambiando velocemente.

Secondo Rob Thomsett [Thomsett 2003] se abbiamo risposto “Si” a tutte le domande precedenti possiamo con fiducia partecipare al premio “il Project Manager del secolo” ed avere anche buone probabilità di vincerlo! In caso contrario, abbiamo probabilmente a che fare con progetti estremi o, comunque, operiamo in un’area in cui un approccio tradizionale di project management potrebbe non dare sempre i risultati desiderati.

Ed è a questo punto quindi che potrebbe entrare in gioco, come nuova filosofia di approccio al problema, l'XPM. Come?

Se lo dicessi adesso..... nei prossimi 7 moduli che ci scrivo??

Xaluti

Eugenio Rambaldi

------------

[1] Il Pervasive Computing (PVC) è la possibilità di ottenere e gestire informazioni in maniera semplice, efficiente e rapida, indipendentemente dalla locazione fisica e per mezzo di strumenti semplici quali pda, cellulari o console ludiche oltre ovviamente che per mezzo degli office-pc

[2] Fonte: Standish Group – “Chaos report”

Indice prossimi argomenti trattati:

Modulo 4: XPM – Concetti di base1

Modulo 5: XPM – Concetti di base2

Modulo 6: Contenuto e Contesto

Modulo 7: I processi di stima

Modulo 8: Critical Chain management

Modulo 9: Rapid Planning

Modulo 10: Time Tracking vs Project Tracking

Modulo 11: Conclusioni e Riferimenti

©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 eventualmente presenti nel presente documento sono copyright dei rispettivi proprietari