PM 컨버팅 #5
1. 초보 PM(Project Manager) 입문편
#5. 제안서 작성하기
이제 모든 준비가 끝났고 제안 작업에 들어간다.
과거에는 사업을 주관하는 업체(일명 마더업체)에서 제안룸을 세팅하고 그 사업에 참여하는 컨소시엄 업체나 협력업체들이 개발하는 파트를 마더업체의 제안룸에 모여서 작성을 하곤 했다. 대기업 SI 같은 경우에는 협력업체들을 각각 골방에 몰아 넣고 업체들이 전체 그림을 조망하지 못하게 꼼수를 펴곤 했지만 최근 들어서는 특별한 경우를 제외하고는 제안서의 마스터 페이지만 공유해서 원격으로 협력업체의 제안 파트만 제안서를 받곤 한다. 과거에는 제안서의 작성 분량이 300p가 기본이었지만 요즘은 50p분량이 거의 대부분인 것 같다.
여담이지만 제안서 관련하여 재미있는 에피소드가 있는데 한 번은 제안서 작성을 위하여 해당 업체들이 지리산의 모기업 연수원에서 제안서를 작성했던 기억이 있고 또 한 번은 제안서를 쓰다가 업체들끼리 트러블이 생겨서 주먹질까지 했던 기억이 있다. 그리고 들러리 제안서를 제출했는데 수주를 하여 혼 났던 기억 등등
분명 제안 작업은 참여인력들의 온 신경을 집중하게 되는 작업이고 꼭 수주하여야 한다는 중압감 그리고 제안서 작성 기간 내내 철야를 해야 한다는 체력적 부담감 그리고 사업 외 부서의 잦은 간섭 특히 영업대표와의 트러블 그리고 기타 여러 이해당사자들의 부탁들로 막판에 가면 갈수록 신경이 날카로워질 수밖에 없는 구조로 흘러간다.
통상적으로 제안서를 쓰게 되는 경우 꼭 제안서를 제출하는 것은 아니다. 회사의 입장에서 처음 사업성을 검토하고 그 사업에 참여를 하겠다고 의사결정을 한 순간부터 원가가 반영이 된다. 그래서 제안서를 쓸지 말지에 대한 의사결정이 필요하고 제안서를 쓰는 와중에도 이 제안서를 제출할지 말지에 대한 의사결정 과정을 거친다. 두 번째 의사결정에서 승산이 없다라고 판단이 서면 회사는 제안팀을 해체한다.
제안서의 구성은 크게 본제안서와 요약본 그리고 PT본과 별첨자료로 구성이 되며 요즘은 거의 대부분 제안팀에서 작성한 제안서를 별도의 디자인팀이 한번 더 디자인 작업을 거쳐서 제출한다.
제안서를 쓸 때 가장 중요한 점은 다음의 몇 가지로 들 수 있다.
첫째 제안서는 계약문서에 포함된다. RFP 과업수행계획서 그리고 제안서 순으로 중요도를 두며 제안서에 작성된 내용은 필히 과업수행기간에 구축 및 개발이 되어야 한다. 즉 실제 구현이 어렵거나 원가를 오버하는 경우에는 절대 제안서에 그 내용을 반영하여서는 안 된다.
둘째 제안서는 철저하게 고객이 요구하는 규격에 맞추어 써야 한다. 요즘은 회사명 기입을 못하게 하는 블라인드 평가를 많이 한다. 즉 회사명이나 실명을 기입하면 감정을 준다거나 제안서의 종이그램 수 색지의 색깔 그리고 페이지수 등 그 제약조건이 상당히 디테일하다 고생해서 제안서를 작성했는데 이런 사소한 부분 때문에 감점을 당하는 억울한 경우가 많다.
셋째로 인력프로필 부분인데 최근에 수주 후 인력을 교체해야지 하는 안일한 생각을 가지고 인력 구성을 하는 경우로 사업 초기부터 고객과 트러블을 빚는 경우를 종종 보게 된다. 그리고 예전에는 협력업체 구성에 큰 제약이 없었다 즉 수주 후 협력업체 또는 인력을 교체하곤 했지만 요즘은 제안서 제출 때 협력업체 협약서를 제출해 수주 후 협력업체 교체를 원천적으로 막는 경우가 많다.
넷째로 본 제안서에 없는 내용을 PT본에 넣지 말아야 한다. 예전 모 사이트에 제안발표를 하는데 제안PM이 본제안서에 없는 내용을 PT본에 넣어서 발표했다가 그 사항을 눈치챈 심사위원의 한마디로 사업에서 탈락한 경우가 있다.
다섯번째로 별첨자료 챙기기다. 별첨자료에는 인력프로필부터 회사 소개자료 신용도 자료 등등 수많은 서류들이 들어가고 이 서류는 제안평가시에 정량적 점수로 평가된다. 서류가 미비할 경우 감점이다. 필히 고객이 요청하는 서류를 두 번 세 번 확인하고 또 확인한 후 제출하여야 한다.
여섯번째 솔루션이나 하드웨어가 병행으로 수행되는 프로젝트에서 가격은 수주 후에 금액 조율이 가능하지만 솔루션이나 하드웨어의 특성은 변경이 불가능하다라고 생각하고 철저하게 분석을 하여야 한다. 절대 RFP에 있는 개발과업만 생각하다가는 프로젝트 수행 중에 큰 난관에 봉착할 수 있다. 과거에 모그룹사의 해외지사에 회계시스템을 구축하여야 하는 프로젝트에서 제안사는 단순하게 다국어지원만 하면 되겠지라는 안일한 생각에 회계 패키지의 단일화 부분만 고려하여 제안서를 제출하여 수주를 하였다. 그러나 실상은 국가별로 회계규정이 달라서 해당 국가별로 별개의 회계프로세스를 지원하는 프로그램을 개발하여야 하는 상황에 봉착한다. 결국 프로젝트는 중단되고 지리한 소송전으로 들어간다. 이런 사례는 비일비재하다.
제안서 작성은 정말 힘든 작업이다. 그리고 프로젝트를 수주하고 수행하기 위하여 필수적으로 거쳐야 하는 과정이기도 하다. PM이 되기 위하여서는 제안서를 작성할 줄 알아야 하고 제안서를 볼 줄 알아야 하고 제안서를 발표할 줄 알아야 된다. 처음부터 잘하는 사람은 없다. 많은 경험과 시행착오를 거쳐서 PM은 만들어진다.
시니어급에게 제안룸은 지옥일 수도 있지만 주니어들에게 제안룸은 기회의 땅이다. 대부분 프로젝트를 마무리하고 복귀한 시니어들이 다음 프로젝트를 나가기 전까지 제안룸에서 제안 지원을 하게 된다. 대다수 사람들이 두 달 이상 제안룸에 있다 보면 여러 가지로 심적으로 복잡한 마음 상태가 되고 슬슬 이직을 고민하게 된다. 그리고 실제로 이직을 하는 사람들도 있다. 어차피 회사에서도 비가득으로 취급하고 한 달 두 달이 지날수록 슬슬 팀장이나 임원들의 눈치를 보내게 된다. 그러나 주니어들에게는 다르다. 고참 선배들의 노하우를 전수받을 수 있는 기회고 제안서를 작성하는 동안 문서작성 스킬도 일취월장할 것이다. 또 제안룸의 특성상 타 부서 사람들과 협업을 하는 공간이라 주니어들이 훌륭한 자질을 보여줄 경우 회사 내에 금방 소문이 난다. 분명 주니어들에게 제안룸은 기회의 땅이다.
다음회에 계속...
지금 읽으신 글은 책으로 출판되어 있습니다.
내일부터 Project Manager가 되어야 한다.
