1. IT 프로젝트 성공의 제어판, 부정적 위험(Negative Risk) 관리의 개요
가. 부정적 위험(Negative Risk/위협)의 정의
프로젝트 목표(범위, 일정, 원가, 품질 등)에 부작용을 초래하는 불확실한 사건 또는 상태를 의미하며, PMBOK에서는 이를 '위협(Threat)'으로 정의함.
기술의 복잡성, 이해관계자의 대립, 요구사항 변동성 등으로 인해 IT 프로젝트에서 위험 관리는 단선적 처리가 아닌 지속적 수명주기 관리가 필수적임.
나. 위험(Risk)과 이슈(Issue)의 핵심 차이점
위험(Risk): 아직 발생하지 않은 미래의 불확실성 (확률적 개념 $\rightarrow$ 예방 및 완화 중심).
이슈(Issue): 이미 발생하여 프로젝트에 영향을 미치고 있는 현재의 현상 (확정적 개념 $\rightarrow$ 해결 및 에스컬레이션 중심).
2. IT 프로젝트 부정적 위험 관리 프로세스 및 정량·정성 분석
위험 관리는 일회성 활동이 아니며, 프로젝트 전반에 걸쳐 '식별 $\rightarrow$ 분석 $\rightarrow$ 대응 $\rightarrow$ 모니터링'의 통제 루프를 가진다.
가. 위험 관리 단계별 핵심 활동
| 단계 | 주요 활동 내용 | 활용 기법 / 산출물 |
| 1. 위험 관리 계획 | * 위험 관리의 접근 방법, 역할 및 책임을 정의 | 위험관리계획서 (Risk Management Plan) |
| 2. 위험 식별 | * 프로젝트에 영향을 줄 수 있는 위협 요소 도출 | 체크리스트, 브레인스토밍, RBS(위험분류구조) |
| 3. 정성적 분석 | * 식별된 위험의 우선순위 평가 | PI 매트릭스 (Probability & Impact Matrix) |
| 4. 정량적 분석 | * 위험이 미치는 영향을 수치적으로 계량화 | 의사결정나무(Decision Tree), 몬테카를로 시뮬레이션 |
| 5. 위험 대응 계획 | * 우선순위가 높은 위협에 대한 전략 수립 | 5대 대응 전략 (회피, 전가, 완화, 수용, 에스컬레이트) |
| 6. 위험 모니터링 | * 잔여 위험 및 2차 위험 감시, 대응 효과 평가 | 위험 통제, 위험 재평가, 위험 대장(Risk Register) |
3. PMBOK 기반 부정적 위험(위협)의 5대 대응 전략 및 IT 실무 사례
| 대응 전략 | 전략의 핵심 개념 | IT 프로젝트 실무 적용 사례 |
| 1. 회피 (Avoid) | * 위험 원인을 근본적으로 제거하거나 프로젝트 계획을 변경하여 위협을 완전히 배제하는 전략 | * 신기술 도입에 따른 리스크를 방지하기 위해, 검증된 안정적인 솔루션이나 프레임워크로 아키텍처 변경 * 위험도가 높은 특정 요구사항 기능을 범위에서 제외 |
| 2. 전가 (Transfer) | * 위험의 책임과 소유권을 제3자에게 넘겨 손실 비용을 대리 부담하게 하는 전략 (위험 자체를 제거하진 않음) | * 핵심 인프라 구축을 전문 아웃소싱 업체에 턴키(Turnkey) 계약으로 발주 * 데이터센터 화재 등 재해 대비를 위한 이행보증보험 또는 손해배상보험 가입 |
| 3. 완화 (Mitigate) | * 위험의 발생 확률이나 영향도를 프로젝트 허용 한계선 이하로 낮추기 위해 선제적 조치를 취하는 전략 | * 시스템 오픈 전 동시 접속자 폭주 위험을 낮추기 위해, 사전 성능 부하 테스트(Load Test) 수행 및 모의 훈련 반복 * 핵심 개발자 이탈에 대비한 백업 인력 풀 가동 |
| 4. 수용 (Accept) | * 위험을 인정하되 예산(예비비)이나 일정을 확보하여 사후에 대응하는 전략 * **적극적 수용(예비비 설정)**과 **소극적 수용(수수방관)**으로 분류 | * 오픈 직전 단순 UI 버그 발생 가능성에 대비해 프로젝트 관리 예비비(Management Reserve)나 우발 사태 예비비(Contingency Reserve) 편성 |
5. 에스컬레이트 (Escalate) | * 프로젝트 팀의 권한을 벗어나거나 상위 조직 차원에서 관리해야 하는 위험을 스폰서나 PMO로 이관하는 전략 | * 전사 ERP 구축 중 현업 부서 간의 극심한 이해관계 대립으로 의사결정이 마비될 때, 기업 최고경영진(CEO) 주관 위원회로 안건 상정 |
4. IT 프로젝트 위험 관리 성공을 위한 기술사적 제언
가. '위험 대장(Risk Register)'의 가시성 및 실시간 자산화
위험은 식별되는 즉시 위험 대장에 기록되어야 하며, 위험의 소유자(Risk Owner), 트리거(Trigger, 발생 징후), 대응 시나리오가 구체적으로 명시되어야 함.
프로젝트 종료 후 위험 대장은 조직 프로세스 자산(OPA)으로 이관되어 향후 유사 프로젝트의 예측 가능성을 높이는 기반 데이터로 활용해야 함.
나. 애자일(Agile) 환경에서의 위험 관리 패러다임 변화
전통적인 Waterfall 방식은 프로젝트 후반부에 위험이 집중(Risk Peak)되는 경향이 있음.
이를 극복하기 위해 매 스프린트마다 위험을 식별하는 'Risk-Adjusted Product Backlog(위험 조절 백업로그)' 개념을 도입하여, 가치가 높고 위험도가 높은 작업을 프로젝트 초기에 우선 해결하는 'Fast-Failure' 전략으로의 전환이 필요함.
댓글 없음:
댓글 쓰기