Risk 관리 기법

IT 프로젝트 진행시 Risk에 대해서 사전에 관리하기 위한 기법을 기술합니다.
출처 : the Art of Agile Development by James Shore & Shane Warden
--

회의 전 칠판에 아래와 같은 항목을 적어둡니다.

 

1.     프로젝트 관련해서 밤에 잠이 안오게 만드는 것들이 무엇이냐?

 

2.     프로젝트가 실패로 끝나고 1년 후에 팀장과 면담을 하는 것을 상상해보라. 무엇이 잘못되었고, 언제 잘못되었는가?

 

3.     프로젝트 관련해서 환상적으로 좋은 것을 상상해보고, 반대로 나쁜 것을 적어라.

 

4.     어느 누구도 잘못한 것이 없는데 프로젝트가 어떻게 실패할 수 있는가?

 

5.     영업, 고객, QA, 협력사, 개발자, 팀장, 사장님 포함 경영진, 아니면 당신의 잘못 등에 의해서 어떻게 프로젝트가 실패할 수 있는가?

 

6.     이대로 가면 프로젝트는 성공한듯 한데, 고객이나 영업들 중에 별로 만족하지 않거나, 화를 낼 수 있는 것이 무엇인가?

 

팀원들에게 낙관적인 시각보다는 이 회의에서는 비관적인 시각으로 프로젝트를 보도록 주문합니다.

 

팀원들을 모두 모은 후 색인카드를 나누어 주고, 프로젝트에 대해서 위의 질문에 답이 될 수 있는 "재앙"에 대해서 적도록 합니다.

 

누군가 색인 카드를 적으면 앞으로 밀어 놓고, 진행자가 색인 카드 내용을 곧 바로 큰소리로 읽습니다.

(이를 통해 중복 내용은 사전에 나오지 않게하고, 다른 팀원들로 하여금 더 생각하게 합니다.)

 

색인 카드들이 모이면 해당 "재앙"이 발생할 수 있는 "시나리오"에 대해서 논의하고, 그러한 "시나리오"가 실제 일어나도록 만드는 "근본 원인 (root causes)" 를 파악합니다.

 

예를 들어, online application을 개발하는데, 하나의 재앙이 "서비스 장애의 지속" 입니다.  이러한 재앙으로 이러는 시나리오는 "과도한 접속" 일 수 있습니다. 이것이 근본 원인은 "악의적 공격" 이나 "생각보다 큰 대박성 인기" 일 수 있습니다.

 

Risk가 다 모이면 프로젝트 관련해서 넓게 알고 있는 소수의 핵심 인력만을 두고 다른 팀원들은 돌려 보냅니다.

 

소수의 핵심인력과 함께 발생 가능성 - "높음", "중간", "낮음" 과 발생했을 때 충격 - "비용", "지연 날짜", "프로젝트 취소" 등을 Risk마다 점수를 매깁니다.

 

충격이 낮고, 발생 가능성도 낮은 것은 버립니다. 발생 가능성이 높아도 충격이 낮은 것들도 버릴 수 있습니다.

 

관리 되어야할 Risk들에 대해서는 Risk가 발생했는지를 나타낼 수 있는 지시자 "Indicators"를 정합니다.

 

"지시자"는 주관적인 것 보다는 객관적인 것이 좋습니다. 예를 들어 online application 에서 "생각보다 대박성 인기로 인한 서비스 장애"가 risk이면 "서버 자원 사용률이 80%를 넘을 경우" 처럼 객관적으로 측정될 수 있는  "지시자"를 정하는 것이 좋습니다.

 

그리고 risk가 발생했을 경우 충격을 최소화 시킬 수 있는 지침 "mitigation"을 마련합니다. 이러한 "mitigation"은 risk 발생 전에 업무 계획에 포함 시켜 실행되어야 합니다. 종전의 예에서 "mitigation"으로 "수평적 확장성 확보" 혹은 "부하 balancer구축" 등일 수 있습니다.

 

Risk 대응을 위한 위험 준비금 "contingency" 를 확보해 둘 수 있습니다. 종전의 예에서 "ISP로부터 추가 Bandwidth구매", "Load Balancer 설치" 그리고 "서버의 추가 구매" 등이 됩니다. 이러한 것은 비용이 들므로 실제 risk발생시에 실행됩니다.

 

"Risk Exposure" 은 얼마나 많은 자금과 시간을 risk 대응을 위해서 비축해야하는 지를 반영할 수 있습니다. 이것을 위해서 먼저 risk 발생 가능성을 수치화 하고, 그리고 충격으로 곱해서 숫자를 구합니다. 종전의 예에서 "접속이 많아서 발생하는 장애"의 발생가능성이 35%이고, 충격은 3일의 추가 개발자 투입, $20,000 bandwidth 추가 확보 비용, 설치 비용 이라면 총 "risk exposure"은 하루 개발자 투입과 $7,000이 됩니다.

 

Risk산출 결과 100% 발생 가능성으로 나오는 것은 더 이상 Risk가 아니라 Reality 입니다.  이것은 무조건 바로 처리될 수 있도록 조치되어야 합니다.

 

어떤 Risk는 발생하는 순간 프로젝트 전체를 없애버릴 수 있는 핵폭탄 같은 것도 있습니다. 이것은 Project Manager 권한  밖에 것이니 경영진에게 전달하고 알리도록 합니다. 예를 들어 조직의 재구성으로 팀이 없어지는 것 과 같은 것…

 

이를 경영진에게 설사 조직의 재구성이 되더라도 팀은 유지되고 계속해서 프로젝트가 유지되어야 함을 이야기하여 경영진과 조율이 되어야 합니다.

 

다른 risk들은 indicator들이 계속적으로 monitoring이 될 수 있도록 이러한 부분도 업무 계획에 포함시켜 계속적으로 risk발생 가능성이 체크될 수 있도록 하고, risk 발생 가능성을 낮추거나 impact를 줄일 수 있는 mitigation에 대해서 업무 계획에 포함시켜 시행하도록 합니다.