Project는 유일성(Unique) / 가정(Assumption)이라는 특성에 의해 점진적 구체화(Progressive Elaboration) 특성이 있고, Unique / Assumption은 프로젝트 전반에 걸쳐 Risk Management를 통해 통제되어야 한다.
=> 성공적 프로젝트를 위해!
* 기획
11,1 위험 관리 기획: 리스크 관리 방법을 결정하는 프로세스 이며, 리스크 관리를 위한 용인 가능한(합의된) 수준을 설정.
11.1.1 Input
1) 범위 기술서
2) 원가 관리 계획서
3) 일정 관리 계획서
4) 의사소통 관리 계획서
5) EEF 6) OPA
* 효용이론(Utility Theory): 고객이 위험에 대해 반응하는 척도가 다르기 때문에 위험 계획 수립시 이를 고려해야 함.
<- 의사 결정 시, 아래와 같은 고객의 유형에 따라 리스크 대응 방안이 달라진다.
1. Risk Seeker
2. Risk Natual
3. Risk Avoider
11.1.2 Tool & Technique
1) 기획 회의 및 분석: 프로젝트 팀은 리스크 관리 계획을 개발하기 위해 관련된 모든 사람이 참여한 계획 수립회의를 개최.
11.1.3 Output
1) 위험 관리 계획서
- 방법론: 리스크 관리 접근법 / 도구 / 데이터 원천을 정의
- 역할 / 책임: 관련된 모든 이해관계자의 책임 / 역할 명시.
- 예산책정: 프로젝트 리스크 관리를 위한 예산 수립(Reserve)
- 시기: 프로젝트 Life Cycle 동안, 언제 Risk Mgt Process가 실행될 것인가를 정의 <- 의사결정에 영향을 미칠 수 있도록 충분히 일찍 개발되어야 하며, 의사결정은 프로젝트 실행동안 정기적으로 재점검해야 함.
- 확률/영향 매트릭스: 리스크 확률과 영향 정의
- 수행된 이해관계자 허용한도(임계치): 프로젝트 팀이 리스크 대응 계획 실행의 효과성을 측정하는 표준(잔존 위험)
- 보고형식
11.2 위험 식별: 어떤 리스크가 프로젝트에 영향을 주는지 식별하고, 문서화 하는 프로세스.
11.2.1 Input
1) 리스크 관리 계획서
2) 범위 기준선
3) 일정 관리 계획서 4) 활동 기간 산정치
5) 원가 관리 계획서 6) 활동 원가 산정치
7) 품질 관리 계획서
8) 프로젝트 문서
9) 이해관계자 등록부
10) EEF(상용 데이터 베이스)
11) OPA(실제 프로젝트 파일) - lesson learned.
* Risk 식별시 신뢰도가 높은 순서?
: 프로젝트 파일(교훈) > 상용 DB > 프로젝트 팀원의 지식(때문에, 팀원에게 문서 검토를 지시함.)
11.2.2 Tool & Technique
1) 문서 검토
2) 가정사항 분석(Assumption)
3) 전문가 판단
4) 정보 수집 방법
- 브레인스토밍: 리스크 원인을 아이디어로 산출하고 유형별로 범주화 하여 정의를 구체화 한다.
- 델파이 기법: 설문지로 프로젝트 리스크의 아이디어를 구한 후, 답변서를 전문가에게 회답하여 공통된 의견 도출 / 수렴.
- 인터뷰: 경험있는 PM/해당 분야 전문가들과 면담하여 Risk 식별
5) 정보 목록 분석(CheckList)
: 신속/단순한 리스크 식별 가능 <- 모든 Risk를 포함하는 점검 목록을 개발하는 것은 불가능. 사용자들이 Risk를 목록 상의 내용으로 제한하는 경향이 있음.
=> 때문에 프로젝트 / 단계 종료 시 OPA중 반드시 갱신해야 하는 것은? Risk Check List.
* Risk 식별 시 가장 유용한 문서는? WBS < WBS 사전.
11.2.3 Output
1) 위험 등록부(Risk Register)
- 식별된 리스크 목록: 근본 원인 / 불확실한 가정에 의해 식별된 ㄹ기스크에 대해 기술한다.
- 가능한 대응 목록: 식별된 리스크에 대한 잠재적 대응은 Risk를 식별하는 과정에 도출 될 수 있다.
-> 대응 방법이 식별된 Risk는 이 정보가 대응 계획 수립시 유용하게 사용된다.
11.3 정성적 위험 분석: 식별된 Risk에 대해, 프로젝트 성공에 미치는 영향력의 우선순위를 결정하는 프로세스.
- 식별된 Risk의 조건 / Risk의 정성적 분석을 통해 우선순위를 결정 한다. =>일반적으로 Risk 식별과 동시에 실행된다.
11.3.1 Input
1) 위험 등록부
2) 리스크 관리 계획서: 리스크 관리 수행을 위한 역할 / 책임, 예산 / 리스크 관리, Risk 확률 및 영향 정의. 리스크 허용한도의 논의를 위한 이해관계자 의견을 포함.
3) 프로젝트 범위 계획서: 프로젝트에 대한 일반적인 제약 / 고려사항이 있음으로 정성적 위험 분석 시 유용한 도구가 된다.
4) OPA
11.3.2 Tool & Technique
1) 리스크 영향 - 확률 평가.
- 리스크 확률(Risk Probability): 리스크가 발생할 가능성.
- 리스크 결과(Risk Consequency): 리스크가 발생할 경우 프로젝트 목적에 미치는 영향(Impact = Consequencies)
* 리스크 결과는 리스크 확률 * 리스크 영향이 아니다.
: 리스크에 대해 영향/확률 평가는 관리해야 하는 리스크의 우선순위 식별 시 도움이 된다.
2) 리스크 영향 - 확률 매트릭스
: 리스크 영향-확률 평가로 얻어진 결과를 매트릭스로 기술, 영향/확률로 평가된 위험들은 리스크 확률 척도 / 리스크 영향 척도로 분류된다.
3) 리스크 자료의 품질 평가: 낮은 품질의 데이터는 정성적 분석의 대상이 되지 않는다. - 리스크의 위험이 크지 않은 경우.
-> 위험 등록부의 Watch List영역에 체크를 한다.
* Risk Management 시 PM은 범위 / 일정 / 비용 / 품질에 대해 동등하게 고려해야 한다.
-> 특별한 우선순위는 없지만, 가장 중요하게 고려해야 되는 부분은 품질이다. <- 품질 실패는 고객이 인수 거부의 결과를 얻기 때문.
11.3.3 Output
1) 리스크 등록부 갱신: 리스크 우선순위 목록 / 낮은 우선 순위(Watch List)를 리스크 등록부 추가.
11.4 정량적 위험 분석: Risk의 확률/결과(Probability/Impact)를 측정하여, 프로젝트 목적에 미치는 시사점(영향요소)를 산정 및 수치화 하는 프로세스.
11.4.1 Input
1) 위험 등록부
2) 리스크 관리 계획서
3) 원가 관리 계획서
4) 일정 관리 계획서
5) OPA
11.4.2 Tool & Technique
1) 데이터 수집 및 표현 기법 - PERT 사용.
2) 정성적 리스크 분석 / 모델링 기법
(1) 민감도 분석(Sensitivity Analysis): 어떤 리스크가 프로젝트에 가장 잠재적 영향을 미칠 것인지 판단.
- 다른 프로젝트 요소들이 모두 기준선의 값으로 고정되었다고 가정할 경우 어느 특정 요소가 변경되는 경우 전체 프로젝트에 미치는 영향력 분석 (예: Tornado Diagram)
-> 장점: 신속하다.
-> 단점: 정확도가 낮다.
=> 범위 / 일정 / 원가는 영향이 없다고 가정(고점 시킴)하고, 품질만 변한다고 가정하여 영향도를 평가하는 방법.
(2) EVM(금전적 기대값 분석) - 불확실성을 전제로 하는 분석 기법
- 의사 결정 나무 분석: 모든 불확실성이 계량화 될 경우, 어떤 의사결정이 가장 큰 기대값을 갖는지 보여줌.
(3) 모델링 / 모의 실험(Modeling / Simulation) - 가장 많이 사용하는 기법은 몬테카를로 기법
- 원가 리스크를 평가 하기 위해서는: 원가 산정치를 Input으로 사용.
- 일정 리스크를 평가 하기 위해서는: 일정 네트웍(PDM) + 기간 산정치(Duration Estmating)을 Input으로 사용.
11.4.3 Output
1) 리스크 등록부 갱신
11.5 위험 대응 기획: 긍정적인 리스크는 향상 시키고, 부정적인 리스크는 줄위기 위한 절차와 기법을 개발
11.5.1 Input
1) 프로젝트 관리 계획서: 정성/정략 분석된 자료가 갱신된 등록부
- 리스크 식별 시 해당 리스크의 근본원인 / 잠재적 대응 목록 / 리스크 책임자 포함.
2) 리스크 관리 계획서: 역할 / 책임, 리스크 분석 정의, 리스크 한계선
11.5.2 Tool & Technique
1) 부정적인 리스크 / 위협에 대응 전략
(1) 회피(Avoidance): 리스크/리스크 발생조건을 제거하거나 프로젝트 계획을 변경하여 "원인 제거".
- 프로젝트의 리스크는 제거할 수 없지만, 일부 특정 리스크는 회피할 수 있다. 예) 프로젝트 예산이 10억, 위험 대응 비용이 9억이라면 Risk Mgt하지 않고 계획 변경을 하는 것이 유리하다.
(2) 전가(Transfer): 리스크의 결과를 대응의 소유권과 함께 제 삼자에게 이전시키는 노력, 리스크 전가는 단지 다른 당사자에게 리스크 관리의 책임을 이전하는 것이지, 리스크를 제거하는 것은 아니다. 예) 보험 / 이행보증 / 사후 보증 / 보장 등.
(3) 완화(Mitigation): 부정적 리스크 사건의 확률 / 결과를 용인 가능한 임계점까지 절감하고자 하는 노력. 리스크 발생의 확률 / 영향을 절감하기 위한 조치는 발생 이후보다는 사전에 취하는 것이 효과적.
(4) 수용(Acceptance): 리스크를 다루기 위한 프로젝트 계획 변경을 하지 않거나, 대응 전략을 찾지 못하는 경우.
- 적극적 수용(Active Acceptance): 돌발 상황 계획(Contingency Plan) 포함. - New System 오픈 시, 장애 발생을 대비하여 Backup 계획 수립.
- 소극적 수용(Passive Acceptance): 아무 조치도 하지 않는다. 예) 리스크 자체는 500만원이고 해결을 위한 예비비는 1000만원인 경우.
2) 긍적적인 리스크 / 기회 대응 전략
(1) 활용(Exploit): 프로젝트에 유용한 자원을 보다 많이 배정하여 더 좋은 품질을 제공 / 완료 기간 단축(Crashing / Pre-Assignment)
(2) 공유(Share): "기회관리"라는 명백한 목적하에 리스크 공유 협력 관계 / 팀 / 제휴회사 체결
(3) 증대(Enhance): 긍정 기회의 "규모"를 변경
(4) 수용(Acceptance): 부정 리스크 위협 대응 전략의 Acceptance와 동일
3) 우발적 대응 전략: 일부 대응책은 특정 사건이 발생하는 경우에만 사용하도록 설계된다.
11.5.3 Output
1) 리스크 등록부 갱신 - 리스크 대응책을 포함하여 갱신.
2) 리스크 관련 계약 결정 사항 - 부정적인 리스크 / 위험의 대응 전략 중 Transfer를 선택한 경우.
3) 프로젝트 관리 계획서 / 문서 갱신
* 감시 및 통제
11.6 위험 감시 및 통제: 잔여 리스크(잔존 리스크:Residual Rsik)를 감시하고, 1) 신규 리스크를 식별하여, 리스크 완화 계획을 실행하고, 2) 프로젝트 수명 주기 전체에 걸친 효과를 평가하는 프로세스.
11.6.1 Input
1) 리스크 등록부
2) 프로젝트 관리 계획서
3) 작업 성과 정보
4) OPA
11.6.2 Tool & Technique
1) 리스크 재평가: 프로젝트 내부 참여자가 개선을 목적으로 수시로 비공식적으로 행함.
2) 리스크 감사: 외부 제 3자가 적발을 목적으로 공식적으로 정기적으로 수행.
3) 차이 / 추세 분석
4) 기술적 성과 측정.
5) 예비 분석
6) 현황 미팅
11.6.3 Output
1) 리스크 등록부 갱신.
2) 프로젝트 관리 계획서 갱신.
3) 작업 성과 정보(시정 조치 / 예방조치)
4) 성과 보고서
5) 프로젝트 문서 갱신
=> 성공적 프로젝트를 위해!
| * 보충 이론 * Risk의 3요소. 1. Event: 위험이 발생할 수 있는 상황(징후) <- Risk 식별시 고려. => Event = 리스크 발생확률(Probability) * 영향(Impact) 2. Probability(=likelihood / outcome: 가능성/확률): 불확실성 - 아직 발생하지 않음 <- Risk 정성/정량 분석 시 사용. 3. Impact(=Consequences: 영향도): 프로젝트에 영향을 줌 <- Risk 정성/정량 분석 시 사용. * Project Risk 유형  * Risk에 대한 일반적인 상황 1. 모든 Risk를 대응해야 한다? <- X(불가능) -> 중요한 위험을 대비해야 한다(효용성 측면) 2. Risk Management의 목적은 Risk를 제거하는 것이다? <-X -> Risk의 관리의 목적은 Risk를 합의된(용인 가능한: <- 잔존 위험(Residual Risk)) 수준으로 낮추는 것이 목적이다. 대응 계획에 의해 집행되어 해소된 Risk에 의해 합의된 수준까지 낮춰졌지만, 여전히 남아 있는 잔존위험이 남아 있음으로 지속적으로 관리 / 모니터링 되어야 한다. 3. 모든 위험(Risk)는 상호 연계된다. 예) 일정 지연 Risk가 증가하면 -> CCB를 통해 Buffer Activity 관리 -> 예비비 여유 확인 -> Fast Tracking을 하는 경우 Rework이 증가하고, Quality가 낮아짐. 즉, 일정 지연이라는 Risk로 인해 파생위험이 나타남. |
* 기획
11,1 위험 관리 기획: 리스크 관리 방법을 결정하는 프로세스 이며, 리스크 관리를 위한 용인 가능한(합의된) 수준을 설정.
11.1.1 Input
1) 범위 기술서
2) 원가 관리 계획서
3) 일정 관리 계획서
4) 의사소통 관리 계획서
5) EEF 6) OPA
* 효용이론(Utility Theory): 고객이 위험에 대해 반응하는 척도가 다르기 때문에 위험 계획 수립시 이를 고려해야 함.
<- 의사 결정 시, 아래와 같은 고객의 유형에 따라 리스크 대응 방안이 달라진다.
1. Risk Seeker
2. Risk Natual
3. Risk Avoider
11.1.2 Tool & Technique
1) 기획 회의 및 분석: 프로젝트 팀은 리스크 관리 계획을 개발하기 위해 관련된 모든 사람이 참여한 계획 수립회의를 개최.
11.1.3 Output
1) 위험 관리 계획서
- 방법론: 리스크 관리 접근법 / 도구 / 데이터 원천을 정의
- 역할 / 책임: 관련된 모든 이해관계자의 책임 / 역할 명시.
- 예산책정: 프로젝트 리스크 관리를 위한 예산 수립(Reserve)
- 시기: 프로젝트 Life Cycle 동안, 언제 Risk Mgt Process가 실행될 것인가를 정의 <- 의사결정에 영향을 미칠 수 있도록 충분히 일찍 개발되어야 하며, 의사결정은 프로젝트 실행동안 정기적으로 재점검해야 함.
- 확률/영향 매트릭스: 리스크 확률과 영향 정의
- 수행된 이해관계자 허용한도(임계치): 프로젝트 팀이 리스크 대응 계획 실행의 효과성을 측정하는 표준(잔존 위험)
- 보고형식
| * 리스크 분류 체계(RBS: Risk Breakdown Structure) 1) Project Management Risk: 9개 지식영역에서 발생하는 리스크. 2) Organizational Risk: 프로젝트 팀간의 우수 인력을 확보하기 위한 Risk <- 협상으로 해결. 3) Technical Risk: 프로젝트 수행팀이 실행 중 발생하는 기술적 Risk -> Outsourcing을 통해 해결 가능. 4) Exteral Risk: 외부 리스크 - 국제 프로젝트 시 환률 폭등 / 테러. |
11.2 위험 식별: 어떤 리스크가 프로젝트에 영향을 주는지 식별하고, 문서화 하는 프로세스.
11.2.1 Input
1) 리스크 관리 계획서
2) 범위 기준선
3) 일정 관리 계획서 4) 활동 기간 산정치
5) 원가 관리 계획서 6) 활동 원가 산정치
7) 품질 관리 계획서
8) 프로젝트 문서
9) 이해관계자 등록부
10) EEF(상용 데이터 베이스)
11) OPA(실제 프로젝트 파일) - lesson learned.
* Risk 식별시 신뢰도가 높은 순서?
: 프로젝트 파일(교훈) > 상용 DB > 프로젝트 팀원의 지식(때문에, 팀원에게 문서 검토를 지시함.)
11.2.2 Tool & Technique
1) 문서 검토
2) 가정사항 분석(Assumption)
3) 전문가 판단
4) 정보 수집 방법
- 브레인스토밍: 리스크 원인을 아이디어로 산출하고 유형별로 범주화 하여 정의를 구체화 한다.
- 델파이 기법: 설문지로 프로젝트 리스크의 아이디어를 구한 후, 답변서를 전문가에게 회답하여 공통된 의견 도출 / 수렴.
- 인터뷰: 경험있는 PM/해당 분야 전문가들과 면담하여 Risk 식별
5) 정보 목록 분석(CheckList)
: 신속/단순한 리스크 식별 가능 <- 모든 Risk를 포함하는 점검 목록을 개발하는 것은 불가능. 사용자들이 Risk를 목록 상의 내용으로 제한하는 경향이 있음.
=> 때문에 프로젝트 / 단계 종료 시 OPA중 반드시 갱신해야 하는 것은? Risk Check List.
* Risk 식별 시 가장 유용한 문서는? WBS < WBS 사전.
11.2.3 Output
1) 위험 등록부(Risk Register)
- 식별된 리스크 목록: 근본 원인 / 불확실한 가정에 의해 식별된 ㄹ기스크에 대해 기술한다.
- 가능한 대응 목록: 식별된 리스크에 대한 잠재적 대응은 Risk를 식별하는 과정에 도출 될 수 있다.
-> 대응 방법이 식별된 Risk는 이 정보가 대응 계획 수립시 유용하게 사용된다.
11.3 정성적 위험 분석: 식별된 Risk에 대해, 프로젝트 성공에 미치는 영향력의 우선순위를 결정하는 프로세스.
- 식별된 Risk의 조건 / Risk의 정성적 분석을 통해 우선순위를 결정 한다. =>일반적으로 Risk 식별과 동시에 실행된다.
11.3.1 Input
1) 위험 등록부
2) 리스크 관리 계획서: 리스크 관리 수행을 위한 역할 / 책임, 예산 / 리스크 관리, Risk 확률 및 영향 정의. 리스크 허용한도의 논의를 위한 이해관계자 의견을 포함.
3) 프로젝트 범위 계획서: 프로젝트에 대한 일반적인 제약 / 고려사항이 있음으로 정성적 위험 분석 시 유용한 도구가 된다.
4) OPA
11.3.2 Tool & Technique
1) 리스크 영향 - 확률 평가.
- 리스크 확률(Risk Probability): 리스크가 발생할 가능성.
- 리스크 결과(Risk Consequency): 리스크가 발생할 경우 프로젝트 목적에 미치는 영향(Impact = Consequencies)
* 리스크 결과는 리스크 확률 * 리스크 영향이 아니다.
: 리스크에 대해 영향/확률 평가는 관리해야 하는 리스크의 우선순위 식별 시 도움이 된다.
2) 리스크 영향 - 확률 매트릭스
: 리스크 영향-확률 평가로 얻어진 결과를 매트릭스로 기술, 영향/확률로 평가된 위험들은 리스크 확률 척도 / 리스크 영향 척도로 분류된다.
3) 리스크 자료의 품질 평가: 낮은 품질의 데이터는 정성적 분석의 대상이 되지 않는다. - 리스크의 위험이 크지 않은 경우.
-> 위험 등록부의 Watch List영역에 체크를 한다.
* Risk Management 시 PM은 범위 / 일정 / 비용 / 품질에 대해 동등하게 고려해야 한다.
-> 특별한 우선순위는 없지만, 가장 중요하게 고려해야 되는 부분은 품질이다. <- 품질 실패는 고객이 인수 거부의 결과를 얻기 때문.
11.3.3 Output
1) 리스크 등록부 갱신: 리스크 우선순위 목록 / 낮은 우선 순위(Watch List)를 리스크 등록부 추가.
11.4 정량적 위험 분석: Risk의 확률/결과(Probability/Impact)를 측정하여, 프로젝트 목적에 미치는 시사점(영향요소)를 산정 및 수치화 하는 프로세스.
11.4.1 Input
1) 위험 등록부
2) 리스크 관리 계획서
3) 원가 관리 계획서
4) 일정 관리 계획서
5) OPA
11.4.2 Tool & Technique
1) 데이터 수집 및 표현 기법 - PERT 사용.
2) 정성적 리스크 분석 / 모델링 기법
(1) 민감도 분석(Sensitivity Analysis): 어떤 리스크가 프로젝트에 가장 잠재적 영향을 미칠 것인지 판단.
- 다른 프로젝트 요소들이 모두 기준선의 값으로 고정되었다고 가정할 경우 어느 특정 요소가 변경되는 경우 전체 프로젝트에 미치는 영향력 분석 (예: Tornado Diagram)
-> 장점: 신속하다.
-> 단점: 정확도가 낮다.
=> 범위 / 일정 / 원가는 영향이 없다고 가정(고점 시킴)하고, 품질만 변한다고 가정하여 영향도를 평가하는 방법.
(2) EVM(금전적 기대값 분석) - 불확실성을 전제로 하는 분석 기법
- 의사 결정 나무 분석: 모든 불확실성이 계량화 될 경우, 어떤 의사결정이 가장 큰 기대값을 갖는지 보여줌.
(3) 모델링 / 모의 실험(Modeling / Simulation) - 가장 많이 사용하는 기법은 몬테카를로 기법
- 원가 리스크를 평가 하기 위해서는: 원가 산정치를 Input으로 사용.
- 일정 리스크를 평가 하기 위해서는: 일정 네트웍(PDM) + 기간 산정치(Duration Estmating)을 Input으로 사용.
11.4.3 Output
1) 리스크 등록부 갱신
11.5 위험 대응 기획: 긍정적인 리스크는 향상 시키고, 부정적인 리스크는 줄위기 위한 절차와 기법을 개발
11.5.1 Input
1) 프로젝트 관리 계획서: 정성/정략 분석된 자료가 갱신된 등록부
- 리스크 식별 시 해당 리스크의 근본원인 / 잠재적 대응 목록 / 리스크 책임자 포함.
2) 리스크 관리 계획서: 역할 / 책임, 리스크 분석 정의, 리스크 한계선
11.5.2 Tool & Technique
1) 부정적인 리스크 / 위협에 대응 전략
(1) 회피(Avoidance): 리스크/리스크 발생조건을 제거하거나 프로젝트 계획을 변경하여 "원인 제거".
- 프로젝트의 리스크는 제거할 수 없지만, 일부 특정 리스크는 회피할 수 있다. 예) 프로젝트 예산이 10억, 위험 대응 비용이 9억이라면 Risk Mgt하지 않고 계획 변경을 하는 것이 유리하다.
(2) 전가(Transfer): 리스크의 결과를 대응의 소유권과 함께 제 삼자에게 이전시키는 노력, 리스크 전가는 단지 다른 당사자에게 리스크 관리의 책임을 이전하는 것이지, 리스크를 제거하는 것은 아니다. 예) 보험 / 이행보증 / 사후 보증 / 보장 등.
(3) 완화(Mitigation): 부정적 리스크 사건의 확률 / 결과를 용인 가능한 임계점까지 절감하고자 하는 노력. 리스크 발생의 확률 / 영향을 절감하기 위한 조치는 발생 이후보다는 사전에 취하는 것이 효과적.
(4) 수용(Acceptance): 리스크를 다루기 위한 프로젝트 계획 변경을 하지 않거나, 대응 전략을 찾지 못하는 경우.
- 적극적 수용(Active Acceptance): 돌발 상황 계획(Contingency Plan) 포함. - New System 오픈 시, 장애 발생을 대비하여 Backup 계획 수립.
- 소극적 수용(Passive Acceptance): 아무 조치도 하지 않는다. 예) 리스크 자체는 500만원이고 해결을 위한 예비비는 1000만원인 경우.
2) 긍적적인 리스크 / 기회 대응 전략
(1) 활용(Exploit): 프로젝트에 유용한 자원을 보다 많이 배정하여 더 좋은 품질을 제공 / 완료 기간 단축(Crashing / Pre-Assignment)
(2) 공유(Share): "기회관리"라는 명백한 목적하에 리스크 공유 협력 관계 / 팀 / 제휴회사 체결
(3) 증대(Enhance): 긍정 기회의 "규모"를 변경
(4) 수용(Acceptance): 부정 리스크 위협 대응 전략의 Acceptance와 동일
3) 우발적 대응 전략: 일부 대응책은 특정 사건이 발생하는 경우에만 사용하도록 설계된다.
11.5.3 Output
1) 리스크 등록부 갱신 - 리스크 대응책을 포함하여 갱신.
2) 리스크 관련 계약 결정 사항 - 부정적인 리스크 / 위험의 대응 전략 중 Transfer를 선택한 경우.
3) 프로젝트 관리 계획서 / 문서 갱신
* 감시 및 통제
11.6 위험 감시 및 통제: 잔여 리스크(잔존 리스크:Residual Rsik)를 감시하고, 1) 신규 리스크를 식별하여, 리스크 완화 계획을 실행하고, 2) 프로젝트 수명 주기 전체에 걸친 효과를 평가하는 프로세스.
11.6.1 Input
1) 리스크 등록부
2) 프로젝트 관리 계획서
3) 작업 성과 정보
4) OPA
11.6.2 Tool & Technique
1) 리스크 재평가: 프로젝트 내부 참여자가 개선을 목적으로 수시로 비공식적으로 행함.
2) 리스크 감사: 외부 제 3자가 적발을 목적으로 공식적으로 정기적으로 수행.
3) 차이 / 추세 분석
4) 기술적 성과 측정.
5) 예비 분석
6) 현황 미팅
11.6.3 Output
1) 리스크 등록부 갱신.
2) 프로젝트 관리 계획서 갱신.
3) 작업 성과 정보(시정 조치 / 예방조치)
4) 성과 보고서
5) 프로젝트 문서 갱신
'PMP' 카테고리의 다른 글
| PMP - 전문가 책임. (0) | 2010.12.23 |
|---|---|
| PMP(tmp) - 조달(Procurement) (0) | 2010.12.02 |
| PMP(tmp) - 의사소통(Communication) (0) | 2010.12.02 |
| PMP(tmp) - 인적 자원 (0) | 2010.12.02 |
| PMP(tmp) - 품질(Quality) (0) | 2010.12.02 |
