프로젝트 관리 완벽 가이드 2편: 안녕하세요? 독자 여러분. 오늘은 프로젝트 관리 완벽 가이드 2편, 프로젝트 관리 사전/사후 프로세스에 관해 알려드립니다. 프로젝트는 고객이 지정한 특정일에 시작되지만 시작 전 진행되는 프로세스가 굉장히 복잡하며 이 과정은 짧게는 수 개월에서 길게는 1년 이상이 소요되기도 합니다. 뿐만 아니라 프로젝트가 종료된다고 해서 수행사가 프로젝트로부터 완전히 벗어날 수 있는 것도 아닙니다. 프로젝트 시작 전/후에 진행되는 과정에 대해 자세히 소개해 드리겠습니다.
프로젝트 관리 사전/사후 프로세스
PM, PMO를 목표로 하는 사람이라면 프로젝트의 타임라인을 좀 더 확장해서 프로젝트가 시작되기 전 또는 프로젝트 종료 후에 진행되는 발주사와 수행사 간에 진행되는 프로세스에 대해 숙지할 필요가 있습니다. 아래 그림은 프로젝트 타임라인(사전, 수행, 사후)에 걸쳐 발주사와 수행사 간에 진행되는 프로세스를 도식화한 것인데, 특히 프로젝트 시작 전 발주사와 수행사 간에 진행되는 프로세스는 프로젝트 관리 실무와는 직접적인 연계성은 없지만 보통 6개월에서 1년 이상 소요되고 이 기간 동안 예산수립, RFI, 수주활동(영업), 입찰공고, 제안, 계약 등의 중요 과정이 진행됩니다. 또한 프로젝트가 종료된 이후에도 그 전에 발견되지 않았던 오류가 발생할 수 있으므로 오류에 대한 대응(무상유지보수)이 필요합니다. 이러한 사전/사후 프로세스에 대한 관리는 영업 담당자뿐만 아니라 계약 후 직접 프로젝트 수행에 참여하는 프로젝트 관리자도 충분한 협업을 해야 합니다.
예산 수립
어떤 목적을 가진 IT 시스템을 새로 구축하거나(신규 구축) 기술 환경/고객 니즈의 변화로 기존 시스템을 변경(흔히 재구축, 리뉴얼 등으로 불림)하고자 할 때 가장 먼저 선행되는 작업은 발주사의 예산 수립입니다. 긴급으로 수행되는 사업도 있을 수 있지만 보통 예비비를 사용하므로 비용이 많이 들지 않는 경우에나 가능하고 재구축이나 리뉴얼과 같은 대규모 사업은 전년도에 미리 예산 계획을 수립하고 예산 집행 계획에 따라 당해 년도에 사업을 발주하게 됩니다.
사업 비용은 하드웨어(서버, 네트워크장비 등), 소프트웨어(운영체제, Web, WAS, DB, 보안솔루션 등) 그리고 업무 전산화를 위한 개발비(인건비)로 구성되는데 하드웨어나 소프트웨어는 분리시켜 발주하는 경우가 많습니다. 예산 수립 시 하드웨어나 소프트웨어는 시장 가격 조사를 통해 쉽게 가능하지만 소프트웨어를 개발해야 하는 경우 소요되는 개발비(개발규모)는 어떻게 산정할까요?
대표적인 개발비(개발 규모) 산정 방법에는 투입 공수(M/M) 방식과 기능 점수(Function Point) 방식이 있는데, 두 가지 방식 모두 장단점이 있고 특히 기능 점수 방식은 법에 의해 공공기관에서 필수적으로 사용해야 하는 방식이지만 산정 방식이 꽤나 높은 숙련도를 요구하고 정확한 기능들에 대한 결과물이 분석/설계 단계 이후에나 나올 수 있는 특징이 있어서 사전에는 명확한 도출이 어렵다는 단점이 있습니다.
개발비 산정 방법은 예산 수립 시에도 필요하지만 제안사가 제안 금액을 결정할 때도 동일하게 적용될 수 있으므로 숙지해야 합니다. 자세한 내용은 [PMI의 PMBOK]를 참조하십시오.
사전정보요청(RFI, Request For Information)
사전정보요청이란 사업발주를 통해 전문업체에게 제안 요청을 하기 전에 구축하고자 하는 시스템 관련 정보(최신 기술동향, 예상 비용 등) 수집하여 각종 최신 기술과 동향에 대한 이해도를 높이는 과정입니다. 예산 수립 당시의 IT 상황과 사업 추진 당시의 상황이 다르므로 빠른 트렌드와 이를 반영하려는 목적으로 RFI를 요구하는 기업이 증가하고 있습니다.
구축하고자 하는 시스템 관련 정보 외에도 정보 제공자의 업무 현황 및 수행 능력(회사 연혁, 규모, 보유 기술, 유사구축사례 등)과 관련된 정보를 함께 제공받아서 개략적으로 후보 업체를 선정하는 역할도 합니다. 제안요청서 공시와 같이 자사 홈페이지 게시판에 요청하는 경우도 있지만, 제 경험에 의하면 시스템 구축 관련하여 과거에 발주사와 계약 경험이 있는 업체에 한정해 요청하는 경우도 있습니다.
소규모 사업의 경우 RFI 요청이 없는 경우도 있고 대형 사업의 경우 전문가집단(주로 컨설팅업체)에 큰 비용을 들여 정식 의뢰하기도 합니다.
사업발주(입찰공고 및 제안요청)
수립된 예산 집행 계획에 따라 발주사는 입찰 과정을 거쳐 외주 업체를 선정합니다. 발주사는 구축하고자 하는 시스템에 대해 요구사항을 포함한 사업 전반에 대한 상세한 내용을 문서화하여 공지합니다(자사 홈페이지, 언론매체 등 활용).
사업공고와 함께 사업 전반에 대해 이해도를 높이기 위해 특정 일자에 사업 설명회를 개최하여 사업의 배경 및 목적, 현행 시스템 및 필요 시스템 요건, 평가 기준, 제안 시 유의 사항 등을 설명합니다. 사업공고 시 포함되는 내용에는 공고문, 제안 안내서, 기술제안요청서 등이 있으며 특히 기술제안요청은 입찰에 참여하고자 하는 업체(제안사)가 올바른 제안을 할 수 있도록 구체적이고 명확해야 합니다. 사업 설명회에 참석하지 않은 업체는 제안 참여 기회가 박탈될 수도 있습니다.
사업규모가 극단적으로 큰 사업(1000억 이상의 규모)의 경우, 제안서 분량만 일천 페이지가 넘는 경우가 허다하고 이 정도면 제안서 작성에 소요되는 비용(작성인력 인건비, 제안서 출력/제본 등)도 만만치 않은데 불행히도 대부분 그 비용은 발주사가 부담하지 않습니다(보통 제안서 작성 비용 부담 주체는 제안사임을 제안요청서에 명시). 또한 부득이한 사유 발생 시 입찰 공고를 다시 할 수 있습니다.
사업제안(제안서 작성, 제출, 제안 발표)
공지된 제안요청서를 기반으로 사업 참여 여부가 결정되면 제안사는 제안요청서에 근거하여 최적의 시스템 구축 방안을 담은 제안서를 작성해서 제출해야 합니다.
사업 참여 여부는 영업담당자, 기술담당자, 의사결정권자 등의 책임자에 의해 결정되지만, 앞서 언급한 바와 같이, 입찰공고 전 아주 오랜 기간동안 영업담당자는 사전 수주 활동(영업)을 전개해 왔기 때문에 사업 관련 정보(경쟁업체, 수익구조, 리스크 등)를 충분히 알고 있으며 또한 책임자 및 의사결정권자에게 보고 및 공유해 왔기 때문에 입찰공고 후 RFP 분석 결과에 따라 사업참여여부 결정이 되는 경우는 거의 없습니다.
물론 사업에 대한 충분한 정보가 없는 경우 즉, 사전 수주 활동을 전개하지 않은 경우라면 해당 사업의 수익구조, 리스크, 기술 내역 등을 꼼꼼히 분석하는 절차가 필요합니다. 제안서 제출 마감 시한은 공고 후 2주가 보통인데 사업규모에 따라 유동적입니다.
제안팀 리더(예정 수행 PM)는 팀원들과 함께 목표 시스템을 어떻게 구축할 것인가에 대한 전략, 방안, 일정, 세부 기술 내역, 관리방안, 유지보수 등 제안서 작성요령에 맞춰 제안서를 작성하고, 영업담당자가 제안서와 별도로 밀봉하여 제출해야 하는 견적서 작성에 필요한 백데이터를 전달해야 합니다.
영업 담당자의 견적서 작성에 필요한 백데이터에는 투입 공수(등급포함, 투입 공수 방식), 도입이 필요한 하드웨어 및 소프트웨어 목록 등이 있으며, 영업 담당자는 이를 바탕으로 인건비, 구매비용 등을 책정하고 회사 정책(마진), 예상치 못한 상황을 대비한 예비비, 기타 비용(개발장소 임대 시 임대비용, 개발자를 위한 복지비용 등)을 추가하여 최종 견적서를 작성합니다(개발규모 산정 시 투입 공수 방식은 3.1.1 투입공수 방식 참조). 견적서는 제출한 금액(사업 대가)으로 제안서에 담긴 내용을 충실히 이행하겠다는 제안사의 약속에 해당하므로 제출 전 신중에 신중을 기해야 합니다(최종 의사결정자의 승인 필요).
발주사의 잦은 요건 변경, 요건 추가, 의사결정 지연 등 프로젝트를 진행하다 보면 발주사의 귀책으로 판단되는 여러 가지 상황이 발생할 수 있고 이런 이유로 일정이 지연되고 캐치업을 위한 인력이 추가되는 상황이 비일비재하지만 대부분 수행사의 몫으로 남게 됩니다. 계약 체결 후 추가 인력 투입 등의 사유로 비용이 증가하더라도 이해관계자가 서로 합의한 특별한 사유가 없는 한 발주사에게 추가 금액을 요청하기 어렵다는 현실에 유의하기 바랍니다.
제안서(제안서와 함께 요약본, 발표본 등을 함께 제출함) 및 견적서 제출이 완료되면, 지정된 날짜에 제안발표회(설명회)를 통해 자사의 제안 내용을 발주사에 설명합니다. 제안 발표는 통상적으로 발표 30분, 질의/응답 30분(또는 각각 40분/20분)으로 진행되며 사업 수주 시 투입될 예정인 PM이 발표합니다(보통 제안서 제출 역순으로 제안 발표 순서를 정하여 발표). 이 때 수행 예정 PM의 제안 발표 스킬이 문제가 되는 경우도 있습니다.
우선협상 대상업체 선정
발주사는 RFP에 명시된 평가 기준에 의거하여 제출된 제안서 내용을 점수화하고 가장 높은 점수를 획득한 업체를 우선협상 대상업체로 선정합니다. 점수는 기술 점수와 가격 점수를 분리하여 기술점수 대 가격 점수를 7 : 3 또는 8 : 2로 평가하나 일반적 기준이며 상황에 따라 다릅니다.
기술점수에 더 비중을 두고 평가하는 이유는 지나치게 낮은 가격으로 제안한 업체가 수주하는 것을 방지하기 위한 것이지만, 결국 발주사의 입장에서 제안업체에 대한 평가란 “기술이 중요하지만 비슷한 수준의 제안이라면 가격이 싼 게 최고”이므로 기본적으로 기술 우위를 갖지 못하면 제안 평가에서 불리한 것은 당연합니다.
부득이한 사유로, 예를 들어 제안 업체들의 기술 수준이 평가 기준에 현저히 떨어지거나 한 개의 업체만 입찰(단독 입찰)한 경우 입찰 공고를 다시 진행해 우선협상 대상업체 선정 과정을 진행하는 경우도 있습니다.
계약
우선협상 대상업체로 선정되면 그동안 본 사업을 주관했던 발주사의 사업주관부서와 가격 및 제안 내용 검토/의견 차를 조율한 후 최종 합의를 도출합니다.
계약은 발주사의 계약담당 부서와 체결하는데 이 과정에서도 넘어야 할 산이 있습니다. 계약담당 부서는 조금이라도 계약금액을 낮춰 부서의 목표를 달성해야 하기 때문입니다. 합의된 금액 그대로 계약이 이루어지며 좋겠지만 최종 계약금액은 조금이라도 줄어드는 경우가 많습니다.
어디까지나 제 경험이므로 일반화할 수는 없지만, 간혹 발주사의 무리한 가격 인하 요구가 협상에 걸림돌이 되는 경우가 있습니다. 예를 들어 발주사가 제안사 평가에서 2위를 획득한 업체의 가격을 제시하면서 그 가격에 준하여 협상을 시도할 경우 제안사 입장에서 수용이 불가능한 경우라면 계약이 체결되지 않고 재공고로 이어질 수 있습니다. 계약진행을 위해, 발주사와 관계를 유지하기 위해 그리고 발주사가 향후에 발주할 사업에 유리한 고지를 점령하기 위해 울며 겨자 먹기 식으로 대응하는 관행이 아직도 있는지는 확실하지는 않지만 계약 부서와의 최종 계약까지 넘어야 할 산이 많다는 것은 확실합니다.
사업수행
목표 시스템을 성공적으로 구축하기 위한 여러가지 과업들이 진행됩니다. 본 문서에서 집중적으로 다루고자 하는 프로젝트 관리가 가 집중적으로 이루집니다.
무상유지보수
오픈과 안정화 단계를 거쳐 프로젝트가 종료되면 프로젝트에 투입되었던 자원(인력, 장비, 소프트웨어 등)에 대한 철수/반납/철거가 진행됩니다.
프로젝트가 종료되고 난 후 시스템에 장애가 발생하면 어떻게 될까요? 통상적으로 종료 후 시스템에 장애가 발생했을 때 그 장애의 원인이 수행사로 판단되면 프로젝트 종료 후라도 수행사가 장애 대응을 하도록 무상유지보수(1년) 조건이 계약서에 명시되므로 수행사는 무상유지보수 기간 동안 무상으로 장애 대응을 해야 합니다. 무상유지보수는 오류의 원인을 찾아 수정하는 것이므로 개선이나 신규 기능 구축은 해당되지 않는다 점 유의하기 바랍니다.
맺음말
이상으로 프로젝트 관리 사전/사후 프로세스에 대해 알아보았습니다. 프로젝트 관리 사전/사후 프로세스에는 프로젝트 착수 전 그리고 종료 후에 발생하는 발주사와 수행사 간의 여러 가지 과업들이 존재하는데요, 이 과업들은 프로젝트 수행과는 무관해 보이나 프로젝트 관리에 작지 않은 영향을 미칠 수 있으므로 소홀히 여겨서는 안됩니다. 다음 글에는 [프로젝트 이해관계자 및 투입인력]에 대해 알아보기로 하겠습니다.