목적
  • 프로젝트의 위험을 식별하고 분석하며 우선순위를 지정하고, 적절한 위험 관리 전략 판별
  • 현재 프로젝트 상태를 반영하도록 위험 목록 갱신
역할:  프로젝트 관리자 
빈도: 필요에 따라, 일반적으로 반복당 최소 한 번.
단계
입력물: 
 
결과물:   
툴 강좌:   

워크플로우 세부사항:   

잠재적인 위험 식별 페이지 맨 위

목적 프로젝트에서 '잘못될 수 있는 사항'의 목록 작성 

위험 목록을 초기화하려면(개념화 단계에서) 다음을 수행하십시오.

프로젝트 팀을 소집하십시오. (이 때 프로젝트 팀은 소규모이어야 합니다. 팀 구성원이 다섯 명에서 일곱 명 이상인 경우 위험 평가 프로세스를 활동 리더로 제한하십시오.)

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

보다 정확하게 말해, 올바른 기능과 필수적인 품질 레벨을 갖춘 프로젝트를 적시에 예산 범위 내에서 제공할 수 있는 가능성을 감소시킬 수 있는 이벤트를 찾아 내는 것입니다.

브레인스토밍을 통해 각 구성원이 프로젝트 위험을 식별하도록 하십시오. 프로젝트 위험을 분명하게 설명하기 위한 질문은 할 수 있지만 그룹이 위험을 평가하거나 위험에 대한 의견을 첨부해서는 안됩니다. 위험이 식별되지 않을 때까지 논의를 계속하십시오.

이 프로세스에 모든 관계자를 참여시키십시오. 나중에 목록을 정리할 수 있으므로 양식이나 사본 작성에는 지나치게 주의를 기울일 필요가 없습니다. 동종 그룹(고객, 사용자, 기술자 등)을 이용하십시오. 이렇게 하면 위험을 수집하는 프로세스가 용이해 집니다. 상이한 그룹보다는 동료들(기술 및 계층 구조면에서 동등함)과 함께 있는 경우 의견을 자유롭게 게재할 수 있기 때문입니다.

위험을 제기한다고 해서 위험을 자진해서 처리해야 하는 것은 아니라는 것을 참여자가 분명히 인식하도록 하십시오. 위험을 제기하면 위험 처리의 책임도 맡게 된다고 생각하게 되면 아무도 위험을 식별하려고 하지 않을 것이며 또는 사소한 위험만 제기하게 됩니다.

Capers Jones[JON94]의 소프트웨어 위험 평가 및 제어 또는 SEI(Software Engineering Institute)[CAR93]에서 확립한 분류 기반 위험 식별에서 시작해 보십시오. 이미 식별된 위험을 확인하는 것이 도움이 되므로 위험 목록을 회람하십시오.

위험 목록을 갱신하려면(추후 단계에서) 다음을 수행하십시오.

위에서 식별된 사항에 따라 입력을 요청할 수 있습니다. 그러나 일반적으로는 기존 목록의 예를 기반으로 팀 구성원이 새 위험을 식별하고 정기적인 프로젝트 상태 평가에서 이를 캡처합니다. 활동: 반복 평가를 참조하십시오.

위험 분석 및 우선순위 지정 페이지 맨 위

목적 유사한 위험을 결합함(위험 목록의 크기를 줄이기 위해)
프로젝트에 미치는 영향에 따라 위험의 등급을 정함 

더 이상 위험이 발견되지 않으면 위험 목록을 그룹 단위로 검토하여 자연적으로 그룹화될 수 있는 위험(동일한 위험)이 있는지 확인하고, 이들 위험이 중복되지 않도록 위험을 결합하십시오. 식별된 일부 위험은 보다 근본적인 위험의 증상에 해당할 수 있으며 이러한 경우 관련된 위험을 보다 근본적인 위험 아래에 그룹화하십시오.

양적(quantitative) 위험 관리 기술은 프로젝트에 대한 전체적인 위험 노출도에 따라 위험의 우선순위를 정하도록 권장합니다. 각 위험의 노출도를 판별하려면 그룹은 다음 정보를 평가해야 합니다.

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

하나의 그룹으로서 각 위험의 노출도는 합의에 의해 도출되어야 합니다. 견해 차이가 큰 경우 모든 개인이 동일한 방법으로 위험을 해석하고 있는지 확인해야 합니다. 일반적으로 위험 목록 테이블에는 이 정보에 해당하는 컬럼이 포함되어 있습니다.

가장 큰 영향을 미칠 수 있으나 발생 가능성이 거의 없는 위험보다는 흔히 간과할 수 있는 중간 정도의 위험을 관리하는 것이 실제로는 더 중요합니다. 이러한 접근법은 위험의 등급 및 발생 가능성을 모두를 고려하므로 프로젝트 관리자가 프로젝트 제공에 가장 큰 영향을 미치는 영역에 대해 위험 관리 작업을 집중하도록 도와 줍니다.

각 위험의 노출도가 결정되면 노출도의 내림차순으로 "상위 10개" 위험 목록을 작성할 수 있습니다.

위험 발생 가능성 및 비용에 대한 평가는 그 자체로 비용이 많이 들고 위험하기 때문에 일반적으로 상위 10개에서 20개의 위험을 정하는 것이 유용합니다. 소규모 프로젝트는 고려할 위험의 수가 작은 반면 대규모 프로젝트에서는 '위험 대상'이 더 커지므로 관련된 위험의 수도 많아집니다.

노출도의 내림차순으로 위험 순위를 지정하는 방법과 함께, 프로젝트에 미치는 영향의 등급(위험 등급)에 따라 위험을 카테고리로 그룹화하거나 클러스터링하는 방법도 유용합니다. 대부분, 다음 다섯 개의 카테고리로 구분됩니다.

  1. 높음
  2. 중요함
  3. 중간
  4. 중요하지 않음
  5. 낮음

위험을 문서화하여 프로젝트 팀 구성원이 회람하도록 하십시오.

위험 회피 전략 식별페이지 맨 위

목적 프로젝트를 재구성하여 위험을 제거함 

경우에 따라 위험을 완전히 피할 수도 있습니다. 위험은 흔히 시스템의 유효 범위가 잘못되어 발생할 수 있습니다. 시스템의 유효 범위를 좁히면(비본질적인 요구사항을 제거하여), 위험 목록의 섹션을 현저히 줄일 수 있습니다. 이러한 위험은 작업을 수행하는 데 필요한 자원(시간 포함)이 충분하지 못하여 발생하는 것이 아닙니다.

또는 특정 기능을 설정하는 데 따르는 위험을 감소시키는 기술을 사용할 수 있습니다. 즉, 하나의 위험 세트(기술 구축에 따르는 위험)를 다른 위험 세트(제어 영역 외부의 힘에 의존하여 발생하는 위험)와 바꾸어 위험을 피하는 방법입니다.

결국 위험은 다른 조직으로 전가될 수 있습니다.

위험 완화 전략 식별 페이지 맨 위

Purpose 위험을 완화시키는(위험의 영향을 줄이는) 계획 개발 

직접적인 위험 즉, 프로젝트가 어느 정도 제어할 수 있는 위험의 경우 위험의 발생 가능성을 줄이거나 프로젝트에 미치는 영향을 줄이는 데 필요한 조치를 식별하십시오(완화 전략). 일반적으로 위험 자체는 정보가 부족하여 발생하므로 완화 전략은 불확실성을 줄이는 방법 연구에 중점을 둡니다.

일부 위험은 약간의 조치를 취하여 구체화하거나 제거할 수 있습니다. 가능한 초기에 위험을 완화시킬 수 있도록 반복 개발 프로세스에서 해당 조치를 초기 반복에 할당하십시오. 위험은 되도록 초기에 처리하도록 하십시오. 위험의 양식이 "X가 작동하지 않을 수도 있습니까?" 인 경우에는 가능한 빨리 X를 수행하도록 하십시오.

예:

  • X 및 Y 제품이 통합되지 못하는 위험을 줄이려면 프로토타입은 통합의 장해를 조사하도록 설정됩니다. 해당 기능(목록에 열거함)을 테스트하여 통합에 성공했는지 확인합니다.
  • A 데이터베이스가 적절히 수행되지 못하는 위험을 줄이려면 대상 어플리케이션의 워크로드를 모델링하는 테스트 도구를 사용하여 벤치마크합니다.
  • Z 테스트 툴이 어플리케이션의 회귀 테스트를 효율적으로 수행하지 못하는 위험을 줄이려면 다음 반복 중에 Z 테스트 툴을 획득하여 사용합니다.

이런 조치는 특정 위험의 발생 가능성을 0에 가깝게 줄이는 것을 목표로 해야 합니다. 위험이 확인된 경우에는 비상 계획을 세워 해당 위험에 대처합니다(비상 전략 식별 참조).

비상 전략 식별 페이지 맨 위

목적 대체 계획 개발 

각각의 위험을 적극적으로 완화하는 계획의 개발 여부에 관계없이 위험이 구체화되는 경우 즉, 문제점이 발생하는 경우(보험 용어로 "멸실"의 경우) 취하게 될 조치를 결정해야 합니다. 일반적으로 이를 "'B' 계획" 또는 비상 계획이라고 합니다. 비상 계획은 위험 회피 및 전가에 실패하고 위험 완화에도 성공하지 못하여 위험을 바로 처리해야 하는 경우에 필요합니다. 이는 간접적인 위험(프로젝트가 제어할 수 없는 위험)이나 완화 전략을 실현하는 데 많은 비용이 드는 경우 자주 사용됩니다.

비상 계획 시 다음을 고려해야 합니다.

    위험 

    지수 

    조치 

    어떤 위험입니까?  위험이 발생한 것을 어떻게 알 수 있습니까? '멸실'을 어떻게 발견했습니까?  '멸실'을 처리하는 데 필요한 조치는 무엇입니까?(어떻게 "출혈"을 멈출 수 있습니까?) 

위험 지수 식별

일부 위험은 프로젝트 메트릭을 통해 모니터하여 경향과 임계값을 살펴볼 수 있습니다. 예를 들어, 다음과 같습니다.

  • 재작업이 너무 많음
  • 파손이 너무 많음
  • 실제 지출이 계획을 크게 초과함

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

  • 응답 시간이 요구사항보다 한 등급 높음.

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

  • 제3자가 소프트웨어 컴포넌트를 적시에 제공하지 않음.

기타 여러 가지 "소프터(softer)" 지수가 있습니다. 이들 지수는 문제점을 완전하게 진단하지는 못합니다. 예를 들어, 사기를 저하시키는 위험은 항상 있습니다(일반적으로 프로젝트의 특정 시점에서 거의 예측이 가능한 위험입니다). 불평, "빈정댐", 최종 기한 비준수, 품질 불량 등 많은 지수가 있습니다. 이러한 "측정 기준"이 문제점을 파악하는 분명한 지수가 되지는 못합니다. 특정 전달물을 두고 농담을 하는 것이 작업으로 인한 스테레스를 줄이는 방법은 될 수 있으나 이러한 행위가 지속되면 팀의 조직력에 영향을 줄 수 있습니다.

불만을 지나쳐 버리지 말고 모든 지수를 주의 깊게 살펴 보십시오. 불만을 퍼뜨리는 직원을 태도가 불량한 개인으로 낙인찍는 것은 쉬운 일이나 냉소적인 태도 이면에는 진실 이상의 것이 숨어 있을 수 있습니다. 흔히 '불만분자'들은 '프로젝트의 양심' 역할을 합니다. 대부분의 개인들은 프로젝트가 성공하기를 원하며 프로젝트가 잘못된 방향으로 추진될 때 실망합니다.

"손실" 조치 또는 "B 계획"을 식별하십시오.

단순한 경우에는 비상 계획에서 대체 솔루션을 열거합니다. 일반적으로 나타나는 영향은 현재 솔루션을 파기하고 새 솔루션을 구현하는 데 드는 비용과 시간의 지연입니다.

기타 "소프터" 위험은 손실이 발생한 경우 여러 가지 조치를 취합니다. 예를 들어, 사기가 저하되었을 때는 상황을 인정하고 그룹으로 모여서 프로젝트에 대해 팽배해진 태도를 논의하는 것이 최선입니다. 관심사를 듣고 문제를 찾기 위해 개인들이 의견을 분출하도록 하십시오. 충분히 의견을 나누었으면 문제의 원인을 처리하기 위해 논의하십시오. 논의에 집중하려면 위험 목록을 사용하십시오. 주된 위험을 조직적으로 처리하려면 위험의 우선순위를 다시 지정하고 반복 계획을 다시 구성하여 구체적인 조치 계획을 수립하십시오. 적극적인 조치는 긍정적이나 무의미한 한 마디 말보다 더 효과적입니다.

손실은 분명히 부정적인 영향을 미치지만 긍정적인 면도 있습니다. 조치 실행의 추진력이 되는 것입니다. 겉으로 보이는 안정에 만족하여 위험을 무시하고 뒤로 미루기 쉽습니다. 멸실이 발생하면 조치가 필요합니다. 이렇게 되면 위험은 더 이상 추상적이거나 불확실한 것이 아닙니다.

멸실도 위험을 피하거나 완화하지 못하여 발생합니다. 위험 목록을 재검토하여 프로젝트 팀에게 조직적인 맹점이 없는지 판별해야 합니다. 솔직한 자체 평가가 어려운 만큼 이를 통해 추후 다른 문제점을 막을 수 있습니다.

반복 중 위험 다시 수행 페이지 맨 위

목적 프로젝트 전체에서 위험 목록이 현재 상태를 반영하는지 확인 

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

  • 매주 목록을 다시 수행하여 변경사항을 확인하십시오.
  • 상위 10개 항목을 전체 프로젝트에서 볼 수 있게 하고 해당 항목에 대한 조치를 강조하십시오. 상태 평가 보고서에 현재 위험 목록을 첨부할 수도 있습니다.

반복 종료 시 위험 다시 수행 페이지 맨 위

목적 프로젝트 전체에서 위험 목록이 현재 상태를 반영하는지 확인 

반복 종료 시 위험 목록에 비추어 반복의 목표에 다시 한번 확인하십시오. 특히, 다음을 수행하십시오.

  • 완전하게 완화된 위험은 제거하십시오.
  • 최근 발견된 새로운 위험을 추가하십시오.
  • 등급을 다시 평가하고 위험 목록을 재정렬하십시오(위험 분석 및 우선순위 지정 참조).

개념화 및 구현화 단계 중에 위험 목록이 늘어나더라도 개념치 마십시오. 프로젝트 구성원으로서 작업을 수행하면서 사소하게 여겼던 사항이 실제로는 위험을 내포하고 있었다는 것을 알게 됩니다. 통합을 수행하면서 숨겨진 어려움을 발견할 수도 있습니다. 그러나 프로젝트의 구현화 및 구성 단계에 도달할수록 위험은 점차 줄어 듭니다. 그렇지 않은 경우는 위험을 적절하게 처리할 수 없거나 시스템이 너무 복잡하여 체계적이고 예측 가능한 구축이 불가능하기 때문입니다. 자세한 정보는 가이드라인: 위험 목록을 참조하십시오.



Rational Unified Process   2003.06.15