사업계획서 일정이 2주 늦어졌을 때: 마일스톤 수정표 작성 예시

#기준일을 정하고 남은 작업을 다시 적으세요

마일스톤은 완료 여부를 확인할 수 있는 중요한 결과 지점입니다. 처음 일정표를 만드는 단계라면 마일스톤 일정표 글부터 확인하세요.

가상의 팀이 6주 차 금요일에 일정을 점검한다고 합시다. 이 날짜를 상태기준일로 둡니다. 상태기준일은 그 시점까지 확인한 실제 진척과 이후의 예상 작업을 나누는 기준입니다.

“개발 80% 완료”만으로는 언제 실증을 시작할 수 있는지 알기 어렵습니다. 남은 작업과 완료를 확인할 자료를 적어 보세요.

표의 기간과 목표 수는 이 사례를 위한 가정이며, 어떤 사업에도 적용되는 표준값이 아닙니다. 특히 고객의 참여 의사와 일정 확정은 구분해야 합니다. 제품 준비가 늦어지면 참여 고객의 사정도 바뀔 수 있습니다.

미국 회계감사원 GAO의 일정 관리 가이드는 실제 진척을 반영해 일정을 갱신하고, 작업 간 선후행 관계를 연결하는 방식을 설명합니다. 이 글의 간단한 표는 그 원칙을 초기팀의 문서 수정에 적용한 자체 예시입니다. GAO Schedule Assessment Guide

#다음 작업이 무엇을 기다리는지 표시하세요

선행 작업은 다음 일을 시작하기 전에 끝나야 하는 일입니다. 이 사례에서는 외부 시스템 연동이 끝나야 고객이 실제 업무에서 제품을 써 볼 수 있습니다. 실증 결과가 나와야 수정할 오류를 확정할 수 있고, 그 수정과 출시 점검을 마친 뒤 출시합니다.

기존 계획은 다음과 같았습니다.

연동에 2주가 더 필요하고 뒤의 작업 기간을 그대로 유지한다면, 실증은 9~10주 차, 오류 수정은 11~12주 차, 출시 준비는 13~14주 차로 이동합니다. 기존 출시 예정이 12주 차 말이었다면 수정 예상은 14주 차 말입니다.

모든 작업을 무조건 2주씩 미루지는 않습니다. 실증 참여 일정 재확인이나 사용 안내 초안은 연동 작업과 병행할 여지가 있습니다. 다만 같은 담당자가 같은 시간에 두 일을 할 수 있는지, 제품 변경 때문에 안내서를 다시 써야 하는지도 확인해야 합니다. 병행 가능하다는 말만으로 종료일을 앞당기지는 마세요.

#변경 전후를 한 표에 남기세요

아래는 선행 작업에 걸린 단계만 옮긴 가상 수정표입니다. 새 날짜는 남은 기간과 참여 고객의 일정이 확인된다는 조건의 예상입니다.

기존 일정은 비교 기준으로 보관합니다. 수정 이유와 작성일을 남기고, 이미 실제로 끝난 작업의 완료일은 예상일로 바꾸지 않습니다. 승인이나 협의가 필요한 일정이라면 ‘검토안’, ‘협의 중’, ‘확정’을 구분해 표시하세요.

#마감이 고정돼 있다면 바꿀 범위를 먼저 정하세요

외부 제출일이나 고객에게 약속한 날짜를 옮기기 어려울 수 있습니다. 그럴 때 검토할 수 있는 선택지는 작업 범위 축소, 가능한 작업의 병행, 추가 자원 투입입니다. 각각 어떤 완료 조건을 충족하는지 따져야 합니다.

• 부가 기능을 다음 버전으로 옮긴다면, 이번에 제공할 기능과 제외할 기능을 함께 적습니다
• 작업을 병행한다면, 담당자의 실제 가능한 시간과 재작업 위험을 확인합니다
• 외부 인력을 추가한다면, 인수인계·접근 권한·작업 이해에 필요한 시간을 포함합니다

고객 실증 2주를 근거 없이 1주로 줄여 기존 출시일을 맞추는 식의 수정은 피하세요. 검증 기간을 줄였다면 확인하지 못한 항목도 기록해야 합니다. 안전·보안·필수 규격과 관련된 점검을 생략한 채 같은 결과물을 약속해서도 안 됩니다.

이 사례에서는 연동 문제를 해결해야 실증이 가능한 것으로 가정했으므로, 기능 범위를 바꾼다는 이유만으로 바로 12주 차 출시가 가능해지지는 않습니다. 다른 경로를 택하려면 그 경로에서 필요한 테스트와 고객 동의부터 다시 확인합니다.

#추가 비용과 늦게 들어오는 돈을 구분하세요

일정이 밀리면 예상 잔액도 다시 계산해야 합니다. 이때 이미 예산에 들어 있는 인건비를 전부 ‘추가 비용’으로 또 더하지 않도록 주의하세요. 실제로 늘어나는 지출과 입금 시점이 뒤로 이동하는 효과를 나눠 봅니다.

다음 표는 위 일정표의 11~12주 차에 대한 현금수지 전망입니다. 10주 차 말의 예상 잔액을 두 안 모두 2,000만 원으로 두고, 기존 12주 차 말 출시 준비 완료에 맞춰 받기로 가정했던 300만 원이 지연안에서는 14주 차 말 이후로 이동한다고 봅니다. 금액과 지급 조건은 모두 설명용 가정입니다. 단위는 만 원이며, 같은 시점의 현금 입출금을 비교합니다.

같은 시점의 예상 잔액 차이는 420만 원입니다. 이 중 추가 지출은 120만 원이고, 나머지 300만 원은 해당 기간에 들어오지 않는 돈입니다. 420만 원을 모두 비용 증가나 매출 손실이라고 적으면 의미가 달라집니다. 이 표에서 다룬 기간은 11~12주 차입니다. 출시까지 필요한 13~14주 차의 지출과 입금도 이어서 작성해야 합니다.

입금이 뒤로 이동한다는 가정도 상대방의 실제 지급 조건으로 확인해야 합니다. 실증 완료가 결제 조건인지, 납품·검수·청구와 지급일은 어떻게 연결되는지 계약과 협의 내용을 대조하세요. 아직 합의되지 않은 매출이나 입금은 확정 금액과 구분합니다. 이 표는 자금수지 점검 예시이며 회계상 매출 인식 판단을 대신하지 않습니다.

#외부 문서에는 변경 사실과 다음 판단 시점을 적으세요

수정한 사업계획서에는 지연 사유만 길게 적기보다 현재 상태, 바뀐 일정, 필요한 결정이 보이도록 씁니다. 다음 문장은 앞의 가상 사례를 요약한 작성 예시입니다.

“6주 차 말 기준 핵심 기능의 내부 테스트는 완료했으나 외부 시스템의 오류 처리가 남아 있다. 연동 테스트 완료 예상을 6주 차 말에서 8주 차 말로 변경했다. 이후 실증과 오류 수정 기간을 유지해 출시 준비 완료를 14주 차 말로 다시 추정했다. 8주 차 말 테스트 결과와 참여 고객의 일정을 확인한 뒤 실증 시작일을 확정한다.”

정부지원사업의 협약 기간, 승인된 목표나 사업비가 연결된 경우에는 이 문장만 수정하고 끝내지 마세요. K-Startup의 해당 사업공고와 첨부자료, 본인의 협약서·관리 안내를 찾아 어떤 변경에 사전 협의나 승인이 필요한지 확인해야 합니다. 사업별 규정이 다르므로 이 글의 2주 예시로 기간 연장이나 목표 변경이 허용된다고 판단할 수는 없습니다.

새 계획을 정한 뒤에는 팀의 작업표, 고객에게 전달한 일정, 사업계획서 본문, 자금수지표가 같은 날짜를 쓰는지 확인합니다. 자금수지표는 돈이 들어오고 나가는 시점과 잔액을 적은 표입니다. 다음 점검일에는 실제 완료 여부와 남은 작업을 갱신하세요. 그 기록이 있어야 다시 일정이 바뀌더라도 같은 이유를 처음부터 설명하지 않아도 됩니다.