얼마전 중견 시스템 통합회사(SI)에서 이틀 동안 제안 프레젠테이션에 대한 강의와 실습을 진행했었습니다. 교육 일주일전 참가자들이 실제 필드에서 사용했던 제안발표 슬라이드를 저에게 제출했고 교육 당일 그에 대한 발표를 두번씩 진행했죠. 첫 발표는 교육의 시작부분에서 있는 그대로의 모습을 보여주는 자리였고 두 번째 발표는 교육 이틀째 핵심을 다시 정리하여 다시 달표하는 자리였습니다. 저는 교육이 끝나고 각자의 발표에 대해 서면으로 피드백을 제출하기로 했고 집으로 돌아와 차분하게 첫번째 발표에 대한 ‘진단’을 총론적으로 정리하기 시작했습니다.
그런데 다 적고보니 사실 이 내용은 그 회사에게만 해당되는 내용이 아니라 제가 지금까지 다니면서 본 여러회사들의 제안발표의 문제점과 거의 일치했습니다. 진단과 제언부분만을 발췌하여 올립니다.
진단
8명의 프리젠터에게 각 5분의 발표시간이 주어졌고 각자에게 피드백할 계획이었으나 8명 모두의 개선점이 유사하여 전체적으로 다루는 것이 낫다고 판단하였습니다. 따라서 아래 각 항의 내용은 8명 모두에게 공통적으로 해당된다고 보면 되겠습니다.
- 주어진 시간 초과
- 정보의 단순나열
- 슬라이드에 의존
- 간결하지 못한 주장
- 뒤바뀐 맥락
- 당위성의 결여 (= Benefit 설계미흡)
- 전체를 보여주지 못한 구성
- 구체성의 결여
- 이해도가 떨어지는 장표
1. 주어진 시간초과
8명 모두 주어진 5분의 시간을 초과하였고 14분까지 발표한 분도 있었습니다. 이는 제안서가 논리전개의 단순한 플롯이 없이 단순나열된 정보의 집합체로 구성되었다는 것을 방증합니다. 실제 프레젠테이션이 30분이든 15분이든 상관없이 모든 발표는 1분, 5분이내에 핵심을 전달할 수 있어야 하며 이는 제안서 작업 초기에 굵직한 제안전략 방향이 확고하게 구축되어야 가능합니다. 보통 SI업계의 제안서들은 시간에 쫓겨 내용을 채워넣는데 급급하여 이런 현상이 공통적으로 나타납니다. 앞으로 제시될 2~8까지의 원인으로 인해 종합적으로 나타나는 현상이며 그 문제들이 해결되면 자연스럽게 다양한 길이로 함축적으로 발표할 수 있게 됩니다
2. 정보의 단순나열
모든 발표자가 정보나 데이타를 단순나열하고 있습니다. 이때문에 청중들은 제안의 전체 모양새를 기억하지 못한채 각자 인상적이었던 서로다른 사실의 조각만을 각자 기억할 가능성이 높아 결국 전체적으로는 ‘잘 모르겠다’는 반응을 나타낼 것이 유력합니다.
이는 정보의 앞뒤 인과관계가 연결되어 전체 제안의 그림이 머리속에 그려지는 것과 반대되는 현상으로 논리전개와 흐름이 없기 때문에 발생합니다. 상황-이슈-문제-원인-해결책으로 이어지는 단단한 구조가 먼저 만들어져야 합니다
3. 슬라이드에 의존
대부분의 발표자가 슬라이드를 넘겨가며 거기에 나타나는 내용에 대한 설명에 급급하고 있습니다. 이때문에 전체 발표가 고저장단과 악센트 없이 평이하게 나열되며 전개되는 느낌이 들게되어 청중의 이해력을 떨어뜨립니다.
슬라이드는 보조자료입니다. 우리는 슬라이드가 없어도 제안의 특성과 필요성을 강하게 주장할 수 있어야 합니다. 슬라이드에 의존할 수밖에 없는 것은 전체의 흐름과 강조점 등이 머리속에 확고하게 형성되어 있지 않기 때문입니다. 너무 내용이 많고 복잡한 것이 원인입니다.
4. 간결하지 못한 주장
주장하고자 하는 내용이 다듬어 지지 않은체 긴 문장으로 되어 있는 경우가 많습니다. 가령 네 가지 특징을 얘기하는데 각 특징이 두 줄 정도의 긴 문장으로 되어 있으면 글자가 하나 늘어나는 것에 비례하여 청중의 기억과 이해도는 반감합니다. 핵심적인 문장은 짧고 강렬하게 다듬어 기억하기 좋게 만들어야 합니다. 여러가지를 나열한다면 각 항목의 글자 수를 맞추고 비슷한 어감으로 끝내는 네이밍 전략이 중요합니다.
5. 뒤바뀐맥락
많은 발표자가 발표의 첫부분을 회사소개로 채우고 있습니다. 이로 인해 처음부터 프레젠테이션이 지루한 길을 가게 됩니다. 이는 제안요청서의 순서에 의거한 결과입니다만 제안서는 그 순서에 의해 제출하되 프레젠테이션에서는 제품과 서비스 등 핵심에 집중시키고 나중에 제반요건과 회사소개를 하는 방식이 더 설득력있습니다. 회사소개는 맥락이 뒤바뀐 예의 하나입니다. 우리는 청중이 가진 선입견이나 예상반을을 순서대로 바꿔나간다는 개념을 지니고 있어야 합니다.
6. 당위성의 결여 (=Benefit 설계미흡)
대부분의 발표가 Feature(기능)설명위주의 발표였습니다. 이 때문에 청중이 절실하게 자신이 원하는 Pain Point를 치유할 솔루션을 얻었다고 생각해 줄지 의문입니다. 청중은 Feature보다 Benefit에 반응하여 마음이 움직입니다. 고객이 현재 가지지않은 부분을 정확히 지적하고 이에 대해 우리의 솔루션이나 서비스가 어떻게 그것을 해결해 줄지 설명하는 형태라야 하는데 현재로서는 우리의 기능을 듣고 고객들이 알아서 판단하라는 형식이다보니 설득력이 전반적으로 떨어집니다
7. 전체를 보여주지 못한 구성
프레젠테이션은 내용 하나하나를 전달하는 것이 아닌 우리가 가진 내용의 구조를 전달하는 데 초점이 맞춰져야 합니다. 이때문에 중간중간 지금까지 얘기한 내용과 방향을 요약해 주는 등 큰 그림을 고객의 머리속에 전달해야 하는데 조각난 내용의 전달에 그치는 인상입니다. ‘2. 정보의 단순나열’과 관련있습니다.
8. 구체성의 결여
내용을 함축하면서 여러개의 현상을 한꺼번에 설명하는 ‘안정성’, ‘생산성’ 등의 광범위하고 모호한 단어가 많이 사용되는데 이것이 내용의 구체성을 떨어뜨려 전체 제안을 추상적으로 보이게 합니다. 모호한 단어를 필해 아주 구체적인 단어로 항목을 바꾸거나 구체적인 수치 등과 함께 써서 현실적인 제안임을 보여주어야 합니다
9. 이해도가 떨어지는 장표
각 장표는 신속하게 오해없이 읽어낼 수 있느냐가 관건입니다. 이것은 아름다운 장표와는 다른말입니다. 장표의 디자인은 크게 구도와 내용으로 나뉠 수 있는데 구도는 장표가 등장한 순간 직관적으로 청중이 어떻게 읽어야 할지를 수 초내에 결정할 수 있도록 방향성과 구획정리가 잘되어 있는 것을 뜻합니다. 내용면에서는 타이틀 보다는 키워드가 더 크게 등장해야 하며 오해할 수 있는 컬러와 스타일은 단순화 되어야 합니다. 전반적으로 더 단순화될 필요가 있습니다.
요약하면 단순한 논리구조와 맥락전개가 부족한 모습으로 현 상태는 정보를 단순나열하는 쪽에 가깝다고 할 수 있습니다.
개선후 모습
이론과 실습 교육후 각자 핵심 위주로 재정리한 발표는 대부분 3분 이내로 요약된 핵심사안에 포커스를 맞추어 전날 발표보다 나은 모습을 보여주었습니다. 다만 구체적이고 간결한 네이밍과 단순한 플롯으로 맥락을 잡아내는 작업은 부족했는데, 이는 주어진 시간의 부족을 감안하면 괜찮은 결과라 생각합니다. 금번 교육의 핵심은 프레젠테이션에 대한 마인드 전환입니다. 교육에서 강조되었던 한 장으로 풀어내는 단순한 논리전개를 계속 염두해 둔다면 지속적으로 결과가 개선되리라 예상됩니다.
제언
제안 기획 과정과 제안서 작성에 대해 크게 두 가지를 제안합니다. 기획과정에서는 RFP를 받은 직후 해당 고객사와 프로젝트에 대한 제안환경(시간, 순서, 제안사수 등)과 고객들의 성향과 프로젝트에 대한 관심도 등의 정보를 영업과 기술부서에서 취합해 종합적으로 담은 ‘1)환경분석서’가 필요하며 제안 PM은 이를 토대로 제안전략과 핵심만을 담은 2~3장짜리 ‘2)제안전략’이 만들어져 본격적인 제안서 작성이전 커다란 방향과 강조점에 대해 의견을 나누고 접근방법에 대해 관련자들이 합의하는 단계가 필요합니다. 이 두가지 활동은 고객들의 니즈와 Pain Point를 정확하게 단순명확한 논리로 공략하는데 대단히 도움이 됩니다.
제안서 작성에 있어서는 기존의 제안발표 문서는 핸드아웃으로 활용하고 제안PT용 슬라이드는 좀 더 심플하고 핵심에 집중하도록 제안서 목차에 상관없이 재구성하는 것이 논리구조를 전달하는데 더 도움이 될 것으로 생각됩니다.
에필로그 : 게임체인저를 기다리며
제언 부분은 제가 SI업체에 강의를 갈 때면 늘 하는 이야기 입니다. 현재 상황을 타개하기 위한 제안준비 단계에서의 변화와 제안서 작성 관행에 변화를 주는 두 가지 변화에 대해 얘기하고 있는데 사실 누구도 선뜻 실천하기 어렵습니다. 이 두 가지 변화의 주안점은 ‘제안은 굵직한 테마를 가져야 한다’입니다. 아마도 회사를 초월하여 몇몇 의식있는 관리자들은 제안서의 ‘선굵은 맥락 세우기’를 실천하고 있을겁니다. 하지만 몇몇 개인의 노력으로는 부족하죠. 저도 16년간 몸담아온 경험에 미루어 얘기하자면 IT산업은 프로젝트 제안에 너무 많은 정력을 낭비하고 있습니다. 그것도 매우 비효율적으로 말이죠. 발표가 끝나면 아무도 보지않을 수백장의 제안서 작성에 (사실 프로젝트 진행중간과 종료단계에서 소송전을 대비해 문구를 확인하러 보는 경우가 있긴하죠) 너무 많은 자원이 사용됩니다. 그런데도 불구하고 제안 프레젠테이션은 거의 악몽과 같이 후진적으로 진행되죠. 이런 후진성이 사실 저에게 손쉬운 차별화의 기회를 제공합니다.
저는 제안서는 그냥 두더라도 제안발표는 우리방식대로 끌고가자고 ‘탈선’을 유도하죠. 제안서는 목차까지 RFP에 규정된 반면 프레젠테이션은 자유로운 경우가 많거든요. 하지만 수십억원이 걸린 제안발표에서 이런 ‘모험’을 시도하는 경우는 별로 없었습니다. 제 생각엔 그건 모험도 아니라고 생각합니다만.
출처원문 : 제안발표에 대한 진단과 제언
관련 기사
