위험과 이슈

  PM 이 사업관리 하는 것 중에 가장 모호한 것이 위험과 이슈다. 도대체 이것의 기준이 무엇인가 헷갈리기 일쑤다.

지금까지 만나본 수 많은 감리들 조차 이 두가지를 구분하는 감리인을 만나보지 못했다. 그래서 어떤 경우에는 각각 관리 대장을 따로 만드는 것이 아니라 아예 '위험/이슈 관리 대장'이라고 하나로 작성하는 경우도 있다.

 

  나는 이것을 이렇게 이해하고 있다. 물론 나 나름의 생각이라 정답이라고 할 수 는 없다. 위험은 프로젝트가 시작되기 전에 이미 식별된 것들이다. 이슈는 사전에 인지되지 못한 즉 프로젝트 수행 도중에 예상치 못한 리스크가 발생한 경우를 말한다. 문제는 이 얘기를 하려는 것이 아니라 앞서 얘기한 위험 관리에 대해 말하고자 한다. 내 생각에 따르면 위험은 미리 예견된 리스크라고 했다.

자! 공공 프로젝트를 20년 아니 5년만 넘게 한 사람이면 어떤 위험이 도사리고 있는 지 이미 알고 있다.

 

그럼 나열해 보자

우선 일반적인 프로젝트에서 발생하는 위험요소이다.

 

- 고객은 그들의 생각을 결정하지 못한다. 요구사항은 계속 변한다.
- 프로젝트 일정은 항상 뒤 쳐진다.
- 작업기간이 비현실적이다.
- 프로젝트 수행요원 불충분하다.
- 장비도 불충분하다
- 부족한 예산
- 해서 코스트 초과한다.
- 사람문제가 발생한다.
- 협력업체들은 말을 안듣는다.

 

 

공공프로젝트를 할 때 우리가 경험하는 그래서 미리 예측할 수 있는 위험요소이다.

 

- 예산 : 프로젝트 직접 관련된 예산만 확보되며, 예비비가 전혀 없다.
- 역할과 책임 : 역할과 책임이 불분명하며, 비협조적이고, 업무 부하의 불균형이 발생한다.
- 전문성 결여 : 전문지식 결여 및 조직의 빈번한 교체가 발생한다.
- 개발 프로세스 : 개발 프로세스가 부적정하여 일정지연, 비용초과가 발생한다.
- 프로젝트 계획 : 범위가 애매모호하고, 추정이 부정확하며, 계획성이 결여되어 있다.
- 프로젝트 인터페이스 : 복합적 인터페이스로 요구사항의 혼선을 초래하고, 기술적 제약이 발생하며, 일정조정의 곤란해져 마침내 프로젝트 통제성이 상실된다.
- 시스템 엔지니어링 : 아키텍쳐, 인터페이스 설계 정의 불충분으로 백화점식 아키텍쳐가 이루어진다.
- 요구사항 : 요구사항이 막판까지 변경으로 일정지연 및 예산추가 부담이 발생한다.
- 일정 : 일정제약이 발생하고, 고객의 인수준비 결여 및 운영조직 미비하다
- 테스트 : 테스트 프로세스의 불충분한 정의 및 테스트 툴과 자료가 미흡하다.

 

공감하는가?

 

  위에 열거한 모든 위험이 하나도 빠지지 않고 일어난 프로젝트를 난 2번 경험했다. 그리고 지금 무지 반성한다.

미리 예견되는 위험이라면 왜 미리 대책을 마련하지 않았는지? 즉, 위의 일이 발생할 때 아무런 대책이 없다면 그는 아직 PM 이 아닌 것이다. 해서 난 아직 PM 이 아니다.

엄청 부끄럽다.