결혼을 앞두고 선배들과 술자리를 가지면 결혼한 선배중 열에 아홉은 측은한 눈빛으로 당신을 바라보며 깊은 한숨을 곁들여 이런 종류의 멘트를 날리게 된다.
아무개도 이제 인생의 무덤으로 걸어 들어 가는구나, 결혼이랑 죽음은 늦을수록 좋은거야.. 같은 비교적 온건한 멘트에서 부터 아직 안늦었어 지금이라도 도망쳐~~ 같은 극단적인 멘트까지..
여기에 대한 당신의 대답도 정해져 있다.
"자기들은 다 결혼 했으면서 ~~"
그렇다 옛날처럼 얼굴도 모르고 부모님의 말씀에 따라 결혼한 것도 아니고 다 자기들이 죽고 못살겠다고 사랑해서 결혼 했건만 결혼 생활이 만만한 사람들은 하나도 없다. 당신에게 도망치라고 조언 하는 그 유부남 선배들도 언젠가 당신의 자리에서 결혼은 인생의 무덤이라는 선배들의 말을 술자리가 파하기 전에 세번 부정했으리라~ 뭣이 중한줄도 모름서 말이다..
결혼 생활이 쉽지 않은건 모두가 아는 사실이지만 한번 사랑에 빠진 이상 당신에게 결혼은 그저 도달해야만 하는 이상향, 정복해야할 산마루, 사랑의 완성일뿐이다.
프로젝트도 마찮가지다. 수주하기전의 프로젝트란 어렵고 풀어 나가야 하는 문제가 아니라 수주라는 목표를 위해 사전영업이라는 리소스를 투입한, 손에 넣어야만 하는 목표인것이다.
이 목표를 달성하기 위해서는 고객의 필요와 영업의 소개, 컨설팅이 제시한 비전위에 각자의 필요에 따라 모호하게 관념화 되어 있는 프로젝트를 이리 묶고 저리 잘라서 땅위로 끌어 내려 구체화 시키는 작업이 필요한데 이것이 바로 제안서 작성과 제안발표다.
제안서를 작성하기 위해서는 고객사에서 게시한 공고(공사라면 나라장터, 사기업이라면 자사 홈페이지)에 포함된 RFP(Request for proposal) 확인 및 사업설명회라고 불리는 RFP 내용 설명회에 참여 해야 한다.
기존 사전영업에서 획득한 정보들과 RFP 그리고 사업설명회에서 나온 내용을 모아 모아서 제안서를 쓰게 된다. 당연한 이야기지만 수주를 하려면 제안서를 잘 써야 한다. 그러면 제안서를 잘 쓰려면 어떻게 써야 할까? 가장 잘 쓴 제안서는 어떤 제안서일까? 멋진? 잘 설명된? 크리에이티브가 넘치는? NoNoNoNoNo~
가장 잘 쓴 제안서는 수주한 제안서다.(잠깐 그런걸 모니터에 던지면 당신의 모니터가 망가지게 된다. 침~착~~해~~~) 그럼 다시 진지하게 궁서체로 수주하려면 제안서를 어떻게 써야 하는건가 일단 고객이 쉽게 이해 할 수 있게 써야 한다. 고객의 문제점을 정확하게 파악한후 고객이 사용할 수 있는 금액 안에서 문제를 해결 할 수 있는 솔루션을 제시하면 된다는 하나 마나한 소리 말고 실제로 필드에서 제안서를 어떻게 쓰고 제안서 쓰는 작업중에 PM롤을 맡을 사람은 무엇을 해야 하는지 알아 보자
제안서는 보통 파워포인트 200페이지 정도를 써야 하는데 복사 붙여 넣기로 해결 되는 회사 소개나 프로젝트 방법론 등의 분량을 제외 하더라도 평균적으로 100페이지 정도의 새로운 문서를 만들어야 하는 일이기 때문에 결코 만만한 작업이 아니다. 그리고 한명이 쭈욱 쓰는것도 아니고 기술부분, 제안개요 부분 등 해당 부분의 회사내 전문가들이 모여서 작성 하기 때문에 이 작업을 리딩할 리더가 필요하게 된다. 제안서 작성에 대한 전체 일정을 조율하고 작성된 제안서가 고객의 니즈와 눈높이에 맞는가라는 퀄리티를 확인할 수 있어야 한다. 그래서 사전 영업단계 부터 고객과 가장 긴밀하게 접촉했던 사람이 맡는것이 가장 합리적이다.
제안서 작성의 리더는 제안작성자들과 제안에 대해 브리핑을 한 후 제안 목차를 작성 하고 각 목차를 누가 장성할것인지 몇페이지 정도 작성할것인지를 정한 다음 제안서 템플릿과 함께 배포한다. 그리고는? 죽으라고 쓰고 리뷰를 한다. 1차 2차 3차~
하지만 무작정 쓰고 리뷰하는것 보다는 1차때는 전체 문서의 얼개, 2차 때는 제안서의 스토리라인 3차때는 각 페이지의 디테일 등의 중점 리뷰사항을 공유하고 진행 하면 한번 두번 야근할꺼 한번 하고 토일 작업할꺼 일요일은 쉴 수 있게 될 확률이 증가한다.
그럼 제안서 작성에서 PM은 뭘 해야 할까 우선 제안서는 아래와 같은 목차로 작성되는게 일반적이다.(제안 목차는 고객이 배포한 RFP에 포함 되어 있으면 그것을 준용하고 그렇지 않으면 적당히 알아서 구성해야 한다.)
1. 제안개요
2. 시스템 기능 및 구축방안
3. 프로젝트 관리방안
4. 제안업체 현황
PM은 이 목차에서 어디를 작성해야 할까? 자신이 개발에 좀 더 오리엔티드 되었다면(즉 개발자에서 연차가 올라와서 PM이 되는 테크트리를 탔다면) 기능 및 구축방안에 좀 더 깊이 관여할 것이고 기획에 오리엔티드 되었다면(기획이나 컨설팅에서 연차가 차서 PM이 되는 테크트리를 탔다면) 제안개요에 좀 더 깊이 관여할 것이다. 하지만 어떤 테크트리를 탓더라도 프로젝트 관리방안은 PM의 몫이다. 프로젝트 방안에는 프로젝트 방법론같은 일견 뻔하고 반복적인 내용부터 프로젝트팀 구성에 대한 구체적인 내용이 포함된다.
이렇게 제안서를 쓰고 리뷰를 하면서 PM이 신경 써야할 가장 중요한 일은 크게 2가지인데 첫번째는 제안서 작업을 통해 사업 이해를 높이는것이고 두번째는 프로젝트팀의 구성이다.
첫번째가 중요한 이유는 제안서를 작성해서 제출 하고 나면 제안작업의 꽃이라고 할 수 있는 제안발표를 하게 되는데 이때 PM이 발표자로 제안발표를 해야 하기 때문이다. 고객과 제안심사위원들을 설득 하기 위해서는 제안 발표자 스스로가 제안에 대한 확실한 비전과 구상이 서 있어야 한다. 제안서 작업을 통해 여러 사람들과 사업에 대해 논의 하고 텍스트와 이미지로 구체화된 제안서를 리뷰하면서 해당 사업에 대한 자신만의 이해를 한층 높일 수 있다.
두번째 프로젝트팀의 구성은 수주했을때 프로젝트를 해나갈 팀을 구성하는 일이다. 본인은 후배들에게 프로젝트의 성공과 실패는 이 프로젝트팀 구성에서 거의 50% 이상 결정 난다고 이야기 한다. 프로젝트는 사람이 하는 일이기 때문에 능력 있는 팀원 자신과 손발이 잘 맡는 팀원으로 팀을 구성하는 것은 무엇보다도 중요하다.
그럼 어떻게 해야 할까? 내가 원한다고 척척 내가 원하는 팀원으로 팀을 구성할 수는 없다. 이미 다른 프로젝트에 투입 되어 있을 수도 있고 능력 있는 팀원들은 언제나 바쁘기 마련이다. 하지만 포기해서는 안된다. 프로젝트팀을 꾸리는 과정에서 PM은 프로젝트 수행에 대해 이런 저런 협상을 하게 된다. 프로젝트의 성격에 따라 투입된 리소스에 비해 개발 사항이 늘어 나기도 하고 개발 기간이 줄어 들기도 한다.(대부분 네거티브한 변화가 일어나는게 일반적이다.) 협상과정에서 이런 저런 조건들때문에 양보해야 할 일이 생기기 마련이다. 하지만 자신이 원하는 인력에 대한 양보가 가장 마지막이어야 한다. 이말은 나 이 사람 아니면 프로젝트 안해 못해 하고 무작정 때를 쓰라는게 아니다. 회사에서도 납득할만한 지금까지 자신이 파악한 프로젝트 성격 및 상황과 개발자들의 특성 및 장점을 잘 버무린 누구라도 납득할만한 전략적인 접근이 있어야 한다는 말이다.
그러기 위해서는 평소에 회사의 개발자들이 어떤 능력이 있는지 그 개발자와 프로젝트를 하기 위해 어떻게 하면 가장 강력한 모티베이션이 줄 수 있는지 알고 있어야 한다. 개발을 엄청 잘하지만 까칠해서 같이 일하기 힘들어 하는 개발자와 손발을 맞출 수 있다면 어떨까? 개발 실력이 그다지 뛰어 나지 않아 다른 PM들은 꺼려하지만 근면성실해서 단순한 개발이 양만 많은 프로젝트에 적합한 개발자가 있을 수도 있다. 평소에 개발자들과 아주 좋은 관계를 유지해서 개발자가 자신의 프로젝트에 투입에 대해 강력하게 요구할 수도 있다. 프로젝트를 수주에 대한 욕망이 좀 더 강한 영업대표나 경영진에게 자신이 원하는 팀원이 프로젝트에 투입되었을때 수주확률과 구축이 더 원활할 수 있다는것을 남들보다 효과적으로 어필 할 수 있다면 그것도 도움이 될것이다. 본사와 각을 세워야 할 수도 있다. 수단과 방법중 불법적인것, 본인의 평판에 심대한 악영향을 줄만한 누가봐도 양스러운짓 빼고는 뭐든 동원해서 팀원을 확보해야 한다.
이제 전쟁같은 제안서 쓰기 작업이 마감되었다면 출력해서 고객사에 제출한다. 그리고 남은것은 제안발표다. 제안발표는 대부분 제안서의 내용을 기본으로 제안발표를 맡게될 PM이 작성하게 된다.
다음 시간에는 제안발표 자료 만들기와 제안발표에 대해 알아 보도록 하자
'나는 PM(Project Manager)이다 ' 카테고리의 다른 글
나는 PM(Project Manager)이다 - 8. 시작은 시작이지 반이 아니다. (0) | 2018.03.13 |
---|---|
나는 PM(Project Manager)이다 - 7. Show time (0) | 2018.03.13 |
나는 PM(Project Manager)이다 - 5. 섀도우스트라이커의 역할 (0) | 2016.07.06 |
나는 PM(Project Manager)이다 - 4. PM위에 PM 있고 PM 밑에 PM 있나? (0) | 2011.11.08 |
나는 PM(Project Manager)이다 - 3. PM은 고스톱쳐서 되는게 아니다. (0) | 2011.10.19 |