06 PM이 알아야 할 범위 관리
“첫 단추가 잘못 끼워진 프로젝트입니다.”
일을 하다보면 이런 비유를 쓸 때가 있다. PM이 알아야할 관리 역량 중 이 첫 단추에 해당하는 것이 범위 관리다. 옷을 입다가 첫 단추를 잘못 끼우면 단추를 풀러서 다시 끼운다. 이를 초반에 알면 다시 풀러야 할 단추가 많지 않아 덜 수고스럽다. 그런데 마지막까지 다 채웠는데 끼워야 할 단추가 남았다는 걸 알게 되면 대략 난감하다. 모든 단추를 다시 풀러서 단추구멍에 다시 일일이 다시 끼워야 하는데 여기 또 하나, 단추가 적으면 그나마 다행인데 단추가 많으면.. 그 다음은 안봐도 비디오다.
프로젝트도 이와 동일하다. 첫 단추가 잘못 끼워지면 시작부터 순조롭지 않다. 그 이유를 빨리 파악하면 잘못 끼워진 단추를 빨리 다시 풀러서 다시 끼우고 그 이후 과정을 진행해 나가면 된다. 첫 단추가 잘못 채워졌는데 알면서도 그대로 진행을 하거나 알지도 못한 채 너무 많은 시간이 지나고 나면 단추를 다시 풀러서 채울 수도 없는 상황이 초래된다. 일정이 지연되는 것은 기본이고 손해배상까지 가는 엄청난 사태가 발생할 수도 있다. 범위 관리가 PM의 관리 역량의 첫 번째인 이유가 이러한 중요도 때문이다. 첫 번째 단추를 잘 끼워도 나머지 단추가 잘못 끼워지는 상황이 발생할 수 있는데 첫 단추부터 잘못 끼운다는 것은 본인의 손으로 헬 게이트를 열고 프로젝트를 착수한다는 것을 의미한다. 혼자만의 여정이라면 제발로 호랑이 굴에 들어가든 토끼굴에 들어가든 상관 없지만 프로젝트는 팀원과 함께 하는 작업이다. 팀원을 사지로 몰아넣는 PM이 되어서도 안 되지만, 팀원을 사지로 몰아넣고 PM 본인만 살아남는 프로젝트를 만들어서는 더 더욱 안 된다.
첫 단추를 잘 끼우기 위해 사전에 체크해야 할 사항들은 다음과 같다. 제안 참여나 계약/견적에 관여하지 않은 구축 프로젝트 기준이며, 진행 순서는 회사와 프로젝트마다 일부 다를 수 있다.
제안 산출물, 계약, 견적 검토하기
- RFP 내용과 제안 내용 일치 여부 검토하기
- RFP에는 없지만 영업과 사전 협의된 추가 요구사항이 있다면 어떤 내용인지 확인하기
- RFP와 함께 공유받은 요구사항 정의서가 있다면 해당 자료 함께 검토하기
- RFP상의 업무 범위와 견적서에 기재된 업무 범위 동일 여부 확인하기
- RFP상의 업무 범위와 견적서에 기재된 투입 공수 확인하기 (인력 등급과 MM)
- 계약서 내 정의된 업무 범위와 검수 및 계약금 지급일자 확인하기
- 계약서 내 의심 조항 확인하고 문의하기
AS-IS 사전 분석하기 (리뉴얼 프로젝트인 경우)
- 구현 환경
- 유저 플로우, 정보 구조, 내비게이션 구조
- 레이아웃, 컴포넌트, 화면 구조 (주요 기능/화면 중심, 캡쳐는 필수)
- 컨텐츠, 비주얼, 인터랙션 요소 (브랜드 연관성, 가이드 요소 중심)
!!!!! 제안에 참여하여 해당 단계를 함께 진행한 경우 스킵할 수 있다 !!!!!
내부 수행 계획서 작성, 리스크 사전 진단 및 대응 방안 협의
- 개요: 구축 배경, 목표, 추진 방향
- 구현 환경: 구현 채널(PC Web, Mobile Web/App 등), 구현 방법(적응형/반응형,
Web/Native/Hybrid), 해상도, OS 버전, 브라우저 버전, 기준 디바이스 범위, 그 외 고려해야 할
시스템 환경
- 구현 범위: 기능 요구사항, UX/UI 요구사항, 비주얼/인터랙션 요구사항, 컨텐츠 요구사항
(최대한 상세히) * AS-IS 분석과 비교하여 유지/개편/신규/삭제 요건 체크하기
- 일정: WBS(마일스톤 기준)
- 조직: 고객사/협력사, TFT(견적 기준), 의사결정 및 이해관계, 그 외 특이사항
- 산출물: 워킹/공식 산출물 목록 및 특이사항, 검수 및 제출 일정 (감리 진행 여부 반드시 확인 필요)
- 사전 리스크 진단 및 대응 방안: 구현 환경 ~ 산출물 상에서 예상되는 리스크와 사전 대응 방안 수립
및 협의
- 기타: 파견 여부, 파견지 환경, 파견지 그라운드 룰, 업무 장비, 유의사항 등
!!!!! 기술 협상 단계에 관여할 경우 내부 킥오프 내용 기반으로 사전 진단한 리스크를 미연에 방지할 수 있도록 최대한 협상을 이끌어 낸다. 리스크를 안고 진행해야 할 경우 내부적인 대응 방안을 수립하고 협의 후 진행한다 !!!!!
!!!!! 해당 내용을 기반으로 수행계획서와 수정 견적을 작성하고, 계약을 진행한다. PM이 견적서 작성과 계약 진행을 하지 않는 경우, 협의한 범위와 공수 기반으로 수행계획서를 작성한다 !!!!!
지금까지 프로젝트 착수 전 체크해야 할 범위 관리 사항들을 살펴보았다. 첫 단추를 잘 끼웠더라도 다음 단추들이 잘못 끼워질 수 있으니 단추와 단추구멍을 확인하고 끼우는 습관을 들여야 한다. PM은 회사가 개입할 정도로 문제를 발생시켜도 문제를 키워도 안되며, 각 단계에서 회사의 손실과 신뢰에 손상을 입을 리스크가 감지될 경우 PM은 교체될 수 있다.
분석 단계: 수행 계획서 상의 업무 범위와 요구사항을 기반으로 상세 요구사항을 정의 단계에서 다양한 요인에 의한 요건 변경이 발생할 수 있다. 프로젝트 일정, 투입 인력 범주 안에서 진행 가능한 요구사항인지 확인하고 협의 및 관리를 진행한다.
전략 단계: 구현을 위한 상세 전략 수립과 디자인 시안 작업 진행 과정에서 다양한 이해 관계와 최고 의사결정권자의 영향도 요인에 의한 요건 변경이 발생할 수 있다. 내부 요인에 의한 이슈도 흔히 발생하는 단계이므로 방향성, 실행 가능성, 퀄리티 이슈가 발생하지 않도록 철저히 중간 점검을 진행한다. 외부 요인에 의한 이슈는 계약된 일정과 인력 범주를 벗어난 범위가 될 수 있으므로 이러한 경우에는 영업 또는 상위 의사결정권자를 대동하여 협의 및 관리를 진행한다.
실행 단계: 화면설계와 화면디자인, 그래픽 디자인 단계에서 추가/변경 요건이 발생할 수 있다. 현업/개발 리뷰 전에 반드시 내부 리뷰를 선 진행하고 내부적으로 요건 변경 및 퀄리티 이슈가 발생하지 않도록 점검 및 관리를 진행한다. 이후 현업/개발 리뷰와 승인 절차를 거쳐 1.0 버전을 배포한다. 1.0 버전은 개발 단계에서 이슈 발생 시 문제 제공자 여부가 누군지를 판가름하는 첫 증거 자료이므로 반드시 합의를 통해 산출된 1.0 버전을 배포하고, 해당 버전 기반으로 개발이 착수될 수 있도록 한다.
개발 단계: 개발 진행상에서 추가/변경 요건이 발생할 수 있다. 개발사가 다른 협력사인 경우 불가피한 충돌이 발생할 수 있으므로 PM은 기민하고 전략적으로 상황에 대처할 수 있도록 해야 한다. 분석/전략/실행 단계에서 범위 관리를 잘 진행해 왔다면 해당 단계에서도 문제를 떠안을 확률은 거의 제로, 하지만 이 전 단계에서 단추를 잘못 끼워온 것이 이 단계에서 발견된다면 상황의 반전은 절대 일어날 수 없고 기적이 일어날 수 없으므로 회사가 개입하여 문제 해결 방안을 함께 찾아야 하며, 손실 또한 감수해야 한다.
!!!!! 분석, 전략 단계를 무난히 잘 통과했다면 그 이후 단계는 불가피한 충돌들만 잘 해결하고 가면 된다 !!!!!
!!!!! 내부적인 이슈가 있을 경우(인력이나 퀄리티 이슈) 실행 단계까지 업무 로드가 발생할 수 있다. 이 시기에 PM이 손발 역할을 해주면서 이슈를 해징하고 일정 준수를 한다면 고객의 무한 신뢰 도장을 찍고 갈 수 있다. PM이 실무를 놓아서는 안되고, 실무를 할 수 있어야 하는 이유다 !!!!!
!!!!! 개발 단계에서 불가피한 충돌 외에 고난이 계속 된다면 그동안의 단추도 잘못 끼워왔을 확률이 높다. 회사가 필히 관여하여 최대한 손실을 방지할 수 있도록 방안을 찾아 사태를 마무리 지어야 한다 !!!!!
20년 넘게 프로젝트 PM 역할을 하면서 내린 결론은 ‘세상에 똑같은 프로젝트는 단 하나도 없다. 그리고, 예상은 항상 틀리지 않고 과한 욕심을 내면 결국 망한다.’ 사전에 점검하고 방지하고, 하다못해 회사가 협력해 주지 않으면 회사에 예상 리스크 발생에 대해 사전 선언이라도 하고 갈 수 있다. 그러니 괜한 고객이나 협력사 탓하지 말고 나 자신부터 먼저 돌아보며 단계마다의 범위 관리를 꼼꼼히 잘 하시길… 그리고, 그동안 내가 헬 게이트를 여는 장본인은 아니었는지, 팀원들을 사지로 몰아넣고 나만 살아 돌아온 PM은 아닌지 가슴에 손을 얹고 반성해 보시길.. 본인의 이런 일관성을 깨닫지 못하는 PM이 주변에 있다면 더 많은 사상자가 발생하기 전에 조치를 취하시길 권해 드립니다.
* 프로젝트 현실에 직면하여 풀리지 않는 의문이나 사전 리스크 진단이나 문제 해결 방안에 대한 조언이 필요하신 분들은 언제든 연락주세요. 현실적인 해결 방안을 드리기 위해서는 구체적인 내용 확인이 필요하니 도움이 필요하신 분들은 개인적으로 연락 부탁드려요.
