범위가 슬금슬금 늘 때: 작은 프로젝트의 변경요청 최소 절차

요지

범위추가(scope creep)는 한 번에 크게 오지 않는다. 「이것만 하나 더」, 「이 정도는 금방이죠?」가 쌓여서 온다. 하나하나는 작아 보여 거절하기 어렵고, 기록도 남지 않는다. 그러다 끝날 무렵 일정과 원가가 맞지 않는 이유를 아무도 설명하지 못한다. 이 글은 범위가 늘어나는 것을 알아채는 신호와, 작은 프로젝트에서도 부담 없이 쓸 수 있는 변경요청 한 줄 기록과 승인 기준을 정리한다. 범위와 일정을 먼저 정해 놓고 진행하는 프로젝트를 기준으로 썼다.

범위추가와 통제된 변경의 차이

변경 자체는 나쁜 것이 아니다. 일을 하다 보면 처음에 몰랐던 것을 알게 되고, 계획을 바꾸는 편이 나은 때가 생긴다. 범위추가는 다르다. 할 일은 늘었는데 일정도 예산도 사람도 다시 잡지 않은 상태, 아무도 정하지 않았는데 범위가 넓어진 상태다. 둘을 구분하는 것은 요청의 내용이 아니라 들어오는 길이다.

표는 가로로 밀어서 볼 수 있습니다.

같은 요청이라도 왼쪽 길로 들어오면 변경이고, 오른쪽 길로 들어오면 범위추가다. 그러니 막아야 할 것은 변경이 아니라 기록과 판단 없이 들어오는 길이다.

통제가 시작되는 때도 알아 둔다. 통제는 범위를 합의한 날부터 시작된다. 그 전의 수정은 계획 세우기이고 그 뒤의 수정은 변경이다. 그래서 「여기까지가 이번 범위」라고 합의한 문서가 먼저 있어야 한다. 그것이 없으면 무엇이 추가인지조차 말할 수 없다.

알아채는 신호 다섯 가지

• 일정은 그대로인데 할 일 목록이 길어졌다. 지난달 목록과 이번 달 목록을 나란히 놓아 보면 바로 보인다.
• 「그 김에」라는 말이 자주 들린다. 「화면 고치는 그 김에 이것도」는 범위추가의 가장 흔한 입구다.
• 요청이 정해 둔 창구가 아닌 곳으로 온다. 담당자에게 직접 온 메시지, 복도에서 들은 부탁이 그대로 할 일이 된다.
• 완료 기준이 자꾸 바뀐다. 「다 됐어요」 뒤에 「그런데 이것도 되나요?」가 이어지고 검수가 끝나지 않는다.
• 팀이 늦게까지 일하는데 진척률은 그대로다. 늘어난 일이 계획에 없으니 진척으로 잡히지 않는다.

신호 하나만 보이면 우연일 수 있다. 둘 이상이 함께 보이면 범위추가라고 보고 기록부터 시작한다. 숫자로 보고 싶다면 계획에 없던 인도물이 전체 인도물에서 차지하는 비율을 재는 방법이 있다(지침서 2.2.5). 이 비율이 점검 때마다 오른다면 범위추가가 진행 중이다.

변경요청 한 줄 기록

작은 프로젝트에 무거운 양식은 맞지 않는다. 공유 문서의 표 하나면 된다. 요청 하나에 한 줄이다. 요청이 말로 왔더라도 표에 옮겨 적은 뒤에 일을 시작한다. PMBOK® 지침서는 제출된 변경과 그 처리 결과를 모두 적는 문서를 변경사항 기록부라고 부르는데, 아래 표가 그 가장 작은 형태다.

표는 가로로 밀어서 볼 수 있습니다.

가장 중요한 칸은 영향이다. 일정과 원가가 기본이고, 자원이나 리스크, 다른 이해관계자에게 미치는 영향이 있으면 함께 적는다. 요청자는 대개 자기 요청이 무엇을 밀어내는지 모른다. 「3일이 들고, 그만큼 남은 예비가 줄어든다」를 적어서 보여 주면 요청자 스스로 요청을 거두거나 줄이는 일도 생긴다.

누가 정하나: 영향 크기별 승인 기준

모든 요청을 스폰서에게 올리면 스폰서가 지치고, 모든 요청을 프로젝트 관리자가 정하면 큰 결정이 묻힌다. 누가 정하는지는 프로젝트를 시작할 때 계획에 적어 둔다. 영향 크기로 기준을 나누면 그때그때 다투지 않는다. 아래는 하나의 예시다. 경계는 프로젝트 크기에 맞게 정한다.

• 작음(일정 영향 없음, 추가 원가 없음): 프로젝트 관리자가 정하고 기록만 남긴다.
• 중간(일정이나 원가에 영향이 있지만 정해 둔 예비 안): 프로젝트 관리자가 요청자 쪽 책임자와 함께 정한다.
• 큼(오픈일, 계약 금액, 핵심 범위처럼 기준선이 바뀜): 스폰서가 정한다. 규모가 큰 프로젝트라면 변경통제위원회(CCB)가 이 몫을 맡는다.

큰 변경은 결정이 나오기까지 시간이 걸린다. 기다리는 동안에도 하기로 한 일은 그대로 한다. 그사이 넣으면 무엇이 밀리고 빼면 무엇을 잃는지 정리해 결정자에게 가져간다.

기준은 착수 회의에서 요청할 사람들과 함께 정해 둔다. 요청이 들어온 뒤에 기준을 꺼내면 거부하려고 만든 규칙처럼 들린다.

짧은 주기로 만들어 보이며 가는 프로젝트라면 절차가 조금 다르다. 요청을 백로그에 올리고 영향을 따져 순서를 매긴다. 승인 도장 대신 백로그의 순서가 결정을 말해 준다. 위에 놓이면 곧 할 일, 아래로 밀리면 미뤄진 일, 목록에 없으면 하지 않기로 한 일이다(지침서 2.1.6.8.2). 기록하고, 영향을 보고, 정해 둔 사람이 정한다는 점은 같다.

거부하는 말과 미루는 말

거부도 연기도 영향을 근거로 말하면 덜 부딪힌다.

• 거부: 「좋은 생각입니다. 다만 지금 넣으면 오픈일이 일주일 밀립니다. 오픈일이 더 중요하다고 정해 두었으니 이번에는 빼겠습니다. CR-09로 기록해 두었습니다.」
• 연기: 「이번 오픈 범위에는 넣지 않고 다음 개선 목록 맨 위에 올리겠습니다. 오픈 뒤 첫 회의에서 다시 보겠습니다.」
• 맞바꿈: 「이것을 넣으려면 다른 기능 하나를 빼야 합니다. 둘 중 어느 쪽을 먼저 할지 정해 주십시오.」

어느 경우든 「기록해 두었다」는 말을 함께 한다. 요청이 사라지지 않았다는 것을 알면 요청자도 받아들이기 쉽다.

바로 쓰는 변경 기록 한 장

• 「여기까지가 이번 범위」라고 합의한 문서가 있는지 확인한다
• 공유 문서에 번호, 요청자, 무엇, 왜, 영향, 결정, 결정자와 날짜 칸을 만든다
• 착수 회의에서 영향 크기별로 누가 정할지 함께 정한다
• 말이나 메신저로 온 요청도 한 줄로 옮겨 적는다
• 승인하기 전에 일정과 원가에 미치는 영향을 먼저 적는다
• 승인한 변경은 범위, 일정, 예산 문서에 바로 반영한다
• 연기하거나 거부한 요청도 지우지 않고 남긴다
• 정기 점검 때 계획에 없던 일이 얼마나 늘었는지 지난번과 비교한다

요구사항 자체를 정리하는 법은 「요구사항 관리」 글을, 계약 문서에 범위를 적는 법은 「작업기술서(SOW)에 꼭 들어갈 항목」 글을 함께 보면 된다.

참고

• PMBOK® 지침서 8판 한국어판, 지침서 편 2.1.6.8 변경 평가 및 실행, 2.2.5 결과 확인, 섹션 4 투입물 및 결과물, 용어집. 범위추가의 뜻, 기준선을 정한 뒤부터 변경을 통제한다는 것, 요청을 글로 남긴다는 것, 승인과 연기와 거부, 변경통제위원회, 변경사항 기록부, 결정을 기다리는 동안의 일, 백로그로 변경을 다루는 방식, 범위추가를 비율로 재는 방법의 개념과 용어만 따랐다. 문장은 옮기지 않았다.
• 신호 다섯 가지, 한 줄 기록의 칸, 영향 크기별 승인 기준 예시, 말 예시는 이 글에서 새로 정리했다. 예시 프로젝트와 날짜는 가상의 것이다.
• PMI와 PMBOK은 Project Management Institute의 등록 상표입니다.