세수를 마치고 거울로 얼굴을 보면, 가끔 작은 뾰루지를 발견할 때가 있다. 시간이 가면 자연스럽게 없어질 것을 알지만, 그날 기분에 따라서 거스를 때가 있다. 이 기분을 이기지 못하고 뾰루지를 건드리고 나면 잠시 개운하지만, 상처가 난 자리라 계속해서 손이 가게 된다. 운이 없을 때 짠 부위가 감염되어 부을 때도 있다. 붉게 올라온 뾰루지를 보고 있노라면, 한순간 자제하지 못한 내가 미울 때가 있다. 후회해야 상황은 이미 늦었고, 그렇게 커진 뾰루지는 곪고 터질 때까지 기다려야 한다.
프로젝트 관리자가 해야 할 일 중에서, 팀이 마주하거나 해결해야 할 문제를 정의하고, 해결책을 풀도록 인적 물적 자원을 동원하는 건 매우 중요하다. 이런 문제를 파악하기 위해서, 의사소통 계획, 위험 관리, 이슈 관리 등의 다양한 방법이나 기술을 사용한다. 그런데 이런 것들을 사용해서 문제를 정의하다 보면, 새삼 문제 정의의 중요성을 느낀다. 어떤 면에서 문제 정의의 중요성일까?
프로젝트라는 게 결국 사람이 하는 일이라, 팀에서 발생하거나 팀이 마주하는 문제 대부분은 사람과 관련된 것이다. 말하자면 팀원들의 문제도 있고, 고객과 팀원과의 문제도 있고, 프로젝트팀이 속한 회사와의 문제도 있다. 사람 사이에서 생기는 일이 그렇듯이, 프로젝트 이해당사자들이 제기하거나 암묵적으로 나타나는 문제 가운데, 딱히 해결책이 없는 게 참 많다. 말하자면 문제가 생기는 경우, 문제 스스로 답을 찾아 해결책이 생기는 경우가 흔하다. 마치 대다수 뾰루지가 시간이 지나면 그냥 사라지는 것처럼, 사람 사이의 문제도 그냥 해결될 때가 잦다.
대다수의 사람 사이의 문제가 그냥 해결된다면, 프로젝트 관리자로서 무책임한 PM을 옹호하는 것처럼 들릴 수도 있다. 이 글에서 말하고자 하는 바는 무책임하거나 무능력한 프로젝트 관리자를 옹호하기 위한 게 아니다. 내가 하고 싶은 이야기는 이런 것이다. 열성적인 프로젝트 관리자 혹은 자신이 어떤 중요한 역할을 하는지 팀원들에게 각인시켜 주고 싶은 관리자들이, 문제를 너무 쉽게 정의하거나 사람 간의 관계를 쉽게 정리하려는 경향이 있다는 점이다.
팀원들이 제기하는 많은 불만이나 문제는, 진짜 문제가 있는 경우도 있지만, 그냥 프로젝트를 수행하면서 겪는 불만이나 불평일 때가 많다. 그런 것들이 불만이나 불평으로 표출되다 보니, 프로젝트 관리자로서 그 불평과 불만을 문제로 정의해서 어떻게든지 제거하고 싶어 초조해진다. 그러다 보니 “네가 그렇게 생각해서 안 되지.” 혹은 “그렇게 부정적으로 생각하면 어떻게 하느냐?”는 등의 깔끔한 답을 내놓을 때가 많다. 결국, 불편 몇 마디로 풀리거나 관리자가 관심을 두고 듣는 자세로 해결된 일이, 팀원의 생각에 문제가 있는 것으로 정의되거나 프로젝트가 잘 안되는 것처럼 결론지어질 때가 흔하다.
물론 팀원들이 불만의 형식으로써 토로하는 것 중에 프로젝트를 위기에 빠트릴 중요한 문제들의 단서도 있다. 따라서 팀원들의 이야기에 적극 경청하는 자세가 필요하다. 불만이나 불평을 잘 듣고 잠재적인 위험요소를 찾아내어, 잠정적인 위험을 찾아내는 건 전형적인 위험 관리의 절차라 할 수 있다. 물론 이런 위험 관리 프로세스야 프로젝트 관리의 근본이고, 프로세스 필수다. 그런데 이런 활동이 잘 이뤄지려면, 프로젝트 관리자로서 다양한 불만들을 잘 듣고 섣불리 문제 정의를 하려는 시도를 참아 보는 게 중요하다. 모든 뾰루지를 짜야 하는 게 아니듯이 말이다.
