인사이트
「프로젝트가 무너지는 여섯 개의 순간」 — PM 실무 에세이 시리즈.
시리즈 「프로젝트가 무너지는 여섯 개의 순간」 — 1편
빠뜨린 일은 '계획에 없던 일'이 아니다
착수 3주 뒤 "이 작업은 누가 하기로 했죠?" — WBS 100% Rule·8/80 Rule·상호배제로 빠뜨린 일을 계획 단계에서 잡는다.
시리즈 「프로젝트가 무너지는 여섯 개의 순간」 — 2편
엑셀로 만든 계획은 만든 날부터 죽는다
WBS 따로, 간트 따로 — 2주 뒤 두 문서가 서로 다른 말을 한다. 계획 산출물과 실행 데이터를 하나의 모델로.
시리즈 「프로젝트가 무너지는 여섯 개의 순간」 — 3편
일정이 밀린 게 아니라, 기준이 사라진 것이다
"원래 계획이 뭐였죠?"에 아무도 답 못 하는 회의 — 베이스라인 스냅샷과 변경통제(CR·CCB)의 힘.
시리즈 「프로젝트가 무너지는 여섯 개의 순간」 — 4편
'80% 완료'라는 거짓말
8주째 80%에 멈춘 진척률 — EVM 기초(PV·EV·AC, SPI·CPI)와 정직한 진척 산정 규칙.
시리즈 「프로젝트가 무너지는 여섯 개의 순간」 — 5편
WBS와 애자일은 싸우지 않는다
"우린 애자일이라 WBS 안 써요"와 계약·보고 요구 사이에 낀 PM — What의 분해(WBS)와 How의 실행(스프린트)은 싸우지 않는다.
시리즈 「프로젝트가 무너지는 여섯 개의 순간」 — 6편
보고서를 만드느라 프로젝트를 못 챙기는 PM
주간보고·RACI·Dictionary에 주 10시간 쓰는 PM — 산출물은 '작성'이 아니라 '추출'이어야 한다.
케이스 스터디
Claude에게 SI 프로젝트 WBS를 통째로 맡겨봤다
PAT로 wbsgantt MCP에 연결해, 6개월 제조사 ERP 구축 WBS를 Claude가 초안·정련·일정·정의서까지 만들게 했다 — 회상은 기계, 약속은 사람.
케이스 스터디
이번 주간보고는 쓰지 않고 뽑았다
Claude와 만든 그 ERP 프로젝트에서 Excel 내보내기 버튼 하나로 개요·WBS·주간·월간 네 시트를 뽑았다 — 자동으로 채워지는 것과 사람이 채워야 하는 칸의 경계.
케이스 스터디
그 ERP 프로젝트에 리스크 등록부를 붙여봤다
같은 ERP 프로젝트 위에 5×5 매트릭스로 리스크 8건을 식별·평가·대응·감시했다 — WBS 노드에 매달린 리스크는 계획을 볼 때마다 따라온다.
케이스 스터디
그 ERP 프로젝트, 실행 7주차에 밀리기 시작했다
Baseline을 잡고 진척을 넣자 SPI 0.84가 먼저 경고했다 — S-Curve와 Top Delay로 지연의 원인 작업까지 내려간 실행 리포트.
케이스 스터디
이 마감일, 원래 언제였죠?
일정 조정 직후, 변경 이력으로 복기했다 — 필드 단위 old→new와 누가·언제, 그리고 기록되지 않는 것까지.
케이스 스터디
한 작업이 3일 밀리면, 전체는 며칠 밀리는가
+3일을 넣자 CPM이 연쇄를 다시 계산했다 — 처음엔 0일 지연, 알고 보니 빠진 선 하나. 종속성을 채우자 크리티컬 패스가 통째로 이사했다.
케이스 스터디
계획을 통째로 망쳤다. ⌘Z로는 부족했다
위험한 편집 직전 BL-2를 체크포인트로 박고, 한 번의 사고로 단계 하나가 통째로 날아간 계획을 스냅샷으로 되돌렸다 — 자동 백업·진척률 보존·전부-아니면-전무.