실용적인 프로젝트 위험관리 방안(2)
프로젝트 위험을 피하는 유일한 방법은 프로젝트를 하지 않는 것입니다.
- 위험을 보고해서 손해 볼 일은 별로 없습니다.
경영층에게 위험을 보고해서 손해 볼 일은 무엇일까요? 위험보고서 작성을 위한 시간과 노력은 분명히 프로젝트 관리자에게 부담이 됩니다. 한가지 더 프로젝트 관리자에게 부담이 되는 상황은 위험보고를 하니 매주 진행상황을 보고하라는 황당한 피드백입니다. 만일 조직에서 황당한 피드백을 받을 가능성이 없다면 위험보고가 프로젝트 관리자에게 마이너스가 되는 일은 거의 없습니다.
프로젝트 후반부에 위험을 보고하면 늦게 보고했다는 질책을 받을 수 있지만, 위험을 보고하지 않는 것보다는 좋습니다. 물론 프로젝트 후반부에 프로젝트 관리자가 확실히 감당가능한 위험을 보고해서 경영층에게 나쁜 인상을 남길 필요는 없지만, 프로젝트 관리자가 감당가능한 위험인지는 냉정하게 판단해야 합니다. 프로젝트 후반부에 프로젝트 관리자가 위험하다고 판단할 때에는 대부분 감당여부가 불확실한 경우이기 때문에 위험을 보고하는 것이 도움이 됩니다. 프로젝트가 지연되거나 예산을 초과해서 끝났다면 조금이라도 빨리 위험을 보고해야 문제를 숨겼다는 오해를 덜 받을 수 있고, 이슈가 발생하지 않고 프로젝트가 잘 끝나면 프로젝트 관리자가 위험을 잘 관리했다는 인상을 남길 수 있습니다.
프로젝트 착수 전 또는 초반이라면 위험을 보고하는 것이 무조건 좋습니다. 물론 사소하고 자잘한 위험이 아니라 경영층이 볼 때 어느 정도 위험으로 판단할 수 있는 내용이어야 합니다. 그러한 내용의 위험이라면 조금이라도 빨리 공식적으로 위험을 보고해야 합니다. 착수보고회는 위험을 보고하기 가장 좋은 자리입니다. 프로젝트 추진계획을 설명 한 뒤, 프로젝트 팀에서 식별한 위험과 대응방안, 경영층에게 바라는 지원사항을 설명하면 됩니다. 당장 요청할 사항이 없다면 프로젝트 팀에서 위험을 자체적으로 관리하다 필요할 때 지원을 요청하겠다고 말씀하시면 됩니다.
프로젝트 관리자가 설명하지 않으면 경영층이 해당 프로젝트의 어려움을 이해할 수 없습니다. 내가 얼마나 어려운 프로젝트를 하는지를 알아주기를 바라기만 해서는 안됩니다. 프로젝트가 잘 끝나면 프로젝트 관리자가 위험관리를 잘한 것을 완료보고 시에 설명하고, 실제로 문제가 발생해도 사전에 위험을 보고했기 때문에 부담이 덜 합니다. 위험보고는 프로젝트 관리자가 체계적으로 프로젝트 관리하고 있다는 역량을 경영층에게 어필할 수 있는 좋은 기회입니다.
프로젝트 위험보고의 유형과 결과를 정리하면 다음과 같습니다.
프로젝트 위험보고의 유형과 결과
- 위험의 깃발은 빨리 강하게 흔드는 것이 좋습니다.
위험을 보고 하기로 결심했다면 약간 과장하는 것이 좋습니다. 그래야 경영층이 위험내용을 인지할 수 있습니다. 보험 약관처럼 눈에 잘 띄지 않게 보고서의 구석에 위험을 기술 한 뒤, 나중에 문제가 발생했을 때 예전에 보고한 위험이라고 주장하시면 안 됩니다. 경영층이 위험을 위험으로 인지할 수 있게 해야 합니다. 따라서 위험보고를 다른 보고서에 포함하는 것은 바람직하지 않습니다. 프로젝트 관리자는 위험하다고 보고했지만, 해당 문서를 읽는 경영층은 위험으로 인지하기 힘들기 때문입니다. 대면이 아닌 메일로 의사소통 하는 경우라면 특히 유의해야 합니다. ‘과장’이라는 표현을 사용했는데 거짓 보고를 하라는 의미가 아니라 ‘축소’하여 보고하지 말고 경영층이 위험내용을 정확하게 인지할 수 있게 하라는 의미입니다.
경영층에게 위험을 보고하기로 결정했다면 해당 위험이 경영층의 머릿속에서 오래 남아 있도록 해야 합니다. 곧 잊힐 위험보고를 하면 안 됩니다.
- 모든 위험에 대응할 수 없습니다.
식별된 모든 위험에 대응할 수 없습니다. 만일 그런 시도를 한다면 그것이 위험합니다. 식별한 위험에 대해선 우선순위를 부여하여 신중하게 대응할 위험과 아닌 위험을 구분해야 합니다. 식별된 위험에 1, 2, 3과 같은 우선순위를 부여하라는 말은 아닙니다. 그런 우선순위 부여는 평가가 복잡할 뿐 아니라 활용할 방법도 없습니다. 2개 또는 3개의 등급으로 위험을 관리하면 충분합니다. 예를 들어 3개 등급으로 관리한다면 1등급은 경영층과 공유할 위험, 2등급은 프로젝트에서 대응계획을 수립할 위험, 3등급은 별도 조치를 하지 않을 위험으로 구분하시면 됩니다. 위험등급을 평가하는 기준은 ‘위험의 발생 가능성’과 ‘위험이 프로젝트에 미치는 영향력’입니다. 발생할 가능성이 높고 프로젝트에 미치는 영향력이 클수록 위험의 심각도는 커집니다. 위험의 심각도를 계량화하려면 발생가능성과 영향력을 5점 척도로 계산하여 곱하거나 더한 점수를 활용하시면 됩니다. 위험 발생가능성과 영향력의 5점 척도를 활용하여 위험등급을 구분하는 예는 다음과 같습니다.
위험 발생가능성과 영향력을 활용한 위험등급 구분 예
- 위험 대응계획을 수립할 때 다음에 유의해야 합니다.
• 비용 대비 효율적이어야 합니다.
위험의 심각도를 고려하여 대응계획을 수립하고 모니터링 활동에 자원(예산, 일정)을 할당해야 합니다. 위험관리를 수행하기 위해 또 다른 위험을 만들면 안 됩니다.
• 대응계획수립 시기를 놓쳐서는 안 됩니다.
위험의 심각도가 커지기 전에 대응계획을 수립하고 조치해야 합니다.
• 실현할 수 있는 현실적인 계획이어야 합니다.
실행을 염두에 두지 않고 경영층에게 보여주기 식의 의욕적인 계획을 수립하는 것은 금물입니다. 실행 가능한 계획을 수립해야 합니다.
• 위험 대응계획에 대해서 이해관계자들의 합의를 얻어야 합니다.
대응계획의 실행력을 높이기 위해서는 위험을 식별·분석할 때뿐 아니라 대응계획을 수립할 때에도 이해관계자들을 참여시켜 공감대를 확보해야 합니다.
- 위험 대응전략의 유형을 고려하여 대응계획을 수립하시기 바랍니다.
위험대응 전략의 유형 또는 위험 대응전략 수립 시 접근방법은 다음과 같습니다.
• 식별된 위험의 정보가 충분하지 않으면 의사결정을 미룹니다.
위험에 대한 정보가 충분히 파악되지 않은 상태에서 성급하게 위험에 대응하는 것은 설익은 과일을 따거나 충분히 곪지 않은 상처를 치료하는 것과 같습니다. 위험에 대한 분석정보가 부족하면 대응계획수립이 가능할 때까지 별도의 목록으로만 관리하며 지켜봅니다.
• 심각한 위험은 발생 가능성을 원천적으로 제거합니다.
심각한 위험은 계획 자체를 변경하여 발생 가능성을 없애는 것입니다. 특정 아키텍처로 인한 시스템 다운의 위험이 있다면 기술 아키텍처를 바꾸어 시스템 다운의 위험을 원천적으로 제거하는 것이 이에 해당합니다. SI 프로젝트에서 제안참여를 안 하는 것도 발생가능성을 제거하는 방법입니다. 이러한 위험을 ‘show stopper’라고도 합니다.
• 프로젝트 팀에서 위험의 발생가능성이나 영향력을 줄입니다.
위험의 발생 가능성이나 영향력을 줄여서, 허용할 수 있는 수준으로 위험의 심각도를 낮추는 방법으로 위험완화라고 합니다. 위험완화는 위험대응 비용이 커지기 전에 대응하는 것이 중요합니다. ‘테스트 강화’ ‘적격 업체 선정’과 같이 발생 가능성과 영향력을 동시에 줄이는 방법과 ‘시스템 장애 발생을 대비한 백업 준비’와 같이 영향력만 줄이는 방법이 있습니다.
• 일정 수준 이하의 위험은 수용합니다.
위험의 심각도가 일정 수준 이하라면 별도의 대응계획을 수립하지 않고, 위험이 실제로 발생할 때 대응합니다.
• 위험 대응을 외부 전문가에게 위임할 수 있습니다.
프로젝트 팀 외부 전문가가 위험에 대응하는 것이 더 효과적이라면 위험예방 또는 영향력 최소화를 위한 조치를 외부 전문조직에 위임합니다. 보험이 대표적인 유형입니다.
• 경영층에서 대응해야 하는 위험도 있습니다.
프로젝트 관리자의 통제범위를 벗어나 경영층이 대응해야 하는 위험도 있습니다. 이러한 위험은 식별되는 즉시 경영층에게 보고하여 경영층이 대응하도록 해야 합니다.
- 위험은 변하기 때문에 지속적으로 모니터링해야 합니다.
프로젝트 위험은 프로젝트와 마찬가지로 시간에 따라 상황에 따라 역동적으로 변합니다. 따라서 위험관리는 1회성의 활동이 아니라 프로젝트 착수부터 종료까지 지속적으로 수행하는 것이 바람직합니다. 위험을 모니터링하고 통제할 때 유의할 사항은 다음과 같습니다.
• 위험 대응계획의 이행 여부를 모니터링해야 합니다.
아무리 좋은 대응계획도 실행하지 않으면 의미가 없습니다. 복잡하고 바쁜 프로젝트 상황에서는 계획만 수립하고 실행을 소홀히 하기 쉽기 때문에 위험 대응계획을 이행하는지 정기적으로 모니터링하는 것이 바람직합니다.
• 위험 대응계획의 효과를 파악해야 합니다.
위험 대응계획은 질병에 비유하면 처방입니다. 처방대로 이행한 뒤에는 치료가 잘 되는지 파악해야 하듯이 위험도 마찬가지입니다. 위험 대응계획의 효과를 파악해야 합니다. 발생 가능성이나 영향력이 줄어들지 않거나 오히려 늘어나고 있으면 대응계획이 잘못되었다는 의미이므로, 새로운 대응계획수립을 검토해야 합니다.
• 신규 위험의 발생 여부도 모니터링해야 합니다.
위험식별은 프로젝트 착수 때 한 번만 하는 것이 아닙니다. 언제든지 새로운 위험이 발생할 수 있기 때문에 지속적으로 신규 위험을 모니터링해야 합니다.
• 합병위험 또는 파생위험도 고려해야 합니다.
신규 위험을 식별하는 경우 기존의 위험과 합치면 또 다른 합병위험이 있을 수도 있습니다. 파트너사의 재무상태가 좋지 않은 상태에서 파트서와 관련된 솔루션의 위험이 있다면 두 개의 위험은 합병위험이 됩니다. 파생위험은 위험을 조치하는 과정에서 또 다른 위험이 발생하는 것을 의미합니다. 요구사항의 불확실성을 관리하기 위해 팀원이 익숙하지 않은 애자일 방법론을 사용하는 것이 파생위험의 예입니다.
https://brunch.co.kr/@kbhpmp/160
