Definizione: L’identificazione del rischio è il processo di determinazione dei rischi che potrebbero potenzialmente impedire al programma, all’impresa o all’investimento di raggiungere i suoi obiettivi. Esso comprende documentare e comunicare la preoccupazione.
Keywords: risk, risk identification, risk management
Ruoli MITRE SE & Aspettative: I MITRE Systems engineers (SEs) che lavorano sui programmi governativi sono tenuti a identificare i rischi che potrebbero avere un impatto sul progetto e sul programma. Essi sono tenuti a scrivere e rivedere dichiarazioni di rischio che sono chiare, inequivocabili, e supportato da prove .
Background
L’identificazione del rischio è il primo passo fondamentale del processo di gestione del rischio descritto nella Figura 1.
L’obiettivo dell’identificazione del rischio è l’identificazione precoce e continua di eventi che, se si verificano, avranno impatti negativi sulla capacità del progetto di raggiungere obiettivi di performance o capability outcome. Possono provenire dall’interno del progetto o da fonti esterne.
Esistono diversi tipi di valutazioni del rischio, tra cui valutazioni del rischio del programma, valutazioni del rischio a supporto di una decisione di investimento, analisi di alternative e valutazioni dell’incertezza operativa o dei costi. L’identificazione del rischio deve corrispondere al tipo di valutazione richiesta per supportare il processo decisionale informato sul rischio. Per un programma di acquisizione, il primo passo è identificare gli obiettivi e gli obiettivi del programma, promuovendo così una comprensione comune tra il team di ciò che è necessario per il successo del programma. Ciò fornisce un contesto e delimita l’ambito in cui i rischi sono identificati e valutati.
Identificazione dei rischi nel programma di ingegneria dei sistemi
Esistono molteplici fonti di rischio. Per l’identificazione del rischio, il team di progetto dovrebbe rivedere l’ambito del programma, le stime dei costi, la pianificazione (per includere la valutazione del percorso critico), la maturità tecnica, i parametri chiave delle prestazioni, le sfide delle prestazioni, le aspettative degli stakeholder rispetto al piano corrente, le dipendenze esterne e interne, le sfide di implementazione, integrazione, interoperabilità, supportabilità, vulnerabilità della supply chain, Inoltre, i dati storici provenienti da progetti simili, interviste con gli stakeholder e elenchi di rischi forniscono informazioni preziose sulle aree da considerare per il rischio.
L’identificazione del rischio è un processo iterativo. Man mano che il programma progredisce, verranno acquisite ulteriori informazioni sul programma (ad esempio, design specifico) e la dichiarazione di rischio verrà modificata per riflettere la comprensione corrente. I nuovi rischi saranno identificati man mano che il progetto progredisce nel ciclo di vita.
Best practice e lezioni apprese
Rischio operativo. Comprendere la natura operativa delle funzionalità supportate e il rischio per gli utenti finali, le loro missioni e le loro operazioni delle funzionalità. La comprensione della necessità/missione operativa (vedere l’argomento di sviluppo del concetto della Guida all’ingegneria dei sistemi) ti aiuterà ad apprezzare la gravità dei rischi e l’impatto che potrebbero avere sugli utenti finali. Questa è una parte fondamentale dell’analisi del rischio: realizzare l’impatto reale che può verificarsi se si verifica un rischio durante l’uso operativo. In genere gli utenti operativi sono disposti ad accettare un certo livello di rischio se sono in grado di compiere la loro missione (ad esempio, mission assurance), ma è necessario aiutare gli utenti a comprendere i rischi che stanno accettando e valutare le opzioni, i saldi e le alternative disponibili.
Maturità tecnica. Lavorare con e sfruttare l’industria e il mondo accademico per comprendere le tecnologie considerate per uno sforzo e la probabile transizione della tecnologia nel tempo. Un approccio consiste nel lavorare con i fornitori nell’ambito di un accordo di non divulgazione per comprendere le capacità e dove stanno andando, in modo che il rischio possa essere valutato.
Elementi non di sviluppo (NDI). NDI include articoli commerciali-off-the-shelf e governo-off-the-shelf. Per gestire il rischio, considerare la redditività del fornitore di NDI. Il fornitore ha una quota di mercato? Il fornitore ha una longevità adeguata rispetto ai suoi concorrenti? In che modo il provider affronta i problemi di capacità e le correzioni di rilascio, ecc.? Qual è la base di utenti per il particolare NDI? Il fornitore può dimostrare l’NDI, preferibilmente in un ambiente simile a quello del tuo cliente? Il governo può usare l’NDI per creare un prototipo? Tutti questi fattori aiuteranno a valutare il rischio della redditività dell’NDI e del fornitore. Cercare risposte a queste domande da altri personale MITRE che hanno lavorato la zona o hanno utilizzato la NDI in fase di valutazione.
Driver di acquisizione. Enfatizza gli abilitatori di capacità critiche, in particolare quelli che hanno alternative limitate. Valutare e determinare i driver principali per un’acquisizione e sottolineare il loro rischio associato nella formulazione di raccomandazioni di mitigazione del rischio. Se un particolare aspetto di una capacità non è fondamentale per il suo successo, il suo rischio dovrebbe essere valutato, ma non deve essere l’obiettivo primario della gestione del rischio. Ad esempio, se esiste un rischio per un’interfaccia utente proposta, ma il mercato ha numerose alternative, il successo dell’approccio proposto è probabilmente meno critico per il successo complessivo della capacità. D’altra parte, è probabile che una funzionalità di sicurezza delle informazioni sia fondamentale. Se solo un approccio alternativo soddisfa la necessità, dovrebbe essere posto l’accento su di esso. Determinare i driver di successo primari valutando esigenze e progetti e determinando le alternative esistenti. È una soluzione unica sul percorso critico verso il successo? Assicurati che le analisi dei percorsi critici includano l’intero ciclo di ingegneria del sistema e non solo lo sviluppo (cioè, lo sviluppo del sistema, di per sé, può essere un “pezzo di torta”, ma mettere in campo in una situazione operativa attiva può essere un rischio importante).
Utilizzare capability evolution per gestire il rischio. Se requisiti particolari stanno guidando l’implementazione di funzionalità ad alto rischio a causa di uno sviluppo unico, esigenze di prestazioni edge-of-the-envelope, ecc., i requisiti dovrebbero essere discussi con gli utenti per la loro criticità. Può darsi che la necessità potrebbe essere rinviata, e la comunità di sviluppo dovrebbe valutare quando potrebbe essere soddisfatta in futuro. Aiutare gli utenti e gli sviluppatori valutare quanto rischio (e pianificazione e costo impatto) una particolare capacità dovrebbe assumere rispetto ai requisiti per ricevere le capacità meno rischiose prima. Nello sviluppare le vostre raccomandazioni, prendere in considerazione la fattibilità tecnica e la conoscenza dei relativi successi e fallimenti di implementazione per valutare il rischio di implementare ora invece che il futuro. Nel differire le capacità, fare attenzione a non cadere nella trappola di rinviare il fallimento finale negoziando successi facili a breve termine per un futuro di molteplici requisiti ad alto rischio che potrebbero essere essenziali per il successo generale.
Parametri di prestazione chiave (KPPs). Lavorare a stretto contatto con gli utenti per stabilire KPP. Il rischio complessivo di annullamento del programma può essere centrato sul mancato rispetto dei KPP. Lavorare con gli utenti per garantire che i parametri siano rispondenti alle esigenze della missione e tecnicamente fattibili. I parametri non dovrebbero essere così indulgenti da poter essere facilmente soddisfatti, ma non soddisfare le esigenze della missione; né dovrebbero essere così rigorosi da non poter essere soddisfatti senza uno sforzo esteso o una tecnologia di spinta, che può mettere a rischio un programma. Cercare i risultati di operazioni passate, esperimenti, valutazioni delle prestazioni e implementazioni del settore per aiutare a determinare la fattibilità delle prestazioni.
Dipendenze esterne ed interne. Avere una prospettiva aziendale può aiutare gli acquirenti, i program manager, gli sviluppatori, gli integratori e gli utenti ad apprezzare i rischi derivanti dalle dipendenze di uno sforzo di sviluppo. Con l’emergere di approcci orientati ai servizi, un programma diventerà più dipendente dalla disponibilità e dal funzionamento dei servizi forniti da altri che intendono utilizzare negli sforzi di sviluppo del loro programma. Lavora con gli sviluppatori di servizi per garantire la creazione di servizi di qualità e il pensiero è stato dedicato alla manutenzione e all’evoluzione di tali servizi. Lavora con il personale del programma di sviluppo per valutare i servizi disponibili, la loro qualità e il rischio che un programma ha nell’utilizzare e fare affidamento sul servizio. Allo stesso modo, esiste un rischio associato alla creazione del servizio e al non utilizzo dei servizi di un altro sforzo aziendale. Aiuta a determinare i rischi e i potenziali benefici della creazione di un servizio interno allo sviluppo con una possibile transizione al servizio aziendale in un momento futuro.
Integrazione e interoperabilità (I & I). I&Sarò quasi sempre un importante fattore di rischio. Sono forme di dipendenze in cui il valore dell’integrazione o dell’interoperabilità è stato giudicato superiore ai loro rischi intrinseci. Tecniche come enterprise federation architecting, capacità componibili su richiesta e modelli di progettazione possono aiutare il governo a pianificare ed eseguire un percorso per navigare I&I rischi. Fare riferimento alla sezione Enterprise Engineering della Guida all’ingegneria dei sistemi per gli articoli sulle tecniche per affrontare I & I rischi associati.
Sicurezza delle informazioni. La sicurezza delle informazioni è un rischio in quasi ogni sviluppo. Alcuni di questi sono dovuti all’unicità delle esigenze e dei requisiti del governo in questo settore. Alcuni di questi sono dovuti alle difficoltà intrinseche nel contrastare gli attacchi informatici. Creare capacità difensive per coprire lo spettro degli attacchi è impegnativo e rischioso. Aiutare il governo a sviluppare approcci di resilienza (ad esempio, piani di emergenza, backup/ripristino, ecc.). Consentire la condivisione delle informazioni tra i sistemi nelle operazioni di coalizione con partner internazionali presenta sfide tecniche e problemi politici che si traducono in rischi di sviluppo. I problemi di sicurezza delle informazioni associati alla gestione della supply chain sono così ampi e complessi che anche mantenere una consapevolezza rudimentale delle minacce è una sfida tremenda.
Livello di abilità. L’abilità o il livello di esperienza degli sviluppatori, degli integratori, del governo e di altre parti interessate possono portare a rischi. Essere alla ricerca di competenze insufficienti e raggiungere tutta la società per colmare eventuali lacune. In tal modo, aiutare a educare i membri del team di governo, allo stesso tempo si stanno portando le competenze aziendali e l’esperienza a sopportare.
Rischi di costo. I programmi in genere creano una stima dei costi del governo che considera il rischio. Man mano che si sviluppano e si perfezionano i rischi tecnici e di altro tipo del programma, anche le stime dei costi associate dovrebbero evolversi. La stima dei costi non è un’attività una tantum.
Informazioni storiche come guida all’identificazione del rischio. Le informazioni storiche provenienti da programmi governativi simili possono fornire informazioni preziose sui rischi futuri. Cerca informazioni sulle sfide operative e sui rischi in varie lezioni di funzionamento apprese, dopo i rapporti di azione, i riassunti degli esercizi e i risultati della sperimentazione. I clienti hanno spesso repository di questi per accedere. I capi di governo normalmente comunicheranno le loro esigenze e sfide strategiche. Comprendi e considera questi elementi nella tua valutazione delle funzionalità più importanti necessarie al tuo cliente e come base per le valutazioni dei rischi.
I dati storici per aiutare a valutare il rischio sono spesso disponibili dalle valutazioni delle prestazioni passate e dalle lezioni apprese dai programmi di acquisizione e dagli appaltatori. In molti casi, il personale MITRE assisterà il governo nella preparazione delle informazioni sulle prestazioni per una particolare acquisizione. L’AF dispone di una Past Performance Evaluation Guide (PPEG) che identifica il tipo di informazioni da acquisire che possono essere utilizzate per future selezioni di fonti governative . Questo archivio di informazioni può contribuire a fornire informazioni di base sulle sfide precedenti e su dove potrebbero ripresentarsi, sia per il particolare tipo di attività di sviluppo che per i particolari appaltatori.
Esistono numerose valutazioni tecniche per i prodotti del fornitore a cui è possibile accedere per determinare il rischio e la redditività di vari prodotti. Un repository MITRE di valutazioni di strumenti è il Toolshed di analisi che contiene indicazioni e l’esperienza con strumenti analitici. L’utilizzo di risorse come queste e la ricerca di altri che hanno provato prodotti e tecniche in prototipi ed esperimenti può aiutare a valutare i rischi per un particolare sforzo.
Come scrivere un rischio a una best practice . Un protocollo di best practice per scrivere una dichiarazione di rischio è il costrutto Condition-If-Then. Questo protocollo si applica ai processi di gestione del rischio progettati per quasi tutti gli ambienti. È un riconoscimento che un rischio, per sua natura, è probabilistico e che, se si verifica, ha conseguenze indesiderate.
Qual è il costrutto Condition-If-Then? La Condizione riflette ciò che è noto oggi. È la causa principale dell’evento di rischio identificato. Quindi, la Condizione è un evento che si è verificato, si sta attualmente verificando o si verificherà con certezza. Gli eventi di rischio sono eventi futuri che possono verificarsi a causa della condizione presente. Di seguito è riportata un’illustrazione di questo protocollo.
L’If è l’evento di rischio associato alla Condizione presente. È di fondamentale importanza riconoscere l’If e la Condizione come duale. Se esaminati congiuntamente, potrebbero esserci modi per intervenire direttamente o porre rimedio alla radice sottostante dell’evento di rischio (Condizione) in modo tale che le conseguenze di questo evento, se si verifica, non minaccino più il progetto. L’If è la parte probabilistica della dichiarazione di rischio.
Il Then è la conseguenza, o insieme di conseguenze, che avrà un impatto sul progetto del sistema di ingegneria se si verifica l’evento di rischio. Un esempio di un Condition-If-Then costrutto è illustrato in Figura 2.
Incoraggia i team a identificare i rischi. La cultura in alcuni progetti e programmi governativi scoraggia l’identificazione dei rischi. Ciò può verificarsi perché le attività di gestione del rischio di monitoraggio, monitoraggio e mitigazione dei rischi sono considerate onerose e inutili. In questa situazione, può essere utile parlare con i team dei benefici dell’identificazione dei rischi e dell’incapacità di gestire tutto nella tua testa (ad es., determinare la priorità, chi deve essere coinvolto, azioni di mitigazione). Assistere i team governativi nell’esecuzione di un processo che bilancia gli investimenti di gestione con valore per i risultati del progetto. In generale, un buon equilibrio viene raggiunto quando l’ambito del progetto, la pianificazione e gli obiettivi di costo vengono raggiunti o mitigati con successo dai piani d’azione e il team di progetto ritiene che le attività di gestione del rischio forniscano valore al progetto. La rappresentazione tra team è un must; i rischi non dovrebbero essere identificati da un individuo, o strettamente dal team di ingegneria dei sistemi (rivedere le fonti di rischio sopra).
Considerare i fattori organizzativi e ambientali. Fattori organizzativi, culturali, politici e altri fattori ambientali, come il supporto degli stakeholder o le priorità organizzative, possono rappresentare un rischio maggiore o maggiore per un progetto rispetto ai soli fattori tecnici. Questi rischi dovrebbero essere identificati e mitigati attivamente per tutta la durata del progetto. Le attività di mitigazione potrebbero includere il monitoraggio di mandati legislativi o cambiamenti di emergenza che potrebbero influire sulla missione del programma o del progetto, cambiamenti organizzativi che potrebbero influire sui requisiti degli utenti o sull’utilità della capacità o cambiamenti nel supporto politico che potrebbero influire sul finanziamento. In ogni caso, considerare il rischio per il programma e identificare le opzioni di azione per la discussione con le parti interessate. Per ulteriori informazioni, consultare l’articolo Pianificazione, implementazione e monitoraggio dei progressi della mitigazione dei rischi.
Includere le parti interessate nell’identificazione del rischio. Progetti e programmi di solito hanno più parti interessate che portano varie dimensioni di rischio per i risultati. Essi comprendono operatori, che potrebbero essere sopraffatti da nuovi sistemi; utenti, che potrebbero non essere adeguatamente formati o avere timori per il loro lavoro; supervisori che potrebbero non sostenere una nuova capacità perché sembra diminuire la loro autorità; e responsabili politici, che si occupano di approvazione legislativa e dei costi. Inoltre, è importante includere tutte le parti interessate, come le autorità di certificazione e accreditamento che, se inavvertitamente trascurate, possono comportare gravi rischi in seguito al programma. Le parti interessate possono essere profondamente consapevoli di vari fattori ambientali, come la legislazione in sospeso o il sostegno al programma politico che possono comportare rischi per un progetto che sono sconosciuti al governo o al team del progetto MITRE. Includere le parti interessate nel processo di identificazione dei rischi per aiutare a far emergere questi rischi.
Scrivi chiare dichiarazioni di rischio. L’utilizzo del formato Condition-If-Then aiuta a comunicare e valutare una dichiarazione di rischio e a sviluppare una strategia di mitigazione. La causa principale è la condizione sottostante che ha introdotto il rischio (ad esempio, un approccio di progettazione potrebbe essere la causa), l’If riflette la probabilità (ad esempio, la valutazione della probabilità che la parte If della dichiarazione di rischio dovesse verificarsi) e l’If comunica l’impatto al programma (ad esempio, maggiori risorse per supportare i test, pianificazione aggiuntiva e preoccupazione per soddisfare le prestazioni). La strategia di mitigazione è quasi sempre migliore se basata su una dichiarazione di rischio chiaramente articolata.
Aspettatevi modifiche alla dichiarazione di rischio man mano che viene sviluppata la strategia di valutazione e mitigazione del rischio. È comune che le dichiarazioni di rischio siano perfezionate una volta che il team valuta l’impatto. Quando si valuta e si documenta l’impatto potenziale del rischio (costo, calendario, tecnico o temporale), la comprensione e la dichiarazione del rischio potrebbero cambiare. Ad esempio, quando si valuta un impatto di rischio del software schedule slip, la dichiarazione di rischio potrebbe essere perfezionata per includere la data di scadenza e/o ulteriori chiarimenti sull’impatto (ad esempio, se il software xyz non viene consegnato entro marzo 2015, non ci sarà tempo sufficiente per testare gli scambi di interfaccia prima del Test utente limitato).
Non includere la dichiarazione di mitigazione nella dichiarazione di rischio. Fare attenzione a non cadere nella trappola di avere la dichiarazione di mitigazione introdotto nella dichiarazione di rischio. Un rischio è un’incertezza con potenziale impatto negativo. Alcuni saltano rapidamente alla conclusione della mitigazione del rischio e, invece di identificare il rischio che dovrebbe essere mitigato (con opzioni di mitigazione identificate), identificano il rischio come un approccio di progettazione non ottimale. Ad esempio, una dichiarazione di rischio potrebbe essere: Se il contraente non utilizza XYZ per il test, il test fallirà. La preoccupazione è davvero la sufficienza di prova. Se l’appaltatore non esegue il test con risultati misurabili per l’analisi, il programma potrebbe non superare un test utente limitato. L’uso di XYZ può essere un’opzione di mitigazione per ridurre il rischio di sufficienza del test.
Non passare a una strategia di mitigazione prima di valutare la probabilità di rischio e l’impatto. Un rischio può essere perfezionato o modificato dopo un’ulteriore analisi, che potrebbe influire su quale potrebbe essere la mitigazione più efficiente/desiderata. Gli ingegneri spesso saltano alla soluzione; è meglio passare alla fase successiva discussa nell’articolo sulla valutazione dell’impatto del rischio e sulla definizione delle priorità per decomporre e comprendere prima il problema. In definitiva questo porterà a una strategia che è strettamente allineato con la preoccupazione.
Riferimenti& Risorse
- The MITRE Institute, September 1, 2007, MITRE Systems Engineering (SE) Competency Model, Version 1, pp. 10, 40-41.
- Garvey, PR, 2008, Analytical Methods for Risk Management: A Systems Engineering Perspective, Chapman-Hall/CRC-Press, Taylor & Francis Group (UK), Boca Raton, London, New York, ISBN: 1584886374.U. S. Air Force, gennaio 2008, Air Force Past Performance Evaluation Guide(PPEG), IG5315.305 (a).
- U. S. Air Force, gennaio 2008, Air Force Past Performance Evaluation Guide (PPEG), IG5315.305(a).
Riferimenti aggiuntivi& Risorse
MITRE E520 Risk Analysis and Management Technical Team checklist, Risk Checks, Risk Analysis and Management Documents.
Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK Guide), Fourth Edition, ANSI/PMI 99-001-2008, pp. 273-312, accessed March 2, 2010.
SEPO, “Standard Process / Steps of Process, Step 2: Identify Risks & Hazards,” MITRE SEPO Risk Management Toolkit, accesso 5 maggio 2010.
