Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Project planning and implementation according ECSS ST-M-10

Confronto e sinergie tra la di un progetto secondo la norma ISO 9001 e lo standard ESA ECSS-ST-M per la gestione dei progetti del settore SPAZIO

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

Project planning and implementation according ECSS ST-M-10

  1. 1. Appunti sulla pianificazione e la realizzazione di un progetto in ambito spaziale secondo gli standard ECSS Fonte: standard ECSS-M-ST-10C Rev. 1 del 6 marzo 2009 by Mario Gentili
  2. 2. Space project management - Project planning and Implementation 1 1 Sommario 1 GLOSSARIO ..............................................................................................................................................3 2 PROJECT PLANNING.................................................................................................................................5 2.1 INTRODUZIONE........................................................................................................................................... 5 2.2 SCOPO ED OBIETTIVI DEL PROGETTO ............................................................................................................... 5 2.3 ASSESSMENT RISORSE.................................................................................................................................. 5 2.4 RIUSO ...................................................................................................................................................... 5 2.5 VALUTAZIONE DEL RISCHIO ........................................................................................................................... 6 2.6 APPROCCIO DI SVILUPPO .............................................................................................................................. 6 2.7 RISULTATI DEL PROGETTO............................................................................................................................. 6 2.8 REQUISITI E VINCOLI DEL CLIENTE ................................................................................................................... 6 2.9 DOCUMENTI DEI REQUISITI DEL PROGETTO (PRD)............................................................................................. 6 2.10 PROJECT MANAGEMENT PLAN ....................................................................................................................... 6 3 PROJECT ORGANIZATION.........................................................................................................................8 3.1 INTRODUZIONE........................................................................................................................................... 8 3.2 STRUTTURA ORGANIZZATIVA ......................................................................................................................... 8 3.3 COMUNICAZIONE E REPORTING ..................................................................................................................... 8 3.4 AUDITS..................................................................................................................................................... 8 4 PROJECT BREAKDOWN STRUCTURES .......................................................................................................9 4.1 INTRODUZIONE........................................................................................................................................... 9 4.2 ALBERO DELLE FUNZIONI -FUNCTION TREE ....................................................................................................... 9 4.3 ALBERO DELLE SPECIFICHE - SPECIFICATION TREE............................................................................................... 9 4.4 ALBERO DEL PRODOTTO - PRODUCT TREE ........................................................................................................ 9 4.5 WORK BREAKDOWN STRUCTURE (WBS) ....................................................................................................... 10 4.6 WORK PACKAGE (WP) .............................................................................................................................. 10 4.7 ORGANIZATION BREAKDOWN STRUCTURE (OBS) ............................................................................................ 10 5 PROJECT PHASING – PROJECT CVS ......................................................................................................... 11 5.1 INTRODUZIONE......................................................................................................................................... 11 5.2 RAPPORTO TRA ACCORDI COMMERCIALI E FASI DEL PROGETTO ........................................................................... 12 5.3 LE FASI DI PROGETTO................................................................................................................................. 13 5.3.1 Phase 0 (Mission analysis/needs identification).............................................................................. 13 5.3.1.1 Attività principali .................................................................................................................................... 13 5.3.1.2 Review associate .................................................................................................................................... 13 5.3.2 Phase A (Feasibility) ........................................................................................................................ 13 5.3.2.1 Attività principali .................................................................................................................................... 13 5.3.2.2 Review associate .................................................................................................................................... 13 5.3.3 Phase B (Preliminary definition)...................................................................................................... 14 5.3.3.1 Attività principali .................................................................................................................................... 14 5.3.3.2 Review associate .................................................................................................................................... 14 5.3.4 Phase C (Detailed definition)........................................................................................................... 15 5.3.4.1 Attività principali .................................................................................................................................... 15 5.3.4.2 Review associate .................................................................................................................................... 15 5.3.5 Phase D (Qualification and production) .......................................................................................... 15 5.3.5.1 Attività principali .................................................................................................................................... 15 5.3.5.2 Review associate .................................................................................................................................... 15 5.3.6 Phase E (Operations/utilization)...................................................................................................... 16 5.3.6.1 Attività principali .................................................................................................................................... 16 5.3.6.2 Review associate .................................................................................................................................... 16 5.3.7 Phase F (Disposal)............................................................................................................................ 17
  3. 3. Space project management - Project planning and Implementation 2 5.3.7.1 Attività principali .................................................................................................................................... 17 5.3.7.2 Review associate .................................................................................................................................... 17 6 ALLEGATI ............................................................................................................................................... 18 6.1 A- PROJECT MANAGEMENT PLAN (PMP) – DRD............................................................................................ 18 6.1.1 Contenuti del documento:............................................................................................................... 18 6.2 B - PRODUCT TREE - DRD .......................................................................................................................... 20 6.2.1 Contenuti del documento:............................................................................................................... 20 6.3 C - WORK BREAKDOWN STRUCTURE (WBS) – DRD........................................................................................ 21 6.3.1 Contenuti del documento:............................................................................................................... 21 6.4 D - WORK PACKAGE (WP) DESCRIPTION – DRD............................................................................................. 22 6.5 E - PROGRESS REPORT – DRD..................................................................................................................... 23 6.6 F - ECSS MANAGEMENT BRANCH DOCUMENTS DELIVERY PER REVIEW ................................................................. 24 6.7 G -DOCUMENTI PERIODICI O A SEGUITO DEL VERIFICARSI DI UN INCIDENTE ........................................................... 25 6.8 H - WBS LIVELLO DI DETTAGLIO .................................................................................................................. 26 7 BIBLIOGRAPHY....................................................................................................................................... 27
  4. 4. Space project management - Project planning and Implementation 3 1 Glossario Sigla Descrizione AR acceptance review B/L baseline CBCP current baseline cost plan CDR critical design review CRR commissioning result review DRD document requirements definition DRL document requirements list EAC estimate at completion EGSE electrical ground support equipment ELR end-of-life review ETC estimate to completion FRR flight readiness review GSE ground support equipment ILS integrated logistic support ITT invitation to tender LRR launch readiness review MCR mission close-out review MDR mission definition review MGSE mechanical ground support equipment N/A not applicable OBCP original baseline cost plan OBS organizational breakdown structure ORR operational readiness review PDR preliminary design review PMP project management plan PRD project requirements documents PRR preliminary requirements review QR qualification review RFP request for proposal RFQ request for quote
  5. 5. Space project management - Project planning and Implementation 4 SRR system requirements review WBS work breakdown structure WP work package
  6. 6. Space project management - Project planning and Implementation 5 2 Project planning 2.1 Introduzione La pianificazione e l’implementazione di un progetto spaziale è l’insieme delle attività che permettono di realizzare l’intero ciclo di vita del progetto stesso, dal suo inizio alla sua fine. Le attività devono tener conto della catena cliente-fornitore e ricevono input da tutte le fasi del progetto e prevedono la stretta cooperazione tra tutti i domini del progetto stesso. Un progetto o sistema spaziale, è sempre contraddistinto da tre segmenti (vedere ECSS-E-ST-70): • space segment, • ground segment, • launch service segment. In linea di principio, una proposta per avviare un progetto spaziale può avere origine da qualsiasi parte. Tuttavia, coloro i quali più comunemente danno origine ad un progetto spaziale (sponsor) sono: • singoli governi o cooperazione tra un certo numero di governi; • agenzie spaziali nazionali o internazionali, singolarmente o collettivamente; • comunità scientifiche nazionali o internazionali; • operatori di sistemi spaziali commerciali. 2.2 Scopo ed obiettivi del progetto Lo scopo e gli obiettivi del progetto sono definiti dallo sponsor nel documento mission statement (il Project Management Institute-PMI, www.PMI.com, parla di project charter) che include i parametri chiave di prestazione, i requisiti e i vincoli tecnici e programmatici da applicare al progetto. Normalmente sono coordinati con il top level customer, se ne è stato assegnato uno. 2.3 Assessment risorse Si tratta della fase, effettuata congiuntamente tra cliente e fornitore, tesa a valutare la disponibilità di: • know-how scientifico e tecnologico, • tecnologia necessaria, • risorse umane, • formazione, per attuare il progetto. Il risultato di questa valutazione fornisce significative indicazioni su risorse, costi e tempi del progetto e alla successiva valutazione del rischio tecnico e programmatico. 2.4 Riuso Si tratta di fase tesa a valutare il riutilizzo di prodotti esistenti e viene generalmente eseguita come risposta diretta a un requisito del cliente. Analogamente alla fase di assessment, il risultato di questa valutazione fornisce significative indicazioni su risorse, costi e tempi del progetto e alla successiva valutazione del rischio tecnico e programmatico.
  7. 7. Space project management - Project planning and Implementation 6 2.5 Valutazione del rischio Le valutazioni iniziali dei rischi tecnici e programmatici di un progetto sono eseguite dal cliente, sulla base degli input dello sponsor del progetto rispetto allo scopo e agli obiettivi del progetto, insieme ai vincoli tecnici e programmatici identificati da applicare al progetto. La valutazione iniziale viene successivamente ampliata regolarmente per includere altri parametri rilevanti, man mano che diventano disponibili e man mano che il progetto matura. Valutazioni di rischio complete sono condotte a ogni revisione del progetto principale. 2.6 Approccio di sviluppo L’approccio di sviluppo per un progetto è definito congiuntamente dal cliente e dal fornitore per conformarsi documento di mission statement ai requisiti e ai vincoli della missione 2.7 Risultati del progetto Il cliente ha la responsabilità di definire i prodotti consegnabili, necessari per soddisfare la mission statement dello sponsor. 2.8 Requisiti e vincoli del cliente I requisiti e i vincoli del cliente sono preparati dal cliente in base alle uscite delle precedenti fasi (da 1.2 a 1.7). Sono esplicitati in un formato adatto per l’applicazione diretta in un bando di gara (ITT - Invitation To Tender). Riguardano i requisiti tecnici e programmatici, nonché i vincoli politici, commerciali e industriali da applicare al progetto e rappresentano, collettivamente, i documenti dei requisiti del progetto (PRD – Project Requirement Documents). 2.9 Documenti dei requisiti del progetto (PRD) I documenti dei requisiti del progetto (PRD) sono parte integrante di un bando di gara, o di una richiesta di proposta (RFP – Request For Proposal) o una richiesta di preventivo (RFQ – Request For Quote) preparata e rilasciata da un cliente a potenziali fornitori. Il PRD, in genere, comprende: • statement of work (è il project charter del PMI), • requisiti tecnici documentati in nella Specifica dei Requisiti tecnici, come definito in ECSS-E- ST-10-06, • requisiti di gestione, • requisiti di ingegneria, • requisiti di garanzia del prodotto, • requisiti programmatici, • altri requisiti specifici del progetto (ad esempio distribuzione geografica, filosofia del modello da applicare), • elenco dei requisiti dei documenti (DRL – Document Requirement List), • requisiti di gara. 2.10 Project management plan Il Piano di Progetto iniziale (o top level PMP - Project Management Plan) è l’insieme dei documenti o dei piani che devono essere sviluppati per ognuno dei domini (il PMI li chiama Aree di conoscenza) di un progetto. Generalmente si articola nei piani relativi a: ID Area di conoscenza 1 Gestione dell’integrazione di prj
  8. 8. Space project management - Project planning and Implementation 7 ID Area di conoscenza 2 Gestione dell’ambito (scope) 3 Gestione dei Tempi 4 Gestione dei Costi 5 Gestione della Qualità 6 Gestione delle Risorse umane 7 Gestione della Comunicazione 8 Gestione dei Rischi 9 Gestione degli Approvvigionamenti 10 Gestione degli Stakeholders
  9. 9. Space project management - Project planning and Implementation 8 3 Project organization 3.1 Introduzione L’istituzione di un’organizzazione ben strutturata e coerente per attuare un progetto, a tutti i livelli nella catena di clienti-fornitori, è un fattore chiave per garantire un approccio gestionale efficace ed efficiente. Ad ogni livello nella catena cliente-fornitore, un’organizzazione di progetto può essere costruita come un team di progetto autonomo, che contiene tutte le discipline necessarie all’interno della struttura del team o, più spesso, può essere costruita attorno a un team di progetto principale che racchiude le funzioni chiave del progetto, e che si rivolge all’esterno per la fornitura di altre competenze, attività o servizi. • Ogni cliente e fornitore deve individuare il proprio responsabile di progetto, che, tra l’altro, ha l’autorità di firmare gli accordi commerciali. • Se il progetto ha collegamenti con altri progetti, ogni cliente e fornitore deve individuare il responsabile delle relazioni. • Se un cliente o fornitore impiega consulenti o altri specialisti per assisterlo nello svolgimento delle sue funzioni, devono essere definiti i ruoli, le responsabilità e l’autorità di questi consulenti e specialisti. • Quando un cliente fornisce un prodotto a un fornitore, deve individuare il responsabile di prodotto per la fornitura. 3.2 Struttura organizzativa È essenziale che la struttura organizzativa del progetto sia organizzata in modo da includere tutte le competenze necessarie per implementare il progetto con funzioni ben definite, nonché chiare linee di comunicazione e reporting, inter-relazioni e interfacce. Tutti gli attori del progetto, al di sotto del top level customer e al di sopra del (i) fornitore (i) di più basso livello, hanno il ruolo sia di fornitori, sia di clienti, e le loro strutture organizzative devono soddisfare entrambi i ruoli. La struttura organizzativa fornisce una chiara e inequivocabile definizione e assegnazione dei ruoli e delle responsabilità individuali assieme all’identificazione delle necessarie autorità per l’implementazione dell’organizzazione del progetto (sia interna al gruppo di lavoro, sia esterna, in caso di ricorso a fornitori esterni). 3.3 Comunicazione e reporting Efficaci mezzi di comunicazione sono strumenti essenziali per garantire un’interazione chiara ed efficiente tra tutti gli attori del progetto, nonché tra il team di progetto e le sue interfacce esterne. La tecnologia dell’informazione è il mezzo principale per lo scambio di informazioni. La comunicazione serve inizialmente per fornire chiarezza sugli obiettivi e gli obiettivi del progetto e, successivamente, per supportare il lavoro quotidiano del team di progetto. Le relazioni periodiche sono uno strumento importante per lo scambio di informazioni relative allo stato di avanzamento del progetto 3.4 Audits Gli audit sono attività indipendenti di verifica e controllo per assicurare che i processi e le procedure del progetto raggiungano gli obiettivi prefissati nei tempi e modi previsti dal piano di progetto. Sono fondamentali per individuare aree di criticità e si esplicano in richieste di modifica (change request) che in genere portano ad azioni correttive e/o azioni preventive.
  10. 10. Space project management - Project planning and Implementation 9 4 Project breakdown structures 4.1 Introduzione La Project breakdown structures fornisce le basi di una conoscenza comune del progetto tra tutti gli attori del progetto e consiste nella scomposizione di attività complesse in attività più semplici da gestire. La metodologia di implementazione è quella descritta nel seguito. 4.2 Albero delle funzioni -Function tree L’albero delle funzioni consiste nella suddivisione delle prestazioni del sistema in funzioni. Ogni funzione è scomposta in sotto-funzioni indipendentemente dal tipo di prodotti coinvolti. L’approccio "funzione" viene applicato durante la fase di avvio del progetto o durante la fase di definizione del sistema. 4.3 Albero delle specifiche - Specification tree L’albero delle specifiche definisce la relazione gerarchica di tutte le specifiche dei requisiti tecnici per i diversi elementi di un sistema o prodotto. 4.4 Albero del prodotto - Product tree L’albero del prodotto è la suddivisione del progetto in livelli successivi di prodotti o elementi hardware e software, articolati per eseguire le funzioni identificate nell’albero delle funzioni. Tuttavia, l’albero delle funzioni e l’albero del prodotto non si rispecchiano necessariamente l’un l’altro. La struttura del prodotto include i modelli di sviluppo, il Ground Support Equipment - GSE, gli strumenti di integrazione e le apparecchiature di prova e gli elementi esterni necessari per convalidare il prodotto finale e la documentazione dell’Integrated Logistic Support - ILS. Comprende items sottoposti al controllo della configurazione del cliente e items che sono oggetto di una specifica dei requisiti tecnici. L’albero del prodotto costituisce la base per l’elaborazione della struttura di ripartizione del lavoro del progetto. Esempio: Space System Space Segment Ground Segment PayloadPlatform GSE Mission Control Center Payload Control Center Communications System Structure Thermal control On-board power supply Attitude control Data handling Instrument 1 MGSE EGSEInstrument 2 Instrument 3
  11. 11. Space project management - Project planning and Implementation 10 4.5 Work breakdown structure (WBS) La WBS è la struttura principale utilizzata nella gestione di un progetto e fornisce un quadro per la gestione dei costi, della pianificazione e della realizzazione tecnica. Divide il progetto in pacchetti di lavoro gestibili, organizzati in base alla natura del lavoro, suddividendo il lavoro totale da eseguire in livelli crescenti di dettaglio. La WBS deriva dalla struttura del prodotto, i cui elementi selezionati vengono estesi per includere funzioni di supporto (ad esempio gestione, ingegneria, garanzia del prodotto) e servizi associati (ad esempio, strutture di test). Esempio: Space System Space Segment Ground Segment PayloadPlatform GSE Mission Control Center Payload Control Center Communications System Structure Thermal control On-board power supply Attitude control Data handling Instrument 1 MGSE EGSEInstrument 2 Instrument 3 Management tasks Engineering tasks Product Assurance tasks Support function extensions 4.6 Work package (WP) Un WP è un qualsiasi elemento della WBS che può essere misurato e gestito per la pianificazione, il monitoraggio e il controllo. I pacchetti di lavoro di controllo sono identificati dal fornitore a quel livello della WBS in cui è richiesta la visibilità e il controllo e per il quale deve essere fornito un report. I pacchetti di lavoro di controllo rappresentano lo scope totale del progetto e sono concordati con il cliente. Il lavoro di ciascun fornitore è esplicitamente identificato nella WBS da almeno un WP di controllo. 4.7 Organization breakdown structure (OBS) L’OBS descrive l’organizzazione del progetto proposta, compresa le interfacce e le responsabilità contrattuali, in contrapposizione alla struttura dell’organizzazione aziendale, che invece descrive gli aspetti funzionali dell’azienda. L’OBS di progetto mostra il personale chiave e le responsabilità assegnate per ogni pacchetto di lavoro nella WBS.
  12. 12. Space project management - Project planning and Implementation 11 5 Project phasing – Project CVS 5.1 Introduzione Il ciclo di vita di un progetto spaziale prevede sempre le seguenti sette fasi: FASE DESCRIZIONE NOTE 1- Phase 0 - Mission analysis/needs identification Le tre fasi 0, A, e B si focalizzano principalmente su: • l’elaborazione dei requisiti funzionali e tecnici del sistema e l’identificazione dei concetti di sistema per conformarsi alla mission statement, tenendo conto dei vincoli tecnici e programmatici identificati dallo sponsor del progetto e dal cliente principale (top customer), • l’identificazione di tutte le attività e risorse da utilizzare per sviluppare i segmenti space e ground del progetto, • le valutazioni iniziali del rischio tecnico e programmatico, • avvio di attività di pre-sviluppo. 2- Phase A - Feasibility 3- Phase B - Preliminary Definition 4- Phase C - Detailed Definition Le fasi C e D comprendono tutte le attività da svolgere al fine di sviluppare e qualificare i prodotti dei space e ground segment.5- Phase D - Qualification and Production 6- Phase E - Utilization La fase E comprende tutte le attività da svolgere al fine di avviare, commissionare, utilizzare e mantenere gli elementi propri dello space e ground segment associato. 7- Phase F - Disposal (smaltimento) La fase F comprende tutte le attività da svolgere al fine di smaltire, in sicurezza, tutti i prodotti propri dello space segment e del ground segment associato.
  13. 13. Space project management - Project planning and Implementation 12 Al termine delle attività principali e delle revisioni relative alla configurazione del progetto, vengono stabilite le baseline di riferimento (vedere ECSS-M-ST-40). Ciascuna delle fasi del progetto termina con delle milestone finali che si esplicitano nella forma di documenti di revisione (review) del progetto, il cui esito determina la disponibilità del progetto a passare alla fase successiva. I requisiti relativi all’organizzazione e allo svolgimento delle revisioni sono forniti nell’ECSS M ST-10-01. Ad eccezione della Mission Definition Review - MDR che normalmente coinvolge solo il project initiator (lo sponsor) del progetto e il top level customer, tutte le altre revisioni del progetto, in genere, vengono eseguite da tutti gli attori del progetto nella catena cliente-fornitore. Dalla Preliminary Requirement Review - PRR al Preliminar Design Review - PDR, la sequenza delle review è top-down, a partire dal cliente di livello superiore e dal suo fornitore di livello superiore, e proseguendo lungo la catena di clienti-fornitori fino al fornitore di livello più basso. Di contro, dal Critical Design Review - CDR all’AR, la sequenza delle review viene invertita in bottom- up: a partire dal fornitore/cliente di livello più basso verso il fornitore/cliente di primo livello. Questo cosiddetto "modello V" è illustrato nella seguente figura: Project Initiator System Operator 2nd Level Customer Top Level Customer 1st Level Customer nth Level Customer Lowest Level Supplier nth Level Supplier 2nd Level Supplier 1st Level Supplier MDR PRR/SRR/PDR PDR PDR PDR CDR/QR/AR CDR/QR/AR CDR/QR/AR CDR/QR/AR CRR 5.2 Rapporto tra accordi commerciali e fasi del progetto Un accordo commerciale può coprire una singola fase di progetto, ovvero un raggruppamento sequenziale di fasi o sotto fasi del progetto (ad esempio fase B1 / fase B2, fase B2 / fase C1 / fase C2), in base a fattori come disponibilità di finanziamento, gare competitive, programma, rischio percepito. Indipendentemente dall’approccio utilizzato per definire l’ambito dei singoli accordi commerciali, tutti i progetti spaziali seguono essenzialmente le fasi del progetto classico.
  14. 14. Space project management - Project planning and Implementation 13 5.3 Le fasi di progetto 5.3.1 Phase 0 (Mission analysis/needs identification) Questa è un’attività svolta principalmente dal project initiator, dal top level customer e dai principali rappresentanti degli utenti finali. 5.3.1.1 Attività principali • produrre la mission statement in termini di identificazione e caratterizzazione dei bisogni di missione, prestazioni attese, affidabilità e obiettivi di sicurezza e vincoli operativi della missione rispetto all’ambiente fisico e operativo, • sviluppare la specifica dei requisiti tecnici preliminari, • identificare i razionali della missione, • effettuare una valutazione preliminare degli aspetti programmatici supportata da studi di mercato ed economici, a seconda dei casi, • eseguire una valutazione preliminare del rischio. 5.3.1.2 Review associate Mission definition review (MDR). La valutazione di questa review è usata per verificare la maturità del progetto di passare alla successiva fase A. L’obiettivo principale della MDR è di rilasciare la mission statement e valutare la specifica preliminare dei requisiti tecnici e degli aspetti programmatici. 5.3.2 Phase A (Feasibility) Si tratta di un’attività condotta principalmente dal top level customer e da uno o più fornitori di primo livello. I risultati di questa fase sono riportati direttamente al project initiator e ai rappresentanti degli utenti finali per la loro condivisione e approvazione. 5.3.2.1 Attività principali • stabilire la versione iniziale del management plan, del system engineering plan e del product assurance plan di progetto, • elaborare i razionali di sistema e l’iniziale architettura di sistema per confrontarla con i bisogni identificati, per individuare eventuali livelli di incertezza e rischi, • definire l’albero delle funzioni, • valutare la fattibilità tecnica e programmatica dei possibili concetti identificando i vincoli relativi all’implementazione, ai costi, alle pianificazioni, all’organizzazione, alle operazioni, alla manutenzione, alla produzione e allo smaltimento, • identificare le tecnologie critiche e proporre attività di pre-sviluppo, • quantificare e caratterizzare elementi critici per fattibilità tecnica ed economica, • proporre i modelli alla base del sistema e le soluzioni tecniche, inclusa la filosofia del modello e l’approccio di verifica, da elaborare ulteriormente durante la fase B, • elaborare la valutazione del rischio. 5.3.2.2 Review associate La Preliminary Requirement Review (PRR). Gli obiettivi principali della PRR sono: • versione iniziale dei piani di: o management,
  15. 15. Space project management - Project planning and Implementation 14 o system engineering, o product assurance, • specifica dei requisiti tecnici, • conferma della fattibilità tecnica e programmatica dell’impostazione del sistema, • selezione di strumenti, tecniche soluzioni tecniche, inclusa la filosofia del modello e l’approccio di come effettuare le verifiche ed i controlli. 5.3.3 Phase B (Preliminary definition) 5.3.3.1 Attività principali • completare e aggiornare la versione iniziale del management plan, del system engineering plan e del product assurance plan di progetto, • definire la pianificazione iniziale del progetto (GANTT), • definire il piano iniziale dei costi, • definire la struttura organizzativa preliminare (OBS), • confermare le soluzioni tecniche per il sistema, • condurre studi "trade-off" e selezionare il concetto di sistema preferito, insieme alle soluzioni tecniche preferite, • realizzare la progettazione preliminare del progetto, • determinare il programma di verifica, • identificare e definire interfacce esterne, • preparare le specifiche di livello successivo e i relativi documenti di accordo commerciale, • avviare lavori di pre-sviluppo su tecnologie critiche o aree di progettazione del sistema, • iniziare qualsiasi approvvigionamento di articoli, • preparare il piano di smaltimento dei detriti spaziali, • sviluppare il piano della sicurezza, • completare il product tree, la WBS e l’albero delle specifiche, • finalizzare il project management, engineering and product assurance plan, • definire la baseline master schedule, • aggiornare il piano dei rischi. 5.3.3.2 Review associate Sono due le review della fase B: • la system requirements review (SRR), che ha per obiettivi: o rilascio dell’aggiornamento delle specifiche dei requisiti tecnici, o assessment della progettazione iniziale, o assessment del programma di verifica iniziale. • la preliminary design review (PDR), che ha per obiettivi: o verifica della progettazione preliminare del concetto selezionato e delle soluzioni tecniche individuate per rispondere ai requisiti di progetto e di sistema, o versione finale dei piani di: ▪ management, ▪ system engineering, ▪ product assurance, o rilascio del product tree, della WBS e dell’albero delle specifiche, o rilascio del piano di verifica (inclusa la filosofia del modello).
  16. 16. Space project management - Project planning and Implementation 15 5.3.4 Phase C (Detailed definition) 5.3.4.1 Attività principali • realizzazione delle versioni finali della progettazione a tutti i livelli della catena cliente- fornitore. • Produzione e sviluppo del piano dei test e dei criteri per la prequalificazione come richiesto dal modello selezionato per il sistema e dalla strategia di verifica, • completamento dell’assemblaggio, dell’integrazione e della pianificazione dei test per il sistema e le sue parti costitutive, • definizione dettagliata di interfacce interne ed esterne, • rilascio del preliminare manuale utente, • aggiornamento del piano dei rischi. 5.3.4.2 Review associate La critical design review (CDR) i cui obiettivi principali sono: • i piani di qualificazione e di validazione per i critical item, • la conferma della validità delle interfacce esterne, • rilascio della progettazione finale, • rilascio dei piani di assemblaggio, di integrazione e di test, • rilascio dei prodotti hw/sw di volo e dei loro piani di assemblaggio e test, • rilascio del manuale utente. 5.3.5 Phase D (Qualification and production) 5.3.5.1 Attività principali • completamento delle attività di test e di verifiche, • completamento della fornitura dell’assemblaggio e del test dell’hw/sw di volo e del relativo ground segment, • completamento dei test di interoperabilità tra lo space e il ground segment, • preparazione dell’acceptance test. 5.3.5.2 Review associate Sono tre: • la qualification review (QR), che ha per obiettivi: o confermare che il processo di verifica ha dimostrato che il progetto, inclusi i margini, soddisfi i requisiti applicabili, o verificare che le registrazioni di verifica siano complete a tutti i livelli della catena cliente-fornitore, o verificare l’accettabilità di tutte le deroghe e deviazioni. o verificare la configurazione funzionale durante la quale: o rilasciare dei file master di produzione per le produzioni di serie. o ottenere l’accettazione, da parte del cliente finale, del file di produzione della serie. • la acceptance review (AR), che ha per obiettivi: o confermare che il processo di verifica ha dimostrato che il prodotto è privo di errori di lavorazione ed è pronto per il successivo utilizzo operativo, o verificare che le registrazioni di verifica dell’accettazione siano complete a tutti i livelli della catena cliente-fornitore,
  17. 17. Space project management - Project planning and Implementation 16 o verificare che tutti i prodotti consegnabili siano disponibili secondo l’elenco di articoli consegnabili approvati, o verificare il prodotto "as-built" corrisponda al prodotto "as-designed", o verificare l’accettabilità di tutte le deroghe e le deviazioni. o verificare che l’Acceptance Data Package sia completo. o autorizzare la consegna del prodotto. o rilasciare il certificato di accettazione. • la operational readiness review (ORR), che ha per obiettivi: o verificare la disponibilità delle procedure operative e la loro compatibilità con il sistema di volo, o verificare la disponibilità dei team operativi, o accettare e rilasciare il ground segment per le operazioni. 5.3.6 Phase E (Operations/utilization) 5.3.6.1 Attività principali • Eseguire tutte le attività a livello di space e ground segment ai fini del lancio della missione, • condurre tutti i lanci e le operazioni orbitali iniziali, • eseguire attività di verifica in orbita (compresa la messa in servizio), • eseguire tutte le operazioni in orbita al fine di raggiungere gli obiettivi della missione, • esegui tutte le attività proprie del ground segment per sostenere la missione, • eseguire tutte le altre attività di supporto a terra al fine di sostenere la missione, • completa il piano di smaltimento. 5.3.6.2 Review associate Sono 4: • la flight readiness review (FRR) che si consegna prima del lancio, e che ha per obiettivi: o la revisione che i segmenti di volo e di terra, inclusi tutti i sistemi di supporto come i sistemi di tracciamento, i sistemi di comunicazione e i sistemi di sicurezza siano pronti per il lancio, • la launch readiness review (LRR), che si attua immediatamente prima del lancio, e che ha per obiettivi: o verificare la disponibilità al lancio del veicolo di lancio e dei segmenti di spazio e di terra, compresi tutti i sistemi di supporto come i sistemi di tracciamento, i sistemi di comunicazione e il sistemi di sicurezza o fornire l’autorizzazione per procedere al lancio. • la commissioning result review (CRR), che si attua dopo il completamento delle attività della fase di messa in orbita, e che ha per obiettivi: o l’attivazione delle operazioni di routine / utilizzo. Questa review viene eseguita dopo il completamento di una serie di test in orbita progettati per verificare che tutti gli elementi del sistema stiano funzionando entro i parametri prestazionali specificati. Il completamento riuscito di questa revisione viene in genere utilizzato per contrassegnare il passaggio formale del sistema al project initiator del progetto o all’operatore del sistema. • la end-of-life review (ELR) rilasciata a completamento della missione, ha per obiettivi: o la verifica che la missione abbia completato tutte le operazioni e i servizi previsti,
  18. 18. Space project management - Project planning and Implementation 17 o la verifica che tutti gli elementi posti in orbita siano configurati per permettere il loro smaltimento in sicurezza. 5.3.7 Phase F (Disposal) 5.3.7.1 Attività principali • Implementare il piano di smaltimento. 5.3.7.2 Review associate La mission close-out review (MCR) che ha come obiettivo: • verificare ed assicurare il completamento con successo di tutte le attività del piano di smaltimento.
  19. 19. Space project management - Project planning and Implementation 18 6 Allegati 6.1 A- Project management plan (PMP) – DRD Il PMP si realizza per definire lo scopo della missione e per fornire una breve introduzione al sistema di gestione del progetto. 6.1.1 Contenuti del documento: Introduzione Contiene una descrizione dello scopo, dell’obiettivo e del motivo che ne richiede la preparazione (ad esempio programma o riferimento e fase del progetto). Documenti applicabili e di riferimento Contiene la lista dei documenti applicabili e di riferimento utilizzati per la stesura del PMP. Obiettivi e vincoli del progetto Contiene la lista degli obiettivi e dei vincoli funzionali e non funzionali del progetto. Organizzazione del Progetto Contiene l’organizzazione del progetto come da §2. In particolare, deve esplicitare: • Il project manager (sia del cliente, sia del fornitore), • se il progetto ha collegamenti con altri progetti, ogni cliente e fornitore deve individuare il responsabile delle relazioni, • se un cliente o fornitore impiega consulenti o altri specialisti per assisterlo nello svolgimento delle sue funzioni, devono essere definiti i ruoli, le responsabilità e l’autorità di questi consulenti e specialisti, • se il cliente fornisce un prodotto a un fornitore, deve individuare il responsabile di prodotto per la fornitura. Project breakdown structures Il paragrafo contiene la struttura del prodotto (product tree) per tutti i prodotti del progetto. Da tener presente che: • le regole per l’identificazione degli articoli del prodotto devono essere uniformi all’interno dello stesso progetto, • ogni prodotto deve avere un’identificazione univoca all’interno del product tree, • l’identificazione deve rimanere invariata durante la vita del prodotto, a meno che una modifica non causi una interruzione di intercambiabilità, • l’albero del prodotto deve essere soggetto all’approvazione del cliente, • l’albero del prodotto deve essere soggetto a controllo di configurazione. • il fornitore deve stabilire la WBS per il sua parte di lavoro, incorporando la WBS di ciascuno dei suoi fornitori di livello inferiore, in conformità all’allegato C. • le funzioni di supporto (gestione, ingegneria, garanzia del prodotto) devono essere identificabili in relazione ai relativi elementi dell’albero del prodotto, • la WBS sarà soggetta all’approvazione del cliente,
  20. 20. Space project management - Project planning and Implementation 19 • il fornitore deve evidenziare le descrizioni dei pacchetti di lavoro (WP) della sua WBS in conformità all’allegato D. Ogni WP deve avere un unico responsabile, • il fornitore deve individuare la propria OBS di competenza, che include: o l’interfaccia e le responsabilità contrattuali tra i soggetti coinvolti, o il personale chiave e le parti responsabili assegnate per ciascuno WP della WBS. Gestione della configurazione, comunicazione e documentazione Il paragrafo deve contenere gli strumenti e i metodi adottati per la gestione della configurazione e della comunicazione tra le parti coinvolte, come definito nell’ECSS-M-ST-40, Allegato A. Se la gestione della configurazione, la gestione delle informazioni e della documentazione è contenuta in un piano specifico, allora qui si possono evidenziare gli elementi chiave e fare riferimento ai documenti piano specifici. Cost and schedule management Il paragrafo deve contenere l’approccio di gestione dei costi e della pianificazione, come definito in ECSS-M-ST-60. Se la gestione dei costi e dei tempi è contenuta in un piano specifico, allora qui si possono evidenziare gli elementi chiave e fare riferimento ai documenti specifici del piano. Integrated logistic support Il paragrafo deve contenere l’approccio di supporto logistico integrato individuato per il progetto, come definito in ECSS-M-ST-70. Risk management Il paragrafo deve contenere una breve descrizione dell’approccio utilizzato per la gestione del rischio che sarà descritto in dettaglio nel piano di gestione del rischio a lungo termine, come definito nell’ECSS-M-ST-80, allegati A e B. Product assurance management Il paragrafo deve contenere una breve descrizione dell’approccio utilizzato per la gestione del product assurance, in genere descritto in dettaglio nel piano di product assurance. Engineering management Il paragrafo deve contenere l’approccio di engineering management, compresa la suddivisione proposta in discipline ingegneristiche e le interfacce tra queste discipline, come definito nell’ECSS-E- ST-10, allegato D. Se la gestione di engineering management è contenuta in un piano specifico, allora qui si possono evidenziare gli elementi chiave e fare riferimento ai documenti specifici del piano.
  21. 21. Space project management - Project planning and Implementation 20 6.2 B - Product tree - DRD L’obiettivo del documento del product tree (PT) è descrivere, in un singolo documento, la suddivisione gerarchica di un prodotto consegnabile fino a un livello concordato tra il cliente e il fornitore. L’albero del prodotto fa parte della progettazione del progetto. È il punto di partenza per selezionare gli elementi di configurazione (come specificato in ECSS-M-ST-40) e stabilire la struttura di ripartizione del lavoro. È una struttura di base per stabilire l’albero delle specifiche (come definito in ECSS-E-ST-10). 6.2.1 Contenuti del documento: Introduzione Contiene una descrizione dello scopo e degli obiettivi del documento (per esempio, fasi e riferimenti del progetto) Documenti applicabili e di riferimento Contiene la lista dei documenti applicabili e di riferimento utilizzati per la stesura del PT. Tree structure Il PT fornisce la scomposizione dei prodotti di livello inferiore che costituiscono il prodotto consegnabile. Per ogni articolo identificato nell’albero del prodotto, devono essere fornite le seguenti informazioni: • codice di identificazione, • nome dell’elemento, • fornitore, • specifica applicabile. Il PT deve essere presentato o sotto forma di diagramma grafico o forma di una struttura indentata dove il prodotto finale (cioè al livello superiore dell’albero) viene scomposto in prodotti di livello inferiore. Ogni articolo prodotto selezionato come elemento di configurazione deve essere identificato nell’albero del prodotto. Quando vengono utilizzati prodotti ricorrenti da precedenti progetti spaziali, questi devono essere identificati nella struttura ad albero.
  22. 22. Space project management - Project planning and Implementation 21 6.3 C - Work breakdown structure (WBS) – DRD L’obiettivo della WBS è fornire, in un singolo documento, un quadro di assieme del progetto relativamente alle attività di gestione dei costi e dei tempi (come definito nell’ECSS M ST-60) e per la gestione del contenuto tecnico. La WBS è utile a tutti gli attori del progetto per: comparare diverse offerte di gara e gestire, di conseguenza, negoziazioni tra i fornitori, ottimizzare la distribuzione del lavoro tra i diversi fornitori; monitorare il programma del progetto. Informazioni sulla determinazione del livello appropriato di dettaglio in WP della WBS fare riferimento al documento ECSS-M-ST-10, allegato H. 6.3.1 Contenuti del documento: Introduzione Contiene una descrizione dello scopo e degli obiettivi del documento (per esempio, fasi e riferimenti del progetto) Documenti applicabili e di riferimento Contiene la lista dei documenti applicabili e di riferimento utilizzati per la stesura del PT. Tree structure La WBS deve fornire una ripartizione logica ed esaustiva degli elementi della struttura del prodotto, che include le funzioni di supporto definite dal cliente (ad esempio gestione del progetto, ingegneria, supporto alla garanzia del prodotto) necessarie per produrre i prodotti finali (modelli di sviluppo e di volo) e i servizi necessari al progetto. Deve essere utilizzato uno schema di codifica per gli elementi WBS che rappresenta la struttura gerarchica quando viene visualizzato in formato testo. Deve essere individuato un sistema di codifica comune per facilitare le comunicazioni tra tutti gli attori del progetto, La WBS identificherà tutti i WP di controllo. I pacchetti di lavoro di controllo possono essere ulteriormente suddivisi dal fornitore in diversi pacchetti di lavoro più dettagliati. L’insieme dei pacchetti di lavoro deve coprire l’intero ambito di lavoro.
  23. 23. Space project management - Project planning and Implementation 22 6.4 D - Work package (WP) description – DRD L’obiettivo dei WP è descrivere il contenuto dettagliato di ciascun elemento della WBS come definito nell’ECSS-M-ST-10, allegato C. La descrizione del WP deve contenere i seguenti elementi: • nome del progetto e fase del progetto, • Titolo WP, • identificazione univoca di ciascun WP e numero di rilascio, • fornitore o entità responsabile delle prestazioni del WP, • Nome e organizzazione del responsabile del WP, • paese del fornitore, • link al PT, • descrizione degli obiettivi del WP, • descrizione dei compiti, • elenco degli input necessari per raggiungere i compiti, • interfacce o collegamenti con altre attività o WP, • elenco di vincoli, requisiti, norme e regolamenti, • lista delle uscite previste, • lista di prodotti, • luogo di consegna, • evento di avvio del WP, compresa la data, • evento di fine del WP, compresa la data, • compiti esclusi.
  24. 24. Space project management - Project planning and Implementation 23 6.5 E - Progress report – DRD L’obiettivo del Progress report (PR), anche detto Stato Avanzamento Lavori (SAL), è fornire a tutti gli attori del progetto evidenza reale sullo stato del progetto. È una fotografia hic et nunc del progetto. Il PR deve contenere le seguenti informazioni: • la valutazione, da parte del responsabile di progetto, della situazione attuale in relazione alle previsioni e ai rischi, ad un livello di dettaglio concordato tra i soggetti interessati, • lo stato di avanzamento del lavoro eseguito dal fornitore, • stato e previsioni sulle prestazioni chiave concordate e sui parametri chiave di progettazione, • evidenza di andamenti e scostamenti negativi nelle prestazioni tecniche e programmatiche e proposte di azioni correttive, • aggiornamento della pianificazione ed evidenza di eventuali azioni correttive da intraprendere, • un rapporto consolidato che scaturisce dai rapporti sullo stato dei fornitori di livello inferiore, • progressi su tutte le azioni a partire dal precedente PR. Output del PR è la conferma della baseline di progetto o il suo aggiornamento in una nuova baseline.
  25. 25. Space project management - Project planning and Implementation 24 6.6 F - ECSS management branch documents delivery per review La Tabella F-1 fornisce le informazioni relative ai documenti deliverable delle diverse fasi di un progetto spaziale. Questa tabella costituisce una prima indicazione per il contenuto del pacchetto di dati in varie revisioni. Il contenuto completo di tale pacchetto di dati è stabilito come parte dell’accordo commerciale, che definisce anche la consegna del documento tra recensioni.
  26. 26. Space project management - Project planning and Implementation 25 6.7 G -Documenti periodici o a seguito del verificarsi di un incidente La Tabella G-1 elenca i documenti periodici o a seguito del verificarsi di un incidente.
  27. 27. Space project management - Project planning and Implementation 26 6.8 H - WBS livello di dettaglio La principale sfida associata allo sviluppo della WBS è quella di determinare il bilanciamento tra la necessità di suddivisione il progetto in parti più elementari e le attività necessarie alla raccolta e al reporting delle parti stesse. Un livello eccessivo di WBS può portare a livelli di manutenzione e reporting non realistici e, di conseguenza, a un progetto inefficiente e costoso. Tra le diverse domande che sorgono quando si sviluppa una WBS, una importante è: la WBS dovrebbe essere ulteriormente scomposta? Una possibile guida potrebbe essere il seguente elenco di domande. Se alla maggior parte delle domande è possibile rispondere SÌ, l’elemento WBS analizzato dovrebbe essere scomposto. Al contrario, se alla maggior parte delle domande è possibile rispondere NO, non è necessario. Se le risposte sono approssimativamente 50/50, è necessario un ulteriore giudizio. • È necessario migliorare la valutazione delle stime dei costi o della misurazione dei progressi dell’elemento della WBS? • C’è più di un responsabile per l’elemento della WBS? • Il contenuto dell’elemento della WBS include più di un tipo di processo di lavoro o produce più di un risultato finale? • È necessario valutare i tempi dei processi di lavoro interni all’elemento della WBS? • È necessario valutare il costo dei processi di lavoro o dei deliverable interni all’elemento WBS? • Ci sono relazioni tra i deliverable di due o più elementi della WBS? • Vi sono significative lacune temporali nell’esecuzione dei processi di lavoro interne all’elemento WBS? • I requisiti delle risorse cambiano nel tempo all’interno di un elemento WBS? • Esistono criteri di accettazione che portano a risultati intermedi, applicabili prima del completamento dell’intero elemento WBS? • Esistono rischi identificati che richiedono un’attenzione specifica per un sottoinsieme dell’elemento WBS? • Un sottoinsieme del lavoro da eseguire all’interno dell’elemento della WBS può essere organizzato come un’unità separata?
  28. 28. Space project management - Project planning and Implementation 27 7 Bibliography ECSS-S-ST-00 ECSS system – Description, implementation and general requirements ECSS-E-ST-10 Space engineering – System engineering general requirements ECSS-E-ST-40 Space engineering – Software general requirements ECSS-E-ST-70 Space engineering – Ground systems and operations ECSS-M-ST-10-01 Space project management – Organization and conduct of reviews ECSS-M-ST-60 Space project management – Cost and schedule management ECSS-M-ST-70 Space project management – Integrated logistic support ECSS-M-ST-80 Space project management – Risk management ECSS-Q-ST-10 Space product assurance – Product assurance management

×