프로젝트 위험관리는 실전에서 적용하기 힘든 프로세스입니다. 위험관리는 이슈가 발생하기 전에 예방하는 것이 목적인데, 현실에서는 발생한 이슈를 해결하기에도 시간이 부족하기 때문입니다. 그렇지만 프로젝트의 어떤 요인이 불확실하고, 그 요인이 프로젝트에 미치는 영향은 무엇인지, 그리고 부정적인 영향력을 최소화하려면 무엇을 해야 하는지 파악하는 것은 중요합니다.

1) 위험관리 개요

2) 위험관리와 프로젝트 계획

3) 위험관리 워크숍 실시

4) 위험식별, 위험보고, 대응계획수립

같은 업무라고 해도 프로젝트 계획에 따라 위험할 수도 있고, 위험하지 않을 수도 있습니다. 시간과 예산만 충분하면 대부분의 위험은 없어지고, 역량이 높고 팀워크가 좋은 프로젝트 팀을 구성해면 많은 위험이 사라집니다. 따라서 위험에 대응하기 위한 가장 좋은 방안은 프로젝트 계획을 조정하는 것입니다. 프로젝트 계획에 반영하지 못하는 위험은 이슈가 될 가능성이 높아집니다. 이상적인 위험관리 활동은 프로젝트 계획을 확정하기 전에 위험을 식별하고 식별된 위험을 완화하고 감당할 수 있는 프로젝트 계획을 수립하는 것입니다. 

프로젝트를 시작한 뒤에는 부실한 계획과 프로젝트 팀의 잘못이 복합적으로 작용하기 힘들기 때문에 뒤늦게 위험을 식별해도 프로젝트 계획에 반영하기 힘듭니다. SI 프로젝트라면 제안서 작성시점부터 프로젝트 계획을 확정할 때까지 위험을 프로젝트 계획에 반영할 시기입니다. 상품개발과 같은 조직내부 프로젝트라면 경영층에게 프로젝트 계획을 보고하기 전까지 프로젝트 관리자가 비난 받지 않고 위험을 프로젝트 계획에 반영할 수 있습니다. 

위험을 프로젝트 계획에 반영한다는 것은 프로젝트 계획의 균형을 형성한다는 것을 의미하며 구체적인 내용은 다음과 같습니다.

- 범위, 일정, 예산 모두가 제약조건이면 위험을 반영한 프로젝트 계획이 아닙니다. 

범위와 일정이 제약조건이면 예산은 의사결정 항목이 되어야 합니다. 왜냐하면 범위와 일정을 준수하기 위해 보다 우수한 팀원 또는 파트너를 활용하면 제약조건의 예산보다 증가할 수 있기 때문입니다. 일정과 예산이 제약조건이면 범위를 조정할 수 있어야 합니다. 범위, 일정, 예산이 제약조건이면 의사결정 가능한 수단으로는 프로젝트 계획을 달성하기 힘듭니다. 

- 품질/성능이 제약조건에 가까우면 프로젝트 위험이 증가합니다.  

품질/성능목표가 변경할 수 없다면 제약조건이 하나 추가됩니다. 표면적으로는 모든 프로젝트의 품질/성능은 타협할 수 없는 제약조건 입니다. 그러나 우주선을 발사하는 프로젝트와 챗봇을 개발하는 프로젝트의 품질은 다릅니다. 챗봇의 답변 정확도는 상황에 따라 90%면 충분하지만, 우주선의 성능은 99%라도 문제가 될 수 있습니다. 소프트웨어 개발 프로젝트에서 오픈을 결정할 때 기능의 사용빈도와 중요도를 고려하여 허용가능한 품질 수준을 정할 수 있습니다.

특히 운영시스템(OS)과 디바이스가 다양한 요즘 모든 상황을 고려한 품질관리가 어렵기 때문에 특정 품질이슈는 알면서도 릴리즈 할 수 있습니다. 글로벌 솔루션도 100% 완전하지 않으며 이미 알고 있는 문제를 ‘known issue’로 고객지원 사이트에 공개합니다. 심지어 언제 이러한 품질이슈를 해결하겠다는 일정도 없습니다. 국내 소프트웨어 회사에서 품질이슈를 공개하고

조치 일정도 알려주지 않는 것은 상상하기 힘든 일입니다. 

품질을 제약조건으로 활용하여 일정과 범위를 준수하는 방안은 유의해야 합니다. 프로젝트 관리자가 품질이슈를 인지하여 이해관계자와 공유하고, 릴리즈 또는 시스템 오픈 이후 안정화기간을 통해 품질이슈를 해결할 수 있는 수준의 품질이슈 이어야 합니다. 통제되지 않는 품질이슈를 안고 시스템을 오픈하면 최악의 경우 프로젝트 결과물 자체가 무효가 될 수 있습니다. 

- 대부분의 위험은 수단의 불확실성 때문에 발생합니다.  

위험이 미치는 영향력은 범위•일정•예산과 같은 ‘프로젝트 목표’이지만 위험이 발생하는 원인은 팀원 역량•이해관계자 관리•리더십•방법론과 같은 ‘프로젝트 목표 달성수단’입니다. 수단의 불확실성이 높을수록 보수적인 목표를 설정하는 것이 프로젝트 계획에 위험을 반영하는 것입니다. 예를 들어 프로젝트 팀원의 역량이 낮고, 관료적인 조직문화에서 프로젝트를 수행한다면 프로젝트 생산성을 그만큼 낮게 설정해야 합니다. 

특정 수단항목의 위험관리를 위해 다른 수단항목을 조정할 수 있습니다. 예를 들어 이해관계자 참여 수준의 불확실성이 높다면 이해관계자 참여주기와 참여 수준을 높이기 위한 프로젝트 관리 프로세스를 수립할 수 있습니다. 프로젝트 결과물을 잘게 쪼개어 프로젝트 초반에 잦은 쇼케이스를 수행하여 프로젝트 팀에 대한 신뢰를 확보하는 것이 그 예입니다. 

=======================================================
제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 <슬기로운 PM 생활>을 25년 1월 출간한 소식을 공유합니다.

https://product.kyobobook.co.kr/detail/S000215148133