프로젝트 변경 관리 프로세스
Change Control Process
프로젝트를 진행하며 플래닝 단계에서 예상치 못한 범위/일정/원가의 변경이 발생할 수 있다. 이러한 변경을 승인하고, 실행하고, 관리하기 위해 변경 관리 프로세스가 필요하다. PM을 포함한 프로젝트 팀원 누구나 변경을 요청할 수 있고, 승인자는 변경의 영향을 분석하여 승인 또는 거부를 결정하며, 이 모든 프로세스를 변경 로그에 기록해야 한다. 변경 관리 프로세스가 없는 조직에서 변경을 실행하려면 누구에게 어떻게 변경을 요청해야 하는지부터 찾아야 한다. 이 같은 주먹구구식 문제 해결 방식을 없애고, 체계적으로 변경을 관리하기 위해 변경 관리 프로세스가 필요하다.
변경 관리 프로세스
변경 관리는 프로젝트 팀이나 조직에서 정의하는 변경 관리 계획의 일부이다. 쉽게 말하면 프로젝트 변경 요청을 추적하는 변경 로그를 만들고 관리하는 절차이다.
프로젝트 이해관계자는 누구나 변경을 요청할 수 있다. 요청은 프로젝트 일정이 살짝 변경되는 것처럼 사소할 수도 있고, 프로젝트 결과물이 변경되는 등의 큰 영향이 있을 수도 있다. 변경을 요청하는 자는 요청이 거부될 수도 있다는 점을 유념해야 한다. 변경 요청이 승인될지, 거부될지는 승인자에게 달려 있기 때문이다.
변경 관리 프로세스의 이점
1. 변경을 요청하고 승인받기 위해 쏟는 불필요한 시간 낭비를 없앨 수 있다.
2. 공유 스페이스에 변경을 기록하여 커뮤니케이션을 효율적으로 할 수 있다.
3. 변경을 관리하여 프로젝트 타임라인 및 결과물을 효과적으로 관리할 수 있다.
변경 관리 프로세스
우선 전통적인 변경 관리 프로세스를 알아보기 위해 아래와 같이 레퍼런스를 조사했다.
출처: https://asana.com/프로젝트 협업 툴을 제공하는 Asana에서 제안하는 변경 관리 프로세스는 총 5단계로 다음과 같다.
1. 개시 : 변경을 요청하는 단계
2. 평가 : 변경을 평가하는 단계
3. 분석 : 변경을 승인하거나 거부하는 단계
4. 구현 : 변경을 적용하는 단계
5. 종결 : 변경 요청을 종결하는 단계
출처: https://www.atlassian.com/Jira를 만든 Atlassian에서 제안하는 변경 관리 프로세스는 총 6단계로 다음과 같다.
1. 변경 요청 : 예상되는 위험, 구현 및 영향을 받는 시스템에 대해 작성하여 변경을 요청하는 단계
2. 변경 요청 검토 : 변경 관리자 또는 동료 검토자가 초기 변경 요청을 검토하는 단계로 성공 가능성, 위험과 보상이 정확한지, 적용할 가치가 있는지 검토한다.
3. 변경 계획 : 프로젝트 팀에서 변경에 대한 계획을 세우는 단계로 예상 결과, 리소스, 일정, 테스트 요건 및 롤백 하는 방법을 문서화한다.
4. 변경 승인 : 변경 관리자, 동료 검토자 또는 CAB가 계획을 검토하고 변경을 승인 또는 거부하는 단계
5. 변경 구현 : 변경을 실행하고, 그 과정에서 절차와 결과를 문서화하는 단계
6. 변경 마감 : 변경 관리자가 변경 사항을 검토하고 적절할 때 종료하며, 보고서에 변경이 성공적인지, 시기적절 한지, 정확하게 예측되었는지, 예산 범위 내에서 이루어졌는지 등을 작성하는 단계
상기 레퍼런스를 참고하여 내가 만든 변경 관리 프로세스는 아래와 같다.
1. 요청
- 프로젝트 범위/일정/원가의 변경이 필요한 경우, 프로젝트 팀원 누구나 변경을 요청할 수 있다.
- 변경을 요청하려는 프로젝트 팀원은 변경 요청서를 작성하고 프로젝트 리더에게 공유한다.
- 프로젝트 리더도 변경을 제안할 수 있으며, 동일하게 변경 요청서를 작성하면 된다.
2. 평가
- 결정을 내리는 단계가 아닌 변경되는 사항에 대해 검토하는 단계이다.
- 프로젝트 리더는 변경 요청서의 내용을 평가하고, 필요 시 수정 및 보완한다.
3. 승인
- 리더십에서 변경에 대한 승인 또는 거부를 최종적으로 결정하는 단계이다.
- 승인 시 다음 단계(실행)로 넘어가며, 변경 요청서와 프로젝트 문서에 관련 내용을 기록한다.
- 거부 시 거부 사유 등을 변경 요청서에 기록하고, 혼선을 방지하기 위해 프로젝트 팀에 내용을 공유한다.
4. 실행
- PM 또는 프로젝트 리더는 변경사항을 프로젝트 팀에 공유하고, 이해관계자들이 변경을 적용할 수 있도록 한다.
예시 1) 일정이 변경된 경우 Project Timeline을 업데이트하고 팀에 공유
예시 2) 범위가 변경된 경우 One-pager, PRD 등을 업데이트하고 팀에 공유
5. 종결
- 변경 요청서 및 변경이 기록된 모든 문서를 프로젝트 공유 스페이스에 저장하고 변경을 종결한다.
변경 요청서
변경을 요청하려는 팀원은 조직의 템플릿에 맞춰 변경 요청서를 작성하고 프로젝트 리더에게 공유해야 한다. 변경 요청서에는 아래와 같은 내용이 포함된다.
- 프로젝트명
- 요청 일자
- 요청자
- 변경 책임자
- 우선순위: 다음의 변경 종류에 따라 우선순위를 정한다.
표준 변경: 위험이 적고 자주 수행되며 문서화된 프로세스를 따르는 사전 승인된 변경
일반적인 변경: CAB(변경 자문 위원회)의 추가 검토 및 승인이 필요한 비긴급 변경
긴급 변경: 예기치 않은 오류 또는 위협으로 인해 발생하며 즉시 해결해야 하는 변경
- 변경되는 내용
- 변경이 미치는 영향
- 필요한 리소스
- 마감일
오늘은 변경 관리 계획의 일부인 변경 관리 프로세스에 대해 이야기했는데, 사실 변경 관리 계획에서 가장 중요한 것은 변경 로그(Change Log)를 작성하고 관리하는 것이다. 다음 포스팅에서는 변경이 승인 또는 거부됨에 따라 해당 내용을 변경 로그에 업데이트하는 방법과 최종적으로 변경이 종결된 후 프로젝트 공유 스페이스에 변경 로그를 저장(Archiving) 하는 방법에 대해 이야기하겠다.
