태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

좋은 PM은 훌륭한 리스크 관리자

2009/03/02 23:42 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

프로젝트에서 가장 중요한 활동 중에 하나가 리스크 관리입니다. 프로젝트 실패의 원인의 대부분이 리스크 관리를 하지 않거나 하더라도 부실하게 하는 데 있습니다. 성공하는 프로젝트관리자는 우수한 리스크 관리자입니다.

 

성공하는 프로젝트는 대부분 성공 가능한 범위 및 일정을 가지고 리스크를 잘 관리한 프로젝트입니다. 반면, 성공 가능한 범위 및 일정을 가지고 시작한 프로젝트라도 리스크 관리에 거의 신경을 쓰지 않으면 예상치 못한 돌발 변수에 프로젝트는 실패하기 쉽습니다.

프로젝트 리스크 관리를 하다 보면 소프트웨어 프로젝트는 정말 가시밭길을 걷고 있다는 생각이 듭니다. 웬만한 크기의 프로젝트에서 리스크 수십 개를 찾아내기란 그리 어렵지 않기 때문입니다. 하지만 미리 발견되고 관리되는 리스크들은 그 위험을 현저히 낮출 수 있고, 다른 대처 방법들을 얼마든지 찾을 수 있습니다.

 

 프로젝트에서 리스크 관리는 다음과 같은 절차로 진행됩니다.

 

1. 리스크관리 책임자 임명 - 대부분의 중소규모의 프로젝트는 프로젝트관리자가 리스크관리자도 겸하지만 프로젝트가 대단히 크거나 특수한 경우 리스크관리자를 별도로 임명합니다.

 

2. 리스크 인지 - 리스크는 프로젝트에 관련된 모든 사람이 찾아내야 합니다. 추후 인지하지 못한 리스크 때문에 프로젝트가 지현되거나 실패하면, 리스크 인지가 소흘했기 때문입니다. 리스크 인지는 프로젝트 초기에 한번만 하는 것이 아니고, 프로젝트가 끝날 때까지 꾸준히 찾아야 합니다. 리스크관리자는 사소하게 흘려버리는 걱정거리들을 정리하고 계수화해서 리스크 관리 항목으로 끌어들여야 합니다.

 

3. 리스크 분석 - 인지된 리스크는 분석하여 분류를 해야 합니다. 그리고 발생가능성(P)과 파급효과(I)로 나누어서 분석하여 수치화를 해야 합니다. 각각은 1~5까지의 수치로 정량화를 할 수 있는데, 이때 주관적인 판단이 필요합니다. 발생가능성이 몇%가 될지를 정확하게 예측한다는 것이 거의 불가능하기 때문입니다. 그에 비하여 파급효과는 예측이 좀더 쉽습니다. 그 일이 일어났을 때 발생할 수 있는 피해를 일정이나 금액으로 환산해서 예측할 수 있습니다.

 

4. 리스크 우선순위화 - 프로젝트에서 관리하는 리스크는 대단히 많은 수가 됩니다. 이를 모두 동일하게 관리하기란 쉽지 않고 비효율적입니다. 따라서 우선순위가 높은 리스크를 집중적으로 관리하는 것이 좋습니다.


아래 노출도 계산 공식을 엑셀의 수식으로 변화하면 입력하면 자동으로 해당 리스크의 노출도가 계산이 됩니다.

노출도(E, Exposure) = (P/5-0.1)*0.05*(2^(I-1))

P = 발생가능성(Probability)

I = 파급효과(Impact)


낮은 노출도: 0.05 미만

중간 노출도: 0.05 이상 0.15 미만

높은 노출도: 0.15 이상


5. 리스크 대처 계획 - 리스크가 문제가 되지 않도록 미리 대처를 하거나 리스크가 발생해도 되도록 대비를 하는 것입니다. 예를 들어 개발자가 퇴사할 징후가 보일 때 다음과 같은 대응책을 마련할 수 있다.

  • 개발자가 퇴사하지 않도록 노력한다.
  • 개발자가 퇴사하더라도 보충할 개발자를 미리 사내에서 물색해 놓는다.
  • 사내에서 보충한 개발자를 찾지 못하면, 외부 채용 활동의 준비 단계를 해 놓는다. 즉, 채용 공지를 하고, 이력서를 분석하여 채용자 후보를 미리 물색해 놓는다.
  • 해당 개발자의 모듈을 다른 개발자와 많은 부분 공유하도록 계획 한다.
  • 아예 해당 개발자를 프로젝트에서 제외하고 진행한다.


6. 리스크 감시 - 프로젝트가 진행되면서 리스크는 계속 변합니다. 따라서 리스크를 지속적으로 감시해야 합니다. 리스크의 모든 기록은 리스크관리대장을 만들어서 기록해야 합니다. 리스크관리대장에는 다음과 같은 것들이 적힙니다.

  • 리스크 제목
  • 리스크 내용
  • 리스크 분류
  • 리스크 발생 가능성
  • 리스크 파급 효과
  • 리스크 관리계획
  • 리스크 발생 시 대처 계획
  • 리스크 대처 기록
  • 리스크 재평가 기록

리스크를 주기적으로 재평가하고 우선순위를 재정렬하고, 리스크 대처 계획을 갱신해야 합니다. 이와 더불어 새로운 리스크를 인지하기 위해서 지속적인 리스크 감시를 해야 합니다. 리스크관리대장에 내용이 꾸준히 쌓이면, 프로젝트가 끝난 후에도 다른 프로젝트에서 참조할 수 있습니다. 이 때 놓치기 쉬운 리스크를 쉽게 찾아낼 수도 있고, 리스크에 어떻게 대처해서 문제를 해결했는지도 도움을 얻을 수 있습니다.

 


저작자 표시 비영리 변경 금지

'프로젝트 > 리스크관리' 카테고리의 다른 글

좋은 PM은 훌륭한 리스크 관리자  (6) 2009/03/02
Expect Unexpected  (0) 2008/11/14

전규현 프로젝트/리스크관리

Trackback Address: http://allofsoftware.net/trackback/92 관련글 쓰기
  1. Blog Icon
    [1002]

    위의 노출도 계산 식에서 P 와 I 는 어떻게 계산하는지요?

  2. P와 I를 구하는 기법은 다양하게 많이 있지만, 결국은 스스로 판단하에 결정하게 됩니다. 본문에 좀더 부가해서 설명했습니다.

  3. Blog Icon
    skeom

    진지한 고민이 묻어 나는 글이네요... RSS 등록해놓고 들려야겠습니다. 감사합니다.

  4. skeom님 반갑습니다.
    좋은 글로 계속 만나고 싶습니다. 의견 있으면 언제든지 알려주세요. 감사합니다.

  5. Blog Icon

    비밀댓글입니다

  6. 감사합니다. ^^

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..

우리 식대로
우리 식대로 2011/10/30

"우리 식대로" 마치 북한에서 하는 얘기 같지만, "우리 식대로"를 주장하는 소프트웨어 회사는 의외로 많다. 체계가 하나도 없이 완전 주먹구구 방식의 소프트웨어 회사가 있는가 하면 "우리 식대로"를 주장하여 정말 많은 일을..

문서는 얼마나 적어야 할지?

소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다. 다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다." 물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된..