5.2 Project Management Parte 2

Project management parte 2: planning

Il planning di un progetto

Il planning di un progetto è costituito da differenti step:

• 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).
• Definisco la WBS (Work Breakdown Structure): definiamo come realizziamo l’output, ossia attraverso quali attività, in questa fase non devo considerare la dimensione temporale.
• 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).
• 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.
• 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 è così banale, deve considerare il livello di saturazione delle risorse, dev’essere uno schedule veritiero.

I punti successivi riguardano la gestione del rischio:

• 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);
  • 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.
  • 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à.
• 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 così l’EBIT (ossia l’utile di progetto).
• Invoice plan: è la pianificazione di quando entrano i pagamenti, fase molto importante. Ci fermiamo a questo punto 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 lì sì che vanno considerati gli aspetti finanziari.
• 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).
• 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.

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’essere 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:

• 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.
• 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.
• Creazione WBS: identificazione e scomposizione delle SOLE attività necessarie a realizzare l’obiettivo di progetto.
• Verifica dello scope: approvazione formale dei deliverable di progetto e definizione dei momenti intermedi di revisione.
• 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.
• 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 avanzare.