(퍼옴) 공공프로젝트 제안서 작성요령 1/4

https://blog.naver.com/joypia/222149926443

공공프로젝트 제안서 잘 쓰기 1/4

 

공공 SI 제안서 잘쓰기에 대해서 말하고자 한다. 이거슨 순전히 그간 경험에서 나오는 지극히 개인적인 생각임을 전제로 한다. 2편에서는 제안서 작성 요령에 대해서 살펴 볼 것인데, 그 부분은 조금 개관적이지 싶다.

​

1. 제안서를 잘 쓰기 위한 여건이 필요하다. 주변 환경이 좋을 수록 좋은 제안서가 나온다.

​

제안서 작성을 돕는 전문 조직(보통 제안지원 성격으로 팀명을 정한다)이 있어야한다. SI를 주 업으로 삼고 있고, 하도급으로만 일하지 않고 직접 입찰에 참가하여 주사업자로 프로젝트를 수행한다면 제안이 그 첫걸음이다.

이는 영업보다 앞선다고 감히 말할 수 있겠다. 영업하는 인력이 없더라도 제안에 참여는 할 수 있지 않는가.

​

​

가장 기본적인 제안조직은 이렇다. 팀장 1명, 기획 및 전략 1명, 진행 1명, 여기에 GD(디자이너)가 1명 있으면 훌륭한 팀을 갖추었다고 할 수 있다. 거듭 얘기하지만 이는 최소한의 구성이고, 회사 규모가 커질수록 그에 맞게 조직도 확장되어야 할 것이다.

각자 역할은 다음과 같다.

- 팀장 : 제안 지원팀 총괄

- 기획 및 전략 : 제안 진행 여부를 판단하고, 제안 방향과 전략을 수립

- 진행 : 보통 PO 라고 하며, 제안작성에 필요 모든 업무(제안팀 구성, 일정, 예산 편성 및 집행 등) 관리 및 처리

- GD : 제안서 템플릿, PT 디자인 및 내용 디자인 작업

​

어정쩡한 업체의 경우 이런 전문 조직 두는 걸 꺼리는 경향이 있다. 마치 유휴조직 같이 보이기 때문이다.해서 프로젝트 인력이나 신규 사업에 투입될 인력을 구하기 힘들게 되면 이 조직 인원을 투입하게 되는 불상사가 생긴다. 따라서 제안지원 조직은 설령 제안꺼리가 없어 놀고 있더라도 다른 용도로 전향하면 안된다.

전문조직이 있으면 다음과 같은 장점과 효과가 나타난다.

- 제안 트렌드를 알 수 있다

- 제안 전략이나 제안서 작성에 전문성이 생겨 업무의 효율성을 높힐 수 있다

- 제안 이력이나 QnA 등을 체계적으로 관리한다

- 당연히 수주 확률이 높아진다

'제안 지원'이라는 표현에서 알 수 있듯이 이들은 단지 제안을 잘 할 수 있게 서포트하는 조직이다.

제안서는 기술자가 작성해야 한다. 그들이 잘 쓸 수 있도록 가이드하고 작성 방법을 알려 줄 뿐이다.

제안팀 구성은 이들과 제안서를 쓸 기술자가 모여서 결성되는 것이다.

​

제안서를 쓸 별도의 공간도 필요하다. 제안은 말 그대로 아이디어가 도출되어야 하므로, 서로 의견을 나눌 수 있는 독립된 공간이 필요하다.

필요 구성은 다음과 같다.

- 독립 공간

- 토론하면서 적을 수 있는 화이트 보드

- 제안서나 PT를 리뷰할 수 있는 빔 프로젝트와 스크린

- 인터넷 라인

- 제안 전용 서버

- 프리터 및 파쇄기

- DRM 등 보안 솔루션 및 장치

​

​

그리고 원할한 두뇌 회전에 필요한 당 섭취를 위한 간식이 필요하겠다.

얼마나 창의적인 제안하겠냐고 생각 하겠지만 그래도 제안은 제안인 것이다. 보안을 철저히 할 필요가 있다.

출입은 물론 서버도 제안팀만 사용하게 통제하고, 제안 파일은 DRM 을 적용해 외부 누출을 차단해야한다. 혹시 제안룸이 투명한 유리로 되어 있다면, 제안서 리뷰나 PT 리뷰를 위해 블라인드도 준비하자.

​

2. 제안요청서 분석을 철저히 해야한다

​

제안요청서를 면밀히 분석하자

영업으로 부터 도전할 사업이 선정되고, 제안요청서(RFP : Request For Proposal)가 입수되면, 가장 먼저 제안요청서를 면밀하게 검토하는 것이다.

거듭 강조하지만 제안요청서 표지 부터 맨 뒷장 까지 전부 하나도 빠짐없이 면밀하게 검토해야한다.

요구사항만 중요한 게 아니다. 제출 양식 중 하단에 아주 작은 글씨로 되어 있는 부분을 무시했다가 제안 자체가 무효화 되기도 한다.

보통 공공SI 의 RFP는 다음과 같은 내용으로 되어 있다.

- 사업개요 : 사업추진의 필요성, 추진 경과, 주요 과제

- 대상 업무 현황 : 업무 현황, 정보시스템 현황

- 사업 추진 방안 : 추진전략, 추진체계, 추진일정

- 제안요청 내용 : 개요, 상세요구사항

- 평가 및 선정 안내 : 사업자 선정 방법, 제안서 평가 방법, 유의사항, 기타

- 제안서 작성 안내 : 제안서 작성 요령, 세부 작성 지침

- 첨부 : 제안서 관련 서식, 관련 서류, 기타

​

​

1) 사업 개요

제안서 1장을 작성하는데 참고해야할 귀중한 자료이며, 발주처가 이번 사업을 어떻게 정의하고 있는지 파악하여야 한다.사업의 전체 흐름과 큰 틀에서 사업을 이해할 수 있다.

제안서를 어떻게 풀어나가야 하는지, 어디에 중점을 두어야 하는지 알아낼 수 있어야 한다.

​

2) 대상 업무 현황

발주처 또는 유사사업을 수행한 경험이 있다면 크게 중요하지 않을 수 있다. 처음 도전하는 경우라면, 업무를 최대한 파악하고 사전에 발주처 담당자를 만나 무엇을 물어보고 어떤 정보를 요구하는지 결정할 자료로 활용한다. 처음 그 기관에 제안을 하면서 한 번도 방문 없이 제안서를 쓰는 건 이해하기 어렵다. 발주처 담당자의 친절 여부와 상관 없이 들이대고 정보를 받아와야 한다.

과거엔 정보를 폐쇄적으로 RFP를 작성해도 되었으나 7년전 부터 신 RFP 제도로 인하여 보다 구체적이고 자세한 내용이 나와 있어서, 충분히 질문 거리나 업무 파악에 필요한 자료를 요청할 수 있을 것이다.

​

3) 사업 추진 방안 : 추진전략이나 일정을 그대로 사용하면 안된다. 참조만 하고 제안사만의 추진전략과 사업 특성에 맞는 일정을 제시할 수 있어야 한다. 그냥 참조만 하는 자료되시겠다.

​

4) 제안요청 내용 : 제안서 3장을 기술할 가장 중요한 핵심 내용이다. 사실 이 부분이 신 RFP 제도에 의하면, 구체적으로 제시되어야 하나 여전히 허술하게 작성되어 있는 게 대부분이다. 잘 알거나 충분히 이해하는 항목이 아니라면 절대 유추하거나 상상하여 기술하면 안된다. 도저히 이해가 되지 않거나 모르는 부분은 반드시 발주처에 문의하도록 하자.

요구사항은 보통 10가지로 분류하여 제시괴고 있다.

- 기능 요구사항 : 일반적 과업 요구사항

- 성능 요구사항 : 응답시간 등 성능관련 요구사항

- 인터페이스 요구사항

- 데이터 요구사항 : 데이터 요건 등을 명시

- 테스트 요구사항

- 보안 요구사항

- 품질 요구사항

- 관리 요구사항 : 사업 진행에 관련된 각종 요구사항

- 지원 요구사항 : 교육 등 기타 사업 진행을 위한 지원에 대한 요구사항

​

3. 제안팀을 결성을 어떻게 하느냐에 이미 결판이 난다

​

자 RFP를 분석해 봤더니, 충분히 사업을 수행할 만하다고 생각이 들면, 이제 본격적으로 팀을 꾸려야 한다. 위에서 말한 지원 조직이 있든 없든 당연한 얘기지만, 기술부분을 담당할 인력이 있어야 한다. 비슷한 경험을 한 사람이 참여하면 가장 좋을 것이다.

​

​

제안서 내용 중 특정 요소 기술이나 솔루션 부분이 있다면, 그 부분은 해당 업체를 빨리 선정하여 제안서 작성을 요청해야 한다.

구체적인 액션 아이템은 다음과 같다.

​

1) 제안서 템플릿을 작성해서 작성자 및 업체에 배포

2) 제안 팀 구성

3) 제안 장소 선정

4) 대략적 개발비 산출 : 이익이 나지 않는 다면 제안할 이유는 급격히 줄어든다

5) 문제점 도출