나는 PM(Project Manager)이다 - 7. Show time

흔히 티비 드라마나 영화에서 법정영화를 보면 변호사와 검사가 주고 받는 멋진 공방 극적인 증거나 증인의 등장 그리고 불리하게 진행 되던 재판이 뒤집어 지면서 끝나는 장면을 보곤 한다. 하지만 실제 재판 현장을 가보면 드라마나 영화의 화면들이 얼마나 과장되어 있는지 알 수 있다. 대부분의 사건에서 변호사의 변론도 검사의 기소도 판사의 구형도 드라마틱한 구석이라고는 1도 없는 사무적이고 건조한 분위기에서 이루어진다.

 

제안발표도 마찬가지다. 영화나 드라마에서 가끔 등장하는 멋진 효과가 가득한 제안발표자료와 배우 뺨치는 격정적인 프리젠테이션은 내 경험상은 없다. 20분 남짓 되는 시간에 자신이 준비한 내용을 알아 듣기 쉽게 자신감 있는 어조로 전달하는 것이 최선이다. 이렇게 설명하면 제안발표 별 것 아닌 것 같지만 이 단순해 보이는 경지도 실제로는 도달하기 쉽지가 않다.

 

필자가 처음으로 제안발표를 직접 하려고 했을 때는 과장 말년이었고 기본적으로 남들 앞에서 말하는 것에 대해 경험도 많고 부담도 없었다. 프로젝트도 꽤 진행 하면서 착수보고나 완료보고 같이 공식적인 발표도 많이 진행한 후라서 그렇게 어렵지 않다고 생각했었다.

 

하지만 처음 제안발표 준비과정에서 너무나 버벅거리고 헤매던 나를 보다 못한 회사에서는 사업개요 부분을 컨설턴트에게 발표하게 하고 구현부분만 내가 발표 하는 형식으로 발표형식을 수정해서 겨우 사업을 수주 할 수 있었다.

 

대중의 시선 앞에 서는 것은 누구라도 부담스러운 일이다. 늘 공연 하는 대중예술가들도 무대로 나가기 위해서 마인드 컨트롤이 필요한데 우리 같은 범인들이야 두말하면 입 아프다. 그런데 자신이 하는 발표에 대해 문제점이나 타당하지 않은 점을 찾아 내려는 심사위원과 고객들, 어떻게 생각해도 편해지기 어려운 청중을 대상으로 자신의 말 한마디 행동 하나 하나가 큰 액수의 수주금액을 결정한다는 부담감까지 더해지기 때문에 제안발표는 다른 일반적인 발표들이 주는 중압감 + 알파가 있다. 게다가 제안발표라는 것이 일주일에 한번이나 한달에 한번 같이 자주 있는 일이 아니고 일반적으로 최소한 3~4개월 길면 1년에 한번 정도의 텀을 가지고 뛰엄 뛰엄 하기 때문에 더욱 익숙해 지기가 힘들다.

 

예전에는 고객측에서 사전영업 단계에서 여러가지 조건을 고려해서 내부적으로 구축사를 내정하는 경우가 많았고 제안발표 전에 심사원들이 모인 자리에서 고객사가 모두 발언을 통해서 어떤 회사를 선호 하는지 노골적으로 지정하는 경우도 많았다. 

이쪽 바닦에서 흔히 하는 말로 영업된 사이트가 많았다는 거다. 그래서 프로젝트를 수주하는데 제안발표의 비중이 그렇게 높지 않았다. 하지만 요즘은 고객이 심사위원들에게 모두발언을 통해 특정 회사를 지정하는 것은 거의 불가능해졌고 제안서나 발표자료에 회사명을 표기 할 수 없게 하는 경우도 있어서 프로젝트 수주에 있어 제안발표의 중요성이 점 점 더 높아지고 있다. 

 

그럼 그렇게 중요해진 제안발표를 잘 하려면 어떻게 해야 할까? 단계별로 한번 살펴 보기로 하자.

 

첫번째 제안발표 자료 만들기

제안서 작성에서는 일부만 참여 했다고 하더라도 제안발표 자료는 발표자가 직접 만들어야 한다. 제안서 작성과 리뷰를 통해 심화된 프로젝트의 성격과 구축방안등을 이미 작성된 제안서를 바탕으로 자신의 언어로 프로젝트에 대해 아무것도 모르는 사람에게 설명할 수 있는 자료를 만들어야 한다.

 

제안발표 자료의 양은 보통 제안발표 시간에 따라 조정하게 된다. 제안발표 시간은 보통 발표 20분 Q&A 10분 정도로 구성되며 특별히 시연이 포함 되지 않는다면 제안발표가 30분을 넘는 경우는 거의 없다.

제안발표 시간이 20분이라면 제안발표를 위해서 간단하게 자기 소개를 하고 인사말을 한다음 본 내용으로 들어가는데 최소 1분 정도, 그리고 마지막에 프로젝트에 임하는 각오나 맺음말을 하는데 1분정도 시간이 필요하기 때문에 실제로 문서의 내용을 설명하는 시간은 18분 정도가 된다.

남은 18분 시간 중에 중요하게 생각되는 내용은 1장에 1분에서 1분 30초를 할당해서 설명 하고 간단하게 언급하고 지나가는 기능 및 일반적인 프로젝트 관리방안 등을 30초 정도로 할당 하기 때문에 제안발표가 20분이라면 발표자료는 30장을 넘어가지 않아야 한다. 30분이라고 하더라도 40장을 넘어가지 않게 조정하는 것이 일반적이다.

우선 전체 제안서 작성 장표 중 제안발표에 포함되어야 할 장표를 선정해서 제안발표 포멧으로 변경하면서 앞에서 말한 장수가 되도록 문서를 수정해야 한다.

 

위의 그림처럼 제안서와 제안발표자료는 크게 목차, 스토리라인, 본문으로 나누게 되는데 제안발표 자료는 제안서 보다 간단한 목차로 정리 되고 스토리라인도 폰트 크기가 파워포인트 기준으로 최소 18px에서 일반적으로는 20px까지 키워야 하기 때문에 의외로 잔손이 많이 간다. 

스티브잡스 처럼 화면에 커다란 키워드를 멋지게 뛰워 놓고 술술 이야기를 풀어 가는 것이 더 효과적이라고 생각할 수도 있겠지만 제안심사위원들이 제안서 전체를 심도있게 보기가 어렵기 때문에 결국 제안발표 자료를 훑어 보는 것으로 내용을 파악하는 경우도 많기 때문에 제안발표자료를 읽는것 만으로도 제안의 내용을 잘 전달할 수 있어야 한다.

 

목차를 정리하고 커진 폰트 크기에 맞게 스토리라인을 정리한 후 슬라이드 장수를 조절하기 위해 선정한 페이지중 여러 장을 한 장으로 합친다던 지 통합하는 장표를 새로 만든다던 지 하는 작업을 진행 한다. 특히 스토리라인이 중요한데 제안서에서도 그렇지만 스토리 라인은 전체 페이지에서 따로 때서 하나의 문서로 만들었을 때도 흐름이 끊어 지지 않고 쉽게 이해 할 수 있는 것이 가장 좋다.

 

두번째 제안발표 스크립트 만들고 익히기

내 경험으로는 제안발표를 연습 하는 스타일에는 크게 두가지가 있다. 그 두가지 스타일중에서 자신에게 맞는 방법을 찾아야 한다.

 

첫번재 방법은 쓰고 읽고 외우는 모범생형이다.

 

이 스타일은 작성된 제안발표 자료 슬라이드 한장 한장에 자신이 해야할 말을 텍스트로 정리한 후 그 내용을 암기해서 발표한다.

 

두번째 방법은 실제 발표를 직접 되풀이 하면서 조금씩 고치는 실전형이다.

 

이 스타일은 제안발표 자료 작성이 완료 되면 슬라이드별로 꼼꼼하게 발표 내용을 적기 보다는 되는 대로 이렇게 저렇게 실제로 말해 보면서 입에 붙이는 방식이다.

 

두가지 방법중 어느것이 더 좋거나 나쁜건 없다. 둘다 결국 자신이 제안발표에 이야기할 내용을 어떻게 하면 가장 빨리 자연스럽게 만들고 숙지하는지에 대한 방법이기 때문이다. 하지만 자신에게 맞는 방식을 찾는 것은 중요하다. 

 

내 경우는 처음 제안 발표할 때 모범생 형으로 제안발표 준비를 하는 분의 지도를 받아 스크립트를 적고 그걸 외우려고 노력했지만 결과는 완전히 실패했다. 두번째 제안발표에서부터는 처음엔 조금 버벅거리지만 계속해서 발표할 슬라이드에 대고 멘트를 조금씩 덧붙이면서 입에 붙이는 방식으로 하자 훨씬 빨리 완성도 있게 제안발표를 준비할 수 있었다.

세번째 제안발표 리허설

 어느 정도 제안발표 내용이 숙지되고 혼자서 리허설을 한후 같이 제안을 준비한 직원들과 몇차례 리허설 및 의견을 받는다.

 경험으로 보면 고객들 앞에서 제안발표 하는것 보다 뻔히 내용 다 아는 직원들과의 리허설이 더 힘들때가 많다. 하지만 힘든만큼 실전에 도움이 되고 다수의 여러가지 의견들을 받으면 아무래도 발표내용이 좀 더 풍성해 진다.

리허설때는 최대한 실전과 동일한 환경에서 하는 것이 중요한데 사소하지만 제안발표때 입고갈 복장부터 인사 실제 제안발표 및 마무리 멘트까지 실제로 제안발표를 한다는 생각을 가지고 리허설에 임해야 한다.

 

그리고 이 리허설에서 준비해야할 중요한 또 한가지 요소는 바로 Q&A 준비다. 고객은 제안발표만 듣고 끝내지 않는다 제안하는 시스템이 솔루션이라면 기본 솔루션의 시연을 요구하는 고객들도 있고 시연을 하건 하지 않건 제안발표 후에는 Q&A 시간을 가진다.

 

이때 여러가지 스타일의 질문들이 들어 오는데 고객들이 생각하기에 프로젝트에 문제점이라고 생각되는 부분에 대해 해답을 요구하는것이 일반적이고 제안 발표 내용중 이해가 가지 않거나 충분하지 않는 부분에 대해 추가 설명을 요청할 수 있다. 혹은 PM이나 제안사의 의지 혹은 프로젝트에 임하는 자세를 시험해 보기 위해 마치 요즘 유행한다는 압박면접처럼 무리한 질문 또는 쉽게 생각하지 못할 어려운 기술적, 구조적 문제를 물어 보기도 한다. 경험상 준비하는 Q&A의 적중률은 30%가 되기도 힘들때가 많다 하지만 이렇게 Q&A를 준비 하다 보면 제안발표와 내용을 고객의 시각에서 한번 조망하는 효과가 있기 때문에 빠질 수 없는 중요한 Task다.

 

마지막 Show Time

자 이런 저런 준비가 끝났다면 이제 실전이다. 제안발표 환경을 꼼꼼히 체크한다. 발표를 위해 노트북을 가지고 가야 하는지 노트북을 가지고 간다면 프로젝터 연결은 RGB인지 HDMI케이블인지 아니면 고객측에서 준비한 노트북에 자료만 USB에 담아가서 하는건지 그것도 아니면 미리 보내준 발표자료로 준비가 되어 있고 몸만 가면 되는지 등등

 

기본적으로는 고객쪽이 준비한것에 맞추면 큰 문제는 없지만 철저히 준비해서 나쁠 것은 없기 때문에 고객 측에서 준비 한다고 해도 백업으로 노트북과 함께 제안발표 자료도 챙겨 가는 것이 좋다.

 

프리젠터의 선택도 중요하다. 프리젠터란 대부분 USB 수신부와 송신기로 나눠져 있고 송신부에 달려 있는 버튼을 클릭 하면 파워포인트 슬라이드가 한장씩 넘어가고 레이저포인터가 포함되어 있는 장치다.

 

이 프리젠터도 시중에 아주 많은 제품들이 출시되어 있는데 그중에 가장 간단하고 버튼이 큰것을 고를것을 권하고 싶다. 복잡한 프리젠터는 마우스 기능에 버튼도 여러개 달려서 거의 키보드에 준하는 제품도 있다. 하지만 이런 복잡한 프리전터로 제안발표를 하다 보면 버튼을 실수로 잘못 누르기도 쉽고 실제로 그런 복잡한 기능이 필요한 제안은 시연자와 호흡을 맞춰서 하는것이 더 효율적이기 때문에 최대한 간단한 제품을 사용하는것이 좋다. 본인은 개인적으로 복잡한 프리젠터를 구매하는 것은 자신의 돈을 들여서 발표에 발생할 실수를 사는 것이라고 생각한다.

 

제안발표장에는 일반적으로 제안발표자 이외에 2~3명이 같이 들어가게 된다. 영업대표와 그 외 제안발표의 성격에 따라 회사를 대표할 임원이 같이 들어가기도 하고 Q&A에 같이 대응할 개발파트리더가 들어가기도 한다. 발표팀은 제안발표장소에 30분 정도 먼저 도착해서 제안발표 내용을 한번쯤 더 훓어 본 후 제안발표장소에 들어간다.

 

제안발표에서 가장 중요한것은 여유있게(노련하게) 그리고 믿음직하게 보여야 한다는 것이다. 왜냐하면 제안발표에 참여한 심사자들이 외부 전문가들이라면 한시간 전쯤에 와서 처음 들어보는 시스템에 대한 200여 페이지 제안서를 훑어 본 정도이기 때문에 디테일한 기술적 문제점이나 제안서 및 발표 내용의 오류를 잡아내기 어렵다.(대부분 심오한 기술적 타당성 검토 보다는 오타나 투입 인원 합산 오류 같은걸 보는 느낌?) 따라서 전달되는 내용도 중요하지만 그걸 전달하는 발표자의 자세가 매우 중요한 포인트다.

 어떤 분야나 비슷하지만 제안발표도 어떤 경지에 다다르기 위해셔는 목소리나 연출력 같은게 타고 나야 하는 부분이 있다. 우리는 세계 최고의 프리젠터가 되는 것이 목표는 아니라서 후천적인 연습으로도 필요한 정도의 노련함과 자신감있는 발표 능력을 장착하고 있어야 한다.

제안발표 대상이 공공 기관이라면 발표 시간을 엄격하게 지키는 경우가 많은데 정해진 시간이 지나면 제안발표가 마무리 되지 않았더라도 딱 끝나 버리기 때문에 제안발표 시간을 맞추는 것도 중요하다.

제안발표를 하면서 고객의 반응을 살필 수 있고 발표중에 벽에 걸린 시계나 자신의 손목시계등을 슬쩍 보면서 시간을 체크할 수 있을 정도의 여유가 생기려면 많은 제안발표 경험을 거쳐야 한다.

자신이 특별히 엄청난 재능을 가진 프리젠테이션계의 유재석 혹은 커쇼 정도라면 모를까 그렇지 않다면 심사자들의 표정이나 호흡을 살피면서 자신이 준비한 내용을 차분히 설명할 수 있다면 중수보다는 윗단계라고 볼 수 있다.

 

제안발표가 끝나면 Q&A 시간을 가지게 되는데 PM이 모든 답변을 할 수는 없겠지만 될 수 있으면 PM이 주도적으로 답변 하는것이 좋다. 부득이 같이 들어온 일행에게 답변을 돌릴때도 간단하게 나마 답변을 한 후 좀 더 상세한 답변을 같이 제안발표장에 들어온 직원에게 돌려야 한다.

 

Q&A는 정확한 답변을 제시하는것도 중요하지만 가장 중요한것은 질문하는 사람이 제안심사자라는 것을 잊지 않는 것이다. 질문이 공격적이거나 어이없을때도 있지만 질문자를 가르치려고 들거나 공격해서는 안된다. 최대한 요점만 간결히 그리고 무엇보다도 최대한 정중하게 답변해야 한다. 

 

제안발표까지 하게 되면 고객사에서는 제안서와 제아발표시 심사자들의 점수 그리고 가장 중요한 입찰금액을 합산해서 우선협상자를 선정하고 결과를 영업대표에게 통보하게 된다. 좋은 소식이 오기를 기다리면 된다.

제안발표를 하고 나면 수주할 수 있는지에 대한 어느정도 감이 오게 되는데 고객의 질문이 제안 내용을 자신의 업무에 실제 대입한 상황에 대한 질문이 많이 나오면 수주 확률이 높다고 볼 수 있다.

다음편에서는 어렵게 준비한 제안을 수주하고 프로젝트에 투입 되기 전까지 드디어 PM이 프로젝트의 리더로써 본격적인 활약을 해야 하는 전초 단계의 일들을 한번 살펴 보도록 하자.