제안서

내부 제안서 (프로젝트 성공률 1% 높이기)

로

제안서. 내부? 외부?

기업에서 진행하는 제안서의 대부분은 외부 고객을 위하여 작성한다. 하지만 외부 고객 못지않게 중요한 것이 내부 고객이다. 하지만 그 중요성을 인식하면서도 제대로 된 제안하는 경우가 드물다. 물론 하지 않는 것은 아니지만 외부 고객에게 하는 만큼 신경을 덜 쓰는 경우가 많다. 하지만 내부 고객이 기본적으로 만족해야 대외적인 성과도 거둘 수가 있다. 
 
제안, 프로젝트 계획은 기업의 필수적인 경영 수단이다. 기업의 첫 시작뿐만 아니라 이미 운영이 되는 기업 조직에도 더욱 절실하다. 잘 작성된 내부 제안서는 경영진뿐만 아니라 실무부서에서도 중요하다. 이에 굳이 대내외 제안서를 구분해 본다면 어떤 면들이 있는지 살펴봐야 한다.
 
 

내부 제안서의 특징들

✅ 전략 방향
: 모든 제안이 그러하듯 가장 중요한 것은 방향성이다. 고객의 니즈가 파악되었다면 어떻게 문제를 풀어갈지, 이 해결책이 궁극적으로 지향하는 목표가 어디인지를 먼저 결정해야 한다. 그렇기 때문에 모든 방향을 염두에 두지만 필요하다. 이러한 결정에는 수많은 계획과 토론, 분석 등을 통해 오너십을 가진 당사자는 전략적 통찰력을 가져야 한다. 이는 저절로 얻어지는 것이 아니라 계획의 첫 단추를 꾀고 효과적인 이행을 위한 의도를 가지고 현실에 접근해야 한다. 모든 것에 주의를 기울이되 빠른 판단과 과감한 행동을 요구한다.
 
✅ 성과
: 제안은 성과를 거둬야 한다. 설득을 통해 가져갈 수 있는 조직을 위한 구체적 성과는 단순한 열매 이상의 과정이 필요하며 이를 통해 모든 구성원이 한 목표를 향해 나아갈 수 있도록 하며 개인과 조직의 성과를 연계하여 기업의 목표를 달성하도록 도와준다. 성과는 피상적이어서는 안 되며 매우 구체적이고 실현할 수 있는 기간 설정과 명확한 목표치를 가져야 한다. 이를 통해 우선순위를 결정하고 프로젝트 기간 내에 맞춰 움직일 수 있도록 조율한다.
 
✅ 성과 측정
: 모든 성과는 지표로 정량화되며 이 지표들은 반드시 명확하고 측정할 수 있는 목표를 제시해야 한다. 다시 말해 목표를 수립하고자 할 때 중요하게 몇 가지는 구체적이어야 하며 측정할 수 있어야 하고 이해당사자들의 합의가 이루어진 현실적이면서 실행 시기가 정해져야 한다. 원대한 목표 뒤에는 뚜렷한 성과를 뒷받침을 달성 방법도 개발하고 이해하여야 한다. 성과 측정은 이에 대한 근간이다.
 
✅ 협력
: 내부여서 장점도 있지만 오히려 이 장점이 프로젝트 진행을 더디게 할 수 있다. 여기서 공과 사는 명확히 발라내야 한다. 성과목표가 설정되고 이를 수행할 조직과 기간이 정해지면 동일한 목표를 위한 이해당사자들의 간의 협력이 매우 중요하다. 여기서 각 조직의 목표를 명확히 하고 구두가 아닌 문서로 공식적 의사소통 경로를 통해 세밀한 통제를 해야 한다. 그렇지 않으면 모든 관계가 동네 사랑방으로 전락하는 수가 있다.
 
✅ 의사소통
: 내부 프로젝트 또한 외부와 마찬가지로 의사소통이 매우 중요하다. 이 정점에는 경영진이 있어야 하며 그들의 의지를 기반으로 하여 공유하고 결정을 내려야 한다. 수면 아래 모든 이슈를 끌어올려 의제화해야 하며 이때 상하관계는 중요하지 않다. 지위에 따른 특권은 철저히 배제하고 프로젝트 관리자 중심으로 모든 것이 통제되고 관리되어야 한다. 특히 실무진의 참여가 필수이며 이들의 목소리를 들어야 한다. 내부 프로젝트는 공유야말로 프로젝트의 성패를 좌지우지한다.
 
✅ 임파워먼트
: 제대로 된 의사소통의 이면에는 원활한 권함 위임이 자리한다. 여기까지 된다면 내부적인 강력한 동기부여는 어떠한 프로젝트이던 성공적으로 마무리할 수 있는 가능성이 커진다. 모든 구성원이 자신의 업무로 프로젝트를 받아들이고 적극적으로 참여하며 자신감을 갖게 되는 비결이 여기에 있다. 신뢰와 믿음은 어떠한 위험도 긍정적으로 해소할 수 있는 힘을 갖게 한다. 자발적 움직임은 기대하지 않았던 곳에서 나온다.
 




 

계획과 실천

제안서가 작성된다. 여러 난관을 뚫고 하나둘 내용이 채워지는 가운데 여러 이슈가 도출된다. 특히 예산 부분은 내부 프로젝트라는 특성 때문에 여러 측면에서 불합리한 판단과 결정이 내려질 수 있다. 예산이 매우 중요하지만, 내부 자원을 투입하는 입장에서 평가를 내세워 제대로 된 계획이나 기준, 배분 등에 문제가 발생할 수 있다. 특히 인건비의 경우가 그렇다. 최악의 경우 내부 인력의 인건비는 급여로 대체되고 시장에서 평가받는 단가를 무시되어 버린다. 이 지점에 경영자와 직원 사이의 입장이 충돌할 수 있다. 
 
무엇보다도 수명업무를 가진 상태에서 프로젝트가 부가적인 업무로 추가가 될 때 프로젝트 구성원들의 불만은 최고조에 달한다. 평상시 100의 일을 하고 있는데 여기에 50이 더해지지만, 시간은 그대로인 경우가 많다. 정해진 업무시간에 모든 것을 하라고 하는 것은 대부분 내부 프로젝트를 병들게 하고 실패 확률을 높이는 가장 큰 원인이 된다.
 
예산의 그 편성과 계획을 분리하여야 한다. 계획은 최우선으로 주기별 예산을 수립해야 한다. 기업의 자금흐름을 바탕으로 투자와 비용지출을 구분한다. 전략을 바탕으로 계획 과정부터 전략 달성의 가능성을 테스트하고 모든 수단을 강구해야 한다. 예상 재무 효과를 평가하고 경영진의 판단과 참여를 적극적으로 유도하여야 한다. 그들이 설득될 수 있는 명분을 제시하고 행동해야 한다. 제안서는 문서에서 벗어나 행동력을 발휘해야 한다. 계획이 문자로만 존재하면 아무 일도 일어나지 않는다. 앞선 중요 요인 중 무엇 하나 빠지지 않게 관리하고 운영해야 한다.
 
내부 프로젝트라고 구성원들에 대한 헌신을 강요해서는 안 된다. 목표, 행동, 시기를 실시간으로 수정할 수 있어야 하며 소통하고 참여시켜야 한다. 쓸데없는 주인의식을 강요하지 말고 동의를 구하고 납득시키며 함께 나아갈 수 있는 길을 열어줘야 한다. 경영진의 관심이 사그라지지 않도록, 색안경을 끼고 보지 않도록, 잘못된 판단과 결정이 내려지지 않도록 항상 날을 세워야 한다. 그래서 내부 프로젝트가 외부 프로젝트보다 더 어려운지도 모르겠다. 
 
 
 
 
※ 과연? 과연!
내부 프로젝트가 제대로 끝난 경우를 나를 포함해서 주변에서도 잘 보지 못한 것 같다. 호기롭게 시작된 일들은 종단에 가선 흐지부지되는 경우도 많다. 어떤 경우엔 서로 상처만 가득 안고 헤어지는 경우도 많이 본 것 같다. 이미 잡아놓은 물고기여서 그런 것인가? 어디서 감히 이런걸? 이라는 생각들이 지배적인가? 눈에도 보이는 수많은 장벽을 깨지 못해서 그런가? 장을 만들어 줬다는 것만으로 내 일은 다했는 것인가? 몸과 마음이 피곤해도 오히려 밖에 나가서 일하는 것이 더 좋다고, 꼴보기 싫은 상황을 피하고픈 웃기지도 않는 상황들은 너무도 많다. 그러나 이 모든 것을 차치하고 내부 프로젝트가 망하는 가장 큰 몫은 경영진에게 있다고 감히 말해 본다. 그것이 편하다. 그리고 정말 맞다.

제안서(2) (프로젝트 성공률 1% 높이기)

로

제안서 프로세스

지난번 내용 중 제안서를 위한 일반적인 프로세스 6단계에 대해서 대략 정리하였는데 이를 좀 더 자세히 알아보자. 우선 제안서는 설득의 글이다. 다시 말해 단편적 지식의 나열이나 하나에 집중하기보다는 전체적인 맥락을 이해하고 하나의 이미지로 접근해야 한다. 그 중심엔 고객이 있다. 고객이 결정되고 나면 그 고객의 모든 것에 대해 알아야 한다. 
 
모든 것을 알기 위해선 먼저 기준이 필요하다. 그 기준의 부합 여부에 따라 전략, 전술이 달라진다. 기준은 가설에 따라 설정된다. 가설을 세우고 가설을 검증하는 과정을 반복하면서 우리는 고객에 좀 더 가깝게 접근할 수 있다. 물론 준비된 고객들도 있지만 대부분은 강한 니즈와 문제의식을 가지고 있으면서도 그래서 무엇을 하고 싶은지를 명확히 표현하지 못하는 경우가 많다. 
 
이 부분은 문제에 대해서는 잘 알지만, 문제점, 즉 원인을 파악하지 못하는 경우다. 문제와 문제점은 다르다. 가설을 세우고 검증하는 과정은 문제에서 문제점으로 접근하는 최단의 경로이다. 이를 통해 고객은 문제점을 인식하고 제대로 원하는 것이 무엇인지 표현할 수 있다. 제안서는 이를 도와주는 설득의 도구이다.
 
 

1️⃣ 정보 수집, 분석 및 가설 설정

가설을 세울 때 필요한 것이 무엇인가? 그것은 정보이다. 많은 정보를 획득할수록 제대된 가설 또한 수립할 수 있다. 물론 고객에 대한 정보가 아주 완벽하게 수집되었다 해도 이런 정보들을 친절히 알려주고 가르쳐 주는 고객은 거의 없다. 따라서 한정된 정보 속에서 우리는 실마리를 찾아내야 하는 것이다.
 
여기서 제대로 된 가설은 없을 수 있다. 가설이 맞고 틀리고가 아니고 당연히 잘못되어 있을 수도 있다. 하지만 가설을 통해 고객이 정말 중요하게 생각하는 점을 그려보는 것이 진짜 중요한 일이다. 가설이 없다면 중구난방 횡설수설할 수 있으며 정보의 중요도도 알아내지 못할 수 있다. 요구사항 아래 잠재적 요구사항을 끄집어내는 일 또한 우리의 일이다.
 
정보는 관점이 중요하다. 수집하되 하나의 단면만 보면 안 된다. 즉 고객, 경쟁사, 고객의 고객 및 거래처의 관점이 필요하다. 이를 통해 제대로 된 요구사항을 확인해 볼 수 있다. 또한 정보는 숨어있는 부분도 많다. 그래서 일반적인 정보와 더불어 고객에게서 입수해야 할 정보도 꼼꼼하게 챙겨야 한다.
 
수집, 획득된 정보는 면밀한 분석이 필요하다. 그와 동시에 가설을 준비한다. 가설은 정보수집의 관점들을 토대로 고객의 장단점 및 기회와 위기를 참작한다. 또한 제약조건은 두지 않고 고객의 눈높이 맞춰 설정해야 한다. 가설은 검증(사실임을 증명할 가능성, 거짓임을 증명할 가능성, 결과에 대해서는 재현 가능성)할 수 있어야 하며 더 간단하거나 정확한 방법을 설명할 수 있다면 다시 설정해야 한다.
 
 

2️⃣ 요구사항 정리

요구사항 정리는 가설의 정리라고도 할 수 있으며 일종의 사전 제안서 형태로 할 수 있다. 여기에는 설정한 가설을 구체적으로 기술하고 고객 요구사항과의 일치성, 또한 어느 부분이 잘못되었는가를 확인하고자 함이다. 이를 통해 수집된 정보를 제대로 분석했고 이해했는지, 잠재적 요구사항들이 도출되었는지도 가려낼 수 있다.
 
이러한 사전 제안서는 가설검증의 도구라고 보면 된다. 그렇기 때문에 세밀하고 구체적인 내용으로 정리해야 한다. 명확하지 않으면 안 된다. 그래서 정성적인 부분도 정량화하는 노력이 필요하다. 또한 하나의 사실에 대한 주변 인터페이스를 살펴야 한다. 누구에 의해서, 누가 작성했고 어디에 쓰이는지, 그 결과는 무엇인지를 명확히 알아야 한다. 정보의 객관화가 여기서 필요하다. 정보의 논리 근거가 필요하다.
 
 

3️⃣ 인터뷰 및 가설 검증

준비된 자료를 바탕으로 가설이 맞는지 검증하는 단계이다. 이때 주된 방법은 인터뷰이다. 다만 목적을 명확하게 하는 인터뷰를 준비하여야 한다. 경청을 기본으로 알고 싶은 내용을 관계자에게 질의응답 방식을 통해 정보를 확인하고 알아내기 위함이다.
 
우리가 대화 속에서 정보를 획득하는 것이 쉬워 보일 수도 있지만 이는 대단히 어려운 일 중 하나다. 그래서 관련한 여러 기술들을 참고해 볼 수도 있는데 그래서 많은 경험 또한 필요한 부분이다. 특히 인터뷰의 목적을 명확히 하는 것은 여러 인터뷰 방식 중 우리는 정보수집을 위한 인터뷰를 하려 하기 때문이다. 이를 중심으로 설득 또한 같이 진행하게 된다.
 
인터뷰는 인터뷰 대상자를 선별한다. 대상자가 누구냐에 따라 그 결과는 천차만별이다. 그러므로 아무나 대상자로 하면 시간과 비용만 낭비된다. 실무자인지 관리자인지 혹은 경영자층인지에 따라 정보의 양과 질이 다르다. 그래서 수집된 정보의 분석이 필요한 것이다. 대상자가 선별되었다면 질문을 준비해야 한다. 질문의 목적을 통해 다양하게 준비하고 리스트를 만들어 관리한다. 
 




 

4️⃣ 결과정리

인터뷰가 진행된다. 앞서 언급했듯이 그 목적이 중요한 만큼 인터뷰 대상자에게 목적을 알리고 최대한 협조할 수 있는 분위기를 조성한다. 이 부분은 의사소통의 스킬을 기반으로 대상자에게 어떠한 부분에 관심이 있는지, 그들의 입장이 무엇인지, 그리고 대답하기 곤란하지 않은지 면밀히 살펴야 한다.
 
인터뷰가 끝나면 그 내용을 제안에 반영하기 위해 가설을 검증하고 수정을 진행한다. 만약 가설이 고객의 요구사항과 일치하면 상관이 없지만 그렇지 않다면 계속 반복, 피드백하여야 한다. 그러기 위해선 인터뷰 내용을 잘 정리한다. 별도 회의록을 만들어 작성하고 필요시 녹취 등을 통해 정보의 유실을 막는다. 
 
인터뷰 내용을 기술할 때 가장 중요한 점은 인터뷰에 참석하지 않은 인력이 그 내용을 보더라도 당시의 내용은 물론 상황까지도 알 수 있도록 쉽게 써야 하는 것이다. 그러기 때문에 답변의 뉘앙스까지도 잡아내야 한다. 그러한 미묘한 차이점이 중요한 의미를 지니고 궁극엔 결과도 다르게 나타날 수 있기 때문이다.
 
정리된 회의록을 통해 가설 검증을 수행하고 문제가 있다면 수정작업을 진행한다. 이는 why, what, where를 명확히 하는 작업이다. why와 what이 명확해질 때까지 계속 확인을 하며 이를 통해 제안범위가 최종적으로 확정된다. 이 세 부분이 스스로 납득이 간다면 이제 최종적인 제안서 작성에 들어갈 준비가 된 것이다.
 
 

5️⃣ 제안서 작성

제안서는 템플릿이 많다. 하지만 고객사가 제공하는 경우도 있을 수 있기 때문에 큰 제약이 되지는 않는다. 형식도 중요하지만, 내용이 더 중요하기 때문이다. 그래서 작성에 많은 신경을 써야 한다. 다른 것도 마찬가지지만 제안의 제목은 확정이 되었기 때문에 제일 어려운 장애물은 제거되었다.
 
그다음 할 일은 목차를 작성하는 것이다. 사실 제목과 목차가 전부이다. 대부분은 제안서에서 제목과 목차가 차지하는 비중은 80%이다. 나머진 사전 제안서를 바탕으로 내용을 채워 넣는 일이기 때문이다. 목차를 통해 스토리를 구성하고 조립한다. 소설처럼 극적인 장치도 마련할 수 있다. 이런 부분은 물론 충분한 논의와 사유가 있어야 하지만 목차 구성만으로도 우린 상대를 설득할 수 있어야 한다.
 
제안서는 그 범위와 경중 등에 따라 혼자 쓸 수도 있고 팀으로 작성할 수도 있다. 최대한 간결한 표현으로 간단하게 이해할 수 있도록 작성해야 한다. 오해가 없어야 하며 사실에 근거하여 기술한다. 여기서 금물은 많이 써봐서 혹은 잘 쓰기 때문이라는 과신이나 선입견이다. 그래서 다양한 관점의 검토가 필요하다. 작성된 제안서는 반드시 객관적 입장에서 평가를 할 수 있는 사람에게 검토받아야 한다.
 
 

6️⃣ 발표

큰일이 모두 끝났다. 하지만 대미를 장식할 더 큰 일, 발표가 있다. 제안은 발표로 완결된다. 제아무리 훌륭하게 작성된 제안서도 어떻게 발표하느냐에 따라 그 결과는 달라진다. 다르게 이야기하면 미흡한 제안서라 할지라도 훌륭한 발표를 통해 제안 기회의 불씨를 살릴 수도 있다는 것이다. 
 
이렇게 중요한 발표는 제안서를 완전히 체화한 발표자를 중심으로 열의와 의욕을 불태워야 한다. 당연히 기술력을 기반으로 고객에게 신뢰를 주어야 하며 요구사항을 제대로 충족시켜 주어야 한다. 고객의 혼란을 야기할 정보들은 정리가 되어야 하며 누구에게 제안하는지, 왜 무엇을 하는지를 확실히 하고 넘어간다. 이를 통해 작성된 스토리에 고객이 동감하고 감동하며 진실한 태도에 고개를 끄덕일 수 있다.
 
 
 
 
※ 무늬만 대표자? 
정말 힘들게 작성한 제안서를 들고 가서 보기 좋게 말아먹는(?) 발표자가 있다. 이는 제안에 참여한 모든 이들을 배신하는 것이다. 그런데 그것을 잘 모르는 발표자가 많다. 대부분은 아니지만, 발표자라면 제안서를 완전히 씹어 먹고 내 것으로 만들지 못한다면 절대 발표하면 안 된다. 왜냐면 발표하면서 내가 얼마나 이 제안에 진심인지가 낱낱이 드러나기 때문이다. 고객도 당연하지만 발표하는 자기가 가장 잘 안다. 발표자 자신이 직급이 있다고, 대표성이 있다고 자신할 것도 아니다. 혼자 잘난 체할 것도 아니다. 남이 다 차려놓은 밥상에 숟가락을 올리지 말고 그 밥상 차림에 일조하길 바란다. 이 자리를 위해 고생하고 애쓴 사람들을 봐서라도..

제안서 (1) (프로젝트 성공률 1% 높이기)

로

제안서?

개발자라는 직업은 많은 능력과 역할이 필요하다. 이는 단순하게 개발에만 국한되어 있지 않다. 모든 것이 개발이지만 개발자가 생각하는 개발은 보통 코딩 또는 프로그래밍만을 생각한다. 하지만 개발이라는 수명주기를 놓고 본다면 프로그래밍은 전체에서 약 20% 정도밖에 차지하지 않는다. 나머지는 기획, 관리, 의사소통, 문서 등 프로젝트 전반의 모든 구성 요소들이 차지한다.
 
‘저는 개발만 하렵니다.’라고 생각한다면 그 넓은 운동장에서 구석 한 귀퉁이에 앉아 모래 장난을 하는 것과 다르지 않다. 특히나 문서로 의사소통하는 프로젝트에서 그 시작 지점의 제안은 누군가가 만들어 주는 것이 아니다. 개발자에게 계속 요구되는 능력 중의 하나로 IT에 관련한 모든 기업, 조직과 인력들에 주어진 과제이다.
 
고객에게 구두로만 내용을 전달할 수는 없다. 결국 손에 문서를 쥐여주어야 하고 그 내용을 그대로 만드는 제안서는 어떠한 방법을 써서라도 부가가치를 높이면서 고객에게 제안한 모든 가치를 인정받을 수 있게끔 작성이 되어야 한다. 그래서 준비 여하를 막론하고 이 과정에서 수많은 시행착오를 거치기 마련이다.
 
제안서는 누가 써주지 않는다. 그 기저에는 개발자가 있다. 그리고 그 개발자가 경력이 쌓이고 시간을 누적하면서 제안개발의 능력을 키우게 된다. 나 자신뿐만 아니라 고객에게 눈을 맞출 수 있으며 고객의 문제에 한 발짝 더 가까이 다가가고 모든 기회를 확대하면 제안에 성공할 수 있다.
 
 

변화무쌍한 제안서

제안은 영업활동이다. 영업은? 개발이 아니다. 그래서 개발자들은 대다수 제안을 남의 일이라고 생각한다. 사업 초기 영업맨들이 열심히 과제를 따와서 제안서를 쓰고 모든 것이 다 된 이후 전달이 되면 그때부터 내가 하는 일이 아니다. 물론 제안과 개발을 분담하는 것이 자연스럽다고 볼 수 있으나 시스템을 만드는 입장에서는 제안은 개발이다.
 
개발자가 제안하고자 한다면, 그 기저에는 다음과 같은 자세와 능력이 필요하다.
 
✔️ 충분한 기술력: 문제 해결력이다. 
✔️ 의사소통 능력: 고객의 요구사항을 제대로 확인할 수 있어야 한다.
✔️ 고객의 문제를 객관화: 명확하고 구체적인 사실에 입각한다.
✔️ 적극적 해결책 모색: 관망이 아니라 수행이다.
✔️ 고객 만족과 매출 확보: 이익 창출
 
즉, 풍부한 IT 지식과 경험을 토대로 한 다양한 문제 접근과 해결책을 강구하고 이에 따른 고객의 요구사항을 만족시킬 수 있는 능력은 개발자만이 할 수 있다. 그래서 단순하게 돌아다니는 템플릿을 하나 가져다 베끼듯 제안서를 만드는 것이 답일 수는 없다. 목적을 달성하기 위한 제안서는 체계적인 프로세스가 있고 도구들이 있다. 
 
또한 제안서는 의사소통의 결과이다. 의사소통을 원활히 하기 위해서 정보를 획득하여 분석하고 목표를 위한 동기를 부여하며 여기에 기반을 둔 최적의 실현 방법을 통한 설득에 있다. 원활한 의사소통은 고객과의 약속을 문서화하며 계약이 된다. 그럼 계약서에는 무엇을 담고 있어야 하는가? 무엇을 전달해야 하는가?
 
✔️ 배경, 현상, 이유: 왜 프로젝트를 하려 하는가?
✔️ 목적과 목표: 프로젝트의 성과는 무엇인가?
✔️ 제안 범위: 시스템화(견적 요건)의 대상은 무엇인가?
✔️ 수단과 방법: 어떻게 구현할 것인가?
✔️ 일정: 납기와 산출물은 무엇인가?
✔️ 체계: 프로젝트 추진은 어떻게 하는가?
✔️ 비용: 투자 판단의 근거는 명확한가?
 
위의 내용 중 가장 중요한 것은 무엇인가? Why와 What일 것이다. 이것이 명확해야지만 나머지 내용들이 의미를 갖는다. 고객이 처한 여러 현상과 문제들, 요구하는 배경과 프로젝트의 필요성, 그리고 문제들을 해소할 구체적인 프로젝트 성과들이 그것이다. 이 배경과 목적은 결국 비즈니스이다. 상호 간의 관계의 정확한 이해가 비즈니스를 알아내는 것이며 이후 제안의 본격적인 작업이 시작된다. 비즈니스를 이해하지 못하면 제안서는 오만가지 형태로 나온다. 이것도 답인 것 같고 저것도 답인 것 같다. 제안서가 달라지는 것은 그 원인을 파악하지 못함에 있다. 제안서는 절대 변화무쌍하지 않다.
 




 

제안서 프로세스

제안서를 위한 일반적인 프로세스는 보통 6단계로 되어 있다. (물론 발주처와 공급처의 입장에 따라 다를 수는 있겠지만 큰 틀에서는 하나의 동일한 흐름이다.)
 
1️⃣ 정보 수집, 분석 및 가설 설정: 고객 정보를 토대로 과제나 요구사항에 대한 가설 수립
2️⃣ 요구사항 정리: 요구사항 도출을 위한 초기 제안
3️⃣ 인터뷰 및 가설 검증: 경청과 검증, 전략회의
4️⃣ 결과정리: 수정과 반복, 확인, 제안팀 구성
5️⃣ 제안서 작성: 명확한 배경과 목적에 대한 해결책 구성, 제안 요약, 제안서
6️⃣ 발표: 고객 설득과 제안 목적 달성
 
앞서도 이야기했듯이 배경과 목적을 알아내기 위한 작업이 우선이 되고 제안서 작성은 그 이후의 일이다. 제안서 작성 전까지 1️⃣에서 4️⃣는 지속, 반복된다. 이를 통해 제안서를 성공시키기 위한 키를 확인한다. 그것은 가설이다. 고객 요구사항을 명확하게 끌어내는 일은 가설을 세우고 그 가설을 검증하는 것이다. 가설은 막연하게 흩어져 있는 여러 사안을 구체화하여 고객과 함께 잠재적인 요구사항까지 명확하게 도출하여 형태를 갖추면 된다. 흔히 고객이 가장 잘 알 것 같지만 의외로 고객 스스로 요구사항을 명확하게 정의하는 일은 드물다. 그래서 개발자가 컨설팅하며 가설을 만들어 검증하는 것이다. 혹 가설에 문제가 있다면 다시 만들면 된다.
 
 
 
 
※  제발 개발만 하게 해주세요!?
일하다 보면 다양한 사람들을 만나게 되는데 가끔 당황스러울 때가 있다. 특히나 신입도 아닌 경력 있는 ‘능력자’들이 자신의 주된 직무를 강조하며 오로지 그것만 할 수 있게 해달라는 것이다. ‘개발만!’, ‘영업만!’, ‘마케팅만!’. 이렇게 ‘무엇!’만을 할 수 있게 해달라고, 자신을 다른 일에 엮이지 않게 가만 놔두라는 요구가 과연 가능한지, 맞는 것인지 되물어 보지 않을 수 없게 한다. 이는 자신을 스스로 작은 방에 가두는 일이며 당장은 편하고 신경 쓸 일이 없겠지만 추후엔 아무것도 할 수 없음을 모르는 것일까? 그저 눈 앞의 뭔가를 회피하기 위한 것이라면 다시 생각해 볼 일이다. 회사 차원에도 매우 심각하게 받아들여지는 이런 태도들은 결국 개인과 회사 모두에게 득이 될 것은 전혀 없다. 전혀!

프로젝트 제안 (프로젝트 성공률 1% 높이기)

로

프로젝트 발주

프로젝트 발주는 고객의 니즈를 내부적으로 충족할 수 없는 경우 조직 외부로부터 제품, 서비스 또는 특정 결과물을 조달하는 것이다. 이를 전담하는 인력은 흔히 발주 PM이나 발주업무 담당자라고 볼 수 있는데 실제 프로젝트를 진행할 PM의 입장에서도 프로젝트 배경과 필요성을 제대로 파악하는 것이 프로젝트의 요구사항 분석과 성공을 위한 필수적이다.
 
발주는 공개적인 방식 또는 제한된 정보망 등을 통해서 공유된다. 사업자들은 항시 발주 이벤트를 주시하고 있으며 언제든지 진행할 준비를 하고 있다. 누가 먼저 소식을 접했느냐도 중요하지만 제한된 시간 내에 모든 역량을 투입할 수 있는 여건도 또한 중요하다. 어찌 보면 중요하지 않은 것이 하나도 없다.
 
 

프로젝트 제안

제안서는 프로젝트 사업자 선정을 위한 기술평가를 통해서 수주 경쟁화한다. 이를 통해 사업제안자들의 사업수행역량을 체크하고 각 제안 별 핵심 사항과 역량 검증을 통해 최적의 사업자를 하나둘 선별해낸다. 이런 제안의 흐름은 일반적으로 다음의 단계를 거친다.
 
🚩제안요청서
 : RFP(Request For Proposal)라고 말하는 것. 사업에 대한 고객의 세부적 요구사항이 정의되어 있고 제안을 위한 기본 틀과 요건을 제시한다. 다양한 형태의 제안서가 존재하지만 가장 중요한 것은 원하는 것이 무엇인지, 이를 통해 최종 결과물의 이미지가 무엇인지 명확하게 제시하는 것이다. 가끔 고객 스스로가 무엇을 할지 제대로 모르면서 부실한 RFP를 내는 경우가 있는데 이건 시장에서도 매력도가 떨어지며 그 누구도 참여할 이유를 찾지 못하기에 이 또한 잘 만들어야 한다. 그러기 위해선 고객도 공부가 많이 되어 있어야 하며 자신들의 약점과 강점을 알고 조직적인 대응을 해야 한다.
 
🚩제안서
: RFP가 뜨고 나서 사업을 검토 후 제안에 응할 목적으로 작성하는 것. 사업을 어떻게 수행할지 포괄적으로 정리하며 고객이 평가를 통해 결정할 수 있는 근거 자료와 신뢰를 줘야 한다. 즉, 요구사항에 대한 구체적인 방안과 제안사의 사업수행 능력을 명확히 보여줘야 한다. 여기서 최우선은 고객 만족이다. 이를 우선순위로 내용을 작성하며 사업수행을 위한 다양한 투입자원을 고려하여 현실적인 사업 범위를 결정, 제시한다. 특히 경쟁사 대비 차별화는 추후 POC(Proof Of Concept) 나 BMT(Bench Marking Test) 등을 염두에 두고 변별력을 가질 필요가 있다.
 
🚩계약
: 선발된 다수명의 심사자 및 심사조직을 통해서 제안심사가 진행된다. 몇 단계에 걸쳐 심사 결과들이 발표되기도 하는데 계약 성사를 위해 제안서를 토대로 제안프로젝트를 본격적으로 진행한다. 제안 분석과 전략 수립, 목차를 구조화하고 핵심 내용을 선별 후 예상 질의까지 준비한다. 제안발표를 하고 당 제안이 타당하다고 평가되면 사업자가 선정된다. 협상을 통해 최종사업자를 가리게 되면 계약이 진행된다. 계약에는 RFP와 제안서를 토대로 여러 법리해석과 최종견적이 완성된다. 사업 대가는 프로젝트 단계별로 고려하고 규모와 자원투입, 시간을 기준으로 산출한다.
 




 

RFQ, RFI, 그리고

프로젝트 발주를 위한 RFP는 봤는데 이와 비슷한 RFQ, RFI, RFB 등 여러 용어도 볼 수 있다. 이것들은 프로젝트 진행을 위한 분야별 세부 확인을 위해 쓰이는 것들인데 주요한 것만 살펴보면 RFI(Request For Information)는 사전정보요청으로 RFP를 작성하기 전 프로젝트에 필요한 여러 정보나 환경 등을 파악하기 위한 자료로 쓰인다. 특히 기술 부분에 있어 내부 역량에 따른 외주 여부 등을 사전에 파악해 볼 수 있으며 일차적인 필터 기능도 포함한다. RFQ(Request For Quotation)는 제안 견적요청서로 예산 중심의 문건이다. 즉, 적절한 프로젝트 비용을 파악할 필요가 있는데 RFP 요청 시 RFQ도 같이 요구하는 경우가 많으며 두 문건을 같이 검토하여 평가의 기초로 다룬다.

 

프로젝트 수주

제안서 작성의 최종 목적은 프로젝트 수주이다. 아무리 제안서를 훌륭하게 작성하였어도 프로젝트를 수주하지 못하면 그 제안서는 아무런 의미가 없다. 결국 가격 부분을 제외한 나머지 부분, 제안사는 고객의 이번 사업을 다른 누구보다도 잘 이해하고 있으며, 최고의 솔루션(제안된 솔루션을 이행할 계획과 인력, 기술, 그에 대한 풍부한 경험)을 제안하여 제안사를 선택할 경우 성공적인 프로젝트를 수행할 것을 보장한다는 내용을 빠짐없이 담고 있어야 한다. 제안서는 고객의 요구사항을 정확하게 파악하고 고객과의 원활한 커뮤니케이션, 구체적 서비스 내용을 제안서에 어떻게 표현했는가에 따라 그 결과가 좌우된다.
 
다시 말해 제안서는 단순한 제안 문서로서의 의미보다 제안 업체의 사업역량의 위상을 표현하는 최고의 서비스 상품이 되어야 한다. 그렇기 때문에 사업자 스스로 질문과 답을 해야 하고 고객 이전에 먼저 설득이 되어야 한다. 그러고 나서 고객을 설득한다. 그러기 위해서 정말이지 어디에 내놔도 당당한 제안서라는 상품을 만들 필요가 있다.
 
 
 
 
※ 템플릿
요즘처럼 넘쳐나는 정보 속에서 자료가 없이 일을 못 했다는 건 말이 되지 않는 세상이 되었다. 그런데 정작 중요한 것은 형식도 형식이지만 내용이 먼저다. “고객이 원하는 것이 무엇인가?”에 대한 깊은 고민은 책상 앞에서 만으론 해결되지 않는다. 그러니 틀이 짜졌다면 열심히 더 뛰어다녀야 한다. 그러면서 체득한 내용들을 채워 넣어야 한다. 그러나 지금 당장 일어나 움직이자!