성공적인 프로젝트 팀의 비밀
복잡한 프로젝트를 관리하려 할 때, 프로젝트 관리 전문가가 항상 필요한 것은 아니다. 프로젝트를 성공적으로 관리하려면, 그 일을 수행하는 방법을 가장 잘 알고 있는 사람들에게 책임을 맡기면 된다.
딘 메이어
당신의 IT 부서는 복잡한 프로젝트를 수행중이다. 그것은 새로운 애플리케이션을 만드는 프로젝트로, 거기에는 데이터 통합 작업, 웹 전위처리 기능, 새로운 데이터베이스 관리 시스템 플랫폼, 데이터 센터의 전용 서버, 그 애플리케이션 배포와 관련된 현장직원의 훈련 등이 포함된다. 여기에 변화관리 이슈 및 지속적인 지원 서비스를 위한 헬프데스크 구축과 계약 이슈 등도 포함된다.
이 프로젝트는 제안 단계와 구현 단계 양쪽 모두에서 세계적 수준의 팀웍과 프로젝트 관리를 필요로 한다. 과거의 경험으로 볼 때, 애플리케이션 개발자들은 모든 구성요소를 한데 묶거나 전체 프로젝트를 관리할 수 있는 능력이 잇는 것 같아 보이지 않는다. IT 부서가 대체로 대형 프로젝트를 관리하는데 있어 어려움을 겪고 있다는 것은 널리 알려진 사실이 아닌가.
프로젝트 관리자는 PMO에서 와야만 하는가?
이런 상황에 처하면, CIO는 프로젝트 관리실(PMO)에서 ‘수퍼 프로젝트 매니저’를 지명하려 할지 모르겠다. 많은 IT 조직이 앞의 것과 같은 까다로운 프로젝트들을 위한 프로젝트 관리자로서 역할하는 프로젝트 관리 전문가들을 PMO에 갖고 있기 때문이다.
그런데 여기서 언어는 아주 중요하다. ‘프로젝트 관리자’라는 말은 프로젝트를 책임지고 전달해 주는 사람을 의미한다. 이번 경우, 그것은 새로운 애플리케이션이다. 이것을 비즈니스 언어로 번역해 보면, 의뢰인은 PMO에서 애플리케이션을 ‘구매’하는 것이며, PMO는 다시 여러 다른 관리자들(애플리케이션 엔지니어링, 웹 엔지니어링, 데이터베이스 관리 시스템 엔지니어링, 서버 엔지니어링 등)의 도움을 받아 그것을 전달해 줘야 한다.
다른 말로 하자면 PMO는 다른 그룹의 영역에 있는 제품(애플리케이션)을 의뢰인(돈이 오고가든 그렇지 않든 상관없이)에게 팔고 있는 것이다. 그리고 PMO는 다른 관리자들이 제품을 현업에 넘기는 책임을 대신 떠맡는다.
그러나 이런 방식은 책임소재를 불분명하게 만들며, 따라서 좋은 프로젝트 관리 방법과는 대치되는 것이다. 애플리케이션의 종단간(end-to-end) 전달에 대한 책임은 누가 질 것인가? 의뢰인은 누구에게 가서 무엇을 요구할 것인지, 그리고 그 결과에 대한 책임은 누구에게 따질 것인지를 어떻게 알 수 있는가? 또 만약 PMO가 진짜 프로젝트 관리자라면, PMO에 속한 스탭들은 그들이 다른 그룹들에서 필요로 하게 될 것이 무엇인지, 어떤 개발 방법과 도구들을 사용할 것인지, 그 프로젝트 전반에 걸쳐 있는 디자인 결정들은 어떻게 내릴 것인지 등에 대해 의사결정을 할 수 있는 자격을 갖추고 있는가? 명심해야 할 것은, PMO 스탭들이 프로젝트 관리의 전문가들일지는 모르지만, 애플리케이션 엔지니어링의 전문가들은 아니란 사실이다. 따라서 그들은 기술적 결정을 내릴 만한 자격이 없다.
물론 PMO 스탭들은 다른 사람들로부터 충분한 정보를 입수한다는 점을 곧 지적할 것이다. 그리고 프로젝트 관리자는 프로젝트의 전달을 책임지며, 따라서 프로젝트 관리자가 프로젝트와 관련해 궁극적 결정권을 가지게 될 것이다. 하지만 이것은 그 권한을 휘두를 자격을 가장 잘 갖춘 사람에게 권한이 주어지는 그런 상황은 아니다.
여기에 애플리케이션 엔지니어링 관리자는 자신의 업무에 대해 완전하게 제어하지 못할 것이다. PMO가 가끔씩 지휘권을 가져가고 결과물의 전달을 책임을 맡게 될 때, 애플리케이션 개발 관리자가 진실로 권한을 위임받는다는 것은 힘든 일이 아닐 수 없다.
만약 당신이 애플리케이션 개발 관리자라면, 프로젝트 관리자가 어떻게 애플리케이션 개발 영역에 가장 큰 이익이 되는 방향으로 결정을 내릴 것이라고 확신할 수 있겠는가? PMO의 그 프로젝트 관리자는 손쉬운 방법을 택해 마감시한 안에 프로젝트를 완료함으로써 자신에 대한 신용만 높이려 하지 않을까? 그리고 아마도 그 프로젝트 관리자는 미래의 유지보수성, 지원성, 운영 효율성, 통합 등 이슈와 관련해서는 과도한 위험을 택하지 않으려 할지 모른다.
프로젝트 관리의 전문가들이 대형의 복잡한 프로젝트에서 정말 중요한 역할을 한다는 것은 틀림없는 사실이다. 하지만 PMO 스탭에게 ‘프로젝트 관리자’로서의 책임을 맡길 경우, 해결되는 문제만큼 새로운 문제가 나올 것이다.
시장에서 더 나은 방법 찾기
멋진 팀웍과 고품질의 프로젝트 관리를 위해서는 책임소재의 충돌이나 권한의 박탈 같은 사태가 벌어져서는 안된다.
“하지만 과거의 사례로 볼 때, IT 부서는 대형의 복잡한 프로젝트에서 어려움을 겪었다. 그 문제는 어떻게 해결할 것인가?”
근본적인 원인을 봐라. 대부분의 팀웍 문제는 그 팀에 필요한 기술이 무엇인지 모르기 때문에 발생하는 것이 아니다. 대부분의 애플리케이션 개발자는 프로젝트를 수행하기 위해 어떤 사람들에게서 어떤 도움을 받아야 하는지를 알고 있으며, 어떤 서비스와 하부 구성요소들을 구매할 필요가 있는지 정확히 파악하고 있다. 진짜 문제는 그런 도움을 얻기 위한 프로세스가 없다는 것이다. 또한 많은 감시 기능이나 프로세스가 없어도 다른 사람들이 하나의 프로젝트에서 각자가 맡은 부분을 정확하게 전달해 줄 것이라고 믿게 해 주는 원칙들이 확립되어 있지 않다는 것이다.
이와 비슷하게 프로젝트 관리의 문제 대부분은 프로젝트를 관리하는 기술의 부족 때문이 아니다. 문제는 한 사람에게 대형 프로젝트 팀의 활동들을 관리하고 제어하도록 요구하는 것에 있다. 자동차를 개발하는 것과 같은 아주 복잡한 프로젝트를 관리하는데 따른 도전과제들을 한번 생각해 봐라. 그런 복잡한 프로젝트의 모든 측면을 관리하는 일을 한 사람에게 의존한다면, 그 프로젝트는 위험에 빠질 것이다. 하지만 다행스럽게도 다른 방법이 있다.
프로젝트 관리를 여러 개의 뭉치로 나눔으로써 이 길고 긴 공급망 전체의 모든 개인이 매일 매시간 하는 일을 모두 제어할 수 있는 그런 수퍼-프로젝트 관리자의 필요성을 없애는 것이다. IT 부서에 이 방법을 적용하는 일은 아주 간단하다. 거기에는 단 3가지 규칙만 있다.
첫째, 모든 사람이 해당 현업부서를 위한 제품과 서비스 공급의 주 계약자이다. 어느 누구도 그들이 맡은 현업부서 밖으로 제품이나 서비스를 팔지 못한다.
둘째, 주 계약자가 가장 먼저 해야 하는 일은 필요한 하도급 계약자들을 확보하는 것이다. 그리고 그런 하도급 계약자들에게서 사람이 아니라 결과물의 전달에 대한 약속을 확실하게 받아낸다.
셋째, 모든 사람은 각자가 약속한 제품이나 서비스의 전달에 대해 책임을 진다.
모든 사람이 협력하는 방법
이제 원래의 문제로 돌아가 보자. 그 의뢰인은 애플리케이션을 구매하고자 한다. 따라서 그 복잡성에도 불구하고, 주 계약자는 애플리케이션 개발 그룹이 되어야 하는 것이 분명하다.
이제 주 계약자는 제안 단계 및 구현 단계 양쪽 모두에서 필요한 모든 구성요소를 위해 하도급 계약자들을 모집한다. 예를 들면, 데이터 공급을 위한 다른 애플리케이션 그룹들, 웹 전위처리 기능을 위한 웹 컨텐트 관리 시스템 그룹, 데이터 모델을 위한 데이터베이스 관리 시스템 엔지니어 그룹 등이다. 그리고 PMO의 프로젝트 관리자 전문가는 프로젝트 계획 서비스, 프로젝트 관리 조언, 프로젝트 데이터 관리 등과 관련된 하도급 계약자가 될 수 있다는 사실도 잊지 마라.
프로세스들을 정확하게 확립하면, IT 부서는 수퍼-프로젝트 관리자들에게 권한을 빼앗기지 않고도 탁월한 팀웍과 프로젝트 관리 능력을 보여줄 수 있다. 주 계약자 및 하도급 계약자란 이런 시장 논리에 기반한 프로세스들은, 단지 사람만이 아니라 결과물 전달에 대해서도 책임을 지는 하도급 계약자 시스템과 함께 이용될 때, 대형 프로젝트 관리 능력을 모든 사람의 능력으로 만들어준다.
------------------------------------------
딘 메이어는 미CIO지 웹사이트(www.cio.com)의 ‘Beneath the Buzz’ 칼럼을 쓰고 있다.
