저는 한 때 SI업체에서 근무하면서 다양한 기업의 IT프로젝트 구축에 참여한 경험이 있습니다. 한 프로젝트가 종료되면 다음 프로젝트를 찾아서 입찰에 참여하고 수주가 되면 다시 투입되는 방식이었습니다. 이렇게 쳇바퀴처럼 돌아가다가 예정된 큰 프로젝트가 드롭이 되면 일이 없이 마냥 놀게 되는 경우도 생깁니다. 여유를 만끽하는 것도 좋지만, 마냥 손놓고만 있을 순 없어서 작은 프로젝트라도 발굴해야겠다는 생각이 들었습니다. 그래서 들여다보기 시작한 것이 조달청 나라장터였습니다. 공공쪽은 경험이 전혀 없었지만 모든 입찰공고가 공개되고 있고 신규 업체라도 요건만 맞으면 제안하는 것까지는 문제가 없어 보였습니다.
적당한 공고를 찾아서 ‘안돼도 그만’이라는 마음으로 혼자서 제안서를 작성해 입찰에 참여하기 시작했습니다. 원래 저는 민간 대기업을 상대로 10여명이 훌쩍 넘는 인력으로 제안팀을 꾸려 2-3주 동안 밤을 새며 제안작업을 하는 방식으로 일을 했었습니다. 한번의 제안에 수많은 동료들의 땀과 노력이 담겨 있었기 때문에 우선협상대상자 선정 발표날이 되면 모두들 숨죽이며 초조하게 결과를 기다리곤 했습니다.
그런데 공공입찰은 제가 그냥 ‘노느니 이거라도 해보겠다’는 입장이어서 맘 편하게 작업할 수 있었습니다. 그럼에도 제안은 제안이라 야근과 주말근무는 어쩔 수 없었습니다. 어쨌든 열심히 공공입찰에 문을 두드렸고, 신기하게도 이 기간 동안 진행한 모든 제안이 수주에 성공했습니다. 운이 좋았다고 말하는 것이 맞을 듯합니다. 그럼에도 이 시기에 제가 터득한 몇가지 깨달음과 비결은 있었습니다. 오늘은 그 부분에 대해 써볼까 합니다.
1. 회사의 규모와 실적이 절반입니다
모든 입찰경쟁이 그렇겠지만 ‘수행사’가 믿음이 가지 않으면 좋은 결과를 얻기 어렵습니다. 제안 내용이 좋다고 해도 제안업체의 규모가 영세하고 유사 사업실적이 없다면 민간이든 공공이든 쉽지 않다고 봅니다. 저는 다행히 회사의 규모가 있었기 때문에 이 부분에서 꿀릴 것이 없었습니다. 공공 SI에서 공룡으로 불리는 회사가 경쟁상대였지만 ‘공정한 경쟁이 맞다면’ 출발선은 같다고 판단했습니다. 물론 회사의 체급과 실력을 충분히 잘 어필하는 것은 기본 중의 기본이지요.
2. 그 다음은 제안발표가 90%입니다
제안서 내용이 아무리 좋아도 발표가 좋지 않으면 탈락입니다. 반대로 제안이 조금 부실하다고 해도 발표가 훌륭하면 이길 수 있습니다. 꼭 이겨야 한다면 발표역량이 검증된 사람을 PM으로 세워서 제안서 작성을 이끌게 하고, 발표를 직접하게 해야 합니다. PM이라는 이유로 발표 울렁증이 있는 사람을 억지로 발표하게 한다면 백전백패입니다. 회사에 프리젠테이션 역량이 있는 PM 인력을 얼마나 확보하고 있느냐가 관건입니다.
3. 제안서 원본을 요약한 것이 발표자료가 되면 안됩니다
제안서라는 것이 제안요청서의 각 항목별로 답변을 써내려가는 것이 일반적입니다. 제안요청서의 목차에 충실하게 정리해서 제안서를 완성하고 그 다음에는 내용을 요약한 요약본을 만들고, 요약본에 편집 디자인을 입혀서 발표본으로 만드는 방식으로 제안작업을 하는 곳이 많습니다. 이렇게 한다면 차별점이 약할 수 밖에 없습니다. 다른 업체도 주로 이런 식으로 제안서를 작성합니다. 심사위원들이 평가하는 데는 좋을 지 몰라도 발표는 재미없을 확률이 높습니다. 무엇보다 이렇게 작업할 경우 제안서 원본 작성에만 급급해서 발표전략을 제대로 구상하지 못하고, 발표에 담길 엣지포인트를 뒤늦게 고민하게 되는 문제가 생깁니다.
4. 전문가로서 근본 문제를 어떻게 잘 해결할 수 있을까를 고민해야 합니다
가장 좋은 방식은 이렇습니다. 제안요청자의 문제와 이슈를 나름대로 분석하고 전문가 시각으로 솔루션을 도출한 후에 제안요청서에 있는 요청사항과 다시 비교하는 것입니다. 그러면 요청사항과 기능요건 중에서도 중요한 것과 덜 중요한 것이 구분되고 빠져도 될 만한 것과 누락된 부분, 보강이 필요한 부분을 분류할 수 있습니다. 전문가는 요청사항의 중요도를 파악하고 어떤 순서와 어떤 방법으로 해결해나가는 것이 가장 비용효율적인지를 알려주는 사람입니다. 제안서 원본에는 요청내용에 대한 일대일 응답을 적시하되, 발표자료만큼은 ‘제안요청 답변’이 아니라 ‘문제에 대한 스마트한 해법’으로 재구성돼야 합니다. (이 해법은 요청서 각 항목과 기가 막히게 연결돼야 합니다) 사실 제안요청서도 이미 어떤 전문가가 문제에 대한 해결방안을 고안해서 만들어진 문서입니다. 이 전문가의 수준을 제안서가 얼만큼 더 뛰어넘을 수 있느냐가 중요합니다.
5. 암기형 발표를 하지 말고 이야기를 들려주세요
저는 한번도 발표를 위해 발표대본을 만들거나 스크립트를 암기해서 말해본 적이 없습니다. 긴장된 상황에서도 말이 술술 나올 수 있었던 까닭은 발표를 준비한 것이 아니라 ‘이야기’를 준비했기 때문입니다. 발표본에서 가장 중요한 것을 꼽으라고 한다면 스토리라인이라고 말하고 싶습니다. 스토리에는 기승전결의 구조가 담겨있습니다. ‘뻔한 시스템 구축을 제안하는데 무슨 기승전결이냐’고 물으실 수도 있습니다. 하지만 얼마든지 가능합니다! 그것도 엄청 재밌는 이야기를 만들어 갈 수도 있습니다. 이 부분이 바로 창의력이 요구되는 부분이고 탁월한 인재와 범재가 구분되는 지점이기도 합니다.
6. 발표는 심사위원들과의 교감이 가장 중요합니다
왜 발표가 ‘이야기’가 돼야하냐면 이야기야 말로 심사위원과 교감할 수 있는 방식이기 때문입니다. 발표가 딱딱하고 재미가 없으면 심사위원들의 눈은 문서로 향합니다. 귀로 듣고 있지만 눈으로는 제안서를 앞뒤로 넘겨가면서 본인이 질문할 꺼리를 찾고 있습니다. 안타깝게도 발표시간이 심사위원에게 공격을 준비하는 시간이 되는 것입니다. 이것을 막기 위해서는 심사위원을 홀려야 합니다. 그들의 눈과 귀를 사로잡기 위해서는 이야기가 재밌어야 합니다. 미처 몰랐던 사실을 알게 해줘야 하고, 어디에서도 들을 수 없었던 정보를 흘려야 하며, 어딜 가서도 써먹을 수 있는 문제해법을 들려줘야 합니다. 발표자가 자신의 경력을 통틀어서 실전에서 부딪히며 어렵게 확보한 인사이트를 하나씩 꺼내놓을 때 그들은 눈을 떼지 못하고 발표자에게 집중하게 됩니다. 이 때부터는 발표자가 평가의 대상이 아니라 경청의 대상이 됩니다.
7. 마지막으로 절박함으로 호소해야 합니다
제가 사용했던 최후의 일격은 간절함이었습니다. 믿을 수 있는 회사규모, 충분한 기술적 역량, 매력적인 제안내용, 유능한 PM의 노련한 발표스킬까지 연속타를 날린 다음에 제가 취한 스탠스는 겸손함이었습니다. 마치 발표를 망쳐버린 PM이 마지막 카드로 내밀법한 ‘간절한 호소’를 떨리는 목소리로 ‘연기’했습니다. “제안사는 이 과제를 최고의 레퍼런스로 만들어야 할 분명한 이유가 있습니다... PM인 저 자신에게도 중요한 의미가 있으며 수주한다면 모든 것을 걸고 가장 성공적인 프로젝트로 만들고 싶습니다”고 호소했습니다. 항상 이 대목에서 저는 심사위원들의 고개가 미세하게 끄떡이는 것을 감지할 수 있었고 그 순간에 저는 승리를 확신할 수 있었습니다.
수주와 실주를 결정 짓는 것은 제안발표장에 모인 몇몇의 심사위원들입니다. 사람의 판단은 대단히 감성적이기 때문에 이들의 마음을 얻으면 높은 점수를 얻고 원하는 결과를 달성할 수 있습니다. 이 글에서는 그런 감성을 터치할 수 있는 부분에 대한 노하우를 소개해 보았습니다. 다만, 규모가 크고 특정 기술분야의 높은 전문성이 요구되는 사업의 경우에는 노련한 발표와 감성터치만으로는 성공을 보장하기 어렵다는 점을 미리 말씀 드립니다.
41
