riskidentifiering

Definition: riskidentifiering är processen för att bestämma risker som potentiellt kan förhindra att programmet, företaget eller investeringen uppnår sina mål. Det inkluderar att dokumentera och kommunicera oro.

nyckelord: risk, riskidentifiering, riskhantering

MITRE se Roller & förväntningar: MITRE systems engineers (SEs) som arbetar med statliga program förväntas identifiera risker som kan påverka projektet och programmet. De förväntas skriva och granska riskdeklarationer som är tydliga, entydiga och stöds av bevis .

Bakgrund

riskidentifiering är det kritiska första steget i riskhanteringsprocessen som visas i Figur 1.

målet med riskidentifiering är tidig och kontinuerlig identifiering av händelser som, om de inträffar, kommer att ha negativa effekter på projektets förmåga att uppnå prestanda eller kapacitetsutfallsmål. De kan komma från projektet eller från externa källor.

det finns flera typer av riskbedömningar, inklusive programriskbedömningar, riskbedömningar för att stödja ett investeringsbeslut, analys av alternativ och bedömningar av operativ eller kostnadsosäkerhet. Riskidentifiering måste matcha den typ av bedömning som krävs för att stödja riskinformerat beslutsfattande. För ett förvärvsprogram är det första steget att identifiera programmets mål och mål, vilket främjar en gemensam förståelse över teamet för vad som behövs för programframgång. Detta ger sammanhang och begränsar omfattningen av vilka risker identifieras och utvärderas.

identifiera risker i Systemteknikprogrammet

det finns flera riskkällor. För riskidentifiering bör projektgruppen granska programmets omfattning, kostnadsberäkningar, schema (för att inkludera utvärdering av den kritiska vägen), teknisk mognad, viktiga prestandaparametrar, prestandautmaningar, intressenters förväntningar jämfört med nuvarande plan, externa och interna beroenden, implementeringsutmaningar, integration, interoperabilitet, stödbarhet, sårbarheter i försörjningskedjan, förmåga att hantera hot, kostnadsavvikelser, förväntningar på testhändelser, säkerhet, säkerhet och mer. Dessutom ger historiska data från liknande projekt, intressentintervjuer och risklistor värdefull inblick i områden för riskbedömning.

riskidentifiering är en iterativ process. När programmet fortskrider kommer mer information att erhållas om programmet (t.ex. specifik design) och riskdeklarationen kommer att justeras för att återspegla den nuvarande förståelsen. Nya risker kommer att identifieras när projektet fortskrider genom livscykeln.

bästa praxis och lärdomar

operativ Risk. Förstå den operativa karaktären hos de funktioner du stöder och risken för slutanvändarna, deras uppdrag och deras verksamhet av funktionerna. Förståelse för det operativa behovet / uppdraget (se Konceptutvecklingsämnet i Systemteknikguiden) hjälper dig att uppskatta allvaret av risker och den inverkan de kan ha för slutanvändarna. Detta är en kritisk del av riskanalysen-realisera den verkliga påverkan som kan uppstå om en risk uppstår under operativ användning. Vanligtvis är operativa användare villiga att acceptera en viss risknivå om de kan utföra sitt uppdrag (t.ex. uppdragsförsäkring), men du måste hjälpa användarna att förstå de risker de accepterar och bedöma tillgängliga alternativ, saldon och alternativ.

teknisk löptid. Arbeta med och utnyttja industrin och akademin för att förstå den teknik som övervägs för en ansträngning och den troliga övergången av tekniken över tiden. Ett tillvägagångssätt är att arbeta med leverantörer enligt ett sekretessavtal för att förstå kapaciteten och vart de ska, så att risken kan bedömas.

icke-utvecklingsobjekt (NDI). NDI inkluderar kommersiella-Off-the-shelf och regeringen-off-the-shelf objekt. För att hantera risker, överväga ndi-leverantörens lönsamhet. Har leverantören marknadsandelar? Har leverantören lämplig livslängd jämfört med sina konkurrenter? Hur hanterar leverantören kapacitetsproblem och släppfixar etc.? Vad är användarbasen för den specifika NDI? Kan leverantören visa NDI, helst i en miljö som liknar din kunds? Kan regeringen använda NDI för att skapa en prototyp? Alla dessa faktorer kommer att bidra till att bedöma risken för ndi: s och leverantörens lönsamhet. Sök svar på dessa frågor från annan MITRE-personal som har arbetat i området eller har använt NDI som bedöms.

förvärvs drivrutiner. Betona kritiska förmåga möjliggörare, särskilt de som har begränsade alternativ. Utvärdera och bestämma de primära drivkrafterna för ett förvärv och betona deras associerade risk vid formulering av riskreduceringsrekommendationer. Om en viss aspekt av en förmåga inte är avgörande för dess framgång, bör dess risk bedömas, men det behöver inte vara det primära fokus för riskhantering. Till exempel, om det finns risk för ett föreslaget användargränssnitt, men marknaden har många alternativ, är framgången med det föreslagna tillvägagångssättet förmodligen mindre avgörande för kapacitetens övergripande framgång. Å andra sidan är en informationssäkerhetsfunktion sannolikt kritisk. Om bara ett alternativt tillvägagångssätt uppfyller behovet, bör tonvikten läggas på det. Bestäm de främsta framgångsdrivrutinerna genom att utvärdera behov och mönster och bestämma vilka alternativ som finns. Är en unik lösning på den kritiska vägen till framgång? Se till att kritiska väganalyser inkluderar hela systemteknikcykeln och inte bara utveckling (dvs. systemutveckling kan i sig vara en ”bit kaka”, men fält i en aktiv driftssituation kan vara en stor risk).

använd capability evolution för att hantera risker. Om särskilda krav Driver genomförandet av kapacitet som är hög risk på grund av unik utveckling, edge-of-the-envelope prestandabehov, etc., kraven bör diskuteras med användarna för deras kritik. Det kan vara så att behovet kan skjutas upp, och utvecklingsgemenskapen bör bedöma när det kan vara nöjd i framtiden. Hjälp användare och utvecklare att mäta hur mycket risk (och schema och kostnadspåverkan) en viss kapacitet bör anta mot kraven för att få mindre riskfyllda funktioner tidigare. När du utvecklar dina rekommendationer, överväga teknisk genomförbarhet och kunskap om relaterade implementeringsframgångar och misslyckanden för att bedöma risken för att implementera nu istället för framtiden. När du skjuter upp kapacitet, var försiktig så att du inte faller i fällan att skjuta upp det ultimata misslyckandet genom att handla på kort sikt enkla framgångar för en framtid med flera högriskkrav som kan vara avgörande för övergripande framgång.

Viktiga Prestandaparametrar (KPPs). Arbeta nära användarna för att etablera KPPs. Den totala risken för programavbrott kan vara centrerad på misslyckande med att uppfylla KPPs. Arbeta med användarna för att säkerställa att parametrarna är lyhörda för uppdragsbehov och tekniskt genomförbara. Parametrarna bör inte vara så lätta att de lätt kan uppfyllas, men inte uppfylla uppdragsbehovet; inte heller bör de vara så stränga att de inte kan uppfyllas utan en omfattande ansträngning eller tryckteknik—varav någon kan äventyra ett program. Sök Resultat från tidigare operationer, experiment, prestationsbedömningar och branschimplementeringar för att bestämma genomförbarheten av prestanda.

externa och interna beroenden. Att ha ett företagsperspektiv kan hjälpa förvärvare, programchefer, Utvecklare, integratörer och användare att uppskatta risken från beroenden av en utvecklingsinsats. Med uppkomsten av serviceorienterade tillvägagångssätt kommer ett program att bli mer beroende av tillgängligheten och driften av tjänster som tillhandahålls av andra som de tänker använda i sitt programs utvecklingsinsatser. Arbeta med utvecklare av tjänster för att säkerställa kvalitetstjänster skapas, och tanke har lagts på underhåll och utveckling av dessa tjänster. Arbeta med utvecklingsprogrammets personal för att bedöma de tjänster som finns tillgängliga, deras kvalitet och risken för att ett program använder och förlitar sig på tjänsten. På samma sätt finns det en risk förknippad med att skapa tjänsten och inte använda tjänster från en annan företagsinsats. Hjälp att bestämma riskerna och de potentiella fördelarna med att skapa en tjänst som är intern för utvecklingen med eventuellt en övergång till företagstjänsten någon gång i framtiden.

Integration och interoperabilitet (i &I). I& jag kommer nästan alltid att vara en viktig riskfaktor. De är former av beroenden där värdet av att integrera eller interoperera har bedömts åsidosätta deras inneboende risker. Tekniker som enterprise federation architecting, composable capabilities on demand och designmönster kan hjälpa regeringen att planera och genomföra en rutt för att navigera i i&i-risker. Se avsnittet företagsteknik i Systemteknikguiden för artiklar om tekniker för att hantera i &i-associerade risker.

informationssäkerhet. Informationssäkerhet är en risk i nästan varje utveckling. En del av detta beror på det unika med regeringens behov och krav på detta område. En del av detta beror på de inneboende svårigheterna att motverka cyberattacker. Att skapa defensiva förmågor för att täcka spektrumet av attacker är utmanande och riskabelt. Hjälp regeringen att utveckla resiliency-metoder (t.ex. beredskapsplaner, säkerhetskopiering/återställning etc.). Att möjliggöra informationsutbyte mellan system i koalitionsverksamhet med internationella partners innebär tekniska utmaningar och policyfrågor som leder till utvecklingsrisk. Informationssäkerhetsproblemen i samband med supply chain management är så breda och komplexa att även upprätthålla rudimentär medvetenhet om hoten är en enorm utmaning.

skicklighetsnivå. Kompetensen eller erfarenhetsnivån hos utvecklare, integratörer, myndigheter och andra intressenter kan leda till risker. Var på jakt efter otillräckliga färdigheter och nå över företaget för att fylla eventuella luckor. På så sätt hjälper du till att utbilda regeringsteammedlemmar samtidigt som du tar med företagskunskaper och erfarenhet att bära.

Kostnadsrisker. Program kommer vanligtvis att skapa en regeringens kostnadsberäkning som beaktar risken. När du utvecklar och förfinar programmets tekniska och andra risker bör de tillhörande kostnadsberäkningarna också utvecklas. Kostnadsberäkning är inte en engångsaktivitet.

historisk information som en guide till riskidentifiering. Historisk information från liknande regeringsprogram kan ge värdefull inblick i framtida risker. Sök information om operativa utmaningar och risker i olika operativa lärdomar, efter åtgärdsrapporter, övningssammanfattningar och experimentresultat. Kunder har ofta förråd av dessa att komma åt. Regeringsledare kommer normalt att kommunicera sina strategiska behov och utmaningar. Förstå och faktor dessa i din bedömning av de viktigaste funktionerna som behövs av din kund och som underlag för riskbedömningar.

historiska data som hjälper till att bedöma risker är ofta tillgängliga från tidigare prestationsbedömningar och lärdomar från förvärvsprogram och entreprenörer. I många fall kommer MITRE-personal att hjälpa regeringen att förbereda prestandainformation för ett visst förvärv. AF har en Past Performance Evaluation Guide (Ppeg) som identifierar vilken typ av information som ska fångas som kan användas för framtida statliga källval . Detta arkiv med information kan hjälpa till att ge bakgrundsinformation om tidigare utmaningar och var de kan uppstå igen—både för den specifika typen av utvecklingsaktivitet och med de specifika entreprenörerna.

det finns många tekniska bedömningar för leverantörsprodukter som kan nås för att bestämma risken och lönsamheten för olika produkter. Ett MITRE-arkiv med utvärderingar av verktyg är analysverktyget som innehåller vägledning om och erfarenhet av analysverktyg. Att använda resurser som dessa och söka andra som har provat produkter och tekniker i prototyper och experiment kan hjälpa till att bedöma riskerna för en viss insats.

hur man skriver en risk-en bästa praxis . Ett protokoll för bästa praxis för att skriva ett riskdeklaration är Condition-If-Then construct. Detta protokoll gäller för riskhanteringsprocesser utformade för nästan alla miljöer. Det är ett erkännande av att en risk till sin natur är probabilistisk och en som, om den inträffar, har oönskade konsekvenser.

Vad är Condition-If-then construct? Villkoret återspeglar vad som är känt idag. Det är grundorsaken till den identifierade riskhändelsen. Således är tillståndet en händelse som har inträffat, för närvarande inträffar eller kommer att inträffa med säkerhet. Riskhändelser är framtida händelser som kan uppstå på grund av det aktuella tillståndet. Nedan följer en illustration av detta protokoll.

If är riskhändelsen associerad med det aktuella tillståndet. Det är kritiskt viktigt att känna igen If och villkoret som en dubbel. När det undersöks gemensamt kan det finnas sätt att direkt ingripa eller avhjälpa riskhändelsens underliggande rot (tillstånd) så att konsekvenserna av denna händelse, om den inträffar, inte längre hotar projektet. If är den probabilistiska delen av riskdeklarationen.

då är konsekvensen eller uppsättningen konsekvenser som kommer att påverka ingenjörssystemprojektet om riskhändelsen inträffar. Ett exempel på en Condition-If-Then-konstruktion illustreras i Figur 2.

uppmuntra team att identifiera risker. Kulturen i vissa statliga projekt och program avskräcker identifieringen av risker. Detta kan uppstå eftersom riskhanteringsaktiviteterna för att spåra, övervaka och mildra riskerna ses som betungande och ohjälpsamma. I den här situationen kan det vara bra att prata med teamen om fördelarna med att identifiera risker och oförmågan att hantera allt i dina huvuden (t. ex., bestämma prioritet, vem som behöver vara involverad, begränsningsåtgärder). Hjälp regeringsteamen att genomföra en process som balanserar förvaltningsinvesteringar med värde för projektets resultat. I allmänhet uppnås en bra balans när projektets omfattning, schema och kostnadsmål uppnås eller framgångsrikt mildras av handlingsplaner, och projektgruppen anser att riskhanteringsaktiviteter ger projektet värde. Korsteamsrepresentation är ett måste; risker bör inte identifieras av en individ eller strikt av systemteknikteamet (granska riskkällor ovan).

Tänk på organisatoriska och miljömässiga faktorer. Organisatoriska, kulturella, politiska och andra miljöfaktorer, såsom intressentstöd eller organisatoriska prioriteringar, kan utgöra lika mycket eller mer risk för ett projekt än enbart tekniska faktorer. Dessa risker bör identifieras och aktivt mildras under hela projektets livstid. Mitigationsaktiviteter kan omfatta övervakning av lagstiftningsmandat eller akuta förändringar som kan påverka programmet eller projektuppdraget, organisatoriska förändringar som kan påverka användarnas krav eller förmåga användbarhet eller förändringar i politiskt stöd som kan påverka finansieringen. I varje fall överväga risken för programmet och identifiera handlingsalternativ för diskussion med intressenter. För ytterligare information, se artikeln riskreducering planering, genomförande och övervakning av framsteg.

inkludera intressenter i riskidentifiering. Projekt och program har vanligtvis flera intressenter som ger olika dimensioner av risk för resultaten. De omfattar operatörer, som kan vara överväldigade med nya system; användare, som kanske inte är ordentligt utbildade eller har rädsla för sina jobb; Handledare som kanske inte stöder en ny kapacitet eftersom det verkar minska deras auktoritet; och beslutsfattare, som är intresserade av lagstiftningsgodkännande och kostnader. Dessutom är det viktigt att inkludera alla intressenter, såsom certifierings-och ackrediteringsmyndigheter som, om de oavsiktligt förbises, kan utgöra stora risker senare i programmet. Intressenter kan vara mycket medvetna om olika miljöfaktorer, till exempel pågående lagstiftning eller politiskt programstöd som kan utgöra risker för ett projekt som är okänt för regeringen eller MITRE-projektgruppen. Inkludera intressenter i riskidentifieringsprocessen för att hjälpa till att täcka dessa risker.

skriv tydliga riskdeklarationer. Med hjälp av Condition-If-Then-formatet kan du kommunicera och utvärdera en riskdeklaration och utveckla en begränsningsstrategi. Grundorsaken är det underliggande tillståndet som har infört risken (t.ex. en designmetod kan vara orsaken), If återspeglar sannolikheten (t. ex. sannolikhetsbedömning att If-delen av riskdeklarationen skulle inträffa) och sedan kommunicerar effekten till programmet (t. ex. ökade resurser för att stödja testning, ytterligare schema och oro för att uppfylla prestanda). Begränsningsstrategin är nästan alltid bättre när den bygger på ett tydligt formulerat riskdeklaration.

förvänta ändringar av riskdeklarationen när riskbedömnings-och riskreduceringsstrategin utvecklas. Det är vanligt att ha riskdeklarationer förfinade när teamet utvärderar effekten. Vid bedömning och dokumentation av den potentiella riskeffekten (kostnad, tidsplan, teknisk eller tidsram) kan förståelsen och redogörelsen för risken förändras. Till exempel, vid bedömning av en riskpåverkan av Programvarans schema, kan riskdeklarationen förfinas för att inkludera behovsdatum och/eller ytterligare förtydligande av påverkan (t.ex. om xyz-programvaran inte levereras i mars 2015, kommer det inte att finnas tillräckligt med tid för att testa gränssnittsutbytet före begränsat användartest).

inkludera inte riskdeklarationen. Var försiktig så att du inte faller i fällan att ha begränsningsdeklarationen införd i riskdeklarationen. En risk är en osäkerhet med potentiell negativ påverkan. Vissa hoppar snabbt till slutet av riskminskningen och i stället för att identifiera den risk som bör mildras (med identifierade begränsningsalternativ) identifierar de risken som en suboptimal designmetod. Till exempel kan ett riskdeklaration vara: om entreprenören inte använder XYZ för test, kommer testet att misslyckas. Oron är verkligen testa tillräcklighet. Om entreprenören inte utför testet med mätbara resultat för analys, kan programmet inte passera begränsat användartest. Användning av XYZ kan vara ett begränsningsalternativ för att minska risken för test tillräcklighet.

hoppa inte till en begränsningsstrategi innan du bedömer risksannolikheten och effekten. En risk kan förfinas eller ändras med ytterligare analys, vilket kan påverka vad den mest effektiva/önskade begränsningen kan vara. Ingenjörer hoppar ofta till lösningen; det är bäst att gå vidare till nästa steg som diskuteras i artikeln Risk Impact Assessment and Prioritation för att sönderdela och förstå problemet först. I slutändan kommer detta att leda till en strategi som är nära anpassad till oro.

referenser & resurser

1. MITRE Institute, September 1, 2007, MITRE Systems Engineering (SE) Kompetensmodell, Version 1, s.10, 40-41.
2. Garvey, pr, 2008, analysmetoder för riskhantering: ett Systemtekniskt perspektiv, Chapman-Hall / CRC-Press, Taylor & Francis Group (UK), Boca Raton, London, New York, ISBN: 1584886374.US Air Force, januari 2008, Air Force Past Performance Evaluation Guide(PPEG), IG5315.305 (a).
3. US Air Force, januari 2008, Flygvapnets Utvärderingsguide för tidigare resultat(PPEG), IG5315.305 (a).

ytterligare referenser & resurser

MITRE E520 riskanalys och hantering tekniska team checklistor, riskkontroller, riskanalys och Förvaltningsdokument.

Project Management Institute, en Guide till Project Management Body of Knowledge, (PMBOK Guide), fjärde upplagan, ANSI/PMI 99-001-2008, s.273-312, åtkomst 2 mars 2010.

SEPO, ” standardprocess/steg för Process, steg 2: identifiera risker & faror,” MITRE SEPO Risk Management Toolkit, åtkomst 5 maj 2010.