변경관리 · 이슈·리스크 로그
Change Control & Issue/Risk Log
변경관리란?
- 변경은 막는 것이 아니라 절차로 다루는 것
- 이슈는 발생한 일, 리스크는 발생 가능한 일
- 로그를 회의 첫 안건에 두면 회의가 결정의 자리가 된다
변경관리를 도입하면 팀이 얻는 것은 요청을 막는 권한이 아니라 요청에 가격표를 붙이는 언어입니다. '이것 하나만 더'라는 말에 '그건 개발 3일, 검수 2일이 추가됩니다'라고 답할 수 있게 되면 논의의 주제가 감정에서 거래로 옮겨갑니다. 실무에서 더 크게 달라지는 것은 요청이 들어온 날짜와 요청자 이름이 남는다는 점입니다. 프로젝트가 끝난 뒤 지연 책임을 따질 때 기록이 없으면, 결국 가장 성실하게 야근한 사람이 책임을 지게 됩니다.
모든 변경을 같은 무게로 다루면 절차 자체가 병목이 됩니다. 그래서 현장에서는 영향 규모별로 승인 구간을 쪼갭니다. 일정 3일 이내이고 총예산 2% 이내면 PM 전결, 그 이상은 격주로 여는 변경통제위원회(CCB)에서 다루는 식입니다. 리스크와 이슈의 경계도 운영 규칙으로 정해둬야 합니다. 리스크가 현실이 되는 순간 이슈 로그로 넘기고 원래 리스크 항목은 '발생'으로 닫습니다. 리스크는 확률과 영향도를 곱해 상위 5~7건에만 대응 계획을 붙이고 나머지는 월 1회 재평가하는 편이 실행 가능합니다.
이슈 로그를 회의록의 액션 아이템 목록과 같은 것으로 여기면 금방 무너집니다. 회의록은 그날의 기록이지만, 로그는 닫힐 때까지 번호가 유지되는 하나의 목록입니다. 주간 회의에서는 신규 등록 건과 기한이 지난 건만 먼저 훑고, 닫힌 항목은 누가 언제 무엇으로 닫았는지 한 줄로 남깁니다. 이 한 줄이 몇 달 뒤 같은 문제가 재발했을 때 가장 빨리 찾는 단서가 됩니다.
흔한 오해는 변경관리를 거절 장치로 쓰는 것입니다. 요청이 번번이 반려되면 현업은 절차를 우회해 개발자에게 직접 전화하고, 결국 기준선 문서만 깨끗하고 실제 산출물은 다른 상태가 됩니다. 로그도 마찬가지입니다. 담당자 칸에 '기획팀', 기한 칸에 '추후'라고 적힌 항목은 석 달 뒤에도 '진행 중'입니다. 담당자는 사람 이름 하나, 기한은 날짜 하나로 적어야 로그가 살아 움직입니다.
프로젝트 관리 지식체계(PMBOK)의 통합 변경통제 프로세스에서 체계화됐고, 형상관리·품질관리 실무의 변경 통제 개념과 결합해 산업 전반의 표준적 관리 방식으로 자리 잡았습니다.
국내 중견 화장품 OEM 제조사 A사(임직원 340명, 연매출 1,150억 원)가 8개월 일정으로 ERP 재구축을 진행했습니다. 4개월차에 현업 요청이 메신저와 구두로만 쌓이면서 개발 잔여 과제가 62건까지 늘었고, 오픈 일정은 이미 두 번 밀린 상태였습니다. (가상 예시)
- PMO 팀장이 한 주를 들여 메신저와 메일에 흩어진 요청을 전수 조사해 한 장으로 옮겼더니, 62건 중 38건이 승인 기록 없는 추가 개발이었습니다.
- 영업본부 상무가 '이건 원래 계약에 들어 있던 것 아니냐'고 하자, PMO 팀장이 제안요청서 원문과 한 줄씩 대조해 34건은 신규 요청, 4건은 범위 내로 판정했습니다.
- 이후 변경 요청서에 개발 공수(MD)와 검수 일수를 반드시 적게 하고, 5MD 이하는 PM 전결, 초과 건은 격주 수요일 CCB에서 정보전략실장과 CFO가 함께 결정하도록 바꿨습니다.
- 이슈와 리스크를 한 시트로 합치고 담당자 칸에 부서명 대신 사람 이름을 적게 했습니다. 기한이 지난 항목만 주간 회의 첫 5분에서 다루니 회의가 40분대로 줄었습니다.
- 3개월 뒤 신규 요청 41건 중 19건은 2차 오픈으로 이관하고 22건만 승인해 잔여 과제가 23건으로 줄었고, ERP는 최초 계획 대비 3주 지연으로 마감됐습니다.