처음 제안서를 쓰게 되었을때 어려움을 접하게되는점이 많은것 같다.
많은 제안 작업 중에서 처음 제안서쓰게 되었을때가 가장 기억에 남는데 그때 썼던 제안서를 아직도 보곤 한다. 잊지 않기 위해서인지 아니면 수중한 기억때문인건지...
이거랑 똑같이 쓰면 되니까 걱정 말라던 선임의 말을 믿고 출발했던 제안작업이 수포로 돌아갈때 그렇게 아무렇지 않게 얘기 했던 선임의 호통이 떠오른다.

뭘 잘못 한건지도 모르고 그걸 가르쳐주는사람도 없었으니까.. 나혼자 해결해야만 했었다.
절치부심하고 두번째 제안땐 정말 죽을힘을 다했던거 같다. 시간도 촉박했고 양도 많았다.
이런 저런 컨셉 잡는데만도 하루가 지나갔고 목적있는 제안을 위해서 여러가지 방법의 서브제안들을 만들어갔다.
그리고 하나로 합치고 다시 읽어 보고 다시 수정하고 제안결과는 수주였으나 기술평가(제안서의 평가)에서 조금 못미치는 근소한 점수차이였다.
무엇인가 다른 방법을 써야 하는데.. 항상 이런 생각들이 있었던것 같다.
세번째 부터 제안서 작성은 그렇게 신경쓰지 않았다.
장표 한장에 신경쓰는것보다 큰 틀을 우선 보았다. 제안요청서에 적혀 있는 담당자에게 연락해서 제안을 하게된 배경을 상세하게 물어보고 또 담당자로써의 고충들을 물어보았다. 그땐 그걸 제안요청서에서 못찾았기 때문에 물어본것이였는데 담당자는 좋은 인상을 받았던거 같다.
그리고 제안서를 쓰게 되니 무엇을 찾아서 무엇을 넣어야 하는지 확실하게 알것 같았다.
모르면 물어보면 되는데.. 그 담당자 얘기론 이렇게 물어보는 업체가 한번도 없었다고 한다. 그래서 더 답답했다고 했었다.
내가 원하는것은 이것인데 하나의 문서로(제안요청서) 전달되지 않는다는것이다.
그도 그럴것이 그 많은 제안 요건을 몇십장의 제안요청서로 어떻게 나열하겠는가?
솔찍하게 추가 했으면 하는 제안들도 많이 얘기 해주더라..
담당자와의 연락을 영업팀에 맡겨 제안서의 문서 작성만 하는것이 가장 잘못된 제안작업 인듯 싶다.

오래되지 않았지만 제안서 작업 시 그래도 이정도면 된다 싶은 몇가지의 사항을 정리해보았다.



1. 제안요청서의 담당자에게 물어봐라.
  • 담당자의 인식에 제안업체를 각인시켜야 한다. (이만한 영업이 있을까 싶다.)
  • 제안의 배경과 제안의 목적을 물어봐라.
  • 제안 내용 중 중요도를 체크 해라 (요소별 (기획/디자인/개발...)로 중요도를 물어보면 답은 나온다.)


2. 역지사지
  • 담당자로써의 고충을 본인이 생각해봐라
  • 담당자는 어떤 업체가 들어오는지 중요하지 않다. 어떤사람이 들어오는지가 중요하다. 자신의 생각을 읽는 개발자가 들어온다면 그것이 가장 중요한 제안의 내용이 될것이다. (간혹 정해놓은 업체가 있기도 하다 그것은 그 업체의 개발자들을 알기 때문이다.)


3. 제안의 목적을 가져라
  • 제안 작업 시 가장 중요한것은 제안의 목적이다.
  • 제안의 목적을 다방면으로 리스트업 해라
  • 중요도에 따른 분류로 최종 목적을 잡아라.


4. 추가 제안을 생각해라
  • 제안요청서의 내용만으로 제안서를 작성 한다면 그것은 제안이 아니다. (기본만 하겠다는 업체에게 손을 들어줄 평가위원은 없다.)
  • 추가 제안의 비용산정을 한 후 최종 목록을 뽑아라.
  • 추가 제안에 대한 표시를 해라 (장표에 유치하지만 별표를 한다던지 그냥 넘지지 못하도록 꼭 읽을 수 있도록 표시 해야 한다, 제안서를 평가 하는데 제안서의 디자인을 높이 보는데는 없다. 물론 눈에는 좋겠지만...)


5. 제안서 작업 완료 후 중요도에 따른 표시를 하라
  • 제안서의 모든 장표를 작성한 후 중요도를 체크 하라.
  • 중요도에 따른 표시를 눈에 띄도록 해라

기본적으로 제안서의 작업 보다 제안서 작업 이전의 행동들이 제안을 수주하느냐 못하느냐를 결정 하는것 같다.

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

  1. 2011.04.26 08:13

    역시~! 저번에 지적하신 사항을 잘 정리해주셨네요~^^

  2. 2011.04.27 06:16 신고

    조금더 편하게 읽을 수 있는 글쓰기가 가능했음 좋겠는데.. 그게 안되네요 앞으로 많이 연습해야할듯...ㅋㅋ 도움 되었음 좋겠습니다.


사이트 분석(착수 후)

초기 사이트의 분석이 끝나면 제안요청서와 제안서 기술협상에서 발생한 추가사항과 변경사항에대한 분석을 해야 한다.

사이즈 체크뿐 아니라 기능에대한 분석을 해야한다 리스크 발생요인을 체크하고 히스토리관리도 해야한다.

전체 사이트의 분석은 이정도의 수순으로 요구사항 분석 단계로 넘어간다.

이때도 작업 범위에서 벗어 나지 않도록 이해당사자들과의 협의가 중요하다.

상세한 분석과 히스토리관리 리스크 관리가 있어야 협의 시점에서 유리하게 이끌어 갈수 있다.


Posted by 김상환
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

SLA(service level agreement) 적용

 

요즘 공공기관의 RFP에서 자주보는 단어가 SLA다.

언제부터인지 SLA로 사업의 성공여부를 따지는듯 하다.

SLA를 높게 잡으면 그만큼 사업의 범위가 커질 수밖에 없다.

가능한 SLA범위를 잡는것이 중요하며 이범위는 사업의 전체 성공여부까지 결정할 수 있다.

솔찍히 SLA가 있어 검수단계가 깔끔해지는 경우도 있다.

SLA보고만 지나면 검수는 당연한결과이기 때문이다.

다만 기준치에 못미쳤을때의 대비가 가장 중요하다.

일별, 주별, 월별 기준치 체크를 하여 못미쳤을때의 대비방안도 마련하여 SLA의 기준치를 넘어서야 한다.

 

(예시 : 월별 SLA보고를 통하여 전반적인 서비스의 진척도를 나타낼 수 있다)

예를 들면 유지보수의 프로젝트에서 회원가입수와 PV수를 가지고 체크 하는 SLA의 기준을 잡았다면 유지보수 기간에 SNS의 활용과 각종 이벤트를 이용한 대비 방안을 마련하여 꾸준한SNS 활용(트위터, 블로그, 페이스북..)을 진행 하고 회원가입을 유도하는 다양한 이벤트를 진행 하여 SLA의 수치를 맞출 수 있어야 하는것이다.


Posted by 김상환
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

RFP(Request For Proposal)분석은 SWOT분석, 요구목록분석, 업무별분석(서비스별분석), 평가방식분석 후에 제안서를 작성해야 한다.



제안작업을 하다보면 기본을 지키지못하는경우가 있다.
제안서의 기본은 제안요청서에 있다.
제안요청서의 분석뒤에 제안서의 러프한 방향을 잡고 제안의 컨셉을 정한다.
뒤에 목차와 업무분장을 나눠 세부 장표를 도출한다.
뒤에 모든 장표를 확인하고 손을 봐야한다.
그리고 이 제안의 핵심을 클라이언트를 통해 습득하고 그에대한 장표가 돋보이도록 포장 그리고 추가제안을 하는것이다.
기본은 지켜야한다. 본전부터 시작해야 승산이 있다.
제안요청서를 분석하는 방법에는 다음의 방법이 있다.

  1. SWOT 분석
    기회의 요인과 위협의 요인을 장점과 약점으로 나누어 분석함으로써 제안요청서의 내용과 제안 수주의 확율을 확인할 수 있다.
  2. 요구목표 분석
    제안요청서에는 이번 사업의 목표가 있다. 이런 목표에 부합되는 제안서가 나와야 한다.
  3. 업무별 분석(서비스별 분석)
    업무(서비스)의 리스트를 나열하고 그에 대한 중요도를 체크 하여 제안서의 목차에 알아보기 쉽도록 작성 한다.
  4. 평가방식 분석
    보통 기술부분에 중점을 주어 평가를 하게 되는데 기술부분에도 이사업에서의 중요한 부분을 점수로 표시한다. 중요도에 따른 제안이 되어야 한다.

Posted by 김상환


Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

이전버튼 1 이전버튼