프로젝트 위험 등록부: 회의 녹음으로 만드는 템플릿과 예시

위험은 발생할 수 있고 문제는 이미 존재합니다

위험 등록부는 결과에 영향을 줄 수 있는 불확실성을 기록합니다. 무엇을 관찰하고, 미리 무엇을 하며, 언제 계획을 바꿀지 보여 줍니다.

“고객이 자료를 사흘 늦게 전달했다”는 문제입니다. “수요일까지 받지 못하면 금요일까지 검증을 못 할 수 있다”는 위험입니다. 서로 연관되지만 필요한 행동은 다릅니다. 여기서는 일반 프로젝트를 다루며 안전, 감사, 규제 관련 전문 등록부는 다루지 않습니다.

팀의 논의를 바탕으로 등록부 작성하기

1. 불확실성을 드러내는 말을 찾으세요

   “만약”, “~에 달려 있다”, “아직 모른다”, “제때 못 할 수 있다”를 찾으세요. 프로젝트의 어느 결과에 영향을 주는지 구체화합니다.

2. 세 부분으로 나눠 적으세요

   원인 또는 조건 → 가능한 사건 → 영향. “알렉세이가 위험이다”보다 “승인이 한 사람에게 달려 있다”가 원인을 더 잘 설명합니다.

3. 팀과 평가를 합의하세요

   발생 가능성과 영향을 따로 보세요. 소규모 프로젝트라면 정의가 분명한 정성 등급을 쓸 수 있습니다. 주관적 점수를 계산된 확률처럼 제시하지 마세요.

4. 관찰 담당자를 지정하세요

   담당자는 신호를 추적하고 정보를 모아 문제를 제기합니다. 모든 원인을 혼자 없앨 의무가 없으며 사건이 발생했다고 해서 책임을 추궁할 대상도 아닙니다.

5. 사건 전후의 대응을 적으세요

   예방은 가능성이나 영향을 낮춥니다. 대안은 정해진 조건에서 시작합니다. 각각의 실행 담당자와 제약을 명시하세요.

6. 다음 검토일을 정하세요

   중요한 시점이나 새 정보가 생길 때 기록을 확인하세요. 의존성이 없어졌거나 사건이 발생했거나 해당 단계가 끝났다는 등 종료 이유를 적으세요.

연동에 필요한 테스트 접근 권한

가상의 발언입니다. 공급자가 기한을 어길 것이라는 증거는 아닙니다. 위험을 등록하고 신청 상태를 따로 확인하세요.

근거가 부족해 “70%”라는 확률은 적지 않았습니다. 공급자가 답하면 평가를 보완할 수 있습니다. 신호의 날짜와 시간이 있으면 새 사실 없이 같은 걱정을 매번 되풀이하지 않아도 됩니다.

프로젝트가 바뀌면 등록부도 업데이트하세요

접근 권한을 받으면 실제로 작동하는지 확인하세요. “권한 준비 완료”라는 이메일만으로 의존성이 사라진 것은 아닙니다. 위험이 현실이 되면 현재 문제와 대안 실행에 연결하세요. 가능성이 낮아졌다면 이유를 남기세요.

등록부를 계속 활용하세요. 회의에서는 바뀐 항목, 다가오는 전환 조건, 담당자가 없는 위험을 논의합니다. 무엇을 새로 알았고, 평가가 어떻게 달라지며, 다음에 무엇을 할지 묻습니다. 추가 대책을 하지 않기로 했다면 담당자와 재검토 조건도 적습니다.

팀을 위한 기본 등록부

ID와 발견일:
프로젝트 목표 또는 단계:
[조건]이면 [사건]이 발생해 [영향]이 생길 수 있다.
출처: 녹음 / 타임코드 / 근거 문서:
발생 가능성과 근거:
영향과 근거:
관찰 담당자:
예방 조치, 실행 담당자, 기한:
대안 전환 신호:
대안과 승인자:
다음 검토일:
상태와 변경 이유:

• 조건을 확인할 수 있다.
• 불확실성이 분명히 드러난다.
• 누가 신호를 관찰하는지 명확하다.
• 다음 검토 날짜가 있다.