실용적인 프로젝트 위험관리 방안(1)
프로젝트 위험을 피하는 유일한 방법은 프로젝트를 하지 않는 것입니다..
프로젝트 위험관리는 실전에서 적용하기 힘든 프로세스입니다. 위험관리는 이슈가 발생하기 전에 예방하는 것이 목적인데, 현실에서는 발생한 이슈를 해결하기에도 시간이 부족하기 때문입니다. 그렇지만 프로젝트의 어떤 요인이 불확실하고, 그 요인이 프로젝트에 미치는 영향은 무엇인지, 그리고 부정적인 영향력을 최소화하려면 무엇을 해야 하는지 파악하는 것은 중요합니다. 필자는 프로젝트 위험관리에 대해 관심이 많아 관련된 논문이나 도서를 많이 읽어보고 조직에서 이를 적용하기 위해 여러 가지 시도도 했습니다. 필자의 경험에 근거한 실용적인 위험관리를 위한 팁을 공유합니다.
- 위험관리와 이슈관리를 구분하는 것은 도움이 되지 않습니다.
위험이 발생하면 이슈가 됩니다. 이슈는 발생한 위험이고, 위험은 발생하지 않은 이슈입니다. 따라서 위험은 예방하는 것이 중요하고, 이슈는 신속하게 해결하는 것이 중요합니다. 여기까지 논리적으로 옳고 이해하기도 쉽습니다. 그러나 현실의 프로젝트에서 위험과 이슈를 구분하기 쉽지 않습니다. 위험관리든 이슈관리든 무언가를 식별해야 대응할 수 있는데 그게 이슈인지 위험인지 헷갈리는 경우가 많습니다. 현실에서는 그런 구분을 하는 것은 사치이고, 식별한 문제를 해결하는 것이 중요합니다. 당면한 일을 처리하는 것은 프로젝트 관리자의 일상입니다. 이는 건강검진에서 당뇨수치가 놓게 나왔는데 건강의 위험신호인지, 건강에 문제가 생겼다는 이슈인지를 구분하는 것과 비슷합니다.
특히 프로젝트의 이슈가 심각하지 않을 때는 위험과 이슈를 구분하기 힘듭니다. 프로젝트를 시작하기 전에 식별하면 위험이고 프로젝트를 착수한 이후에 식별하면 대부분 이슈인 경우가 많습니다. 예를 들어 프로젝트를 수행하는 도중 핵심 이해관계자가 변경되어 프로젝트 요구사항의 변동가능성이 높아졌다면 이슈일까요? 위험일까요? 핵심 이해관계자가 변경되었다는 것은 이미 발생한 사건이니 이슈 같기도 하고, 프로젝트 요구사항은 변경될 가능성이 높지만 확실하지는 않기에 위험 같기도 합니다. 그런 고민을 할 시간에 변경된 이해관계자를 먼저 찾아가서 프로젝트 방향을 설명하고 이해관계자의 의견을 청취하는 것이 중요합니다.
누군가가 이슈관리와 위험관리를 구분하여 설명하면서 이슈관리만 하고, 위험관리는 하지 않는다고 말하면 무시하셔도 좋습니다. SI 프로젝트의 감리에서 이러한 지적을 받을 수가 있는데, 의견에 대해 인정하고 다투지 않는 것이 좋습니다.
산불을 예방하는 것도 중요하지만, 여기저기 산불이 나고 있는데 위험과 이슈를 구분하는 것은 공허합니다. 불길이 작을 때 빨리 불을 끄는 것이 중요합니다. 프로젝트도 마찬가지입니다. 작은 이슈일 때 빨리 해결하는 것이 실용적입니다.
- 위험관리는 수단이지 목적이 아닙니다.
위험관리 활동의 목적은 프로젝트를 잘 끝내는 것입니다. 그러나 위험관리 활동도 ‘일일 스탠드 업 미팅’처럼 원래의 목적을 잊고 활동자체가 목적이 되는 경우도 많습니다. 고객이나 경영층이 요구하기 때문에, 제안서에 약속했다는 이유 때문에 본질은 잊히고 위험관리 활동을 정리하는 문서만 양산할 수도 있습니다. 일상에 쫓긴 형식적인 위험관리보다 바쁜 일상에서 잠깐 벗어나 1시간 정도 차분하게 프로젝트의 현안은 무엇인지, 어떻게 대응하고 있는지, 좀 더 중요하고 큰 것을 놓치고 있는 것은 없는지 고민하는 것이 실질적인 위험관리 활동입니다. 따라서 비교적 시간의 여유가 있는 금요일 오후 30분에서 1시간 정도 위험관리를 위한 루틴을 가지는 것도 효과적입니다.
- 위험관리를 하려면 부정적인 생각을 허용해야 합니다.
위험관리는 프로젝트가 실패한다면 무엇 때문일지 고민하고 예방하는 활동입니다. 영향력이 높은 고객이나 경영층이 그런 활동을 나약하고 부정적인 생각을 한다고 비난한다면 위험관리 활동을 할 수 없습니다. 우수한 프로젝트 관리자는 부정적으로 계획하고 긍정적으로 실행합니다. 실패하는 프로젝트 관리자는 긍정적으로 계획하고 부정적으로 실행합니다. 긍정적으로 계획한다는 것은 디테일하게 고민하지 않고 낙관적으로 계획하는 것을 의미하고, 부정적으로 실행하는 것은 실행을 두려워하고 주저하는 것을 의미합니다. 타임머신을 타고 프로젝트 종료시점으로 이동했다고 가정하고 그때 나쁜 상황을 상상해 보시기 바랍니다.
- 프로젝트 착수 전에 식별한 위험의 대응방안은 프로젝트 계획에 반영해야 합니다.
같은 업무라고 해도 프로젝트 계획에 따라 위험할 수도 있고, 위험하지 않을 수도 있습니다. 시간과 예산만 충분하면 대부분의 위험은 없어지고, 역량이 높고 팀워크가 좋은 프로젝트 팀을 구성해도 많은 위험이 사라집니다. 따라서 위험에 대응하기 위한 가장 좋은 방안은 프로젝트 계획을 조정하는 것입니다. 프로젝트 계획에 반영하지 못하는 위험은 이슈가 될 가능성이 높아집니다. 이상적인 위험관리 활동은 프로젝트 계획을 확정하기 전에 위험을 식별하고 식별된 위험을 완화하고 감당할 수 있는 프로젝트 계획을 수립하는 것입니다.
프로젝트를 시작한 뒤에는 부실한 계획과 프로젝트 팀의 잘못이 복합적으로 작용하기 힘들기 때문에 뒤늦게 위험을 식별해도 프로젝트 계획에 반영하기 힘듭니다. 프로젝트 진행도중 프로젝트 계획을 변경하는 경우는 대규모의 요구사항 변경이 아니라면 프로젝트의 납기 내 완료가 확실해졌을 때입니다. SI 프로젝트라면 제안서 작성시점부터 프로젝트 계획을 확정할 때까지 위험을 프로젝트 계획에 반영할 시기입니다. 상품개발과 같은 조직내부 프로젝트라면 경영층에게 프로젝트 계획을 보고하기 전까지 프로젝트 관리자가 비난받지 않고 위험을 프로젝트 계획에 반영할 수 있습니다.
위험을 프로젝트 계획에 반영한다는 것은 아래그림과 같이 프로젝트 계획의 균형을 형성한다는 것을 의미합니다.
위험을 반영한 프로젝트 계획① 범위, 일정, 예산 모두가 제약조건이면 위험을 반영한 프로젝트 계획이 아닙니다.
범위와 일정이 제약조건이면 예산은 의사결정 항목이 되어야 합니다. 왜냐하면 범위와 일정을 준수하기 위해 보다 우수한 팀원 또는 파트너를 활용하면 제약조건의 예산보다 증가할 수 있기 때문입니다. 일정과 예산이 제약조건이면 범위를 조정할 수 있어야 합니다. 범위, 일정, 예산이 제약조건이면 의사결정 가능한 수단으로는 프로젝트 계획을 달성하기 힘듭니다.
② 품질/성능이 제약조건에 가까우면 프로젝트 위험이 증가합니다.
품질/성능목표가 변경할 수 없다면 제약조건이 하나 추가됩니다. 표면적으로는 모든 프로젝트의 품질/성능은 타협할 수 없는 제약조건입니다. 그러나 우주선을 발사하는 프로젝트와 챗봇을 개발하는 프로젝트의 품질은 다릅니다. 챗봇의 답변정확도는 상황에 따라 90%면 충분하지만, 우주선의 성능은 99%라도 문제가 될 수 있습니다. 소프트웨어 개발 프로젝트에서 오픈을 결정할 때 기능의 사용빈도와 중요도를 고려하여 허용가능한 품질 수준을 정할 수 있습니다. 특히 운영시스템(OS)과 디바이스가 다양한 요즘 모든 상황을 고려한 품질관리가 어렵기 때문에 특정 품질이슈는 알면서도 릴리즈 할 수 있습니다. 글로벌 솔루션도 100% 완전하지 않으며 이미 알고 있는 문제를 ‘known issue’로 고객지원 사이트에 공개합니다. 심지어 언제 이러한 품질이슈를 해결하겠다는 일정도 없습니다. 국내 소프트웨어 회사에서 품질이슈를 공개하고 조치 일정도 알려주지 않는 것은 상상하기 힘든 일입니다.
품질을 제약조건으로 활용하여 일정과 범위를 준수하는 방안은 유의해야 합니다. 프로젝트 관리자가 품질이슈를 인지하여 이해관계자와 공유하고, 릴리즈 또는 시스템 오픈 이후 안정화기간을 통해 품질이슈를 해결할 수 있는 수준의 품질이슈이어야 합니다. 통제되지 않는 품질이슈를 안고 시스템을 오픈하면 최악의 경우 프로젝트 결과물 자체가 무효가 될 수 있습니다.
③ 대부분의 위험은 수단의 불확실성 때문에 발생합니다.
위험이 미치는 영향력은 범위•일정•예산과 같은 ‘프로젝트 목표’이지만 위험이 발생하는 원인은 팀원 역량•이해관계자 관리•리더십•방법론과 같은 ‘프로젝트 목표 달성수단’입니다. 수단의 불확실성이 높을수록 보수적인 목표를 설정하는 것이 위험을 반영하는 것입니다. 예를 들어 프로젝트 팀원의 역량이 낮고, 관료적인 조직문화에서 프로젝트를 수행한다면 프로젝트 생산성을 그만큼 낮게 설정해야 합니다.
프로젝트 수단의 특정항목의 위험관리를 위해 다른 수단항목을 조정할 수 있습니다. 예를 들어 이해관계자 참여 수준의 불확실성이 높다면 이해관계자 참여주기와 참여 수준을 높이기 위한 프로젝트 관리 프로세스를 수립할 수 있습니다. 프로젝트 결과물을 잘게 쪼개어 프로젝트 초반에 잦은 쇼케이스를 수행하여 프로젝트 팀에 대한 신뢰를 확보하는 것이 그 예입니다.
- 위험식별 워크숍은 위험식별을 위한 유용한 도구입니다.
위험관리를 시작하려면 위험을 식별해야 합니다. 프로젝트 초반에 위험을 식별하는 방법은 계획문서(제안서, 계약서, 프로젝트 계획서)를 검토하거나 팀원이나 이해관계자들과 워크숍 또는 인터뷰를 하는 방법이 있습니다. 프로젝트의 모든 상황을 계획문서에 표현할 수 없기 때문에 팀원 또는 이해관계자들과 워크숍을 실시하는 것도 위험식별을 위한 유용한 방법입니다. 워크숍을 통해 위험을 식별하면 참석자들이 프로젝트를 인식하는 관점을 파악할 수 있는 것도 프로젝트 관리자에게는 도움이 됩니다. 워크숍을 통한 위험식별 시 유의할 사항은 다음과 같습니다.
① 참석자들이 부정적인 생각을 하고 토의하는데 부담이 없도록 합니다.
부정적인 상상을 하고 공식적으로 이야기하는 것은 참석자들에게 부담스럽습니다. 따라서 참석자들이 부담 없이 위험을 이야기할 수 있어야 합니다. 퍼실리테이터 또는 프로젝트 관리자가 프로젝트 팀원들에게 다음과 같은 이야기로 워크숍을 시작하는 것이 좋습니다.
“지금은 프로젝트에서 생길 수 있는 나쁜 일들에 관하여 이야기하는 시간입니다. 우리가 프로젝트 납기를 지키고 고객의 요구사항을 충족시키면서 예산 내에 끝낼 수 있을까요? 만일 그렇지 않을 수도 있다는 생각이 든다면 무엇 때문에 그렇게 될까요? 모두들 가슴속에 있는 ‘만에 하나’를 이야기해 주시길 부탁드립니다. 부정적인 상상을 하는 것은 성숙한 사람들의 특징입니다.”
필자는 오래된 야구팬이기 때문에 야구에 대한 기사를 자주 보는데 SK(지금은 SSG) 왕조시대를 열었던 김성근 감독이 이야기한 ‘마이너스 사고’의 내용이 좋아 소개합니다. 프로젝트를 수행하는 내내 아래의 ‘마이너스 사고’로 생각하면 안 되지만, 적어도 프로젝트를 착수하는 시점에서 한 번은 진지하게 다음과 같은 생각을 하는 것이 바람직합니다.
“나는(김성근 감독) 이렇게 되면 우승하지 못한다”를 먼저 고민한다. 이어 김정준 코치가 “이렇게 되면 경기에서 진다”를 걱정하고, 박경완(포수)은 “이 타자에겐 이렇게 하면 맞는다”를 근심하는 순서다. “마이너스 사고란 ‘이렇게 하면 이긴다’ 보다 ‘이렇게 하면 진다’를 생각하는 것이다. 누가 잘 던지고 누가 잘 치면 이긴다의 사고가 아니라 누가 못하면 진다의 개념을 먼저 생각하고 준비하는 것이 SK의 특징이다. (〈이데일리〉, 2011년 2월 5일)
② 위험식별 워크숍을 계획합니다.
• 참석 대상자
프로젝트 팀과 프로젝트의 이해관계자 모두가 참석하는 것이 바람직합니다. 경영층이 참석하면 자유로운 토의에 제약이 있다고 판단하면 경영층은 워크숍 대상에서 제외할 수 있습니다. 가급적 많은 사람이 참석해야 하는 이유는 다양한 위험을 식별할 수 있다는 장점뿐 아니라 위험식별 회의가 팀빌딩을 하는 수단이 되기 때문입니다. 많은 사람이 참석할수록 식별된 위험에 대한 정당성도 확보할 수 있습니다.
• 회의 시기
참석 대상자들이 프로젝트 내용을 이해하고 있어 그에 따른 위험을 식별할 수 있는 시기이어야 합니다. 보통 프로젝트 계획을 시작한 이후부터 착수보고 이전이 이 시기에 해당합니다. 착수보고 전에 워크숍을 하면 위험 내용과 대응계획을 착수보고서에 포함시키는 것이 좋기 때문입니다.
• 준비물
프로젝트 개요 설명자료, 위험식별 체크리스트, 포트스잇을 준비합니다. 프로젝트 개요는 프로젝트 내용을 설명하는 자료이며 위험식별 체크리스트는 참석자의 위험식별을 도와주는 자료입니다. 포스트잇은 참석자가 식별한 위험을 기록하는 용도로 활용합니다.
③ 위험식별 워크숍은 다음과 같은 순서로 진행합니다.
• 회의목적 안내
프로젝트 관리자 또는 퍼실리테이터가 참석자에게 회의목적과 향후 활용방안을 설명합니다.
• 프로젝트 개요 설명
참석자의 프로젝트 이해 수준을 고려하여 너무 길지 않게 간단하게 설명합니다.
• 위험식별 체크리스트 설명
조직에서 위험식별 체크리스트가 있다면 그것을 활용하거나 챗 GPT에 문의한 체크리스트를 활용하는 것도 좋습니다. 체크리스트는 위험식별을 도와주지만, 참석자의 사고를 제한하는 단점도 있습니다. 참석자들의 역량을 고려하여 체크리스트를 준비하지 않아도 됩니다.
• 개인별 위험식별
미리 준비한 포스트잇을 한 사람에 5장 정도 배포한 뒤, 한 장에 한 가지의 위험을 기록하도록 요청합니다. 포스트잇은 나중에 칠판에 붙여서 특성요인도 형태로 정리할 수 있기 때문에 가급적 글씨를 크게 적도록 요청합니다. 또한 위험의 내용도 키워드를 중심으로 간략하게 정리해 주도록 부탁한다. 미리 샘플을 준비하여 보여주는 것도 좋은 방법입니다. 작은 포스트잇은 잘 떨어지기 때문에 접착력이 좋고 조금 큰 포스트잇을 준비합니다. ‘일정지연 위험’처럼 아무런 의미를 제공하지 않는 위험의 결과를 기술하지 말고 위험의 원인을 기술하
도록 안내합니다. 너무 긴 시간을 주지 않고 10분 정도만 부여하시기 바랍니다.
• 위험유형 분류
포스트잇을 취합하여 퍼실리테이터가 취합된 포스트잇의 비슷한 유형별로 위험을 그룹핑하여 화이트보드나 큰 칠판에 부착합니다. 위험유형 분류의 목적은 향후 의사소통을 위한 것이기 때문에 이해관계자들의 동의가 중요하지만 토의가 길어지면 퍼실리테이터가 잠정결론을 내려야 합니다. 위험을 분류하는 과정에서 위험대응계획에 관한 내용도 언급될 수 있지만 회의의 목적은 더 많은 위험을 정확하게 식별하는 것임을 밝혀 위험식별에 집중합니다.
• 향후 일정 설명
식별된 위험의 대응계획을 어떤 일정으로 수립할 것인가를 설명합니다. 프로젝트에서 적용할 위험관리 프로세스와 양식을 이 자리에서 설명하는 것도 좋습니다.
④ 워크숍의 결과를 최종 정리합니다.
화이트보드에 정리한 내용을 노트북으로 옮기거나 사진을 찍은 뒤, 워크숍 결과를 최종 정리합니다.
• 불명확한 내용 정리
다른 사람들이 읽었을 때 무슨 위험인지를 알 수 있도록 문구를 보완한다. 상위 수준의 위험을 개략적으로 기술하지 않습니다.
• 중복된 위험항목 제거
워크숍에서 제거하지 못한 중복된 위험을 식별하여 제거합니다.
• 최종 정리
‘위험 유형’, ‘위험’, ‘위험 내용’의 형태로 최종 위험을 정리하여 참석자에게 배포합니다. 위험 내용은 참석자들이 위험을 정확하게 이해할 수 있도록 내용을 보완해도 좋습니다. 위험 내용을 기록하는 방법은 “~때문에(원인), ~가 발생 가능하며(위험), 그때 프로젝트는 ~ 될 수 있다(영향력)”의 형식이 바람직합니다.
상황이 허락한다면 식별한 위험에 대한 대응계획을 수립하는 워크숍을 별도로 진행하는 것도 좋습니다. 그러나 위험대응 계획수립은 소수의 인원이 참석하여 진행할 수도 있습니다.
https://brunch.co.kr/@kbhpmp/160
