4차 산업혁명은 올해 초 1월 20일 스위스 다보스에서 열린 '세계경제포럼'에서 처음 언급된 개념입니다. 세계경제포럼은 전 세계 기업인, 정치인, 경제학자 등 전문가 2천여 명이 모여 세계가 당면한 과제의 해법을 논의하는 자리입니다. '과학기술' 분야가 주요 의제로 선택된 것은 포럼 창립 이래 최초였습니다.
세계경제포럼은 '제4차 산업혁명'을 "3차 산업혁명을 기반으로 한 디지털과 바이오산업, 물리학 등의 경계를 융합하는 기술혁명"이라고 설명합니다. 즉 4차 산업혁명은 3차 산업혁명의 연장선입니다. 4차 산업혁명을 이해하기 위해서 먼저 산업 혁명의 역사를 짚어봐야 합니다.
1차 산업혁명: 증기기관
1784년 수력 증기기관을 활용하여 철도, 면사방적기와 같은 기계적 혁명을 불러일으킵니다.
2차 산업혁명: 전기 동력 대량생산
1870년대부터 시작된 2차 산업혁명은 1차 산업혁명의 연장선입니다. 공장에 전력이 공급되고 컨베이어벨트를 이용한 대량생산이 가능해졌습니다. 자동차 회사 포드의 'T형 포드'와 같이 조립 설비와 전기를 통한 대량생산체계를 구축합니다.
3차 산업혁명: 컴퓨터 제어 자동화
컴퓨터를 이용한 생산자동화를 통해 대량생산이 진화합니다. 업무용 메인프레임 컴퓨터, 개인용 컴퓨터, 인터넷 등을 통한 정보기술 시대가 개막하죠.
Steve Jurvetson, flickr (CC BY)3차 산업혁명의 주춧돌인 정보통신기술의 발달은 4차 산업혁명의 필요조건입니다. 4차 산업혁명의 핵심 키워드는 융합과 연결입니다. 정보통신기술의 발달로 전 세계적인 소통이 가능해지고 개별적으로 발달한 각종 기술의 원활한 융합을 가능케 합니다. 정보통신기술과 제조업, 바이오산업 등 다양한 산업 분야에서 이뤄지는 연결과 융합은 새로운 부가가치를 창출해 냅니다.
예를 들어보겠습니다. 먼 미래의 일이 아닙니다. 최근 사과워치, 우주기어가 유행이었죠. 이와 같은 스마트워치는 '하루에 잠은 얼마나 자는지' '밥은 무엇을 먹는지' 등 사람의 신체 활동 데이터를 축적합니다. 스마트워치는 데이터를 스마트폰뿐만 아니라 냉장고, 전등, 텔레비전 등 다양한 기기들과 공유합니다. 데이터가 축적되면 특정한 패턴이 형성됩니다. 분석 결과를 토대로 사람들의 행동을 예측합니다. 기업들은 예측 결과를 바탕으로 소비자의 특성에 맞는 물건들을 생산해 냅니다.
이처럼 4차 산업 혁명의 특징은 △초연결성 △초지능성 △예측 가능성입니다. 사람과 사물, 사물과 사물이 인터넷 통신망으로 연결(초연결성). 초연결성으로 비롯된 막대한 데이터를 분석하여 일정한 패턴 파악(초지능성). 분석 결과를 토대로 인간의 행동을 예측(예측 가능성).
이와 같은 일련의 단계를 통해 새로운 가치를 창출해 내는 것이 바로 4차 산업 혁명의 특징입니
KCSP.KR
KMS(Knowledge Management System)개발
2017. 7. 24.
2017. 7. 20.
제안서 쓰기 - 첫번째 이야기
IT시스템 구축에 대한 제안서를 쓴다는 것에 대해 필자의 경험을 바탕으로 몇 자 적어보려 한다. 다시 말하지만 이 글은 필자의 개인적인 경험과 지식을 바탕으로 쓰는 글이다. 독자들 중에 해당 분야에 종사하면서 '어, 우리는 저렇게 안 하는데..' 라는 생각이 드는 사람도 있겠지만, 필자가 모든 케이스를 완벽하게 섭렵하고 있는 건 아니니, 이런 경우도 있나 보다 정도로 이해하시라.
IT시스템 구축 사업은 사전 조사를 거쳐 입찰공고 또는 사업설명회 ▷ 제안요청서 배포 ▷ 제안서 및 견적서 제출(입찰) ▷ 제안 발표(프리젠테이션) ▷ 제안 평가 ▷ 우선협상대상자 선정 및 발표 ▷ 우선협상 및 계약 ▷ 사업착수 와 같은 순서를 대략 따르게 된다. 본 글은 이 중 제안서를 작성하는 부분에 대해 살펴볼 것이다.
1. 제안요청서 받기
IT시스템 구축을 위해 공공기관이나 기업체에서 입찰공고를 하고 사업설명회를 하고 제안요청서(RFP: Request For Proposal. 제안을 해달라고 요청하는 것)를 배포하면, 그 사업을 하고 싶은 IT업체들은 제안요청서를 받아 와서 제안서를 만들어서 제출하게 된다.
물론 아무한테나 다 제안요청서를 주는 것은 아니다. 발주처에서는 사전에 구축하고자 하는 IT시스템과 관련된 업체가 어떤 데가 있는지 조사하고 그 과정에서 각 업체의 영업 담당들이 발주처 담당자들과 만나 미리 이야기도 하고 접대도 해 주는 등의 과정을 거쳐 발주처의 낙점을 받은 업체들만이 제안요청서를 받아 그 사업에 참여할 수 있는, 즉 제안서를 내고 평가받을 수 있는 기회를 갖게 된다.
이렇게 사업공고가 나기 이전의 치열한 물밑작업은 각 업체의 영업맨들의 영역이다. 사업 규모나 내용, 그리고 발주처에서 사업결정에 대한 권한을 가진 사람의 스타일에 따라 다를 순 있겠지만 어찌 보면 제안요청서를 받기 전에 이미 어떤 업체가 수주할 것인가 하는 대략의 윤곽이 정해져 있는 경우도 많다. 그만큼 사전영업(전문용어로 프리세일즈 Free Sales 라고 하면 되겠다.)이 중요한 요소가 되는 것이다.
다만, 본 글에서는 영업적인 부분은 언급하지 않고 기술적인 측면에서 제안서를 만들고 제출하고 발표하는 과정을 서술해 보려는 것이니 혹여 영업 쪽의 역할이 왜 빠졌을까 하는 생각은 접어두시라.
2. 제안팀 구성하기
일단 제안요청서를 받은 업체는 회사 내에서 이 제안 작업을 총괄할 제안PM을 선정하고 일을 도와줄 사람들을 골라 제안팀을 꾸린다. 말이 제안팀이지 규모가 작은 업체의 경우엔 한두명이 몽땅 다 맡아서 하는 경우도 많고 일이 몰릴 경우 심지어는 혼자서 여러 개의 제안서를 동시에 써야 하는 경우도 허다하다.
제안PM을 선정하는 것도 대기업 계열의 대형SI인 경우에는 해당 분야의 경험자로 골라서 하겠지만 작은 업체의 경우엔 그냥 시간 남는 사람이 하거나 (그런 사람이 있을 리 없겠지만..) 아니면 대개 제안작업 하는 사람이 몇명 정해져 있기 마련이다. 보통 이런 사람들은 제안작업 뿐만 아니라 프로젝트 나가서 PM도 하고 프리세일즈도 하고 접대도 하고 하는 올라운드 플레이어인 경우가 많다. 작은 업체에서는 어쩔 수 없는 현상이다.
3. 제안요청서 검토하기
이렇게 제안PM과 제안팀이 꾸려지면 우선 제안서를 어떤 내용으로 써야 하는지, 발주처에서 중요하게 생각하는 부분이 뭔지 등을 정확하게 파악하기 위해 제안요청서를 면밀하게 검토한다. 검토 작업은 제안PM이 혼자 하거나, 대규모의 경우 제안팀 팀원이 각 전문 분야별로 분담하여 검토하기도 한다. 예를 들면 인프라 부문(하드웨어, 네트워크), 사업관리 부문, 업무 부문, 개발 부문 등으로 구분할 수 있다.
해외와 달리 국내에서는 제안요청서에 실제 구축할 시스템의 구체적인 내용에 대해 자세히 설명되어 있는 경우가 드물다. 국내 IT사업의 제안요청서는 거의 대부분 사전에 접촉한 업체들로부터 제안요청서에 어떤 내용이 들어가야 하는지에 대한 의견이나 정보를 수집하여 그대로 짜집기하여 배포해 버리기 때문에 정작 발주처에서는 해당 시스템 구축에 대해 충분히 고민하여 그 내용을 제안요청서에 담아내는 경우가 거의 없다고 보면 된다.
어쨌든 이렇게 제안요청서를 검토하는 과정에서 미비하거나 앞뒤가 맞지 않거나 불명확한 부분이 발견되면 그에 대해 발주처에 확인하는 등의 과정은 제안작업 기간 내내 계속 일어나게 마련이고 또 그렇게 되어야 정상이다. (이런 식으로 표현하는 이유는 그렇게 하지 않는 경우가 더 많음을 의미한다.) 그건 뒤에서 다시 언급하기로 하고 일단 다음 단계로 넘어가자.
4. 제안목차 정하기
제안요청서를 검토하면서 제안서를 어떤 내용과 순서로 작성할 것인지를 정하게 된다. 이를 위해 가장 먼저 제안서의 목차를 정의한다. 일반적으로 제안요청서에는 개괄적인 목차를 제시되어 있는 경우가 많으며 업체에서는 이 목차를 기준으로 하여 보다 상세한 세부 목차를 정의하게 된다.
IT시스템 구축을 목표로 하는 제안서의 경우, 대개 제안 목차는 다음과 같은 내용으로 구성된다. 순서가 바뀌거나 세부 내용에서의 가감은 있을 수 있으나 거의, 대부분의 목차는 이런 식으로 만들어진다. 이때 목차를 정하는 주체는 업체 규모나 조직에 따라 다를 수 있지만 대개 앞서 언급한 제안PM이 주도하여 담당자를 지정하거나 아니면 직접 정하게 된다.
제안서 목차 예시 펼쳐보기
이렇게 목차가 정해지면 각 항목별로 내용을 작성할 담당자나 업체를 지정하여 제안서를 작성하도록 할당한다. 이 때 제안서를 작성하기 위해 공통적으로 사용할 템플릿을 같이 배포하는데 주로 파워포인트로 양식을 만들어 사용하게 된다. 대형SI 업체의 경우 자체적으로 제안작업을 전담하는 팀이 따로 있어서 제안작업이 시작되면 PD(파워포인트 디자이너)가 제일 먼저 템플릿을 만들어서 제안팀에 배포하게 된다. 소형업체의 경우에는 제안담당자가 직접 만들거나 외부 전문PD에게 의뢰하여 작업하기도 한다.
5. 제안품목 정하기
제안요청서를 검토하고 목차도 정했다. 이제 제안서만 열심히 쓰면 게임 끝나는 건가?... 그럴 리가요. 남의 돈 먹는 게 그리 쉬운 일이 아니다. 제안을 할 때 구축 방안에 대한 내용을 만드는 것도 중요하지만 비용에 대한 부분도 중요하다. 그리고 비용은 크게 인건비와 하드웨어, 소프트웨어 등으로 구분된다.
제안작업을 할 때 가장 초반에 결정되어야 할 것 중의 하나가 바로 하드웨어와 소프트웨어 등 시스템 구축에 필요한 품목들을 어떤 걸로 제안할지 결정하는 일이다. 제품과 모델명 등을 결정하고 그다음엔 이 제품을 어떤 업체를 통해서 얼마에 공급받아서 발주처에 제안할 것인가 하는 걸 결정해야 한다. "제품 공급업체 선정 및 견적 작업" 이라는 우아한 전문용어를 사용하면 그럴 듯하게 정리된다.
시스템 구축을 위해 필요한 기간과 투입인원 등은 제안서를 작성하는 과정에서 결정되겠지만 전체 비용을 결정하기 위해 이 제안품목에 대한 결정은 반드시, 그리고 가능한 빨리 이루어져야 한다. 같은 사업에 입찰하는 경쟁업체가 많을 경우 이런 품목 결정 과정에서 업체들 간의 이해관계가 복잡하게 얽혀 복마전을 방불케 하는 더럽고 치사하고 황당한 꼴들도 많이 보고 당하고 저지르고 하게 된다. (난 보기만 했다..진짜로.. 영업 아니거든..) 그에 대한 비화는 나중에 심심하면 한번 알려 줄 수도...
6. 제안서 쓰기
본 글의 제목이자 가장 중요한 내용인 제안서를 드디어 쓴다. 근데, 이 제안서 쓰는 게 사업마다 내용이 다 다르기 때문에 어떻게 쓴다 라고 정해져 있는 게 없다. 그냥 제안요청서 보고 어떤 내용을 집어넣어야 고객이 감동 먹고 점수를 후하게 줄까를 고민하면서 있는 말 없는 말 다 때려넣어서 무조건 다 하겠습니다. 라는 취지로 쓰면 된다.
사실 제안작업을 하는 과정에서 개인적으로 가장 고민스럽고 짜증나고 번뇌를 느끼는 부분이 이거다. 체질적으로 거짓말하는 걸 무척 싫어하는데, 제안서를 쓸 때는 진실만을 말해서는 제안서를 제출할 수조차 없는 경우가 발생한다. 예를 들어 제안요청서에는 A라는 요건이 필수라고 되어 있는데 업체는 사실상 이 요건을 하는 게 불가능한 경우가 있다. 이럴 때 못한다..라고 하면 그냥 스펙아웃이 되어 버린다.
되든 안 되든 제안요청서에서 요구하는 내용은 일단 무조건 '할수있다' '해주겠다' 라고 제안서에 쓴다. 아니 써야 한다. 그렇게 강요받는다. 이 지점에서 내 자존심은 구겨지고 정직한 양심 따위는 개나 줘버려야 한다. (개는 무슨 죄냐...미안..)
급 마무리...
이렇게 해서 제안서를 멋지게 잘 만들어서 발주처가 정한 방식대로 기한 내에 무사히 제출하면 기술 파트 입장에서의 제안 작업은 일차적으로는 마무리된 것이다. 간단히 "제안작업"이라는 네 글자로 부르지만 막상 누구도 말해주지 않고 책에도 안 나오는 IT 제안서 쓰기에 대해 표현하려다 보니 애초 필자가 예상했던 것보다 내용이 매우 많이 늘어나야 할 것 같다.
그래서 일단 본 글은 이쯤에서 급 정리하고 다음 글에서 계속 살펴보기로 하겠다. 긴 글 읽어내리느라 고생들 하셨을 테니 맛있는 거 사 드시고 푹 쉬시라.
잘 통과 되는 제안서 쓰는 몇가지 뻔한 요령
출처: http://www.gamedevforever.com/153 [게임 개발 포에버]
프리랜서를 위한 프로젝트 제안서 쓰는 법
프리랜서를 위한 프로젝트 제안서 쓰는 법
프리랜서를 위한 프로젝트 제안서 쓰는 법
프로젝트 제안서를 쓰는데는 시간과 에너지가 참 많이 소요됩니다. 프로젝트 전반에 대해서 설명하는 것은 물론, 클라이언트가 바로 거래를 하자고 나설 정도로 매력적인 점을 어필해야 합니다. 물론, 비싼 요금 같이 클라이언트가 꺼려할 만한 것들에 대한 이야기도 포함되어 있어야 합니다. 프로젝트 제안서는 설득력도 있어햐 하지만, 동시에 프로페셔널 해 보여야 합니다.
프로젝트 제안서의 양식을 구성하라
모든 프로젝트에 제안서가 필요한 것은 아닙니다. 평생 단 한번도 제대로 된 프로젝트 제안서를 못 써보는 프리랜서들이 많은게 사실입니다. 그저 프로젝트에 대한 간단한 개요서나 클라이언트의 질문에 대한 답변을 제시하기만 해도 프로젝트를 따오는 데 큰 문제가 없는 경우가 많습니다. 하지만 보다 큰 프로젝트를 맡아서 일하려는 욕심이 있으시다면, 프로젝트 제안서 쓰는 법을 익히실 필요가 있습니다. 겨우 몇 문장 가지고 큰 예산이 들어가는 프로젝트에 대해서 설명하기란 불가능하기 때문입니다. 프로젝트에 여러 서비스가 포함되어 있다면, 각각의 서비스가 어떤 것인지, 클라이언트에게 어떤 도움을 줄 수 있는지, 가격은 얼마인지 듣에 대해서 자세히 설명해 주셔야 됩니다.
사업 제안서 없이도 클라이언트를 설득할 수 있다면, 굳이 수고롭게 프로젝트 제안서를 쓰실 필요는 없습니다. 다만, 제안서 쓰는 법을 연습할 필요가 있다면, 평소보다는 조금 더 많은 설득 포인트를 준비해두는 것이 좋습니다. 일회성 프로젝트를 하면서 굳이 그렇게 까지 할 필요가 있나 라고 생각하시는 분이 계실지 모르겠지만, 이런 연습을 해보시기를 권장합니다.
프로젝트 제안서를 쓰는 과정을 간소화하라
큰 프로젝트를 맡든 작은 프로젝트를 맡든 관계없이 언제나 사업 제안서에 꼭 들어가야 하는 내용이 있게 마련입니다. 그런 다음에야 사업 제안서를 쓸 때마다 그 부분을 새로 쓸 필요는 없습니다. 항상 들어가는 내용을 포함한 양식을 미리 만들어 두시면 편리합니다. 많은 매력있는 프리랜서들은 미리 이런 양식을 만들어두지는 않지만, 미리 써놨던 사업 제안서를 재활용함으로써 시간을 절약하는 방법을 사용하고 있습니다.
"사업을 시작하고 지금까지 쓴 사업 제안서가 벌써 수 백 개에요. 이 사업을 하기 전에 다른 일을 할 때 쓴 것까지 합치면 훨씬 더 많겠죠. 프로젝트 제안서를 여러 번 쓰면서 서비스나 다른 부분들에 대해 설명할 때 반복적으로 사용하는 표현이 생겼죠. 따로 양식을 만들어두는 건 아니지만, 자주 쓰는 표현 같은 것들을 미리 정리해두고, 프로젝트 제안서를 쓸 때마다 조금씩 고쳐서 쓰는 거죠."
굳이 완성된 양식을 하나 만들어서 새 프로젝트 제안서를 쓸 때마다 토씨 하나까지 똑 같은 제안서를 쓸 필요는 없지만, 그렇다고 해서 새 제안서를 쓸 때마다 완전히 새로운 표현을 만들어내려고 고생할 필요도 없습니다. 제안서를 쓸 때 예전에 써놨던 것을 펼쳐놓고 참고하면서 쓸 만한 표현들은 그대로 베껴오거나 조금 바꿔서 사용하시면 도움이 될 것입니다. 미리 양식을 만들어 놓고 사업 제안서를 쓰는 것에는 또 다른 장점이 있습니다. 급하게 사업 제안서를 작성하다 보면 평소에는 꼭 빠뜨리지 않고 넣던 내용을 빠뜨리는 경우가 의외로 많습니다. 사업 제안서에 넣을 내용의 목차를 미리 짜두시면 중요한 내용을 빠뜨리는 일을 막으실 수 있습니다. 모든 프로젝트 제안서에 무조건 들어가야 하는 내용은 없습니다. (가격에 대한 내용을 제외한다면 말입니다.) 모든 프로젝트가 다 같지는 않기 때문입니다. 그렇지만 자주 맡게 되는 종류의 프로젝트에 알맞은 제안서 양식을 미리 만들어 둔다면 도움이 될 것입니다.
클라이언트가 원하는 바를 파악하라
훌륭한 사업 제안서를 쓰는 비결은 클라이언트가 원하는 것이 무엇인지 정확히 파악하는 것입니다. 여기서 훌륭하다는 말은 곧 짭짤한 수입을 가져다 준다는 의미입니다.
"최고의 프로젝트 제안서는 바로 클라이언트를 설득하는 제안서입니다! 즉 (1) 프리랜서가 가진 능력과 (2) 사업 수완을 보여주고, (3) 클라이언트에 대해 얼마나 잘 이해하고 있는지를 보여주는 제안서가 바로 최고의 프로젝트 제안서입니다. 이 세 가지를 모두 충족하는 제안서를 쓴다면, 최고의 조건으로 거래를 성사시키는 건 이미 따놓은 당상이죠."
프로젝트 제안서를 쓰기에 앞서 클라이언트에 대해 자세히 알아두시기 바랍니다. 제안서를 작성하기도 전에 클라이언트와 만나는 경우가 많습니다만, 한 걸음 더 나아가기 나아가기 위해서는 이런 사전 조사가 필요합니다. 클라이언트 기업이 겪고 있는 경쟁의 양상, 산업 전반, 기타 클라이언트가 구체적으로 바라는 바에 대해 사전 조사를 한다면, 더욱 호소력을 지닌 프로젝트 제안서를 쓰실 수 있을 것입니다.클라이언트는 구체적인 문제를 해결하기 위해 프리랜서를 찾습니다. 이러한 관점에서 보면 기본적으로 제안서란 문제를 어떻게 해결할 것인지에 대한 제안이라고 할 수 있습니다. 하지만 이것이 곧 제안서를 작성할 때 클라이언트가 해결해달라고 부탁한 문제점만 고려하면 된다는 의미는 아닙니다. 클라이언트에 대해서 구체적으로 조사를 한다면, 클라이언트에게 도움이 될 만한 또 다른 방안이 있는지 파악할 수 있는 것은 물론, 여러 프리랜서보다 단연 앞서 나가게 것입니다..
옵션은 하나만 제시하라
보통 클라이언트에게는 구체적인 옵션 하나를 제시해주는 것이 좋습니다. 혹은 클라이언트가 고를 수 있는 딱 몇 가지 정도의 옵션만 제시하는 것도 방법이 될 수 있습니다. 이 말은 너무 많은 옵션을 제시해서 클라이언트가 무엇을 선택해야 좋을지 망설이게 만들면 안 된다는 뜻입니다.
"프리랜서의 서비스는 중국집 메뉴가 아닙니다. 너무 많은 옵션을 들이밀지 마세요. 클라이언트가 망설이다가 아무것도 선택하지 않을 수도 있으니까요. 물론 많은 옵션을 바라는 클라이언트도 가끔 있습니다."
제시하지 않은 옵션을 나중에 제시할 수는 있지만, 이미 제시한 옵션을 없던 것으로 하기란 쉽지 않습니다. 사업 제안서를 간단명료하게 쓴다면, 클라이언트에게 제안서 전체를 읽어줄 수도 있을 겁니다. 또, 제안서는 클라이언트가 이해하기 쉽게 작성하는 것이 좋으며, 클라이언트에게 익숙지 않은 단어나 전문 용어는 가급적 사용하지 않는 편이 좋습니다.
프로젝트 제안서는 단순 명료해야 합니다. 하시는 일이 글을 쓰는 일이라거나 화려한 미사여구를 붙이고 싶으셔도 이 원칙에는 변함이 없습니다. 사업 제안서를 받아볼 클라이언트가 받게 될 서비스가 어떤 것일지 최대한 명확하게 설명해주는 것이 좋습니다. 프로젝트 안서가 불명확하여 오해가 생기는 경우 그 책임을 프리랜서가 고스란히 떠맡는 경우가 있으니 주의하시기 바랍니다.
"하고자 하는 바에 대해 명확히 설명하세요. 예전에 사업 제안서에 말을 애매하게 적는 바람에 고생한 적이 많아요. 전혀 생각지도 못한 서비스를 돈도 못 받고 해준 적도 있고 말이죠."
마찬가지로, 요금을 부과하는 방식도 간단하게 설명해두는 것이 좋습니다. 클라이언트들은 대개 프로젝트 제안서를 받아 들면, 제대로 읽기 전에 먼저 프리랜서가 제시하는 최소 가격이 얼마인지부터 찾아보는 경향이 있습니다. 가격 책정 방식에 대해서 명확하게 설명하고, 제안서의 초반부에 최종 견적을 굵은 글씨체로 표시해두시면 좋습니다. 제안서 어딘가에 가격이 제시되어 있다하더라도 클라이언트가 못 찾는다면, 나중에 요금으로 인한 오해가 생길 수도 있습니다. 클라이언트가 프로젝트 제안서를 완전히 이해하도록 하기 위해서라면 직접 만나서 설명하는 것도 마다하지 않아야 합니다.프리랜서의 사업 분야가 무엇인지, 클라이언트 기업이 일을 처리하는 과정이 얼마나 복잡한지에 따라서 다르겠지만, 아마 클라이언트와 만나서 사업 제안서에 대해 설명하는 것은 굉장히 중요한 일입니다. 이런 만남을 통해서 프리랜서와 클라이언트는 질의응답 시간을 가질 수도 있고, 직접 얼굴을 대하고 만나기 때문에 서로의 관계를 돈독히 하는 데에도 도움이 되기 때문이죠. 접 클라이언트를 만나는 일이 다소 수고로울 수도 있겠지만, 그렇게 해서 거래를 따낼 수만 있다면, 그만한 노력이 헛된 것은 아닐 것입니다.
프로젝트 제안서는 다듬고 또 다듬어라
아주 조그만 오타만 있어도 클라이언트는 왠지 거래하기가 싫어질 수 있습니다. 프로젝트 제안서를 보내기 전에 최대한 많이 검토하시기 바랍니다. 밤을 새서 제안서나 프로젝트를 마무리하고, 그 즉시 클라이언트에게 보낸 후, 나중에서야 실수를 발견하게 되는 이런 일은 프리랜서에겐 그야말로 치명적입니다. 귀찮아할 수도 있겠지만 다른 사람에게 프로젝트 제안서를 검토해달라고 부탁하는 것이 좋습니다. 여러 번 읽었는데도 오타를 잡아내지 못하는 경우도 있기 때문입니다. 제안서를 처음 본 사람이 오히려 실수를 더 잘 잡아낼 수도 있습니다. 특별히 훈련된 사람이 아니라도 말입니다. 프로 편집자에게 프로젝트 제안서 검토를 부탁한다면, 시간이 많이 들지는 몰라도, 훨씬 더 좋은 결과를 얻을 수 있을 것입니다. 아마도 지금까지 쓴 어느 제안서보다도 좋은 제안서를 쓸 수 있을지도 모릅니다.
프로젝트 제안서 쓰는 연습을 게을리 하지 마라
프로젝트 제안서는 쓰면 쓸수록 나아집니다. 프리랜서로서의 경력을 쌓아가면서 당연히 제안서도 발전해야 합니다. 사업을 키워나가면서, 미리 작성해둔 양식이나 자주 쓰는 표현들 역시 계속해서 발전시켜 나가는 것이 중요합니다.
"대략 2년 동안 사업 소개를 할 때 똑 같은 글을 썼어요. 동료가 이제는 제 사업의 중점 분야가 바뀌었다는 걸 지적해주었을 때야 그걸 깨달았죠. 사업 소개와 같은 것은 반드시 시간이 가면 그에 맞게 내용을 수정을 해줘야 합니다. 이상하게도 저는 그 생각을 전혀 하지 못했던 거죠."
프로젝트 제안서를 쓸 때 다른 방식을 시도해 보는 것도 좋습니다. 클라이언트가 제안서를 요청하자마자 보내줘야 하는 급한 경우에는, 프로젝트 제안서를 쓰는 다른 어떤 방식이 있는지 충분히 알아보기가 힘들지만, 프로젝트 제안서를 쓰는 다른 방식에는 무엇이 있는지 등을 자세히 알아볼 필요도 분명 있습니다.