타스크: 위험성 식별 및 평가
이 타스크는 프로젝트에 대한 위험성을 식별 및 분석하고 우선순위를 결정하며 적합한 위험성 관리 전략을 결정하고 이들을 프로젝트에 대한 위험성 목록에 반영하는 방법을 설명합니다.
원칙: 프로젝트 관리
목적
  • 프로젝트에 대한 위험성을 식별 및 분석하고 우선순위 결정
  • 적합한 위험성 관리 전략 결정
  • 현재 프로젝트 상태를 반영하도록 위험성 목록 갱신
관계
단계
잠재적 위험성 식별
목적 프로젝트에서 '잘못될 수 있는 사항'의 인벤토리를 작성합니다. 

위험성 목록 시작(도입/인식(Inception) 단계에서)

프로젝트 팀을 한데 모으십시오. (이 시점에서는 아주 작습니다. 프로젝트 팀에 6 - 7명이 있는 경우 위험성 평가 프로세스를 활동 리더로 제한하십시오.)

위험성을 식별할 때 '잘못될 수 있는 사항'을 고려합니다. 물론 넓게 보면 모든 것이 잘못될 수 있습니다. 그러나 중요한 점은 프로젝트를 비관적으로 보지 않는 것입니다. 성공에 대한 잠재적인 장애물을 줄이거나 제거할 수 있도록 식별하는 것이 목적입니다. 자세한 정보는 중간 산출물 가이드라인: 위험성 목록을 참조하십시오.

보다 자세하게는 주어진 시간 내/예산 내에서 프로젝트에 올바른 기능, 필요한 품질 수준을 제공할 수 있을 가능성을 감소시키는 발생 가능한 이벤트를 찾고 있습니다.

브레인스토밍 기법을 사용하여 각 구성원에게 프로젝트 위험성을 식별하도록 요청하십시오. 명확성을 위한 질문은 허용되지만, 해당 그룹에서 위험성을 평가하거나 주석을 달아서는 안됩니다. 더 이상의 위험성을 식별할 수 없을 때까지 반복적으로 검토하십시오.

이 프로세스에 모든 관계자를 참여시키되 양식이나 중복에 대해서는 너무 걱정하지 마십시오. 나중에 목록을 정리할 수 있습니다. 동종의 그룹(고객, 사용자, 기술직 등)을 사용하십시오. 이는 위험성 수집 프로세스를 쉽게 만듭니다. 즉, 개인은 큰 혼합 그룹보다 동료(전공 및 직위 면에서) 앞에서 덜 위축됩니다.

위험성의 제기가 어떤 식으로든 해당 위험성의 자발적 처리를 의미하지는 않음을 참가자들에게 주지시키십시오. 위험성 제기 시 해당 위험성 처리 책임을 맡게 될 것이라는 느낌이 조금이라도 있으면 누구도 위험성을 식별하지 않을 것입니다(또는 제기되는 위험성이 사소하게 됨).

이를 촉진하기 위해 Capers Jones의 Assessment and Control of Software Risks[JON94] 또는 Software Engineering Institute에서 발간한 Taxonomy-Based Risk Identification [CAR93] 같은 일반 위험성 목록으로 시작해보십시오. 위험성 목록을 회람하십시오. 이미 식별된 것을 보면 종종 더 많은 것을 식별하는 데 도움이 됩니다.

위험성 목록 갱신(차후 단계에서)

위에서 식별된 대로 입력을 요청할 수 있습니다. 그러나 일반적으로 기존 목록의 예제를 기반으로 팀 구성원이 새 위험성을 식별하며 일반 프로젝트 상태 평가에서 캡처됩니다. 타스크: 반복 평가를 참조하십시오.

위험성 분석 및 우선순위 결정
목적 비슷한 위험성을(위험성 목록의 크기를 줄이기 위해) 결합합니다.
프로젝트에 대한 영향에 따라서 위험성의 등급을 매깁니다. 

더 이상의 위험성을 찾지 못하면 위험성 목록을 하나의 그룹으로 보고 자연스런 그룹화(동일한 위험성의 발생)가 가능한지 확인한 다음 가능하면 위험성을 결합하여 중복을 제거하십시오. 가끔, 식별된 위험성이 좀 더 근본적인 위험성의 증상일 수 있습니다. 이 경우 관련된 위험성을 보다 근본적인 위험성 아래에 함께 그룹화하십시오.

정량적 위험성 관리 기법은 위험성이 프로젝트에 표시하는 전체적인 위험성 노출에 따라서 위험성의 우선순위를 결정할 것을 권장합니다. 각 위험성에 대한 노출을 판별하려면 그룹에서 다음 정보를 예상해야 합니다.

위험성의 영향  위험성이 발생하는 경우 계획에 대비한 스케줄, 노력 또는 비용의 편차 
발생 가능성  위험성이 실제로 발생할 확률(대개 백분율로 표현) 
위험성 노출  발생 가능성에 영향을 곱하여 계산 

그룹에서 각 위험성의 노출은 합의에 의해 파생되어야 합니다. 상당한 의견 차이가 있는 경우 추가로 논의하여 모든 사람이 동일한 방식으로 위험성을 해석하고 있는지 확인해야 합니다. 일반적으로 이 정보는 표 형식의 위험성 목록에 열로 포함됩니다.

사람은 본능적으로 가장 높은 영향을 가지는 위험성에 대해 걱정하게 됩니다. 그러나, 이들이 발생할 가능성이 아주 낮은 경우, 실제로는 종종 간과되는 중간 정도의 위험성보다 덜 중요합니다. 이 접근 방식은 위험성의 크기와 발생 가능성을 모두 고려함으로써 프로젝트 관리자가 프로젝트 인도에 가장 중요한 효과를 가지는 영역에 위험성 관리 노력을 집중하도록 도와줍니다.

각 위험성에 대한 노출이 결정된 후에 위험성을 노출의 내림차순으로 정렬하여 "최상위 10" 위험성 목록을 작성할 수 있습니다.

가능성 및 비용의 예상 자체가 비용이 많이 들고 위험하기 때문에 일반적으로 최상위 10개에서 20개 위험성의 영향을 판단하는 데에만 유용합니다. 더 작은 프로젝트는 더 적은 위험성을 고려할 수 있는 반면, 더 큰 프로젝트는 더 큰 '위험성 대상'을 제공하고 결과적으로 많은 수의 관련 위험성을 갖습니다.

노출 정도의 내림차순으로 위험성의 등급을 매기는 것 외에, 프로젝트에 대한 영향의 크기(위험성 크기)를 기반으로 위험성을 카테고리로 그룹화 또는 클러스터화하는 것이 유용할 수도 있습니다. 대부분의 경우 다음의 다섯 개 카테고리로 충분합니다.

  1. 높음
  2. 중요
  3. 보통
  4. 사소
  5. 낮음

위험성을 문서화하고 프로젝트 팀 구성원 사이에 회람시키십시오.

위험성 회피 전략 식별
목적 위험성을 제거하도록 프로젝트를 재구성합니다. 

항상 가능하지는 않지만 가끔은 위험성을 완전히 회피할 수 있습니다. 종종 위험성은 빈약한 시스템 범위에 의해 유발됩니다. 시스템의 범위를(본질적이 아닌 요구사항을 제거하여) 축소할 수 있는 경우 위험성 목록의 전체 섹션이 제거된 요구사항과 함께 제거됩니다. 이러한 위험성의 상당수는 작업을 수행할 충분한 자원(시간 포함)이 없는 위험성입니다.

다른 경우에는 특정 기능성을 빌드하는 위험성을 축소하기 위한 기술을 획득할 수 있습니다. 한 위험성 세트(기술을 구축하는 위험성)가 다른 세트(제어 불가능한 요소에 의존하는 위험성)과 교환되는 위험성 회피의 한 양식입니다.

마지막으로 위험성을 다른 조직으로 이전할 수 있습니다.

위험성 완화 전략 식별
목적 위험성을 완화시키는, 즉 위험성의 영향을 축소하는 계획을 개발합니다. 

직접 위험성, 즉 프로젝트가 어느 정도 제어할 수 있는 위험성에 대해, 위험성의 확률을 줄이기 위해 또는 프로젝트에 대한 영향을 줄이기 위해(완화 전략) 취할 조치를 식별하십시오. 일반적으로 위험성 자체는 정보 부족에서 파생됩니다. 따라서 완화 전략 자체는 불확실성을 더 줄이기 위한 주제 조사 중 하나입니다.

위험성을 구체화하거나 제거하기 위해 어떤 조치를 취할 수 있는 위험성이 있습니다. 반복 개발 프로세스에서 그런 조치를 초기 반복에 할당하여 가능한 빨리 위험성을 완화하십시오. 가능한 빨리 위험에 직면하십시오. 위험성이 "X가 계획대로 기능할 수 없습니까?"의 양식을 갖는 경우 가능한 빨리 X를 시도하도록 계획하십시오.

예제:

  • 제품 X와 Y가 통합될 수 없는 위험성을 줄이기 위해 통합의 어려움을 조사하기 위한 프로토타입을 빌드합니다. 성공적인 통합을 위해 다음 기능(목록에 나열)을 테스트합니다.
  • 데이터베이스 A가 적절히 수행되지 않을 위험성을 줄이기 위해 대상 응용프로그램의 워크로드를 모델링하는 테스트 스위트를 사용하여 벤치마크를 수행합니다.
  • 테스트 도구 Z가 응용프로그램을 효과적으로 회귀 테스트할 수 없을 위험성을 줄이기 위해, 곧 진행될 반복 중에 해당 도구를 확보하여 사용합니다.

이러한 조치의 결과로 특정 위험성이 발생할 확률이 거의 0까지 줄어 들어야 합니다. 위험성이 확인되는 경우 위험성은 비상사태 계획으로 응답됩니다(비상사태 전략 식별 참조).

비상사태 전략 식별
목적 대체 계획을 개발합니다. 

각 위험성에 대해 해당 위험성을 능동적으로 완화시킬 계획이 있는지 여부와 상관없이 위험성이 구체화되는 경우 즉 문제점, 보험 전문 용어로 '손실 사건'이 되는 경우 취해야 하는 조치를 결정해야 합니다. 이를 일반적으로 "계획 'B'" 또는 비상사태 계획이라고 부릅니다. 비상사태 계획은 위험성 회피 및 위험성 이전이 실패했고 완화가 그렇게 성공적이지 않으며 이제 위험성을 정면으로 다루어야 할 때 필요합니다. 이는 간접 위험성, 즉 프로젝트가 제어할 수 없는 위험성이나 완화 전략을 구현하는데 너무 많은 비용이 드는 경우 자주 발생합니다.

비상사태 계획은 다음을 고려해야 합니다.

위험성 

지표 

조치 

위험성이 무엇입니까?  위험성이 현실이 되었음을 어떻게 압니까? '손실 이벤트'를 어떻게 인식합니까?  '손실 이벤트'를 다루기 위해 해야 하는 사항("출혈"을 어떻게 멈출 수 있습니까?) 

위험성 지표 식별

일부 위험성은 동향과 임계값을 보고 프로젝트 메트릭을 사용하여 모니터할 수 있습니다. 예를 들어 다음과 같습니다.

  • 재작업이 여전히 너무 많음
  • 파손이 여전히 너무 많음
  • 실제 지출이 계획보다 훨씬 많음

일부 위험성은 프로젝트 요구사항 및 테스트 결과를 기반으로 모니터할 수 있습니다. 예를 들어 다음과 같습니다.

  • 응답 시간이 요구사항보다 1 크기 정도 높습니다.

일부 위험성은 특정 이벤트와 연관됩니다. 예를 들어 다음과 같습니다.

  • 써드파티에서 소프트웨어 컴포넌트를 제 시간에 전달하지 않습니다.

"더 약한" 지표도 달리 많이 있지만 문제점을 완전히 진단해 주지는 않습니다. 예를 들어 사기가 떨어질 위험성이 항상 있습니다(사실, 프로젝트의 특정 시점에 거의 확실히 발생함 - 예측 가능). 불평, "분위기에 안맞는 농담", 최종 기한 어김, 낮은 품질 등의 많은 지표가 있습니다. 어떤 "지표"도 확실하지는 않습니다. 특정 인도물이 쓸모없다는 농담은 스트레스를 푸는 건전한 방법일 수 있지만, 계속되는 경우 팀이 점점 더 실패를 느끼고 있다는 표시일 수 있습니다.

비난하지 말고 모든 지표에 귀기울이십시오. '나쁜 소식'을 전하는 사람은 나쁜 태도를 가진 사람으로 오인하기 쉽지만, 냉소 뒤에 어느 정도의 진실이 숨어 있는 경우가 종종 있습니다. '나쁜 소식을 전하는 사람'이 '프로젝트의 양심'인 경우가 종종 있습니다. 대부분의 사람은 프로젝트가 성공하길 원하며, 프로젝트가 다른 방향으로 추진되고 있을 때 실망합니다.

"손실" 조치 또는 "계획 B" 식별

단순한 경우에 비상사태 계획은 대체 솔루션을 나열합니다. 그 영향은 대개 현재 솔루션을 폐기하고 새 솔루션을 구현하기 위한 비용과 지연입니다.

다른 경우, "더 약한" 위험성은 종종 손실이 발생했을 때 취할 하나의 조치가 아니라 여러 개의 조치입니다. 예를 들어 사기가 저하되는 경우 그 상태를 인지하고 프로젝트에 대한 우세한 태도를 논의하기 위해 그룹으로 모으는 것이 가장 좋습니다. 관심사항 듣고 문제를 식별하고 전체적으로 사람들이 감정을 발산하게 하십시오. 적당히 감정을 표출한 후 관심사항의 원인을 다루는 쪽으로 이동하십시오. 논의를 집중하기 위한 방법으로 위험성 목록을 사용하십시오. 위험성의 우선순위를 다시 정하고 최상위 위험성을 조직적으로 다루기 위해 반복 계획을 다시 공식화하여 관심사항을 구체적인 조치 계획으로 변환하십시오. 긍정적인 조치가 긍정적인(그러나 공허한) 단어보다 더 강력한 효과를 갖습니다.

이 시점의 분위기에도 불구하고 손실 발생은 조치를 강제하는 긍정적인 측면을 갖습니다. 종종 위험성을 무시하고 명백한 침묵으로 자기 만족에 빠져 위험성을 뒤로 미루기 쉽습니다. 손실 이벤트가 발생하면 조치가 필요하게 됩니다. 위험성은 더 이상 위험성이 아니며, 위험성의 발생에 대한 불확실성이 없어집니다.

손실 발생은 위험성 방지 또는 완화에 실패한 것입니다. 위험성 목록을 다시 평가하여 프로젝트 팀이 어떤 조직적인 맹점을 갖지 않는지 판단해야 합니다. 자기 평가가 솔직하기 어려운 만큼 나중에 다른 문제점이 발생하는 것을 막을 수 있습니다.

반복 중에 위험성 재확인
목적 프로젝트 내내 위험성 목록이 최신으로 유지되도록 합니다. 

위험성 평가는 프로젝트의 특정 간격에서만 발생하는 것이 아니라 실제로는 계속되는 프로세스입니다. 최소한 다음을 수행해야 합니다.

  • 매주 목록을 다시 확인하여 어떤 내용이 변경되었는지 확인해야 합니다.
  • 최상위 10개 항목을 전체 프로젝트에 제시하고 해당 항목에 조치를 취하십시오. 보통 현재 위험성 목록을 상태 평가 보고서에 첨부합니다.
반복 종료 시 위험성 재확인
목적 프로젝트 내내 위험성 목록이 최신으로 유지되도록 합니다. 

반복이 끝날 때 위험성 목록의 측면에서 반복의 목적에 다시 초점을 맞추십시오. 특히, 다음에 유의하십시오.

  • 완전히 완화된 위험성을 제거하십시오.
  • 최근에 발견된 새 위험성을 추가하십시오.
  • 크기를 다시 평가하고 위험성 목록을 다시 정렬하십시오(위험성 분석 및 우선순위 결정 참조).

도입/인식(Inception) 및 정제(Elaboration) 단계에서 위험성 목록이 커지는 것을 발견하는 경우 너무 걱정하지 마십시오. 프로젝트 구성원은 작업을 수행하면서 사소하다고 생각했던 것이 실제로는 위험성을 포함함을 인식하게 됩니다. 통합 작업을 수행하면서 어떤 숨겨진 어려움을 발견할 수 있습니다. 그러나 프로젝트가 정제의 후반부에 도달할수록, 그리고 구현/구축(Construction) 중에 위험성은 점점 줄어들어야 합니다. 그렇지 않은 경우 위험성을 제대로 처리하지 못하고 있거나, 시스템이 너무 복잡하거나, 조직적이고 예측 가능한 방식으로 빌드하는 것이 불가능할 수 있습니다. 자세한 정보는 중간 산출물 가이드라인: 위험성 목록을 참조하십시오.