리스크 관리의 중요성
프로젝트의 경험을 조직의 자산으로 만들자.
이제까지의 수많은 경험을 토대로 계획을 수립하고, PM으로써 할 일을 모두 완벽하게 수행했음에도 불구하고, 프로젝트가 어려워지는 경우가 있다. 그런 경우는 대체로 내가 당연히 그러할 것이라고 생각했던 부분이 실제로는 그렇지 못한 경우에 발생한다. 빵꾸는 언제나 예상치 못한 부분에서 발생한다.
* 내가 경험했던 예상치 못한 이슈 사례
- 프로젝트 투입인력이 당연히 알 것이라고 기대했던 개발환경 세팅이나, 쿼리문 작성과 같이 기본적인 활동에 어려움을 겪는 경우
- 기존 시스템의 운영 담당자가 당연히 갖고 있을 것이라고 생각했던 테이블 설계서나 시스템 구성도를 전혀 갖고 있지 않은 경우
- 기존 시스템 운영 담당자가 업무 프로세스도 설명하지 못하는 경우(담당자가 최근 교체된 경우)
- 심지어 기존 시스템의 개발환경도 없고, 개발 소스가 유실된 상태인 경우
- 그럼에도 불구하고, 고객사의 품질관리 수준이 내가 예상했던 수준보다 훨씬 더 가혹한 기준을 갖고 있는 경우
누군가는 정말로 이런 곳이 있냐고 물어볼 수 있겠지만, 정말로 있다. 위 모든 사례를 한군데에서 경험한 것은 아니지만, 위 사례는 모두 본인이 실제로 경험한 사례다.
위와 같은 경우는 PM으로써 예상하기 힘든 부분이며, 위의 사항이 프로젝트 진행 중 이슈화된다면, 이슈화된 이후 바로잡기 위해서는 많은 노력이 수반된다. 뒤늦게 인력을 추가로 투입하거나, 오픈 일정을 조정해야 할 것이며, 그런 경우는 프로젝트 원가의 상승, 이익률의 하락으로 이어진다. 그렇게 하더라도 고객은 이미 절반쯤은 실망한 상태일 것이며, 심한 경우에는 당신이 하는 모든 일에 대해 불안한 눈으로 바라볼 것이다.
이슈를 수면으로 드러내지 않고 프로젝트팀 차원에서 해결하려면 개발자들에게 야근이라도 엄청 시켜야 할 텐데, 야근을 통해 지연을 만회할 수 있는 수준에는 한계가 있으며, 개발자들로부터 믿음을 얻기는 글렀다고 봐야 한다. 야근은 서비스 오픈 작업이나, 긴급한 오류/장애 처리 등 어쩔 수 없는 경우를 제외하고는 되도록 없어야 한다는 것이 내 생각이다.
만일 위 현황을 사전에 정확히 알고 있는 상태에서 착수한다면 PM으로써 할 수 있는 방법은 많다. 개발자를 사전에 교육시키거나, 대체인력을 구하거나, 인력 투입 계획을 확대하거나, 추가적인 프로젝트 QA(품질관리자)인력을 확보하는 등을 고려할 수 있을 것이다. 즉, 어떤 이슈라도 PM이 알게 된 이후부터는 관리할 수 있는 프로젝트의 범위인 것이며, 착수 전에 미리 파악하였다면, 그 이후부터 바로잡아가는 과정 또한 계획대로 진행되는 상태인 프로젝트의 일부인 것이다.
그렇다면, 이와 같이 이슈를 사전에 파악하려면 어떻게 해야 할까?
첫 번째, 프로젝트의 수행과정상 발생했던 이슈들을 기록하여 조직의 자산으로 만들어야 한다.
KMS(지식관리시스템)가 있다면 더할 나위 없겠지만, 그렇지 않다면, 프로젝트 종료보고서 양식을 만들어 이슈/해결 과정, 잘된 점, 잘못된 점, Lessons & Learned를 정리하여 사내 그룹웨어 게시판에라도 올려놓자. 일단은 조직의 프로젝트 경험이 좀 쌓여야 한다. 해당 종료보고서는 PM이 주도하여 작성하되, 참여했던 개발자들의 의견도 최대한 포함시키는 것이 좋다.
두 번째, 과거 프로젝트의 수행 기록을 DB 화하여 리스크 체크리스트를 만들자.
프로젝트의 수행사례와 이슈 해결사례가 쌓이면, 이것들을 정제하고 일반화(일반적인 상황에 체크할 수 있는 항목으로 변경)하여 DB화 하여야 한다. 기술 영역/프로젝트 관리 영역 기준으로 분류하여 정리하고, 기존의 리스크 관리 체크리스트에 더한다.
과거 프로젝트에서 발생하여 문제가 되었던 이슈들은 대체로 그 당시에 PM의 입장에서는 미처 예상치 못했던 사항일 가능성이 높다. 따라서, 프로젝트 착수 전에 체크해보는 것만으로도 프로젝트를 수행할 PM의 입장에서는 상당히 의미가 있을 것이다.
세 번째, 착수 전 리스크 검토회의를 통해 회사차원의 대응계획을 확정하자.
PM은 착수 전~착수단계에서 영업담당이나 프리세일즈 담당을 통해 프로젝트 리스크에 대한 현황을 최대한 파악하자. 단순히 일방적으로 정보를 제공받는 입장이 아니라, 리스크 항목에 있는 사항을 기준으로 질문을 던져서 답을 얻어내자. 그렇게 한다면, 분명 이슈가 될 가능성이 있는 항목들이 추려질 것이다. 너무 꼬치꼬치 캐물으면 거부반응이 나올 수도 있겠지만, 그런 거부반응 없이 정보를 얻어내는 정도의 개인기는 갖고 있는 PM이기 바란다.
리스크 발생 가능성과 영향도를 각각 상/중/하로 점수를 매기고, 사전에 대응방안(회피, 제거, 완화 등에 해당하는...)을 수립해 놓는다. 발생 가능성 와 영향도가 높은 항목에 대해서는 반드시 구체적인 대응방안을 수립하자.
정리된 리스크 관리대장을 갖고 한 번 정도는 회사 내부 이해관계자 모두와 회의를 거칠 필요가 있다. 영업대표, 프리세일즈 담당, PMO(전사 프로젝트 관리팀), 가능하면 담당 임원까지 모두 참석한 상태에서 PM이 생각하는 프로젝트의 리스크와 대응방안에 대해 리뷰하여, 가능하다면 회사 차원의 프로젝트 대응계획을 확정하자.
네 번째, 주기적으로 리스크 관리 활동을 수행하자.
그리고, 주기적으로 리스크 관리 활동을 수행하자. 나는 개인적으로 프로젝트 기간 중 주 1회 스케줄을 예약해놓고 리스크 관리 활동을 하려고 노력하는 편이다.
- 리스크 관리대장을 전체적으로 조망하여 전체 프로젝트 범위에서 누락된 부분이나 새로 추가해야 할 부분이 있는지 검토한다.
- 수립해놓은 대응방안 중 현재 상황이 바뀐 부분이 있는지 검토한다. 더 좋은 방안이 생긴다면, 업데이트한다.
- 현재 제거된 리스크가 있다면, 해당 내용도 업데이트한다. 리스트에서 아예 삭제하지 말고 완료 처리해놓는다. 프로젝트가 모두 끝난 이후에 다시 참고할 수 있도록...
물론 이러한 활동을 지속적으로 수행한다고 해도 프로젝트 진행 중에 이슈는 또 발생할 것이다. 전혀 새로운 이슈라면 속수무책이겠지만, 적어도 조직에서 이미 경험했던 이슈에 대해서는 그래도 한두 가지 대응방안 정도는 준비해놓은 상태일 것이며, 프로젝트의 경험이 쌓여갈수록 전혀 예상치 못한 이슈가 발생할 가능성은 점점 줄어들 것이다.
가장 좋은 것은 이러한 활동을 회사 차원에서 제도화하여 운영하는 것이다. 사내의 PMO에서 프로젝트의 이슈/해결 과정에 대해 취합하고, 정제하여 프로젝트 리스크 항목을 지속적으로 업데이트하여 PM들에게 배포해야 한다. 프로젝트 진행과정 중에 정기적으로 리스크/이슈 관리항목을 PMO가 취합하여 계획된 대응방안이 최선인지, 함께 리뷰하고, PM 개인 차원이 아니라, 회사차원에서 대응할 준비를 갖추어야 한다. PM은 프로젝트 종료 시에 프로젝트 종료보고서를 작성하여 보고하는 것이 정례화되어야 하며, 종료보고서를 통해 치열하게 토론하고 더 나은 해결방법을 찾아야 한다.
만일 회사차원에서 이러한 활동을 할 수 있는 여건이 안된다면, PM 본인 스스로라도 이러한 활동을 수행하기 바란다. 본인이 경험했던 프로젝트를 리뷰하여 리스크 관리항목을 만들고 착수 전에 반드시 체크하는 것을 본인만의 규칙으로 만들기 바란다. PM 혼자서 개인적으로 이러한 리스크 관리 활동을 할 때 주의할 점은 그저 루틴 하게 매너리즘에 빠져버리는 것이다. 일주일에 단 30분만이라도 진지하게 몰입해야 한다. 가장 상세한 부분까지 빠짐없이 생각하되, 전체를 조망해야 한다. 물 위에 고요하게 떠 있는 오리가 물 밑에서는 쉼 없이 발길질을 하고 있는 것처럼, 항상 완벽하게 프로젝트를 수행하는 어느 PM도 본인 스스로는 쉼 없이 촉각을 곤두세우고 있는 것이다. 사자는 토끼를 잡을 때도 최선을 다해서 사냥한다.
다섯 번째, 프로젝트 종료 리뷰
프로젝트가 끝나고 나면 다시 첫 번째로 돌아가 프로젝트 종료보고를 통해 프로젝트의 이슈와 해결 과정을 리뷰하자. 이 과정에서 도출된 사항 중 조직 자산화(그룹웨어에 등록, 리스크 체크 항목에 추가) 외에 회사 차원에서 제도화를 해야만 근본적인 해결이 가능한 부분도 있을 것이다. 이러한 부분은 회사의 경영진까지 보고하여 개선되도록 하자. 이러한 현장의 목소리가 정책에 잘 반영되는 회사가 건강하고 발전 가능성이 있는 회사이고, 이와 같이 회사 정책에 까지 반영되도록 하는 것까지가 PM의 의무라고 생각한다.
만일 당신이 특정 한 가지 업무분야 시스템 구축 PM을 5년 이상 한 사람이라면 RFP(제안요청서)를 한 번만 읽어보더라도, 예상되는 리스크와 대응방안이 이미 어느 정도 머릿속에 그려질 것이다. 그렇다면, 그러한 본인의 노하우를 문서로 정리하여 사내의 다른 경험이 부족한 PM에게 전달되도록 조직의 자산을로 만들어 물려주자.
