Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
vuoi
o PayPal
tutte le volte che vuoi
Specifiche del progetto
Budget: 500.000€
Caso - Pitone
Domande:
- Quale parte del testo fa riferimento allo Statement of Work?
- Quale parte fa riferimento al Project Charter?
- Chi è la Committenza?
- Quali sono i criteri di valutazione?
Lo Statement of Work è il documento che stabilisce cosa fare e gli obiettivi strategici. Gli Initiator fanno partire il progetto e in questo caso sono i clienti esterni, il marketing interno e i laboratori di ricerca interni. Lo Statement of Work include una lista delle richieste e l'adozione di specifiche standard. Spesso, il cliente non fornisce lo Statement of Work e quindi dobbiamo crearlo noi.
Il Project Charter è un documento più dettagliato in cui vengono effettuate analisi di fattibilità e pianificazione. Il Project Charter descrive il "come" del progetto. L'analisi di fattibilità è suddivisa in tre sottoparti.
La Committenza è composta dal CEO e dai responsabili delle funzioni di marketing, R&D, produzione e logistica.
I criteri di valutazione includono la redditività, il livello di rischio, la rilevanza tecnologica e il livello di rischio.
Casi Zanzotti e Matti
Principi di pianificazione e...
ma può subire dei cambiamenti nel corso del progetto. È importante gestire questi cambiamenti in modo efficace per evitare ritardi o problemi nella realizzazione del progetto.3) Work Breakdown Structure (WBS): suddivisione del progetto in attività più piccole e gestibili. Questo permette di avere una visione chiara delle attività da svolgere e dei tempi necessari per completarle.4) Time Estimation: stima dei tempi necessari per completare le singole attività e per il progetto nel suo complesso. È importante fare una stima realistica dei tempi per evitare ritardi nella consegna del progetto.5) Resource Allocation: assegnazione delle risorse necessarie per svolgere le attività del progetto. Questo include personale, attrezzature, materiali, ecc. È importante allocare le risorse in modo efficiente per ottimizzare i risultati del progetto.6) Cost Estimation: stima dei costi necessari per completare il progetto. Questo include i costi delle risorse umane, materiali, attrezzature, ecc. È importante fare una stima accurata dei costi per evitare sorprese durante l'esecuzione del progetto.7) Risk Management: identificazione e gestione dei rischi che possono influire sul successo del progetto. È importante individuare i rischi in anticipo e adottare misure preventive per mitigarli o gestirli efficacemente.8) Quality Planning: definizione degli standard di qualità che devono essere raggiunti nel progetto. È importante pianificare le attività di controllo della qualità per garantire che gli obiettivi di qualità siano soddisfatti.9) Communication Planning: pianificazione delle attività di comunicazione all'interno del team di progetto e con gli stakeholder esterni. È importante stabilire una buona comunicazione per garantire che tutte le parti interessate siano informate sullo stato del progetto.10) Integration Planning: integrazione di tutte le attività di pianificazione in un unico piano di progetto coerente. Questo permette di avere una visione completa del progetto e di coordinare tutte le attività in modo efficace.mapuò esserci la necessità di cambiarlo, bisognagestire il cambiamento dello scope.- Dopo aver fatto lo Scope inizio a costruire i piani della mia casetta nella WBS (Work Breakdown Structure) lista gerarchizzata delle attività che andrò a fare nel progetto ma non ho un’ottica temporale.
- Dopo aver definito cosa devo fare dobbiamo arrivare a chi le fa, affronto la fase di Organization Staffing, vado a definire chi saranno le risorse all’interno del progetto e le strutturo all’interno della OBS (Organizational Breakdown Structure), andremo a mettere tutte le risorse che inserisco nel progetto. Consiste nell’organigramma di progetto, una cosa a sé.
- Incrociando da una parte OBS e dall’altra WBS vado a definire il Control Account (CA) è l’unità atomica del progetto che ha una sua pianificazione. Ogni CA ha un suo costo, un suo Scope e un suo tempo.
- Mettendo insieme CA posso andare a definire Budget e
Schedule di progetto. Lo Schedule è la pianificazione intera del progetto, cioè il diagramma di Gantt. Per fare schedule non basta sommare i tempi ma ci sono varie tecniche per mettere in fila i vari CA.
7) Dopo Budget e Schedule arrivo a una visione d'insieme complessiva, il Time Phased Budget è la distribuzione in un'unica curva dei costi a budget nel tempo. Su un asse ho il tempo e su un asse i costi.
8) Una parte fondamentale che non faremo è il Rischio (Risk), per ogni cosa che può andare storta vado a identificare la probabilità di accadimento e un potenziale impatto. Sulla base di quello si può agire nei confronti del singolo rischio.
9) Come si affrontano i rischi?
- Fregarsene
- Mitigations: vado a modificare il progetto (magari aumentando dei tempi e dei costi), per fare in modo di annullare la probabilità di accadimento di quel rischio
- Contigencies: vado ad imputare dei costi che mi coprano dall'accadimento
Mezzo a due ruote
Caratteristiche estetiche, costo di realizzazione inferiore a tot, consumi, cilindrata, altezza, lunghezza, larghezza, tempi di produzione e assemblaggio.
Uno scope fatto bene permette di evitare incomprensioni, più è dettagliato meglio è. Lo scope esclude quello che non bisogna andare a fare. Uno scope fatto male mi avrebbe fatto pensare di produrre una moto del genere, ma non è quella richiesta.
09/05 Obiettivo: garantire la realizzazione di quanto richiesto dal cliente (interno od esterno) evitando però di realizzare più di quanto richiesto, per non incorrere in maggiori tempi e costi di progetto. Costruire uno scope è un processo lungo, strutturato. Lo svolgimento avviene in 5 fasi principali:
- La prima cosa che va
Fatta è la Pianificazione delloscope, definire in modo strutturato come lo scope sarà definito, verificato e controllato, come sarà realizzata la WBS e come ne sarà verificata la completezza.
Definizione dello scope, è quella l'attività e bisogna scrivere lo scope statement, documento che descrive quello che viene realizzato, il come e le varie assunzioni -> viene definito nello scope statement ciò che si aspetta nella verifica dello scope per evitare di finire davanti a un giudice.
Tradurre lo scope statement nelle attività di progetto, cioè tradurlo in come bisogna farlo.
Creazione WBS, identificate tutte e sole le attività necessarie al raggiungimento degli obiettivi di progetto, struttura gerarchizzata delle attività di progetto.
Successivamente c'è la Verifica dello scope, il cliente vorrà verificare se quello che faccio nel progetto corrisponde allo scope su cui ci siamo messi d'accordo.
La chiusura di questa fase coincide con la pianificazione definitiva dello scope. In ultimo c'è il Controllo dello scope, quest'attività serve a verificare eventuali cambiamenti da apportare che saltano fuori nel corso del progetto. Se cambia lo scope deve cambiare il piano. Qualsiasi cambiamento allo scope di progetto avrà sempre ricadute su tempi, costi e rischi. Come viene fatto un buon scope statement? Versione dettagliata del Project charter, ma nei progetti non sempre è così dettagliato. 23 La definizione dello scope 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; obiettivi specifici spettano al PM, ricordare chegli obiettivi strategici spettano alla Committenza!- 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 dalla casa, ai software con le sue release alla documentazione, lista di requisiti, prototipi, output finale ecc.). Importante indicare anche quali deliverable non sono compresi;
- criteri di completamento: come faccio a dire che il deliverable è stato fatto? Criteri associati tipicamente a 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.
- 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 (laddove è consentito, e dipende dai progetti) questa cosa viene chiarita in anticipo, di interazione con il cliente, di modalità di
testing ecc. Sono quindi le regole general