프로젝트 관리는 ‘주어진 프로젝트를 성공적으로 끝내기 위해 프로젝트 관리자(PM)가 수행하는 활동’으로 요약할 수 있습니다.
프로젝트 관리자의 역할은 업종과 조직에 따라 다르지만 프로젝트 관리가 중요할수록 프로젝트 관리자가 챙길 일이 많아집니다. 업무가 새롭고, 기술적인 난도가 높고, 이해관계가 복잡하고, 규모가 클수록 프로젝트 관리가 어렵고 프로젝트 성과에 프로젝트 관리자가 미치는 영향이 큽니다. 예를 들어 대형 SI 프로젝트와 상품개선 프로젝트는 프로젝트 관리자의 영향력이 다릅니다.
위에서 설명한 프로젝트 유형에 따라 프로젝트 관리자의 역할이 달라지지만, 프로젝트 시작, 프로젝트 실행, 프로젝트 종료로 이어지는 프로젝트 단계에 따라서도 프로젝트 관리자의 역할이 달라집니다. 프로젝트 수행단계별 프로젝트 관리자의 역할을 제가 경험했던 상품개발 프로젝트, 회사내부 시스템개발 프로젝트, SI 프로젝트의 사례로 설명드리겠습니다.
– 시작: 프로젝트를 수동적으로 받기보다 프로젝트 정의에 능동적으로 참여해야 합니다.
프로젝트 관리자를 ‘주어진’ 프로젝트를 책임지고 끝내는 사람으로 정의했지만, 주어진다는 것의 의미에 유의해야 합니다. 주어진다고 하면 특정시점을 기준으로 다른 조직 또는 다른 사람으로부터 프로젝트 관리자에게 업무가 이관되는 것으로 생각하기 쉬운데 실제로는 계주에서 바통을 넘겨받는 것과 비슷합니다.
프로젝트 유형이나 조직의 상황에 따라 프로젝트 관리자가 프로젝트를 정의하는 활동에 깊이, 오랫동안 참여 할 수 있습니다. 일단 프로젝트 관리자가 바통을 넘겨받으면 운영 책임자에게 바통을 넘겨줄 때까지 프로젝트는 프로젝트 관리자의 책임입니다.
프로젝트 정의에서 중요한 것은 해결하고자 하는 문제(why)를 명확하게 하는 것입니다. 많은 경우 개략적인 해결방안(what)이나 납기(when)도 프로젝트 시작 전에 정의합니다.
상품개발 프로젝트에서는 상품관리자가 요구사항을 프로젝트 관리자에게 제공합니다. 규모가 작은 스타트업에서는 상품관리자가 프로젝트 관리자의 역할을 겸하기도 합니다. 회사내부 시스템개발 프로젝트에서는 스폰서가 프로세스 개선을 위한 시스템 개발을 프로젝트 관리자에게 요청합니다. 문제를 제기한 사람이 직접 프로젝트 관리자가 될 수도 있지만, 프로젝트를 승인하고 지원하는 스폰서는 존재합니다. SI프로젝트에서는 고객사의 스폰서가 제안요청서(RFP)를 작성하여 프로젝트를 발주합니다.
프로젝트 유형에 상관없이 프로젝트 관리자가 일찍부터 깊게 프로젝트 정의에 관여하는 것이 좋습니다. 그 과정을 통해 프로젝트가 추구하는 가치나 해결하고자 하는 문제에 대한 이해도가 깊어집니다. 뿐만 아니라 개발관점에서 이슈가 있는 내용은 사전에 반영할 수 있습니다. 그 결과 성공가능성이 높은 프로젝트 계획을 수립하게 됩니다. 덤으로 프로젝트 생성부터 관여하면 프로젝트에 대한 애정과 책임감도 커집니다.
– 관리: 무엇을 관리할지, 어떻게 관리할지 고민해야 합니다.
프로젝트 관리 활동은 ‘관리대상’과 ‘관리방법’으로 구분할 수 있습니다. 관리대상은 범위•일정•예산•품질•팀•이해관계자•의사소통•조달•위험과 같이 구분할 수 있고, 관리방법은 계획• 실행•통제로 구분할 수 있습니다.
프로젝트 관리활동은 그림 *와 같이 관리대상과 관리방법이 씨줄과 날줄처럼 만나는 곳에서 발생합니다. 예를 들어 범위계획, 범위검증, 범위통제가 범위관리를 위한 활동입니다. 모든 관리영역에 계획과 통제는 해당되지만 일정과 예산같이 실행이 해당되지 않는 관리활동이 있을 수 있습니다. 국제 프로젝트 관리표준인 PMBOK의 7판 이전의 구성체계가 이러한 프레임워크를 따랐습니다.
위의 그림과 같이 구성된 PMBOK의 프로젝트 관리 프로세스는 40여 개가 되는데 프로젝트 관리활동의 난이도 관점에서 다음과 같이 요약할 수 있습니다.
• 범위, 일정, 예산은 계획수립과 통제가 어렵습니다.
요구사항은 불확실하고 소통하는 과정에서 오해가 많이 발생하기 때문에 요구사항(범위)을 제대로 정의하기 어렵습니다. 불확실한 요구사항을 기반으로 예산과 일정을 추정하기 때문에 일정 및 예산 계획의 불확실성도 증가합니다. 뿐만 아니라 범위, 일정, 예산은 상호 영향을 주고받기 때문에 프로젝트 계획의 불확실성을 증폭시킵니다. 결론적으로 ‘이 일을, 이 일정으로, 이 예산으로 수행할 수 있을까?’의 질문에 확신을 가질 수 있는 계획을 수립하기 힘듭니다. 범위, 일정, 예산의 통제도 마찬가지입니다. 프로젝트를 진행하는 도중 차질이 발생하여 범위, 일정, 예산계획을 다시 수립하는 것이 통제의 본질입니다. 그런데 통제를 위한 재계획은 최초 계획수립보다 어렵습니다. 그 이유는 프로젝트 차질에는 프로젝트 팀의 잘못도 포함되기 때문에 재계획을 할 때 도전적인 계획수립에 대한 압박이 많기 때문입니다.
• 이해관계자, 팀, 의사소통 관리는 실행이 힘듭니다.
이해관계자, 팀, 의사소통은 사람들을 대상으로 프로젝트 관리자가 리더십을 발휘해야 하는 영역입니다. 프로젝트 팀원들을 대상으로는 동기부여를 제공해야 하고, 이해관계자가 프로젝트에 긍정적으로 참여하도록 유도해야 합니다. 그리고 이해관계자들이 원하는 정보를 파악하고 이를 제때 제공하는 의사소통도 쉽지 않습니다. 성인들은 이미 굳어진 각자의 가치관들이 있기 때문에 특정 조건만 충족되면 언제든지 부정적인 갈등이 표면화될 수 있고, 이는 프로젝트 생산성에 마이너스가 됩니다. 상이한 가치관을 가진 사람들을 이끌어 목표를 달성하게 하는 것은 정치만큼이나 어려운 작업입니다.
– 종료: 운영을 시작해야 프로젝트는 끝납니다.
프로젝트 관리자는 다른 사람에게 프로젝트를 정의한 문서(‘프로젝트 헌장’이라고 합니다.)를 받아 프로젝트를 착수했고, 프로젝트를 끝내면 프로젝트 관리자가 프로젝트 결과물을 운영책임자에게 이관해야 합니다. 프로젝트 종료에 대한 바통을 운영책임자가 받지 않으면 프로젝트 관리자가 계속 바통을 쥐고 있을 수밖에 없습니다. 바통을 땅에 내려놓고 누구의 책임도 아닌 경우는 예외적입니다. 마치 아파트를 완공했는데 특수한 상황으로 입주를 시작하지 못하는 것과 같습니다.
프로젝트는 끝내기 위해 시작합니다. 프로젝트를 시작할 때 프로젝트 관리자가 프로젝트를 정의한 사람과 협업했듯이 프로젝트를 끝낼 때도 프로젝트 관리자가 운영책임자에게 프로젝트 결과물에 대한 지식이전을 충분히 해야 부담 없이 운영을 시작할 수 있습니다. 운영을 시작해야 비로소 프로젝트는 진짜 종료합니다.
그러나 프로젝트를 빨리 끝내고 싶은 마음과 프로젝트의 문제점을 충분히 수정한 뒤에 운영하고 싶은 마음은 상충됩니다. 프로젝트 개발팀이 운영까지 담당하면 아무런 문제 없이 운영을 시작할 수 있지만, 운영인력과 프로젝트 팀이 다르다면 프로젝트 종료하기 이전에 일정기간 운영인력을 프로젝트에 참여시켜야 합니다.
지금까지 말씀드린 내용을 정리하면 아래 그림과 같습니다.
