결정 요청서 한 장: 회의 없이 결정을 받는 법

요지

결정권자가 바쁠수록 결정을 받으려고 잡은 회의는 자꾸 밀린다. 겨우 잡은 회의에서는 배경 설명에 시간을 다 쓰고 「좀 더 알아보고 다시 봅시다」로 끝나기도 한다. 한 장짜리 결정 요청서는 이 과정을 줄이는 데 도움이 된다. 정할 것, 배경, 선택지, 선택지마다 득실과 가장 강한 반대 논리, 권하는 안, 정할 기한을 한 장에 담아 결정권자가 읽고 고르기만 하면 되게 한다.

회의로 결정을 받을 때 생기는 일

회의가 나쁜 것은 아니다. 다만 결정 하나를 받으려고 회의를 열면 흔히 이런 일이 생긴다.

• 시간: 참석자 일정을 맞추는 데 며칠이 간다. 그동안 일은 멈춰 있다.
• 다시 설명: 결정권자가 처음 듣는 이야기라 배경부터 다시 설명한다. 질문이 이어지고 정작 고를 시간이 모자란다.
• 결정 흐려짐: 「그 방향으로 가 보죠」로 끝나면 무엇을 정했는지 사람마다 다르게 기억한다.

요청서를 먼저 보내면 결정권자는 자기 시간에 읽고, 필요하면 질문 한두 개만 돌려보낸다. 회의가 꼭 필요한 경우에도 요청서를 미리 읽고 들어오면 회의가 짧아지기 쉽다.

어떤 결정을 올리나

모든 결정을 올릴 필요는 없다. 팀이 정할 수 있는 것은 팀이 정한다. 요청서가 필요한 것은 팀 권한을 넘는 결정이거나, 윗선이 움직여야 풀리는 일일 때다. 이렇게 위로 올리는 일을 에스컬레이션이라 한다. PMBOK® 지침서는 범위와 일정을 먼저 정하고 가는 예측형 환경에서 더 필요할 수 있는 거버넌스 요소로 에스컬레이션을 든다. 결정 요청서는 그때 쓰는 서식이다.

한 장에 들어갈 칸

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

가장 자주 빠지는 칸은 가장 강한 반대 논리다. 작성자는 권하는 안에 유리한 말만 쓰기 쉽다. 선택지마다 반대 논리를 한 줄씩 쓰면 결정권자는 「다른 안은 왜 안 되나」를 묻지 않아도 된다. 권하는 안에도 반대 논리를 쓴다. 그래야 요청서가 설득 문서가 아니라 판단 자료가 된다.

정할 기한에는 날짜만 쓰지 않는다. 「이날까지 정하지 않으면 계약 협상을 다시 시작해야 해서 2주가 더 든다」처럼 미뤘을 때 생기는 일을 함께 쓴다. 기한의 무게가 보여야 결정이 미뤄지지 않는다.

좋은 예와 나쁜 예

가상의 예로, 사내 교육 시스템을 만들 외주 업체를 고르는 상황이다.

나쁜 예

외주 업체 관련해 검토 부탁드립니다. A사와 B사가 제안서를 냈고 각각 장단점이 있습니다. 자세한 내용은 첨부를 봐 주시고 의견 주시면 진행하겠습니다.

결정권자는 무엇을 언제까지 정해야 하는지 모른다. 첨부를 다 읽고 스스로 비교표를 만들어야 한다. 이런 요청은 뒤로 밀리기 쉽다.

좋은 예

정할 것: 사내 교육 시스템 외주를 A사와 B사 가운데 어디에 맡겨 다음 달 첫 주에 착수할까요? 배경: 두 회사 모두 요구 기능을 충족했다. 금액은 A사가 15퍼센트 낮다. 오픈일은 계약상 바꿀 수 없다. A사: 비용이 낮다. 비슷한 규모 실적이 한 건뿐이다. 반대 논리: 「첫 대형 건이라 일정이 밀리면 오픈일을 못 지킨다.」 B사: 비슷한 실적이 여럿이다. 비용이 높다. 반대 논리: 「차액이면 운영 첫해 유지보수를 살 수 있다.」 권하는 안: B사. 오픈일을 옮길 수 없어 일정 리스크를 줄이는 쪽이 낫다. 기한: 금요일. 넘기면 두 회사 제안 가격의 유효기간이 지나 다시 받아야 한다.

같은 내용을 담았지만 결정권자는 이 한 장만 읽고 고를 수 있다. 숫자는 모두 가상의 것이다.

권하는 안을 넣을 때와 넣지 않을 때

요청서를 쓰는 사람은 대개 그 일을 가장 잘 아는 사람이다. 그러니 기본은 권하는 안을 넣는 것이다. 결정권자가 「당신이라면 무엇을 고르겠나」를 다시 묻지 않아도 된다.

다만 권하는 안을 비워 두는 편이 나을 때도 있다. 결과를 되돌리기 어렵고, 고르는 기준 자체가 결정권자의 가치 판단인 경우다. 예를 들어 어느 사업을 먼저 할지처럼 방향을 정하는 결정은 작성자가 권하면 결정권자의 판단이 그쪽으로 기울 수 있다. 이때는 선택지와 반대 논리를 공평하게 쓰고, 권하는 안 칸에 「작성자 의견 없음, 선택지별 득실만 정리함」이라고 밝힌다. 칸을 지우지 않고 비운 이유를 쓰면 빠뜨린 것이 아님을 알 수 있다.

한 장을 넘기지 않으려면

쓰다 보면 할 말이 늘어난다. 한 장을 지키는 요령은 세 가지다.

• 결정에 필요 없는 경과는 뺀다. 누가 언제 무엇을 검토했는지는 결정권자가 고르는 데 쓰이지 않는다.
• 자세한 자료는 뒤에 붙이되, 읽지 않아도 고를 수 있게 쓴다. 첨부는 확인용이지 판단의 전제가 아니다.
• 정할 것이 둘이면 요청서도 둘로 나눈다. 한 장에 결정 두 개를 섞으면 하나만 정해지고 나머지는 잊힌다.

받은 결정을 기록으로 옮기기

결정권자가 고르면 그 답을 요청서 맨 위에 「결정: B사, 날짜, 결정한 사람」으로 적는다. 그리고 의사결정 기록에 한 줄로 옮긴다. 요청서에 이미 선택지와 반대 논리가 있으니 기록의 「버린 대안」 칸은 그대로 옮겨 적으면 된다. 기록 칸 구성은 「의사결정 기록 쓰는 법」 글에 자세히 있다.

바로 쓰는 서식

• 팀이 정할 수 있는 일인지, 올려야 하는 일인지 먼저 구분한다
• 정할 것을 물음 한 문장으로 쓴다
• 배경은 결정권자가 모르는 사실만 세 줄 이내로
• 선택지를 두 개에서 네 개 적고, 같은 기준으로 득실을 쓴다
• 선택지마다 가장 강한 반대 논리를 한 줄씩 쓴다(권하는 안 포함)
• 권하는 안과 이유가 되는 사실을 쓴다. 비울 때는 비운 이유를 쓴다
• 정할 기한과 미뤘을 때 생기는 일을 쓴다
• 첨부 없이 이 한 장만 읽고 고를 수 있는지 다시 읽는다
• 답을 받으면 요청서 맨 위에 적고 의사결정 기록으로 옮긴다

참고

• 결정권자가 승인만 하면 되도록 완성해서 올린다는 생각은 군대 참모 업무에서 「Completed Staff Work」라는 이름의 원칙으로 널리 알려져 있다. 이 글은 그 원칙의 문장을 옮기지 않았다.
• PMBOK® 지침서 8판 한국어판, 2.1 거버넌스 성과 영역의 2.1.4 예측 환경에 대한 추가 고려사항. 팀 권한을 넘는 결정을 위로 올린다는 에스컬레이션의 개념과 용어만 따랐다. 문장은 옮기지 않았다. 결정 요청서라는 서식은 지침서에 나오지 않는다.
• 칸 구성, 「가장 강한 반대 논리」 칸, 서식은 이 글에서 새로 정리했다.
• 예시 회사, 금액 차이, 일정은 모두 가상의 것이다.
• PMI와 PMBOK은 Project Management Institute의 등록 상표입니다.