관리자가 가져야 하는 태도
린다 A힐과 켄트 라인백의 저서 '보스의 탄생'에서는 관리자가 겪게 되는 모순적인 상황에 대해 말한다.
자신이 직접 하지 않은 일을 책임져야 한다
지시하지 않으면서 직원의 머리와 가슴까지 움직여야 한다
직원들에게 감독인 동시에 심판이 되어야 한다
다양한 구성원으로 응집력 있는 팀을 만들어야 한다
팀과 그 팀을 둘러싼 환경, 두 가지 모두 관리해야 한다
오늘과 함께 내일에도 초점을 맞춰야 한다
변화를 주도하면서 연속성을 유지해야 한다
더 큰 이득을 위해 손해를 감수해야 한다
하나하나 읽다보면 정말 기가 찬 상황이다. 모순된 상황이 하나만 있어도 힘든데, 무려 여덟가지의 모순점이라니… 보통 한시적으로 진행되는 프로젝트 환경에서 프로젝트 매니저가 겪게 되는 모순은 주로 1번과 2번에 집중되어 있다.
자신이 직접 하지 않은 일을 책임져야 한다
책임을 지는 것은 결과가 나왔을 때 필요한 태도이다. 결과가 잘 나오면 그것은 같이 프로젝트를 진행한 구성원들이 잘했기 때문이다. 프로젝트 매니저가 아무리 관리를 하더라도 실제 업무 담당자들이 일을 제대로 하지 않으면 프로젝트는 결코 성공할 수 없다. 대부분의 사람들은 이 말에 동의할 수 있지만, 프로젝트가 실패했을 때 실패가 프로젝트 매니저의 책임이라는 것을 인정하는 것은 쉽지 않다. 성공을 위해서는 업무 담당자들의 노력이 필요했듯이, 실패를 한 것도 실제로 일을 하는 업무 담당자들이 일을 잘못했기 때문이라는 생각이 들기 때문이다. 프로젝트 매니저가 실제로 무엇인가를 하지도 않았는데, 실패에 대해 책임을 진다는 것이 석연치 않은 것이다. 실패에 대한 책임을 지는 것은 모든 매니저가 겪는 일이다. 스포츠 팀의 매니저 역시 팀의 성적이 나오지 않으면 경질을 당한다. 그런데 우리 사회는 매니저가 실패에 대해 책임을 진다는 개념이 전무하다시피 하다. 우리나라에서 매니저는 일이 잘못되면 자신은 빠져 나오고 아랫사람의 탓으로 돌리는 경우가 많다.
퍼거슨 이후 맨유 감독들에게 애도를...그렇다면 왜 매니저는 실패에 대해 책임을 져야 할까? 많은 매니저들이 이에 대해 납득할 수 있다면, 실패에 책임을 지는 매니저가 조금 더 많아지지 않을까? 권한과 책임은 항상 같이 다닌다. 매니저가 실패에 대한 책임을 져야 하는 이유는, 책임을 담보로 권한을 위임 받았기 때문이다. 최근 직장에서 수평적인 문화가 강조되고 있다. 또한 예전 같은 강한 프로젝트화(projectized)가 되는 상황이 아닌 매트릭스에 가까운 프로젝트 환경이 일반적이다. 이런 상황에서는 프로젝트 매니저의 권한이 꽤나 제한적이다. 프로젝트원들을 평가할 수 있는 권한도 없고, 그들에게 영향을 미칠 수 있는 결재권한도 가지고 있지 않다.
그럼에도 불구하고 프로젝트 매니저는 프로젝트를 수행하면서 권한을 부여 받는다. 프로젝트 매니저는 정보를 획득함으로써 권한을 얻게 된다. 프로젝트 매니저는 프로젝트 보고를 위해 높은 위치의 이해관계자를 만난다. 자원의 확보 및 업무 현황을 논의하기 위해 기능관리자(functional manager) 역시 만나게 된다. 의사소통이 주된 역할인 프로젝트 매니저는 주요한 의사소통 통로를 장악하는 위치이기 때문에 많은 정보를 획득할 수 밖에 없다. 프로젝트 매니저가 가지고 있는 다양한 정보와 상위 이해관계자와 소통할 수 있는 기회 자체가 프로젝트 매니저의 힘이자 권한이다.
다음으로 프로젝트 관리자는 일정을 관리함으로써 권한을 얻는다. 프로젝트 전체의 일정을 관리하는 것은 프로젝트 구성원들의 시간을 임의로 사용한다는 뜻이다. 물론 세부적인 일정은 프로젝트원들과 협의를 해서 정해야 하고, 개인의 일정이 충돌을 일으키는 상황이면 충돌을 해결해야 한다. 그럼에도 불구하고 일정을 정하는 주도권이 프로젝트 매니저에게 있다는 점은 그 자체로 큰 권한이다.
마지막으로 프로젝트 관리자는 업무를 할당하고 체크함으로써 권한을 가진다. 수평적인 조직에서의 프로젝트 매니저라면 업무를 막무가내로 지시하지는 않을 것이다. 왜 그 업무가 필요한지를 서로 간에 합의하고, 업무를 부탁하는 식으로 처리를 할 것이다. 협조의 형태로 업무가 할당 되겠지만, 프로젝트 매니저가 단위 업무를 식별하고, 담당자에게 할당했다는 사실은 변하지 않는다. 업무를 할당하고, 진행상태를 모니터링 하는 자체가 곧 권한이다.
프로젝트 매니저는 프로젝트의 성패를 책임져야 하기 때문에 이렇게 많은 권한을 부여 받는 것이다. 따라서 프로젝트가 실패했을 때 자신이 책임지는 것을 억울하게 생각해서는 안된다. 진심으로 자신이 책임 지겠다는 생각을 하지 않겠다면, 애초에 매니저라는 직책은 맡지 않는 것이 옳다.
지시하지 않으면서 직원의 머리와 가슴까지 움직여야 한다
책임을 지는 것이 결과에 대한 문제라면, 지시하지 않으면서 직원의 머리와 가슴까지 움직여야 한다는 것은 실행(execution)의 문제이다. 직접 단위 업무를 수행하지 않으면서, 어떻게 하면 프로젝트를 성공적으로 이끌 수 있을까? 나는 머리와 가슴까지 움직여야 한다는 점에 주목한다. 머리를 움직이게 하려면, 합리적인 논의를 통해 업무의 당위성을 설득해 낼 수 있어야 한다. 가슴을 움직이게 하려면 구성원의 자율성을 최대한 인정해 주어야 한다.
프로젝트 매니저는 안개 속에 있는듯한 프로젝트를 조금씩 명확하게(tangible) 만들어 갈 수 있어야 한다. 그러려면 전체 목표를 바라보면서도 업무를 씹어먹을 수 있는(bitable) 단위로 쪼개고, 각 업무 간의 의존성과 우선순위, 그리고 진행순서를 결정할 수 있어야 한다. 합리적이고 논리적으로 설정된 프로젝트 계획은 구성원들의 동의를 이끌어 내어, 그들이 업무를 수행할 때 혼란스럽지 않은 상태로 진행할 수 있도록 돕는다.
자율성을 인정해 주는 것도 쉽지는 않다. 상호 간에 합의한 마감일이 있었음에도 마감일 며칠 전에 업무의 진행 상황을 물어보면 자신의 자율성을 침해 당했다는 생각에 날카로운 반응을 보이는 경우가 종종 있다. 반면 마감일이 되어서야 확인을 하면, 사전에 아무런 고지도 없이 그제서야 일정을 지키지 못하겠다고 말하는 경우도 빈번하다. 이런 딜레마 속에서 내가 사용하는 방법은 ‘죄수의 딜레마’를 가장 효과적으로 해결했다고 여겨지는 ‘티포탯’ 전략이다. — <전략의 탄생, 애비너시 딕시트, 배리 네일버프 저> 이 전략은 처음에는 협력을 가정하고, 상대의 행동에 따라 계속해서 협력할지 배신할지 결정을 하는 방식이다. 나는 프로젝트 일정 체크를 할 때 처음에는 마감일이 될 때까지 아무런 말도 하지 않는다. 서로가 한 약속을 지킬 것이라 믿고 자율성을 보장해 주는 것이다. 그러나 업무 담당자가 몇차례 마감일을 지키지 못하는 상황이 발생하면, 마감일이 얼마 남지 않은 시점에서 업무의 완료 여부를 지속적으로 체크한다. 이상적인 경우는 완료일에 대한 약속이 지속적으로 지켜지면서 프로젝트 매니저와 업무 담당자 간의 신뢰가 쌓이는 것이다. 계속해서 업무 담당자의 자율성이 지켜지는 환경이 보장되면 업무 담당자는 가슴이 움직인 상태(engagement)에서 일을 하게 될 것이다.
내가 경험한 가장 효과적인 방법
내가 프로젝트를 관리하면서 가장 효과적이라 느꼈던 방법이 있다. 효과적이라 판단했던 근거는 내가 이 방법을 지속적으로 사용하면 할 수록 각 업무 담당자들의 굳은 표정이 조금씩 밝아졌고, 맡은 업무에 대해 좀 더 꼼꼼히 처리하는 모습이 보였으며, 프로젝트의 전체 분위기가 좋아졌기 때문이다. 물론 이런 상황이 지속된다면 프로젝트의 성공 확률도 올라간다.
먼저 프로젝트에 관심을 가져야 한다. 프로젝트 매니저로서 프로젝트에 관심을 갖는다는 것은 끊임없이 일정을 챙기는 것에 한정되는 것은 아니다. 최대한 많은 프로젝트 구성원들과 최대한 자주 대화를 해야 한다. 그 대화 속에서 내가 원하는 결과 뿐 아니라 그들이 업무를 진행하는 과정과, 업무를 진행하며 하는 생각 자체에 관심을 가져야 한다. 그 과정 속에서 그들이 진정 힘들게 생각하는 것이 무엇인지 찾을 수 있으며, 그 방해물(impediment)을 제거해 주는 것이 프로젝트 매니저의 역할 중 하나이다.
다음은 프로젝트 매니저 스스로가 가지는 업무에 대한 태도이다. 회의를 참석할 때나, 문서를 작성할 때 프로젝트 매니저가 프로젝트에 보이는 태도는 프로젝트 구성원들에게 그대로 전파된다. 프로젝트 매니저가 업무에 대한 열정과 성실함을 보이는 것이 백마디의 말보다 훨씬 효과적이다.
프로젝트 매니저는 프로젝트 전체를 이끌어 가고, 프로젝트 구성원들에게 영향을 미친다는 점에서 아주 매력적인 직무이다. 우리나라의 기업 문화에서는 많은 개발자들이 연차가 올라가면서 프로젝트 매니저의 역할을 자연스럽게 수행하게 된다. 하지만 선임 개발자와 프로젝트 매니저가 하는 업무의 성격은 완전히 다르며, 관리를 위해서는 많은 고민과 학습이 필요하다는 점을 받아들여야 할 것이다. 모순점이 가득한 관리업무지만, 관리 업무 내에서 즐거움과 보람을 느끼는 매니저들이 더욱 많아졌으면 하는 바람이다.
