PART1. 시작할 것인가, 말 것인가
제안요청서를 검토한 다음 제안서를 쓴다. 이 순서는 너무 자연스러워서 별다른 설명이 필요 없어 보인다. 하지만 이 두 문서의 성격은 처음부터 다르다.
제안요청서는 고객사가 정리한 요구의 목록이고, 제안서는 그 요구에 대해 프로젝트를 담당하게되는 우리가 어떤 방식과 조건으로 응답할 것인지를 밝히는 문서다. 작성 주체도, 문서가 담당하는 역할도 서로 다르다.
제안서를 쓰려다 보면, 간혹 아래와 같은 요청을 받는 경우도 있다.
“제안요청서에 있는 내용 그대로 정리해 주세요.”
이 말은 겉으로 보면 정리하는 수고를 줄이자는 이야기처럼 들린다. 하지만 실제로는 아직 판단하지 않은 상태로 프로젝트를 시작하자는 말에 가깝다. 제안요청서를 그대로 옮긴 제안서는 ‘어떻게 만들 것인가’에 대한 답이 없다. 무엇을 받아들이고, 무엇을 제외할지에 대한 선택도 없고, 어떤 기준으로 진행하겠다는 입장도 드러나지 않는다. 그래서 그 문서는 제안서라기보다 제안요청서를 다시 정리해 놓은 요약본에 가깝다
제안서를 쓴다는 것은
제안서를 쓴다는 것은 요구사항을 다시 적는 일이 아니라, 요구사항을 다시 판단하는 일이다. 이 요구사항이 반드시 필요한지, 제안요청서에는 적혀 있지 않지만 이 프로젝트를 위해 우리가 오히려 제안해야 할 것은 무엇인지, 그리고 이 모든 것이 주어진 일정 안에서 가능한지에 대한 답이 제안서 곳곳에 형태를 바꿔 스며든다. 그래서 제안서는 읽는 사람보다 쓰는 사람의 태도와 입장을 더 분명하게 드러내는 문서가 된다.
즉, ‘좋은 제안서’란 요구사항을 빠짐없이 담은 문서가 아니라, 문제가 무엇인지, 그 문제를 어떻게 풀 것인지, 그리고 그 과정에서 우리가 어떤 선택을 했는지가 드러나는 문서다. 무엇을 만들어 달라는 요청에 응답하는 것을 넘어, 무엇을 해결해야 하는지, 왜 이 방식이 더 적절한지, 그리고 제안요청서에는 없었지만 프로젝트를 위해 우리가 추가로 제안하는 내용이 어떤 전제 위에서 가능한지가 함께 설명되어야 한다. 이 기준은 웹 기획이든, UX 프로젝트든, 일반적인 비즈니스 제안이든 크게 다르지 않다.
그래서 제안서를 쓸 때 기획자는 기능 목록보다 먼저 이 세 가지를 정리하게 된다.
- 이 프로젝트에서 이미 결정된 부분
- 협의 및 확인이 필요한 부분
- 이번 제안 범위에 포함되는 것과 포함되지 않는 것
이 구분이 명확할수록 제안서는 설득의 문서가 아니라 기준의 문서가 된다. 반대로 이 구분이 흐릿하면 제안서는 모든 것을 가능하게 보이게 만들고, 그 결과 중요한 결정은 계약 이후로 미뤄진다.
“상세 기획하면서 조율하면 되죠.”
“진행하면서 맞추면 될 것 같아요.”
이 말들은 유연해 보이지만, 실제로는 기준을 확정하지 않은 채 프로젝트를 시작하겠다는 뜻에 가깝다. 그리고 이렇게 미뤄진 결정들은 프로젝트가 시작된 이후 가장 예민한 형태로 다시 모습을 드러낸다.
그래서 제안서를 쓸 때 기획자는 ‘잘 써야 한다’보다 ‘분명해야 한다’를 먼저 생각하게 된다. “이 범위로, 이 일정으로, 이 전제로 정말 시작해도 되는가?” 이 질문에 스스로 답하지 못한 채 제출한 제안서는 프로젝트가 시작된 이후 계속해서 설명의 대상이 된다.
제안서를 제출하는 순간, 프로젝트의 방향은 공식적으로 고정되기 시작한다. 비록 모든 것이 완전히 결정된 것은 아니더라도, 제안서에 적힌 말들은 이후 논의의 기준이 된다. 그래서 기획자는 제안서를 쓰며 한 번 더 조심스러워진다. 이 문서에 적힌 선택들을 계약 이후에도 지킬 수 있을지.
이 장에서 말하고 싶은 말은 결국 하나다. 제안서는 요청에 대한 답변이 아니라, 프로젝트의 첫 번째 기준이다. 따라서 제안서는 ‘잘 써야 하는 문서’가 아니라, 함부로 써서는 안 되는 문서다. 이 문서가 무엇을 약속하고 있는지, 그리고 무엇을 아직 약속하지 않았는지를 분명히 알지 못한 채 프로젝트를 시작하면, 그 대가는 항상 나중에 더 크게 돌아오기 때문이다.
다음 장에서는 최우선 협상 대상자로 선정된 이후,
왜 제안서에 없던 요구사항이 하나씩 등장하는지,
그리고 그때 제안서가 기준으로 남는지 참고 자료로 밀리는지를 다뤄보려 한다.