Ferpi > News > XPM: extreme project management

XPM: extreme project management

20/01/2004

Pubblichiamo un interessante pezzo del nostro socio Umberto Santucci, uscito su Apogeo Online.

X significa expanded (html -> xtml) o extreme (xxx = hard core estremo). Nel nostro caso vale il significato di "estremo", inteso come "al limite", "rapido", "mutevole" Il project management è insieme l'arte e la tecnica del gestire progetti, in modo da raggiungere gli obiettivi prefissati entro tempi e costi limitati. Extreme project management significa gestione "estrema" dei progetti, o gestione di progetti "estremi". Si distingue dal project management tradizionale o TPM, più formale e più rigido, mentre l'XPM è più flessibile e più leggero. Il TPM è più adatto a gestire grandi progetti a lunga scadenza, come la costruzione di un ponte o di una portaerei. L'XPM è più adatto a gestire progetti "turbolenti" come la creazione e lo svilupo di un software, di un sito Web, di un prodotto con time to market molto ridotto (e cioè che deve essere messo in vendita al più presto per battere la concorrenza). In genere le aziende piccole, con pochi addetti, ad alta tecnologia e con ritmi rapidi di produzione, tendono a rifuggire dal TPM, perché lo trovano troppo complicato e burocratico. Quindi vivono alla giornata, cadendo spesso nel disordine e in livelli di stress intollerabili. L'XPM è particolarmente adatto a queste aziende, perché è una via di mezzo fra progetto e caos. Vediamo allora che cos'è, a che cosa serve e come si sta sviluppando. Che cos'è l'XPM?Un progetto classico è quello di un edificio. È focalizzato su un obiettivo: costruire un palazzo di cinque piani. Analizza e pianifica macro e microfasi di costruzione: fondamenta, strutture in cemento armato, murature, rivestimenti, infissi, copertura, impianti. Non prevede modifiche sostanziali in corso d'opera. Se pensiamo al progetto di un software, vediamo che si tratta di qualcosa di più fluido, più flessibile, orientato al cliente e ai suoi bisogni più che alla costruzione della cosa in sé. I metodi classici del TPM non sono adatti a questo tipo di progetti. Si deve ricorrere all'XPM. Che cos'è l'XPM? Non c'è una definizione univoca di XPM. Doug DeCarlo lo definisce "....a complex, self-correcting venture in search of a desired result". Il project manager "estremo" si comporta come gli uomini radar che devono seguire e gestire velivoli in continuo movimento, tenendo davanti agli occhi una mappa che cambia in continuazione. Quindi, ciò che caratterizza un progetto estremo rispetto a un progetto tradizionale è il suo livello di prevedibilità. Un edificio sarà costruito in modo molto simile al suo progetto esecutivo. Un software si sviluppa man mano in modi diversi e può arrivare ad essere tutt'altra cosa rispetto al punto di partenza. Nel primo caso il project manager si limita a pianificare e gestire le fasi di costruzione. Si muove in un ambiente chiuso e alquanto stabile. Nel secondo caso il project manager tiene d'occhio i benefici e il valore aggiunto per il cliente, modificando il "prodotto" in base alle mutevoli esigenze. Si muove in un ambiente aperto e turbolento. Come dice Eugenio Rambaldi nelle sue dispense sull'XPM (scaricabili gratuitamente dal sito Xpm.it): "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 è? È ancora un progetto, per il solo fatto che lo chiamiamo ancora così, o e tutt'altra cosa? 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 sì 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" 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". Inquietanti, a dir poco, sono i dati statistici che importanti istituti pubblicano annualmente sullo stato di salute dei progetti software: 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/servizi 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. Da dove viene e come si sviluppa l'XPM?L'XPM nasce dallo studio di alcuni consulenti senior americani per affrontarte adeguatamente questo nuovo genere di progetti, con consegne più veloci, maggior creatività, maggior attenzione al "lato umano" dei progetti, sensibilità alle richieste di clienti e stakeholder e al ritorno dell'investimento (ROI). L'XPM non è una metodologia rivoluzionaria. Non si contrappone alle più consolidate e ortodosse metodologie del Traditional Project Management o TPM, illustrate da molti libri e definite dal Project Management Institute nel suo famoso testo PMBok [PMBok2003]. L'XPM non estremizza il project management tradizionale, ma gestisce progetti estremi partendo proprio dai principi del TPM per poi semplificarli. Appartiene ad una certa cultura dell'organizzazione di cui fanno parte il chaos management e sistemi di gestione dei progetti software come UML, RUP, Scrum, applicati in seguito anche ad altri ambiti progettuali. Rispetto al TPM, l'XPM usa tecniche leggere, agili, da applicare però con costanza e determinazione, più adattive che predittive. All'idea militaresca di un piano preciso e obbligatorio che predice le cose da fare, sostituisce un metodo che si adatta ad una realtà in continuo cambiamento. È il piano a doversi adattare alla realtà, ottenendo i risultati al momento desiderati, piuttosto che quelli pianificati. L'XPM distingue nettamente il contenuto di un progetto dal suo contesto. Il TMP si focalizza verso il basso e verso l'interno del progetto, verso il team ed il contenuto tecnico del progetto. L'XPM si focalizza verso l'esterno e l'alto, verso gli stakeholder, lo sponsor del progetto, le relazioni complesse fra progetto e stakeholder. Il project manager tiene conto soprattutto delle informazioni sugli aspetti di business, e lascia al technical manager quelle che riguardano gli aspetti tecnici, come le tecnologie di sviluppo e le specifiche tecniche da sviluppare. In tal modo può essere più sensibile al contesto, all'ambiente, agli scenari. L'XPM si basa su un team molto motivato e responsabilizzato, pronto a cambiare per adattarsi ai cambiamenti improvvisi del progetto estremo, e su una leadership a sua volta leggera, che si limita a dare direttive e a controllare i risultati, accettandoli anche se non sono esattamente quelli che ci si sarebbe aspettato. In tal modo si lascia autonomia al team e se ne sviluppa la creatività. MetaforePer comprendere meglio la differenza fra il TPM e l'XPM tornano utili alcune metafore. Il primo è come una portaerei, il secondo come un gommone. La portaerei è grande, complessa, potente, ma lenta nelle manovre, costosa, difficile da governare. Il gommone ha un raggio d'azione limitato, ma è rapidissimo nel cambio di direzione, può andare fra gli scogli, può arrivare fin sulla spiaggia. Oppure il TPM è come un'orchestra sinfonica, che ha bisogno di partiture scritte nota per nota e di un direttore dal pugno di ferro. L'XPM è come un gruppo di jazz, dove il leader prepara la scaletta dei pezzi da suonare e dà alcune direttive sommarie, ma poi ogni musicista suona a modo suo al momento, pur rispettando gli schemi armonici e l'arrangiamento del pezzo. Oppure il TPM è come un'azione di guerra, l'XPM come un'azione di guerriglia. O ancora, per chi ama la montagna, il TPM è come una spedizione d'alta quota, con portatori, campi base e campi alti, corde fisse, rifornimenti, attrezzature varie. L'XPM invece è come il free climbing, dove si arrampica in pantaloncini e maglietta, con una corda e un po' di moschettoni, su vie di alta difficoltà ma di 25 metri, con arrampicate di pochi minuti ciascuna. Il sito XPMRecentemente è stato dedicato un sito all'XPM, vi si trovano informazioni su software, metodi e notizie varie, e il corso completo di Eugenio Rambaldi, di cui ho parlato sopra, da scaricare e leggere gratuitamente, con riferimenti biblio/sitografici. Nel sito c'è anche una mia rubrica, "il Tao del project management", dove cerco di combinare la leggerezza dell'XPM con la leggerezza e flessibilità dell'antico testo di saggezza cinese. Umberto Santucci
Eventi