brunch

You can make anything
by writing

C.S.Lewis

by 목휴 May 06. 2023

내가 경험한 PMO의 케이스들

IT회사에서 수년간 컨설턴트로 살아오면서 다양한 형태의 크고 작은 프로젝트를 하였는데 그때마다 늘 신기했던 것이 바로 PMO(Project Management Office)의 정체였다. 


프로젝트 원으로서 고객사에 들어가서 산출물을 만들고 회의도 하면서 가끔 보였던 사람들. "저 사람들 도대체 뭐 하는 사람들이지?" 라며 나를 갸우뚱갸우뚱하게 만들었던 존재. 내가 직접 PMO가 되고 나서야 "아 이게 이런 거구나" 하고 어렴풋이 이해를 할 수 있었는데 사실 그렇게 되기까지는 사실 꽤 많은 시간이 걸렸던 것 같다. 


그간 내가 경험했던 세 개의 PMO에 대해서 이야기해보고자 한다. 


1. 대규모 장기 프로젝트의 상시조직 PMO 


첫 번째 케이스는 회사의 근간이 되는 큰 IT시스템을 다음 제너레이션으로 바꾸기 위한 장기 프로젝트였다.  시스템은 고객사의 메가 프로세스와 긴밀하게 결합되어있었기에, 시스템을 기획하고 개발하는 업무에 고객사 영역 별 실무자들이 상시 업무로서 굴비처럼 엮어있었고, 프로세스 정비, 시스템 개발, 시스템 안정화 및 확산까지 최소 3년 이상 걸리는 프로젝트였다. 


내가 맡은 프로젝트는 장기 프로젝트의 후반부에 만들어진 소규모 프로젝트로 "타깃 시스템의 확산을 돕기 위한 도구를 기획하고 실행"하는 것이 목표였는데, 여기서 만난 PMO는 수년간 이어져온 부서와 같은 모습이었다. 


상시 조직의 모습을 띈 이 PMO는 놀랍게도 거의 행정업무에 완벽히 집중된 모습이었다. 

처음 사이트에 도착했을 때 업무 환경 세팅을 해주고 보안 규정에 대해 알려주고, 우리에게 WBS와 산출물 정의서를 요청하고 때때로 고객과의 회의를 잡아주고 그리고 때가 되었을 때 산출물을 취합했다. 


프로젝트의 내용, 혹은 그와 관련된 의사결정에는 거의 관여하지 않고 너무나 정직하게 코디네이션만 했기 때문에 우리가 고객의 니즈를 좀 더 잘 이해하도록 부연 설명을 해준다던가 전체 프로젝트 맥락에 대해서 업데이트를 해준다거나 하는 부분은 기대할 수가 없었다. 


다만 업무 상에서 필요한 문서가 있을 때, 만나야 할 사람이 있을 때, 필요한 업무자원이 있을 때 요청하면 고객과 커뮤니케이션해서 지원해 주는 역할을 했다. 


2. 변화관리에 집중하는 전략적 PMO 


두 번째 케이스는 IT시스템 운영 프로젝트에 참여했을 때 만난 PMO였는데, 고객사는 기존의 시스템을 운영하면서 새로운 시스템으로 이관하기 위한 준비를 동시에 진행하고자 했다. 


나는 기존 시스템 측 프로젝트의 일원으로서 새로운 시스템으로 이관할 때까지 기존 서비스를 정상적으로 운영하는 동시에 이관에 필요한 요소들을 고객사 측에 제공해야 했는데 여기서 만난 PMO는 새로운 시스템을 선정하고 성공적으로 도입하는 역할이었다. 


지금 생각해 보면 이 PMO는 전략 컨설팅 역할에 PMO를 겸한 모습이라고 볼 수 있었는데, 그렇게 생각하게 된 이유는 이 PMO가 고객의 목표에 따라 전체 일정을 관리하고 목표에 맞는 산출물이 나올 수 있도록 지원하는 동시에 고객이 생각하는 우선순위에 영향을 줬기 때문이다


예를 들어 A라는 목표가 있으면 그를 위해 최초에 B-C-D-F라는 일을 순서대로 진행하기로 하였는데, PMO의 개입으로 C가 없어지고 B-D-F-G가 된다거나 B-D-F순으로 진행되어야 할 일이 B-F-D 이런 식으로 순서까지 뒤바뀌는 현상이 일어났다. 


사실 A라는 목표로 가는 길은 처음부터 하나가 아니었다. 따라서 PMO는 프로젝트 진행 중 큰 이슈가 발생하거나 아니면 고객의 입장에서 목표를 달성하는데 더 유리한 제3의 길을 찾았다고 판단했을 때 프로젝트 안에서 일어나야 하는 일의 순서나 종류까지도 재구성했던 것이다. 이러한 과정에서 PMO는 고객과 굉장히 긴밀하게 커뮤니케이션했고 그들의 요구사항을 디벨롭하는데 중요한 역할을 했다. 


3. 서로 다른 시각을 통합하는 데 집중하는 Integrative PMO 


마지막 케이스는 내가 직접 PMO 역할을 했던 컨설팅 프로젝트였다. 


단순히 컨설팅으로 끝나는 게 아니라 후속 시스템 개발을 기약하기 위해 고객의 니즈에 맞게 아이디어를 내고 이를 실행가능한 모습으로 구체화하는 것이 목표였다. 따라서 IT관점에서만 볼게 아니라 타깃 시스템의 도메인인 마케팅, 고객이 원하는 맞춤화된 서비스를 구현하는데 근간이 되는 데이터의 관점에서 고객의 비즈니스와 시스템을 바라봐야만 했다. 


하지만 이 세 개의 시각, 세 개의 분과가 서로 너무나 달랐기 때문에 각자의 세계관을 조율하고 통합하는 역할이 프로젝트의 성공을 위해 너무 중요했다. 그렇지 않으면 각자 최선을 다했는데 결과는 산으로 가는 상황이 발생하기가 너무 쉬운 환경이었다. 


각자의 이점을 살리되 하나의 통합된 산출물로 나오게 하기 위해서 고객과 또 각 분과 간 끊임없이 서로 소통하고 조율하는 역할이 PMO의 주된 역할이었다. 물론 기본적으로 프로젝트의 기준을 수립하고, 일정과 산출물이 제 때에 나올 수 있도록 관리하고 지원하는 역할이 기본이었고 그 위에 고객의 진화하는 니즈, 프로젝트의 목표, 그리고 서로 다른 시각들이 얼라인 될 수 있도록 통합 관리(Integrtion Management)를 수행하였다. 




내가 경험한 세 개의 PMO는 사실 너무 각양각색인 모습이었다. 프로젝트의 목표, 성격 및 조직의 구조에 따라서 PMO 역할의 포커스가 달라진다는 것을 알 수 있었다. 또한 PMO의 크기, 그리고 구성하는 인력들의 특성도 달라졌다. 


하지만 여기서의 공통점은 언제 PMO가 필요한가에 대한 인사이트이다. 

내가 관찰과 경험을 통해 깨달은 것은 아래의 두 가지였다. 


하나의 커다란 목표를 위해 복수의 프로젝트가 동시에 돌아가는 경우 PMO가 반드시 필요하다. 또한 이것은 종종 복수의 서로 다른 역할을 하는 파트너사가 참여하는 프로젝트일 경우가 많다. 각자 잘하는 부분을 하려고 들어왔지만 좀 더 큰 시각에서 통합적으로 관리가 되지 않는다면 프로젝트는 실패할 수 있다. 이는 고객사 입장에서 시간, 비용, 노력의 낭비가 일어나게 된다는 의미가 된다. 이를 방지하기 위해 PMO가 필요한 것이다.


또 하나의 공통점은 PMO는 반드시 고객사와 외주사의 인력들이 모두 참여하는 방식으로 구성된다는 점이다. 프로젝트를 성공적으로 수행하는데 필요한 정보와 이해관계자의 의견들을 적시에 취합하기에 용이한 구조를 만들어야 되기 때문이 아닌가 싶다. 


수년 전부터 DT(Digital Transformation)가 큰 화두가 되었고 그에 따라 기업 내에서 체질을 바꾸기 위한 대규모 프로젝트들이 많이 일어나고 있기에 PMO의 중요성은 앞으로도 점점 더 커지면 커졌지 줄어들지는 않을 것 같다. 



 


 



 




작가의 이전글 ChatGPT는 교육프로그램 설계에 활용될 수 있을까?
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari