제안서에 대해 막연히 어려워하거나, 첫 시작을 제대로 하지못해 제안자체를 망쳐버리는 경우를 많이 봅니다.  전략적인 부분이나 아이디어부분은 간단한 교육이나, 책으로는 얻을 수 없는 부분이지만, 제안서를 쓰기위한 몇가지 기본방법을 착실히 진행하면, 최소한 요구에 대해 정확히 제시를 하고, 한덩어리로 보이는 논리적 제안서를 쓰는것은 그리 어렵지 않습니다.

 근래, 많은 젊은커플들이 이미 결혼하기로 약속하고, 날을 잡은 후에도 ‘프로포즈’라는걸 요구하는데, 사실 굉장히 우스운 이야기입니다.  프로포즈는 말 그대로, 자신과 결혼하여 함께 살기를 제안하는 행위인데, 이미 결정난 후에 프로포즈라는 것은 어떤 의미를 부여하는지 저는 이해를 못하겠습니다.  우리가 흔히 제안서를 영문으로 ‘Proposal’이라고 쓰게되는데, Google에서 검색해보면, 프로포즈에 대한 내용과 이미지가 많이 검색결과값으로 나오는 걸 보게됩니다.

 제안(Proposal)은 프로모즈와 같은 의미입니다.  즉 자신의 제안을 받아들이도록 하는 것이지요.

 그렇다면, 만약 여러분께서 프로포즈를 하기위해서, 또는 받아들이기 위해서는 어떠한걸 사려하게될까요?  상대의 인성, 외모, 재력, 가정도 중요하지만, 자신의 성격과 가장 잘 맞는지, 자신과 인생을 함께하는 반려자로서 잘 맞는지가 중요하지 않을까요?  제안서도 마찬가지입니다.  첫째로, 자신과 함께 목표를 위해 동지로서 잘 맞는지가 중요하고, 이외에 외형적인부분, 기술적인부분, 재정의 안정도 등이 중요한 역할을 합니다.  일단 여러분이 제안을 하기위해서는 상대를 사랑(이해)해야 하겠지요.

 1. 상대를 잘 알아야 합니다.

 제안을 받는 기업(당사자)의 현황에 대해, 기본적인 부분과 근래 동향은 꼭 확인해야 하는 부분입니다.  보통 홈페이지나, 소셜페이지, 기사등을 검색해서 보기도 하지만, RFA(질의서)를 통해, 추가적으로 필요한 부분을 알 수도 있으며, 제안참여설명회에서 이야기를 듣거나, 별도의 미팅을 진행할 수도 있습니다.  배경을 모른다면, 제안서의 가장중요한 부분인 ‘당위성’검증이 어려울 수 있습니다.  꼭 확인해보세요.

 2. 요구하는게 무엇일까요?

 일반적으로 제안을 받는 곳에서는 ‘제안요청서-RFP’라는걸 제공합니다.  물론, 구두로 요청하거나, 전혀 이에대한 언급이 없이, 간략한 요구로 진행되는 경우도 있지만, 제안요청서가 없는 경우라면, RFA를 통해, 제작에 필요한 상대방의 요구를 가능한한 상세히 알아내야 합니다.  간혹 회사별로 RFA의 틀을 만들어놓고, 상황에 맞게 변경해서 보내는 경우도 있는데, 보통의 클라이언트들은 RFA에 성실히 대답하지 않는 경우가 많으므로, 가능한한 주요 부문을 중심으로 작성하고, 기타사항은 별도로 발송하시는 것이 좋습니다.  주의할점은 간혹 클라이언트들은 각 제안사에서 문의해온 내용을 Merge해서 공유해버리는 경우가 있으니, 전략적인 부분은 별도로 문의하시는 것이 좋습니다.

 제안요청서는 말그대로, 제안을 위한 설계도입니다.  무엇을 요구하는지 정확히 파악이 되어야만 적절한 제안이 가능합니다.  가끔 등이 간지러워서 누군가에게 긁어달라고 할때, 엉뚱한데를 자꾸 긁어대며 ‘여기? 여기?’하면 짜증만 부가되는 것처럼, 정확한 좌표를 찾아내, 한방에 긁어 주셔야 시원~하겠지요?

제안요청서를 분석한 ‘요구사항분석서’를 별도로 작성할것을 추천합니다.  어떤페이지에, 몇번째줄에 무엇을 요구했는지, 요구가 어떤유형인지 (서비스, 콘텐츠, 디자인, 등) 구분을 지어 정리하면, 향후 ‘제안조견표’, ‘요구사항조견표’, ‘검수보고서’등을 변형해 지속적으로 사용할 수 있습니다.

 예를들어 제안요청서에 ‘고객이 쉽게 접근하여, 편리하게 사용할 수 있는 콘텐츠의 구현’이라는 제안요청 내용이 있다면, 해당 내용에는 많은 이야기가 있습니다.  첫째 고객에 대한 세그멘트가 필요하고, 둘째, UX에 대한 접근방법론, 셋째, 콘텐츠 아이디어 및 콘텐츠 제공방법, 넷째, 콘텐츠 유지운영 방안, 다섯째, 해당 콘텐츠 카테고리 유용성 검증방안’ 이라는 5가지의 요구사항이 포함된 문장이라 볼 수 있습니다.

 요구사항분석이 끝나면, 담당자의 머릿속에는 전체 제안에대한 방향성과 전략이 형성되게 되며, 영업쪽과는 실제 이 제안을 진행가능한지, 거부해야하는지 결정을 내릴 수 있는 단계를 거쳐야합니다.

 3. Needs vs Wants

 본 제안을 통해 만들어지는 온라인 서비스 또는 제품등을 사용하는 실제 ‘고객’에게 필수항목인지, 선택항목인지는 중요한 척도가 됩니다.  보통의 기획자 분들은 뭐든지 Needs라고 통칭하는데, Needs는 Wants와 다른 사항입니다.  예를들어 집에 변기가 없는 집은 없습니다.  변기가 Needs라면, 비데는 Wants가 되겠지요.  전략의 방향을 잡을때 이 제안내용의 산물이 Needs인가 Wants인가를 정확히 판단하고, 이를 토대로 전략을 세우게 되는데요.  보통 대다수의 기업에서 제공하는 것들은 Wants라고 볼 수 있으며, 관공서에서 진행하는 사업들은 Needs에 해당되는 경우가 많습니다.  Needs는 필요에 의해 사용하게되므로, 접속경로나 외부노출, 외형적인 부분보다는 안정적인 사용성이 주안점이 되는 경우가 많으며, Wants는 추가적인 욕구사항이므로, 유입경로에 대한 부문(SEO 등)과 이탈방지를 위한 방안등이 꼭 필요합니다.

 4. Bench marking

 벤치마킹을 가끔 제안을 여럿이서 작성할때, 페이지를 채우는 항목처럼 생각하고, TF 막내에게 할당되는 경우가 많은데, 이건 굉장한 오류를 발생시킬 수 있습니다.  꼭 전체적인 전략을 리딩하는 리더가 벤치마킹을 진행할 것을 권합니다.  또, 벤치마킹의 경우 비슷한(경쟁사 등) 사이트를 통으로 벤치마킹 하는 경우가 많은데, 이 부분은 일부 효과적이지 못한 경우가 많이 있습니다.  벤치마킹은 크게 3가지 그룹으로 진행하는 것이 좋습니다.  첫째는 경쟁사와 자사 벤치마킹, 둘째는 유사서비스 운영사 벤치마킹, 셋째는 주요 기능(콘텐츠, 서비스)별 벤치 마킹으로 진행하는 것이 좋습니다.  세번째 벤치마킹을 추가적으로 말씀드리면, 예를들어 이번 제안에 게시판이 들어간다고 한다면, 유사기업, 경쟁사 부문은 제외하고, 게시판이 가장 잘 되어있는 항목을 벤치마킹 하게됩니다.  즉, 항목별 선진사례 (적정사례)를 제공해야합니다.  또 각 항목별로 벤치마킹한 장표를 나열한 후에는 전체 비교내용을 한눈에 볼 수 있는 테이블을 꼭 제공하는 것이 좋습니다.

 5. 목차와 Page making

 보통 목차를 작성하면 제안서의 50%는 끝났다는 말을 하는데요. 정말 맞는 말입니다.  그만큼 목차는 전략과 내용, 방법론 모든것이 총망라된 하나의 서식이라고 보시면 좋을듯 합니다.  목차에 들어가야할 항목은 (순서. 제목(목차), 주요내용(Point), 작성내용(Contents), 제안요청서연계, 작성자, 페이지수)로 볼 수 있습니다.  제목은 실제 제안서에 작성될 제목이며, 주요 내용은 해당 페이지에서 말해야할 포인트, 작성내용은 실제 들어가야 할 내용, 제안요청서 연계는 해당작성내용이 제안요청서에서 어느 페이지에 의해 작성되었는지, 작성자는 TF내 담당자, 페이지수는 작성예상페이지 숫자입니다.  보통 전체 목차는 제안리더가 작성합니다.  제안요청서를 분석하고, 벤치마킹을 통해 트랜드를 읽은후, 전략방향에 맞춰 목차 순서를 정하고, 각페이지에 들어가야할 내용을 Summary하여 삽입합니다.  기승전결 부분도 한눈에 볼 수 있고, 각 페이지 작성담당자도 포인트에 적합하게 제안요청 내용에 맞춰 작성이 가능합니다.  페이지 숫자는 간혹, 제안요청서에 전체 페이지 용량의 규격이 있는경우, 조절을 하기 위한 부분입니다.

 제안목차가 완료되면, 각 작성담당자는 실제 작성할 ppt에 실제 페이지 제목을 넣고, 그 안에 들어가야할 내용을 참조하여 간략히 텍스트를 작성하고, 해당 내용을 뒷받침할 수 있는 사례나, 근거자료의 필요성 부분을 점검합니다.  이는 가끔 제안서를 작성할때 무조건 하얀 ppt를 열어놓고 멍~하니 있거나, 첫장부터 온갖 기교를 부려 멋진 제안서를 작성하다보면, 뒤로갈수록 일정이나 뒷심부족으로 용두사미가 될 수 있는 부분을 방지할 수 있습니다.  이렇게 작성하는 것을 ‘페이지메이킹’이라 하는데, 실제 제안서 장표수와 동일한 장표수가 제작되고, 짧은 시간에 전체 페이지에 대한 밑그림이 완료됩니다.

 완료된 페이지 메이킹페이지는 하나로 합본하여 전체 리뷰를 진행하며, 기승전결이 맞는지, 논리적인 부분에 문제가 없는지, 추가하거나, 삭제해야 하는 페이지가 있는지 최종적으로 검토를 진행하게 되며, 드디어, 제안서의 전체적인 덩어리가 구현되는 시점입니다.

 6. Page lay-out

 각각의 페이지 레이아웃은 제안사별로 특색이 있거나, 제안요청서에서 규정하는 경우도 있습니다.  다만, 제안서를 보게되는 클라이언트가 쉽게 이해할 수 있는 레이아웃을 제공해야하는데, 가장 기본적인 부분이 ‘Key copy, Context, Diagram’입니다.  키카피는 해당페이지에서 무엇을 이야기하려하는지에 대한 응축된 카피입니다.  클라이언트는 키카피와 다이어그램이 제일먼저 보이게되고, 보통, 이 상황에서 해당페이지 내용이 이해되지만, 추가적인 설명을 text로 볼 수 있게 합니다.  즉, 제안서의 페이지는 구애(제안)를 받는, 클라이언트가 가장 쉽게 볼 수 있는 상태로 구성되어야 합니다.

 7. Summary

 제안서의 장수가 많거나, 항목중 주요 페이지의 경우에,  보는사람의 편이를 위해, 마지막장에 앞에서 이야기한 전체 내용에 대한 Summary를 삽입하면 좋은 효과를 볼 수 있습니다.  저도 심사를 많이 해봤지만, 제안서를 보는 시간이 그리 길지 않은 상황에서 제안요약서도 쉽게 이해가 안되는 경우가 많습니다.  이럴때, 각 항목별로 단원이 끝나고 앞서 이야기한 바를 요약해놓은 페이지를 삽입하면, 쉽게 제안내용을 이해할 수 있습니다.

 8. Decoration

 보기 이쁜떡이 맛도 있듯이, 제안도 마찬가지입니다.  가끔 ‘내용이 중요하지 제본따위!!’ 하시는 분들 있으신대요.  그렇다면 대다수의 회사들이 자사 제안용 쇼핑백(박스)를 만들고, 표지를 만들겠습니까?  심사를 하는 사람도, 보는 사람(클라이언트)도 사람입니다.  이쁜게 이쁘게만 보이는게 아니라, 성의있게 보입니다.  페이지 분량이나, 레이아웃에 적절한 데코레이션을 진행해야 합니다.  제안용 마스터를 만들때도, 링바인더로 할경우 상단에 글이 짤리지 않도록 여백을 생각해주셔야 하며, 양면인쇄의 경우도 신경써주셔야합니다.  간지나 탭을 넣는것도 좋은 방법입니다.  주의할점은 제안서 내에 있는 이미지나 다이어그램도 Identity를 맞춰주셔야합니다.  여기저기서 따다쓴 제안서를 실제로 전체적으로 보면, 넝마페이지 같은 느낌도 든답니다.

 9. 제출제반사항

 최초 제안요청서 분석시에 별도로 준비해야하는 사항입니다.  제출에 대한 제반서류 (공공의 경우는 엄청나지요)와 규격, 부수, 제출항목등은 꼼꼼히 챙기셔야합니다.  간단한 서류한장, 카피본 한부로 인해, 수일간 고생한 제안서를 제출도 못하는 경우도 많다는걸 잊지 마셔야 합니다.

 10. 시간의 안배

 항상 제안의 시간은 짧습니다.  하지만 시간은 상대적인 부분이고, 물리적으로 불가한 시간도 있습니다.  다시말해, 적절하고 정확한 리미트 타임을 만들어 운용해야하며, 제안TF리더는 작성에 소요되는 시간을 산출하여, 물리적으로 불가능할 경우, 제안불가를 선언해야합니다.   욕심에 진행했다가, 퀄리티에 문제가 생기면, 이번 기회는 당연하고 향후에도 제안의 기회조차 갖지못하는 경우도 있음을 기억해야합니다.  그리고, 제안제출일에는 항상 여분의 시간이 있어야 합니다.  제본시간도 중요하지만, 제출은 가능한한 일찍 제출(접수) 해야합니다.  이는 제출시 혹여 누락된 서류나 문제가 있을경우 수정하여 다시 제출 할 수 있는 시간을 벌기위한 부분입니다.

 근래, 어느 기업은 제안하는 팀 따로, 수행하는 팀 따로 되는 회사들이 많은데.  제 개인적으로는 문제의 소지가 많다고 생각됩니다.  물론 제안서를 작성할 줄 아는 인원이 충분하지 않기에 생기는 현상인것은 알지만, 제안을 진행한 리더가, 해당 프로젝트의 PM으로 참여했을 때 최고의 효과를 볼 수가 있습니다.  그렇지 않을경우, 수주하기위한 제안팀과 수행을 하는 수행팀 사이의 문제는 지속적으로 발생하게 됩니다.

 마지막으로, 기획자라면, 제안과 수행은 할 줄 알아야 하지 않을까요?
거의 대다수의 기획자분들이 제안은 못한다고 말하는 요즘 상황이 많이 답답합니다. 감사합니다.