위험관리 표준

개요

목적

프로젝트 수행시 발생되는 사항을 지속적으로 관리해 위험을 최소화하고, 문제를 사전에 예방하여 정해진 납기 및 비용 하에서 프로젝트의 종료를 지원하도록 한다.

전제조건

• 본 문서는 QM SI사업부문 ver 7.4를 기준으로 작성
• 위험관리는 프로젝트관리와 연계되어 관리됨
• 프로젝트관리 수행시 프로젝트 보유 시스템으로 본 프로젝트에서 사용하는 자원은 다음과 같음
• 열린마당 - VSD - 위험관리 등록

위험관리 프로세스

위험관리 프로세스는 다음 방침을 준수해야 한다..

1. 프로젝트의 위험에 대해 프로젝트 관리자가 통제한다.
2. 프로젝트 관계자는 위험이 발생시 즉각적으로 프로젝트 관리자에게 보고한다. 각 업무 PL들은 주기적으로 위험사항에 대해 프로젝트 관리자에게 보고한다.
3. 위험사항은 문서화하여 위험사항을 추적관리 할 수 있도록 한다.
4. 위험관리는 프로젝트 전공정을 통해 이루어진다.

5. 수행 프로세스는 다음과 같다.

   프로세스명	단위 프로세스명	산출물
   위험관리	위험관리	이슈목록, 위험보고목록, 위험보고서, 회의록

    

   개요

   구분	내용
   목적	본 프로젝트의 수행시 발생되는 사항을 지속적으로 관리하여 위험을 최소화하고, 문제를 사전에 예방하여 정해진 납기 및 비용 하에서 프로젝트의 종료를 지원하도록 한다.
   측정지표	위험제거율
   검증방법	QAO심사
   책임역활	● PM : 위험사항 모니터링, 위험 해결을 위한 대안 협의 ○ 영업대표 : 위험사항이 프로젝트에 미치는 영향이 클 때, 수용여부를 결정 ○ 개발자 : 위험사항 발생시 관리자에 보고 ○ QAO : 위험사항에 대한 절차 준수 확인 ○ PL : 각 업무별 위험사항에 대한 발생 모니터링, 위험사항 발생시 관리자에게 보고
   착수기준	위험사항 발생
   완료기준	위험사항 종결

    

   주요절차

   수행절차	입력물	산출물
   1. 위험사항 정의 1.1 위험사항 후보 발견

• 고객과 회의/인터뷰 등 커뮤니케이션 혹은 산출물 검토 및 공동작업 수행 시(외부) 발견 
• 팀내 문제 가능성 파악시 혹은 이미 문제가 되었을 때 발견 
  
  1.2 위험사항 평가 및 확정 
• 이슈 가능성 있는 항목에 대해 제기자가 제목, 발생일자, 상세 내용 등을 PL에게 설명하고 관련자들이 초기평가 실시하여 위험 선정(업무 내) 
• 각 업무별 취합한 위험사항은 PM과 같이 주간보고를 통해 협의 후 확정. 급한 경우 긴급히PM에게 보고, 확정할 수 있음. 
  
  1.3 위험사항 등록 
• 확정된 위험사항은 담당자 및 위험번호를 할당 
  
  => 위험보고목록 및 위험보고서 

• 등록 후 팀원에게 공지|회의록|이슈목록 
  
  
  
  위험보고목록 
  위험 보고서|

  2. 위험사항 관리 2.1 위험사항 방안 수립

• 위험에 대한 파급효과 
• 위험에 대한 해결담당자 및 일정을 공지 
• 위험에 대한 대안 및 처리내역 
  
  2.2 위험사항 지속관리 

• 해결될 때까지 위험보고서로 계속 사후관리 =>변동사항 발생시마다 주간보고를 통해 계속적인 보고/제출|위험보고목록 
  위험보고서|위험보고목록 
  위험보고서|

  3. 위험사항 종결 3.1 위험사항 해결

• 해결이 완료되었으면 담당자는PM에게 승인획득을 받고 위험관리목록, 위험보고서를 최종정리 
• PM은 프로젝트 수행팀 전원 (혹은 PL)에게 최종결과 공지|위험보고목록 
  위험보고서|위험보고목록 
  위험보고서| 
  

  수행 가이드

  
  1. 위험관리 프로세스 정의
  '위험'이란 『프로젝트의 성공에 부정적인 영향을 미치는 불확실한 사건』으로 정의 할 수 
  있다. 프로젝트 상황에 따라 식별/분석과 통제/해결을 중심으로 적합한 위험관리 프로세스
  를 결정하여 정의하도록 한다. 위험관리 계획 수립 시 유의하여야 할 사항은 다음과 같다.

1. 위험관리 활동은 몇몇 사람이 아니라 고객을 포함한 전체 팀원이 참여하여야 한다.
2. 위험식별은 착수 시 뿐만 아니라 프로젝트 전체 진행단계에 걸쳐 이루어져야 한다.
3. 위험에 대한 우선순위 결정 및 진행경과를 모니터링 하기 위해서는 위험의 수준을 계량적으로 평가하여야 한다.
4. 위험은 프로젝트 상황에 따라 변하는 것이기 때문에 지속적인 모니터링을 수행하여야 한다.
5. 각종 프로젝트 성과 분석데이터는 위험식별을 위한 참고자료로 활용 할 수 있다.

위험관리의 주요 프로세스의 내용은 다음과 같다.

5.2 위험식별 및 분석

1. 위험식별 기준

• 위험원인에서 식별하는 방법

가장 일반적인 방법으로 인원의 스킬, 요구사항 명확성, 아키텍처 적합성 등의 위험원인을 체크리스트화 하여 식별하는 방법이 있다.

• 위험징후에서 식별하는 방법

주로 프로젝트 분위기에서 식별하는 방법으로 비생산적인 회의의 지속 팀원사기의 저하, 고객과의갈등의 증가 등의 이상징후에서 문제가 무엇인가를 식별하는 방법이다.

• 프로젝트 진척결과로부터 식별하는 방법

주로 프로젝트 진척결과의 계획대비 실적을 비교 분석하여 차이가 나는 경우 그 원인이 무엇일까를 분석하는 방법이다.
2) 위험식별 방법

• 인터뷰에 의한 방법
• 설문조사에 의한 방법

3) 식별된 위험요소를 기술할 때 유의할 사항은 다음과 같다.

• 원인 (6하 원칙과 같은 객관적인 사실)과 예상결과로 나누어 기술하는 것이 바람직하다.
• 복합적인 위험은 개별위험으로 나누어 기술하도록 한다.
• 가급적 위험요소별로 유니크한 ID를 부여하여 관리하도록 한다.

1. 위험분석

위험의 분석은 위험에 대한 우선순위를 부여하기 위하여 수행한다. 위험의 우선순위 결정은 제한된 프로젝트의 자원으로 우선적으로 대응하여야 할 위험을 선정하는 작업이다.
우선적으로 대응하여야 할 위험이란 위험이 실제 문제로 발생할 가능성이 높고, 발생하였을 때 프로젝트에 미치는 영향력이 큰 것을 의미한다. 
5.3 위험 대응계획 수립
위험 대응계획은 식별된 위험에 대한 조치계획을 수립하는 활동으로 크게 나누어 다음의 5가지 접근방법으로 정리할 수 있다. 

1. Accept : 위험예방을 위하여 별다른 대응계획을 수립하지 않는 것을 의미한다. 실제로 모든 위험에 대하여 대응하여 예방활동을 하는 것은 거의 불가능할 뿐만 아니라 바람직하지도 않다. 예를 들어 메인 프로세스가 아니 부분에 대하여 고객요구사항 증가가 예상되나 그 규모가 작다고 판단되는 경우엔 요구사항 증가예상이라는 위험항목에 대하여 별동의 조치를 취하지 않을 수 있다.
2. Avoid : 위험이 문제로 발생하는 경우 프로젝트에서 감당하기 힘들어 문제로 발생할 가능성을 원천적으로 봉쇄하는 방법이다. 주로 계획을 변경하는 방법으로 이루어진다.
3. Watch : 위험을 수용하기는 힘들지만 위험이 명확하게 파악되지 않아 시간을 가지고 추이를 지켜보는 것을 의미한다. 예를 들어 고객사 전산실 조직의 변경이 예상되나 그 방향이나 구체적인 변경내용이 확정된 않는 경우에는 구체적인 대응방향을 수립하기 힘들 것이다.
4. Mitigate : 식별된 위험에 대하여 조치를 취하지 않으면 프로젝트의 진행에 지장이 있어 조치계획을 수립하는 것을 의미하며 간단한 실행항목의 계획 혹은 상세한 일정 계획의 수립한다.
5. Transfer : 위험예방에 대한 책임을 프로젝트 외부의 조직으로 넘기는 것을 의미한다.

아웃소싱이 대표적인 예가 된다. 한가지 유의할 것은 예방에 대한 책임을 넘기는 것이
위험 자체를 프로젝트 외부조직으로 넘기는 것은 아니라는 것이다. 
식별된 위험에 대한 접근방법을 위의 5가지 중에 결정한 뒤 책임자 및 구체적 대응계획을 정의하여야 한다.