사업수행계획서 맞추기 - 제안서 인력, 협상 반영, 감리 3단 비교

제안서를 그대로 붙이면 수행계획이 될까?

되지 않습니다. 제안서는 낙찰을 위한 약속이고, 수행계획서는 계약과 기술협상을 반영한 실행 기준입니다. 입찰본을 표지만 바꿔 내면 착수 주에 이미 과업이 어긋납니다.

미국 프로젝트관리협회(PMI) 용어집에서 프로젝트 헌장은 사업을 공식으로 승인하고 PM에게 자원 투입 권한을 주는 문서입니다. 프로젝트 관리계획은 그다음에 실행, 감시, 통제, 종료를 어떻게 할지 적는 문서죠.

공공 SW의 사업수행계획서는 후자에 가깝죠. 제안서는 헌장과 영업 자료가 섞인 낙찰용 묶음이고, 수행계획서는 계약 금액과 기간, 기술협상으로 빠진 화면, 확정 WBS를 한 철로 모은 실행본입니다.

표지만 바꾸고 본문을 입찰본으로 두면, 낙찰 때 넣었던 부가 화면이 그대로 오픈 범위로 남죠. 과학기술정보통신부 소프트웨어사업 계약 및 관리감독에 관한 지침 제25조제5항은, 계약 때 합의한 수행계획서나 과업내용서로 과업이 구체화되면 그다음부터는 그 문서를 확정 과업으로 본다고 적습니다.

입찰본을 승인받으면 입찰본이 기준선이 되죠. PMBOK이 말하는 관리계획을 착수 주에 다시 쓰는 이유가 여기 있습니다.

계약이 끝나자마자 꼭 제출해야 할까?

지침은 계약 체결 후 제출이라고만 적습니다. 며칠인지는 과업지시서와 착수계 칸이 정하죠. 그 칸이 비면 수행계획은 구두 파일이 됩니다.

같은 지침 제18조제4항은 계약상대자가 계약 체결 후 사업수행계획서를 국가기관등의 장에게 내라고 하고, 발주는 이행에 필요한 정보를 주라고 적습니다. 법정 일수를 18조가 며칠로 박아 두지는 않죠.

현장 과업지시서가 계약일부터 7일 안 착수보고를 넣는 경우가 많고, 그때 수행계획과 산출내역, 보안서약이 착수계 묶음으로 붙습니다. 7일을 모든 사업의 법으로 외우면 안 됩니다.

다만 그 주가 비면 개발 WBS만 돌아가고 기준 문서는 늦게 따라옵니다. 제18조제5항은 발주가 수행 상태와 산출물을 검사할 합동검토계획을 세우고 그 계획대로 검토하라고 하죠.

합동검토 일정이 수행계획에 없으면 중반 산출물 검사가 주간회의 감상으로 줄어듭니다. 착수 주에 제출일, 승인 주체, 합동검토 첫 날짜를 한 줄에 두지 않으면, 승인 없는 파일이 이미 일정표가 됩니다.

인력표만 고치면 왜 3단 비교에서 막힐까?

감리와 발주 착수 점검은 제안요청서, 제안서, 수행계획을 한 표에 놓습니다. 이름만 바뀐 인력칸은 통과해도, 범위와 일정과 산출물이 입찰본이면 표가 깨집니다.

정보화사업 착수 점검에서 자주 보는 칸이 세 줄입니다. 착수계를 받았는가, 기술협상 결과가 수행계획에 들어갔는가, 제안요청서와 제안서와 수행계획을 담은 3단 비교표를 봤는가.

인력 실명만 고치면 첫 줄은 채워집니다. 둘째 줄과 셋째 줄은 범위 칸이죠.

낙찰 전 제안서에 넣었던 대시보드 네 본이 협상에서 두 본으로 줄었는데 수행계획 화면 목록이 네 본이면, 비교표는 제안서를 이깁니다. 기능점수나 서비스수준협약으로 대가를 산정한 사업은 같은 지침 제18조제3항이 투입 인원 수와 투입 기간을 관리하지 말라고 합니다.

수행계획에 맨먼스 투입표를 크게 그려 두면, 발주가 그 표를 주간 관리 칸으로 읽기 쉽습니다. 기능점수 계약에서 인력표는 제안 이력이지 진척 분모가 아닙니다.

분모는 확정 기능과 산출물입니다. 3단 비교의 가운데 열을 인력으로만 채우면, 감리는 범위 열을 비었다고 봅니다.

기술협상으로 빠진 화면은 어디에 적나?

수행계획의 범위 장과 과업대비표, 산출내역에 같은 번호로 내립니다. 회의록에만 남기면 입찰본이 다시 오픈 범위가 됩니다.

과업심의 실무 자료는 사업수행계획서를 제안요청서의 개발 범위, 사업자 제안서, 기술과 가격 협상 결과를 반영해 쓰라고 말합니다. 협상에서 뺀 연계 한 건을 회의록 PDF에만 두면, 수행계획 화면 목록은 제안서 숫자를 유지합니다.

승인을 받는 순간 그 숫자는 제25조제5항의 확정 과업이 됩니다. 빠진 화면은 세 곳에 같이 내려야 합니다.

범위 장의 비목표 칸, 요구 ID가 있는 과업대비표, 기능점수나 공수가 붙은 산출내역. 한곳만 고치면 중반 기성에서 다른 두 장이 입찰본을 증거로 내밉니다.

상용소프트웨어 직접구매가 있는 사업은 도입 시기와 협력 창을 수행계획에 적지 않으면, 구축 일정만 있고 라이선스 창은 공란입니다. 공란은 개발이 끝난 뒤에야 구매 이슈가 됩니다.

Risk(위험) 대장에 협상 잔여를 한 줄로라도 옮기지 않으면, 잔여는 다음 주 현업 요청으로 돌아옵니다.

승인받은 뒤에 범위가 늘면 수행계획을 고치면 될까?

승인본을 임의로 고치면 기준선이 사라집니다. 변경은 변경 창구와 과업심의를 타고, 개정 번호가 있는 수행계획만 다음 기준이 됩니다.

수행계획 승인은 착수의 끝이 아니라 변경의 출발점입니다. 주간 CCB에서 화면 두 본을 더 받기로 했어도, 그 사인이 곧 계약 과업은 아닙니다.

공공 SW에서는 과업 내용과 금액, 기간 조정이 과업심의 칸을 타는 경우가 있고, 프로젝트 안의 변경관리는 그 칸의 앞단 기록입니다. 승인본 워드 파일의 날짜만 오늘로 바꿔 올리면, 감리는 어느 버전이 기준인지 묻습니다.

개정 이력에 버전, 변경 안건 번호, 반영 장, 승인일을 남기고, 같은 주의 WBS와 산출내역을 맞춥니다. 이력을 안 남긴 채 본문만 고치면 입찰본과 최신본이 동시에 살아 있습니다.

전자정부법 제57조에 해당하는 정보화는 감리가 의무인 구간이 있고, 감리는 계약 문서와 수행계획 준수를 봅니다. 준수 대상이 두 파일이면 지적 사항은 항상 최신본이 아니라 승인본을 집어 듭니다.

승인 주에 버전 칸을 만들지 않으면, 중반의 모든 추가가 원래부터 있던 일처럼 읽힙니다.