프리모템: 시작 전에 「이 프로젝트는 실패했다」고 가정하고 이유를 모으는 법

요지

착수 회의에서 「무엇이 잘못될 수 있을까요?」라고 물으면 조용해지기 쉽다. 계획을 막 세운 자리에서 그 계획의 약점을 말하기는 어렵기 때문이다. 질문을 바꾸면 분위기가 달라진다. 「1년 뒤, 이 프로젝트가 크게 실패했습니다. 왜 실패했을까요?」 이것이 프리모템(premortem)이다. 계획이 거의 정해졌지만 아직 바꿀 수 있는 때 한 시간이면 할 수 있다. 프리모템은 리스크를 식별하는 여러 방법 가운데 하나이고, 나온 것은 리스크 관리대장에 옮겨 계속 관리한다.

왜 「이미 실패했다」가 더 많은 리스크를 끌어내나

프리모템은 의사결정 연구자 Gary Klein이 2007년 Harvard Business Review에 짧은 글로 소개하며 널리 알려졌다. 이름은 일이 끝난 뒤 원인을 따지는 사후 검토(postmortem)를 거꾸로 돌린 것이다. PMBOK® 지침서에 나오는 기법은 아니지만, 지침서가 말하는 리스크 식별에 그대로 쓸 수 있다.

효과의 근거로 흔히 드는 것은 1989년 Mitchell, Russo, Pennington의 연구다. 사람들에게 어떤 일이 「일어날 수도 있다」고 묻기보다 「이미 일어났다」고 상상하게 하면 그 이유를 더 많이 떠올렸다. 다만 이 연구를 다시 읽은 해설에 따르면 연구가 잰 것은 떠올린 이유의 개수였고 그 이유가 맞았는지는 따지지 않았다. 그러니 프리모템이 리스크를 정확히 맞힌다고 말하기보다, 평소보다 많은 후보를 찾게 해 준다고 이해한다.

이유는 하나 더 있다. 「잘못될 수 있나」에 답하면 계획에 반대하는 사람이 된다. 「이미 실패했다」는 전제에서는 이유를 많이 찾는 사람이 일을 잘하는 사람이 된다. 「핵심 담당자가 이 일에 시간을 못 낼 것 같다」처럼 말하기 어려운 걱정이 이때 나온다.

한 가지 한계도 알아 둔다. 리스크에는 목표에 해가 되는 위협과 도움이 되는 기회가 모두 들어간다. 프리모템은 실패를 가정하므로 주로 위협을 끌어낸다. 기회는 따로 찾는다.

진행 순서

표는 가로로 밀어서 볼 수 있습니다.

단계	시간(권장)	하는 일
준비	5분	진행자가 계획 요점을 한 번 읽고, 「1년 뒤 이 프로젝트는 크게 실패했다」고 선언한다
각자 쓰기	10분	말하지 않고 각자 실패 이유를 적는다. 많을수록 좋다
돌아가며 말하기	15분	한 사람이 한 번에 하나씩, 아직 안 나온 이유를 말한다. 각자 적은 목록이 빌 때까지 돈다
분류하기	10분	비슷한 이유끼리 분류하고 이름을 붙인다
고르기	10분	일어날 만하고 피해가 큰 것을 3개에서 5개 고른다
대응과 담당	10분	고른 것마다 지금 할 대응 하나와 담당 한 명을 정한다

각자 쓰기를 먼저 하는 데는 이유가 있다. 처음부터 말로 하면 직급이 높은 사람이나 말을 잘하는 사람의 이유에 다른 사람의 생각이 끌려간다. 쓰다가 막히는 사람이 많으면 진행자가 기술, 일정, 사람, 외부 업체, 조직 안의 결정 같은 리스크 범주를 불러 준다. 범주가 생각의 실마리가 된다. 지침서는 미리 정해 둔 리스크 범주 목록을 프롬프트 목록이라 부른다. 여기 든 범주는 이 글에서 새로 든 예다.

좋은 실패 이유와 쓸모없는 실패 이유

가상의 예로, 한 회사가 6개월 동안 사내 업무 시스템을 새로 만드는 프로젝트를 시작한다고 하자.

표는 가로로 밀어서 볼 수 있습니다.

쓸모없는 이유	왜 쓸모없나	좋은 이유로 고치면
일정이 늦어졌다	결과일 뿐 원인이 없다	옛 시스템 데이터 정리가 늦어 이관 테스트를 두 번 미뤘다
소통이 부족했다	누가 무엇을 몰랐는지 없다	현업 부서가 화면 시안을 오픈 한 달 전에야 처음 봤다
운이 나빴다	대응할 수 없다	외부 개발사의 핵심 개발자가 중간에 다른 사업으로 빠졌다

좋은 이유에는 구체적인 일이 있고, 그 일을 막거나 줄일 무언가가 떠오른다. 진행자는 「일정이 늦어졌다」 같은 말이 나오면 「무엇 때문에 늦어졌을까요?」라고 한 번 더 묻는다. 막연한 걱정과 실제 리스크를 구분하는 것이 리스크 식별에서 할 일이다.

구분할 것이 하나 더 있다. 리스크는 아직 일어나지 않은 일이고, 이슈는 이미 일어난 일이다. 「데이터 정리 담당이 지금 없다」는 벌써 벌어진 이슈다. 지켜볼 일이 아니라 지금 풀 일이다. 프리모템을 하다 보면 이런 이슈가 섞여 나오니 따로 적어 둔다.

리스크 관리대장으로 옮기기

프리모템에서 나온 문장은 「원인, 이벤트, 결과」로 나눠 리스크 관리대장에 적는다. 리스크를 이 세 부분으로 설명하는 구조는 지침서에도 나온다. 「리스크 관리대장 쓰는 법」 글의 「원인, 사건, 영향」과 같은 구조이고, 여기서는 지침서 표기를 따랐다. 여기에 대응과 담당 칸을 더해 위 예 가운데 하나를 옮기면 이렇다.

표는 가로로 밀어서 볼 수 있습니다.

칸	적는 내용
원인	옛 시스템 데이터에 중복과 빈칸이 많고, 얼마나 되는지 아직 재 보지 않았다
이벤트	이관 테스트에서 오류가 많이 나와 테스트를 다시 하게 될 수 있다
결과	오픈이 늦어지고, 현업의 마감 업무와 겹친다
대응	착수 첫 달에 데이터 표본을 뽑아 정리 규모를 잰다
담당(리스크 오너)	현업 데이터 책임자 한 명

「원인이 있어서 이벤트가 생길 수 있고, 생기면 목표에 이런 결과가 온다」로 나눠 적으면 대응을 어디에 둘지 분명해진다. 원인에 대응하면 일어날 가능성을 낮추고, 결과에 대응하면 일어났을 때의 피해를 줄인다. 관리대장 칸 구성은 「리스크 관리대장 쓰는 법」 글에 자세히 있으니 함께 보면 된다.

자주 하는 실수

탓하는 자리가 된다. 「누구 때문에 실패했다」가 나오면 진행자가 「어떤 상황 때문에」로 바꿔 적는다. 사람이 아니라 조건을 적는다.
너무 늦게 한다. 계약과 일정이 모두 굳은 뒤에 하면 리스크를 찾아도 바꿀 수 있는 것이 없다. 계획이 거의 정해졌지만 아직 고칠 수 있는 때에 한다.
기록만 하고 대응이 없다. 목록이 길게 남고 아무도 맡지 않으면 다음 회의에서 아무도 다시 보지 않는다. 고른 것마다 담당과 첫 대응을 그 자리에서 정한다.
한 번으로 끝낸다. 리스크는 처음에 다 찾을 수 없고, 일이 나아가면서 새로 생긴다. 프리모템은 첫 목록을 만드는 자리다. 그 뒤 정기 점검에서 관리대장을 다시 보고 새 리스크를 더한다.

바로 쓰는 진행표

참고

Gary Klein, 「Performing a Project Premortem」, Harvard Business Review, 2007년 9월호. 프리모템의 개념과 이름, 진행 단계의 뼈대(실패했다고 가정하기, 각자 쓰기, 돌아가며 하나씩 말하기, 나온 목록으로 계획 보강하기)를 따랐다. 문장은 옮기지 않았다.
Deborah J. Mitchell, J. Edward Russo, Nancy Pennington, 「Back to the Future: Temporal Perspective in the Explanation of Events」, Journal of Behavioral Decision Making, 1989. 「이미 일어났다고 상상하면 이유를 더 많이 떠올린다」는 결과의 요지만 옮겼다.
Jason Collins, 「The premortem」(강의 노트 「Course notes on behavioural economics and corporate decision making」의 한 장), https://corporate.jcx.au/premortem . 1989년 연구가 이유의 개수를 쟀고 이유의 질은 따지지 않았다는 해설을 참고했다.
PMBOK® 지침서 8판 한국어판, 2.7 리스크 성과 영역(2.7.1 핵심 개념, 2.7.2.2 리스크 식별)과 섹션 5 도구 및 기법의 프롬프트 목록. 리스크와 이슈의 구분, 위협과 기회, 리스크 식별이 되풀이된다는 점, 「원인, 이벤트, 결과」 구조, 프롬프트 목록의 개념과 용어만 따랐다. 문장은 옮기지 않았다. 프리모템 자체는 지침서에 나오지 않는다.
단계별 시간, 분류하기와 고르기의 기준, 예시, 대응과 담당 칸은 이 글에서 새로 정리했다. 예시 회사와 프로젝트는 가상의 것이다.
PMI와 PMBOK은 Project Management Institute의 등록 상표입니다.