이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
첫 SAP 구축 프로젝트에서 PMO 지원 역할을 맡았을 때, 고객사 측 담당자가 구현 중간에 새 요건을 지속적으로 추가했습니다. 처음엔 작은 요청이라 수용했지만 일정 대비 스코프가 40%가량 늘어나면서 팀 전체가 과부하 상태가 됐습니다. 저는 변경 요청마다 영향도 시트를 만들어 일정·인력·비용에 미치는 영향을 한 눈에 보여줬습니다. 고객사가 시각적으로 보고 나서 요청 우선순위를 스스로 조정하기 시작했습니다.
설득이 아니라 데이터로 트레이드오프를 전달한 게 전환점이었습니다. 그 이후로 저는 변경 관리에서 투명한 영향도 제시가 가장 효과적인 조율 방법이라는 걸 배웠고, 스코프 변경 로그를 꼬박꼬박 남기는 습관이 생겼습니다. 작은 변경이라도 기록으로 남겨두면 나중에 분쟁 없이 정리된다는 것도 배웠습니다.
PMO 역할에서 제가 어려웠던 또 다른 결은, 사업 부서와 IT 부서의 입장이 갈릴 때 그 사이를 조율한 일입니다. SAP 구축 프로젝트에서 사업 측은 새 기능을 빨리 원했고 IT 측은 일정과 안정성을 들어 난색을 표해, 양쪽을 다 만족시킬 수 없었기 때문입니다. 그래서 제가 직접 한 건, 각 요청을 사업 가치와 IT 공수 두 축으로 점수화해 한 표에 올린 일입니다. 어느 게 가치 대비 공수가 큰지를 같은 화면에서 보게 하니, 양측이 감정이 아니라 데이터로 우선순위를 함께 정하기 시작했습니다. 한쪽 편을 드는 게 아니라 트레이드오프를 보이게 한 게 전환점이었습니다. 다만 회고하면 부족함도 솔직히 짚습니다. 저는 PMO 지원 역할이라 그 우선순위의 최종 결정 권한은 없었고, 표를 만들어 올리는 데까지가 제 몫이었습니다. 또 입장 차를 더 일찍 표면화했다면 일정 손실을 줄였을 텐데 중반에야 손댄 게 아쉬웠습니다. 그래서 입장 차를 우선순위로 조율한 경험을 토대로, 그 PMO 역량을 더 키우려 합니다.
PMO 역할에서 제가 어려움을 겪고 배운 건, 작은 변경이라도 기록으로 남겨야 나중에 분쟁이 없다는 점입니다. 첫 SAP 구축 프로젝트에서 고객사가 작은 요건을 계속 추가했는데, 구두로만 받다 보니 스코프가 40%가량 늘어난 뒤엔 무엇을 누가 언제 요청했는지가 흐려졌기 때문입니다. 그래서 제가 직접 한 건, 변경 요청마다 영향도 시트를 만들어 일정·인력·비용 영향을 한눈에 보이고, 그것을 스코프 변경 로그로 꼬박꼬박 남긴 일입니다. 고객사가 시각적으로 트레이드오프를 보고 나서 스스로 요청 우선순위를 조정했고, 설득이 아니라 데이터로 전달한 게 전환점이었습니다. 작은 변경도 기록으로 남기면 나중에 분쟁 없이 정리된다는 걸 배웠습니다. 다만 회고하면 솔직히, 저는 지원 역할이라 변경을 거절할 권한은 없었고 초기엔 작은 요청을 그냥 수용해 과부하를 키운 면도 있습니다. 더 일찍 영향도를 들이댔어야 했습니다. 그래서 변경 로그로 분쟁을 예방한 경험을 토대로, 그 PMO 역량을 더 키우려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.