사업수행계획서가 과연 필요한가

머 거창(?)하게 제목을 붙였지만 어디까지나 개인적인 생각이다.

 

  공공SI를 하기 위해 계약과 관련된 문서 중 가장 비중이 큰 세 개가 있다. 보통 RFP 라고 하는 제안요청서, 이 걸 보고 밤새워 업체에서 만드는 제안서, 그리고 수주하게 되면 10일 이내 만들어 내는 사업수행계획서가 그 것이다.

이들의 의미를 생각해보자.

확실한 근거를 찾기 위해 여기 저기 뒤져야하지만 매우 귀찮은 관계로, 그냥 내가 이제껏 들어 왔거나,혹은 어디서 봤거나, 아무튼 내가 인지하고 있는 것으로 설명해 보겠다.

 

  우선 제안요청서부터 살펴보자.

제안요청서가 만들어지려면 먼저 사업계획서가 만들어 져야 한다. 그래야 내부적으로 결재도 받고, 예산도 받고 할 수 있다. 이 거 만들 때, 요즘은 공공기관이나 정부부처 담당자가 직접 만드는 경우가 많아졌지만 예전엔 거의 외부 업체에서 기초 자료를 만들어 주었다. 보통은 정보팀에 기획 파트가 있고 실제 필요한 부서에서 제시한 대략적인 요구사항을 가지고 형식에 맞춰 작성한다. 이 '대략적인' 내용 때문에 사업이 시작되면 여러 가지 문제점이 발생했다. 이를 보완하고자 정부에서 '신RFP' 제도를 만들었지만, 여전히 형식만 따를 뿐 각 요구사항에 대한 기능점수(Function Point)는 제시하지 못하고 있다. 즉, 명확한 요구사항을 제시하지 못한다는 뜻이다. 그래도 발주처에서는 문제가 없다. 제도만 공표했지, 그 작성된 RFP 의 내용을 체크하는 장치는 없기 때문이다.

 

  둘째로 제안서이다.

이런 RFP 를 보고 각 SI 업체들은 고민을 한다. 참, 여기서는 연차사업 말고 신규 시스템 구축 사업으로 한정한다. 이유는 연차 사업의 경우 상대적으로 RFP 와 제안서 작성이 좀 더 명확하거나 구체적이기 때문이다. 우선 장비와 부대비용은 어느 정도 신뢰성 있는 예산을 산출할 수 있다. 하지만 개발 부분은 앞에서 말했듯이 기능 점수는커녕 대략적인 요구사항이라 경험에 의존하여 투입공수와 인건비를 산출한다. 이렇게 나온 예상 비용과 RFP 에 제시된 예산을 비교한다. 차이가 많이 나면 쉽게 입찰에 응하는 것을 포기하면 된다. 예산 안에 있거나 비슷하게 맞을 경우, 잠재된 리스크가 없나 검토하고 팀을 꾸려 제안서를 쓰게 된다.

이 때 다행히도 멋진 아이디어가 떠오르면 - 물론 예산 안에서 - 작성에 재미를 느낄 수 있지만, 그렇지 못하거나 뻔한 사업일 경우 '그냥' 쓴다. 어떤 경우든 어렵다. 지금도 제안서를 쓰고 있을 인력들에게 경의를 표한다. ㅠㅠ

 

  이 제안서 작성에서 유혹이 발생한다. 

할 수 없는 것, 엉터리로 하려고 하는 것, 왜곡이 포함된 과대 포장, 있지도 않는 걸 그럴듯하게 표현, 이런 것을 과감히 포함시킨다. 2등에게는 사업을 안주기 때문이다. 일단 따고 봐야한다는 생각이 들기 때문이다.

마지막으로 잘 못 이해하는 경우가 있다. 발주처의 RFP 작성자의 문장이나 표현력이 부족해서 인지 그걸 이해하는 능력이 부족해서 인지 아니면 둘 다 멍청해서 인지는 몰라도 잘 못 제안서를 작성하는 경우다. 이 부분을 다행히 심사위원이 발견하여 적정한 점수로 실추하면 상관이 없다. 수주를 했을 경우엔 문제가 될 수 있다. 특히 금액적으로 많은 차이가 날 경우 힘들게 수주하고는 포기하는 불상사가 발생하기도 한다.

 

 

  셋째로 얘기하고자 하는 사업수행계획서이다. 수주를 하면 규정에 의해 10일 이내에 사업수행계획서를 작성하여 제출해야 한다. 이는 말 그대로 사업을 수행하기 위한 방안을 제시하는 것이다. 이 사업수행계획서를 제출하게 하는 이유는 무엇일까?

 

  앞서 주저리주저리 얘기 했지만 다시 요약해 보자.

자 제안요청서는 발주처가 SI 개발 전문가가 아니다라는 핑계로 대충 만들어진다. 그걸 소위 전문가인 업체에서 나름대로 해석하여 개발 방안을 제시한다. 그런데 이 두 가지 문서에서는 그 속성상 잠재된 오류가 있다. 또 발주처에서는 미처 생각지 못한 참신한 아이디어가 제안되었을 수도 있다. 그러니 이 둘을 참조하여 진짜 개발계획을 만들어 내야 하는 것이다. 

이 과정에서 발주처 담당자와 협의하여 뺄 건 빼고, 보완할 것 보완하고 해서 사업의 범위를 명확히 하게 되는 것이다.  

그런데 사업 공고에 보면 이런 조항이 있다. "제출하는 제안서는 계약서의 일부로 간주한다." 그리고 감리는 그 가업의 완료 여부의 기준을 제안요청서로 삼는다. 그리고 저 조항 때문에 제안서도 사업의 기준요건으로 본다. 이러한 현상으로 인해 수행팀은 요구사항 도출을 할 때 위 세 가지 문서의 내용을 모두 나열하고 작업하게 되는 것이다. 사업수행계획서의 내용이 대부분 제안요청서와 제안서를 기준으로 작성한 최종본인데도 불구하고 나머지 두 문서도 다시 기준으로 삼아야 하는 이상한 일이 벌어지고 있는 것이다. 웃기는 짬뽕이지 않는가... ㅠㅠ

 

  괜히 수행팀만 괴롭히는 것이다. 다음 둘 중 하나로만 해야 한다.

1. 사업수행계획서가 승인이 나면 그 것만 사업의 기준으로 정해야 한다.

2. 아니면 사업수행계획서는 작성할 필요 없이 RFP 와 제안서만 갖고 사업을 수행하면 된다.

인력이나 일정 등 변경 사항이 발생하지 않냐고?

심지어 개발 내용도 사업 도중에 변경된다. 인력이든 일정이든 고객의 변심 즉, 요구사항 변경이든 간에 변경요청절차를 밟아 다 문제없이 진행하지 않는가.

 

사업수행계획서만 인정할 수 없다면 아예 만들지 않는 것이 현명한 것이다.

수행사 뿐만 아니라 고객과 감리 모두에게 이로운 거라고 확신한다.