일정이 밀린 게 아니라, 기준이 사라진 것이다

프로젝트 5개월 차, 스폰서가 묻는다. "그래서 지금 얼마나 밀린 겁니까?" PM이 답한다. "3주 정도입니다." 스폰서가 다시 묻는다. "무엇 대비 3주죠? 원래 계획이 뭐였는데요?"

회의실이 조용해진다. '원래 계획'이라 부를 만한 것이 여러 개이기 때문이다. 킥오프 때의 계획, 요구사항이 추가된 뒤의 계획, 인력이 빠진 뒤 다시 짠 계획. 그 사이의 어느 시점부터 최신 계획이 곧 원래 계획이 되어 있었다. 일정이 밀렸다는 사실보다 심각한 것은, 무엇으로부터 밀렸는지 아무도 말할 수 없다는 사실이다.

기준 없는 측정은 측정이 아니다

"3주 지연"은 측정값이다. 모든 측정값에는 기준점이 필요하다. 몸무게가 늘었다는 말은 언제 대비인지 없이는 의미가 없다. 프로젝트에서 이 기준점을 베이스라인(baseline) 이라 부른다. 승인된 시점의 범위·일정·원가를 통째로 얼려 둔 스냅샷이다.

베이스라인이 없는 프로젝트에서 벌어지는 일은 늘 같다.

계획을 고칠 때마다 이전 계획을 덮어쓴다. 그래서 지연은 항상 "최근에 고친 계획 대비"로만 측정되고, 매번 조금씩만 밀린 것처럼 보인다. 3일씩 열 번 밀리면 한 달이지만, 기록이 없으면 그 누적은 어디에도 보이지 않는다. 이것이 프로젝트가 조용히 침몰하는 방식이다. 큰 사고가 아니라, 기준점의 실종으로.

더 나쁜 것은 범위 쪽이다. 요구사항이 하나둘 추가될 때 베이스라인이 없으면 "원래 범위가 어디까지였는지" 논쟁이 된다. 그 논쟁에서 PM은 대개 진다. 문서가 없는 쪽이 지게 되어 있다.

베이스라인은 문서가 아니라 규율이다

PMBok은 이 문제에 두 가지 장치를 처방한다.

첫째, 승인 시점에 스냅샷을 얼려라. 계획이 승인되는 순간의 WBS·일정·원가를 통째로 저장하고, 그 뒤로는 절대 수정하지 않는다. 수정하지 않는다는 것이 핵심이다. 베이스라인은 고치는 것이 아니라 새로 뜨는 것이다(re-baseline). 그리고 새로 뜰 때는 반드시 승인 절차를 거친다.

둘째, 모든 변경을 기준 대비 차이로 관리하라. 변경요청(Change Request)이 들어오면 "이 변경이 베이스라인 대비 일정·원가·범위에 어떤 영향을 주는가"를 산정하고, 승인 권한자(CCB, Change Control Board)의 결정을 기록한다. 이 기록이 쌓이면, 5개월 차 스폰서의 질문에 이렇게 답할 수 있게 된다. "승인된 베이스라인 대비 3주 지연이며, 그중 2주는 승인된 CR-007과 CR-011의 영향, 1주는 순수 지연입니다."

같은 "3주"인데 무게가 완전히 다르다. 앞의 답은 변명처럼 들리고, 뒤의 답은 통제처럼 들린다. 실제로도 그렇다. 뒤의 PM은 프로젝트를 통제하고 있다.

베이스라인·예측·실적 — 절대 섞으면 안 되는 세 개의 날짜

실무에서 가장 자주 무너지는 지점은 이 세 개념의 혼동이다.

지연이란 Forecast − Baseline이다. Actual과 Forecast만 있으면 "예상보다 밀렸다"는 말은 할 수 있어도 "약속보다 밀렸다"는 말은 할 수 없다. 그리고 스폰서가 궁금한 것은 언제나 후자다.

베이스라인을 뜨기 전에는 네 가지가 갖춰졌는지 확인한다. 승인된 WBS(1편의 100% Rule 통과), 의존성 기반 일정 계산 완료, 주요 가정의 문서화(투입 인력·외부 의존·환율 같은 전제), 예산·자원 기준 확정. 이 중 하나라도 빠진 채 얼린 스냅샷은 기준이 아니라 짐이 된다.

변경요청 처리의 5단계

베이스라인이 살아 있으려면 변경이 이 경로로만 흘러야 한다.

1. 접수 — 변경 요청을 양식으로 받는다 (구두 요청은 접수가 아니다)
2. 영향 분석 — 베이스라인 대비 일정·원가·범위 델타를 산정한다
3. 승인/반려 — CCB(또는 지정된 승인권자)가 결정하고 기록한다
4. 델타 기록 — 승인된 변경을 베이스라인 대비 차이로 등록한다 (CR 번호 부여)
5. Forecast 반영 — 예측 일정에 반영하고 이해관계자에게 통지한다

이 경로가 있으면 스폰서 보고가 문장 하나로 정리된다.

"현재 예상 완료일은 베이스라인 대비 15일 지연입니다. 그중 10일은 승인된 범위 변경(CR-007, CR-011), 5일은 실행 지연이며, 실행 지연분에 대한 만회 계획은 다음과 같습니다."

지연의 총량이 아니라 지연의 구성을 말하는 순간, 보고는 변명에서 통제로 바뀐다.

언제 re-baseline 하는가

베이스라인을 지키는 규율만큼, 놓아줄 때를 아는 것도 중요하다.

• 유지: 개별 CR로 설명 가능한 수준의 변경. 누적 델타가 관리 가능한 범위
• 재설정 검토: 승인된 변경의 누적으로 원래 기준이 무의미해졌을 때 (경험칙: 델타가 전체의 15~20%를 넘을 때), 또는 사업 목표 자체가 바뀌었을 때
• 원칙: 재설정은 반드시 스폰서 승인을 거치고, 이전 베이스라인은 삭제하지 않고 보존한다. 실행 지연을 리셋으로 세탁하는 것이 아니라, 새 약속을 다시 하는 것이다

왜 다들 알면서 안 하는가

베이스라인 개념을 모르는 PMP는 없다. 그런데 현장에서 자주 실종되는 이유는 단순하다. 수작업으로는 유지 비용이 너무 크기 때문이다. 엑셀에서 베이스라인을 지키려면 파일을 복사해 날짜를 붙이고, 변경 때마다 두 파일을 대조해야 한다. 바쁜 주에 가장 먼저 생략되는 일이 바로 이런 일이다.

우리가 도구를 만들며 세운 원칙 하나는, 베이스라인을 부속 파일이 아니라 시스템의 1급 객체로 다뤄야 한다는 것이었다. 스냅샷이 자동으로 얼려지고 모든 변경이 기준 대비 차이로 표시된다면, 규율을 지키는 비용이 0에 가까워진다. 규율은 의지로 지키는 것보다 구조로 지키는 것이 오래간다.

당장 할 수 있는 일도 있다. 오늘 날짜로 현재 계획의 사본을 만들어 읽기 전용으로 잠그고, 팀 전체에 공지하라. "오늘부터 모든 지연과 변경은 이 파일 대비로 말합니다." 그 한 문장이 기준점을 되살린다.

밀리는 것은 죄가 아니다. 무엇으로부터 밀렸는지 모르는 것이 죄다.

PM의 실행 블록

내일 바로 할 일 3가지

1. 현재 계획의 사본을 날짜 붙여 읽기 전용으로 잠그고 "오늘부터의 기준"으로 공지한다
2. 진행 중인 변경 요청을 전부 목록화하고 CR 번호를 부여한다 (소급해서라도)
3. 다음 보고부터 "베이스라인 대비 N일, 그중 승인 변경 N일 + 실행 지연 N일" 형식을 쓴다

회의에서 던질 질문

• "이 지연은 무엇 대비입니까? 그 기준은 언제 승인됐습니까?"
• "이 변경의 베이스라인 영향은 산정됐습니까? CR 번호가 있습니까?"
• "지금 누적 델타가 전체의 몇 %입니까? re-baseline을 논의할 때입니까?"

좋은 신호 / 나쁜 신호

도구는 무엇을 해결해야 하는가

베이스라인 규율이 무너지는 이유는 유지 비용이었다. 그래서 wbsgantt는 베이스라인을 파일 사본이 아닌 시스템의 1급 객체로 만들었다 — 승인 시점에 자동으로 얼려지고, 간트 위에 기준선과 현재선이 겹쳐 그려지며, 모든 변경이 델타로 기록된다. 규율의 비용이 0이 되면, 남는 것은 판단뿐이다.