29. 업무 담당자의 프로젝트 만들기
IT 프로젝트 발주 과정
프로젝트 기획
개발자나 SI업체도 프로젝트를 수행하는 것이 쉽지 않지만, 프로젝트를 발주하는 회사 담당자도 프로젝트를 기획하는 것이 쉬운 일이 아니다. 특히 예산이 많이 들어가는 사업일수록 프로젝트를 기획하는 과정은 더 어렵고 많은 시간이 소요된다.
회사 현업 담당자 입장에서 프로젝트를 만들기 위해, 일반적으로 거치는 과정에 대해 알아보자. 인터넷 뱅킹 재구축과 같은 IT사업을 추진해야 하는데, 사업 추진 절차를 잘 몰라 어려워하는 담당자를 많이 봤다. 기업마다 고유의 절차가 있지만, 보편적인 과정 중심으로 살펴보자.
｜사업 예산 수립｜
사업을 추진하려면 경비가 필요하다. 대부분 기업에서 경비를 집행하려면 예산이 있어야 한다. IT사업은 경비가 많이 든다. 올해 사업을 추진하려면 예산이 있어야 한다. 따라서 담당자는 프로젝트 수행을 위한 예산을 미리 전년도에 잡아 놓아야 한다.
구체적으로 살펴보면, 인터넷뱅킹 담당(예:소매 금융부서 소속) 자는 내년에 인터넷 뱅킹 전면 대 개편을 하고자 한다면, 사업 예산을 미리 수립해서 예산 승인을 받아 놓아야 한다.
예산을 잡기는 잡아야 하는데 얼마나 잡아야 할지 난감하다. 인터넷 뱅킹 전면 개편에 드는 비용을 현업 담당자가 산정하기란 쉽지 않다. 그래서 담당자는 예산 수립 시기에 여러 IT업체에게 대략의 사업 내용을 설명하고 예산용 사업 견적서를 받아서 적절하게 예산을 신청해 놓는다. 행여 사업 예산이 부족할 수 있어 넉넉하게 예산신청을 하지만, 예산 심의 과정에서 축소되는 경우가 허다하다.
업무 담당자는 IT사업을 추진하기 위해 사전에 사업예산이 수립되어 있어야 한다. IT사업 예산은 관련 IT업체로 부터 받은 견적을 참조하여 사업 예산을 수립한다.
｜사업 추진 기획 및 품의｜
사업 예산도 확보했고, 사업 추진의 필요성에 대한 회사 내의 여론도 형성되었다면, 사업 추진 기획을 본격적으로 할 수 있다. 앞서 말한 인터넷 뱅킹 개편과 같은 사업은 두 자리 숫자 이상의 억 단위로 금액이 드는 사업이라, 내부 분위기를 형성하는데만 시간이 오래 걸린다. 그렇게 큰돈을 들일 필요가 있나? 인터넷 뱅킹 개편이 시급하다! 는 사내 의견은 큰 사업일수록 엇갈리기 마련이다. 사업의 필요성에 대한 이해관계자들의 공감이 첫째로 필요하고, 공감과 별도로 업무와 기술적인 측면에서 검토하는 데에도 오랜 시간이 소요된다.
사업 추진 기획서를 만들기 위해 담당자는 프로젝트 추진 범위, 일정, 경비, 기술 및 효과 등을 검토하여야 한다. 이러한 과정은 현업담당자 혼자 할 수 없다. 기술적인 부분은 IT부서의 도움을 받기도 하지만, 가장 많은 도움을 받는 곳이 관련 IT업체다. 현업부서 담당자는 사업 수행이 가능한 IT업체를 물색하여 사업 추진 내용을 담은 RFI(Request For Information)를 IT업체에게 발송하여, 프로젝트 추진 비용, 소요시간, 기술 등에 대한 정보를 수집한다.
｜RFI(Request for Information, 사전정보 요청)｜
관련 업체들로 부터 회사소개, 제품/서비스 소개, 간단한 시장 동향, 주요 경쟁사 정보 등을 제공받아 추진 사업에 대한 정보를 미리 수집하고 비교 분석하여 사업 기획 자료로 활용하기 위해서다. RFI에는 많은 요구사항을 담지는 않고, 추진하고자 하는 업무(프로젝트)에 대한 간단한 개요, 목적, 기간 정도를 표시하고, 필요로 하는 정보에 대해 리스트업 한 후 제출 날짜를 기재한 공문을 보내고, IT업체는 자신들이 생각하는 사업에 대한 제안을 자유롭게 제출한다.
내부적으로 사업추진에 대한 의사결정이 되었으면, 담당자는 사업 추진 품의서를 만들어 승인권자로부터 결재를 받고 본격적인 사업 추진을 한다.
(대부분 기업은 사업 규모에 따라 사업추진 승인권자의 직위도 다르며, 재무 부서와 합의도 필요하다. 이런 과정이 매우 복잡하고 의사결정의 시간이 오래 걸린다. 그만큼 추진 담당자도 힘들다는 뜻!)
｜RFP발송｜
사업 추진 담당자는 IT업체로 부터 제안 요청을 하기 위해 RFP를 작성한다. RFI가 단순한 정보를 위한 요청이라면 RFP는 정식 제안 요청서기 때문에 법적인 구속력을 가질 수 있다. 따라서 담당자는 프로젝트의 범위, 프로젝트 일정, 관련 기술, 상호 책임의 범위 등을 명확하게 기술하여야 한다. RFP가 명확하고 구체적일수록 IT업체의 제안의 품질이 좋아지고, 사업 추진 담당자는 더 정확하게 제안 내용을 평가할 수 있다.
｜RFP(Request for Proposal, 제안 요청서｜
사업추진을 위해 발주 사가 IT업체에게 사업 제안을 요청하는 제안 요청서이다. RFP에는 해당 업무(프로젝트)에 대한 자세한 정보, 추진 일정, 예산, 그리고 제안서의 목차, 제안 평가 기준 등을 구체적으로 명시해야 한다.
모호한 RFP는 법적인 문제가 될 수 도 있다. 예를 들어 "인터넷 뱅킹 홈페이지 디자인 개선"이라 한다면, A제안 업체는 단순히 색상과 일부 디자인 정도만 범위로 잡고 제안하고, B업체는 디자인 콘셉트에서 모든 것을 다 바꾸는 것을 범위로 해서 제안했다면, 당연히 A업체가 비용이 낮을 것이다. 그러면 제안 평가에서 A업체가 유리할 것이다. B업체는 피해를 볼 수 있다. 이러한 모호한 RFP기술은 추후 문제가 될 수 있다. 따라서 개선이라면 어느 수준에서 어떤 범위에까지 개선을 요구하는지 구체적으로 표현하여야 할 것이다.
그러나 모든 것을 명명백백히 규정할 수 없으므로, 모호한 부분은 문의를 하도록 한다. 문의를 통해 업체가 오고 간 내용은 제안하는 모든 업체에게 공유하여 공정한 경쟁이 되도록 해야 한다.
RFP가 완성되면, 내부 승인 절차를 거쳐서 RFP를 IT업체에게 공지한다. RFP는 RFI단계에서 RFI를 받은 업체만 RFP를 주는 경우도 있고, 상관없이 원하는 업체에게 다 주는 오픈 경쟁도 있다. 중요하고 큰 프로젝트인 경우는 관련 업체에게 통지를 하고 업체 대상으로 RFP에 대한 설명회를 개최하여, 사업 내용이 제안 업체에게 충분히 전달될 수 있도록 한다.
｜제안평가｜
사업담당자는 제안사들이 제안서를 작성하는 동안 제안 설명회를 준비한다. 제안 설명회에서 가장 중요한 것은 제안 평가 위원과 제안 평가항목을 정하는 것이다. 제안 평가 위원 구성은 매우 민감한 사안으로 사업 추진 품의시 제안 평가 위원 구성에 대한 품의를 획득해 둔다. 제안평가 위원의 선정은 밖으로 나가지 않도록 기밀유지에 신중을 기해야 한다. 일반적으로 제안 평가 위원은 업무 담당자 70%, IT담당자 30% 비율로 구성한다. 제안 평가 시작 전 담당자는 해당 부서에 구제적인 평가 위원 선임을 요청해서 평가위원을 확정한다.(이러한 과정은 IT부서에서 진행하는 경우도 있다. - 회사마다 다를 수 있음)
다음으로 중요한 것이 평가 항목인데 대부분 기업들은 자체적인 평가 항목이 있다. 평가항목은 정확하게 RFP단계에서 정해진다. RFP에 평가 항목에 대한 내용을 넣어 제안 업체가 평가 내용을 알 수 있게 한다. 일반적으로 평가 항목의 구성은 업무, 기술, 가격의 비율로 구성된다. 프로젝트가 기술적인 부분이 중요하다면 가격의 비중을 낮추고 기술 비중을 높이기도 한다. 이러한 비중의 변화도 자의적으로 하지 못하도록 내부 의사결정 과정을 거치도록 회사 규정이 마련되어 있는 경우가 많다.
제안 설명회는 평가에서 가장 중요한 부분이다.제안 참가업체는 제안 설명회를 마친 후 회사가 요구한 서류와 견적을 밀봉하여 회사에 제출한다. 제안 설명회가 끝나면, 평가 위원의 제안 평가서와 제안사가 제출한 견적을 개봉하여 평가 기준에 따라 최종 평가 결과를 도출한다.
제안사 중에서 최고로 평가점수를 받은 제안사를 우선협상 대상자로 선정한다. 아직 계약 기간까지 많은 변수가 남았기 때문에 계약 당사자가 아닌 우선협상 대상자로 선정한다. 우선협상대상자 선정에 대해 내부 보고를 하고 해당 사실을 제안사에게 통보를 한다. 나머지 제안사에 대해서도 제안 평가 결과를 통보한다.
업체 선정은 위와 같이 제안을 통해 평가로서 업체를 선정하는 것이 일반적이다. (제안을 통한 협상의 방법). 그러나 프로젝트의 규모가 아주 작거나, 특수한 기술이 필요한 프로젝트인데 그 기술을 특정 업체가 가진 경우 등 특별한 경우는 '수의계약'이 가능하다. 수의계약은 업체 선정의 공정성이 문제가 될 소지가 많기 때문에, 공기업, 금융기관에서는 특별한 제한 규정을 두고 있다. 제안이 아닌 특정 업체와 수의계약을 하려면 그러한 규정에 적합한 사유가 반드시 있어야 한다.
｜계약 및 착수｜
제안사가 선정되면 사업 추진이 일단락된 것 같지만, 프로젝트를 착수하기 위해서 넘어야 하는 관문은 아직 많이 남아 있다. 우선 협상 대상자로 선정된 IT업체와 현업담당자, IT담당자는 본격적인 협의가 시작된다. 사업 추진 범위에 대한 구체적인 논의와 기술적인 부분에 이르기까지 깊은 논의가 이루어진다. 이 과정에서 처음 RFP의 내용과 다른 요구사항이 나오거나 발견되므로 해서 상호 간에 마찰이 발생하는 경우도 많다. 그러한 마찰이 잘 해결되지 않아 우선 협상이 결렬되는 경우도 있다.
업무와 기술 관련 검토와 협상이 끝났으면 다음으로 하는 것이 가격 협상이다. 제안 사는 업무와 기술 관련 협상과정에서 나온 것을 감안하여 새로운 견적을 제출한다. 가격협상의 목적이 가격을 깎자는 것이 목적이기 때문에 이 경우 견적은 제안 견적보다 낮은 것이 보통이다. 대부분의 사업이 회사가 미리 보고한 사업 예산 보다 업체의 제안 견적이 높기 때문에, 예산의 범위에 들어오도록 길고 긴 가격 협상을 한다.
그러는 중 시간은 하염없이 흐르고, 프로젝트 착수도 계속 늦어진다. 협상 기간이 길어지면 프로젝트 인력이 먼저 투입되는 경우가 많다. 원칙적으로 계약이 이루어지고 나서 인력이 투입되어야 하나 시간이 자꾸 지나가면 서로 힘들 수 있어 상호 합의(?)하에 인력이 먼저 투입되는 것이 예전에는 관행이었다. 그러나 최근 계약 전 인력 사전 투입은 불공정한 행위로 문제가 되고 있어 그러한 관행은 많이 줄었다.
발주 사 와 제안사의 오랜 줄다리기 끝에 가격이 결정되고 계약이 체결되었다. 이제 본격적인 프로젝트가 착수되었고, Finish를 위해 달려갈 일만 남았다.
체계적이고 보완된 내용으로 브런치 글과 같은 이름으로 출간을 하게되었습니다. 아래의 링크를 통해 자세한 내용을 확인할 수 있습니다.
교보문고
나에게 맞는 IT 직업 찾기
예스24
나에게 맞는 IT 직업 찾기
알라딘
나에게 맞는 IT 직업 찾기
프로젝트를 추진하는 현업 담당자의 관점에서 살펴보았다. 여기 기술된 과정은 기업규모가 큰 기업의 전형적인 대규모 SI사업을 기준으로 했다. 억 단위 이하의 프로젝트와 같은 소규모 프로젝트나 단순 개발 프로젝트는 이러한 과정을 다 밟지 않는다. 다음 편에서는 IT업체 관점에서의 프로젝트 준비과정을 살펴보자.
