나는 PM(Project Manager)이다 - 8. 시작은 시작이지 반이 아니다.

나는 어릴 적에 차를 타면 늘 멀미를 했다. 머리가 아프다가 속이 메스꺼워지면서 구토를 하고 두통과 함께 몸에 힘이 빠지면서 축 늘어졌다. 그래서 차를 타는 것 자체가 두려웠었다. 도대체 왜 멀쩡했던 컨디션이 차만 타면 멀미로 엉망이 되는걸까 궁금했지만 아무도 알려 주지 않았다. 

 

그런데 친구 한 녀석이 멀미는 냄새 때문에 난다는 주장을 들고 나왔다. 말인 즉슨 자기도 버스를 타고 다닐 때는 멀미가 났었는데 아버지가 자가용을 사고 나서는 멀미가 나지 않는다. 그래서 차이가 뭘까 생각해 봤더니 아빠 차에서는 버스에서 나던 기름 냄새가 나지 않는다는 것이었다. 그 당시 동네에서 자가용을 가진 집은 그 친구가 유일했기 때문에 옳다 그르다를 논하기 보다는 자가용 있는 친구 녀석이 부러웠었다. 

 얼마 지나지 않아 아버지가 자가용을 사고 나서 나 또한 멀미가 나지 않았기 때문에 정말 냄새가 멀미의 원인이라고 생각하기도 했다. 물론 멀미가 냄새 때문에 나는 것은 아니다. 차를 타고 가면서 우리 몸이 움직이는 정보를 처리함에 있어 시신경을 통해 들어오는 정보와 귓속 반고리관의 정보가 일치 하지 않은 정보의 혼란 때문에 생긴다. 즉 우리의 몸은 자신이 느끼는 정보와 실제 정보 사이의 괴리가 생기는 것 만으로도 엄청난 스트레스를 받는 것이다.

 프로젝트는 이런 정보의 괴리가 생길 수 있는 여지가 많다. 같은 상황과 정보를 놓고도 다양한 이해관계자들이 다양한 해석으로 접근 하기 때문이다. 프로젝트를 책임지는 프로젝트 매니저는 프로젝트를 시작할 때 자신과 함께 프로젝트를 수행할 프로젝트 팀이 다양한 정보로 인해 프로젝트에 대해 멀미를 일으키지 않게 조치를 취해야 한다. 물론 귀밑에 동그란 패치를 붙이는 것으로는 막을 수 없다. 그러면 어떻게 해야 할까

프로젝트를 위해 경쟁입찰에 참여해서 프로젝트를 수주하게 되면 바로 계약 되는 것이 아니라 우선협상대상자로 선정이 되게 된다. 경쟁입찰에 참여한 업체들 중에 계약에 대해 우선권을 얻게 된다는 의미인데 바로 계약이 이루어 지지 않는 것은 실제 계약에 들어가기 위해 세부적인 조정이 이루어지기 때문이다. 계약 금액에서 부 터 세부적인 기술적인 요구사항 들을 조율한다. 이때 프로젝트 관리자는 우선협상대상자로 참여도 해야겠지만 같이 프로젝트를 진행할 팀을 위해 팀빌딩을 본격적으로 진행 하면서 프로젝트에 대한 정보를 전달해야 한다.

그렇다면 팀빌딩시 프로젝트에 대한 어떤 정보를 전달해야 할까?

가장 기본적인 것은 프로젝트에 대한 객관적인 사실을 전달 하는 것이다. 프로젝트 일정과 투입될 인원, 투입시기, 고객의 상황과 현재 파악된 요구사항, 구현해야 할 기능 등의 정보를 가감 없이 전달하고 예상되는 리스크와 이미 식별된 이슈에 대해서 최대한 객관적인 정보를 팀원들과 공유함으로써 프로젝트에 투입되기 전에 마음의 준비를 할 수 있게 도와 준다.

 기본적인 정보를 전달하다 보면 팀원들이 프로젝트에 대한 잘못된 정보를 가진 경우를 의외로 많이 보게 된다. 프로젝트가 시작되려고 하면 회사 내에선 이런 저런 이야기가 떠돈다. 이번 프로젝트는 줄줄이 철야가 계속되게 빡셀것이라느니 고객이 소문난 진상이라 프로젝트가 산으로 갈 거라느니 하는 걱정들이거나 혹은 그 반대로 이번 프로젝트는 별로 할게 없다더라 하는 경우도 있다. 정보는 사람의 입과 입을 거쳐 사실과 다르게 부풀려 지거나 편집되기 쉽기 때문이다.

 따라서 투입될 인원들에게 프로젝트 상황에 대한 정확한 정보를 공유하는 이 과정이 꼭 필요하다. 팀원들이 필요 이상으로 프로젝트를 겁낼 경우도 너무 만만하게 보는 경우도 프로젝트에 도움이 되지 않기 때문이다.

 

객관적인 정보 전달후에는 PM으로써 이번 프로젝트를 돌파 하기 위한 방법을 제시한다.

 객관적인 정보를 전달 하는 것만으로 리더의 역할이 끝나지는 않는다. PM이 프로젝트 팀을 리딩 하기 위해서는 모두가 수긍할 수 있는 목표와 방법을 제시 할 수 있어야 한다. 다시 말하자면 프로젝트의 객관적인 정보를 바탕으로 프로젝트에서 예상되는 이슈와 리스크를 해쳐나갈 방법을 제시해야 한다는 것이다.

 예를 들면 까다롭고 추가 요구사항이 많기로 소문난 고객사의 프로젝트를 수주했다고 하자. 이 고객사의 요구사항을 어떻게 관리할 것인가는 여러 가지 방법이 있을 수 있다. 프로젝트에 투입인력을 계획보다 적게 잡고 이슈를 만들고 협의를 통해 투입인력을 조율하는 것으로 고객을 압박해서 요구사항을 관리할 수도 있다. 전체 개발할 내용을 분석/설계 단계에서 최대한 상세히 도출하여 하루 단위로 개발할 양을 산정해서 제시함으로써 개발 가능한 업무량에 대해 고객의 동의를 이끌어 낼 수도 있다. 어떤 방법이 되었건 PM으로써 자신이 맡은 프로젝트를 성공적으로 이끌어 나갈 나름의 청사진이 있어야 하고 이 청사진을 팀원들과 공유하고 공감을 이끌어 낼 수 있어야 한다.

 이렇게 이야기 하면 일부 PM들은 자신이 계획한다고 그렇게 될지도 장담하기 힘들고 계획을 세운다 한들 팀원들을 설득하기도 너무 어렵다고 난색을 표하기도 한다.

 하지만 프로젝트라는 예외상황으로 가득찬 일정 속에서 프로젝트를 해결하기 위한 개별 프로젝트별 맞춤 돌파방법을 만들고 그 방법을 팀원들에게 설득하는 과정은 팀원들이 PM을 신뢰할 수 있게 만들고, 프로젝트에 좀 더 적극적으로 참여하며, 팀이라는 일체감을 만드는 최상의 툴이라는 것이 내가 오랜 PM생활의 경험으로 체득한 결론이다.

 그저 위에서 시키니까 프로젝트를 맡았고 프로젝트 수행 하라니까 수행 하는 PM과 자신이 투입될 프로젝트에 대해 한번 더 고민하고 나름대로의 경험을 바탕으로 정확한 정보를 통한 분석으로 해결책을 제시하는 PM과는 프로젝트 수행에 있어서 당연히 차이가 발생한다.