멀티프로젝트 관리하기
동시에 여러 개의 프로젝트를 진행할 때 생각해야 할 것들
PMBOK이나, 프로젝트 관리에 대한 서적을 아무리 찾아봐도 없는 내용 중의 하나가 멀티프로젝트를 관리하는 방법에 대한 것이다. 일단 여러 개의 프로젝트를 한 명의 PM이 맡아서 진행한다는 것 자체를 인정하지 않는 것 같다. 그러나, 솔루션 도입 및 커스터마이징 형태로 프로젝트를 진행하는 경우, 특히 우리나라의 중소/중견기업의 경우, 실제로는 멀티 프로젝트 관리를 요구받는 경우가 많다고 생각한다.
첫 번째, 동시에 진행하는 프로젝트의 개수를 제한할 필요가 있다.
솔루션 도입 + 커스터마이징 진행 필요한 프로젝트를 수행해야 한다면 대체로 3개가 넘어가면서부터 자잘한 문제가 발생하기 시작하는 것 같다. 정말 심할 때는 총 10개의 프로젝트를 동시에 맡아서 진행한 적이 있었는데, 한동안 어찌어찌 진행시켜나갈 수는 있었지만, 몸과 마음이 피폐해져 가는 상태에서 모든 프로젝트가 더디게 진행되고, 한 개 프로젝트에서 이슈가 발생할 경우 그 프로젝트에 집중하다 보면 나머지 프로젝트들이 연쇄적으로 망가져가는 것을 몸소 경험한 적이 있다.
회사를 사랑하는 마음으로, 또는 본인의 능력을 과신하여 인간의 머리로 처리 가능한 개수를 넘어서는 프로젝트를 멀티로 맡아 진행하는 것은 정말 피해야 한다. 그 이상의 프로젝트를 맡는 경우는 투입 MM가 0.1 이하인 경우나 되어야 가능할 것 같다. 즉, 설치 1일, 테스트/교육 1일로 끝낼 수 있는 완전한 패키지 도입이 아니라면, 아무리 단순 커스터마이징만 하는 1MM짜리 프로젝트라도 5개가 한계라고 생각한다.
두 번째, 프로젝트의 주요 정보를 한 개의 파일에 관리하자.
프로젝트를 관리한다는 것은 고도의 몰입이 필요한 행위이다. PM은 이메일이나 보고서를 쓰거나, 고객사의 담당자와 전화통화를 하는 동안에도 프로젝트의 주요 범위, 이해관계자, 일정, 리스크 등이 모두 머릿속에 들어있어야 하며, 지난번 미팅 때 무슨 얘기를 했었는지, 다음번 미팅 때 무슨 얘기를 하기로 했었는지 모두 기억하고 있는 상태여야 한다.
PM의 뇌를 절반으로 쪼개서 A 프로젝트를 생각하는 동안 B 프로젝트 보고서를 쓸 수는 없기 때문에, 프로젝트를 두 개 이상 진행한다는 것은 뇌를 사용하는 시간을 쪼개서 사용하게 되는 것이고, A 프로젝트 업무를 하다가 B 프로젝트 업무를 수행하기 위해서는 어느 정도 프로젝트의 주요 내용을 머릿속에 떠올리는 시간이 필요하다. 마치 분석을 수행하는 서버에 일을 시키려면 분석용 데이터를 서버의 메모리에 로딩시켜놓고 작업을 돌려야 하는 것처럼 말이다.
멀티로 프로젝트를 관리하는 경우라면, 빠르게 프로젝트 정보를 리뷰할 수 있도록 주요 정보를 엑셀 파일 하나에 정리해놓고, 그 프로젝트 업무를 시작하기 전에 빠르게 훑어보고 시작하면, 업무 전환시간을 줄일 수 있다. 즉, 그 프로젝트 정보를 읽음으로써, 그 프로젝트의 업무를 진행하는 것을 뇌에게 알려주는 것이다. 필자가 사용하는 엑셀 파일을 예시로 첨부하면 다음과 같다.
프로젝트의 기본정보를 한 개 시트에 적어놓고, 주요 이해관계자, 미팅 기록, 리스크 내용, 인터페이스 목록 등을 기본으로 해서, 프로젝트의 특성과 내용에 따라서, 시트를 추가해가면 될 것이다.
세 번째, 고객 전화는 반드시 즉각 받을 필요는 없다.
필자는 여러 개의 프로젝트를 동시에 진행해 본 경험이 있는데, A 프로젝트 업무를 진행하는 동안 B 프로젝트 고객사에게서 전화가 오면 순간 당황하게 되는 경험이 많다. 전화받는 순간 지난번 미팅 때 무슨 얘기를 했었는지 순간 기억나지 않아서 당황하게 되는 것이다. 심지어는 이름은 본 이름인데, 이 사람이 어느 고객사 담당자인지조차 바로 생각나지 않아서 한참 동안 생각했던 적이 있다.
그럴 경우에 나는 바로 전화를 받지 않는다. 다행히 요즘 스마트폰에는 메시지로 거절하는 좋은 기능이 있다. 일단 회의 중이라고 메시지를 보내 놓고, 미리 정리해놓은 엑셀 파일을 통해 그 프로젝트의 내용을 일단 머릿속에 업로드해놓은 다음, 예상되는 통화내용과 내가 얘기해야 할 사항을 미리 정리한 후에 전화를 한다.
바로 전화를 받아서 버벅대는 것보다는 미리 준비해놓고 전화를 다시 하는 것이 오히려 나을 수 있다. 만일, 진짜로 회의 중이어서 메시지로 거절했는데, 정신없이 일하고 몇 시간 후에 미처 준비되지 않은 상태임에도 불구하고 고객이 다시 전화할 정도로 바쁘다면, (적시 대응을 못한 것이므로) 이미 너무 많은 프로젝트를 맡고 있는 것으로 봐야 한다.
네 번째, 본인이 PM을 맡고 있는 프로젝트들 간 기술 공유를 진행한다.
예를 들어, A 프로젝트에서 구현에 애를 먹고 있는 부분을 B 프로젝트에서는 이미 구현이 완료된 것일 수 있다. 각 프로젝트에 투입된 개발자들의 역량이 차이가 나기 때문이다. 이런 경우, B 프로젝트의 개발자가 A 프로젝트 개발자를 지원하도록 하면, 쉽게 해결될 수 있다. 다만, 이러한 비공식적인 지원이 일회성 지원이 아니라, 지속적/반복적으로 지원하는 경우가 생긴다면, 지원을 하는 개발자는 불만을 가질 수밖에 없는 상황이므로, 지원하는 횟수를 최소화할 필요가 있다.
다수 프로젝트를 진행해야 하는데 모든 프로젝트에 숙련된 개발자를 투입하기 어려운 경우, 몇 개 프로젝트를 묶어서 고급 개발자 1명을 비상주로 지원할 수 있는 체계를 공식화하여 마련하는 것도 좋은 방법일 수 있다. 멀티로 진행하는 프로젝트에 고급 개발자 1명을 각각 0.5MM 정도 투입하는 것으로 계획을 세우고, 경험이 부족한 개발자들이 질문을 하거나, 프로젝트 초반에 기능설 계시 검토회의에 참여시키거나, 주기적으로 프로젝트에 방문하여 소스코드를 리뷰하게 하는 등의 활동을 하게 하면, 멀티로 진행하는 모든 프로젝트에 고급 개발자의 경험을 활용할 수 있게 되고, 경험이 부족한 개발자들이 헤매는 일을 줄일 수 있다.
다섯 번째, 출구전략을 세우자.
멀티 프로젝트를 관리할 때 가장 큰 문제는 끝이 없이 프로젝트가 이어진다는 것이다. A 프로젝트를 종료할 때가 되면, B 프로젝트는 한창 개발 중일 수 있고, C 프로젝트는 착수단계일 것이다. B가 끝나기 전에는 D가 시작할 것이다. 이렇게 되면 계속해서 프로젝트가 이어지는 것이다.
대체로 멀티로 관리가 가능한 프로젝트들은 그리 큰 규모는 아니기 때문에 그와 같이 관리하는 것이 불가능한 것은 아니지만, PM에게는 상당히 안 좋은 형태의 패턴이라고 생각한다.
나는 PM에게 가장 필요한 시간은 오히려 프로젝트를 관리하지 않는 시간이라고 생각한다. 프로젝트가 끝난 후에는 지난 프로젝트를 돌아보고, Lesseons & Learned를 작성하여 사내에 공유하고, 회사 내부에 자산화할 부분이 있는지, 자사 솔루션의 개선점은 무엇인지 등을 생각해야 한다.
이런 활동들은 재충전/재정비의 시간이기 때문에 여유를 갖고 차분히 앉아서 깊이 생각하면서 해야 하는 일들이다. 한창 다른 프로젝트를 진행하고 있는데, 이런 활동을 하기는 쉽지 않다.
따라서, 멀티로 프로젝트를 관리하는 PM은 현재 진행 중인 프로젝트들이 언제 종료될지를 예상하여 그 시점까지는 더 이상 프로젝트를 맡지 않겠다는 것을 회사에 얘기해놓을 필요가 있다. 이러한 PM의 요구를 회사에서 들어주지 않을 수도 있다. 하지만, 계속해서 멀티로 프로젝트 관리를 하다 보면 어느 순간 Burn-out 되는 순간이 다가올 것이고, 그러면 더 이상 그 회사에서 일 할 에너지가 남아있지 않게 될지도 모른다. 따라서, 회사에 이러한 본인의 상태와 생각을 좀 더 분명하게 전달하고, 회사에 오래 남아있기 위해서 재충전의 시간이 필요함을 강력히 어필해야 한다. 그것이 본인을 위해서 뿐만 아니라, 회사를 위해서도 나은 방향임을 얘기해야 한다.
