112. 위험통제 의사결정 시 유의사항
성공적인 소프트웨어 신상품 개발가이드
위험의 대응계획 수립이후에는 대응계획을 이행하고 위험 진척상황을 모니터링하고 필요시 통제를 해야 한다. 이번 회에서는 위험을 통제하는 목적과 위험통제시 유의할 사항을 설명한다.
1) 위험을 통제하는 목적
위험을 통제하는 목적은 다음과 같다.
- 위험대응계획의 이행 점검
아무리 좋은 대응계획도 이행하지 않으면 의미가 없다. 복잡하고 바쁜 프로젝트 상황에서는 계획만 수립하고 실행을 소홀히 하기 쉽다.
- 위험대응계획의 효과성(effectiveness) 평가
위험대응계획을 계획대로 이행했을 경우 그 효과(발생 가능성이나 영향력이 줄어들고 있는지)를 평가한다. 발생 가능성이나 영향력이 줄어들지 않거나 오히려 늘어나면 대응계획이 잘못되었다는 의미이므로 새로운 대응계획 수립을 검토해야 한다.
- 프로젝트 가정의 변경 여부 점검
가정목록(assumptions list)은 프로젝트 위험목록과 동일하다. 가정이란 불확실한 프로젝트 상황에 대하여 임의로 설정한 사항으로, 그대로 되지 않을 경우에는 프로젝트의 위험요소가 된다.
- 위험 심각성 추이 모니터링
위험 대응계획의 효과성을 판단하기 위해서는 위험 심각성을 지속적으로 모니터링 해야 한다.
- 신규위험의 발생 여부 모니터링
위험식별은 착수할 때 한 번만 하는 것은 아니다. 프로젝트 진행 도중 신규위험의 발생 여부를 지속적으로 모니터링 해야 한다
2) 위험통제를 위한 의사결정 시 유의사항
위험통제를 위한 의사결정시 유의할 사항은 다음과 같다.
- 상품개발의 속도나 품질보다 방향을 먼저 검토해야 한다.
프로젝트가 잘 진행되는 것처럼 보이다가 잘못된 계획, 간과된 작업, 잘못된 가정들이 한꺼번에 터져 나오는 순간들이 있다. 그때 어떤 의사결정을 하느냐에 따라 통제가 팀에 도움이 될 수도 있고, 팀을 더디게 할 수도 있다. 이 순간 가장 중요한 것은 프로젝트의 방향성을 점검하는 것이다.
프로젝트의 방향성을 파악하지 못한 상태에서의 의사결정은 표면적인 조치에 그치기 쉽다. 프로젝트의 방향성이란 고객가치 관점에서 상품개발의 적정성을 점검하는 것이다. 마치 항해 중인 배의 방향을 모른 채, 단순히 항해 거리와 속도만 측정해서는 안 되는 것과 같은 이치다. 지금까지의 문제가 방향성과 관련된 문제라고 판단되면 단순히 프로젝트 일정이나 품질에 집중해서는 미래의 불확실성을 제거할 수 없다. 프로젝트의 방향을 먼저 제대로 잡은 뒤 일정이나 품질 문제를 해결해야 한다.
방향성의 불확실성을 제거하고 나면 생산성의 불확실성을 제거해야 한다. 생산성의 불확실성은 대부분 투입인력의 양이나 질과 관련된 문제다. 투입인력의 양과 질을 바꾸지 못한다면, 지금까지의 속도로 미래를 전망하는 것이 안전하다. 이때 미래의 불확실성을 제거하기 위해서는 계획을 바꾸거나 수행방법 혹은 팀원을 바꾸는 의사결정을 해야 한다. 중요한 것은 이해관계자와 팀원이 의사결정의 결과를 신뢰할 수 있어야 불확실성이 줄어든다는 것이다.
관리자 혼자 의사결정을 하거나 미래의 성과를 낙관해서는 안 된다. 불확실성의 근본 원인을 제거하지 않은 상태에서 숫자로만 주장하는 의지나 낙관적인 미래는 신뢰를 얻기 힘들다.
- 프로젝트 내부 여러 팀의 일정이 지연되는 경우 문제파악에 유의한다.
프로젝트가 지연되는 경우 프로젝트 내부 팀의 여러 업무가 한꺼번에 지연 중일 가능성이 높다. 이때 표면적으로 가장 큰 원인을 제공하는 팀이 희생양이 되어, 나머지 팀들은 자기 팀은 이상이 없고 모든 잘못을 그 팀으로 돌리는 경우가 있다. 예를 들어 A팀의 업무가 B팀의 업무수행을 위해 먼저 끝나야 하는 경우, B팀이 일정 지연을 A팀과 관련된 업무지연에 물타기를 해서 보고하는 경우가 있다.
프로젝트 내부에서 “A팀 때문에~(또는 A이슈 때문에)”라는 전염병이 퍼지는 순간이다. 나머지 팀들은 희생양이 충분한 시간을 벌어주기를 기대하면서 내부적으로 미흡한 업무를 보완한다. 그러다 A팀의 문제가 해결되고 안개가 걷히면 준비 안된 B팀, C팀이 새로 나와 관리자를 당혹스럽게 할 수 있다.
이런 현상은 인터페이스가 복잡한 대형 프로젝트에서 발생할 수 있다. 프로젝트 관리자는 각 팀의 리더에게 정확한 현황을 보고할 것을 요청하고 동시에, A팀뿐 아니라 나머지 팀의 현황도 상세하게 파악해야 한다.
- 소탐대실해서는 안 된다
프로젝트 정상화를 위한 대책을 수립할 때 눈앞의 작은 이익을 취하려 하다가 큰 것을 놓치는 우를 범해서는 안 된다. 원가가 초과되고 일정이 지연된 상황에서 더 이상의 원가초과와 일정지연을 최소화하는 것은 당연하다. 그러나 궤도를 이탈하고 있는 프로젝트에서는 좀 더 안전한 조치가 필요하다. 암 수술을 할 때 실제 종양이 있는 부위보다 크게 제거하듯이 프로젝트에서도 약간 과한 듯한 의사결정이 적절한 경우가 많다. 물론 이런 의사결정을 내리기는 쉽지 않다. 그러나 결과적으로 보면 예산초과와 기간연장을 결정할 때 조금 넉넉하게 의사결정 하는 것이 종료시점의 전체 예산과 기간을 줄이는 경우가 많다.
- 정상화를 위한 계획 수립 시 프로젝트 팀원을 충분히 참여시킨다
최종 의사결정은 프로젝트 관리자의 몫이지만, 의사결정 과정에서 팀원의 의견을 충분히 듣고 서로 토의하는 시간을 가져 정상화를 위한 계획수립에 팀원들이 공감해야 한다. 흔히 프로젝트 정상화를 위한 일정・원가・인력 등의 계획을 일방적으로 위에서 아래로 전달하는 경우가 많은데 이는 피해야 한다.
시간이 걸리더라도, 약간 돌아가더라도 정상화를 위한 계획 수립 시 팀원과 함께 하여야 한다. 그것이 정상화 계획에 명분과 권위를 주는 것이다. 일방적으로 수립하여 전달하는 정상화 계획은 아무도 쳐다보지 않는 프로젝트 상황실의 현황 판과 같다.
- 기준선과 계획의 변경은 신중하게 한다
기준선(baseline)과 현재 계획(current plan)은 다르다. 기준선은 프로젝트의 계획 대비 실적의 성과를 평가하는 것이 목적이지만, 현재 계획은 현재 계획대로 프로젝트가 통제되고 있는가를 확인하는 기준이 된다. 기준선은 최초 계획 대비 일정을 파악할 수 있기 때문에 신중하게 변경해야 한다.
계획을 너무 자주 변경하면 계획의 권위가 없어지고, 계획을 변경하지 않으면 목표로서의 기능을 상실한다. 일정이 2~3개월 이상 지연되면 따라잡는 계획으로서의 의미가 없으니 변경할 것을 권고한다. 반면 1개월 이내의 지연이라면 만회활동을 통해 계획을 따라잡는 것이 중요하다. 잦은 계획변경은 팀원을 피곤하게 할 뿐만 아니라, 새로운 계획수립에도 시간이 많이 소요된다. 나아가 신경이 곤두선 경영층에게 계획변경의 필요성을 설명해야 하는 과정에서 많은 시간과 자원이 낭비된다..
- 상품개발 후반부의 속도는 초반보다 느리다
상품개발 후반부의 속도는 초반보다 느리기 때문에 일정과 관련된 의사결정 시 유의해야 한다. 상품개발 후반부에 속도가 느린 이유는 다음과 같다.
• 프로젝트 후반부에 남은 결함은 고치기 힘든 결함이 많다.
• 상품출시를 앞두고 예상하지 못했던 업무가 많이 추가된다. (예:마케팅 지원, 각종 문서작성)
• 기능들을 통합하면서 예상하지 못했던 새로운 이슈들을 발견한다.
• 이전 단계에서 100퍼센트 완료하지 않은 작업들을 처리해야 한다.
