Project management

Da Wikipedia, l'enciclopedia libera.

Elenco in continuo aggiornamentoQuesta pagina è stata massivamente aggiornata di recente e si trova ancora in una fase di ristrutturazione approfondita, vedere pagina di discussione.
« Se qualcosa può andare storto, lo farà. »

Con l'espressione inglese project management (Gestione di Progetto) si intende l'insieme di attività volte alla realizzazione degli scopi/obiettivi di un progetto. Un progetto è uno sforzo delimitato nel tempo (con una data di partenza e una di completamento) diretto a creare dei prodotti e/o servizi e/o risultati specifici che comportano dei benefici o del valore aggiunto al committente.

Secondo il PMBOK[1] (pubblicato dal PMI) il project management è l'applicazione di conoscenze, attitudini, tecniche e strumenti alle attività di un progetto al fine di conseguirne gli obiettivi.

La collocazione in un arco temporale finito distinguono il progetto dai processi operativi di un'azienda (le cosiddette attività di routine) che sono invece permanenti o semi-permanenti e sono diretti a produrre in modo ripetitivo lo stesso prodotto o servizio. Proprio la diversa natura di queste attività richiede lo sviluppo di filosofie, attitudini e approcci diversi per la loro gestione.

La sfida principale del project management è quella di raggiungere gli obiettivi del progetto restando all'interno del perimetro costituito dai classici vincoli determinati dal contesto del committente, solitamente il costo, il tempo e lo scopo (nel senso anche della qualità). La sfida secondaria - ma non meno ambiziosa - è quella di ottimizzare l'allocazione delle risorse e integrare gli input necessari a raggiungere gli obiettivi definiti. Queste sfide infine devono essere portate avanti risolvendo i problemi e mitigando i rischi che ciascun progetto, in misura diversa, troverà comunque lungo la sua strada (con un po' di ironia si potrebbe considerare il project management come la risposta scientifica alla Legge di Murphy).

Indice

[modifica] Cenni storici sul project management

particolare della colonna Traiana, Roma
particolare della colonna Traiana, Roma

Fondamenti di una cultura di project management si sono sviluppati fin da tempi remoti presso diverse civiltà anche geograficamente distanti e con labili legami tra loro. Le Piramidi egizie (alla piramide di Cheope lavorarono 100.000 uomini per 20 anni), il Colosseo (eretto in 10 anni) e i grandi acquedotti romani, rimangono testimonianze concrete di progetti che non avrebbero potuto svilupparsi in assenza di una buona cultura nel campo del project management. La capacità di gestire grandi progetti venne meno nel corso della civiltà occidentale sia per il disfacimento del sistema imperiale romano che comportò la dispersione delle capacità ingegneristiche (presenti in particolare nel genio militare delle legioni) e sia per il superamento dello schiavismo che rendeva più difficilmente realizzabili grandi progetti per via dell'aumento dei costi causato dalla progressiva diminuzione della manodopera gratuita (facendo collassare il classico triangolo dei vincoli del project management (vedere più avanti). A riprova di come, già in tempi antichi, l'idea di gestire risorse complesse in ottica progettuale fosse diffusa e in qualche modo strutturata, è utile citare il De bello gallico: nei paragrafi XVII, XVIII e XIX del libro IV Giulio Cesare descrive i dettagli tecnici ed organizzativi (tempi, obiettivi, materiali utilizzati, gestione delle risorse) della costruzione di un ponte sul Reno nel corso della quinta campagna di Gallia[2]. Poche righe, che sorprendentemente contengono elementi fondamentali comuni ad un moderno piano di progetto (testo e traduzione in linea libro IV De Bello Gallico).

In epoca moderna il project management si è sviluppato a partire da diversi campi di applicazione incluso il settore delle costruzioni, l'ingegneria industriale, la difesa (logistica e organica militare e, in tempi più recenti, la realizzazione di software.

Uno dei contributi più precoci e più importanti venne dato dall'ingegnere statunitense Henry Gantt, che introdusse nei primi anni del XX secolo una tecnica di pianificazione ricordata ancora oggi con il suo nome (Diagramma di Gantt) tuttora parte essenziale di ogni attività di pianificazione, a suo tempo sviluppata da Gantt per supportare l'introduzione delle Teorie di Taylor [3] di cui fu importante collaboratore. Sulla base del suo lavoro sono nati successivamente altri fondamentali concetti ampiamente usati nelle prassi di project Management, come quello di allocazione delle risorse e quello di Work Breakdown Structure (WBS), utilizzato per rappresentare la struttura delle attività di un progetto.

Nel corso della II Guerra mondiale e nel periodo successivo presero luce i primi veri e propri progetti strutturati secondo una concezione moderna del Project Management. Il Progetto Manhattan, lanciato dal governo degli U.S.A. con l'obiettivo di realizzare per primo armi nucleari in anticipo rispetto agli sforzi in corso da parte del governo nazista, è riconoscibile come il primo grande progetto organizzato secondo un modello scientificamente somigliante ai grandi progetti attuali. Il fisico Robert Oppenheimer che ne venne nominato direttore nel 1942, sfruttando la sua abilità organizzativa (nonché ovviamente la sua profonda conoscenza teorica degli argomenti trattati) riuscì a dare una forma organizzativa e una profonda motivazione a tutto il team di progetto (vi lavorarono per diversi anni circa 700 persone). Oltre ai diagrammi di Gantt e altre tecniche e strumenti informali, negli anni successivi al 1950 vennero sviluppate altre importanti tecniche: il PERT (Program Evaluation and Review Technique) sviluppato dalla società Booz Allen Hamilton per il progetto di sviluppo del missile Polaris da parte della Marina statunitense (in collaborazione con la Lockheed Corporation) e il CPM (Critical Path Method) sviluppato congiuntamente da DuPont Corporation and Remington Rand Corporation per gestire i progetti di manutenzione degli impianti industriali. Negli anni successivi queste tecniche si diffusero largamente e velocemente nel mondo industriale.

Il Project Management moderno è una cultura che viene soprattutto dall'esperienza derivante dalla gestione di progetti complessi. Tra i primi a sottolineare questo approccio sia come Project Manager che come consulente delle maggiori Società, Imprese e Committenti è stato Russel D. Archibald[1].

L'ingegneria gestionale si evolse e, grazie al lavoro pionieristico di Hans Lang e altri, vennero sviluppate tecnologie per la stima dei costi di progetto e per la gestione dei costi. Nel 1956 venne fondata la “American Association of Cost Engineers” (ora AACE International - “Association for the Advancement of Cost Engineering”) da parte dei primi cultori del project management e delle prassi correlate (pianificazione, stima dei costi, controllo di progetto (controllo costi/pianificazione). La AACE ha continuto la sua attività di sviluppo degli standard tecnologici e nel 2006 ha rilasciato il "Total Cost Management Framework" (versione pdf del libro) sviluppato da John Hollman[4].

Nel 1969 venne fondato il Project Management Institute (PMI) con l'obiettivo di diffondere e rafforzare le prassi di project management attraverso l'affermazione di uno standard, sulla base della convinzione che i diversi campi di applicazione del project management., dall'Edilizia alla Ingegneria del software avessero una larga base comune nelle tecnologie e nelle metodologie di gestione dei progetti. Nel 1981 il Comitato Direttivo del PMI autorizzò lo sviluppo della Guida al "Project Management Body of Knowledge" (altrimenti noto come PMBOK), contenente una guida completa e sintetica degli standard e delle linee guida indispensabili per le prassi di project management. L'International Project Management Association (IPMA), fondata in Europa nel 1967, ha intrapreso una direzione simile istituendo l'IPMA Competence Baseline (ICB). Entrambe le organizzazioni stanno partecipando ora allo sviluppo di uno standard ISO per il project management.

[modifica] Il ruolo del Project Manager

La gestione di un progetto è solitamente demandata a un project manager, che a volte partecipa direttamente alle attività che lo compongono, ma principalmente si focalizza nel coordinamento e nel controllo delle varie componenti e dei diversi attori coinvolti con l'obiettivo di minimizzare la probabilità di insuccesso.

Il project manager può essere un rappresentante del committente o della organizzazione/società incaricata di realizzare il progetto (in diversi casi ne esiste uno per parte, ciascuno con responsabilità di progetto verso la propria parte). Il suo obiettivo essenziale è quello di assicurare il rispetto dei costi, dei tempi e della qualità concordati e soprattutto il raggiungimento della soddisfazione del committente.

A prescindere dal campo di realizzazione del progetto, un bravo project manager deve essere abile a interpretare gli obiettivi reali del progetto dal suo inizio sino alla fine, assicurandosi che la visione del committente venga realizzata secondo le sue aspettative.

Al completamento del progetto di solito il prodotto o servizio realizzato vengono presi in carico da una figura operativa diversa, tipicamente il Product Manager o il Service Manager.

[modifica] Concetti e tecniche fondamentali

Premesso che sia a livello internazionale che in Italia circola una quantità notevole di metodologie e di tecniche correlate alla teoria e alla prassi del Project Management, esistono dei concetti e delle tecniche fondamentali ricorrenti nella maggior parte degli approcci esistenti.

[modifica] Stima di un Progetto

La stima dimensionale di un progetto è una delle prime attività cruciali da cui dipende il successo del progetto e la sorte del project manager. Esistono molteplici tecniche per quantificare i tempi e i costi necessari a realizzare un progetto o, se si vuole, la sua durata. Nei progetti complessi, al fine di rendere il più possibile oggettiva e affidabile la stima, è fortemente raccomandabile produrre almeno due stime indipendenti possibilmente prodotte con tecniche diverse, provvedendo poi a effettuare una riconciliazione che produca una convergenza. La durata del progetto naturalmente dipende dalla struttura della pianificazione adottata, in particolare dal grado di parallelismo tra le attività che compongono il progetto, parallelismo a sua volta dipendente dal numero di risorse impiegate. La tecnica più semplice è quella di:

  • identificare le attività elementari (task) necessari a produrre i deliverable associati a ciascun elemento della Work Breakdown Structure (WBS) e le loro dipendenze;
  • rappresentare la scomposizione dei task in un diagramma di Gantt, mettendo in evidenza le interrelazioni tra le diversi elementi del progetto (macro-attività o work packages, task e output) in una scala temporale;
  • valorizzare la quantità di lavoro necessaria (il cosiddetto effort) a completare ciascun task, determinando la tipologia di risorse (umane e non) necessarie alla loro realizzazione;
  • calcolare i tempi di realizzazione di ciascun task in base al numero di risorse a loro assegnate;
  • determinare i costi del personale per la realizzazione di ciascun task moltiplicando la quantità di lavoro (effort) stimato per i costi medi della tipologie di risorse individuate; aggiungere i costi degli altri materiali e/o servizi necessari;
  • determinare il percorso critico in base alle dipendenze esistenti dentro la WBS;
  • calcolare il tempo totale (il cosiddetto elapsed) sommando i tempi di tutti i task che si trovano all'interno del percorso critico;
  • determinare il costo totale sommando i costi (personale + materiali + servizi) di tutti i task.

Questo procedimento è reso molto più semplice dagli strumenti di controllo della pianificazione disponibili, che consentono di rappresentare la struttura dei task associati alla WBS, visualizzare il diagramma di Gantt e cercare il miglior assetto del piano che ottimizzi l'utilizzo delle risorse e minimizzi i rischi presenti nella pianificazione, con il vincolo di restare all'interno del tempo di realizzazione richiesto dal committente.

Triangolo dei vincoli di progetto
Triangolo dei vincoli di progetto

[modifica] Il Triangolo dei vincoli di progetto

Al pari di ogni altro sforzo umano, anche i progetti vengono realizzati e rilasciati in un contesto sottoposto a determinati vincoli. Tradizionalmente questi vincoli vengono elencati come scopo/qualità, tempo e costo/risorse. Spesso viene usata l'immagine del Triangolo del Project Management (dove ogni lato rappresenta un vincolo), per rappresentare la loro correlazione: ciascun vincolo non può essere cambiato senza impattare sugli altri due. Un ulteriore variante di questo sistema dei vincoli separa la 'qualità' (o le 'prestazioni') dallo 'scopo', trasformandolo in un tetraedro con quattro vincoli correlati tra loro.

Il vincolo tempo indica la quantità di tempo disponibile per completare il progetto. Il vincolo costo/risorse rappresenta il budget disponibile per il progetto e al tempo stesso l'insieme delle risorse a disposizione del progetto (è evidente la correlazione lineare tra costo e risorse assegnate). Il vincolo scopo/qualità rappresenta quanto deve essere fatto per conseguire i risultati attesi dal progetto sia in termini di requisiti che di criteri di qualità/performance. Questi tre vincoli sono strettamente correlati: incrementare lo scopo tipicamente significa aumentare i tempi e i costi/risorse del progetto; dei tempi più corti possono richiedere dei costi più alti (risorse più grandi) e/o uno scopo più ristretto; un budget più risicato (meno risorse) può implicare dei tempi più lunghi e/o una riduzione dello scopo.

E' proprio la teoria del project management che fornisce gli strumenti e le tecniche che consentono al team di progetto di organizzare il proprio lavoro all'interno di questo sistema di vincoli.

Una rappresentazione alternativa dei vincoli consiste nel scegliere come variabili il costo, il tempo e le risorse umane. Se occorre finire un progetto in un tempo minore si possono aumentare le persone assegnate, il che aumenterà anche i costi per il probabile aumento di inefficienza nella allocazione delle risorse.

[modifica] Tempo

Le dipendenze tra i task interni e quelle dagli eventi esterni (es: la fornitura di prodotti o materiali che servono da input a determinati task) possono impattare sulla durata del progetto, introducendo spesso nei progetti reali la necessità di rivedere la pianificazione precedente. Un'altro classico fattore che impatta sui tempi riguarda la disponibilità delle risorse, piuttosto che l'assunzione (in fase di stima) di produttività/performance significativamente diverse da quella effettiva del team reale. Nella maggior parte dei progetti medio-grandi la misurazione dell'avanzamento, il controllo e l'adattamento del piano fanno parte delle attività periodiche di routine del project manager. Il Tempo non è considerato un costo ne una risorsa dato che il project manager non può controllare la velocità con cui trascorre; questo ne fa la differenza fondamentale con gli altri vincoli.

[modifica] Costo/Risorse

I costi necessari a sviluppare un progetto dipendono principalmente da diverse variabili: quantità e qualità delle risorse assegnate, costi del lavoro, costi dei materiali e/o dei servizi acquistati esternamente, gestione dei rischi (es: quanto viene speso/accantonato per mitigare i principali rischi), costi di controllo e amministrazione del progetto, impianti e strumenti a disposizione, rivalutazione dei costi (in caso di progetti pluriennali), costi indiretti.

[modifica] Scopo/Qualità

Lo scopo del progetto, ossia i risultati che devono essere prodotti, è fortemente correlato alla qualità e/o alle performance di quanto deve essere rilasciato. La qualità prodotta rappresenta l'accuratezza con cui i risultati conseguiti sono aderenti ai requisiti concordati, nel senso che soddisfano completamente i requisiti richiesti ed eventualmente aggiungono ulteriore valore per il committente. Per garantire una aderenza soddisfacente (zero sorprese) è necessario investire uno sforzo maggiore nella fase di ingaggio del progetto arrivando a definire con la maggior precisione possibile i requisiti e i criteri di accettazione che dovranno essere utilizzati per valutare i risultati prodotti (caratteristiche e performance).

[modifica] Articolazione delle attività di Project Management

Il Project management si articola in diversi tipi di attività:

  1. Analisi e definizione degli Obiettivi e degli eventi che li pilotano (i cosidetti compelling events)
  2. Pianificazione del lavoro in funzione degli obiettivi
  3. Individuazione e controllo dei Rischi (Risk Management)
  4. Valutazione e pianificazione delle risorse necessarie
  5. Allocazione/disallocazione delle risorse
  6. Organizzazione del lavoro e dei processi
  7. Acquisizione delle risorse umane e dei materiali necessari
  8. Assegnazione dei task
  9. Direzione e coordinamento delle attività
  10. Misurazione dell'avanzamento del progetto (Metriche di progetto)
  11. Analisi dei risultati ottenuti sulla base dei fatti e delle informazioni raccolte
  12. Definizione e controllo delle azioni correttive necessarie e rimettere il progetto in assetto con gli obiettivi
  13. (Ri)previsioni tempi, costi e altri indicatori del progetto
  14. Gestione della qualità
  15. Gestione e soluzione dei problemi
  16. Assicurazione della qualità (riduzione al minimo delle non conformità)
  17. Identificazione, gestione e controllo delle variazioni di scopo (change request o change control)
  18. Chiusura del progetto e disallocazione delle risorse
  19. Gestione della accettazione dei risultati prodotti
  20. Comunicazione dei risultati ottenuti ai committenti

[modifica] Obiettivi del Progetto

Gli obiettivi del progetto definiscono i risultati da raggiungere alla fine del progetto, risultati necessari per il conseguimento dei benefici attesi dai committenti. Gli obiettivi possono essere formulati nel modo migliore verificandone l'aderenza ai requisiti indicati dall'acronimo SMART (traducibile dall'inglese come 'intelligente', 'furbo'):

  • Specifico (ossia ben definito e chiaramente comprensibile)
  • Misurabile (o per lo meno valutabile) nella sua raggiungibilità
  • Accettabile (nel senso di 'considerato raggiungibile' dalle persone coinvolte nel progetto)
  • Rilevante (ossia importante per il committente, al punto di affidare un mandato chiaro e forte a coloro che hanno responsabilità nel progetto)
  • Tempificato (nel senso che deve essere conseguito entro una data certa)

La misurazione (o valutazione) del raggiungimento di un obiettivo può/deve essere accertata alla fine del progetto. Tuttavia una continua vigilanza attiva sul progresso verso ciascun obiettivo dovrebbe essere monitorata e valutata periodicamente nel corso del progetto.

[modifica] Deliverable dell'attività di Project Management

I documenti che seguono servono a chiarire gli obiettivi e i deliverable. Servono inoltre ad allineare le aspettative degli sponsor, dei clienti e del team di progetto. A volte l'insieme di questi documenti viene indicato come Project Management Plan. I documenti di questa lista indicati in italiano riportano comunque a fianco il corrispondente nome (o i nomi) in inglese per facilitare i riferimenti a oggetti ben conosciuti nell'ambito professionale e nella letteratura tecnica:

A seconda degli approccio utilizzato e della complessità del progetto questa lista può essere più snella o anche più articolata, comprendendo per esempio anche documenti del tipo:

Altri deliverable di project management specificamente legati alle attività di controllo del progetto e sviluppati durante il suo corso sono:

Tutti questi documenti sono normalmente sviluppati e manutenuti in un ambiente condiviso (di solito nella intranet del progetto) con i committenti ed il team di progetto (o per lo meno con le persone chiave del team). Gli aggiornamenti effettuati ad alcuni di questi documenti (quelli contrassegnati con '*') dovrebbero essere esplicitamente annotati nel log degli aggiornamenti di versione che di solito compare nelle prime pagine di ogni documento di progetto rilasciato; il documento Controllo variazioni di progetto quando presente ha proprio lo scopo di tracciare le variazioni accadute agli obiettivi, alle specifiche, alle macro-pianificazioni e alle altre principali condizioni determinanti del progetto.

[modifica] Variabili di controllo del progetto

La disciplina del project management ha tra i propri principali obiettivi quello di tenere sotto controllo le variabili del progetto, costituite dalle variabili già descritte nella sezione triangolo dei vincoli di progetto a cui si aggiungono i rischi.

Il rischio può essere definito come una potenziale causa di fallimento del progetto o, in altre parole, un evento potenzialmente in grado di mettere a repentaglio il raggiungimento degli obiettivi del progetto. La maggior parte dei rischi con impatti negativi può essere risolta (o per lo meno mitigata) intervenendo nella pianificazione del progetto e disponendo di maggior tempo e/o maggiori risorse. Secondo alcune definizioni (inclusa la terza edizione del PMBOK) un rischio può essere classificato anche come positivo nel senso che ad esso può essere associato una potenziale opportunità (ad es: completare il progetto prima del previsto, per via di una immissione di risorse aggiuntive o di una sua semplificazione). I committenti di un progetto a volte posso imporre in corsa un peggioramento sulle tre variabili del triangolo: tempi, costi/risorse, scopo/qualità. La restante variabili, i rischi appunto, devono essere gestite dal team di progetto ed in primis dal project manager, mediante una stima iniziale solida e accurata e l'utilizzo di tecniche di pianificazione efficienti e reattive. Sia la determinazione di queste variabili (tempi, costi/risorse, scopo/qualità) sia l'approccio da utilizzare verso i rischi di progetto, di solito vengono fissati attraverso un processo di negoziazione tra le parti che si riflette nel contratto iniziale (formale o informale che sia).

Un buon project manager oltre alla profonda conoscenza di queste variabili di solito ha una buona esperienza anche nei processi di integrazione, comunicazione, gestione delle risorse umane, assicurazione della qualità (Quality Assurance), pianificazione e gestione degli acquisti (Procurement).

[modifica] Approcci metodologici

Esistono diversi approcci adottabili per la gestione delle attività di un progetto, che includono gli approcci agili, interattivi, incrementali e basati sulla successione di fasi predefinite. Ciascuno di questi approcci presenta vantaggi e svantaggi che possono consigliarne l'adozione in certi contesti di progetto piuttosto che sconsigliarlo in altri. In progetti reali non è raro rilevare l'adozione di approcci misti che utilizzano parti dell'uno o dell'altro a seconda del contesto o della fase del progetto.

Molti di essi fanno riferimento al PMBOK sviluppato dal Project Management Institute. Tra i più importanti (vedere ad esempio recensione di Max Wideman) possono essere considerati RUP, PRINCE2 [5], TenStep, SDLC.

Indipendentemente dall'approccio utilizzato, una particolare attenzione va dedicata alla definizione chiara degli scopi/obiettivi del progetto e delle loro implicazioni; anche la definizione chiara dei ruoli e delle responsabilità di tutti gli attori coinvolti, inclusi i committenti, riveste una importanza decisiva per il successo del progetto.

Nel caso di progetti molto complessi (ad esempio nel caso di un insieme di progetti correlati) e comunque in caso di impatti rilevanti dei progetti sulle organizzazioni coinvolte e sui loro processi, il progetto deve essere considerato all'interno di un approccio più globale, agendo sul piano del Change management che si occupa principalmente di gestire l'impatto umano e organizzativo di una trasformazione all'interno di un contesto aziendale e/o sociale.

fasi di sviluppo di un progetto
fasi di sviluppo di un progetto

[modifica] Approccio classico

L'approccio classico è di fatto rappresentato dalla ortodossia del PMBOK sviluppato dal Project Management Institute , all'interno della quale sono definiti 44 processi, raggruppati in 5 componenti e 9 aree di conoscenza. I processi del PMBOK, se applicati in modo appropriato ai progetti, consentono di pianificare, eseguire e monitorare tutti gli aspetti che direttamente o indirettamente possono influire sull'esito del progetto.

Le 5 componenti (4 fasi più il controllo) che rappresentano lo sviluppo di un progetto sono:

  1. fase di allestimento e avviamento del progetto;
  2. fase di pianificazione e progettazione;
  3. fase di esecuzione o produzione;
  4. sistema di monitoraggio e controllo;
  5. fase di completamento e rilascio dei risultati.

Questa sequenza di fasi non va interpretata in modo deterministico: non tutti i progetti arrivano alla fine, qualche progetto probabilmente non ha la fase di pianificazione e monitoraggio, mentre diversi progetti iterano ciclicamente attraverso le fasi 2,3 e 4.

Molti contesti industriali utilizzano variazioni a queste fasi. Per esempio nel settore della progettazione civile i progetti tipicamente avanzano attraverso fasi come la pre-pianificazione, la progettazione concettuale, la progettazione schematica, lo sviluppo della progettazione, il disegno degli elementi costruttivi, l'amministrazione del progetto. Nel settore dei progetti informatici l'approccio classico spesso è conosciuto come modello a cascata (waterfall model) per via della linearità con cui viene esplosa la sequenza dei task nel processo di pianificazione. Il modello a cascata funziona meglio su progetti compatti e ben definiti mentre su progetti più complessi dove esistono larghe aree di scopo non ben definite o sconosciute, è meno indicato. Il Cono di incertezza descrive come la pianificazione fatta nella fase iniziale di un progetto sia affetta da un elevato grado di incertezza. Questo diventa particolarmente vero nei progetti software che hanno l'obiettivo di sviluppare nuovi prodotti. Il modello a cascata viene ritenuto poco affidabile nei progetti nei quali i requisiti non sono chiari e ben definiti e nei casi dove sono suscettibili di variazioni significative.

Mentre i nomi delle fasi possono differire da un campo di applicazione all'altro, le fasi effettive seguono tipicamente i passi tipici della prassi di problem solving (definizione del problema, valutazione delle alternative e delle opzioni, scelta del percorso ottimale, realizzazione e verifica).

[modifica] Approccio Rational Unified Process

Il Rational Unified Process (RUP) è un framework per lo sviluppo iterativo di prodotti software creato da Rational Software Corporation (una divisione di IBM a partire dal 2003). Nelle prassi di sviluppo del software molte organizzazioni hanno adattato il RUP integrandolo con gli approcci di project management, anche se RUP non richiede esplicitamente o raccomanda questa prassi.

Nello schema del RUP, il ciclo di vita di un processo software viene suddiviso in cicli di sviluppo, a loro volta scomposti in fasi secondo lo schema seguente:

  • fase iniziale (Inception) – identifica lo scopo iniziale del progetto, la probabile architettura del sistema e ottiene il mandato e il finanziamento dal committente;
  • fase di elaborazione (Elaboration) – disegna e verifica l'architettura del sistema;
  • fase di costruzione (Construction) – produce il software con scadenze regolari su basi incrementali dando priorità più alta ai rilasci più attesi dai committenti;
  • fase di transizione (Transition) – testa e installa il sistema nell'ambiente di produzione.

Nel RUP ogni fase ha un certo insieme di obiettivi e si conclude con la realizzazione di un deliverable (prodotto) di qualche genere. Le fasi sono ulteriormente scomposte in iterazioni, che sono associate a periodi temporali e hanno deadline precise.

La versione aperta del RUP è la OpenUP (vedere anche wiki inglese).

[modifica] Approccio Critical Chain

L'approccio del Critical chain (catena/percorso critico) si focalizza sulla disponibilità delle risorse oltre che sulle dipendenze logiche tra attività di progetto.

L'approccio è derivato dall'applicazione della Teoria dei Vincoli al project management. L'obiettivo è quello di aumentare la produttività dei progetti (rappresentabile come la percentuale delle attività completate con la qualità richiesta entro le date di rilascio previste dalla pianificazione impostata) all'interno di una organizzazione. Applicando i primi tre passi della T.d.V. Le risorse vengono identificate come il vincolo primario di ogni progetto. Per fronteggiare il vincolo, viene data priorità a tutte le attività che si trovano sul percorso critico. In particolare i progetti vengono pianificati e gestiti in modo tale da assicurare una pronta partenza, con le risorse totalmente disponibili a tutte le attività che si vengono a trovare sul percorso critico.

Per alcuni progetti specifici, la pianificazione di progetto può essere fatta livellando opportunamente le risorse assegnate alle attività; in questo modo la catena di attività (task) più lunga viene identificata con il percorso critico ovvero critical chain (da cui il nome dell'approccio).

In ambienti con diversi progetti interconnessi, il livellamento delle risorse dovrebbe essere realizzato ragionando a livello globale. Tuttavia in molti contesti è facile identificare una risorsa che agisce come un jolly sui diversi progetti, creando forti rischi di destabilizzazione in relazione alla sua disponibilità.

[modifica] Approccio Event chain

La metodologia Event chain (ECM o metodologia della Catena Critica) costituisce un ulteriore affinamento delle metodologie di project management basate sul Critical Path (CPM o Metodologia del Percorso Critico) e sul Critical Chain.

L'ECM è un approccio di modellazione e di analisi dei reticoli di pianificazione che considera e gestisce l'incertezza di alcune catene di eventi in grado di impattare sul piano del progetto. L'ECM è basata su questi principi fondamentali:

  • probabilità istantanea di rischio: un task nella maggior parte dei processi della vita reale non è un processo continuo e uniforme ma può essere impattato da eventi che possono accadere in qualche punto della sua vita;
  • catene di eventi (Event chain): gli eventi possono causare altri eventi, andando a creare catene di eventi che possono condizionare il corso del progetto. L'analisi quantitativa viene usata per determinare l'effetto cumulativo di queste catene di eventi nella pianificazione del progetto;
  • eventi critici o catene di eventi critiche: i singoli eventi o le single catene di eventi potenzialmente in grado di condizionare il progetto costituiscono gli eventi critici o le catene di eventi critiche. Esse possono essere individuate da un procedimento di analisi;
  • tracciamento degli eventi sul progetto: se un progetto è stato parzialmente completato e sono disponibili informazioni riguardanti la sua durata, i suoi costi e gli eventi accaduti nel suo svolgimento, è possibile calibrare previsioni circa i futuri potenziali eventi che potrebbero occorrere, aiutando così a valutare le future performance del progetto;
  • visualizzazione delle catene di eventi: gli eventi e le catene di eventi possono essere visualizzate usando diagrammi di catene di eventi o diagrammi di Gantt.

[modifica] Approcci di Project Management basati sui processi (Agile e XPM)

Gli approcci di Project Management basato sui processi (Process-based management) derivano da una generalizzazione del concetto di controllo di progetto.

Questi approcci, con maggiore diffusione nell'area informatica, sono stati indotti dall'uso del Capability Maturity Model Integration (CMMI) e dello standard ISO/IEC15504 (SPICE - Software Process Improvement and Capability Determination) che riscuotono una popolarità più vasta.

Uno di questi approcci più conosciuti è rappresentato dalla Metodologia Agile, basata sui principi di Management dell'interazione umana (human interaction management) che privilegiano la vista dei processi di collaborazione umana tra gli attori coinvolti nella gestione del progetto. Negli approcci Agile software development e Flexible product development il progetto viene visto come una serie di task relativamente snelli, disegnati ed eseguiti in modo fortemente orientato alla domanda, secondo una logica adattativa, piuttosto che come risultato di un processo completamente pianificato fin dall'inizio.

L'Extreme Project Management (indicato anche anche come XPM) anch'esso ispirato alla Metodologia agile rispetto al project management tradizionale si focalizza maggiormente sull'obiettivo, ne riduce l'ambito agli aspetti essenziali e si dimostra particolarmente versatile di fronte al cambiamento delle condizioni del contesto in cui il progetto si trova.

In alcune rivisitazioni critiche del project management è stato notato che i diversi approcci basati fondamentalmente su logiche PERT non sono particolarmente adatti agli ambienti multi-progetto delle grandi organizzazioni moderne. Oggi molte di queste sono orientate a progetti a scala molto larga, veloci, non ripetitivi, e va considerato anche che molte iniziative manageriali vengono portate avanti sotto forma di progetti.

L'XPM sostiene che, usando per i progetti (o addirittura per i task) modelli troppo complessi, specialmente quando si dilatano su alcune settimane, in molti casi si originano dei costi supplementari dannosi e si abbassano la flessibilità e la reattività del progetto. I fautori dell'XPM si sono ispirati ad approcci leggeri presenti nella Ingegneria del software come l'Extreme Programming e le tecniche Scrum. Se usato in combinazione con il process modeling ed i principi di gestione delle interazioni umane, l'XPM per molti versi può essere considerato come la generalizzazione dell'Extreme Programming all'ambito della gestione di progetto.

[modifica] Sistemi di project management

I Sistemi utilizzati per la gestione di un progetto, pur essendo funzionali agli approcci sopra elencati, hanno (almeno parzialmente) caratteristiche in comune che possono essere utilizzati da approcci diversi. Seguendo l'approccio tradizionale lo sviluppo di un progetto include cinque componenti: le quattro fasi di sviluppo più il controllo.

[modifica] Sistema di controllo del progetto

Il controllo del progetto è quella componente che serve a tenere il progetto in linea con i piani di rilascio, i tempi e i costi. Esso inizia contestualmente alla fase di pianificazione e finisce con la verifica dei deliverable rilasciati, attraversando ogni fase del progetto. Per ciascun progetto dovrebbe essere valutato il livello di controllo necessario più appropriato: un controllo troppo articolato ne innalzerebbe inutilmente i costi, un controllo troppo lasco ne innalzerebbe pericolosamente i rischi. Se il controllo di progetto non venisse costruito correttamente, il costo della realizzazione dovrebbe prevedere anche i costi per la sistemazione degli errori (intesi in generale come difformità dalle specifiche desiderate), e delle revisioni/ispezioni addizionali.

I sistemi di controllo, a seconda del progetto, servono a governare un insieme di aspetti che include (non necessariamente tutte le variabili elencate) i costi, i rischi, la qualità, le comunicazioni, i tempi, le risorse umane, le variazioni di scopo, la gestione degli acquisti. Un auditor, preposto a misurare e controllare l'avanzamento di un progetto, costruisce un sistema di controllo in funzione degli obiettivi attribuiti al progetto e alle variabili (principalmente legate ai rischi più probabili e maggiore impatto) che i committenti/protagonisti ritengono più opportuno tenere d'occhio. Un auditor può fare parte del team di progetto (in diversi casi le sue funzioni possono essere assorbite dal project manager) piuttosto che costituire una figura indipendente (magari dipendente da un'ente esterno) volta a fotografare più oggettivamente lo stato del progetto.

In diversi casi vengono sviluppati dei processi di controllo formale per assicurare che la misurazione e il controllo dello stato di avanzamento del progetto siano effettuati nel modo più oggettivo possibile. Un buon sistema formale di controllo include:

  • una strategia volta a garantire l'allineamento delle direzione del progetto con gli obiettivi generali della organizzazione che lo ha lanciato;
  • standard ai quali deve attenersi il progetto;
  • direttive di gestione del progetto per il rispetto dei tempi e dei costi;
  • procedure di descrizione dei processi che regolano il progetto.

Una tecnica di analisi molto diffusa e comunemente integrata nei sistemi di controllo di un progetto è la Earned Value Analysis che ha l'obiettivo di misurare oggettivamente in termini di costi (o di ore di lavoro, nei progetti in cui l'equivalenza ha un senso) l'avanzamento di un progetto contro i costi preventivati dal piano e quelli effettivamente sostenuti. L'Earned Value misura in pratica i costi maturati in rapporto ai costi totali previsti (aggiornati con le stime "a finire") del progetto.

[modifica] Fasi di sviluppo del progetto

A prescindere dalla maggior parte delle metodologie usate, lo sviluppo di un progetto ha grosso modo (magari indicate con nomi diversi e/o raggruppate in modo diverso) le stesse fasi principali: allestimento e avviamento (o start-up), pianificazione e progettazione (intesa come identificazione dei requisiti del progetto), esecuzione (o produzione dei risultati), monitoraggio e controllo del progetto, completamento e rilascio dei risultati.

[modifica] Allestimento e avviamento

La fase di preparazione determina la natura e lo scopo del progetto. Se questa fase non viene realizzata con cura, è assai improbabile che il progetto riuscirà a raggiungere gli obiettivi per i quali è stato lanciato. È essenziale che il contesto del progetto (organizzativo, di business, ...) venga compreso a fondo e che siano inseriti gli opportuni meccanismi organizzativi (es: Comitato di Controllo detto anche Steering Committee) e di processo (es: variabili da monitorare e modalità di controllo) che siano in grado di assicurarne il buon andamento.

La fase di preparazione dovrebbe includere un piano coerente che copre le seguenti aree:

  • Analisi delle necessità scaturite dal committente e loro traduzione in obiettivi misurabili del progetto
  • Analisi della situazione attuale
  • Disegno concettuale della situazione futura
  • Identificazione delle risorse e delle attrezzature necessarie per il progetto
  • Analisi dei costi e dei benefici e loro traduzione in termini economici (budget del progetto)
  • Identificazione dei committenti, dei protagonisti (inclusi gli utenti chiave) e del personale di supporto al progetto
  • Stesura degli Obiettivi di progetto e/o delle Specifiche preliminari di progetto (Allegato tecnico) che includono costi, attività, deliverable e pianificazione

[modifica] Pianificazione e progettazione

Dopo la fase di allestimento inizia lo sviluppo della progettazione fino al livello di dettaglio ritenuto opportuno e necessario per l'esecuzione del progetto. A volte in questa fase (o nella parte iniziale della fase di esecuzione) viene costruito e verificato un (piccolo) prototipo del prodotto finale. Il Test può avvenire al termine della costruzione del prototipo o parallelamente al suo sviluppo ed in genere è realizzato con la partecipazione degli utenti chiave e di figure interne al progetto (spesso identificate con il ruolo di tester).

In questa fase dovrebbe essere già operativo un adeguato sistema di controllo che assicuri l'aderenza del prodotto finale alle specifiche definite negli Obiettivi di progetto. Il risultato della fase di progettazione deve assicurare che il prodotto finale:

  • soddisfi il committente, gli utenti finali e i requisiti iniziali;
  • funzioni come ci si aspetta;
  • possa essere prodotto nel rispetto degli standard di qualità definiti;
  • possa essere prodotto dentro i vincoli di tempo e di costi (budget) definiti.

[modifica] Esecuzione

La fase di esecuzione consiste nei processi necessari a soddisfare i requisiti del progetto. Dalla prospettiva del project manager ciò equivale a realizzare e completare il lavoro definito nei documenti facenti parti parte del Project Management Plan (così come indicato nella precedente sezione Deliverable dell'attività di Project Management). I deliverable vengono prodotti come risultati dai processi definiti nel Project Management Plan. I processi presenti nella fase di esecuzione, ancor più che la fase di pianificazione e progettazione, possono determinare impegni notevoli per il coordinamento di risorse umane e non.

[modifica] Monitoraggio e Controllo

Il monitoraggio e controllo è formato da quei processi attuati per osservare e misurare l'esecuzione del progetto in modo da identificarne per tempo i rischi e i potenziali problemi e intraprendere, quando necessarie, le azioni correttive volte a rimettere il progetto in linea con i propri obiettivi. Il presupposto principale di questa attività di controllo consiste nella possibilità di osservare e misurare regolarmente la produttività del progetto, identificandone gli scostamenti (chiamati varianze nella teoria dell'Earned Value Management) rispetto alla produttività assunta in fase di pianificazione (Project Management Plan).

Ciclo di monitoraggio e controllo
Ciclo di monitoraggio e controllo

Il monitoraggio e controllo include:

  • misurazione dell'avanzamento delle attività del progetto (dove ci troviamo);
  • confronto con le previsioni del Project Management Plan che costituiscono la baseline del progetto (dove dovremmo essere);
  • messa a punto e controllo delle azioni correttive volte a rimuovere i problemi e/o evitare i rischi in modo da ristabilire la produttività desiderata del progetto (come dobbiamo continuare);
  • sorveglianza verso l'adozione implicita di variazioni di scopo (change request) non concordate e approvate.

Le misurazioni effettuate presuppongono la definizione di un sistema di indicatori definito all'inizio del progetto (metriche di progetto) di cui fanno quasi sempre parte i costi e la quantità di lavoro erogato (effort).

In questa fase l'attività di identificazione dei problemi e dei rischi richiede il continuo supporto degli utenti chiave; dal punto di vista un auditor la velocità di identificazione e gestione dei problemi costituisce un indicatore importante per determinare lo stato di salute del progetto.

In progetti multifase (progetti in cui la fase di pianificazione e/o esecuzione vengono suddivise temporalmente in sottofasi attraverso il rilascio di macro-deliverable ben identificati) il processo di monitoraggio e controllo provvede anche a creare le connessioni tra le sottofasi del progetto, allo scopo di implementare le azioni che mantengano il progetto coerente con il Project Management Plan.

In determinati contesti (dal settore delle costruzioni al software) sui progetti di media o grande complessità è quasi impossibile che non si verifichino variazioni di scopo. Le variazioni possono essere costituite ad esempio da:

  • modifiche originate dalla necessità di risolvere problemi di progettazione;
  • condizioni operative riscontrate diverse da quelle ipotizzate (es. nel settore edile: consistenza del terreno differente da quella prevista);
  • problemi di reperibilità dei materiali necessari;
  • variazioni richieste dagli appaltatori o introdotte da terze parti;
  • ecc.

Oltre a recepire le variazioni nel contesto del progetto (spesso questo implica un riciclo nella fase di progettazione) esse necessitano di essere documentate, mantenendo evidenza delle differenze con gli scopi originali del progetto (per consentire al committente di capire chiaramente cosa è cambiato e soprattutto trovare le giustificazioni per i diversi tempi e costi di realizzazione del progetto). In ambito industriale e in quello delle costruzioni la produzione della documentazione “as built” (“come costruito”) è una prassi abbastanza comune prevista dai contratti. Le variazioni di scopo possono richiedere anche variazioni al contratto stabilito tra le parti per la realizzazione del progetto.

Lo strumento centrale della fase di monitoraggio e controllo è costituito dal rapporto di Stato Avanzamento Lavori (SAL, conosciuto anche come Project Status Report), redatto dal project manager per informare gli altri attori del processo di monitoraggio sullo stato del progetto. Le informazioni principali presenti nel SAL sono:

  • deliverable rilasciati (in rapporto al piano);
  • costi e tempi maturati in (rapporto al piano);
  • problemi e rischi, sia aperti che risolti;
  • azioni in corso (“chi fa che cosa entro quando”) per l'indirizzamento dei problemi e dei rischi aperti.

I costi (distinguibili tra maturati, effettivi, pianificati) spesso vengono espressi tramite il costo standard secondo un approccio di contabilità industriale piuttosto che il costo puntuale (inteso come il costo preciso) utilizzato dalla contabilità generale

[modifica] Completamento

Il completamento del progetto prevede l'accettazione formale dei deliverable rilasciati e l'esecuzione di tutte le attività “amministrative” indirizzate a chiudere tutte le pendenze, inclusa l'archiviazione dei documenti e la redazione dei rapporti di chiusura (tra cui il “lesson learned” ossia le lezioni imparate dal progetto). La fase di chiusura può essere divisa in due parti:

  • chiusura del progetto: completamento di tutte le attività aperte sul progetto (dismissione e reallocazione del team di lavoro impiegato, consuntivazione lavoro e costi effettivi, statistiche di performance, rapporti di chiusura, pulizia dell'ambiente fisico del progetto incluso file e spazi utilizzati);
  • chiusura del contratto: conseguimento della accettazione formale del committente per ciascun gruppo di deliverable statuito dal contratto, spunta di tutte le obbligazioni contrattuali e soluzione di tutti i problemi rimasti aperti.

[modifica] Strumenti per il project management

Gli strumenti di project management includono:

[modifica] Associazioni e Standard

[modifica] Associazioni per il project management

Esistono diverse associazioni nazionali e professionali con lo scopo di promuovere e sviluppare le prassi di project management e le professionalità correlate. Le principali associazioni sono:

[modifica] Standard internazionali

Nel tempo si sono manifestati diversi tentativi per sviluppare standard di project management, tra i quali:

[modifica] Certificazioni Professionali

Vedere anche: una lista riconosciuta di standard internazionali (Project Management Maturity Models)

[modifica] Note bibliografiche

  1. ^ Project Management Institute. Guida Al Project Management Body of Knowledge. 3a ediz.. Project Management Institute, 2003. ISBN 1930699220
  2. ^ Cesare, De Bello Gallico, IV, 17
  3. ^ F.W. Taylor. L'organizzazione scientifica del lavoro. Milano, Etas Kompass, 1967.
  4. ^ John Hollmann. Total Cost Management Framework. Morgantown WV, AACE International, 2006.
  5. ^ The PRINCE2 Guide - A to Z, FAQ and 1000+ Exam Questions

[modifica] Voci correlate

[modifica] Bibliografia

[modifica] libri in italiano

  • Russel D. Archibald. Project Management - La gestione di Progetti e programmi complessi. 3a ediz.. Franco Angeli, 2004. ISBN 9788846451798
  • Project Management Institute. Guida Al Project Management Body of Knowledge. 3a ediz.. Project Management Institute, 2003. ISBN 1930699220
  • Harold Kerzner. Project management. Pianificazione, scheduling e controllo dei progetti. 1a ediz. (8a ediz. inglese). Hoepli, 2005. ISBN 8820334267
  • Lucio Bianco, Massimiliano Caramia. Metodi quantitativi per il project management. 1a ediz.. Alpha Test, 2006. ISBN 8820336669
  • Marion E. Haynes. Project management: dall'idea all'attuazione. Una guida pratica per il successo.. 7a ediz.. Franco Angeli, 2004. ISBN 882047462X
  • ISIPM - A cura di E.Mastrofini e E.Rambaldi. Guida alla Certificazione Base di Project Management. 1a ediz.. Franco Angeli, 2008. ISBN 8846497062


[modifica] libri in inglese

  • Scott Berkun. Art of Project Management. Cambridge, MA, O'Reilly Media, 2005. ISBN 0-596-00786-8
  • Fred Brooks. The Mythical Man-Month. 20th Anniversary Edition. Adison Wesley, 1995. ISBN 0-201-83595-9
  • Gary Heerkens. Project Management (The Briefcase Book Series). McGraw-Hill, 2001. ISBN 0-07-137952-5
  • Yamal Chamoun. Professional Project Management, THE GUIDE. 1st.Edition. Monterrey, NL MEXICO, McGraw Hill, 2006. ISBN 970-10-5922-0
  • James Lewis. Fundamentals of Project Management. 2nd ed.. American Management Association, 2002. ISBN 0-8144-7132-3
  • Meredith, Jack R. and Mantel, Samuel J.. Project Management : A Managerial Approach. 5th ed.. Wiley, 2002. ISBN 0-471-07323-7
  • Stellman, Andrew and Greene, Jennifer. Applied Software Project Management. Cambridge, MA, O'Reilly Media, 2005. ISBN 0-596-00948-8
  • Thayer, Richard H. and Yourdon, Edward. Software Engineering Project Management. 2nd Ed.. Wiley-IEEE Computer Society Press, 2000. ISBN 0-8186-8000-8
  • Eric Verzuh. The Fast Forward MBA in Project Management. 2nd. Wiley, 2005. ISBN 0-471-69284-0 (pbk.)


[modifica] Collegamenti esterni

Estratto da "http://it.wikipedia.org/wiki/Project_management"
Strumenti personali