PM이라는 직무는 정말 쉽지 않다. 프로젝트는 회사의 꽃이라 불릴만큼 회사의 목표를 달성하는데 필수적인 요소이다. 그 중 프로젝트 매니저는 프로젝트의 성공을 위해서 반드시 필요하다. 이런 배경에도 불구하고 문화적인, 또는 인간 본성에 따른 이유로 사내에서 PM의 가치를 제대로 인정받는 것은 쉽지 않은 일이다.

사업의 성과는 비즈니스 조직이 가져가며, 프로젝트를 수행한 PM은 용병처럼 사라진다. 반면 PM이 비즈니스 조직에 속하는 순간, 도메인 전문성은 높아지겠지만 PM이 수행하는 통합의 가치는 떨어질 수 밖에 없다.

PM의 역량과 성과를 계속해서 증명해내라는 요구가 빗발친다. PM의 역량은 매우 정성적으로 평가된다. 업무의 90% 이상이 커뮤니케이션이다. 커뮤니케이션은 효과적&효율적이어야 한다는 내용의 관점도 있지만, 정보를 공유하거나 이슈를 해결하는 것에 있어 속도감이 있어야 한다는 즉시성과 적시성이 더욱 중요하다. 적절한 커뮤니케이션을 통한 통합의 역량이 프로젝트를 성공시킨다.

PM이 자신의 기여를 정량화 할 수 있는 방법이 있을까? 가능하다. 자신이 커뮤니케이션 하는 사람들의 수를 모두 측정하고, 그들과의 커뮤니케이션 빈도와 응답하는 딜레이를 측정하면 된다. 이것은 PM이 커뮤니케이션 병목이 되지 않고, 정보의 흐름을 촉진시켰음을 증명한다. 그리고 이슈가 발생한 후 얼마나 잦은 주기로 트래킹 했는지와 해결까지 얼만큼 시간이 걸렸는지 측정할 수 있다. 이것은 프로젝트의 블로커를 얼마나 잘 해결했는지를 보여준다.

그럼에도 불구하고 나는 PM이 이런 자료를 만들어 스스로를 방어하는 상황은 이미 틀린 상황이라고 생각한다. 인간의 능력은 유한하고, 저런 자료를 작성해야 한다면, 프로젝트 수행에 집중할 수가 없을 것이다. 역설적으로 프로젝트의 성공확률은 급격히 떨어지게 된다.

내가 생각하는 PM의 역설이 여기에서 온다. PM의 성공조건은 프로젝트의 성공에서 오지만, 고용주 또는 상위 의사 결정자가 원하는 ‘증거’를 만들기 위해서는 프로젝트를 성공시킬 수가 없다는 것이다. 프로젝트 매니저의 성공은 프로젝트의 성공적 완료 하나로 평가 받아야 한다. 물론 프로젝트의 성공에는 이해관계자들의 만족도가 포함되어야 하며, 그들과 지속적으로 긍정적인 관계를 유지해야 함도 당연한 일이다.

다시 한 번 강조하지만 PM은 프로젝트의 성공으로만 평가받아야 한다. 예를 들어 축구감독이 경기를 승리하여 팀을 우승 시킨 상황에서, 구단주가 감독에게 당신이 무엇을 해서 경기를 이겼는지 증명하라는 질문을 한다면 얼마나 황당한 일인가? 그런데 기업환경에서는 이런 일들이 비일비재하게 발생한다. 나의 승리를 무엇으로 증명해야 할까? 아니, 왜 내가 그걸 증명해야 할까?

또 다른 문제는 조직도 상에서 PM과 실무자가 종종 동일한 기준으로 평가 받고 있다는 것이다. 이것 역시도 축구로 비유하자면, 골을 집어넣은 공격수를 데려와서, 감독에게 당신은 골을 얼마나 넣었는지를 묻는 꼴이다. 기업은 매니저에 대한 이해가 없다. 아니다. 사실은 이해가 있다. 그렇기에 매니저에게 더 높은 연봉을 기꺼이 주는 것이다. 그런데 고용 후에는 매니저의 가치를 평가절하 한다.

나는 나의 프로젝트 관리 역량과 문제 해결 역량으로 일을 성공시키기를 원한다. 그 자체가 내 역량에 대한 증명이라 생각한다. 그러나 그에 대해 일일이 증명하거나 방어해야 한다면, 굳이 그런 업무를 할 생각은 없다. 프로젝트가 평온하게 흘러가면 그들은 내 역량에 대한 증거를 요구할 것이고, 프로젝트가 다 망가지면 어디에 뛰어난 PM이 있는지 찾아헤매는 멍청한 일을 반복하게 될 것이다.

이건 인간 본연의 모습일테고, 난 이걸 바꿀 자신도, 상황을 견딜 자신도 없다.

p.s 내 블로그가 구글에 꽤 잘 검색되는 만큼, 어떤 상위관리자가 PM의 평가 방법에 대해 검색을 하다가 이 글을 보게 될 수도 있을 것이다. 부디 뛰어난 PM을 괴롭히지 말기를 바란다. 그가 프로젝트를 계속해서 성공하고 있다면, 그를 소중히 여겨라. 그에게 무언가를 계속 증명하기를 요구하는 행위는 황금알을 낳는 거위의 배를 가르는 멍청한 짓이다.

프로젝트에 대한 더 많은 내용을 보고 싶다면 – Link

린다 A힐과 켄트 라인백의 저서 ‘보스의 탄생’에서는 관리자가 겪게 되는 모순적인 상황에 대해 말한다.

• 자신이 직접 하지 않은 일을 책임져야 한다
• 지시하지 않으면서 직원의 머리와 가슴까지 움직여야 한다
• 직원들에게 감독인 동시에 심판이 되어야 한다
• 다양한 구성원으로 응집력 있는 팀을 만들어야 한다
• 팀과 그 팀을 둘러싼 환경, 두 가지 모두 관리해야 한다
• 오늘과 함께 내일에도 초점을 맞춰야 한다
• 변화를 주도하면서 연속성을 유지해야 한다
• 더 큰 이득을 위해 손해를 감수해야 한다

하나하나 읽다보면 정말 기가 찬 상황이다. 모순된 상황이 하나만 있어도 힘든데, 무려 여덟가지의 모순점이라니… 보통 한시적으로 진행되는 프로젝트 환경에서 프로젝트 매니저가 겪게 되는 모순은 주로 1번과 2번에 집중되어 있다.

자신이 직접 하지 않은 일을 책임져야 한다

책임을 지는 것은 결과가 나왔을 때 필요한 태도이다. 결과가 잘 나오면 그것은 같이 프로젝트를 진행한 구성원들이 잘했기 때문이다. 프로젝트 매니저가 아무리 관리를 하더라도 실제 업무 담당자들이 일을 제대로 하지 않으면 프로젝트는 결코 성공할 수 없다. 대부분의 사람들은 이 말에 동의할 수 있지만, 프로젝트가 실패했을 때 실패가 프로젝트 매니저의 책임이라는 것을 인정하는 것은 쉽지 않다. 성공을 위해서는 업무 담당자들의 노력이 필요했듯이, 실패를 한 것도 실제로 일을 하는 업무 담당자들이 일을 잘못했기 때문이라는 생각이 들기 때문이다. 프로젝트 매니저가 실제로 무엇인가를 하지도 않았는데, 실패에 대해 책임을 진다는 것이 석연치 않은 것이다. 실패에 대한 책임을 지는 것은 모든 매니저가 겪는 일이다. 스포츠 팀의 매니저 역시 팀의 성적이 나오지 않으면 경질을 당한다. 그런데 우리 사회는 매니저가 실패에 대해 책임을 진다는 개념이 전무하다시피 하다. 우리나라에서 매니저는 일이 잘못되면 자신은 빠져 나오고 아랫사람의 탓으로 돌리는 경우가 많다.

퍼거슨 이후 맨유 감독들에게 애도를…

그렇다면 왜 매니저는 실패에 대해 책임을 져야 할까? 많은 매니저들이 이에 대해 납득할 수 있다면, 실패에 책임을 지는 매니저가 조금 더 많아지지 않을까? 권한과 책임은 항상 같이 다닌다. 매니저가 실패에 대한 책임을 져야 하는 이유는, 책임을 담보로 권한을 위임 받았기 때문이다. 최근 직장에서 수평적인 문화가 강조되고 있다. 또한 예전 같은 강한 프로젝트화(projectized)가 되는 상황이 아닌 매트릭스에 가까운 프로젝트 환경이 일반적이다. 이런 상황에서는 프로젝트 매니저의 권한이 꽤나 제한적이다. 프로젝트원들을 평가할 수 있는 권한도 없고, 그들에게 영향을 미칠 수 있는 결재권한도 가지고 있지 않다.

그럼에도 불구하고 프로젝트 매니저는 프로젝트를 수행하면서 권한을 부여 받는다. 프로젝트 매니저는 정보를 획득함으로써 권한을 얻게 된다. 프로젝트 매니저는 프로젝트 보고를 위해 높은 위치의 이해관계자를 만난다. 자원의 확보 및 업무 현황을 논의하기 위해 기능관리자(functional manager) 역시 만나게 된다. 의사소통이 주된 역할인 프로젝트 매니저는 주요한 의사소통 통로를 장악하는 위치이기 때문에 많은 정보를 획득할 수 밖에 없다. 프로젝트 매니저가 가지고 있는 다양한 정보와 상위 이해관계자와 소통할 수 있는 기회 자체가 프로젝트 매니저의 힘이자 권한이다.

다음으로 프로젝트 관리자는 일정을 관리함으로써 권한을 얻는다. 프로젝트 전체의 일정을 관리하는 것은 프로젝트 구성원들의 시간을 임의로 사용한다는 뜻이다. 물론 세부적인 일정은 프로젝트원들과 협의를 해서 정해야 하고, 개인의 일정이 충돌을 일으키는 상황이면 충돌을 해결해야 한다. 그럼에도 불구하고 일정을 정하는 주도권이 프로젝트 매니저에게 있다는 점은 그 자체로 큰 권한이다.

마지막으로 프로젝트 관리자는 업무를 할당하고 체크함으로써 권한을 가진다. 수평적인 조직에서의 프로젝트 매니저라면 업무를 막무가내로 지시하지는 않을 것이다. 왜 그 업무가 필요한지를 서로 간에 합의하고, 업무를 부탁하는 식으로 처리를 할 것이다. 협조의 형태로 업무가 할당 되겠지만, 프로젝트 매니저가 단위 업무를 식별하고, 담당자에게 할당했다는 사실은 변하지 않는다. 업무를 할당하고, 진행상태를 모니터링 하는 자체가 곧 권한이다.

프로젝트 매니저는 프로젝트의 성패를 책임져야 하기 때문에 이렇게 많은 권한을 부여 받는 것이다. 따라서 프로젝트가 실패했을 때 자신이 책임지는 것을 억울하게 생각해서는 안된다. 진심으로 자신이 책임 지겠다는 생각을 하지 않겠다면, 애초에 매니저라는 직책은 맡지 않는 것이 옳다.

지시하지 않으면서 직원의 머리와 가슴까지 움직여야 한다

책임을 지는 것이 결과에 대한 문제라면, 지시하지 않으면서 직원의 머리와 가슴까지 움직여야 한다는 것은 실행(execution)의 문제이다. 직접 단위 업무를 수행하지 않으면서, 어떻게 하면 프로젝트를 성공적으로 이끌 수 있을까? 나는 머리와 가슴까지 움직여야 한다는 점에 주목한다. 머리를 움직이게 하려면, 합리적인 논의를 통해 업무의 당위성을 설득해 낼 수 있어야 한다. 가슴을 움직이게 하려면 구성원의 자율성을 최대한 인정해 주어야 한다.

프로젝트 매니저는 안개 속에 있는듯한 프로젝트를 조금씩 명확하게(tangible) 만들어 갈 수 있어야 한다. 그러려면 전체 목표를 바라보면서도 업무를 씹어먹을 수 있는(bitable) 단위로 쪼개고, 각 업무 간의 의존성과 우선순위, 그리고 진행순서를 결정할 수 있어야 한다. 합리적이고 논리적으로 설정된 프로젝트 계획은 구성원들의 동의를 이끌어 내어, 그들이 업무를 수행할 때 혼란스럽지 않은 상태로 진행할 수 있도록 돕는다.

자율성을 인정해 주는 것도 쉽지는 않다. 상호 간에 합의한 마감일이 있었음에도 마감일 며칠 전에 업무의 진행 상황을 물어보면 자신의 자율성을 침해 당했다는 생각에 날카로운 반응을 보이는 경우가 종종 있다. 반면 마감일이 되어서야 확인을 하면, 사전에 아무런 고지도 없이 그제서야 일정을 지키지 못하겠다고 말하는 경우도 빈번하다. 이런 딜레마 속에서 내가 사용하는 방법은 ‘죄수의 딜레마’를 가장 효과적으로 해결했다고 여겨지는 ‘티포탯’ 전략이다. — <전략의 탄생, 애비너시 딕시트, 배리 네일버프 저> 이 전략은 처음에는 협력을 가정하고, 상대의 행동에 따라 계속해서 협력할지 배신할지 결정을 하는 방식이다. 나는 프로젝트 일정 체크를 할 때 처음에는 마감일이 될 때까지 아무런 말도 하지 않는다. 서로가 한 약속을 지킬 것이라 믿고 자율성을 보장해 주는 것이다. 그러나 업무 담당자가 몇차례 마감일을 지키지 못하는 상황이 발생하면, 마감일이 얼마 남지 않은 시점에서 업무의 완료 여부를 지속적으로 체크한다. 이상적인 경우는 완료일에 대한 약속이 지속적으로 지켜지면서 프로젝트 매니저와 업무 담당자 간의 신뢰가 쌓이는 것이다. 계속해서 업무 담당자의 자율성이 지켜지는 환경이 보장되면 업무 담당자는 가슴이 움직인 상태(engagement)에서 일을 하게 될 것이다.

내가 경험한 가장 효과적인 방법

내가 프로젝트를 관리하면서 가장 효과적이라 느꼈던 방법이 있다. 효과적이라 판단했던 근거는 내가 이 방법을 지속적으로 사용하면 할 수록 각 업무 담당자들의 굳은 표정이 조금씩 밝아졌고, 맡은 업무에 대해 좀 더 꼼꼼히 처리하는 모습이 보였으며, 프로젝트의 전체 분위기가 좋아졌기 때문이다. 물론 이런 상황이 지속된다면 프로젝트의 성공 확률도 올라간다.

먼저 프로젝트에 관심을 가져야 한다. 프로젝트 매니저로서 프로젝트에 관심을 갖는다는 것은 끊임없이 일정을 챙기는 것에 한정되는 것은 아니다. 최대한 많은 프로젝트 구성원들과 최대한 자주 대화를 해야 한다. 그 대화 속에서 내가 원하는 결과 뿐 아니라 그들이 업무를 진행하는 과정과, 업무를 진행하며 하는 생각 자체에 관심을 가져야 한다. 그 과정 속에서 그들이 진정 힘들게 생각하는 것이 무엇인지 찾을 수 있으며, 그 방해물(impediment)을 제거해 주는 것이 프로젝트 매니저의 역할 중 하나이다.

다음은 프로젝트 매니저 스스로가 가지는 업무에 대한 태도이다. 회의를 참석할 때나, 문서를 작성할 때 프로젝트 매니저가 프로젝트에 보이는 태도는 프로젝트 구성원들에게 그대로 전파된다. 프로젝트 매니저가 업무에 대한 열정과 성실함을 보이는 것이 백마디의 말보다 훨씬 효과적이다.

프로젝트 매니저는 프로젝트 전체를 이끌어 가고, 프로젝트 구성원들에게 영향을 미친다는 점에서 아주 매력적인 직무이다. 우리나라의 기업 문화에서는 많은 개발자들이 연차가 올라가면서 프로젝트 매니저의 역할을 자연스럽게 수행하게 된다. 하지만 선임 개발자와 프로젝트 매니저가 하는 업무의 성격은 완전히 다르며, 관리를 위해서는 많은 고민과 학습이 필요하다는 점을 받아들여야 할 것이다. 모순점이 가득한 관리업무지만, 관리 업무 내에서 즐거움과 보람을 느끼는 매니저들이 더욱 많아졌으면 하는 바람이다.