Scribbles2014. 7. 20. 10:50



옛날 파일들을 정리하다가 우연히 발견한 문서 하나: "좋은 제안서를 쓰는 법"
생각하던 걸 끄적거렸던 듯. 혹은 어디서 보고 쓴 건지도 모르겠네요.

 


1. 숫자는 확증을 위한 도구!

    • 제안서에는 반드시 수치(로 상징되는) 제반 정보와 데이터가 들어가야 합니다. 하지만 이 수치는 confirmatory figure이지 exploratory figure가 아닙니다. 
    • 수치는 descriptive하지만 새로운 인사이트를 발견할 수 있는단초가 들어있어야 해요. 그게 안되면 대부분 쓸모없는 (심지어 클라이언트도 이미 아는) 정보이기 십상.
    • 클라이언트는 논리에 차근차근 공감하는 것이지 수치에 설득되지 않아요.
    • 공감할 수 있는 논리는 우리의 고민과 이해를 바탕으로 한 우리 내부의 커뮤니케이션에서 나오죠.

 

 

2. 우리가 파는 것이 뭐라고 생각하나요?

    • 제안서에는 프로젝트에 대한 우리의 고민과 이해가 드러나 있어야 합니다. 그게 '제안'이니까요.
    • 그래야 클라이언트를 우리와 공감시키고, 우리와 결속시켜 줄 수 있습니다. 
    • 제안서는 클라이언트가 팔고 싶은 걸 팔게 해 주는 겁니다. 클라이언트가 원하는 게 뭔지 파악하고, 왜 그걸 원하는지 생각하고, 클라이언트가 어쩌면 모르고 있는 솔루션이 뭔지 생각하고,
    • 클라이언트가 최대의 자신감을 갖게 해주세요. 우리 제안서는 그 자신감의 근거가 되면 됩니다.

 

 

3. 설득할 것인가 이해시킬 것인가

    • 클라이언트는 (대부분의 경우) 설득할 대상이 아닙니다. 공감시켜 우리 편(파트너)으로 만들어야 하는 대상입니다.
    • 클라이언트보다 더 많이 고민하는 컨설턴트는 없습니다. 컨설턴트는 단지 비슷한 고민을 더 많이 해봐서 더 잘 살펴보고, 더 잘 고민할 수 있을 뿐. 그러니 제안하는 내용을 잘 이해시키고, 여러분이 놓친 부분이 있는지 끝없이, 다시 한 번, 또 살펴보세요.
    • 제안서는 우리의 고민과 해결책과 그 과정을 설명하는 이야기입니다. 우리가 해본 고민에 대해 클라이언트의 공감을 먼저 산 후, 그 다음에 우리의 솔루션이 근거 없지 않음을 이해시키면 됩니다. Wowness는 사실 덜 중요한 문제입니다.
    • 제안서는 어려운 말로 이루어진 전문서가 아니에요. 클라이언트의 Top Management부터 신입사원까지 한눈에 이해할 수 있는 '흐름'을 만들어주는 것이 중요합니다.

 

 

4. 간결하게.

    • 클라이언트는 전후사정에 이미 충분히 밝습니다. 빨리 넘어가세요.
    • 클라이언트의 요구 조건 혹은 브리프가 복잡하거나 모호하다고 해서 제안서가 복잡 모호해도 되는게 아닙니다.
    • 슬라이드 한 장에, 한 마디로 제안 내용을 정리할 수 없다면, 다시 고쳐 쓰세요.

 

간결하고 쉬운 보고서는 언제나 중요합니다
‘우리가 무엇을 말해주고 싶은가’ 보다 ‘클라이언트가 무엇을 알고 싶어 하는가’에 초점을 맞추세요. 무조건. 반드시.
프로젝트 발주 후 첫 미팅에서 보통 의문과 해답이 떠오르는데, 여기에 천착하지는 말되 잊지도 마세요. 아무런 해답이 떠오르지 않았다면, 그 프로젝트에 대해 더 공부하세요.


Posted by ecarus