프로젝트 매니저가 뛰어난 사람인지 아닌지를 알아볼 수 있는 방법에는 여러가지가 있을 것이다.
그중 하나가, 이 양반이 위험관리를 하는 사람인가를 살펴보는 것이다.
위험관리를 하고 있다면, PM내공이 상당함을 인정해도 된다고 본다.
위험관리가 무엇이고 왜 중요하고 하는 것은 회사생활 5년차 넘으면 알긴 알 것이다.
근데 정말 알까?
최근, 부장/차장 급들이 신경써서 만들었다는 RR모델(
Risk/Return Model)을 보고 사람들이 위험에 대한 개념이 없는 경우가 제법 있다고 느꼈다. (지금 나는 이 바닥에서 20년 이상 묵은 사람들이 위험의 정의를 잘못내리고 있다는 건방진 말을 하고 있는 것이다.)
이에 대한 자세한 내용은 다음 포스트(
http://yjhyjh.egloos.com/279741)에서 다루기로 하고, 먼저 실전에서 사용해야 하는 위험관리에 대해 쭉 한번 살펴보겠다.
(일부는 PMBOK의 내용보다 깊이가 있을 수도 있으므로, 다소 난해한 설명이 되더라도 너그러이 이해를 바라면서...)
< 위험의 정의 >먼저
위험(Risk, 리스크)의 정의는 다음과 같다.
- 원치 않는 결과를 초래하게 될 발생 가능한 미래의 사건
이쯤에서 위험(Risk)와 이슈(Issue)의 차이점을 먼저 짚어보자.
이 둘의 정의를 정리하면 Figure 1과 같다.
< Figure 1 >
요컨대, Risk는 아직 발생하지 않은 확률적 사건이고, Issue는 발생해서 프로젝트의 발목을 잡고 있는 문제점이다.
결국, Risk가 발현하면 Issue가 된다고도 할 수 있다.
이것이 리스크관리와 이슈관리를 종종 혼동하는 이유이기도 하다.
< 위험관리의 정의 >이러한 리스크(Risk)는 관리되어야 한다.
위험관리 또는 리스크관리에 대한 정의는 다음과 같다.
- Risk가 추상적인 상태에서, 문제로 되기 전(이슈화 되기 전)에 대응책을 생각해 내는 과정이다.
- A disciplined and systematic method of managing risk is necessary and feasible to control the quality, cost, and schedule of software products [CMU/SEI]
< 위험 발생 통제 : Trigger >위험관리의 핵심은 아직 발생하지 않은 (확률적으로 발생 가능한) 위험을 어떻게 관리할 것이나의 것이다.
우리는 이를 위해 발생하기 전에 발생을 예고하는 조짐을 관찰하고 통제해야 한다.
위험이 발현될 것임을 알려주는 신호를 Risk 전이 경계지표(Trigger)라고 한다.
즉,
Trigger는 Risk가 현실화되는 촉발점이다.
우리는 Risk 각각에 대해 한 개 이상의 Trigger를 설정하고, 항상 감시해야 한다.
구르는 공은 뛰어오는 아이보다 앞서 나타난다라는 격언을 떠올려보면, 무슨 말인지 쉽게 이해갈 것이다.
< 위험관리가 필요한 이유 >프로젝트는 다음과 같은 특징을 가진다.
- 프로젝트에서 만드는 산출물 중에 변하지 않는 산출물은 없다.
- 프로젝트에서 존재하는 불확실성은 제거할 수 없다.
- 변경을 통제하는 것보다, 변경의 종류/규모/빈도를 예측하는 것이 더 효과적이다.
- 동일한 프로젝트는 없다.
- 정확한 일정계획 및 비용계획을 수립할 수 없다.
- 대부분의 프로젝트는 일정/원가/품질을 모두 만족시키기 어려운 조건으로 진행된다.
불확실성이 있는 곳에는 언제나 Risk가 있다.
이러한 Risk에 대해 “모르겠다”라는 대답을 하는 것보다는, 불확실성 정도를 이해하는 것이 문제에 대응할 수 있는 실마리를 제공한다.
프로젝트는 항상 불확실성에 시달리므로 위험관리가 꼭 필요하다.
위에 언급한 위험관리가 필요한 이유를 도식화 하면 Figure 2와 같다.
< 위험관리 프로세스 >
PMBOK에서 제안하는 위험관리 표준 프로세스를 조금 수정하여 내가 사용하고 있는 프로세스는 Figure 3과 같다.
- Risk Management Planning (위험 관리 계획 수립)
- Risk Identification (위험 인지/확인)
- Risk Analysis (위험 분석)
- Risk Response Planning (위험 완화전략 수립)
- Risk Monitoring & Control (위험 모니터링)
< 위험 정량분석 >위험은 불확실성으로 인한 잠재적 문제점이다.
그러므로 위험은 확률모델로 정량화되게 된다.
기본적인 위험 분석에 사용될 수 있는 툴은
Risk Rating Matrix Analysis 이다.
이것은 마치 정량화 분석처럼 보이지만, 사실은 이를 흉내낸 정성적 분석이다. 물론, 이것은 정량화의 시작점이 되기 때문에 의미가 있다.
Risk Rating Matrix Analysis에서는 Figure 4와 같은 방식으로 발생가능성과 영향력을 평가해서 각 Risk의 우선순위를 결정한다.
< Figure 4 >
Risk Rating Matrix Analysis를 통해 위험의 발현으로 인한 영향력을 예상할 수 있으며, 각 위험의 우선순위를 파악할 수 있다.
하지만,
진정한 위험관리의 꽃은 리스크 다이어그램(Risk Diagram)이다.
리스크 다이어그램은
특정항목에 대해 불확실성을 확률기반 다이어그램으로 나타낸 것이다.
이것은 특정항목의 목표달성이 정확히 얼마나 불확실 할까를 통계적으로 파악하여 위험을 가늠하는 것이다.
Figure 5와 같은 모양으로 나타나는 리스크 다이어그램의 특징은 다음과 같다.
- 모든 확률의 합이 1이 되도록 수직축 값의 크기를 결정한다.
- 정규분포에서 고성과쪽으로 군집하는 모양을 보인다.
- Continuous Probability Distributions
< Figure 5 >
Figure 5는 일정에 대한 리스크 다이어그램이다.
이에 대한 해석을 짧게 정리하면 아래와 같다.
- 그래프의 X축은 날짜를 나타내며, 그래프의 면적은 해당날짜에 완료할 수 있을 확률이다.
- 여기서 극소-확률 일자(Nano-Percent Date)는 곡선과 수평축이 만나는 지점의 확률이 0이 아닌 첫번째 날짜로써, 해당 날짜에 완료가능성이 발생하기 시작하는 지점이다. N지점에서는 아직 완료할 수 있을 가능성이 0%이다.
- N지점 보다 나중 일자가 되면 조금씩 완료가능성이 높아진다. 점선으로 표시된 지점의 날짜에 프로젝트가 완료될 확률은 약 30%쯤 된다.
- X축과 맞닿는 지점 이후로 완료일자를 잡으면, 과제가 제때 끝날 가능성은 100%에 육박한다. (물론, 이렇게 너그러운 완료일정을 주는 프로젝트는 전혀 없을 것이다.)
- 모든 일정 리스크는 다음과 같은 원인에 기인한다. : 실제 완료 일정 < 목표 일정 < N
현실에서 대부분의 프로젝트는 N을 완료일자로 잡아서 일정준수에 실패한다.
이와 같은 리스크 다이어그램은 어떻게 그리는 것일까?
바로 몬테카를로 시뮬레이션을 이용해서 그린다. (이전포스트 "몬테카를로 시뮬레이션 (Monte-Carlo Simulation)" 참조)
리스크 다이어그램의 불확정구간의 크기는 조직의 개발 프로세스에 얼마나 많은 노이즈(noise)가 포함되는지에 따라 결정되는 것이다. (Worse case penalty, Most likely case penalty, Best case penalty로 산정하는 것도 한 방법이다.)
프로세스 노이즈는 과거의 Risk가 프로젝트에 미친 영향에 대한 정량화를 통해 나오는 결과다. 즉, 과거의 성과가 불확정구간의 크기를 결정하는 것이다.
리스크 다이어그램의 분석법 및 응용에 대해서는 더 많은 내용이 있다.
이것은 톰 디마르코와 티모시 리스터의 '소프트웨어 프로젝트에서의 리스크 관리'를 읽어서 습득할 것을 권한다.
어제의 문제는 오늘의 Risk이다.
프로젝트의 문제는 반복해서 발생하는 경향이 있어서, 대여섯 개의 프로젝트만 분석해보면 어느정도 충분한 데이터를 얻을 수 있다. 우리는 지속적으로 축적된 프로젝트 Lessons Learned와 위험관리 노하우의 갱신을 통해서 Risk관리 수준을 높일 수 있다.
< 결언 >
위험은 불확실성으로 인한 잠재적 문제점이라는 점을 명심해야 한다.
그러므로, 위험을 말할때는 반드시 확률을 떠올릴 수 있어야한다.
그리고, 위험관리를 말할 때는 항상 리스크 다이어그램을 떠올려야 한다.
많은 사람들이 이슈(issue), 제약(constraint)과 위험(Risk)를 혼동하여, 위험관리를 제대로 못하곤 한다.
아직가지 위험관리를 한다고 말하면서 확률모델을 다루지 않았다면, 그대는 엉뚱한 것을 하느라고 위험관리를 못했다고 보면 된다. (무엇인가는 했을 것일테니까... 늘 그렇듯이...)
심지어 PMP 획득을 위해, 열심히 공부하는 PMBOK에서도 위험을 확률모델로 이해하려는 시도는 약한 것 같다.
위험관리에 대해서는 PMBOK만 보는 것으로는 부족하다. 좀 더 많은 위험관리 전문가의 서적을 읽어볼 것을 권한다.
프로젝트 관리에서 위험관리는 프로젝트의 불확실성 요소를 통제하려고 하는 확률모델적 접근임을 이 글을 읽는 독자라도 꼭 이해해 줬으면 한다.
<연관 포스트 소개>
다음 포스트에서는 Risk/Return Model (일명 R-R Chart)를 언급하면서 우리회사의 관리자들이 위험을 어떻게 잘못 이해하고 적용했는가를 설명하겠다.
또 다른 포스트에서는 크리티컬 패스(Criticla Path)와 위험관리(Risk Management)의 연관성을 설명한다.
