eXtreme Project Management  

A cura della redazione di www.xpm.it  

::  Conclusioni ::

Reporting, Conclusioni e Riferimenti

Reporting

Nei progetti estremi è di fondamentale importanza il reporting da produrre in fase di avanzamento progetto. Rispetto a quello che per diversi decenni è stata la logica con cui si sono elaborati tali report, occorre nell'XPM cambiare notevolmente la filosofia di approccio.

Da sempre viene ritenuto fondamentale mettere a confronto i dati effettivi di avanzamento (actual) con quanto definito a livello di piano iniziale (baseline). In tale confronto si possono facilmente evidenziare gli scostamenti verificatisi rispetto al quanto preventivato. Per l'analisi degli scostamenti temporali, si producono solitamente grafici di gantt che mettono a confronto, per ogni singola attività, la barra di baseline con quella di avanzamento o, più semplicemente, la barra di baseline con al suo interno la misura dell'avanzamento percentuale (Gantt "filo di lana").

Per l'analisi dell'avanzamento risorse si usano istogrammi comparativi fra le quantità previste e quelle effettivamente consuntivate, provenienti spesso dai time-scheet,.

Per quanto attiene invece l'analisi dei costi, la tecnica dell'Earned Value permette di mettere a confronto le tre famose curve di BCWS (Budget Cost of Work Scheduled), ACWP (Actual Cost of Work Performed) e BCWP (Budget Cost of Work Performed, più noto come Earned Value). Attraverso tale tecnica è possibile non solo definire lo scostamento economico e temporale fra budget previsto e costi effettivamente sostenuti, ma individuare indici di performance e calcolare, in forma algoritmica, il valore del budget finale a completamento (EAC=Estimate To Completion).

Ebbene tutte le forme di reporting di avanzamento sopra descritte si basano su un presupposto: la baseline è il riferimento, la rotta che deve essere seguita e rispetto alla quale occorre fare il punto sul "dove siamo?" ed agire per riprendere la rotta giusta. Tutto ciò non è di per se sbagliato.

Lo può diventare forse se, parlando di progetti estremi, la baseline fosse, come sostiene qualche studioso, niente altro che un "romanzo"! Mettere a confronto un romanzo con un "storia vera" potrebbe non dare informazioni di grande utilità o, peggio ancora, potrebbe indurre ad analisi e decisioni errate. Occorre quindi stare molto attenti nel verificare, ad ogni avanzamento, che i presupporti rispetto ai quali la baseline è stata sviluppata siano ancora validi e, in caso contrario, ci si deve preoccupare più del dove stiamo realmente andando che del dove avevamo deciso inizialmente deciso di andare.  

Al di la delle considerazioni appena fatte, le seguenti informazioni dovrebbero essere comunque il nucleo del processo del reporting e di revisione di progetto:

• Lo stato del progetto: tutto procede secondo programma oppure no?

• Se la risposta è no, come si è modificata la situazione e quali sono le cause di tale variazione?

• Quali azioni sono state intraprese dal team per risolvere i problemi?

• Quali scenari alternativi sono ad oggi disponibili?

• Quali azioni possono essere intraprese dai senior manager?

• Che cosa è stato modificato o aggiunto al business case da dover essere soggetto ad una revisione e approvazione?

Oltre ai report più tecnici e di lavoro, che il project manager ha necessità di predisporre per il supporto alle propri attività di coordinamento e controllo, è necessario che il project manager predisponga dei report di avanzamento per tutti i livelli organizzativi di controllo: lo sponsor, il comitato di coordinamento (presente di solito solo per i grandi progetti), gli stakeholder.

Evidentemente il formato e la tempistica del reporting di progetto varieranno in ogni organizzazione e dipenderanno dalle dimensioni e dal rischio del progetto.

Sarebbe buona norma avere un incontro preliminare con lo sponsor o con il comitato di coordinamento prima di discutere i project report in un meeting. Il motto per una buona riunione di avanzamento dovrebbe essere: Nessuna sorpresa!

Per i piccoli progetti, che oggi aumentano a dismisura, potrebbe bastare una scheda in cui evidenziare solo le informazioni essenziali richieste dallo sponsor o dal comitato di coordinamento. In allegato a tale scheda si potrebbero riportare dati più dettagliati relativi alle informazioni di tracking si tempi, costi, impegni, ecc.

Ecco un possibile layout di tale scheda.

I project report andrebbero discussi ed esaminati durante appositi meeting di avanzamento. Andrebbero organizzati tre meeting distinti:

• Con lo Sponsor

• Con il Comitato di Coordinamento

• Con gli Stakeholder

Per gli stakeholders critici, i project report di progetto potrebbero essere rivisti preventivamente attraverso incontri uno-a-uno.
Per gli stakeholders non-chiave, potrebbe bastare che essi ricevano copia di tutti i sommari del tracking di progetto e dei project report. Nel migliore dei casi, un rappresentante esecutivo di una determinata aree chiave di stakeholder dovrebbe comunque far parte del Comitato di Coordinamento.

Gli argomenti da mettere in agenda per il meeting con lo Sponsor o con il Comitato di Coordinamento potrebbe essere i seguenti:

• Condizione del progetto - ha il business case subito variazioni rispetto alla riunione precedente?

• In caso affermativo, che cambiamenti ci sono stati?

• Lo scope del progetto?

• Obiettivi e loro Priorità?

• Strategia di sviluppo di progetto?

• Rischi?

• Costi e Benefici?

• Project plan o programmi?

• Qualità?

• Mobilità del personale o problematiche di staffing?

• Quali azioni il project manager o il team hanno preso per risolvere i problema?

• Chi può essere di aiuto nella risoluzione dei problema?

• Chi è responsabile del follow-up?

• Quali sono le cause dei cambiamenti?

• Sono previsti altri cambiamenti per il futuro?

• Altri items come richiesto.

Conclusioni

Innanzi tutto, grazie per la pazienza con cui avete seguito questo breve corso. Più che di un corso si è trattato, in effetti, di una serie di brevi articoli, nati dagli appunti da me presi durate lo studio di alcuni testi americani, che vengono elencati più avanti.

Mi sento alla fine di sostenere che nell'Extreme Project Management vi sono sicuramente dei validi "fermenti" che meritano di essere in futuro approfonditi e che, per lo meno, lo saranno dal sottoscritto.

Interessante e, per certi versi, rivoluzionaria è l'attenzione data al "fattore umano", sia come singolo organismo che come organismo aziendale, ritenendolo come l'elemento fondamentale da gestire con cura nella pianificazione e controllo di un progetto. Mi ha personalmente molto coinvolto la tesi secondo la quale la cattiva o nulla considerazione di tali fattori umani (sindrome dello studente, legge di Parkinson, multitasking, ecc..)  possa da sola far si che a stime iniziali, per certi versi, esatte corrispondano poi, a consuntivo, progetti enormemente in ritardo.

Condivisibili sono inoltre i continui incitamenti al ruolo "partecipativo" del team e all'importanza di un valido sponsor. So che molti di voi hanno pianto leggendo tali incitamenti e pensando alla propria realtà aziendale ma, anche se questo passa al momento il convento, occorre farsi forza sperando .... nelle folgori di cui ho precedentemente parlato.

Che il CCM - Critical Chain Method sia la panacea di tutti i mali ed unica vera soluzione alternativa al vecchio e caro CPM, rimane cosa ancora da "testare", almeno per quanto mi riguarda ed anche per quanto riguarda le aziende ed i project manager con cui ho l'onore di collaborare.

Di certo resta valido il tentativo di fornire ai disperati project manager estremi degli strumenti che siano più leggeri ed agili di quanto non lo siano stati i primi tecnicismi e le prime metodiche di pm sviluppate a partire dalla seconda metà del secolo scorso. L'immagine iniziale del sign. Manolo (.... ma gli fischieranno le orecchie?) appeso con la sola forza delle dita a pareti quasi "inscalabili", resta una forte icona della condizione in cui molti project manager si trovano.

Trovare strumenti o, parlando da consulente e formatore, risposte valide per tali project manager diviene un imperativo al quale non ci si può sottrarre.

D’altro canto, ammiro la coerenza la forza con cui alcuni teorici dell'XPM si pongono rispetto all''utilizzo di tali nuove metodiche leggere, affermando che il loro uso dovrà essere fatto "senza compromessi". Inutile, in altri termini, dotarci di tecniche, metodologie e strumenti faraonici e concettualmente potentissimi per poi farne un uso incompleto e approssimativo. L'Italia è piena, tanto per fare un esempio, di meravigliosi e potentissimi sistemi software di project management (Artemis, Primavera, PlanView... solo per citarne alcuni) usati spesso più per farci "la birra" che per elaborare in modo analitico e scientifico gantt, istogrammi e curve ad S.

Meglio quindi, per assurdo, un semplice foglio Excel contenente poche ma utili informazioni strategiche che non un in-stampabile ed aggrovigliato "reticolo ILLOGICO".

°°°°°

Resto a disposizione di tutti voi per un reciproco scambio di pareri e mi auguro, come già sta avvenendo nei messaggi lasciati sul nostro Forum da alcuni amici, che il sito www.xpm.it possa divenire presto il più importante luogo di riferimento e di approfondimento per un più ampio dibattito sulle tematiche dell'XPM.   
 

Riferimenti

      Generali

• [Goldratt 1997] Goldratt, Dr. Eliyahu M., "Critical Chain", 1997, Great Barrington, MA: North River Press.

• [Beck 2001] K. Beck & M. Fowler, “Planning Extreme Programming”. Boston, Addison-Wesley, 2001.

• [Boehm 1989] B. W. Boehm, “Software Risk Management”. Washington, DC, IEEE Computer Scociety Press, 1989.

• [Jones 1994] C. Jones, “Assessment and Control of Software Risks”. Englewood Cliffs, NJ, Prentice-Hall/Yourdon Press, 1994.

• [Thomsett 2002] Rob Thomsett, “Radical Project Management”, NJ, Prentice-Hall PTP, 2002.

• [DeCarlo 2003] Doug DeCarlo,  articoli su www.projectconnections.com

     Extreme Programming

• Chris Meyers‘, “Fast Cycle Development” (1993)

• Steve McConnell's, “Excellent Rapid Development (1996) 

• http://www.extremeprogramming.org 

• http://www.xprogramming.com 

• A.Grillo, “Software Project Management e Pervasive Computing”, Computer Programming n.101 

• D.Mazzeranghi, “Introduzione alla Extreme Programming”, Computer Programming n.101 

• D.Mazzeranghi, “Extreme Testing”, Computer Programming n.108

• Martin Fowler, “The New Methodology” in http://www.martinfowler.com/articles/newMethodology.html 

<> <> <> <> <> <> <> <> <> <> <> 

Fine delle traXmissioni   :-( 

Un caro saluto

Eugenio Rambaldi

 rambaldi@nextarget.it

Acronimi utilizzati nel documento:

CCM - Critical Chain Management

CPM - Critical Path Method

EAC - Estimate To Completion

FS   - Finish to start

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 seguente documento sono copyright dei rispettivi proprietari