Il concetto di agile project management è emerso recentemente in USA, in ambito ICT, in contrapposizione al project management tradizionale, basato su una pesante e minuziosa gestione di compiti e procedure. Comprende due metodi: l'XPM e lo SCRUM.XPML'XPM è la sigla di extreme project management. Se il project management tradizionale (TPM) è paragonabile ad un'orchestra sinfonica, l'XPM è paragonabile ad un gruppo di jazz. Alla prima bisogna scrivere tutta la partitura nota per nota, al secondo basta scrivere una trentina di battute, poi ognuno sa che cosa fare e lo fa a modo suo, ma in modo funzionale al gruppo.Il TPM è stato elaborato per costruire palazzi, navi, centrali elettriche. L'XPM si usa per creare e mettere sul mercato un software, o una sua modifica migliorativa.Un palazzo è qualcosa di strutturato, che parte dalle fondamenta e va su man mano secondo processi codificati, in genere non cambia in corso d'opera, con lo stesso progetto si possono costruire più edifici uguali. Un software è flessibile, virtuale, può servirsi di pezzi di programmi preesistenti, può cambiare più di una volta rispetto all'ipotesi di partenza, continua a cambiare da una versione all'altra. Come per il software, qualsiasi processo immateriale, dalla comunicazione all'enterteinment, è più simile ad un progetto estremo che ad un progetto tradizionale.Che significa "estremo"? Significa fuori dal normale, eccezionale, imprevedibile, che può cambiare da un momento all'altro, che deve fronteggiare cambiamenti di scenario improvvisi. Strumenti e tecniche di gestione di progetti tradizionali non sono più molto adatti ad un progetto estremo.Una work breakdown structure dettagliata, un diagramma di Gantt rigido, una documentazione di progetto troppo voluminosa e burocratica tendono a complicare la gestione del progetto, invece di facilitarla. Sono strumenti e metodi nati in un periodo in cui un progettista "intelligente" faceva lavorare esecutori "stupidi", che dovevano solo eseguire nel modo più disciplinato procedure limitate, dettagliate, immutabili. In un progetto estremo il capo progetto non è più un controllore di esecuzioni, è un gestore di intelligenze più o meno autonome, ognuna delle quali svolge una parte del progetto, in armonia con le altre intelligenze. Solo un team intelligente può realizzare un progetto estremo, perché solo persone intelligenti possono prendere decisioni al momento, possono perfino cambiare alcune finalità del progetto adattandole a condizioni mutate.Le tecniche di gestione di un progetto estremo sono semplici e flessibili. Il progetto è tracciato nelle sue linee generali, tende a combinare un insieme di scatole vuote che ogni team o responsabile del settore penserà a riempire secondo le sue idee. Anche la pianificazione temporale, invece di essere fatta per compiti specifici, tende a fissare alcuni punti di riferimento (i milestone del TPM) dove i vari responsabili si incontrano ognuno con il suo stadio di avanzamento. Il capo progetto si limita a controllare che quelle scadenze di riferimento siano rispettate. Il cliente controlla solo l'inizio e la fine del progetto, il capo progetto controlla le consegne intermedie.SCRUM Il metodo SCRUM prende il nome dalla mischia che fanno i giocatori di rugby per concordare l'azione e rimettere in gioco la palla. Rompe il triangolo di ferro costi/tempi/obiettivi che intrappola il project manager tradizionale. Il triangolo si apre concordando e tenendo fermi solo costi e tempi. Il project manager, o meglio lo scrum master, mette insieme il team di progetto (scrum team), cerca di tenerlo unito il più possibile, comunica gli obiettivi e si accerta che siano compresi e condivisi. A questo punto deve solo pensare a favorire la produttività del team. Deve rimuovere ostacoli, motivare, ispirare, far seguire la metodologia scrum, basata su riunioni frequenti di 15' (una volta al giorno) dove si parte dal punto raggiunto nella riunione precedente, si fa il punto, si dice se c'è stato qualche ostacolo, si definisce il punto della riunione successiva. Invece di consegnare tutto il prodotto completo alla fine del progetto, si consegnano piccoli pezzi (deliverables). In tal modo, se il progetto cambia all'improvviso, si cambia con esso.E' facile capire come un metodo del genere si basi tutto sulla buona gestione delle relazioni fra tutti gli stakeholder, interni ed esterni, e soprattutto fra cliente e fornitore, fra capo progetto e gruppo di progetto.Per ora lo scrum si usa soprattutto nella gestione di progetti di software. Tuttavia già nel 1987 Nonaka e Takeuchi proposero il rugby come metafora per organizzare il lavoro in ambienti iperproduttivi. E' un processo estremamente efficace per situazioni progettuali caotiche, con obiettivi e requisiti in costante cambiamento. Porta ad una assunzione di responsabilità collettiva da parte del gruppo di lavoro, e favorisce la creazione di team coesi. Lo scrum master invece di essere un controllore di compiti e scadenze deve diventare un leader visionario, deve saper ispirare la sua visione al suo scrum team. Se in un'orchestra sinfonica gli strumentisti sono sostituibili, in un gruppo jazz sostituire un musicista significa cambiare il sound e lo stile del gruppo. Altrettanto avviene nella gestione agile del progetto.XPM e SCRUM possono essere considerati come un ottimo bench mark per gestire progetti di altro genere, ma altrettanto caotici e mutevoli, come accade nella comunicazione e in altri settori e funzioni delle organizzazioni.Caos: caderci dentro o gestirlo?Purtroppo nelle nostre aziende non sono ancora entrate bene queste tecniche agili, che cercano di far assomigliare il progetto più ad una gazzella che ad un ippopotamo. Anche perché i progetti sono gazzelle ancora grasse come ippopotami, oppure sono gazzelle che come ippopotami si rotolano ancora nei pantani burocratici. Tuttavia le situazioni sono troppo turbolente per usare le tecniche del project management tradizionale, ritenute più macchinose dei compiti da svolgere. Non si usano software basati su quelle tecniche, come MS Project o altri ancora più sofisticati. Si vive sempre più nella cultura dell'emergenza, invece che in quella del progetto. Il risultato è una visione sempre più corta, una gestione sempre più stressata e stressante, un abbassamento generale della qualità (dicevano le nonne che la gatta furiosa ha fatto i figli ciechi). Non si tiene in nessuna considerazione il collaboratore (se non ci sei tu, ce ne sono tanti altri che aspettano di prendere il posto tuo), meno che mai la coesione del team.Invece, quanto più un progetto è estremo, tanto più si devono adottare tecniche di gestione. Solo, deve cambiare l'approccio. Bisogna ispirarsi ai grandi felini, che sono sempre calmi, rilassati, ma pronti allo scatto fulmineo.Partendo dalle tecniche (wbs più elastica, a cluster; pianificazione a milestones; condivisione di obiettivi; definizione della critical chain, piuttosto che di complicati PERT) l'elemento fondamentale, quello che fa funzionare tutto, è la relazione con gli stakeholder.Gli stakeholder del progettoGli stakeholder sono tutti i soggetti interessati agli obiettivi del progetto e al processo progettuale. Si parte dallo sponsor, che è l'elemento più importante, colui che vuole il progetto, che lo sostiene, che lo finanzia. Si va al project manager, interessato al buon esito del progetto; ai responsabili dei vari settori; ai collaboratori; ai fornitori; al cliente; all'utente finale. Gli stakeholder possono essere i responsabili della ricerca e sviluppo, i creativi, i programmatori, i responsabili di produzione, quelli del marketing, della distribuzione, dell'assistenza tecnica e postproduzione. Nel caso di progetti che abbiano un impatto sociale, o comunque esterno all'azienda, gli stakeholder sono rappresentanti di interessi ambientali, sanitari, legali, finanziari, sindacali, di responsabilità sociale.Gli stakeholder possono essere favorevoli al progetto, o contrari, se pensano che il progetto possa danneggiarli. Si va da rappresentanti sindacali a movimenti antagonisti di vario genere.Il project manager, prima di far partire il progetto, deve avere un quadro abbastanza chiaro di tutti gli stakeholder, e deve avere un'idea dei loro interessi, delle ragioni per cui sono interessati al progetto. Più il progetto è estremo, più si deve partire dagli stakeholder, perché poi non ci si può permettere di perdere tempo ed energie per l'opposizione di alcuni, o per il conflitto di interessi fra uno stakeholder e l'altro.Un caso classico, ampiamente esemplificato da Merril R. Chapman (Alla ricerca della stupidità , 20 anni di disastri hi tech, Mondadori Informatica, 2004), è il conflitto fra programmatori e marketing. Nell'hi tech il time to market è fondamentale, perché spesso farsi bruciare da un concorrente significa perdere un vantaggio competitivo strategico e addirittura vanificare ogni possibilità di profitto. I programmatori hanno interesse a scrivere un programma elegante, scritto bene. I marketing manager hanno interesse ad uscire fra un mese. Nel caso della nuova versione di un programma, se prevalgono i programmatori, tendono a buttare via il vecchio programma e a riscriverlo da capo, perché sostengono che è molto meglio riscrivere tutto invece che rabberciare quello che c'era. Naturalmente sono pronti dopo tre mesi. Nel frattempo il marketing ha annunciato l'uscita della nuova release, e fa pressione sui programmatori. In tale conflitto il project manager non sa che pesci prendere. Il pubblico chiede la nuova versione, la distribuzione vende il prodotto della concorrenza.La beffa della situazione è che tutti lavorano con urgenza e sotto stress, ma il risultato finale è un ritardo più o meno grave sulla consegna del prodotto finito.Un altro problema di relazioni con gli stakeholder riguarda le risorse del progetto: persone, tempi e budget. Queste risorse sono complementari. Se una di esse è scarsa, bisogna aumentare l'altra. Se sono tutte scarse, bisogna ridimensionare il progetto. In genere il cliente tende a chiedere cose in poco tempo, e vuole spendere poco. Dopo aver chiuso il preventivo e il tempo di consegna, fa nuove richieste, spesso in contraddizione con quelle precedenti. In questo caso la figura dello sponsor è determinante, perché è lo sponsor, più che il capo progetto, quello che ha abbastanza potere da far ragionare il cliente. Comunque il capo progetto deve saper governare le relazioni fra il cliente e il suo team progettuale, proponendo compromessi o semplificazioni che riescano ad accontentare tutti.Le tecniche flessibili dell'agile project management hanno bisogno di una gestione del progetto altrettanto flessibile, aperta, responsabilizzante, specialmente nei confronti di quelli che lavorano al progetto. Chaos e failure management vanno integrati con l'agile project management, perché i collaboratori devono sapere che cosa fare, ma devono lavorare a proprio agio, senza paura di sbagliare. Qualche link per xpm:Come rendere un progetto più simile a una gazzella che a un ippopotamo...
