5.2 Project Management Parte 2

PLANNING

Il planning di un progetto è costituito da differenti step:

1. DEFINIZIONE DELLO SCOPE: ossia la descrizione di cosa e come si farà nel progetto e quali

saranno gli output. La definizione dello scope è un processo strutturato, esso non è immutabile,

ed è importante gestirne il cambiamento (gestione e scope change);

2. DEFINISCO LA WBS (Work Breakdown Structure): definiamo come realizziamo l’output, ossia

attraverso quali attività, in questa fase non devo considerare la dimensione temporale;

3. DEFINISCO OBS (Organizational Breakdown Structure): ossia chi farà le mie attività (questo lo

faccio in parallelo alla WBS). Alla fine, è l’organigramma del progetto (differente da quello

dell’azienda);

4. IDENTIFICAZIONE DEL CA (Control Account): il CA è definito come il blocco di controllo

manageriale a cui è possibile attribuire uno scope specifico e delle stime di tempo, costo e

rischio. È un “miniprogetto” che può avere una sua storia. Questo perché nella realtà la

pianificazione e il controllo si fanno a livello di CA e successivamente si aggregano a livello di

progetto.

5. SCHEDULE (livello temporale) e BUDGET (costi): Lo faccio a questo punto perché dipendono da

come ho assegnato le risorse, ossia in base a chi fa cosa. Il budget è banalmente la somma dei

costi, lo schedule non è cosi banale, deve considerare livello di saturazione delle risorse,

dev’essere uno schedule veritiero;

I punti successivi riguardano la gestione del rischio:

6. A LIVELLO DI CA IDENTIFICO GLI EVENTUALI RISCHI. Questi sono eventi avversi o positivi che si

possono verificare (es: rischio aumento/diminuzione dei costi di trasporti). Chiaramente vanno

considerati i rischi con maggiore probabilità di accadimento (essa è ciò che maggiormente mi

dice se considerare i rischi o no);

a. Affidarsi alle contingencies: è un primo modo di gestire i rischi, metto da parte soldi che

utilizzo nel caso si verifichi il rischio. In questo modo non modifico ciò che ho pianificato, se

si verificano li utilizzo altrimenti li considererò come un utile del progetto;

b. Mitigation: Ossia modifico le mie attività in modo da ridurre i rischi. Sostengo un costo

certo per proteggermi da un rischio che è incerto, chiaramente la mitigation influenza la

progettazione delle attività;

7. NEGOZIAZIONE COL CLIENTE: una volta considerati tutti questi aspetti vado a negoziare con il

cliente, quindi stabilito quando mi usciranno i soldi vado a stabilire quando mi entreranno.

Ottengo cosi l’EBIT (ossia l’utile di progetto);

8. INVOICE PLAN: è la pianificazione di quando entrano i pagamenti, fase molto importante;

Ci fermiamo a questo p.to solo in caso di progetti corti questo perché se un progetto dura 3 mesi

non ha rilevanza finanziaria per l’azienda, ma se ho 5 anni di progetto li si che vanno considerati gli

aspetti finanziari.

9. SI CALCOLA IL NIC (Net Invested Capital): sono i soldi che l’azienda spende per portare avanti un

progetto (es: costi del materiale per un progetto edile)

10. CALCOLO EVA = EBIT*(1-t)-NIC*WACC dove t sono le tasse e WACC è il costo del capitale. Posso

arrivare a capire che ciò che guadagno dopo 5 anni lo perdo negli interessi del capitale; 1

LA GESTIONE DELLO SCOPE

Definizione: è l’insieme dei prodotti, servizi e risultati che devono essere forniti come output di un

progetto. È fondamentale essere precisi, non ci dev’esserci ambiguità (il cliente potrebbe non

interpretarlo bene e quindi si sbaglia);

Obiettivo: garantire la realizzazione di quanto richiesto dal cliente (interno ed esterno) evitando

però di realizzare più di quanto richiesto, per non incorrere in maggiori tempi e costi di progetto.

Quali sono le attività che compongono un processo di gestione dello scope:

1. Pianificazione dello scope: si definisce come si andrà a definire lo scope e di come sarà

verificato, controllato, come sarà realizzata la WBS di progetto;

2. Definizione dello scope: si convertono le richieste degli stakeholders in requisiti grazie alla

definizione dello scope statement, per evitare ambiguità è fondamentale definire cose

misurabili, non interpretabili;

3. Creazione WBS: identificazione e scomposizione delle SOLE attività necessarie a realizzare

l’obiettivo di progetto;

4. Verifica dello scope: Approvazione formale dei deliverable di progetto e definizione dei

momenti intermedi di revisione;

5. Controllo dello scope: Gestire tutti i cambiamenti dello scope e i loro impatti sul progetto;

Lo strumento fondamentale della definizione dello scope è lo scope statement, un documento che

contiene tutte le informazioni relative a cosa il progetto debba realizzare. Le informazioni

normalmente contenute in uno scope statement sono:

- Obiettivi del progetto: una descrizione degli obiettivi specifici del progetto e dei fattori che

hanno motivato il suo sviluppo;

- Descrizione dell’output di progetto: una descrizione tecnica o sistemica della soluzione

proposta e di come questa rispetta gli obiettivi di cui sopra;

- Deliverable: sono gli output tangibili o assimilabili che il progetto realizzerà durante il suo

sviluppo (ad esempio, lista di requisiti, prototipi, output finale ecc.). Importante indicare

anche quali deliverable non sono compresi;

- Criteri di completamento: associati tipicamente ai diversi deliverable, indicano quali sono i

criteri che permettono di accettare i deliverable generati e quindi di proseguire nelle fasi

successive. Ad esempio, se vi è un prototipo per lo svolgimento di test funzionali è

importante stabilire se esso può essere accettato solo dopo aver superato tutti i test o è

sufficiente il raggiungimento di un certo numero di test;

- Vincoli di progetto: è importante evidenziare vincoli specifici associati al progetto in

termini di persone, risorse, attori da coinvolgere, attrezzature ecc. Evidenziare fin da subito

vincoli di natura contrattuale o tecnica permette di identificare i punti critici da gestire;

- Misure di successo: sono i parametri di prestazione che sono adottati per valutare il

successo del progetto sia verso il cliente, sia internamente. Alcune possono essere implicite

e legate a criteri autorizzativi del progetto, come ad esempio il livello minimo di redditività.

A questi si legano i fattori critici di successo che devono essere rispettati per la riuscita del

progetto (ad esempio, il rispetto di particolari scadenze);

- Assunzioni: è importante esplicitare le assunzioni secondo cui il progetto sarà pianificato e

gestito. Tra le altre, sono particolarmente importanti da esplicitare le ipotesi relative al

comportamento del cliente (ad esempio, le pratiche autorizzative per l’accesso al sito di

sua responsabilità), al fine di evitare di incorrere poi in problemi difficilmente risolvibili; 2

- Ruoli e stakeholder principali: devono essere evidenziati i principali ruoli associati al

progetto tra cui, ad esempio, l’owner di progetto (chi ne utilizzerà l’output), lo sponsor di

progetto (chi approva il progetto e lo autorizza), il project manager, lo steering committee

e i principali stakeholder ecc.;

- Linee guida e approccio: sono esplicitate le linee guida con cui il progetto sarà gestito, in

termini ad esempio di politiche di outsourcing, di interazione con il cliente, di modalità di

testing ecc. Sono quindi le regole generali che il progetto dovrebbe rispettare lungo il suo

ciclo di vita;

- Stime preliminari di tempi e costi: sono solitamente riportate indicazioni relative a costi e

tempi di progetto, che saranno dettagliati e rivisti nelle successive fasi di pianificazione;

- Sistemi di controllo: sono esplicitati i principali strumenti di controllo del progetto, quali la

frequenza degli incontri di revisione, le modalità di controllo dei rischi e di gestione dei

problemi, i criteri di gestione delle modifiche, ecc.;

- Autorizzazioni: sono riportate le verifiche autorizzative che formalmente permettono al

progetto di partire e quindi di utilizzare le risorse assegnate al progetto.

Diventa importante anche evidenziare le esclusioni, altrimenti ci sono delle divergenze.

10/05

CREAZIONE WBS – Work Breakdown Structure

La WBS non è un elenco banale delle attività di progetto, è strumento che, attraverso un processo

iterativo fatto per approssimazioni successive, decompone il progetto in aggregati di attività

sempre più piccoli, fino ad arrivare a identificarne le attività e i pacchetti di lavoro elementari.

Diverse logiche con cui disaggregare le attività di un progetto:

- Per parti fisiche che costituiscono un

certo deliverable;

- Per funzioni che devono essere svolte

dal deliverable;

- Per fasi attraverso le quali lo si realizza;

- Per obiettivi caratterizzanti l’attività

scomposta;

- Per rilasci progressivi dell’output;

- Per area geografica o spaziale;

ESEMPI SLIDE 12 - 16

Linee guida del processo di costruzione della WBS:

ogni WBE (primo livello, scomposizione delle macro attività) può essere segmentato

• usando una sola logica di scomposizione (si minimizza la perdita d’integrazione e si

riducono le ridondanze);

la profondità (n° di livelli) della WBS dipende dalle dimensioni e dalla complessità del

• progetto e dal livello di dettaglio necessario per pianificarlo;

ad ogni livello, ciascun WBE deve poter essere chiaramente definito in termini di

• responsabilità;

all’interno della WBS devono essere presenti tutti i deliverable (esterni e interni) di

• progetto;

l’insieme di tutti i WBE di un livello della WBS deve descrivere l’intero progetto;

• la struttura della WBS è indipendente da qualsiasi legame temporale.

• 3

IL CONTROLLO DELLO SCOPE

Fattori che portano a cambiamenti di scope generando ripercussioni su

T e C di progetto difficilmente ribaltabili sul cliente:

- Scope Creep (vedi caso GIG): “scivolamento” dello scope a causa di richieste del cliente.

Generalmente si manifesta come una sequenza ininterrotta di piccoli cambiamenti.

Cause: Specifiche non chiare; mancata definizione di momenti di congelamento delle

specifiche con il cliente.

- Scope Gold Plating (vedi caso Aeroplano): si sviluppano funzionalità o si erogano

prestazioni non richieste dal cliente alle quali questo non attribuisce valore.

Cause: non chiara definizione delle attività; non dettagliata descrizione dello scope.

Per limitare queste due situazioni c’è il processo di gestione e monitoraggio dello scope:

OBS - Organizational Breakdown Structure

È l’organigramma di progetto nel quale vengono esplicitate le informazioni che riguardano la

str