piccola guida al project management

20
Piccola guida al Project Management Le piccole guide di TAI Solutions 2

Upload: tai-solutions

Post on 10-Mar-2016

425 views

Category:

Documents


7 download

DESCRIPTION

Questa piccola guida offre una panoramica non tecnica sul Project Management

TRANSCRIPT

  • Piccola guida al

    Project Management

    Le piccole guide di TAI Solutions

    2

  • Piccola guida al

    Project

    Management

    Contenuti

    Project management...4

    Approcci metodologici.9

    Strumenti per il P.M........15

    Project Portfolio Management..16

    Bibliografia..17

    Prefazione Con l'espressione inglese project management, detto anche 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 risul-

    tati specifici che comportano dei benefici o del valore aggiunto al commit-

    tente/cliente.

  • 4

    Secondo il PMBOK (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 perma-

    nenti 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 deter-

    minati 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.

    Focus

    La Project Management Body of

    Knowledge (PMBOK) una

    guida, pubblicata dal Project Man-

    agement Institute (PMI), che ha lo

    scopo di documentare e standard-

    izzare le pratiche comunemente

    accettate di project management.

    Questa guida il riferimento per

    sostenere gli esami per lotteni-

    mento delle certificazioni del

    PMI, la pi diffusa delle quali la

    PMP - Project Management

    Professional, che conta oltre

    470.000 professionisti attivi certifi-

    cati in tutto il mondo.

    Altre certificazioni sono rilasciate

    da Istituti internazionali accredi-

    tati, tra le quali la ISIPM Base

    dellIstituto Italiano di Project

    Management .

    Project Management

  • Storia 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 lavora-

    rono 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 essere sviluppati in assenza di una buona cultu-

    ra nel campo del project management.

    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 recen-

    ti, la realizzazione di software.

    Uno dei contributi pi precoci e pi importanti venne dato dall'ingegnere statunitense Henry Gantt, che intro-

    dusse 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 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 Seconda 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 tecni-

    che 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 Cor-

    poration 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 consu-

    lente delle maggiori Societ, Imprese e Committenti stato Russel D. Archibald.

    L'ingegneria gestionale si evolse e, grazie al lavoro pionieristico di Hans Lang e altri, vennero sviluppate tec-

    nologie 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 Enginee-

    ring") da parte dei primi cultori del project management e delle prassi correlate (pianificazione, stima dei co-

    sti, controllo di progetto costi/pianificazione). La AACE ha continuato la sua attivit di sviluppo degli standard

    tecnologici e nel 2006 ha rilasciato il "Total Cost Management Framework" sviluppato da John Hollman.

    5

  • 6

    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 ba-

    se 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 pro-

    ject management. L'International Project Management Association (IPMA), fondata in Europa nel 1967, ha in-

    trapreso 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.

    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.

    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.

    In progetti di grande respiro, l'attivit di project management pu essere delegata a pi persone: si realizza

    quindi un gruppo di project management. Comunemente nel gruppo esiste un leader che viene comunque chia-

    mato project manager, a questo si affiancano altre persone che si occupano delle attivit di management di

    parti del progetto secondo una vista per componenti del sistema o per aree specifiche. Questi vengono detti

    talvolta task manager.

    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.

  • 7

    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 prodot-

    te con tecniche diverse, provvedendo poi a effettuare una riconciliazione che produca una convergenza. La du-

    rata 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 risor-

    se impiegate. I passi comuni alla maggior parte delle tecniche di pianificazione prevedono di:

    identificare le attivit elementari (task) necessarie a produrre i deliverable associati a ciascun elemento del-la Work Breakdown Structure (WBS) e le loro dipendenze;

    rappresentare la scomposizione dei task in un diagramma di Gantt, mettendo in evidenza le interrelazioni tra i 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 cerca-

    re 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.

  • 8

    Triangolo dei vincoli di progetto

    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

    ovvero ciascun parametro funzione degli 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 rap-

    presenta il budget disponibile per il progetto e al tempo stesso l'insieme delle risorse a disposizione del progetto

    ( evidente la correlazione diretta 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 aumen-

    tare i tempi e i costi/risorse del progetto; ridurre i tempi spesso richiede costi pi alti (risorse pi grandi) e/o

    uno scopo pi ristretto; un budget risicato (meno risorse) pu implicare tempi pi lunghi e/o una riduzione dello

    scopo.

    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 ottimizzando il tutto.

    Una rappresentazione alternativa dei vincoli consiste nello 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.

    .

  • 9

    Tempo Le dipendenze tra i task interni e quelle dagli eventi esterni (es: la fornitura di prodotti o materiali che ser-

    vono 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 atti-

    vit periodiche di routine del project manager. Il Tempo non considerato un costo n una risorsa, dato

    che il project manager non pu controllare la velocit con cui trascorre; questo ne fa la differenza fonda-

    mentale con gli altri vincoli.

    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 ammini-

    strazione del progetto, impianti e strumenti a disposizione, rivalutazione dei costi (in caso di progetti plu-

    riennali), costi indiretti.

    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 un'aderenza soddi-

    sfacente (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).

  • 10

    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 cosiddetti 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 con rimessa del 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 dell'accettazione dei risultati prodotti

    20. Comunicazione di progetto (che in realt inizia dal punto 2) oppure dissemination

    21. Notifica dei risultati ottenuti ai committenti

    A queste si affiancano le attivit trasversali che sottendono all'applicazione delle cosiddette "Soft skill", meno

    tecniche e pi orientate alla motivazione dei gruppi di lavoro e al rapporto interpersonale.

  • 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'acrostico SMART (traducibile dall'inglese come "intelligente",

    "furbo"):

    Specifico/Semplice (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/Tracciabile (nel senso che deve essere conseguito entro una data certa e poter essere traccia-

    to nel suo avanzamento)

    La misurazione (o valutazione) del raggiungimento di un obiettivo pu/deve essere accertata alla fine del pro-

    getto. Tuttavia una continua vigilanza attiva sul progresso verso ciascun obiettivo dovrebbe essere monitorata

    e valutata periodicamente nel corso del progetto.

    La comunicazione di progetto, da non confondere con la comunicazione al committente dei risultati del proget-

    to, un processo diretto a fare comprendere gli obiettivi e valorizzare contenuti del progetto presso una quan-

    tit di pubblici diversi e differenziati. Ad es. promuovere il progetto, le sue finalit e l'organizzazione che lo

    realizza, presso i Media (ufficio stampa), presso target interni (top management, financing, comunicazione

    corporate ecc.) o utilizzarne i valori per il marketing aziendale.

    Deliverable dell'attivit di project management I deliverable nell'ambito del project management sono identificabili in un insieme di documenti, a cui ci si rife-

    risce come Project Management Plan. Tali documenti hanno inoltre lo scopo di allineare le aspettative degli

    sponsor, dei clienti e del team di progetto.

    Variabili di controllo del progetto

    La disciplina del project management ha tra i propri principali obiettivi quello di tenere sotto controllo le varia-

    bili del 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 pianificazio-

    ne 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).

    11

  • I committenti di un progetto a volte posso imporre in corsa un peggioramento sulle tre variabili del triangolo:

    tempi, costi/risorse, scopo/qualit. Le restanti variabili, i rischi appunto, devono essere gestite dal team di pro-

    getto 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 negozia-

    zione 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).

    Approcci metodologici Gli approcci utilizzati nell'ambito del project management consistono in diversi approcci metodologici adottabili

    per la gestione delle attivit di un progetto, che includono gli approcci agili, interattivi, incrementali e basati sulla

    successione di fasi predefinite.

    Molti di essi fanno riferimento al PMBOK sviluppato dal Project Management Institute. Tra i pi importanti pos-

    sono essere considerati RUP, PRINCE2, 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 azien-

    dale e/o sociale.

    Tra i principali approcci esistenti vi sono:

    L'approccio classico che di fatto rappresentato dalla ortodossia del PMBOK sviluppato dal Project

    Management Institute e a cui si ricollegano altri framework (es: Method 123, TenStep);

    Il Rational Unified Process (RUP) costituito da un framework per lo sviluppo iterativo di prodotti software

    creato da Rational Software Corporation;

    L'approccio del Critical chain (catena/percorso critico) che si focalizza sulla disponibilit delle risorse oltre

    che sulle dipendenze logiche tra attivit di progetto;

    Gli approcci di project management basati sui processi (Process-based management) che derivano da una

    generalizzazione del concetto di controllo di progetto.

    12

  • Approccio classico

    Fasi di sviluppo di un progetto

    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 moni-

    torare 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:

    fase di allestimento e avviamento del progetto;

    fase di pianificazione e progettazione;

    fase di esecuzione o produzione;

    sistema di monitoraggio e controllo;

    fase di completamento e rilascio dei risultati.

    Questa sequenza di fasi non va interpretata in modo deterministico: non tutti i progetti arrivano alla fine, qual-

    che 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 pro-

    gettazione 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 ca-

    scata (waterfall model) per via della linearit con cui viene esplosa la sequenza dei task nel processo di pianifi-

    cazione. Il modello a cascata funziona meglio su progetti compatti e ben definiti mentre su progetti pi com-

    plessi dove esistono larghe aree di scopo non ben definite o sconosciute, meno indicato. Il Cono di incertez-

    za descrive come la pianificazione fatta nella fase iniziale di un progetto sia affetta da un elevato grado di in-

    certezza. 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 tipica-

    mente i passi tipici della prassi di problem solving (definizione del problema, valutazione delle alternative e

    delle opzioni, scelta del percorso ottimale, realizzazione e verifica).

    13

  • Approcci di project management basati sui processi (Metodologia Agi-le e XPM)

    Gli approcci di project management basati sui processi (process-based management) derivano da una generaliz-

    zazione 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 Capabi-

    lity 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 develo-

    pment e Flexible product development il progetto viene visto come una serie di task relativamente snelli, dise-

    gnati 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 come XPM) anch'esso ispirato alla Metodologia agile rispetto al

    project management tradizionale si focalizza maggiormente sull'obiettivo, ne riduce l'ambito agli aspetti essen-

    ziali e si dimostra particolarmente versatile di fronte al cambiamento delle condizioni del contesto in cui il pro-

    getto si trova.

    In alcune rivisitazioni critiche del project management stato notato che i diversi approcci basati fondamental-

    mente 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 conside-

    rato 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 quan-

    do 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 Inge-

    gneria 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.

    14

  • Strumenti per il project management Gli strumenti di project management possono essere intesi sia come le tecniche utilizzate per supportare la

    realizzazione delle attivit di project management, sia come i prodotti software che implementano tali stru-

    menti e li forniscono contestualmente ad un insieme integrato di servizi e/o funzionalit.

    Tra le principali tecniche di supporto alle realizzazione delle attivit di project management vi sono:

    Mappe mentali per supportare la fase di ideazione iniziale, il team building e la rielaborazione finale delle

    esperienze

    Diagrammi di causa ed effetto/Ishikawa, per analizzare e valutare la catena causale delle problemati-

    che che si presentano nel corso delle attivit

    Diagrammi Pert, per descrivere in chiave reticolare le attivit e la loro connessione, individuando i percorsi

    critici

    WBS, per descrivere l'articolazione delle attivit in termini di fasi, sottofasi... fino alle attivit elementari, in

    chiave gerarchico-associativa

    Diagrammi di Gantt, per descrivere i legami logico/temporali delle fasi e delle singole attivit

    Diagrammi Event Chain (Event Chain Diagrams)

    Diagrammi per la rilevazione di indicatori (Run chart)

    Project Cycle Optimisation (PCO - Ottimizzazione del ciclo di vita del progetto)

    Participatory Impact Pathways Analysis, per sviluppare una visione comune tra i protagonisti di un

    progetto

    Mappe concettuali per sintetizzare e rappresentare le informazioni e la conoscenza di progetto.

    15

  • 16

    Project Portfolio Management Il Project Portfolio Management (PPM) un termine utilizzato dai project managers e dalle organizzazioni

    per il project management (PM) per descrivere i metodi per analizzare e gestire un gruppo di progetti in corso

    oppure di proposte di progetto, basandosi su diverse caratteristiche chiave. L'obiettivo fondamentale del pro-

    cesso di PPM quello di determinare la sequenza ed il mix ottimale dei progetti proposti per raggiungere nel

    miglior modo possibile gli obiettivi dell'organizzazione, solitamente espressi in termine di misuratori economici,

    obiettivi delle strategie di business oppure obiettivi strategici a livello tecnico, tenendo conto dei vincoli imposti

    dal management o da fattori esterni. I tipici attributi del progetto vengono analizzati in un processo di PPM

    che include: il costo totale di ogni progetto, il consumo di scarse risorse (sia umane che di altro tipo), la dura-

    ta prevista e la pianificazione degli investimenti, i benefici e le relazioni o interdipendenze con gli altri progetti

    nel portfolio.

    Molte organizzazioni sono culturalmente abituate ad usare metodi informali per prendere decisioni sugli inve-

    stimenti per i progetti, ma questo approccio decisionale ha portato molte organizzazioni a risultati insoddisfa-

    centi, permettendo la formazione della domanda per un processo di decision making pi metodologico e tra-

    sparente. Questa richiesta si trasformata in un mercato per i tools ed i sistemi che facilitano tale processo.

    La maggioranza degli strumenti e dei metodi di PP; cercano di stabilire un insieme di valori, tecniche e tecno-

    logie che permettano la visibilit, la standardizzazione, la misurazione ed il miglioramento del processo. Gli

    strumenti del PPM cercano di permettere all'organizzazione di gestire il flusso continuo dei progetti dall'idea al

    completamento.

  • Bibliografia Libri in italiano

    Russel D. Archibald, Project Management - La gestione di Progetti e programmi complessi, 3 ediz., Franco

    Angeli, 2004. ISBN 978-88-464-5179-8

    Project Management Institute, Guida Al Project Management Body of Knowledge, 3 ediz., Project Manage-

    ment Institute, 2003. ISBN 1-930699-22-0

    Harold Kerzner, Project management. Pianificazione, scheduling e controllo dei progetti, 1 ediz. (8 ediz.

    inglese), Hoepli, 2005. ISBN 88-203-3426-7

    Lucio Bianco, Massimiliano Caramia, Metodi quantitativi per il project management, 1 ediz., Alpha Test,

    2006. ISBN 88-203-3666-9

    Brizio Leonardo Tommasi, Massimiliano Caramia, Project management e risorse umane, 1 ediz., Franco

    Angeli, 2009. ISBN 978-88-568-0675-5

    Marion E. Haynes, Project management: dall'idea all'attuazione. Una guida pratica per il successo., 7 ediz.,

    Franco Angeli, 2004. ISBN 88-204-7462-X

    ISIPM - A cura di E.Mastrofini e E.Rambaldi, Guida alla Certificazione Base di Project Management, 1 ediz.,

    Franco Angeli, 2008. ISBN 88-464-9706-6

    Sebastian Nokes, Sean Kelly, Il project management: tecniche e processi, 2 ediz., Pearson Education Italia,

    2008. ISBN 978-88-7192-500-4

    Antonello E.Bove, Project management: la metodologia dei 12 step, 1 ediz., Hoepli Editore, 2008. ISBN

    978-88-203-3970-8

    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

    Frigenti E Comninos D &, The Practice of Project Management - a guide to the business-focused approach,

    Kogan Page, 2002. ISBN 0-7494-3694-8

    Flyvbjerg, Bent, (2006). "From Nobel Prize to Project Management: Getting Risks Right." Project

    Management Journal "http://flyvbjerg.plan.aau.dk/Publications2006/Nobel-PMJ2006.pdf", vol. 37, no. 3,

    pp. 5-15. 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

    17

  • S. Jonathan Whitty, A Memetic Paradigm of Project Management, International Journal of Project Manage-

    ment, 23 (8) 575-583, 2005.

    Whitty, S.J. and Schulz, M.F., The impact of Puritan ideology on aspects of project management, Interna-

    tional Journal of Project Management, 25 (1) 10-20, 2007.

    Stephen R. Pettee, As-builts Problems HYPERLINK "http://primeedge.com/Asbuilt_news/as-

    built.pdf"&HYPERLINK "http://primeedge.com/Asbuilt_news/as-built.pdf" Proposed Solutions, Construction

    Management Association of America, 2005.

    Eric Verzuh, The Fast Forward MBA in Project Management, 2nd, Wiley, 2005. ISBN 0-471-69284-0 (pbk.)

    Fonti e autori delle voci Project management Fonte: http://it.wikipedia.org/w/index.php?oldid=53870430 Autori:: Albesco, Alphamu5-

    7, AndreA, Aushulz, Avesan, Buggia, Bultro, Cornelius383, Demart81, Diuturno,

    Eagleone, Enjoyppm, Er Cicero, Erambaldi, Eumolpo, Gac, Gacio, Gi87, Giovannimacchia, Gipu56, Giuseppe De

    Marte, Gliu, Ignlig, Ilfachiroalcinema, Ittoene, Jalo, Manot, Marcok,

    Marcopil64, Mattiacrespi, Max 3, MaxDel, Memnone di Rodi, Moroboshi, Nikimast85, No2, Paolosub, Salmon57,

    Salvatore Ingala, Senza nome.txt, Shaka, Theirrulez, Ticket

    2010081310004741, Tiesse, Timg, Tomi, Tregrilli, Uji, Veneziano, 91 Modifiche anonime

    Approcci di project management Fonte: http://it.wikipedia.org/w/index.php?oldid=43956577 Autori:: AKap-pa, Alphamu57, Ary29, Aushulz, Balfabio, Shaka

    Strumenti di project management Fonte: http://it.wikipedia.org/w/index.php?oldid=50298997 Autori:: Al-phamu57, Antonell, Aushulz, Balfabio, Daniele.tampieri, Danilomaggi, Diuturno, Luigi.tuby, Manuelete83, Timg, 9 Modifiche anonime

    Project Portfolio Management Fonte: http://it.wikipedia.org/w/index.php?oldid=35257658 Autori:: Aushulz, Marcol-it, Mr buick, Pracchia-78, Rollopack, TenStepIt, 7 Modifiche anonime

    Fonti, licenze e autori delle immagini File:Trajan's Column (Roman Soldiers Building a Fortress).png Fonte: http://it.wikipedia.org/w/index.php?title=File:Trajan's_Column_(Roman_Soldiers_Building_a_Fortress).png Licenza:

    GNU Free Documentation License Autori:: Fikret Yegul

    File:Project Management (triangolo dei vincoli).png Fonte: http://it.wikipedia.org/w/index.php?title=File:Project_Management_(triangolo_dei_vincoli).png Licenza: GNU Free

    Documentation License Autori:: Alphamu57

    Fi le:Project Management fasi .png Fonte : h t tp:// i t .w ik iped ia .org/w/ index.php?title=File:Project_Management_fasi.png Licenza: GNU Free Documentation License Autori:: Alphamu57

    File:Change Management controllo progetto.PNG Fonte: http://it.wikipedia.org/w/index.php?title=File:Change_Management_controllo_progetto.PNG Licenza: Creative Commons

    Attribution-Sharealike 3.0,2.5,2.0,1.0 Autori:: Alphamu57

    18

  • 19

  • Le piccole guide di TAI Solutions 2

    2013 - www.taisolutions.it