개발과 관리는 별개의 영역
프로젝트관리조직(PMO) 체제 도입의 성공은 PMO에 대한 올바른 이해로부터 출발한다. 일부 시스템통합(SI) 업체들은 PMO가 필요없다거나 또는 역할을 최소화하는 방향으로 고객을 유도함으로써 혼란을 가중시키고 있다. PMO 체제가 도입되면 SI업체는 보다 높은 수준의 관리와 통제를 받기 때문이다. PMO 체제 도입과 관련해 몇 가지 중요한 논점에 대해 살펴본다.
◇왜 PMO가 필요한가=과거 IT부서 업무는 운영업무가 80% 이상이었으며, 프로젝트는 간혹 발생하는 `사건'이었다. 지금은 여러 개의 프로젝트가 동시에 진행되는 경우가 많아졌으며, 이로인해 프로젝트 관리 능력이 그만큼 중요하게 됐다. 또 정보시스템의 통합성이 강조되고, 다양한 선진기술이 적용됨에 따라 내용적으로도 프로젝트 관리의 난이도가 높아졌다. 따라서 전문적이고 독립적인 프로젝트 관리 기능이 필요하게 된 것이다.
PMO는 프로젝트 전체 비용을 줄이기 위해 필요하다. 프로젝트 총 비용은 프로젝트 소요비용과 실패로 인한 기회비용의 합이다. 과거에는 총 비용에 실패에 따른 기회비용을 고려하지 않았으나, 지금은 정보시스템 실패는 기업의 경영위험으로까지 연결되고 있기 때문에 실패의 기회비용을 감안해야 한다.
실패의 기회비용은 실패할 경우 예상되는 손실액에 실패 확률을 곱한 값이다. 프로젝트 실패에 따른 손실액에는 가동 지연에 따른 영업기회 상실 비용과 가동 이후 수정 보완에 드는 비용, 가동 이후 예상 활용기간 단축에 따른 비용 등이 포함된다.
PMO를 도입하면 초기 비용은 증가하지만 프로젝트 성공 확률을 높임으로써 결과적으로 프로젝트 총비용을 절감할 수 있다.
◇PMO 체계에 관한 혼란=PMO 도입방식과 관련해 다양한 오해가 존재한다. 하나는 분업인가, 균형인가에 관한 것이고, 다른 하나는 프로젝트 조직인가, 프로세스 조직인가에 대한 것이다.
프로젝트 팀에도 관리 기능이 있는데 PMO를 두게 되면 관리 기능이 중복되는 것이 아닌가하는 의문을 갖게 된다. 분업은 적은 비용으로 높은 산출을 얻게 한다. 생산성에 초점을 맞추게 되면 PMO는 오버헤드만 발생시키는 조직으로 인식하는 오류를 범하게 된다. PMO는 목표 달성을 담보하기 위해 필요한 조직이라는 점을 깨닫는 것이 중요하다.
개발에 치우치다 보면 프로젝트의 목표 달성 및 전사적 통합의 관점을 잃어버리기 쉽다. 또 개발팀에만 의존하다 보면 프로젝트 상황을 객관적으로 파악할 수 없다. PMO는 균형을 추구함으로써 결과적으로 프로젝트의 성공 및 비즈니스 효과 창출에 기여한다.
특정 프로젝트를 위해 PMO 조직을 도입하는 것은 원칙적으로 잘못된 것이다. PMO는 하나의 프로젝트를 위한 조직이 아니다. 복수의 프로젝트를 일관되게 관리하기 위해 필요한 조직이 바로 PMO이다. PMO는 프로젝트의 기획 단계에서부터 종료 이후 평가단계까지를 주관할 수 있어야 한다. 잘못 시작된 프로젝트를 성공시키는 것은 거의 불가능하기 때문이다. 또 PMO는 프로젝트 조직이 아니고 상설 조직이어야 한다. PMO가 종종 `Program Management Office`로 표현되는 것도 이런 이유에서이다.
PMO는 원칙적으로 `갑'이 주도해야 한다. PMO는 아웃소싱 대상이 아니며, 외부요원에 대한 의존도가 크면 클수록 프로젝트의 실패가능성도 높아진다는 점을 명심해야 한다.
다만 PMO를 수행하기 위해 필요한 전문인력이 부족할 경우 외부 인원을 활용하는 것은 바람직하다. PMO에 투입되는 외부 요원을 흔히 `갑의 친구'라고 부르는 것은, 소속은 외부 요원이라 하더라도 PMO에 투입되는 순간 `갑'의 입장에서 프로젝트 관리를 진행해야 한다는 뜻이다.
◇필요한 역량과 규모=PMO의 사명은 비즈니스에 적합한 정보시스템 구현을 책임지는 것이라 할 수 있다. 즉 비즈니스와 정보기술의 연결고리 역할을 담당한다. 따라서 PMO가 갖춰야 할 역량으로는 경영전략에 대한 이해, 충분한 업무지식, 방법론 및 구현 관련 정보기술 능력, 프로젝트 관리 프로세스에 대한 이해와 경험 등 네 가지를 들 수 있다.
PMO에 투입되는 외부 요원은 헌신성과 객관성을 갖추어야 한다. SI사업 또는 장비 공급 등과 같은 사업분야를 수행하고 있다면 공정한 PMO역할을 기대하기 어렵다.
대부분의 전산조직은 만성적인 인력부족 현상을 겪고 있다. PMO의 필요성을 이해하면서도 필요 수준의 인원 충원이 불가능해 착수하지 못하는 경우가 많다. 최소 인원으로 일단 시작하고 보는 기업도 더러 있다. 그러나 인원 규모에 따라 관리의 깊이를 조절하는 것은 바람직하지 않다. 대충하는 관리는 차라리 하지 않는 것만도 못하기 때문이다.
PMO가 확보해야 할 인원은 <표>와 같다. <표>에서 보듯이 일부 업무는 기존에도 담당자가 있을 수 있다. 이런 경우에는 IT조직 전체의 업무 분장을 조정해야 하고, 이렇게 함으로써 인원 충원에 대한 부담도 줄일 수 있다.
IT조직의 크기에 따라 차이가 있겠지만, PMO 조직은 최소 5명 이상은 돼야 한다. 전산인력의 수가 100명을 넘는 경우에는 전체 인원의 5∼10% 정도를 확보해야만 한다.
PMO에 인원을 투입하는 것만으로 PMO 체제를 가동시킬 수 있는 것은 아니다. PMO가 제대로 활동하기 위해서는 PMO의 베이스라인이 확보돼 있어야 한다. PMO 베이스라인은 아키텍처, 정보화계획, 소프트웨어프로세스(주로 프로젝트 관리 및 요구사항 관리), 보유 자원 내역(인력 포함) 등이다. 베이스라인이 확보되지 않은 기업은 사전 PMO 단계를 거쳐야만 한다. 사전 PMO 단계는 1∼4개월 정도 소요된다. 장기적으로는 PMO 프로세스를 자동화하는 것도 필요하다.
PMO는 프로젝트와 상관없이 차세대형 IT 조직의 관점에서 필요하고, 차세대 프로젝트는 PMO 조직이 구성된 이후에 착수하는 것이 바람직하다. 프로젝트 일정에 여유가 없어서 `사전 PMO' 단계를 수행할 수 없다면, 첫번째 프로젝트 과정에서 전사에 적합한 IT관리체제를 구축하고 이를 발전시켜나가는 방안도 가능하다.
프로젝트관리조직(PMO) 체제 도입의 성공은 PMO에 대한 올바른 이해로부터 출발한다. 일부 시스템통합(SI) 업체들은 PMO가 필요없다거나 또는 역할을 최소화하는 방향으로 고객을 유도함으로써 혼란을 가중시키고 있다. PMO 체제가 도입되면 SI업체는 보다 높은 수준의 관리와 통제를 받기 때문이다. PMO 체제 도입과 관련해 몇 가지 중요한 논점에 대해 살펴본다.
◇왜 PMO가 필요한가=과거 IT부서 업무는 운영업무가 80% 이상이었으며, 프로젝트는 간혹 발생하는 `사건'이었다. 지금은 여러 개의 프로젝트가 동시에 진행되는 경우가 많아졌으며, 이로인해 프로젝트 관리 능력이 그만큼 중요하게 됐다. 또 정보시스템의 통합성이 강조되고, 다양한 선진기술이 적용됨에 따라 내용적으로도 프로젝트 관리의 난이도가 높아졌다. 따라서 전문적이고 독립적인 프로젝트 관리 기능이 필요하게 된 것이다.
PMO는 프로젝트 전체 비용을 줄이기 위해 필요하다. 프로젝트 총 비용은 프로젝트 소요비용과 실패로 인한 기회비용의 합이다. 과거에는 총 비용에 실패에 따른 기회비용을 고려하지 않았으나, 지금은 정보시스템 실패는 기업의 경영위험으로까지 연결되고 있기 때문에 실패의 기회비용을 감안해야 한다.
실패의 기회비용은 실패할 경우 예상되는 손실액에 실패 확률을 곱한 값이다. 프로젝트 실패에 따른 손실액에는 가동 지연에 따른 영업기회 상실 비용과 가동 이후 수정 보완에 드는 비용, 가동 이후 예상 활용기간 단축에 따른 비용 등이 포함된다.
PMO를 도입하면 초기 비용은 증가하지만 프로젝트 성공 확률을 높임으로써 결과적으로 프로젝트 총비용을 절감할 수 있다.
◇PMO 체계에 관한 혼란=PMO 도입방식과 관련해 다양한 오해가 존재한다. 하나는 분업인가, 균형인가에 관한 것이고, 다른 하나는 프로젝트 조직인가, 프로세스 조직인가에 대한 것이다.
프로젝트 팀에도 관리 기능이 있는데 PMO를 두게 되면 관리 기능이 중복되는 것이 아닌가하는 의문을 갖게 된다. 분업은 적은 비용으로 높은 산출을 얻게 한다. 생산성에 초점을 맞추게 되면 PMO는 오버헤드만 발생시키는 조직으로 인식하는 오류를 범하게 된다. PMO는 목표 달성을 담보하기 위해 필요한 조직이라는 점을 깨닫는 것이 중요하다.
개발에 치우치다 보면 프로젝트의 목표 달성 및 전사적 통합의 관점을 잃어버리기 쉽다. 또 개발팀에만 의존하다 보면 프로젝트 상황을 객관적으로 파악할 수 없다. PMO는 균형을 추구함으로써 결과적으로 프로젝트의 성공 및 비즈니스 효과 창출에 기여한다.
특정 프로젝트를 위해 PMO 조직을 도입하는 것은 원칙적으로 잘못된 것이다. PMO는 하나의 프로젝트를 위한 조직이 아니다. 복수의 프로젝트를 일관되게 관리하기 위해 필요한 조직이 바로 PMO이다. PMO는 프로젝트의 기획 단계에서부터 종료 이후 평가단계까지를 주관할 수 있어야 한다. 잘못 시작된 프로젝트를 성공시키는 것은 거의 불가능하기 때문이다. 또 PMO는 프로젝트 조직이 아니고 상설 조직이어야 한다. PMO가 종종 `Program Management Office`로 표현되는 것도 이런 이유에서이다.
PMO는 원칙적으로 `갑'이 주도해야 한다. PMO는 아웃소싱 대상이 아니며, 외부요원에 대한 의존도가 크면 클수록 프로젝트의 실패가능성도 높아진다는 점을 명심해야 한다.
다만 PMO를 수행하기 위해 필요한 전문인력이 부족할 경우 외부 인원을 활용하는 것은 바람직하다. PMO에 투입되는 외부 요원을 흔히 `갑의 친구'라고 부르는 것은, 소속은 외부 요원이라 하더라도 PMO에 투입되는 순간 `갑'의 입장에서 프로젝트 관리를 진행해야 한다는 뜻이다.
◇필요한 역량과 규모=PMO의 사명은 비즈니스에 적합한 정보시스템 구현을 책임지는 것이라 할 수 있다. 즉 비즈니스와 정보기술의 연결고리 역할을 담당한다. 따라서 PMO가 갖춰야 할 역량으로는 경영전략에 대한 이해, 충분한 업무지식, 방법론 및 구현 관련 정보기술 능력, 프로젝트 관리 프로세스에 대한 이해와 경험 등 네 가지를 들 수 있다.
PMO에 투입되는 외부 요원은 헌신성과 객관성을 갖추어야 한다. SI사업 또는 장비 공급 등과 같은 사업분야를 수행하고 있다면 공정한 PMO역할을 기대하기 어렵다.
대부분의 전산조직은 만성적인 인력부족 현상을 겪고 있다. PMO의 필요성을 이해하면서도 필요 수준의 인원 충원이 불가능해 착수하지 못하는 경우가 많다. 최소 인원으로 일단 시작하고 보는 기업도 더러 있다. 그러나 인원 규모에 따라 관리의 깊이를 조절하는 것은 바람직하지 않다. 대충하는 관리는 차라리 하지 않는 것만도 못하기 때문이다.
PMO가 확보해야 할 인원은 <표>와 같다. <표>에서 보듯이 일부 업무는 기존에도 담당자가 있을 수 있다. 이런 경우에는 IT조직 전체의 업무 분장을 조정해야 하고, 이렇게 함으로써 인원 충원에 대한 부담도 줄일 수 있다.
IT조직의 크기에 따라 차이가 있겠지만, PMO 조직은 최소 5명 이상은 돼야 한다. 전산인력의 수가 100명을 넘는 경우에는 전체 인원의 5∼10% 정도를 확보해야만 한다.
PMO에 인원을 투입하는 것만으로 PMO 체제를 가동시킬 수 있는 것은 아니다. PMO가 제대로 활동하기 위해서는 PMO의 베이스라인이 확보돼 있어야 한다. PMO 베이스라인은 아키텍처, 정보화계획, 소프트웨어프로세스(주로 프로젝트 관리 및 요구사항 관리), 보유 자원 내역(인력 포함) 등이다. 베이스라인이 확보되지 않은 기업은 사전 PMO 단계를 거쳐야만 한다. 사전 PMO 단계는 1∼4개월 정도 소요된다. 장기적으로는 PMO 프로세스를 자동화하는 것도 필요하다.
PMO는 프로젝트와 상관없이 차세대형 IT 조직의 관점에서 필요하고, 차세대 프로젝트는 PMO 조직이 구성된 이후에 착수하는 것이 바람직하다. 프로젝트 일정에 여유가 없어서 `사전 PMO' 단계를 수행할 수 없다면, 첫번째 프로젝트 과정에서 전사에 적합한 IT관리체제를 구축하고 이를 발전시켜나가는 방안도 가능하다.
