위험관리(Risk Management) 프로세스 #1

프로젝트가 실패하는 가장 큰 요인은 바로 발생할 수 있는 문제점들을 드러내서 함께 논의하지 않고
나중에 해결하면 되겠지... 하는 안일한 생각으로 방치하기 때문이지 않을까 합니다.

그래서 이러한 문제점을 체계적으로 관리할 수 있는 위험관리에 대해서 정리해보려고 합니다.

위험관리를 포함한 품질관리와 관련된 규격으로는 TL 9000이 있습니다.
ISO 9000이란 규격은 많이 들어 보셨을 텐데요..

TL 9000은 ISO 9000에 비해 IT 분야에 특화되어 있고, 품질기획/프로젝트계획/구성관리계획등 계획에 초점을 맞추고 있습니다.
Telecommunication Leader 9000의 약어로 QuEST 포럼에서 ISO 9001을 기반으로 1999년 제정했으며,
IT 분야의 특성에 따라 하드웨어/소프트웨어/서비스 분야로 나누어져 있습니다.

그러나 TL 9000 요구사항에는 구체적인 위험관리에 포함하여야 할 프로세스의 종류에 대해서는 언급하고 있지 않기 때문에 여기에서는 소프트웨어 프로젝트에서 주로 수행하고 있는 위험관리 프로세스에 대해서 정리하도록 하겠습니다.

1. 위험의 원인

먼저 프로젝트를 수행할 때, 이런 위험한 상황들이 왜 발생하는지 살펴보도록 하죠..
가장 많은 경우는 고객 요구 사항의 변경이라고 합니다.
실제로 프로젝트를 요청한 고객 중 그 프로젝트를 제대로 이해하고 있는 고객은 드물다고 생각합니다.
그래서 진행 중에 계속적으로 요구를 변경하거나, 아니면 다른 사이트(대형 포털)와 똑같이 해주세요...
하는 요구들이 많죠..

다음으로는 설계 오류가 있습니다. 개발자가 환경변화나 요구분석을 잘못해서 설계 자체가 자주 바뀌는 경우도 있죠.. 이런 경우는 대부분 부적절한 인력 투입 때문에 발생하기도 하는데요..
심한 경우 프로젝트를 수행하면서 다른 프로젝트와 함께 진행한다던지, 그 프로젝트를 수행하는데 필요한 기술이 부족한 개발자들로 구성된 경우, 아무리 뛰어난 프로젝트 관리자라 해도 난감하겠죠.. -.-

마지막으로는 불분명한 책임과 역할 분담이나 잘못된 예측 및 추정이 있을 겁니다.
관리자의 역량이 필요한 부분이기는 한데, 프로젝트의 규모/복잡성/소요비용/일정등을 잘못 계산해서 프로젝트 기간이 한없이 늘어나는 경우가 종종 있기도 합니다.

2. 위험의 식별

그렇다면 이런 위험을 어떻게 알아낼 수 있을까요?
위험을 식별하기 위한 방법들을 각 분야별로 간략하게 정리해 봅니다.

- 프로젝트 사이즈 위험
프로젝트의 규모를 예측하기 위한 방법으로는 LOC(Line of Code), FP(Fuction Point), COCOMO등이 있는데요. 이런 방법은 프로젝트의 M/M를 계산하기 위해서 주로 사용하죠..
위험관리 측면에서는 이런 사이즈와 더불어 프로젝트 결과물의 사용자 수, 요구사항 변경 회수, 소프트웨어의 재사용등도 살펴봐야 한다고 하네요..

- 비즈니스 영향 위험
비즈니스 측면은 기술적인 측면과는 관점에 있어 차이가 있습니다.
회사의 이익과 프로젝트 결과의 효과, 고객의 니즈, 함께 운용할 시스템 수, 인도 지연에 따른 비용, 결함시 처리에 들어가는 비용등을 고려해야 하죠..

- 고객관련 위험
가장 힘든 부분이 아닐까 합니다. 정말 불량한 고객을 만나면 답답하죠.. -.-
결국 해결책은 대화밖에 없는데, 대화로 이끌어 내기 위한 인간적인 교류도 중요하겠죠..
먼저 고객이 원하는 것을 제대로 이해하고 있는지 파악하는게 중요합니다.
그게 안된다면 고객과 의사소통할 수 있는 채널을 만들고, 회의에 적극적으로 참여하도록 해서 요구사항을 명확하게 하는게 필요하다고 합니다.

- 개발 프로세스 위험
프로젝트는 결국 프로세스입니다. 절차에 따라 진행이 되기 때문이죠..
참여자들이 프로세스를 이해하고, 그에 따라 개발을 진행하는 것이 중요합니다.
프로젝트 형상관리를 문서화를 위한 귀찮은 작업으로 생각하지 않고, 정말 개발에 필요한 단계로 이해하는 것이 중요합니다.
프로젝트 결과가 제품만 있다면 이것은 하나의 프로그램(program)에 불과합니다.
메뉴얼을 비롯한 각종 문서화와 프로세스가 합쳐졌을 때 그 제품이 바로 시스템(system)이 되는 겁니다.

그외에도 프로젝트를 수행할 기술을 가지고 있는지 파악하는 기술 위험, 효율적으로 사용할 수 있는 툴들을 이해하고 있는지에 대한 개발환경 위험,  기술진의 규모와 경험관련 위험 등을 통해 위험을 식별할 수 있습니다.

3. 위험 관리 프로세스

그렇다면, 이렇게 식별한 위험을 관리하는 프로세스는 어떻게 정의되어 있을지 살펴보기로 하죠..
위험관리 프로세스는 다음과 같이 두개의 서브 프로세스로 나누어져 있습니다.

- 위험 평가(Risk Assessment) 프로세스 : 프로젝트에 영향을 미칠 것으로 예상되는 위험 요인의 식별(Risk Identification), 식별된 위험의 분석(Risk Analysis), 위험의 우선순위를 결정(Risk Prioritization)

- 위험 관리(Risk Control) 프로세스 :  위험관리 계획 수립(Risk Management Plan), 발생된 위험의 해결(Risk Resolution)과 위험 요소에 대한 지속적인 모니터링(Risk Monitoring)

이를 도식화 하면 다음과 같습니다.

위에 나와있는 프로세스는 매우 중요한 의미를 가집니다.
앞에서도 설명했듯이 위험 요소를 식별하는 것은 가장 중요한 문제이구요..
이어서 이를 분석해서 발생확률이 높고, 중요성도 높은 것을 결정해야 합니다. 이것이 우선순위겠죠..

그러나 실질적인 위험관리는 위험이 발생했을 때, 처리해야 하는 계획을 수립하고 (아마도 비상계획 - Contingency Plan) 실제로 해결을 해야 할 겁니다. 그를 위해서 계속적인 모니터링이 필요한 거구요..

참고로 위험을 식별해서 발생확률이 100%였다면, 이것은 아주 중요한 위험요소일까요?
보통 프로젝트 관리에서는 이런 경우, 위험요소로 관리하기 보다는 프로젝트의 제약조건(Constraint)로 다루는 것이 낫다고 합니다.

이것을 관리루프로 만들면 다음 그림과 같습니다.

한번에 다 정리하려니 너무 많네요.. -.-
다음에 이어서 위험 관리 방법, RMMM, 위험 정량화에 대해서 추가로 정리하도록 하겠습니다.

프로젝트 관리에 대해서 너무 애자일 부분만 정리하는 듯 해서 당분간은 전통적인 방법들을 정리해 보려고 합니다.