definiție: identificarea riscurilor este procesul de determinare a riscurilor care ar putea împiedica programul, întreprinderea sau investiția să își atingă obiectivele. Aceasta include documentarea și comunicarea preocupării.
cuvinte cheie: risc, identificarea riscurilor, managementul riscurilor
Mitre se roluri & așteptări: inginerii de sisteme MITRE (SES) care lucrează la programe guvernamentale sunt așteptați să identifice riscurile care ar putea avea impact asupra proiectului și Programului. Se așteaptă ca aceștia să scrie și să revizuiască declarațiile de risc care sunt clare, lipsite de ambiguitate și susținute de dovezi .
context
identificarea riscurilor este primul pas critic al procesului de gestionare a riscurilor descris în Figura 1.
obiectivul identificării riscurilor este identificarea timpurie și continuă a evenimentelor care, dacă apar, vor avea un impact negativ asupra capacității proiectului de a atinge obiectivele de performanță sau de rezultat al capacității. Acestea pot proveni din cadrul proiectului sau din surse externe.
există mai multe tipuri de evaluări ale riscurilor, inclusiv evaluări ale riscurilor programului, evaluări ale riscurilor pentru a sprijini o decizie de investiții, analiza alternativelor și evaluări ale incertitudinii operaționale sau a costurilor. Identificarea riscurilor trebuie să corespundă tipului de evaluare necesar pentru a sprijini luarea deciziilor în cunoștință de cauză cu privire la risc. Pentru un program de achiziție, primul pas este identificarea obiectivelor și obiectivelor programului, încurajând astfel o înțelegere comună în cadrul echipei a ceea ce este necesar pentru succesul programului. Acest lucru oferă context și limitează domeniul de aplicare prin care riscurile sunt identificate și evaluate.
identificarea riscurilor în programul de Inginerie a sistemelor
există mai multe surse de risc. Pentru identificarea riscurilor, echipa de proiect ar trebui să revizuiască domeniul de aplicare al programului, estimările costurilor, programul (pentru a include evaluarea căii critice), maturitatea tehnică, parametrii cheie de performanță, provocările de performanță, așteptările părților interesate față de planul actual, dependențele externe și interne, provocările de implementare, integrarea, interoperabilitatea, Suportabilitatea, vulnerabilitățile lanțului de aprovizionare, capacitatea de a gestiona amenințările, abaterile de costuri, așteptările evenimentelor de testare, siguranța, securitatea și multe altele. În plus, datele istorice din proiecte similare, interviurile părților interesate și listele de risc oferă o perspectivă valoroasă asupra domeniilor pentru luarea în considerare a riscului.
identificarea riscului este un proces iterativ. Pe măsură ce programul progresează, vor fi obținute mai multe informații despre program (de exemplu, proiectarea specifică), iar declarația de risc va fi ajustată pentru a reflecta înțelegerea actuală. Noi riscuri vor fi identificate pe măsură ce proiectul progresează pe parcursul ciclului de viață.
cele mai bune practici și lecții învățate
riscul operațional. Înțelegeți natura operațională a capabilităților pe care le susțineți și riscul pentru utilizatorii finali, misiunile lor și operațiunile lor ale capabilităților. Înțelegerea nevoii/misiunii operaționale (a se vedea tema de dezvoltare a conceptului din Ghidul de Inginerie a sistemelor) vă va ajuta să apreciați gravitatea riscurilor și impactul pe care acestea l-ar putea avea asupra utilizatorilor finali. Aceasta este o parte critică a analizei riscurilorrealizarea impactului din lumea reală care poate apărea dacă apare un risc în timpul utilizării operaționale. De obicei, utilizatorii operaționali sunt dispuși să accepte un anumit nivel de risc dacă sunt capabili să își îndeplinească misiunea (de exemplu, asigurarea misiunii), dar trebuie să îi ajutați pe utilizatori să înțeleagă riscurile pe care le acceptă și să evalueze opțiunile, soldurile și alternativele disponibile.
maturitate tehnică. Lucrați cu industria și mediul academic pentru a înțelege tehnologiile luate în considerare pentru un efort și tranziția probabilă a tehnologiei în timp. O abordare este de a lucra cu furnizorii în cadrul unui acord de nedivulgare pentru a înțelege capacitățile și unde se îndreaptă, astfel încât riscul să poată fi evaluat.
elemente non-dezvoltare (NDI). NDI include articole comerciale-off-the-shelf și guvernamentale-off-the-shelf. Pentru a gestiona riscul, luați în considerare viabilitatea furnizorului NDI. Furnizorul are cota de piață? Furnizorul are o longevitate adecvată în comparație cu concurenții săi? Cum abordează furnizorul problemele de capacitate și remedierile de lansare etc.? Care este baza de utilizatori pentru NDI special? Poate furnizorul să demonstreze NDI, de preferință într-un cadru similar cu cel al clientului dvs.? Poate guvernul să folosească NDI pentru a crea un prototip? Toți acești factori vor ajuta la evaluarea riscului de viabilitate a NDI și a furnizorului. Căutați răspunsuri la aceste întrebări de la alți angajați MITRE care au lucrat în zonă sau au folosit NDI evaluat.
drivere de achiziție. Subliniați factorii critici de capacitate, în special cei care au alternative limitate. Evaluați și determinați factorii principali ai unei achiziții și subliniați riscul asociat acestora în formularea recomandărilor de atenuare a riscurilor. Dacă un anumit aspect al unei capacități nu este esențial pentru succesul său, riscul său ar trebui evaluat, dar nu trebuie să fie principalul obiectiv al gestionării riscurilor. De exemplu, dacă există un risc pentru o interfață de utilizator propusă, dar piața are numeroase alternative, succesul abordării propuse este probabil mai puțin critic pentru succesul general al capacității. Pe de altă parte, o caracteristică de securitate a informațiilor este probabil să fie critică. Dacă o singură abordare alternativă satisface nevoia, ar trebui să se pună accentul pe aceasta. Determinați factorii principali de succes evaluând nevoile și proiectele și determinând alternativele care există. Este o soluție unică pe calea critică spre succes? Asigurați-vă că analizele critice ale căilor includ întregul ciclu de Inginerie a sistemului și nu doar dezvoltarea (adică dezvoltarea sistemului, în sine, poate fi o „bucată de tort”, dar plasarea într-o situație operațională activă poate fi un risc major).
utilizați evoluția capacității pentru a gestiona riscul. În cazul în care cerințele speciale sunt de conducere punerea în aplicare a capacităților care sunt de risc ridicat din cauza dezvoltării unice, nevoile de performanță edge-of-the-plic, etc., cerințele ar trebui discutate cu utilizatorii pentru criticitatea lor. S-ar putea ca nevoia să fie amânată, iar comunitatea de dezvoltare ar trebui să evalueze când ar putea fi satisfăcută în viitor. Ajutați utilizatorii și dezvoltatorii să evalueze cât de mult risc (și program și impact asupra costurilor) ar trebui să-și asume o anumită capacitate în raport cu cerințele pentru a primi capacități mai puțin riscante mai devreme. În elaborarea recomandărilor dvs., luați în considerare fezabilitatea tehnică și cunoașterea succeselor și eșecurilor legate de implementare pentru a evalua riscul implementării acum în loc de viitor. În amânarea capacităților, aveți grijă să nu cădeți în capcana amânării eșecului final prin tranzacționarea succeselor ușoare pe termen scurt pentru un viitor cu multiple cerințe cu risc ridicat, care pot fi esențiale pentru succesul general.
Parametrii Cheie De Performanță (Kpp). Lucrați îndeaproape cu utilizatorii pentru a stabili KPP-uri. Riscul general de anulare a programului poate fi centrat pe nerespectarea KPP-urilor. Lucrați cu utilizatorii pentru a vă asigura că parametrii răspund nevoilor misiunii și sunt fezabili din punct de vedere tehnic. Parametrii nu ar trebui să fie atât de îngăduitori încât să poată fi îndepliniți cu ușurință, dar să nu răspundă nevoilor misiunii; nici nu ar trebui să fie atât de stricți încât să nu poată fi îndepliniți fără un efort extins sau împingând tehnologiaoricare dintre acestea poate pune un program în pericol. Căutați rezultatele operațiunilor anterioare, experimentelor, evaluărilor performanței și implementărilor din industrie pentru a ajuta la determinarea fezabilității performanței.
dependențe externe și interne. Având o perspectivă de întreprindere poate ajuta achizitorii, managerii de programe, dezvoltatorii, integratorii și utilizatorii să aprecieze riscul din cauza dependențelor unui efort de dezvoltare. Odată cu apariția abordărilor orientate spre servicii, un program va deveni mai dependent de disponibilitatea și funcționarea serviciilor furnizate de alții pe care intenționează să le utilizeze în eforturile de dezvoltare ale programului lor. Lucrați cu dezvoltatorii de servicii pentru a vă asigura că sunt create servicii de calitate și că s-a gândit la întreținerea și evoluția acestor servicii. Lucrați cu personalul programului de dezvoltare pentru a evalua serviciile disponibile, calitatea acestora și riscul pe care un program îl are în utilizarea și bazându-se pe serviciu. De asemenea, există un risc asociat cu crearea serviciului și nefolosirea serviciilor dintr-un alt efort al întreprinderii. Ajuta la determinarea riscurilor și beneficiile potențiale ale creării unui serviciu intern pentru dezvoltarea cu eventual o tranziție la serviciul de întreprindere la un moment dat în viitor.
integrare și interoperabilitate (I&I). I & voi fi aproape întotdeauna un factor de risc major. Acestea sunt forme de dependențe în care valoarea integrării sau a interoperării a fost considerată a depăși riscurile lor inerente. Tehnici precum enterprise federation architecting, capabilități compozabile la cerere și modele de proiectare pot ajuta guvernul să planifice și să execute o rută pentru a naviga i&i riscuri. Consultați secțiunea Enterprise Engineering din Ghidul de Inginerie a sistemelor pentru articole despre tehnici pentru abordarea I & i riscuri asociate.
securitatea informațiilor. Securitatea informațiilor este un risc în aproape fiecare dezvoltare. Unele dintre acestea se datorează unicității nevoilor și cerințelor guvernamentale în acest domeniu. Unele dintre acestea se datorează dificultăților inerente în combaterea atacurilor cibernetice. Crearea de capacități defensive pentru a acoperi spectrul atacurilor este o provocare și riscantă. Ajutați guvernul să dezvolte abordări de reziliență (de exemplu, planuri de urgență, backup/recuperare etc.). Facilitarea schimbului de informații între sisteme în cadrul operațiunilor de coaliție cu partenerii internaționali prezintă provocări tehnice și probleme de politică care se traduc în risc de dezvoltare. Problemele de securitate a informațiilor asociate cu managementul lanțului de aprovizionare sunt atât de largi și complexe încât chiar și menținerea conștientizării rudimentare a amenințărilor este o provocare extraordinară.
nivelul de calificare. Nivelul de calificare sau experiență al dezvoltatorilor, integratorilor, Guvernului și altor părți interesate poate duce la riscuri. Fiți în căutarea unor abilități insuficiente și ajungeți la corporație pentru a umple orice lacune. În acest sens, ajutați la educarea membrilor echipei guvernamentale în același timp, aduceți abilități corporative și experiență de suportat.
riscuri de Cost. Programele vor crea de obicei o estimare a costurilor guvernului care ia în considerare riscul. Pe măsură ce dezvoltați și rafinați riscurile tehnice și alte riscuri ale programului, estimările costurilor asociate ar trebui să evolueze, de asemenea. Estimarea costurilor nu este o activitate unică.
informații istorice ca ghid pentru identificarea riscurilor. Informațiile istorice din programe guvernamentale similare pot oferi o perspectivă valoroasă asupra riscurilor viitoare. Căutați informații despre provocările și riscurile operaționale în diferite lecții de operare învățate, după rapoartele de acțiune, rezumatele exercițiilor și rezultatele experimentării. Clienții au adesea depozite ale acestora de accesat. În mod normal, liderii guvernamentali își vor comunica nevoile și provocările strategice. Înțelegeți și luați în considerare acestea în evaluarea celor mai importante capacități necesare clientului dvs. și ca bază pentru evaluările riscurilor.
datele istorice pentru a ajuta la evaluarea riscului sunt frecvent disponibile din evaluările de performanță anterioare și din lecțiile învățate din programele de achiziție și contractori. În multe cazuri, personalul MITRE va asista guvernul în pregătirea informațiilor de performanță pentru o anumită achiziție. AF are un ghid de evaluare a performanței anterioare (PPEG) care identifică tipul de informații de capturat care pot fi utilizate pentru viitoarele selecții de surse guvernamentale . Acest depozit de informații poate contribui la furnizarea de informații de fond cu privire la provocările anterioare și la situațiile în care acestea ar putea apărea din nouatât pentru tipul particular de activitate de dezvoltare, cât și pentru contractanții particulari.
există numeroase evaluări tehnice pentru produsele furnizorului care pot fi accesate pentru a determina riscul și viabilitatea diferitelor produse. Un depozit MITRE de evaluări ale instrumentelor este analiza Toolshed care conține îndrumări și experiență cu instrumente analitice. Utilizarea unor astfel de resurse și căutarea altor persoane care au încercat produse și tehnici în prototipuri și experimente pot ajuta la evaluarea riscurilor pentru un anumit efort.
cum se scrie un risc-o bună practică . Un protocol de bune practici pentru scrierea unei declarații de risc este condiție-dacă-atunci construi. Acest protocol se aplică proceselor de gestionare a riscurilor concepute pentru aproape orice mediu. Este o recunoaștere a faptului că un risc, prin natura sa, este probabilist și unul care, dacă apare, are consecințe nedorite.
care este condiția-dacă-atunci construi? Condiția reflectă ceea ce este cunoscut astăzi. Este cauza principală a evenimentului de risc identificat. Astfel, condiția este un eveniment care a avut loc, are loc în prezent sau va avea loc cu certitudine. Evenimentele de risc sunt evenimente viitoare care pot apărea din cauza stării prezente. Mai jos este o ilustrare a acestui protocol.
If este evenimentul de risc asociat cu condiția prezentă. Este extrem de important să recunoaștem dacă și condiția ca dublă. Atunci când sunt examinate în comun, pot exista modalități de a interveni direct sau de a remedia rădăcina (starea) subiacentă a evenimentului de risc, astfel încât consecințele acestui eveniment, dacă apare, să nu mai amenințe proiectul. If este partea probabilistică a Declarației de risc.
atunci este consecința sau setul de consecințe care vor avea impact asupra proiectului sistemului de inginerie dacă apare evenimentul de risc. Un exemplu de construcție condiție-dacă-atunci este ilustrat în Figura 2.
încurajează echipele să identifice riscurile. Cultura în unele proiecte și programe guvernamentale descurajează identificarea riscurilor. Acest lucru poate apărea deoarece activitățile de gestionare a riscurilor de urmărire, monitorizare și atenuare a riscurilor sunt considerate împovărătoare și inutile. În această situație, poate fi util să discutați cu echipele despre beneficiile identificării riscurilor și incapacitatea de a gestiona totul în capul dvs. (de ex., determină prioritatea, cine trebuie implicat, acțiuni de atenuare). Asistați echipele guvernamentale în executarea unui proces care echilibrează investițiile de gestionare cu valoare pentru rezultatele proiectului. În general, se obține un echilibru bun atunci când scopul proiectului, programul și obiectivele de cost sunt îndeplinite sau atenuate cu succes de planurile de acțiune, iar echipa de proiect consideră că activitățile de gestionare a riscurilor oferă valoare proiectului. Reprezentarea între Echipe este o necesitate; riscurile nu trebuie identificate de o persoană sau strict de echipa de Inginerie a sistemelor (examinați sursele de risc de mai sus).
luați în considerare factorii organizaționali și de mediu. Factorii organizaționali, culturali, politici și alți factori de mediu, cum ar fi sprijinul părților interesate sau prioritățile organizaționale, pot prezenta un risc la fel de mare sau mai mare pentru un proiect decât factorii tehnici singuri. Aceste riscuri ar trebui identificate și atenuate în mod activ pe toată durata de viață a proiectului. Activitățile de atenuare ar putea include monitorizarea mandatelor legislative sau a modificărilor de urgență care ar putea afecta misiunea programului sau a proiectului, modificări organizaționale care ar putea afecta cerințele utilizatorilor sau utilitatea capacității sau modificări ale sprijinului politic care ar putea afecta finanțarea. În fiecare caz, luați în considerare riscul pentru program și identificați opțiunile de acțiune pentru discuții cu părțile interesate. Pentru informații suplimentare, consultați articolul planificarea, implementarea și monitorizarea progreselor de atenuare a riscurilor.
Include părțile interesate în identificarea riscurilor. Proiectele și programele au de obicei mai multe părți interesate care aduc diferite dimensiuni ale riscului rezultatelor. Acestea includ operatorii, care ar putea fi copleșiți de noi sisteme; utilizatorii, care ar putea să nu fie instruiți corespunzător sau să aibă temeri pentru locurile lor de muncă; supraveghetorii care ar putea să nu susțină o nouă capacitate, deoarece pare să le diminueze autoritatea; și factorii de decizie politică, care sunt preocupați de aprobarea legislativă și de costuri. În plus, este important să se includă toate părțile interesate, cum ar fi autoritățile de certificare și acreditare care, dacă sunt trecute cu vederea din greșeală, pot prezenta riscuri majore mai târziu în program. Părțile interesate pot fi foarte conștiente de diverși factori de mediu, cum ar fi legislația în așteptare sau sprijinul programului politic care pot prezenta riscuri pentru un proiect necunoscut guvernului sau echipei de proiect MITRE. Includeți părțile interesate în procesul de identificare a riscurilor pentru a ajuta la evidențierea acestor riscuri.
scrieți declarații clare de risc. Utilizarea formatului condiție-dacă-atunci ajută la comunicarea și evaluarea unei declarații de risc și la dezvoltarea unei strategii de atenuare. Cauza principală este condiția de bază care a introdus riscul (de exemplu, o abordare de proiectare ar putea fi cauza), If reflectă probabilitatea (de exemplu, evaluarea probabilității ca porțiunea If a Declarației de risc să apară) și apoi comunică impactul programului (de exemplu, resurse sporite pentru a sprijini testarea, programul suplimentar și preocuparea pentru îndeplinirea performanței). Strategia de atenuare este aproape întotdeauna mai bună atunci când se bazează pe o declarație de risc clar articulată.
așteptați modificări ale declarațiilor de risc pe măsură ce se elaborează strategia de evaluare și atenuare a riscurilor. Este obișnuit ca declarațiile de risc să fie rafinate odată ce echipa evaluează impactul. Atunci când se evaluează și se documentează impactul potențial al riscului (cost, program, tehnic sau interval de timp), înțelegerea și declarația riscului s-ar putea schimba. De exemplu, atunci când se evaluează un impact de risc al alunecării programului software, Declarația de risc ar putea fi rafinată pentru a include data necesară și/sau clarificarea suplimentară a impactului (de exemplu, dacă software-ul xyz nu este livrat până în martie 2015, atunci nu va fi suficient timp pentru a testa schimburile de interfețe înainte de testul limitat al utilizatorului).
nu includeți Declarația de atenuare în declarația de risc. Aveți grijă să nu cădeți în capcana introducerii Declarației de atenuare în declarația de risc. Un risc este o incertitudine cu potențial impact negativ. Unii ajung rapid la concluzia diminuării riscului și, în loc să identifice riscul care ar trebui atenuat (cu opțiunile de atenuare identificate), identifică riscul ca o abordare de proiectare suboptimă. De exemplu, o declarație de risc ar putea fi: dacă contractantul nu utilizează XYZ pentru testare, atunci testul va eșua. Preocuparea este într-adevăr suficientă testare. Dacă contractantul nu efectuează testul cu rezultate măsurabile pentru analiză, atunci programul nu poate trece testul limitat al utilizatorului. Utilizarea XYZ poate fi o opțiune de atenuare pentru a reduce riscul de suficiență a testului.
nu treceți la o strategie de atenuare înainte de a evalua probabilitatea și impactul riscului. Un risc poate fi rafinat sau modificat, având în vedere o analiză suplimentară, care ar putea afecta ceea ce poate fi cea mai eficientă/dorită atenuare. Inginerii SAR adesea la soluție; cel mai bine este să treceți la pasul următor discutat în articolul de evaluare a impactului riscurilor și prioritizare pentru a descompune și a înțelege mai întâi problema. În cele din urmă, acest lucru va duce la o strategie care este strâns aliniată cu îngrijorarea.
referințe & resurse
- Institutul MITRE, 1 septembrie 2007, modelul de competență MITRE Systems Engineering (SE), Versiunea 1, PP.10, 40-41.
- Garvey, P. R., 2008, metode analitice pentru Managementul Riscului: o perspectivă de Inginerie a sistemelor, Chapman-Hall/CRC-Press, Taylor & Francis Group (MAREA BRITANIE), Boca Raton, Londra, New York, ISBN: 1584886374.Forțele Aeriene ale SUA, ianuarie 2008, Ghidul de evaluare a performanței anterioare a Forțelor Aeriene (PPEG), IG5315.305(a).
- Forțele Aeriene ale SUA, ianuarie 2008, Ghidul de evaluare a performanței anterioare a Forțelor Aeriene (PPEG), IG5315.305(a).
Referințe suplimentare& resurse
MITRE E520 Analiza riscurilor și Management liste de verificare echipa tehnică, controale de risc, analiza riscurilor și documente de Management.
Institutul de Management de proiect, Un ghid pentru corpul de cunoștințe de Management de proiect, (ghid PMBOK), ediția a patra, ANSI/PMI 99-001-2008, PP.273-312, accesat la 2 martie 2010.
SEPO, „proces Standard/pași de proces, Pasul 2: identificați riscurile & pericole”, set de instrumente MITRE SEPO pentru gestionarea riscurilor, accesat la 5 mai 2010.
