Skip to content

위험상황을 대비하는 위험관리

2019년 6월 26일에 작성한 포스트입니다.

글의 목적

프로젝트 초기에 위험 식별 활동을 수행하는 것은 중요하다. 위험 식별 활동은 기획서 검토를 통해 장애물을 식별하고 대응 방안을 마련하는 것이다. 그리고 프로젝트 진행 중 발견된 위험을 빠르게 보고해야 하고 의사결정이 필요하다. 의사결정이 빠르게 진행될수록 최소한의 비용으로 위험을 해결할 수 있다.

이러한 위험관리는 프로젝트를 이끄는 리더뿐만 아니라. 프로젝트의 구성원들에게도 중요하다. 위험관리란 무엇이고 어떻게 하는 것인지 정리한 포스트이다.

목차

  • 위험관리란 무엇인가
  • 위험관리를 수행하는 조직이 많지 않은 이유
  • 위험관리는 어떻게 할까

위험관리란 무엇인가

위험이란 아직 결함으로 발생하지는 않았지만, 결함이 될 수 있는 잠재적 가능성을 말한다. 결함이란 사람의 실수가 소프트웨어에 전이된 것으로 동작 여부와 관계없이 요구사항에 부합되지 않는 것을 말한다.

위험관리란 미래에 발생할 문제를 예측하여 미리 대비하는 것이다. 결함을 조기에 발견하기 위한 검출 활동, 발견한 결함을 제거하기 위한 수정 활동, 결함 데이터베이스 구축 및 분석을 통한 예측 활동, 결함이 발생하지 않도록 하는 예방 활동으로 이루어진다.

위험관리를 수행하는 조직이 많지 않은 이유

위험은 문제가 될 수 있음에도 불구하고 위험에 대한 관리를 제대로 수행하는 조직은 많지 않다. 이유는 세 가지가 이유가 있다.

첫 번째 이유는 위험관리에 대한 냉소적인 시각 때문이다. 소극적인 관리자들은 위험이나 문제를 공개해서는 안 된다고 생각하고 고객은 물론 심지어는 팀원들에게도 알리지 않는다. 지금 위험이 있다는 것을 도무지 용인할 수 없다고 생각한다.

두 번째 이유는 위험보다 문제 해결을 우선시하는 현실 때문이다. 위험관리에 소홀하면 지금 당장 발생한 문제만 해결하려고 한다. 소 잃고 외양간 고치는 잘못을 계속 저지르게 된다. 예상치 못한 문제가 생기면 회의가 자주 열리고 결론 없이 끝나는 경우는 우리는 너무 많이 목격했다.

위험과 문제는 같은 속성이 있다. 위험은 향후 발생한 문제이며 문제는 위험이 현실화된 것이다. 본질적인 차이는 없으며 발생 시점의 차이만 있을 뿐이다.

세 번째 이유는 위험관리가 비용과 관련이 있다는 인식을 하지 못하기 때문이다. 평소에는 "잘 되겠지"라는 근거 없는 낙관주의로 일관하여 위험을 내버려두다가 마침내 위험이 현실화되어 최고점에 도달했을 때 급하게 해결하려고 한다. 호미로 충분히 막을 수 있는 것을 굴착기로 못 막는 사태가 발생할 수 있다. 엄청난 비용의 낭비로 초래한다. 위험관리는 경제적 활동이다.

위험관리는 어떻게 할까

위험관리를 위한 중요한 사항 5가지가 있다. 위험관리를 어떻게 해야 하는지 구체적인 방법에 대한 설명이다.

1. 프로젝트 초기에 위험을 도출하라

프로젝트 초기에 위험을 식별해야 한다. 초기에 식별하고 관리할수록 프로젝트는 안전해진다. 그래서 초기에 위험을 식별하면 그 이후에 발생할 문제의 확율이 줄어든다.

2. 유사한 프로젝트 수행사례를 확보하라

프로젝트의 위험은 공통적인 요소가 많다. 프로젝트 차원에서 위험 목록을 관리해야 한다. 관리 목록을 통해 위험 식별에 활용한다. 또한, 발생한 위험과 해결방안을 정리하여 구성원과 공유한다. 즉, 위험 해결 이력을 재사용하여 위험요소를 식별 및 해결하기 쉬워진다.

3. 일정산정에 버퍼를 추가해라

프로젝트 진행 시 발생할 위험을 대비해야 한다. 대비는 일정산정 시 버퍼일정을 확보하는 것이 중요하다. 언제 발생할지 모를 위험을 대비해서 프로젝트 일정 산정시 버퍼를 산정해야 한다.

4. 식별된 위험은 계속 추적하라

발견된 위험은 계속 추적해야 한다. 위험에 관련된 담당자와 해결 목표 일을 지정해야 한다. 그리고 주간회의 등을 통해서 정기적으로 위험 상태와 해결 방안을 감시해야 한다.

5. 위험 신속하게 공개하라

식별한 위험은 이해관계자에게 공개돼야 한다. 이해관계자와 함께 고민하면 쉽게 해결할 수 있다. 만약에 프로젝트 차원에서 발생한 위험은 관리자에게 신속하게 보고돼야 한다. 전달받은 위험을 통해 관리자는 상황을 판단하고 배포일정 연기 또는 스펙아웃 결정한다.

참고문헌

  • 오병곤. 『실용주의 소프트웨어 개발』. 로드북, 2017.