L applicazione di Microsoft Project per il controllo di un appalto di opera pubblica

Transcript

1 L applicazione di Microsoft Project per il controllo di un appalto di opera pubblica di: Laura DI SPES, Marco SOVERA Maggio 2005 Introduzione Da tempo interessati e appassionati alle tecniche di Project Management, avevamo da poco organizzato e frequentato un corso ad hoc sull uso di Microsoft Project applicato alla costruzione di un opera civile, che finalmente, prima di quanto pensassimo, arrivò il fatidico momento.. La nostra avventura comincia nel settembre del 2003, quando l impresa di costruzioni generali, di cui eravamo (allora entrambi) consulenti stabili, risultò aggiudicataria di una commessa di ,00 Euro in ATI con 4 imprese, di cui due civili e due impiantistiche (meccanica ed elettrica). L appalto, indetto da un Amministrazione Comunale, consisteva nella costruzione e ristrutturazione radicale di un complesso di dieci edifici per complessivi mc vuoto per pieno da realizzare in 29 mesi, inserito in un tessuto storico sulle rive di un canale, in una zona caratterizzata da notevoli difficoltà logistiche. Le richieste dell Amministrazione, chiaramente espresse in un documento genericamente denominato Linee guida per la Qualità (che era allegato al Capitolato Speciale d Appalto), prescrivevano a carico dell appaltatore oltre all applicazione di un Sistema di Gestione in Qualità, secondo le canoniche norme ISO 9001, un sistema di controllo della commessa con tecniche di Project Management secondo i canoni del PMBoK, mediante l uso di Microsoft Project. Nell ambito dell ATI, e in special modo nel caso delle imprese civili, l approccio di una commessa pubblica con tecniche di Project Management era un assoluta novità e quindi, anche in relazione alla classica resistenza al cambiamento, fu inizialmente sottovalutata e messa in coda alle usuali attività di start-up quali: stesura di regolamenti associativi e patti parasociali, nomina dei vari responsabili, ricerca personale, incantieramento,.ecc. Le difficoltà di gestione in ATI La prima reazione dell ATI fu quella di affidare tutto ad una società di servizi esterna che ci fornisse il pacchetto completo. Poi fu deciso di ripiegare sulle proprie forze, cercando all interno dell ATI, ognuno fra le proprie risorse, chi potesse risolvere il problema. Tale ricerca risultò di non poco conto visto che a molti la sigla WBS risultava sconosciuta. E così, visto che mi occupo di Qualità, visto che ho fatto un corso di Project (capirai!), io, Laura, sono stata candidata a studiare il problema e portarlo in sede di riunione ATI per coinvolgere gli associati a fare la loro parte. Trovammo scarsa sensibilità tra gli associati, d altronde l impegno iniziale era diverso a seconda delle rispettive competenze. Ci scontrammo col fatto che esigenze che richiedono scelte immediate per le imprese civili, venivano Pag. 1 di 6

2 considerate di poca importanza per le imprese impiantistiche, che prima di un anno non sarebbero intervenute nel cantiere. Ma prima di capire come sviluppare il sistema di controllo commessa bisognava capire come l ATI intendesse organizzarsi, insomma chi faceva cosa! L ATI era così costituita: Impresa 1 - Opere Civili - capogruppo Impresa 2 - Opere Civili - mandante Impresa 3 - Impianti Termomeccanica - mandante Impresa 4 - Impianti Elettrici e speciali - mandante Per la gestione della commessa questa si è organizzata dotandosi di regolamento interno. All interno dell ATI stessa le due imprese civili si sono riunite in Società Consortile anch essa dotata di regolamento specifico. L organizzazione dell ATI, con le sue regole, è stata descritta all Amministrazione appaltante attraverso la redazione di uno specifico Piano di Qualità Generale, sottoscritto da tutte le associate, rimandando la descrizione operativa delle singole organizzazioni ai rispettivi PdQ, cosa che non è stata così immediata per la consortile che ha dovuto costituire un Sistema di Gestione in Qualità (SGQ) apposito. Le richieste delle linee guida - chiarimenti con il PM dell Amministrazione Le linee guida, redatte dal Project Manager (certificato PMP) dell Amministrazione appaltante, recepivano perfettamente le normative vigenti nel campo dei Lavori Pubblici, dando addirittura gli schemi per la loro adozione nella redazione del Piano di Qualità dell Appalto, mentre di più difficile adozione sono state le canoniche regole del PMBoK. Le tecniche di PM, nate per il controllo della commessa mediante i costi della stessa, in questo caso sono state applicate per controllare la commessa da parte dell Amministrazione appaltante con i suoi costi, ovvero l importo delle opere fissato contrattualmente per l ATI. Sviluppare quanto richiesto dalle linee guida, con la complessa organizzazione dell ATI, richiedeva tempo ed energia; si decise quindi di redigere un primo schema da discutere con l Amministrazione appaltante in modo da focalizzare e chiarire alcuni punti poco coerenti con quanto si stava per approntare. In particolare la richiesta di frazionare l appalto in singoli Work Package (WP) aventi un importo non superiore al 0,25% dell importo di contratto non era molto convincente, non tanto per il numero di WP che poteva spaventare (100/0,25 = 400, alla fine della pianificazione comunque si è arrivati a ca. 900 WP) ma per il fatto che il criterio di determinazione era legato agli importi e non alla tipologia e/o alla natura delle lavorazioni. Nell appalto, infatti, sono presenti lavorazioni omogenee e ripetitive di grosso importo (p.es. fondazioni su pali micropali e diaframmi) insieme a lavorazioni uniche di grosso importo ma fondamentali ed indivisibili (p.es. gruppi elettrogeni). Inoltre venivano chiesti gli indici di controllo CPI (Cost Performance Index) e SPI (Schedule Performance Index): in particolare il primo era applicabile ma di scarso interesse poiché sempre uguale a 1. Infatti trattandosi di commessa pubblica appaltata a forfait, secondo le norme vigenti sui LL.PP. (legge Merloni e regolamenti correlati), l importo non può aumentare, a meno di un contratto integrativo (perizia) con conseguente nuova baseline. Nel nostro caso infatti gli importi da tenere sotto controllo non sono i costi dell impresa - che teoricamente possono lievitare senza limite ma l importo forfetario contrattuale, che in assenza di varianti è stabilito fisso e invariabile. Conseguentemente con l applicazione della tecnica d Earned Value, essendo ACWP = BCWP, si aveva sempre CPI = 1; manteneva invece valore la valutazione dell indice SPI dato dal Pag. 2 di 6

3 rapporto tra BCWS e BCWP = ACWP quale indicazione della performance temporale della commessa. Queste precisazioni iniziali, oltre una serie di modifiche ed assestamenti, hanno portato alla redazione di uno specifico capitolo sul Piano di Qualità Generale, per il coordinamento dell ATI e della Consortile nello sviluppo, redazione e presentazione all Amministrazione appaltante del programma di pianificazione generale. La wbs Chiariti i dubbi d impostazione abbiamo cominciato a lavorare sulla struttura della WBS. A riguardo le linee guida non specificavano come dovesse essere. La WBS venne definita e raffinata per passi successivi studiando il progetto così da scomporlo in porzioni minori, correlate al computo metrico estimativo e in relazione alla logica di costruzione. Esisteva inoltre nel CSA una tabella, denominata tabella B, che raggruppava lavorazioni omogenee al fine di evidenziare la loro percentuale sul forfait contrattuale e calcolare gli importi dei SAL (Stato Avanzamento Lavori). Le lavorazioni omogenee di cui alla tabella B del Capitolato Speciale d Appalto sono state associate alle opere principali, individuate dal progetto, creando la seguente WBS (vedi allegato wbs_ati, pagina successiva): 1 livello: che identifica le "opere principali" in linea di massima coincidenti con i diversi edifici del complesso ( 5 mini cantieri). 2 livello: che identifica le principali opere o macrolavorazioni (Opere Civili, Impianti Termofluidici, Elettrici, Correnti deboli, Antintrusione) 3 livello: che identifica le diverse "categorie di lavorazione", ca. 70 in tutto - di cui 20 per le opere civili (tralasciando le sub categorie civili che portavano a 60) 4 livello: che identifica le attività elementari o WP (Work Package), a cui è assegnato un codice WBS, una durata, delle risorse e il relativo importo. Ogni WP è composto da lavorazioni omogenee desunte dal computo metrico progettuale associato all'elenco prezzi d'offerta. Tali lavorazioni, elaborate con software dedicato per la contabilità (Primus System), e strutturate come la WBS di Project, forniscono la valorizzazione (Importo) di ciascun attività. Ma fino a che punto spingerci nella scomposizione del progetto? E quante attività (WP) sarebbero uscite? Eh sì perché questa era la domanda che assillava tutti, quante attività pianificare, quanti legami creare, quante attività da gestire in fase d avanzamento? La necessità di dettagliare ulteriormente le attività elementari fu lasciata a discrezione dei singoli responsabili del lavoro, abbandonando il criterio di determinazione legato all importo (0,25%), finalizzando al principio dell'efficacia e dell'efficienza dello strumento di controllo. E così mentre tutti erano lì a fare conti (le stime oscillavano tra 400 e 2000 attività in tutta l ATI), un dubbio intanto mi assaliva: il programma Project ce l avrebbe fatta a gestire tutte queste voci? e soprattutto i computer a disposizione ce l avrebbero fatta ad elaborare i dati per la curva ad "S" o ci voleva il computer della NASA? Occorreva un consulente, qualcuno con una certa pratica che potesse rispondere ai nostri dubbi. Trovammo una Società di consulenza che rispose ai nostri quesiti e ci supportò nella fase di impostazione. Ok tutti al lavoro Terminata la fase di definizione e impostazione iniziale si passò alla fase operativa, dove con tutto il progetto ben chiaro in mente e con matite colorate e pennarelli in mano, si disegnò Pag. 3 di 6

4

5 su fogli formato A3, debitamente uniti fra loro sia in orizzontale che verticale (fino alla creazione di bei lenzuoloni), le logiche di progetto, o meglio di costruzione, indicando chiaramente le opere (WP), gli importi correlati, i legami logici e le durate presunte (vedi Schema logico WBS 3, pagina successiva). Durante la fase di schedulazione, cominciammo ad inserire i dati in Project, ponendoci le prime domande su come dovesse essere organizzata l architettura dei files, e sulla necessità di definire delle impostazioni generali che fossero comuni anche alle associate, visto anche il manifestarsi di alcuni problemi software, che andavano risolti. Prima di tutto si decise di lavorare tutti sulla versione 2003 di Project; in seguito si predispose un documento con allegato file modello contenente le informazioni di settaggio da applicare: Calendari, Campi personalizzati per il codice wbs, Visualizzazioni personalizzate legate alla gerarchia della wbs, Raggruppamenti per competenze afferenti alle diverse imprese ATI (OBS), e afferenti alle categorie contabili (tabella B) per la produzione dei SAL. Questo lavoro, di non poco impegno, ha creato la base della programmazione che, una volta immessa su file MS-Project, corretta ed affinata, ha permesso l emissione della prima baseline relativamente alle sole opere civili. Questa stampata su carta in formato leggibile aveva le seguenti dimensioni: mt.1,20 x 2,40 d altezza!! Terminato questo step si è passata la mano alle due imprese impiantistiche, le quali partendo dalle sequenze logiche da noi definite hanno proseguito in ugual modo con le lavorazioni di propria competenza. Intanto si continuava a lavorare, finalmente con un po più di presenza dell ATI, sul lato software discutendo se fosse meglio creare un unico file, o un file per ogni gruppo d edifici (livello di WBS 1), oppure ancora un file per ogni gruppo di edifici per ogni impresa dell ATI. Il fatto è che si cominciava a porre il problema di chi dovesse operare materialmente su Project, vista anche la difficoltà inerente la dislocazione geografica delle varie sedi dei membri dell ATI oltre che all ubicazione del cantiere (Nord e Centro Italia). Ancora in questa fase quanto si stava facendo non era considerato così importante da dover organizzare un PM office sul cantiere e quindi si pensò di creare un sistema di gestione dei files che fosse leggero. Il multi-file E così mi tornò in mente la possibilità di gestire il tutto con il sistema del multiprogetto, la cosa fu ben accolta da tutti soprattutto per la possibilità di lavorare ognuno sulla propria postazione e scambiarsi i file via mail; inoltre non conoscendo le capacità degli operatori delle associate, ciò mi dava una certa dose di sicurezza visto che se ognuno lavorava sul proprio file si evitavano danni a terzi. Così ognuno ha lavorato sul proprio file, con i settaggi convenuti secondo la seguente architettura: per ogni elemento di WBS la programmazione è organizzata su cinque file base, uno per gruppo di fabbricati (livello 1 di WBS) per ogni impresa associata (civili, termomeccanici, elettrici), così da avere 5 x 3 = 15 file base, riuniti in un file generale (multifile). L idea, poco sperimentata creò subito qualche difficoltà. La prima fu legata alla gestione delle versioni dei files, che venivano fuori man mano che si affinava la pianificazione. Per eliminare il problema che i file collegati nel multiprogetto non Pag. 4 di 6

6 < 3S'ta9 T= 1-3,* kn,,*vt '7'z/e1 1,''a h r-/ \, -"- 4 f - l ' I )t '! /'u'''".$t. I -,y ' rlr I t't'?a3 T. )S e s2'44e -r= 6c Aot l..ffit é lo',z6 rr,,/z 1r..,-,%?N-c,'rl- - aè't, t 2.3f J3 (.r8c.tzt T.,,{sl j I zf '."'-1 :*F;JaF" I én*'76,'î-r Gc ì- \é,p ': f :d"' r-' es ),l@1.u.2..' l+tr.lcq*- f'l 44. s'sr" T. z. Ct é z.<'a9z r. k -- \ C,u.t; 'J;.;,- ;,3,,s6 ' "r"^'.;:::,',l.ot.s I bsrr'., l.o8't F"IAffi;C@ I e 3o'szo î- 5 '--- l.laa t y'lc.or \ EFl. varsfl e 64'S4s î. tbot-,,' \ ffi,"- k, 6 )ilífu- T. bsr. $ /ì fi,(' I A.ta. I A.tz.1 ( 78'zs9 T- uz, o,t \.':3=- 4M.rèG= 66's'L f= /<ty ze6.4o\ e8'oo7 T. log, f-. uw A. t) A. t') 8z'ets f= 6 S3S Ts.G/u l'f," A.IL qr trrij 4,,8 o?. \n?rrn:fzy I 4 :6 e z T. 4SV (N* Lf o-*zl., w 4 -r=?s (Ìf_t" *Ì.wn^., L*w) rs -fq./2 9 ' î.f-,,th-,r,..- E^fr-', JU

7 potevano essere rinominati, si decise di organizzare i file in sottocartelle (una per wbs) contenute in una cartella generale da rinominare ad ogni revisione. Un secondo problema riguardava invece l apposizione dei legami tra attività gestite dalle diverse imprese, non tanto per il fatto che fossero su diversi file, quanto per il fatto che comportavano, specialmente i predecessori, modifiche alla pianificazione fatta dagli altri interlocutori. La soluzione fu quella di mettere come interlegami a distanza solo i successori, in modo da non toccare la pianificazione degli altri componenti dell ATI, e poi insieme, ossia in presenza degli operatori e dei Direttori Tecnici (al termine di una riunione fiume che è durata dalla mattina alla sera), affinata la pianificazione si arrivò a definire la baseline (erano già passati circa 6 mesi dalla consegna dei lavori). (vedi multiprog-wbs 2, pagina successiva) La baseline costituisce unicamente lo standard rispetto al quale misurare in avanzamento la performance in termini di tempo e di costo realizzato (valorizzazione) alla data di stato. L avanzamento - Il primo report mensile Anche per la fase d avanzamento è stato necessario definire regole e modalità operative; anch esse rese esplicite sempre attraverso il documento di pianificazione della Qualità (PdQ). La verifica dell avanzamento è stata fissata, come richiesto, mensilmente con data stato (timenow) all'ultimo giorno lavorativo del mese, con lo scopo di fornire una fotografia dell andamento nel mese della commessa. Ogni tre mesi nell intento di valutare lo stato della programmazione si potevano apportare eventuali azioni correttive e riformulare, se nel caso, una nuova baseline. L avanzamento d ogni singolo WP è stato espresso in termini di percentuale progressiva di prodotto fisico realizzato, ottenuto come rapporto tra il valore delle opere effettivamente eseguite e il valore totale dell attività alla data di verifica (con il supporto di Primus). I parametri oggetto del controllo sono quindi i tempi e gli importi prodotti espressi in percentuale rispetto al valore delle singole attività e risorse. Per ogni WP sono rilevati al timenow: Data d inizio effettiva dell attività La % di completamento fisica La durata rimanente Tutto ciò, oltre al controllo, deve essere utilizzato per l'emissione degli Stati Avanzamento Lavori. Dal punto di vista operativo, nell ipotesi di non far pervenire ad una figura di riferimento i dati d avanzamento ma di imputare ciascuna componente dell ATI (a turno, per le relative competenze) il proprio avanzamento, sono stati stabiliti i tempi tecnici d elaborazione dei dati, lasciando al Responsabile Qualità il compito di assemblare il tutto per la redazione del report da presentare alla Direzione Lavori. Il report è strutturato con una parte descrittiva organizzata per wbs che descrive quanto fatto nel mese precedente e cosa si prevede di fare nell immediato futuro (se conforme o no a quanto pianificato), ed una seconda parte che riporta i seguenti dati e indicatori: BCWS, BCWP, SPI, % avanzamento fisica e temporale, curve ad S. (vedi allegato Pages from report Febbraio 05, pagine successive) Un anno di reportistica, una pesante sospensione parziale, si prospetta una ripresa a breve con necessità di riprogrammazione (nuova baseline). Pag. 5 di 6

8

9 Avanzamento al 28 Febbraio 2005 III.2. CURVA AD S (di dettaglio) RELATIVA AI SOLI EDIFICI (WBS 3) SPI BCWS Baseline BCWP Time now mar-04 apr-04 mag-04 giu-04 lug-04 ago-04 set-04 ott-04 nov-04 dic-04 gen-05 feb-05 mar-04 apr-04 mag-04 giu-04 lug-04 ago-04 set-04 ott-04 nov-04 dic-04 gen-05 feb-05 SPI 0,23 0,64 0,91 0,83 0,86 0,71 0,84 0,67 0,85 0,85 0,91 0,98 BCWS Baseline BCWP Pagina 20 di 21

10 Avanzamento al 28 Febbraio 2005 III.3 GANTT AVANZAMENTO Pagina 21 di 21

11 Conclusioni Alla data odierna il nostro impegno si è concluso in quanto, terminata la fase di preparazione dello strumento, e della pianificazione, il tutto è stato consegnato in cantiere affinché possa essere gestito direttamente dal sito operativo. Un supporto costante tipo help-desk telefonico è fornito all operatore (disgraziato) di turno al cantiere per la gestione del multifile o per la redazione della nuova baseline post ripresa lavori. Siamo soddisfatti del lavoro effettuato in termini di crescita professionale, ben consapevoli che è solo un primo gradino nella direzione di un controllo commessa vero e proprio, ma ci risulta comunque che questo è stato, a livello nazionale, un primo esempio d applicazione delle tecniche di controllo commessa di PM in un opera pubblica con il software MS Project sulla base di una specifica richiesta contrattuale. Recentemente un altra amministrazione, per un appalto di minore valore economico, ha richiesto sempre nell ambito del proprio sistema di gestione di qualità, la programmazione ed il monitoraggio della commessa con strumenti informatici: siamo sicuri che, anche se Excel continua ad imperare per la sua semplicità a scapito della scarsa efficienza nella gestione delle previsioni e/o variazioni, il futuro nella gestione delle opere pubbliche porterà all applicazione delle tecniche di controllo della commessa con software dedicati come avviene da molti anni per i progetti impiantistici. Non ultimo è d esempio il recente bando per i servizi di Project Management Consulting in relazione alle attività di progettazione definitiva ed esecutiva e realizzazione del Ponte sullo Stretto di Messina per un importo a base d asta di euro ,00, mentre nei lavori privati, è un chiaro esempio il Nuovo Polo Fieristico di Milano dove le imprese interessate alla costruzione hanno sviluppato un ufficio di management, supportato da software Primavera, composto di 170 persone che coordinano, ideano, pianificano, organizzano e fanno supervisione alle 300 imprese per totali lavoratori impegnati in cantiere. Queste realtà sono sicuramente di un ordine di grandezza superiore rispetto a quella in cui noi ci siamo trovati ma, come si dice, chi ben comincia Pag. 6 di 6

12 La Sanità e la gestione per progetti di: Massimo MARTINATI Marzo 2004 Introduzione La complessità dei progetti di sanità pubblica e le trasformazioni introdotte dai D.L. 502/92 e D.L. 517/93 relativamente alla gestione dei servizi sanitari, portano anche la sanità e i suoi interpreti ad un approccio verso il Project Management. L obiettivo dei decreti è infatti una maggiore efficienza della struttura sanitaria e una migliore qualità dei processi e dei risultati raggiunti. E così il Project Management, una disciplina nata per la gestione di progetti complessi in ambito bellico e impiantistico, ed oggi già utilizzata a livello internazionale nei più disparati progetti (dalle costruzioni pubbliche e private, alle opere civili e infrastrutturali, dai progetti di telecomunicazione all industria spaziale, dalla finanza all informatica ), si affaccia prepotentemente anche sullo scenario della sanità. E non poteva che essere così: l azienda sanitaria ha l obbligo di rispettare obiettivi istituzionali ed economici: da una parte la tutela della salute, dall altra l equilibrio economico. Obiettivi complessi, soggetti ad azioni contrastanti, spesso condizionati da un organizzazione che ha bisogno di un azione professionale, flessibile e di un graduale ma deciso cambiamento della propria cultura gestionale. Perché progetto? Ma può in sanità essere contemplato il concetto di progetto? Certamente! Tutto ciò che non è attività ripetitiva, che ha un tempo di esecuzione limitato, che ha un inizio e una fine, che ha come scopo la produzione di un risultato (un prodotto o un servizio), che ha bisogno di un organizzazione, di regole e di responsabilità bene quello può essere considerato un progetto. Alcuni esempi? L apertura di un nuovo laboratorio d analisi, un intervento per la valutazione di un rischio alimentare, un percorso formativo per l aggiornamento del personale, una campagna di vaccinazione, una ricerca scientifica. Consideriamo una campagna di vaccinazione in una ASL. Non si tratta di un attività ricorsiva bensì di un progetto: ha una unitarietà definita dal suo obiettivo (la copertura vaccinale) e dalla valutazione del raggiungimento dell obiettivo stesso. Il concetto di progetto quindi consente ai molti operatori o altri soggetti che, a qualche titolo, influenzano il raggiungimento dell obiettivo, di sentirsi e di essere parte di uno sforzo organizzato. Gli obiettivi del progetto I professionisti della sanità pubblica, hanno un grande obiettivo: ottenere il miglioramento della salute. Per raggiungere questo obiettivo è necessario che tutti gli addetti ai lavori si prodighino a dedicare le proprie capacità e la propria volontà a: - individuare i problemi di salute, - stabilire la prioritari fra tali problemi, - individuare e pianificare le azioni di sanità pubblica che possano migliorare il problema, - mettere in pratica tali azioni - verificarne gli effetti. E questi sono i passi necessari inalienabili per un progetto di sanità pubblica. Pag. 1 di 4

13 La pianificazione delle azioni con la previsione di tutte le entità ad esse correlate: risorse umane (ad esempio staff esperto) e fisiche (apparecchiature e mezzi), costi, qualità e rischi devono essere gestite in modo integrato seguendo procedure standardizzate. E da ciò nascono una serie di esigenze: Un organizzazione pronta e ricettiva alle esigenze di gestione dei progetti Un linguaggio comune Una leadership di progetto che fluidifichi i processi in un ottica integrata e correlata Un team di progetto composto da persone preparate (medici, tecnici, ) in grado di affrontare e gestire tutto il lavoro previsto Una definizione iniziale di obiettivi tangibili e misurabili per verificare l effettivo successo del progetto Un sistema informatico che possa gestire in modo centralizzato l insieme dei dati del progetto Un livello di comunicazione che permetta il flusso dell informazione di progetto attraverso tutti gli attori del progetto (compresa la cittadinanza o il gruppo di persone interessate al problema) Una flessibilità e dinamicità che permettano il raggiungimento degli obiettivi anche contro ostacoli insormontabili Una capacità aggregativa e di negoziazione da parte di tutte le persone coinvolte nel team di progetto Le cause di fallimento dei progetti La statistica medica individua le seguenti cause di fallimento nei progetti gestiti nelle Aziende Sanitarie Locali: Obiettivi non chiaramente definiti, non misurabili o irrealistici Interventi inefficaci o naive Risorse inadeguate Mancanza di un sistema informativo per la gestione e il controllo Sequenza e gerarchia delle attività non disegnate in modo adeguato Mancata assegnazione di compiti e responsabilità Progetti non decisi o non condivisi dal management aziendale Mancanza di un comitato promotore Team di progetto in cui mancano competenze necessarie Mancata individuazione o cattiva scelta della responsabilità del progetto Tale lista, espressa in altri termini è la stessa di statistiche relative a progetti di altri campi: dall ingegneria tradizionale alle costruzioni, dalla finanza all informatica. Il Project Management, una disciplina universale Il Project Management è una disciplina universale e come tale può aiutare la sanità ad affrontare i suoi progetti. Secondo uno dei più famosi guru del Project Management, Russel D. Archibald, un progetto è uno Sforzo complesso, comportante compiti interrelati eseguiti da varie organizzazioni, con obiettivi, schedulazioni e budget ben definiti. E allora le domande che ci si deve porre sono: è possibile immaginare un medico, o più genericamente un operatore sanitario, che sappia pianificare? sappia stilare un Project Charter o una WBS? sappia calcolare una curva di budget? sappia controllare le performance di progetto ed eseguire corrette stime a finire temporali ed economiche? Pag. 2 di 4

14 sappia individuare le milestone fondamentali del progetto? sappia misurare il successo finale del progetto Possiamo comunque sostenere che non bisogna essere esperti di Project Management per pensare che, anche in Sanità, di fronte ad un progetto le domande che sorgono spontanee sono: Come individuare e formalizzare gli obiettivi del progetto e come misurare il loro raggiungimento? Come definire i vincoli del progetto? Come definire il prodotto/servizio finale del progetto? Come definire i risultati da ottenere e quali criteri adottare per verificare il loro effettivo raggiungimento? Quali sono le persone, le organizzazioni e le comunità interessate al buon esito finale del progetto (stakeholders)? e quali sono le loro aspettative? Come descrivere il progetto in modo sintetico? Come definire i ruoli e le responsabilità nel progetto? Come definire il piano temporale del progetto? Come preparare il piano economico-finanziario del progetto? Come definire compiti e sotto-compiti e come assegnarli a ciascun membro del team di progetto? Come definire ed imporre le date di scadenza ai responsabili? Come impostare un piano per l individuazione dei rischi e delle opportunità? Come impostare un piano per la comunicazione verso tutti gli interessati? Come controllare il progetto durante la sua evoluzione? Come aggiustare il tiro nel momento in cui, in seguito al controllo sul progetto, ci si accorge dei primi scostamenti (di tempo, di costi, di prestazione, di qualità)? Come eseguire delle stime a finire (di tempi, di costi) affidabili? Come riuscire a valutare il raggiungimento degli obiettivi e misurare il successo del progetto? Gli standard del Project Management A tutte queste domande risponde la teoria del Project Management. Esiste uno standard de-facto della disciplina: è il PMBOK - Project Management Body of Knowledge anche detto PMBOK, edito dal PMI, il Project Management Institute statunitense, che, raccogliendo esperienze maturate a livello internazionale nei campi progettuali più disparati, descrive la metodologia usando un approccio per processi. Vengono individuati 39 processi, distribuiti in 9 aree di conoscenza (Knowledge Areas) e 5 Fasi (Process Groups). Le aree di conoscenza rappresentano le tematiche da affrontare nel progetto e sono: Integrazione, Contenuto, Tempi, Costi, Risorse Umane, Qualità, Comunicazione, Rischi, Approvvigionamenti. Le fasi sono: Concezione, Pianificazione, Esecuzione, Controllo e Chiusura. Un buon approccio per iniziare: la formazione sul Project Management La formazione è l arma migliore per un efficace avvio al Project Management: un corso introduttivo all approccio metodologico, seguito da un esercitazione pratica. L esercitazione si realizza intorno ad un tavolo dove si simulano ruoli e situazioni. Una lavagna a fogli mobili è l unico strumento necessario per la prima fase dell esercitazione. Il docente affronta la formazione usando il metodo del Brainstorming: massima apertura al pensiero libero di tutti. Il risultato èl individuazione di obiettivi, vincoli, difficoltà del progetto oggetto dell esercitazione. Carta e penna per proseguire: discussione, comunicazione, scambio di idee e processi decisionali simulati. Pag. 3 di 4

15 Quando lo scenario è definito, interviene il software. Lo strumento informatico deve essere semplice ed efficace. Non si pretenda un corso approfondito sul software, c è sempre tempo per imparare! Il docente simula un piccolo progetto usando il software, proiettando su schermo l immagine del proprio PC portatile semplificando al massimo l approccio informatico per i discenti. E poi tutto concentrato sui risultati enfatizzando l importanza del reticolo di progetto, sottolineando il Gantt come risultato della pianificazione dei tempi del progetto; e poi un enfasi particolare sui concetti di criticità di progetto, sull utilizzo e sull ottimizzazione delle risorse e sull importanza strategica di poter stabilire in anticipo un budget temporizzato di progetto; risultati, simulazioni, identificazione di strade alternative, fino alla definizione della baseline di progetto. Nel corso gli argomenti da trattare non sono soltanto tecnici ma anche relazionali e organizzativi: sulla comunicazione ( non tanto uno stile ma una gestione dell informazione completa ed efficace ), sulla negoziazione ( il lavoro è una continua ricerca di un accordo tra le parti con l obiettivo di una reciproca soddisfazione ), sul sapere come costruire e come mantenere un team, ( si deve imparare ad essere leader più che capo, a convincere ed ad ottenere il consenso più che sul comandare ) sulla figura del Project Management visto come agevolatore e coordinatore, ( il Project Manager deve saper operare come risolutore di conflitti e problemi più che come tecnico e massimo esperto dell argomento trattato ). Pag. 4 di 4

16 PROGETTO A id nome durata predecessore legenda 1 preparare i disegni 5-2 identificare i fornitori 6 - id ES EF 3 sviluppare i progetti 4 1 t LS LF 4 selezionare la vista preparare richista dei permessi ottenere i permessi costruire 14 4,5 8 formalizzare i contratti 12 2,3 9 traslocare 2 7,8 settimane assumere che tutte le relazioni siano di tipo FINISH-START s=start durata nr. attività calendario data massima entro la quale può finire l'attività data di partenza la più tardi data di fine al più presto. Il minor tempo entro la quale l'attività può finire data della partenza al più presto. Il minor tempo entro la quale l'attività può iniziare ES LS EF LS S completate il reticolo qui accennato e determinate il percorso critico

17 PROGETTO B id attivita' durata predecessore 1 A 5-2 B C D E F G 14 5,4 8 H 12 3,6 9 I 2 7,8 settimane assumere che tutte le relazioni siano di tipo FINISH-START

18 H-START