▲ 심기보 KAIST 소프트웨어 대학원 겸직교수, PM/PMO 리서치 대표

소프트웨어의 개발 프로젝트에서 리스크 매니지먼트는 성과물의 품질과 납기를 지키기 위해 중요한 역할을 완수한다. 그러나 소프트웨어 개발은 중간 단계에서 납기의 지연이나 비용초과 등을 예측하고 컨트롤하기 어려워 리스크도 예측하기 어렵다. 리스크 대책이 지연되어 납기 지연을 비롯한 치명적인 사태에 빠지는 프로젝트가 끊이지 않는다.

이번 회에서는 정량적으로 리스크를 정의, 반복적으로 멤버 전원에게 철저히 주지시킴으로써 리스크를 최소화하는 방법에 대해 알아보고자 한다.

프로젝트의 리스크를 정기적으로 진단하려면 진단 결과를 ‘리스크 값’으로 정량적으로 나타내는 것이 필요하다. 이 값을 기본으로 프로젝트의 상태를 판단하거나 리스크 대책을 세우게 된다.

리스크에 한정된 이야기는 아니지만 프로젝트 리더는 프로젝트 팀의 문제점을 멤버의 신고에 의해 발견, 인식하는 경우가 많다. 그러나 여기에서는 프로젝트의 리스크 상태를 정기적으로 진단함으로써 리더 스스로가 리스크를 발견하는 방법을 제안한다.

개요 : 수치화하여 생각한다

리스크를 수치화하는 것은 복수의 프로젝트 간에서 리스크의 대소를 비교하여 경향을 분석하는 데에 도움이 된다. 프로젝트 매니지먼트에서의 공통 과제의 발견이나 대책에도 유효다.

공통 과제에의 대책 등을 조직적으로 Knowledge Base(지식 데이터베이스)에 축적해 두면 다음에 수행하는 프로젝트에 활용할 수 있다. 주관적인 요소를 배제하는 것도 수치화 목적의 하나이다.

‘진척은 2주간 늦어지고 있지만 회복할 수 있을 전망’이거나 ‘대책을 검토 중’이라고 한 주관적인 표현에서는 ‘리스크의 조짐’을 파악할 수 없다. 표현에 따라 리스크의 대소에 대한 인식의 차이가 발생하기 때문이다.

주관적인 표현을 원인으로 보고를 받은 상사나 경영자가 사태의 중요성을 인식하지 못하고 방치해 버리는 경우도 있다. 원래 프로젝트 매니지먼트에 기대되는 것은 경영적 관점에서 Accounta bility(설명 책임)를 완수하는 데에 있다. 프로젝트의 투명성을 확보함으로써 코스트 증가나 스케줄의 지연 등을 회피해 소정의 품질을 확보하는 것을 목적으로 한다.

그러나 소프트웨어 개발에서는 진척 상황의 파악이 매우 어렵다는 특징이 있다. 완료 직전이 되어서야 프로젝트가 계획대로 진행되지 않은 것이 밝혀지는 경우도 있다.

불철주야 ‘벼락치기’로 어떻게든 위기적 상황을 감싸 안아 주는 프로젝트가 아직도 끊이지 않는다. 프로젝트 리더나 프로젝트의 구성 멤버로부터 ‘위험의 징조’의 보고에도 불구하고 간과해 버리는 경우가 많다.

진척 측정은 EVMS(Earned Value Management System)등으로 수치화하여 리스크 징조를 읽어낼 수도 있지만 실제로 실천하려면 조직차원의 데이터의 축적이 필요하게 된다.

리스크는 5단계로 추출한다.

리스크 매니지먼트는 5단계로 나눠 실시하는 것이 일반적이다.

①발생할 가능성이 있는 리스크를 추출한다. ②추출한 리스크의 내용을 분석하여 발생 시의 영향 등을 검증한다. ③프로젝트가 진행하고 있는 과정에서 상정한 리스크가 발생한 경우에 대비하여 대책(액션 플랜)을 준비한다. ④책정한 액션 플랜의 정기적인 재검토나 ⑤프로젝트 멤버가 ①~④의 내용을 조직적으로 공유하는 것도 잊어서는 안 된다.

일련의 단계는 프로젝트를 완료하기까지 공정의 부분별로 반복하여 실시하는 것이 바람직하다.

①의 리스크 추출에서는 프로젝트를 둘러싼 환경 등을 고려하여 완료까지 발생할 가능성이 있는 리스크를 추출해야 한다. 이 추출 작업은 동시에 리스크의 내용을 정의하는 경우도 있다.

프로젝트에 관계되는 이해관계자(스테이크 홀더) 전원이 리스크에 대한 인식을 공유할 수 있도록 알기 쉬운 정의가 요구된다. 리스크의 추출은 프로젝트 관계자가 생각하는 것을 열거하는 경우도 있지만 과거 프로젝트의 경험이나 전문가의 인터뷰 등을 통하여 작업하는 경우도 있다.

<이하 상세 내용은 컴퓨터월드 7월호 참조>