Talk about Software with hani

프로젝트 완료일을 달력 위에 동그라미 친 날짜로 생각하는 경향이 있습니다. 물론 작업명세서(SOW, statement of work)나 계약서에 적어 놓은 완료일, 아니면 MS Project에서 산출되는 작업완료일도 특정한 날짜이니. 그다지 틀린 이야기도 아닙니다. 지금 맡고 있는 프로젝트에서도 특정 날짜를 프로젝트 완료일로 정해 놓았고, 팀원도, 고객도, 기타 관련자도 모두 그렇게 생각합니다. 물론, PM인 저도 그날 프로젝트가 끝나야 한다고 믿습니다.*

제가 사랑하는존경하는 톰과 티모시 아저씨가 지은 ‘리스크 관리‘에서, 프로젝트 완료일을 일종의 확률 분포로 봐야한다고 말씀하십니다. 즉, ‘프로젝트 완료일을 산출하는 작업’은 ‘달력 위에 동그라미 그리는 미술숙제’가 아니라 ‘100번 동전을 던져서 앞면이 몇 번 나올지 맞추는 산수문제’라는 것이죠. 톰과 티모시 아저씨의 말씀에 따라서 프로젝트 완료일을 그려보면 다음과 같습니다.

흔히 프로젝트 완료일이라고 하는 부르는 날짜는, 프로젝트를 끝낼 확률이 다소 높은 날짜일 따름이죠.# ‘계약서에 적힌 날짜에 끝날 확률’은 프로젝트 시작일부터 계약서 날짜까지 확률분포 곡선을 적분한 값입니다. 위의 그림에서 ‘계약서에 적힌 날짜’에 끝날 확률은 대략 70퍼센트가 넘는 듯합니다. 반대로 프로젝트 완료일을 지키지 못할 확률이 무려 30퍼센트나 된다는 뜻입니다.

오  마이 갓.

30퍼센트라는 숫자는 고객이나 프로젝트 관리 조직(PMO, Project Management Office)에서 아는 날이면 난리가 날 정도로 높은 숫자입니다. 하하하. 물론 이 확률이 얼마나 맞냐고 물으신다면, 먼산만 쳐다볼 따름입니다. 즉, 확률분포 곡선이 얼마나 정확한지를 먼저 증명해야 하는데, 그게 쉬운 일도 아니고 그마저도 논란이 많은 일이기 때문이죠.

제가 여기서 말하고 싶은 것은, 이런 확률이 맞냐 그르냐의 문제가 아닙니다. 즉, 확률분포 곡선이 어떻게 되든지, 프로젝트 완료일을 지키지 못할 확률… 즉, 위험(risk)은 어떤 프로젝트에서든 존재한다는 사실입니다. 결국, 톰과 티모시 아저씨가 ‘리스크 관리’라는 책에서 하는 이야기로 돌아가야 합니다. 즉, 프로젝트 완료라는 것만 놓고 봐도 완료를 지키지 못할 위험이 존재하기 때문에, 프로젝트 관리를 제대로 하기 위해서, 프로젝트 관리자는 항상 위험관리를 해야 합니다.

자! 비현실적인재미있는 책 이야기는 옆으로 치워두고, 현실로 돌아와보죠. 현실에 있는 수많은 프로젝트(제가 몸 담은 프로젝트를 포함해서)에서 얼마나 위험을 잘 관리할까요? 제가 프로젝트마다 다니면서 현실을 보지 못했으니까, 다 알 수 없지만. 지난 제 경험을 돌이켜보면 위험을 관리하기보다 위험 때문에 발생한 사건을 처리하기 바뻤죠.

뭐, 사랑하는 애인의 과거도 중요하지 않은 마당에, 지난 프로젝트의 과오를 온 세상에 알려서 뭣 하겠습니까? 다만, 우리에게 필요한 것은 과거의 실수를 되풀이 하지 않는 배움과 실천의 자세죠. 그렇기 때문에, 지금부터라도 위험관리를 제대로 하면 됩니다.

하지만, 위험관리를 제대로 할려면 여러가지 문제에 부딪힙니다. 프로젝트 안에서 처리하지 못하는 위험도 있고, 예산 때문에 완화계획을 실행하지 못하는 경우도 있습니다. 그러니 위험을 식별하고, 분석하고, 완화계획을 세운다고. 그냥 한나절 문서작업으로 끝날 때가 많습니다. 그렇다고 좌절해서, 스나미처럼 몰려오는 위험을 목도할 수만은 없습니다.

그래서, 산전수전 공중전까지 치룬 베테랑 관리자가 아닌, 초보 관리자분께 도움이 될만한 팁 하나 알려 드립니다. 위험 관리가 어렵다고 느끼신다면 위험, 이슈, 문제로 분리해서 관리해 보세요. 사실, 위험, 이슈, 문제는 모두 위험이라고 말할 수 있습니다. 다만 세 가지에서 차이는 발생확률에 있습니다.

위험 : 발생하지 않은 것으로 프로젝트에 영향을 줄 수 있는 것입니다. 예를 들어, 2달 후 팀에 합류할 개발자가 정해지지 않았다면, 개발자의 역량에 따라서 개발 속도가 달라져 개발이 지연될 수 있는 게 위험입니다.

이슈 : 팀원이 사용하던 노트북이 고장나서, 당장 조치를 취하지 않으면 개발을 못하는 상황이 바로 이슈입니다. 즉, 위험이 현실화되서 악영향을 줄 수 있는 상황입니다.

문제 : 역량이 떨어진 개발자가 투입되고, 고장난 노트북이 빨리 수리되지 않아 팀원이 며칠째 노는 상황입니다. 위험이 현실화되고, 이슈가 실제로 악영향을 주는 상황입니다.

위험은 아직 발생하지 않은 것이고, 이슈는 위험이 발생해서 당장 조치를 취하지 않으면 프로젝트에 문제를 일으키는 것입니다. 문제는 말 그대로 일정이 지연되고 품질이 떨어지고 비용을 초과한 상태죠. PM은 세 가지 것을 모두 관리해야 합니다. 특히, 위험관리를 잘 한다면, 이슈나 문제를 고민하지 않아도 되죠. 하지만, 현실이란 위험관리를 잘해도 예상하지 못한 문제가 발생하기 마련입니다.

초보관리자가 위험을 식별해서 완화계획을 세우는 게 쉽지 않습니다. 위험이라는 게 확률 문제이기 때문에, 경험이 없다면 예측을 잘 하지 못하기 때문이죠. 따라서 초보관리자에게 위험관리란 약간 피상적으로 느껴질 수 있습니다. 이런 경우, 이슈관리를 중심으로 문제를 해결하는 방법을 체득한 뒤, 어떤 위험이 존재하는지 경험을 쌓은 다음 위험관리로 넘어가는 게 좋습니다.@

자! 그렇다면 이슈관리는 어떻게 하는 게 좋을까요? 팀원과 효과적인 의사소통을 해서, 팀원이 어떤 이슈를 가지고 있는지 파악해야 합니다. 의사소통을 잘 하는 형식적인 방법으로써, 스탠드업 미팅이 좋습니다. 짧은 시간이지만 공적인 회의 자리에서, 자신에게 있는 이슈나 팀에 있는 이슈를 말할 수 있기 때문이죠. 아울러 팀원과 커피를 마시면서, 팀원이 고민하고 있는 부분도 들어보는 것도 좋은 방법이죠. 물론 고민이 모두 이슈는 아니지만. 비공식적인 대화채널도 이슈를 파악하는 좋은 수단입니다.

초보 팀장님, 여러분께 조금이나마 도움 되셨으면 좋겠습니다.

* 믿는 것과 현실은 다릅니다. 하하하. 물론, 그날 끝내야 모든 이가 편합니다.

# 물론 계약, 즉 돈이라는 문제가 걸려 있지만, 이것은 논외로 하겠습니다.

@ 위험관리를 완전히 무시해도 된다는 뜻은 아닙니다.

This entry was posted on Wednesday, July 30th, 2008 at 3:41 pm and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.