2011.11.28

칼럼 | PMO를 별도 프로젝트로 간주해야

Gary Hamilton, Gareth Byatt, Jeff Hodgkinson | CIO

기업들은 대형 IT프로젝트가 끝난 후, 변화관리를 담당하는 전문 부서인 PMO(Program and/or project management office)를 별도로 둔다. 프로젝트를 위해 만들었던 TF팀이 일시적인 부서였다면 PMO는 프로세스 혁신(PI)이 제대로 정착되는지를 관리하는, 장기간 존재하는 부서라 할 수 있다.



<CIO 호주지부> 기자들이 독자들에게 당부하고 싶은 것은 PMO의 이점을 관리하거나 정의를 설명한 기사들과 이 기사를 따로 떨어뜨려 생각하지 말라는 것이다.

유수의 전문가들과 기업들이 이 주제에 관해 작성한 많은 자료들이 있으며 독자들은 여기서 얻은 값진 정보를 채택하거나 각자의 상황에 맞게 적용할 수 있다. 그래서 <CIO 호주지부>는 PMO 자체가 프로젝트라는 관점에 초점을 맞춘 ‘틈새 시각’을 제공하고자 한다.  

<CIO 호주지부>는 많은 프로젝트 관리를 경험한 PMO 전문가들과의 논의를 거쳤다. 그들에 따르면, PMO를 수립할 때 이 자체를 고위 간부들이 깊이 관여하는 여타의 프로젝트처럼 다룬다는 핵심 원칙이 기대만큼의 관심을 끌지 못한 것을 깨닫게 되면서 어려움을 겪게 된다는 것이다.

우선은 프로젝트에서 가장 기본적인 지표라 할 수 있는 '시작'과 '끝'에 관해서 논의해 보고 이것들이 PMO를 수립하는 것과 어떤 관련이 있는지 알아보자. '프로젝트의 시작'은 아이디어가 PMO의 초기 단계 또는 탐구 단계에 있을 때를 말한다. 우리는 PM에게 C-레벨 임원이 접근했거나 PM이 'PMO'의 아이디어를 가지고 그들에게 접근하고 있으며, 타당성에 관한 정보를 계속해서 수집할 수 있도록 구두로 허가 받을 것을 가정했다.

'프로젝트의 끝'은 PMO가 '수립됐다'고 여겨지며 이제 비즈니스 프로세스나 운영의 일부분으로 지속될 때라고 할 수 있다. 이렇게 되면 그 중간 부분이 상당히 광범위해 진다. 프로젝트가 시작되면 다음 핵심 지표는 재정지원 허가를 위해 현재 프로젝트의 '지속/비지속' 여부를 결정할 때가 된다. 확실한 성공을 위해 PM의 프레젠테이션에는 'PMO의 수립'이 하나의 프로젝트로 설명돼야 한다. 물론 해당 프로젝트가 완료되면 PMO 관리자로 지정될 수 있는 프로젝트 관리자가 필요하다.

따라서 다른 프로젝트들과 마찬가지로 PMO 프로젝트를 수립해야 한다. 그래야 분명하면서도 측정할 수 있는 목적, 범위, 일정, 품질, 예산, 위험, 중요한 성공 요소(CSF) 등이 포함된 프로젝트 허가서를 받을 수 있기 때문이다. 이 각 요소를 위한 지침은 아래와 같다.

목적: 다른 프로젝트처럼 문제를 해결하거나 기회에 따라 행동할 것인가? 프로젝트 실행이 계속해서 문제가 된다면 PM의 프레젠테이션은 이 주제에 대해 PMO가 어떻게 해결할 수 있는지 구체적으로 설명하는 방법으로 접근할 수 있을 것이다. 기회가 된다면 PMO가 프로젝트 실행 기간을 단축시키고 생산성을 향상시키며 관리 간접비가 낮아지는 등의 추가적인 이점을 제공한다는 것을 가정하도록 한다.

범위: PMO를 준비하기 위한 모든 작업을 요약하자. 관리자나 PM의 선임, 중앙집중식 데이터베이스, 문서 표준화, 공통 성과지표, 의사소통, 일정관리 소프트웨어 등 프로젝트를 위한 요소들을 정리한다.




2011.11.28

칼럼 | PMO를 별도 프로젝트로 간주해야

Gary Hamilton, Gareth Byatt, Jeff Hodgkinson | CIO

기업들은 대형 IT프로젝트가 끝난 후, 변화관리를 담당하는 전문 부서인 PMO(Program and/or project management office)를 별도로 둔다. 프로젝트를 위해 만들었던 TF팀이 일시적인 부서였다면 PMO는 프로세스 혁신(PI)이 제대로 정착되는지를 관리하는, 장기간 존재하는 부서라 할 수 있다.



<CIO 호주지부> 기자들이 독자들에게 당부하고 싶은 것은 PMO의 이점을 관리하거나 정의를 설명한 기사들과 이 기사를 따로 떨어뜨려 생각하지 말라는 것이다.

유수의 전문가들과 기업들이 이 주제에 관해 작성한 많은 자료들이 있으며 독자들은 여기서 얻은 값진 정보를 채택하거나 각자의 상황에 맞게 적용할 수 있다. 그래서 <CIO 호주지부>는 PMO 자체가 프로젝트라는 관점에 초점을 맞춘 ‘틈새 시각’을 제공하고자 한다.  

<CIO 호주지부>는 많은 프로젝트 관리를 경험한 PMO 전문가들과의 논의를 거쳤다. 그들에 따르면, PMO를 수립할 때 이 자체를 고위 간부들이 깊이 관여하는 여타의 프로젝트처럼 다룬다는 핵심 원칙이 기대만큼의 관심을 끌지 못한 것을 깨닫게 되면서 어려움을 겪게 된다는 것이다.

우선은 프로젝트에서 가장 기본적인 지표라 할 수 있는 '시작'과 '끝'에 관해서 논의해 보고 이것들이 PMO를 수립하는 것과 어떤 관련이 있는지 알아보자. '프로젝트의 시작'은 아이디어가 PMO의 초기 단계 또는 탐구 단계에 있을 때를 말한다. 우리는 PM에게 C-레벨 임원이 접근했거나 PM이 'PMO'의 아이디어를 가지고 그들에게 접근하고 있으며, 타당성에 관한 정보를 계속해서 수집할 수 있도록 구두로 허가 받을 것을 가정했다.

'프로젝트의 끝'은 PMO가 '수립됐다'고 여겨지며 이제 비즈니스 프로세스나 운영의 일부분으로 지속될 때라고 할 수 있다. 이렇게 되면 그 중간 부분이 상당히 광범위해 진다. 프로젝트가 시작되면 다음 핵심 지표는 재정지원 허가를 위해 현재 프로젝트의 '지속/비지속' 여부를 결정할 때가 된다. 확실한 성공을 위해 PM의 프레젠테이션에는 'PMO의 수립'이 하나의 프로젝트로 설명돼야 한다. 물론 해당 프로젝트가 완료되면 PMO 관리자로 지정될 수 있는 프로젝트 관리자가 필요하다.

따라서 다른 프로젝트들과 마찬가지로 PMO 프로젝트를 수립해야 한다. 그래야 분명하면서도 측정할 수 있는 목적, 범위, 일정, 품질, 예산, 위험, 중요한 성공 요소(CSF) 등이 포함된 프로젝트 허가서를 받을 수 있기 때문이다. 이 각 요소를 위한 지침은 아래와 같다.

목적: 다른 프로젝트처럼 문제를 해결하거나 기회에 따라 행동할 것인가? 프로젝트 실행이 계속해서 문제가 된다면 PM의 프레젠테이션은 이 주제에 대해 PMO가 어떻게 해결할 수 있는지 구체적으로 설명하는 방법으로 접근할 수 있을 것이다. 기회가 된다면 PMO가 프로젝트 실행 기간을 단축시키고 생산성을 향상시키며 관리 간접비가 낮아지는 등의 추가적인 이점을 제공한다는 것을 가정하도록 한다.

범위: PMO를 준비하기 위한 모든 작업을 요약하자. 관리자나 PM의 선임, 중앙집중식 데이터베이스, 문서 표준화, 공통 성과지표, 의사소통, 일정관리 소프트웨어 등 프로젝트를 위한 요소들을 정리한다.


X