iOS Code Repository (@davidbae): 제안서 쓰는 과정 정리

어느 회사에서든 제안서 쓰는 것에 대한 요구가 있습니다.
사장님께서 갑자기 오셔서,
- "이런거 이런거 되는 제안서 써서 가져가야 되니까. 만들어봐"
- "예, 사장님"
- "내일까지 알겠지?"
- "예?!!!!"

뭐 이런 대화가 다반사 일 겁니다.
이런 경우, 사장님의 의도와 제출하는 대상자가 어떤 것에 포커스해서 관심을 가지는지가 가장 중요해서, 그것을 알아내는 것이 제안서로 사랑받는 지름길이라 생각 되네요.

근데, 이런거 말고~

어떤 회사인 "갑"에서 RFP가 발송이 되고, 그것에 따라서 제안서를 작서하는 것에 대한 과정을 정리해 보고자 합니다.

우리 이통사의 경우에, 회사에서 친분이 있는 사람들에게 먼저 관련 주제에 대해서, 설명해 줄 수 있는지에 대한 요청이 먼저 들어옵니다.
그러면, 위의 과정과 같이 대략적인 정보만을 가지고, 대략적인 제안서 초안을 만들고, 들어가서 담당자를 만나게 되죠.
그러면 큰 그림이 나오고, 관련 정보를 "갑"담당자에게 주면, 머지않아서
RFP(Request For Proposal) 요청이 메일로 오게 됩니다. 안오면 뭐.. 내부 드롭된거고..
어떤 회사에서는 RFP를 Request For Payment로 사용하는 회사가 있지만, 대부분 제안요청서로 사용이 되죠.

http://blog.hrinmotion.com/wp-content/uploads/2008/06/rfp.jpg

1. RFP 분석

먼저 RFP의 내용이 무엇인지 파악해야 됩니다.
RFP에 있는 문구 들 중에서 이해가 되지 않는 부분에 대해서는 담당자에게 전화 등으로 문의를 해서 그 부분이 뭔지 확실하게 이야기를 들어야 합니다.
"갑"에서 RFP 제안 설명회를 하게 되는데, 그 전에 1차 분석을 마치고, 문의할 내용을 제안 설명회에서 문의할 것들을 정리해야 합니다.
정부과제가 아닌 경우, 공개적으로 RFP 대상 기업들을 불러서 설명회를 하는 경우가 드뭅니다. NIPA경우에는 설명회를 하지만... 대부분 서로 알면, 짜고 칠까봐 안 알려 줍니다.
이 경우, 회사를 차례로 불러서 질문을 하게 되는데, 이 경우 의도적으로 마지막 부분에 문의하는 경우가 좋습니다.
왜냐! 설명회를 먼저한 회사들의 질문들을 담당자가 다 알고 있기 때문에 "이런건 이렇게 해달라, 저건 이런거다" 등등을 다 들을 수 있습니다.
이 설명회에서 "갑"담당자에게 꼭 문의해야 되는 부분은 바로
RFP에서 가장 중요하게 생각하는 부분이 뭔지 담당자의 생각을 들어야 합니다. 그래서, 중요하지 않은 부분과 중요한 부분을 확실히 구분하는 것이 제안서 쓰는 인원들을 중요한 곳에 집중할 수 있게 해 줍니다.
그리고, RFP에서 요구하는 사항들을 나열해 보고, 그 사항이 맞는지 RFP담당자에게 문의를 해야 됩니다. 후에 이 요구사항이 개발할 때, 협상 대상이 되기 때문입니다.

요구사항들을 보고, 개발해야 되는 것의 명칭/이름을 생각해 보고, 그것을 구현하였을 때는 어떤 형태가 될 것인지 생각하고, 그림으로 표현할 수 있어야 제안서의 내용이 구체적인 것이 될 수 있습니다.

http://www.lenfantplazahotel.com/images/meeting_RFP_img.jpg

2. Go Point - 갈건가? 말건가?

RFP를 보고, 이번 제안이 회사에 도움이 되는지, 실현가능성은 인지를 결정해야 합니다.
이 때 결정을하고, 제안을 포기할 지, 전적으로 인원을 투입할 지 결정을 해야 됩니다.
또한 "갑" 내부에서 이미 회사를 선정했을 경우도 있습니다. 이 경우, 뒤엎을 가능성이 얼마나 있는지 조사한 후에 제안서 작업에 들어가야 합니다.
꼭 알아야 합니다. 선정이 이미 결정되있는데, 제안서 쓰느라 힘은 힘대로 빼고, 제안서 통과 못했다고 인사고과 밀리고, 욕먹고.. 쩝

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCFxNgndpmpyMgdUy2l3ejzdkvpjavK-pM9Bo5zS5aCiuLMGaBorOu_bFL8HY55KbDilTl6ivy9v4gyqxk88f2iOBxjLn16PSVc6c7Ox0WAFdgrkt41LmEwebBZgom3oPJizJkMfVCV4Ez/s1600/RFP.gif

3. 제안서 쓰기

제안서 틀을 만들자

제안서의 구성을 어떻게 할 지 생각하고, 전체 흐름을 잡아야 합니다.
틀에서 추가할 부분과 강조할 부분을 생각하고, 요구사항들을 빠짐없이 넣고, 어떻게 구현할 것인지, 실행할 것이지, 제공할 것인지 대략적인 흐름이 나와야 합니다.
이 흐름을 만들 때, 기획, 디자인, 개발팀에 팀장이나 담당자들이 참석해야 후에 수월합니다.
제안서로 쓰일 PPTX파일의 Template을 마련합니다. 나중에 합칠때, 수월하게 하기 위해서, 마스터 보기에서 Template들을 만들어서 배포해야 합니다. 아니면 나중에 정말 노가다 작업을 하게 되고, 보기에도 이상하게 됩니다.

제안서 1차 초안에서 담당자 선정

제안서 초안이 만들어 지면, 각 부분별로 담당자를 선정하고, 그 사람들에게 제안서를 쓰도록 지시를 해야 합니다.
이 때! 담당자들을 다 불러서 모아 놓고, 이번 제안서의 당위성과 가능성, 이후 어떤 일들이 있을지에 대해서, 이야기를 해 줘야 합니다.
이 과정이 제안서의 Quality를 좌우합니다.
제안에 참여하는 사람들이 제안서가 왜 중요한지 그리고 정말 어떻게 써야 가능성이 있는지를 공감할 수 있어야 올바른 제안서가 나오고, 좀더 창의적인 제안 내용을 모아 낼 수 있습니다.
필요하다면, 개발하는데 문제가 있음을 인정하고, 그것을 뛰어 넘을 방법을 수주 한 다음에 만들자고 인정하는 것도 필요합니다.
각 파트를 담당하는 담당자들이 해당 부분을 정확하게 이해 했는지, 반드시 확인을 해서, 다른 방향으로 흘러가지 않도록 해야 됩니다.
담당자에게 꼭 물어봐야 합니다. "이 파트는 어떻게 쓰실 거에요?"

제안서 1차 버전을 바탕으로 도식화 작업

제안서에 있는 각 부분을 설명하기 쉽도록 그림으로 표현하는 것이 중요합니다. 그림으로 초안을 잡고, 그 후에 디자이너가 작업을 하면 됩니다.
해당 페이지에서 제안하는 핵심이 뭔지 아래 부분에 1줄로 정리가 되어야 합니다. 제안 내용이 확실하지 않을 때는, 그 파트의 담당자를 불러서 설명을 듣고, 확실하게 이해를 해야 합니다.
이거 안되면, 나중에 발표할 때, '어버버' 거리게 됩니다.

제안서 내용에서 비교우위를 가질 부분을 체크

RFP에서 중요하게 생각하는 부분에 대해서, 다른 제안 회사들과 차별화 되는 부분이 뭔지 정확하게 나와야 합니다. 다른 회사에서도 이렇게 하면 되는 것이면, 차별화가 되지 않고, 별로 주목도 못 받습니다.
일단 우리 회사에서만 제공할 수 있거나, 우리회사가 이 부분에서는 경험이 많음으 증명할 수 있으면 좋습니다.
이것도, 저것도 없으면, 담당자에게 뭐가 중요할 것 같냐고 물어보는 것도 한가지 방법입니다. "갑"담당자가 까칠하게 나올 수 있지만, 안되면 질문을 해야죠.

제안서 작성 후에 전체적인 흐름에 따러서 재 배열

중요한 것을 어디서 강조할 것인지를 결정해야 합니다.
강조하는 부분에서 우리의 강점이 뭔지 확실하게 표현해야 합니다.

전체적인 틀이 나오면, 디자인 작업에 들어갑니다.

대부분 시간이 많지 않기 때문에, 제안 발표하기 5일 전이면, 제안서 작업을 많이 서둘러서 끝낸 편이라 생각됩니다.
경험상, 하루, 이틀 전에 디자인 작업에 들어가게 되는데, 이 때 디자인 팀의 반발이 대단합니다.
"우리는 뭐 발로하는 줄 아냐, 하루만에 이 많은 것을 어떻게 하냐!" 등등의 불만이 나오게 됩니다.
그래서, 위에 1번, 2번을 할 때, 디자인 팀장이나 디자인 담당자를 회의에 참석을 시켜야 합니다. 그러면 이런 작업이 언제까지 이뤄 질 것이며, 어떤 내용으로 진행되는지 알 수 있게 되므로, 필요한 작업을 준비하게 됩니다.
첫 페이지라도 디자인을 해두게 되므로 반발이 덜하고, Quality도 좋게 됩니다.
디자이너에게 회사의 분위기와 특징들, 제안서의 성향들을 말해 주고, 그거에 맞게 TP를 구성하도록 하면 좀더 Quality를 높일 수 있습니다.

http://www.webstock.org.nz/blog/2009/garr-reynolds-presentation-zen-master-class/

4. Presentation 준비

이제 어려운 부분이 남았습니다.
누가 할 것인가? 당연히 제안서를 중심에서 준비했던 사람이 해야 됩니다.
혹자는 잘 생긴 사람이 해야 된다고도 하는데, 잘 생기고 말 잘하면 금상첨화죠. 개인적으로는 기획팀 여성팀장이 발표하면 IT업계의 생기를 불어 일으킬 수 있고, 듣는 사람들이 대부분 남자들이므로, 더 어필이 가능할 것으로 보입니다.
전적으로 개인적인 생각입니다. 기획팀에 여자분이 안계셨던 관계로...
발표를 준비할 때, 듣는 사람이 편하게 들을 수 있도록, 어떤 스토리로 발표할지를 결정해야 합니다.
그리고 RFP를 어떤 배경에서 나오게 되었는지, RFP에서 가장 중요한 것이 뭔지, 스토리로 풀어서 설명을 시작하면서, 든는 사람들이 '제대로 이해하고 왔군' 이라고 고개를 끄덕이게 만들어야 합니다.
발표 시나리오 데로, 페이지를 그림으로 쉽게 쉽게 설명할 수 있도록 다시 만들고, 핵심 글자와 간단한 도식화 그림으로 표현하는 것이 좋습니다.
전체 요구사항을 카테고리로 나눠서 큰 묶음들로 각 부분을 설명하면 이해가 더 쉽게 됩니다.
마지막에 이 제안서에서 가장 강조할 것을 3가지로 압축해서 요약할 필요가 있습니다. 듣는 "갑"의 담당자들이 중요한 것을 어떻게 만족시킬 수 있는지 각인 시킬 수 있으면, 제안서 작업이 성공한 것이죠.
만약 잘못하면?????