프로젝트 범위정의
프로젝트가 성공하기 위해서는 프로젝트의 계획이 철저하게 수행되지 않으면 수행절차에서 잘 수행하더라도 성공한 프로젝트가 될 수 없다. 프로젝트 계획 프로세스는 프로젝트의 유형에 따라 수행하는 업무가 상이하나 프로젝트의 범위를 설정하는 업무부터는 프로젝트 유형에 무관하게 공통적으로 적용되어 진다.
예를 들어, 고객이 요청한 프로젝트를 수행하는 SI 유형의 경우 고객 요청사항에 따른 범위를 산정에서 부터 시작해야 할 것이고, 내부에서 필요로 하여 수행하는 프로젝트의 경우 내부 고객의 요청사항에 대한 범위를 산정하여 진행하게 되며, 자체 소프트웨어를 개발을 수행하는 프로젝트의 경우 소프트웨어 개발 기획을 수행하여 나온 결과를 요청사항으로 범위를 산정하게 된다.
이에 프로젝트 관리에서 프로젝트 기획이나 내부 프로젝트 의견 수렴등의 절차는 표준 프로젝트 계획 단계에서 포함하지 않는다.
1. 사전고객 협의 및 범위설정
1) 준비절차
영업담당자는 RFP를 분석하여 회사에서 진행가능하다는 판단이 서면 사업부장 또는 제안 PM을 포함하여 제안팀(수주팀)을 구성하게된다. 단기 또는 소규모 프로젝트의 경우 제안팀을 구성하기보다는 영업담당자와 수행 담당자(사업부장)로 구성하기도 한다. 그러나 중/장기 프로젝트(3개월 이상)의 경우 반드시 제안 PM 이나 수행PM을 포함한 제안팀을 구성하여 업무를 진행하는게 타당하다. 이렇게 구성된 제안팀은 고객이 제공한 사전정보 또는 RFP등을 분석하여 범위명세서를 작성한다. 이때 작성되는 범위명세서는 가능한 자세히 작성하는게 좋으며, 이때 고객에게 질의할 사전 질의내용을 포함하여 작성하는게 좋다. 만약 별도의 범위명세서 템플릿이 없을 경우 요구사항 정의서를 활용하여도 좋다.
중요한 점은 사전 고객과의 협의 이전에 프로젝트에 대한 숙지를 충분히 하고, 질의 내용을 사전에 준비해야 한다는 점이다.
중/장기 프로젝트의 경우 범위명세서를 기능과 비기능, 도입장비로 구분하여 작성하는게 좋다.
기능 : 개발을 진행해야할 기능
비기능 : 사무실 및 투입인력, 산출물과 품질 요구조건, 보안사항등 개발 기능외의 고객요구사항
도입장비 : 납품할 장비(소프트웨어, 하드웨어 포함) 및 개발시 투입할 장비(개발서버, 개발 라이센스등)
2) 사전고객협의
고객과의 사전협의는 작성된 범위명세서와 사전 질의내용을 가능하면 사전에 고객에게 전달하고 협의를 진행하는게 좋다. 특히 중/장기 프로젝트의 경우 기능/비기능/장비등에 대한 답변을 발주 담당자가 모두 답변하기 어렵기 때문에 사전에 범위명세서를 작성하고, 사전질의서를 같이 발송하는게 좋으며, 사전 협의를 진행하면서 범위명세서를 정제하는 과정이 필요하다.
3) 범위설정
RFP의 분석과 사전고객협의를 진행에서 산출된 범위명세서는 프로젝트의 투입공수, 경비 및 제안가격을 설정하는데 매우 중요한 근거가 되며, 제대로된 범위 설정을 산출하지 못하면 프로젝트는 시작부터 손실을 부담하고 시작하게 된다.
위험요소 :
제안을 준비하는 기간이 대부분 단기간에 이루어지는 경우가 많아 시간적 여유가 없음을 이유로 형식적으로 진행하는 경우가 많다. 이에 가능하면 PM은 해당 분야에 경험이 많은 담당자를 배정해야 한다.
조직이 성장하려면 가능한한 많은 프로젝트에 대한 제안을 진행하며, 경험과 데이터를 축척해야 한다.
2. 공수 산정
공수 산정은 프로젝트를 진행할때 투입되는 인력 공수를 산정하는 단계를 의미하며, 산출물은 프로젝트 산정 결과서가 작성되게 된다.
공수 산정을 할때 필요한 사항은 범위명세서를 기준으로 작성된 WBS를 기준으로 산정하게 된다.
공수산정을 진행하는 방식은 하향식 산정방법과 상향식 산정방법으로 분류할 수 있다.
-. 하향식 산정방법
경험이 많은 전문가의 판단에 따른 산정방식으로 2명이상의 전문가에게 산정을 의뢰하여 산정된 결과를 활용하거나, 전문가의 산정에 차이를 보정하기 위한 델파이 비용 산정방식을 적용하여 산정하는 방식등이 있다.
-. 상향식 산정방법
범위명세서에 작성된 WBS 를 정의하고, 이에 소요되는 기간과 투입인력등을 산정하여 계산하는 방식으로, 대표적으로 소스 라인수에 근거한 LOC 기법과 개발하게 되는 소프트웨어의 특성을 활용한 기능점수(Function Point)를 활용하여 산정하는 방식이 있다.
하향식 산정방식은 산정하는데 있어 시간적/비용적인 측면에서 접근하기 쉬우나, 전문가의 경험적 판단에 의한 산정 방식으로 산정하는 개인의 역량에 따른 신뢰도와 객관성이 저하되는 문제가 많다.
상향식 산정 방법은 크게 LOC 방식과 FP(Function Point) 방식으로 나누어 지는데, LOC 방식은 언어에 따른 크기의 가변성과 기준이 모호하여 현재는 소프트웨어의 특성에 따른 기능별 점수를 기준으로 산정하는 FP(Function Point)방식이 많이 활용되고 있다. 대부분의 공공 프로젝트에서는 FP 방식을 많이 활용하고 있다.
그러나, 이러한 다양한 산정 방식이 존재하나 실무에서 이를 적용하여 견적가를 산정하기에는 경험많은 전문가를 확보하기도 쉽지 않으며, 짧은 제안 기간에 산정을 완료해야하는 상황상 실무에 적용하기가 쉽지 않다.
이러한 단점을 상쇄하고자 많은 회사에서는 기존에 진행했던 프로젝트중 유사 프로젝트를 참고하여 신규 프로젝트의 규모를 산정하고, 산정을 수행하는 인력을 회사에서 경험이 많은 인력에게 담당시킴으로써 산정을 진행한다.
현재 공공 프로젝트등에서는 FP방식을 많이 활용하는데 FP방식은 WBS를 작성할때 기능단위로 세분화하여야 하는데 기존의 업무 단위로 WBS를 작성하는데 비교하여 기능단위로 분류하는데 소요되는 시간적/자원적으로 제한되는 점이 많아 짧은 기간내에 소요 예산을 산정하는데는 어려움이 있다.
여기서는 FP 방식보다는 업무구분에 따른 규모를 산정하고, 산정된 규모에 따른 공수 산정하는 방식에 대한 방식을 설명한다. 만약 FP방식이 편한 분들은 업무 구분을 업무단위가 아닌 기능단위로 추정본수를 FP로 대치하여 적용하여 사용하면 된다.
1) 규모산정
1. 범위명세서를 WBS 로 변환한다. WBS는 본수를 측정가능한 프로그램 기능 단위로 구성한다.
유사한 프로젝트를 수행하는 회사의 경우 이미 수행한 프로젝트의 WBS를 참고하여 제안할 프로젝트의 WBS 로 수정 보완한다.
2. WBS에 대한 추정 본수를 측정한다. 이때 추정본수를 산출하는 기준은 1본당 1인 개발자가 개발에 소요하는 기본 개발시간을 책정한다. 프로젝트 유형의 난이도에 따라 1본수를 개발하는데 소요되는 기본 개발시간은 상이할 수 있다. 일평균 근무시간을 기준으로 설정하여 사용하기도 한다. 1본수의 평균 개발 시간을 8시간으로 책정하면 WBS 에서 분류한 작업이 1명이 이틀정도의 기간이 소요된다고 가정하면 추정본수는 2로 산정한다.
2) 공수산정
프로그램의 규모를 산정하였으면 이를 기반으로 공수를 산정하여야 한다.
공수를 산정할때는 월 평균 근무일수와 일 평균 근무시간을 배정지정하고, 기본개발시간을 책정하여 공수를 산정한다.
아래 표는 공수산정하는 템플릿으로 참고하시기 바란다.
1) 프로그램 본수당 기본 개발기간 : 12, 12는 이틀정도의 시간적 여유를 부여한 것으로 프로그램의 난이도에 따라 조정간능하다.
2) 요구분석과 설계 : 일반적으로 개발 공수를 작성할때 요구분석과 설계, 테스트에 대한 공수를 누락시키는 경우가 많다.
요구분석은 개발기간의 50%, 설계는 개발기간의 80% 정도 산정하고 테스트(단위테스트 제외)는 50 %를 산정한다.
3) 사업관리 : 사업관리는 프로젝트를 수행할 때 발생되는 행정 및 지원사항을 처리하게 되며, 보통 개발공수의 10% 정도를 산정하나, 산출물이나 지원이 많이 필요한 사업의 경우 비중을 조정가능하다.
4) (기타) : 개발장비 및 사무실등의 부대 비용을 포함한다. 세부항목은 개별적으로 구성하고, 여기에는 총액으로 작성이 가능한다.
5) 환산계수 : 표준은 회사에서 지정한 기본 개발시간 및 비중을 의미하며, 프로젝트의 성격에 따라 조정이 가능하다. 공수의 산정은 조정된 환산계수가 반영된다.
3. 최종 견적 결정
범위명세서와 프로젝트 산정결과서를 기반으로 최종 견적여부를 결정하게 된다.
최종견적여부를 판단할때는 범위명세서와 WBS, 공수산정 내역과 프로젝트 손익이 포함되며, 프로젝트의 위험요소 및 제약사항등을 포함한 수주심의서를 기준으로 프로젝트의 Go Or Drop을 결정 한다.
최종견적 결정을 진행하는 주체는 임원진을 포함한 수주심의회의를 만들어 임원진의 승인하에 프로젝트를 진행하도록 만든다. 수주심의회의는 주간보고나 월간회의등의 정기적 보고 형식을 취하지 말고, 별도의 협의체에서 프로젝트의 정보와 분석을 임원진과 공유하도록 한다.
4. 위험, 가정, 추가제약사항 검토 및 조정
최종 견적 여부가 결정되면, 제안 발표 후 수주여부가 결정된다.
수주 심의가 완료된 이후에도 위험/가정/제약사항등의 변동은 상시적으로 발생하므로, 제안팀은 수시로 확인하여야 하며, 프로젝트 예산이 변경될 경우 수정된 수주심의서를 재승인을 획득하도록 하도록 한다.
여기서 중요한 점은 계약 직전까지는 프로젝트의 예산의 조정은 발생할 수 밖에 없음을 인정해야 한다. 임원진의 성향에 따라 프로젝트 예산 조정에 대한 질책이 발생하게 된다면, 결국 객관적이고 투명한 예산이 아닌 숨겨진 위험요소가 될 수 있음을 반드시 인식하고 있어야 한다.
이에 따라 수주심의절차는 프로젝트의 예산에 대한 조정이 발생한다면 반드시 수주심의회의 승인을 재획득하도록 규정해야 하며, 이는 프로젝트 예산의 오남용을 방지할 수 있는 강력한 장치가 된다. 단, 프로젝트 예산내에서는 수행팀의 재량하에 예산집행이 가능하도록 해야 불필요한 프로세스가 줄어들수 있다.
5. 프로젝트 계약
계약을 진행할때는 반드시 수행 PM이 결정되어 있어야 하며, 수주심의서(범위명세서, WBS, 프로젝트 예산)을 수행 PM에게 인수인계를 진행해야 한다. 특히 계약을 진행할때 수금에 대한 계획을 잘 확인하여 자금집행계획을 경영지원과 협의하여 원할한 업무 지원이 될 수 있도록 한다.
위험요소 :
중/장기 프로젝트의 경우 공수산정이 너무 낙관적으로 작성될 경우 프로젝트의 손실을 처음부터 내재한 상태에서 프로젝트를 수행하게 되므로, 객관적인 공수산정이 될 수 있도록 제안팀을 구성해야 한다. 수주심의에서 확정된 예산 및 기간은 수행팀에게 보장되어야 하며, 프로젝트 예산이 변경되거나 프로젝트 예산내에서 전용이 발생하는 경우에는 프로젝트에 대한 재심의 절차를 수행할 수 있는 제도가 필요하다. 또한 프로젝트 예산내에서 자금 집행은 수행팀이 권한과 책임을 부여하여 효율적인 수행이 될 수 있도록 해야 한다.
마무리
이번글에서는 프로젝트를 계획하고 수주하는데 필요한 프로세스를 확인하였다. 특히 공수산정과 최종 견적을 결정하는 절차는 매우 중요하며, 이때 발생되는 범위명세서, WBS, 프로젝트 예산을 포함한 수주심의서는 프로젝트 수행팀이 프로젝트 수행계획서를 작성하는 기본 자료가 되므로 매우 잘 작성하여야 한다.
프로젝트 수주를 위하여 이렇듯 많은 준비를 하는데 수주 실패에 대한 투입 비용이 남용될 수 있는 소지가 있다. 남용을 축소하기 위해서는 프로젝트의 유형이나 규모에 따른 세부 시행에 대한 차이는 있을 수 있으나, 프로세스는 반드시 시행하는것이 좋다.
댓글