변경 요청이 들어올 때마다 위원회를 열면 회의만 하다 프로젝트가 늦어져요. 반대로 담당자끼리 알아서 처리하면 일정과 비용이 슬그머니 불어나요. 그래서 먼저 '무엇을 위원회에서 볼지' 기준을 정해 두는 게 좋아요.
어떤 변경 요청을 위원회에 올려야 하나요?
범위·일정·비용·품질 중 하나라도 사전에 합의한 허용 범위를 넘는 변경이면 위원회 안건으로 올려요.
- 범위: 계약서나 요구사항 문서에 없던 기능·산출물 추가
- 일정: 주요 마일스톤(중간 점검 시점)이 밀리는 변경
- 비용: 승인된 예산을 넘거나 추가 예산이 필요한 변경
- 품질: 합의한 인수 기준을 낮추거나 바꾸는 변경
허용 범위를 넘지 않는 사소한 변경은 프로젝트 관리자가 승인하고 기록만 남겨요. 허용 범위의 숫자는 회사와 프로젝트마다 다르니 시작 전에 정해 두세요.
위원회는 누구로 구성하면 좋을까요?
결정할 권한이 있는 사람이 들어와야 해요. 의견만 내는 사람만 모이면 안건이 다음 회의로 계속 미뤄져요.
- 프로젝트 관리자: 변경 내용과 영향을 설명해요
- 발주 측(고객 또는 사업부) 대표: 변경의 필요성과 우선순위를 판단해요
- 개발·실행 책임자: 실제로 가능한지, 얼마나 걸리는지 답해요
- 예산 책임자: 추가 비용을 승인해요
인원은 4~5명 안팎으로 작게 유지하고, 안건에 따라 전문가를 잠깐 부르는 방식이 운영하기 편해요.
심의는 어떤 순서로 하면 되나요?
요청서 접수, 영향 분석, 심의, 결정 기록 순서로 진행해요. 심의에서는 승인·반려·보류 중 하나로 결론을 내고, 이유를 한 줄이라도 남겨야 나중에 다툼이 없어요.
실무 체크 포인트: 승인된 변경은 일정표·예산표·요구사항 문서에 반드시 반영하세요. 결정만 하고 문서를 고치지 않으면 다음 회의에서 같은 논쟁이 반복돼요.
가상의 상황을 하나 볼게요. 홈페이지 개편 프로젝트(가정)에서 고객사가 '회원 등급별 쿠폰 기능'을 추가하자고 했어요. 이 기능은 원래 범위에 없고 개발 일정이 2주 늘어난다는 분석이 나왔어요. 범위와 일정 기준을 모두 넘으니 위원회 안건이 되고, 위원회는 추가 비용과 일정 지연을 확인한 뒤 승인하거나 다음 단계로 미루기로 결정해요. 반면 버튼 문구 수정은 관리자가 바로 처리하고 기록만 남겨요.
오늘 바로 할 일
- 범위·일정·비용·품질별로 '위원회에 올릴 기준'을 한 장으로 정하세요.
- 결정권자를 포함해 위원 4~5명을 정하세요.
- 변경 요청서 양식에 영향 분석과 결정 결과 칸을 넣으세요.