Quest’area gestionale è finalizzata alla gestione degli obiettivi del progetto e quindi che includa tutte e soltanto le attività necessarie al suo conseguimento.
Distinguiamo due tipi di scopo:
o Product Scope
Le Funzioni e le Caratteristiche che devono essere garantite in un prodotto, in un Servizio
o Project Scope
Il lavoro che deve essere fatto al fine di consegnare un prodotto con specifiche caratteristiche e funzioni definite
Il Product Scope è normalmente gestito con strumenti quali l'analisi del Life Cycle etc., anche se è indicata per la gestione del Project Scope.
Il Product Scope è controllato tramite l'analisi delle specifiche di prodotto, mentre il Project Scope è controllato rispetto alla pianificazione, essi ovviamente devono essere altamente integrati
| Analisi Preparativa |
Questo processo ha per obiettivo il riconoscimento formale dell'esistenza di un nuovo progetto o l'abilitazione di un progetto in corso a passare alla fase successiva.
Il progetto spesso non è formalmente iniziato fino a quando non è completato uno studio di fattibilità, una pianificazione preliminare etc.
I progetti sono tipicamente autorizzati come risposta a:
o Richiesta di mercato
(i.e. un’azienda automobilistica per aumentare la produzione decide di costruire un nuovo impianto)
o Necessità Economiche
(i.e. si sviluppa un nuovo prodotto per aumentate le entrate)
o Richiesta Cliente
(i.e. una nazione commissiona una centrale elettrica)
o Sviluppi Tecnologici
(i.e. si procede a svilupparne un nuovo tipo di telefonino basato su nuove batterie divenute disponibili)
o Vincoli Legislativi
(i.e. si sviluppa un progetto di smaltimento di rifiuti tossici a fronte di una nuova legge in materia).
o Descrizione del Prodotto
Tutti i documenti che contengono le caratteristiche e le specifiche del prodotto/servizio, compresi i collegamenti con le attività necessarie per svilupparlo. Spesso la descrizione del prodotto è fornita dal cliente.
o Pianificazione Strategica
Tutti i progetti devono mirare al conseguimento di obiettivi strategici da valutare per selezionare i progetti stessi.
o Criteri di Selezione dei Progetti
Sono molto variegati e definiscono le linee guida di selezione (i.e. market share, reddittività, promozione, etc.)
o Dati storici
Dati storici relativi a casi precedenti, importanti per la selezione.
Metodi per la Selezione dei Progetti
Si possono identificare due ampie categorie di metodi selettivi:
o Basati sulla valutazione dei Guadagni: approcci comparativi, modelli economici, valutazione delle prestazioni
o Basati sull'ottimizzazione dei vincoli: modelli matematici, ottimizzazione Lineare, analisi multiobiettivo, etc.
I metodi in questione permettono di sviluppare DSS (Decision Support System) che si basano sia su tecniche tradizionali (alberi decisionali, scelte formate) che su tecniche specifiche (Processi Gerarchici Analitici, Analisi Logica, Simulazione etc)
Giudizio di Esperti
Il Giudizio di esperti è spesso richiesto per arrivare alle scelte finali e prevede di utilizzare:
§ Divisioni specifiche della struttura aziendale
§ Consulenti
§ Associazioni Tecniche Professionali
§ Gruppi Industriali
Project Charter
II Project Charter è il documento che formalmente riconosce l'esistenza di un progetto, deve includere direttamente o tramite riferimento le necessità contrattuali che il progetto si prefigge di raggiungere.
II Project Charter è definito da un manager esterno al progetto di livello adeguato e fornisce un mandato al Project Manager.
Per progetti sotto contratto il contratto stesso funge da Project Charter
Assegnazione/Identificazione del Project Manager
Il project Manager è normalmente definito al più presto possibile nello sviluppo di un progetto, deve essere identificato prima di attuare lo sviluppo della pianificazione generale e possibilmente prima di averne impostato una parte troppo estesa.
Vincoli
Condizioni che vincolano il PMT (budget, provvigioni contrattuali, etc.).
Ipotesi
Tutte le ipotesi fatte su fattori incerti, normalmente queste comportano l'assunzione di un certo livello di rischio che è in ogni caso necessario per la pianificazione degli obiettivi.
| Pianificazione degli Obiettivi e suoi Input |
Si mira all’emissione di un documento scritto che contenga una dettagliata pianificazione degli obiettivi e di possibili alternative come base per future decisioni.
Come input si utilizzano la descrizione del prodotto che funge anche da input per l'Analisi Preparativa e gli output di questa stessa.
Analisi del Prodotto
Quest’analisi è basata su tecniche mirate ad una migliore comprensione del prodotto, queste includono: value engeneering, system engeneering, value analysis, function analysis, QFD (Quality Function Deployment).
Analisi Costi/Benefici
Queste tecniche coinvolgono la determinazione qualitativa e quantitativa di costi (outlays) e benefici (returns) in funzione delle varie possibili alternative; il confronto si basa anche sull'analisi dei parametri economici classici quali payback period, ROI, IRR etc.
Identificazione degli Obiettivi – Valutazione delle
Alternative
Per completare una corretta identificazione di possibili alternative esistono diverse tecniche tipiche della gestione generale (i.e. brainstorming, lateral thinking).
Giudizi di Esperti
II giudizio di esperti è normalmente utilizzato per supportare questa fase.
Relazione sugli Obiettivi
La relazione sugli Obiettivi funge da riferimento per le future decisioni e per avere una conoscenza comune di queste.
Esso include:
o Descrizione del Lavoro SOW (Statement of Work)
o Giustificazione del progetto per valutare futuri trade-off
o Project Product, breve sommario sul Prodotto
o Project Deliverables, sommario sui sotto prodotti
o Obiettivi del progetto (come minimo: costi, tempi e qualità)
Devono essere
caratterizzati da tipo, unità di misura e valori quantitativi relativi e/o
assoluti.
Dettagli di Supporto
Devono favorire l'utilizzo della documentazione e includere relazioni su vincoli ed ipotesi.
Piano per la gestione degli Obiettivi
Il documento definisce come lo scopo del progetto è gestito.
|
☺ Leggi di Golub (da "Le leggi di Murphy") |
|
Le idee fumose servono ad evitare di stimare
gli eventuali costi di una loro realizzazione. |
|
La realizzazione di un progetto mal
pianificato richiede il triplo del tempo previsto; quella di un progetto
pianificato con la massima attenzione soltanto il doppio. |
Un punto chiave consiste nel definire correttamente la descrizione del lavoro da svolgersi: è importante chiarezza sia tecnica sia contrattuale.
Definiamo il SOW (Statement of Work) come la descrizione narrativa del lavoro richiesto per un progetto.
Questo talvolta è definito dal cliente e spesso invece sviluppato dal PM Team e proposto al cliente per l'approvazione.
In questo secondo caso appaiono due tipi di SOW: SOW usato nella proposta e il CSOW (Contract Statement of Work), come pure esistono un WBS (Work Breakdown Structure) e un CWBS (Contract Work Breakdown Structure).
Ovviamente particolare cura deve essere posta nella definizione del contratto al fine di evitare discrepanze tra SOW/WBS e CSOW/CWBS.
Errori in questa sede sono destinati a risultare di difficilissima risoluzione e sono spesso fatali per il buon successo del progetto.
Le principali cause di problemi nel SOW derivano da incomprensioni quali:
o Mischiare task, obiettivi, approvazioni ed istruzioni speciali
o Usare termini imprecisi (ottimale, approssimativamente, presso)
o Mancanza di ordine strutturale o cronologico
o Ampia variabilità delle attività richieste
o Ampie variazioni nella descrizione dei dettagli del lavoro
o Mancanza di revisione da parte di una terza parte.
Esempi tratti da casi reali:
Il SOW per un nuovo tipo di airbag per auto sportive include un numero di 10 test, il budget è tarato su 15 per sicurezza, alla fine dei test il cliente li dichiara inconcludenti e ne richiede altri l0 con un costo extra di 500 milioni.
Nel progetto di una centrale elettrica nel mezzo del deserto ci si accorge che la richiesta di “opere civili di supporto" include una strada di 40 km per il collegamento al centro abitato con un costo extra di oltre 60 miliardi.
La marina nel SOW richiede test in acqua per un siluro; il prototipo viene testato in vasche idrauliche, tuttavia la marina definisce come acqua le condizioni reali dell'Oceano Atlantico, si richiede di effettuare tutte le prove in mare con un costo addizionale di alcuni miliardi.
Il CSOW descrive di trasportare materiali in contenitori aereati; il carico viene posto in container open-top; nel viaggio una serie di acquazzoni torrenziali danneggia i beni, il cliente dichiara che intendeva aereati dal basso: la questione è in mano ad una corte giudiziaria per interpretare il corretto significato del termine.
Statement of work Handbook NHB56oo.2
NASA, Feb 1975
o Il Project Manager o i suoi referenti devono rivedere i documenti che autorizzano il progetto e ne definiscono gli obiettivi come pure rivedere studi e contratti collegati col livello corrente di sviluppo; è opportuno raccogliere una bibliografia di studi collegati e di esempi relativi a casi simili di SOW.
o Deve essere emessa una copia della WBS e subito dopo si deve cominciare un coordinamento tra gli elementi della CWBS e del SOW; ogni attività della CWBS preliminare deve essere estesa in SOW con una codifica corrispondente.
o Il PM può costituire un team per preparare SOW includendo personale ritenuto capace, con esperienza tecnica nelle aree del progetto includendo anche rappresentanti delle acquisizioni, gestione finanziaria, realizzazione, controllo qualità più ogni altra attività coinvolta.
o Prima di cominciare a preparare la SOW il PM deve organizzare un meeting preliminare riassumendo il programma della CWBS e la natura della SOW destinato a restare un riferimento duraturo.
o Il PM può assegnare team specifici per identificare specifiche, criteri e documentazioni da includere nella SOW assegnandone la definizione a responsabili specifici, i membri di questi team devono identificare e ottenere copie di tutto il materiale tecnico necessario per il progetto.
o Il PM deve preparate una checklist dettagliata evidenziando gli elementi obbligatori e quelli opzionali della SOW
o Il PM deve enfatizzare l'uso di liste preferenziali per la definizione di standard, manuali, norme, hardware a software da impiegarsi nello sviluppo tecnico del progetto.
o Le stime dei costi preparate da parte degli esperti debbono essere riviste da coloro che preparano la SOW al fine di identificare componenti non essenziali al progetto
o Il PM deve preparare uno scheduling preliminare per la raccolta coordinata di frammenti della SOW che permettano di rispettare il planning di emissione delle RFP (Request for Proposals); ovviamente quest’attività deve avvenire abbastanza anticipatamente da facilitare il coordinamento a garantire di finire prima della preparazione delle RFF.
o Ogni SOW più lungo di due pagine deve avere un indice conforme alla codifica del CWBS.
o S’invita a limitare al minimo la presenza di elementi nel SOW non compresi nel CWBS
o Chiara e Precisa descrizione delle Attività (lettori diversi) poiché funge da base per il contratto
o Eliminare ambiguità, definire tutti gli obblighi governativi, fissare scadenze per le attività di approvazione a definire nel dettaglio materiali/servizi richiesti al cliente (natura, condizione, tempo etc.)
o Ricordare che ogni attività di controllo anche temporaneo esterna al contractor può portare ad una perdita di responsabilità da parte di questi.
o Nel definire le specifiche usare raramente la terminologia passiva (non il commissioning di HVAC può essere fatto, ma il contractor deve fare il commissioning di HVAC), usare il termine “deve” piuttosto che “può” per tutte le attività richieste.
o Limitare le abbreviazioni a quante di uso comune, fornire una lista all'inizio della SOW; la prima volta che si fornisce un termine fornire abbreviazione e dizione completa.
o Se necessario suddividere le responsabilità tra contract, subcontractor e cliente, dedicate una sezione separata della SOW per delineare nel dettaglio questi aspetti.
o Non richiedere specifiche tecniche extra, definire gli obiettivi e lasciare al contract i modi.
o Definire chiaramente le specifiche sia a fini tecnici sia contrattuali, non dire mai “come richiesto”, ma specificare a carico di chi sono i controlli ed i giudizi.
o Evitate di includere materiale estraneo al progetto; definire a parte le specifiche sui dati tecnici di progetto in un’appendice, ed evitare che questa diventi più estesa dello stretto necessario.
o Non ripetere specifiche già definite in altri documenti, porre piuttosto un riferimento a queste.
Statement of work Handbook NHB56oo.2
NASA, Feb 1975
q La SOW se usata in combinazione con il CWBS consente al contractor di valutare manpower e risorse richieste da ciascun’attività del Progetto?
q I doveri del contractor sono definiti in modo dettagliato al fine di rendergli chiaro quali sono i suoi impegni e di permettere al rappresentante che firma i reports di accettazione di comprendere se le attività sono state completate?
q Le parti della SOW sono scritte in modo da non richiedere chiarimenti su quando e cosa si richiede al contractor?
q Quando necessario, i riferimenti ad altri documenti risultano chiari? Propriamente citati? Sono effettivamente necessari o possono essere parzialmente omessi?
q Le specifiche tecniche e/o dimostrazioni risultano applicabili? Se sì, sono propriamente riferite agli elementi della SOW?
q Le direttive sono distinguibili dalle informazioni generali?
q C’è una specifica temporale per ogni deliverable? Si utilizzano work days o calendario?
q Le quantità dei deliverables sono definite propriamente?
q Si è fatto un controllo ortografico dei titoli? Garantito confrontabilità fra i sottoparagrafi? Coerenza titolo testo? Si utilizza un sistema coerente nella codifica della SOW (alfanumerico o multidecimale)?
q Risulta possibile un riferimento incrociato con il CWBS?
q Sono stati rispettati i regolamenti per le acquisizioni?
q Si è eliminato tutto il materiale/servizi estranei?
q G1i elementi guida del SOW e la configurazione a basso livello può essere riassunta come un CWBS di terzo livello?
q Tutte le specifiche tecniche sui dati sono riassunte in appendice?
q Si sono controllate tutte le specifiche relative alla sicurezza ?
Statement of work Handbook NHB56oo.2
NASA, Feb 1975
| Definizione degli obiettivi |
Quest’attività comporta la suddivisione dei deliverables del progetto principale in componenti minori più facilmente gestibili al fine di:
o Migliorare l'accuratezza delle stime relativi a Costi, Tempi e Risorse
o Definire una base di riferimento per il controllo di progetto
o Facilitare l'assegnazione di chiari incarichi e livelli di responsabilità
Gli output dei processi nelle altre aree di competenza devono essere utilizzati quali riferimento per valutare l'influenza sul progetto quali input di quest’attività.
Quale output si ottiene il WBS (Work Breakdown Structure), struttura dei deliverables.
Work Breakdown Structure Template
Spesso vengono utilizzati i WBS relativi a precedenti progetti quali template per lo sviluppo del nuovo sulla base di analogie.
Tuttavia alcune aree tematiche hanno standard a semistandard WBS che possono essere impiegati quali riferimenti (template).
Decomposition
Lo scopo della metodologia è la suddivisione dei deliverables in sottoclassi facili da gestire in termini di planning esecuzione, controllo e chiusura.
Si sviluppa in passi successivi quali:
o Identificare i principali elementi (spesso i deliverables e il Project Management)
o Decidere se è possibile effettuare stime adeguate su tempi e costi al livello di dettaglio di ciascun elemento
o Identificare gli elementi costitutivi del deliverables in termini tangibili
o Verificare la correttezza della Decomposizione
§ Verifica che i termini di basso livelli siano necessari e sufficienti per completare l’elemento padre
§ Verifica che ogni termine sia chiaramente e completamente definito
§ Verifica che ogni elemento sia pianificabile, definito a budget e assegnabile ad un’unità organizzativa in termini di responsabilità
Nel planning del progetto il Project Manager deve strutturare il lavoro in piccoli elementi che siano:
Gestibili: possibilità di assegnare autorità e responsabilità
Indipendenti: con minima interfaccia con le altre attività
Integrabili: in modo da poterli combinare in pacchetti generali
Misurabili: di cui sia stimabile l'avanzamento ed il successo
Il WBS è un elemento chiave in quanto:
Fornisce una descrizione del progetto complessivo come somma di elementi
Supporta la definizione di un Planning
Consente di stimare costi e budget
È organizzato per controllare tempi, costi e prestazioni
Gli obiettivi possono essere collegati con le risorse aziendali
Si può stabilire procedure per scheduling e un reportage
Si può iniziare a realizzare un network e un controllo di gestione
Si possono assegnare le responsabilità per ogni elemento
Il WBS è una struttura gerarchica che spezza il lavoro in elementi e sottoelementi a vari livelli.
|
|
1 |
Programma Totale |
|
Livelli Manageriali |
2 |
Progetto |
|
|
3 |
Task |
|
|
|
|
|
|
4 |
Sub Task |
|
Livelli Tecnici |
5 |
Work Package |
|
|
6 |
Level of Effort |
o I primi tre livelli del WBS rappresentano uno sforzo di integrazione e non dovrebbero essere collegati a specifiche divisioni aziendali, i cui sforzi dovrebbero invece essere inclusi nei livelli quattro e cinque.
o La somma di tutti gli elementi di un livello deve rappresentare la totalità del lavoro.
o Ogni attività lavorativa deve essere assegnata a uno ed un solo livello.
o Il livello di gestione di un progetto è talvolta chiamato il Work package level e può corrispondere a un qualsivoglia livello fra il 2° ed il 6°
o La WBS deve essere accompagnata da una descrizione degli obiettivi e sforzi richiesti: si tende a riprodurre le richieste del cliente all'interno della WBS.
o Normalmente la miglior politica per il PM è di lasciare ai Line Manager il compito di identificare i rischi a livello di SOW.
Alcune compagnie cercano di definire i livelli 1-3 in modo univoco per tutti i progetti cambiando i soli livelli 4-6: funziona per compagnie che realizzano molti progetti abbastanza simili.
|
|
|
|
|
|
|
|
|
|
||
Il WBS è da considerare elemento fondamentale quale punto di partenza per l’applicazione di Tools Grafici alle attività di Controllo e Valutazione.
Più lunghi diventano i work packages e più difficile e soggettivo diventa la valutazione del WIP (work in process), a meno di introdurre milestones intermedie.
Le attività del WBS devono:
o Essere Chiaramente definite come inizio e fine.
o Essere utilizzabili per controllare risultati e aspettative.
o Essere stimate sulla durata totale (non quando iniziano e finiscono).
o Essere strutturate per ridurre al minimo necessario controlli e documenti.
o Rappresentare le unità di lavoro al livello in cui il lavoro è effettuato.
o Chiaramente distinguere un work package dagli alti assegnati al singolo gruppo funzionale.
o Contenere definizioni di date di inizio e fine con riferimento a realizzazioni pratiche.
o Specificare un budget in termini di denaro, ore uomo o altro.
o Limitare il lavoro da sviluppare a periodi brevi per ridurre il WIP
Talvolta il WBS è definito dal cliente, nel caso sia il contractor a realizzarlo, il PM deve tener conto del:
o Complessità del Programma e Specifiche Tecniche (i.e. SOW)
o Costo del progetto
o Tempo Disponibile per il progetto
o Le specifiche risorse disponibili
o La struttura interna di controllo e gestione di Contractor e Cliente
o Il numero di Subcontrator
Quali criteri guida si sottolineano:
o WBS deve essere facile da capire
o Tutti gli scheduling devono riferirsi al WBS
o Non si devono ridurre le attività a livello bassissimo (costo/beneficio)
o WBS flessibile per adattarsi a cambi negli obiettivi
o Molti elementi della WBS variano fra il o.5% e 2.5% del costo del progetto al livello più basso
o Sviluppare il WBS suddividendo il totale delle attività in sotto-elementi discreti e logici, includendo eventualmente più centri di costo e più contractor su ciascun elemento se necessario.
o Controllare il WBS in termini di completezza, compatibilità e continuità dei lavori proposti.
o Verificare che il WBS soddisfi aspetti funzionali (ingegneria, manufacturing, test) e di progetto (hardware, services etc.) includendo ovviamente anche i costi
o Controllare che il WBS fornisca la suddivisione di tutti i lavori logici
o Stabilire responsabilità per ciascun elemento del WBS
o Verificare che le capacità di report e misura dell'azienda siano compatibili con gli elementi del WBS.
Statement of work Handbook NHB56oo.2
NASA, Feb 1975
Ai livelli 1-3 la definizione delle attività può essere facilmente basata su WBS templates; tuttavia questo non è possibile per i livelli 4-6, infatti:
o Suddividere il lavoro in attività piccole può comportare la definizione di centinaia o migliaia di elementi di costo troppo complessi da gestire; tipicamente si cerca di mantenere i work packages sulle 2oo-3oo ore, con circa due settimane di durata, ovviamente questo comporta un’estrema ramificazione su grandi progetti (i.e. con un milione di ore di lavoro dirette).
o La ramificazione di dettaglio può permettere il controllo costi e delle prestazioni solo se i Line Manager sono in grado di effettuare questi controlli.
o Il WBS è la base per le attività di scheduling (PERT, ADM), ovviamente a basso livello le inter-correlazioni tra le attività diventano troppo complesse e numerose per consentire una qualsivoglia analisi.
Possono essere utilizzati parecchi metodi per la scomposizione, nel caso degli impianti industriali si evidenziano le seguenti Logiche:
o Funzionale: Si divide l'Impianto in sottosistemi e quindi in modo funzionale per l'ingegneria di base e l'avviamento
o Spaziale: Basato sul layout in termini lineari (piping, strade etc.), planimetrico (impiantistica tradizionale), tridimensionale (piattaforme a mare, costruzioni civili), ovviamente è vicino alla logica di cantiere.
o Processi di Lavoro: Basato sui processi di realizzazione del progetto (i.e. ingegneria, acquisti, costruzione avviamento)
o Scomposizione Fisica: Legata alla struttura del prodotto e simile quindi alla distinta base, utile per il montaggio
o Obiettivi: si evidenziano gli obiettivi, i milestones distribuiti nel tempo sono utili per i livelli alti della WBS e legata spesso alla logica funzionale.
q Sviluppare un WBS preliminare da mantenere come riferimento per i primi tre livelli
q Assicurarsi che il contractor si impegni ad estendere, compatibilmente con le proprie capacità aziendali, il WBS in caso d’evoluzioni da parte degli altri contractors
q A seguito delle negoziazioni, il CWBS incluso nel contratto non dovrebbe andare sotto il terzo livello
q Assicurarsi che il CWBS definito sia compatibile con le capacità di reportage
q Assicurarsi che il CWBS sia compatibile con il sistema organizzativo e della gestione del contractor
q Rivedere il CWBS al fine di trovare correlazioni fra: le specifiche, gli elementi contrattuali, i deliverables contrattuali, le specifiche sui dati, le attività e le specifiche di gestione del progetto.
q Definire gli elementi del CWBS al livello cui sono necessari (dizionario del WBS)
q Specificare caratteristiche dei reportage per gli elementi del CWBS
q Assicurarsi che il CWBS riporti attività misurabili, con eventuali livelli d’attività e subcontratti.
q Assicurarsi che il costo totale di un particolare livello sia uguale alla somma dei costi degli elementi costitutivi del progetto al livello più basso.
Statement of work Handbook NHB56oo.2
NASA, Feb 1975
o L'unione di tutte le attività di un livello di un ramo è lo stesso insieme delle attività della radice
o Non vi sono intersezioni fra le attività contenute in due rami diversi allo stesso livello.
o Ogni passaggio di livello deve essere basato sulla stessa logica.
o I Livelli diversi della WBS possono essere sviluppati secondo logiche differenti.
o Ogni livello della WBS deve essere raggruppati in modo da facilitare ricerche di WP (work packages) utili per la pianificazione ed il controllo.
o Al diminuire della dimensione del WP diventa più facile la gestione da parte del diretto responsabile e più difficile il controllo di progetto per l'elevato numero di WP.
o La WBS si incrocia poi con la OBS (organization breakdown structure) a livello di WP, eventuali altre interazioni trasversali ai rami della WBS con la OBS devono essere esplicitate.
o Le parti di WBS vanno compilate dai responsabili per la gestione e controllo siano essi interni o esterni.
o La WBS può essere sviluppata ad hoc oppure su preesistenti templates.
o La logica d’aggregazione/disaggregazione si basa sull'esplicitare i deliverables e gli obiettivi, è consigliabile prevedere una logica di codifica che permetta di aggregare e disaggregare le varie voci con riferimento agli obiettivi desiderati.
o Si tenga presente che possono esistere obiettivi e funzioni trasversali al controllo impostato nella struttura del WBS: questi vanno evidenziati ed esplicitati.
| Verifica degli Obiettivi: Input, Tools & Output |
Questa attività è basata sui deliverables prodotti e sulla documentazione emessa, tramite ispezioni che comprendono misure, esami e test, si verifica la
conformità alle specifiche di base, la documentazione d’accettazione formale proviene dal cliente o dallo sponsor.
Questa attività si differenzia da quelle del controllo di qualità in quanto queste si focalizzano sulla correttezza dei risultati ottenuti, mentre la verifica degli obiettivi si focalizza sulla accettazione dei deliverables.
| Controllo dei cambiamenti degli obiettivi: Input, Output, Tools |
Questa attività si basa sul WBS costruito e sui report relativi alla prestazione misurata e sul piano di gestione degli obiettivi ovvero sul documento che definisce come lo scopo del progetto è gestito.
Ovviamente sono possibili anche richieste volontarie o forzate nel cambiare gli obiettivi, le richieste di cambiamenti possono essere orali o scritte, dirette o
indirette, per esempio
o Evento Esterno: Cambio di Legge Governativa
o Errore nel definire lo scopo del prodotto (non si riesce a fornire ad un nuovo televisore certe funzioni
o Errore nel definire lo scopo del progetto (uso del BOM invece del WBS)
o Cambio nei valori aggiunti (nuova tecnologia riduce i costi ambientali del service)
Sistemi di controllo cambiamenti obiettivi
Definisce le procedure, documenti e autorizzazioni per gestire cambiamenti negli obiettivi e deve integrarsi col Sistema di Controllo dei Cambiamenti (e col CCB) e con tutti i sistemi di controllo del product scope.
Performance Measurement
Sistemi per la valutazione della performance e ogni suo cambiamento al fine di identificarne eventuali cause.
Pianificazione Addizionale
La maggior parte dei progetti richiedono di sviluppare modifiche e aggiunte al planning per compensare l'evoluzione del progetto.
Cambi negli Obiettivi e nelle capacità
Ogni modifica accettata alle capacità del prodotto/obiettivi del progetto secondo quanto definito nel WBS. Questo comporta planning addizionale per sistemare tempi, risorse e costi, correzione della documentazione ed informazione dei membri del team.
Azioni Correttive
Tutte le azioni per riportare un progetto a poter rispettare le prestazioni attese secondo il planning.
Lezioni Apprese
Tutti i cambiamenti negli obiettivi debbono essere documentati e analizzati al fine di estendere il database storico aziendale al fine di poter supportare il progetto corrente come pure altri progetti presenti e/o futuri.
☺
LE MODICHE AI PROGETTI SECONDO MURPHY
Prima legge
delle modifiche
Qualsiasi informazione che comporti un cambiamento nel progetto sarà trasmessa al progettista dopo - e soltanto dopo - che tutti i disegni sono stati completati. (Meglio conosciuta come Legge dell’"Adesso me lo dicono! ")
Corollario:
In
casi semplici, che presentino una soluzione ovviamente giusta ed una
ovviamente sbagliata, è spesso più saggio scegliere quella sbagliata, in
modo da avere già pronta la conseguente modifica.
Seconda legge delle modifiche
Quanto più innocua sembrerà una modifica, tanto più le sue conseguenze si estenderanno e maggiore sarà il numero dei disegni che dovranno essere rifatti.
Terza legge delle modifiche
Se, quando il completamento di un disegno è imminente, le dimensioni vengono finalmente comunicate come sono in realtà - invece di come si era pensato che fossero - si fa sempre prima a ricominciare tutto da capo.
Corollario:
E' normalmente poco
pratico preoccuparsi in anticipo di eventuali ostacoli: se non ce ne sono,
qualcuno si preoccuperà di crearvene.
