협력업체 PM 입장에서 프로젝트 수행
PL의 역할에 충실하자.
프로젝트에서 본인의 회사가 어떤 계약관계에 의해 참여하게 되었는지에 따라 그 프로젝트를 바라보는 관점과 수행방식이 달라지게 된다.
계약관계가 아래와 같을 경우,
갑 : 현업 고객, 최종 사용자
을 : PM, 주관사업자
병 : 주관사업자로부터 하도급 계약을 맺은 협력업체.
'병'업체의 PM으로써 프로젝트를 진행하게 된다면, 전체 프로젝트 내에서는 PM이 아닌, PL의 역할을 수행하게 되고, PM의 직함은 총괄 PM이 갖게 된다.
이번 장에서는 협력업체 PM 즉 PL로 일 할 때, 내가 생각하는 중요한 부분을 적어보려고 한다.
* PL로써, 착수시점에 생각해야 하는 것들
PL로 일 할 때, PM일 때와는 다르게 아예 프로젝트 초반부터 투입되는 경우는 거의 없었고, 대체로 착수 이후 몇 개월 지난 후에 투입되는 경우가 많았다. 그런 경우, 프로젝트는 이미 한참 지나있는 상태이고, Ground Rule도 이미 정립되어있는 상태이므로, 빠르게 적응하기 위해 노력해야 한다.
첫 번째, 계약관계 및 주요 이해관계자 파악
먼저 최종 사용자인 고객사가 어디인지, 주관사업자와 우리 회사의 관계는 하도급 관계인지, 아니면 공동수급인지 확인하자. 그에 따라, 주요 이해관계자들이 누구인지 파악해야 한다. 이름과 직급, 메일 주소, 전화번호와 같은 기본정보 외에 그 사람이 요구사항을 내는 최종 사용자인지, 사업의 진행에 어떠한 영향을 미칠 수 있는 사람인지 확인하자.
두 번째, 적절한 인력 투입 시점을 잡아야 한다.
인력의 투입이 너무 빠르면 업무 진행에 필요한 제반사항이 제대로 준비가 안되어, 정작 일은 진행이 안되고 시간만 까먹는 경우가 많다. 대체로 협력업체는 주관사업자와 MM기반의 하도급 계약을 맺은 상태이므로, 투입 MM가 계약 MM보다 초과될 경우 회사 내부의 저항과 프로젝트 관리 역량을 저평가받을 가능성이 있다. 그러므로, 총괄 PM이 인력 투입을 독촉하더라도, 일단은 PM이 먼저 프로젝트룸에 들어가서 프로젝트 상황을 확인하고, 프로젝트 상황이 일을 진행하기 위한 준비가 되어있는 상태인지 먼저 확인한 후에 결정해야 한다.
반대로 인력의 투입이 늦으면 개발기간이 촉박하여 일정을 맞추는 데 어려움을 겪을 수 있다. 하지만, 조금 이르게 투입하는 것보다는 조금 늦게 투입하는 것이 대체로 결과는 좋았던 것 같다.
나는 대체로 프로젝트 초반에 분석/설계까지 최대한 비상주 형태로 진행 가능한 만큼 내부에서 진행해놓고, 투입되자마자 빠르게 확정하여 개발을 시작할 수 있도록 노력하는 편이다. 비상주 상태에서 RFP(제안요청서)나, 한 두 번 미팅 정도만 갖고 현업 요구사항을 상세히 파악하기는 힘들지만, 되도록 상주 기간 중에 시간이 허비되지 않기 위해 먼저 진행하려고 노력한다.
세 번째, 프로젝트 Ground Rule 파악
인력 투입 이후 초반에 파악할 것들은 대체로 다음과 같다.
출퇴근 시간과 점심시간, 지각에 대한 고객의 태도가 어떠한지
주간보고는 언제 취합해서, 언제 진행하는지
파일서버 경로, 각종 산출물의 파일 저장 위치
업무 진행 의사소통 채널 파악(출입등록, 방화벽 신청, 미팅 일정, PC 신청 등의 방법과 담당자)
산출물 템플릿, 작성 범위
품질관리 수준
프로젝트의 주요 일정(개발 완료, 통합 테스트, 서비스 오픈 등의 MileStone)
* PL의 마인드
첫 번째, PL의 역할에 충실하자.
PL로 일을 할 때에는 품질, 일정, 이슈 해결 등 프로젝트 진행상 여러 가지 내용들에 대해 주도적인 역할을 하기보다는 PM이 진행하는 대로 일단은 맞춰주는 것이 좋다.
때로는 내가 경험해 본 것보다 낮은 수준으로 품질관리를 하는 경우도 있을 것이고, 산출물 템플릿도 그다지 좋지 않을 수도 있다. 또한, PM이 이슈를 해결하는 방식이나, 고객을 응대하는 스타일이 적절하지 않다고 느껴질 수도 있다. 그렇다 하더라도 일단은 PM이 진행하는 대로 맞춰줄 필요가 있다.
PL의 역할을 벗어나는(PM이 영역을 침범하는) 의견을 내는 경우, 자칫 PM 입장에서는 자신에 대한 공격으로 받아들일 수 있기 때문에, 어쨌든 PL은 좀 낮은 자세로 임해야 한다.
두 번째, PM을 도와줄 때는 도와주자.
만일 이슈나 리스크가 식별된다면, 고객에게 얘기하기 전에 PM에게 먼저 얘기해주고, 대응방안에 대해 먼저 합의한 후에 고객에게 얘기하자. 그것이 심각한 이슈일수록, 먼저 발견된 것일수록 PM은 당신을 신뢰하고 믿게 될 것이다. 일단은 신뢰를 얻어놓아서 나쁠 것은 없다.
세 번째, PM을 이용할 때는 이용해야 한다.
PM의 스타일은 천차만별이지만, PM을 하는 사람들 중에는 본인이 PM이면서도 모든 사항에 대해 협력업체들에서 먼저 작성해오고, 본인은 취합하는 역할만 수행하려는 경향을 가진 경우도 있다. 심한 경우에는 PM스스로는 어떤 경우도 책임을 지지 않으려는 것으로 보일 때도 있다.
이런 스타일의 PM으로부터 (필수적이지 않거나, PM 본인이 할 일을 떠넘기는 것 같은) 작업 요청을 받을 경우에는 좀 더 구체적인 방향성이나 사례, 템플릿, 그 작업의 목적 등에 대해 물어보자. 오히려 "전체적인 틀을 PM님이 먼저 잡아서 내려주시면, 검토해보고 구체화해서 드리겠습니다."라고 하는 것도 방법이 될 수 있다.
네 번째, PL의 목표는 투입 MM를 최소화하는 것이다.
PM 입장에서는 전체 프로젝트를 모두 완료시키는 것이 목적이겠지만, PL의 가장 큰 목표는 투입 MM를 최소화하는 것이다. 그렇기 때문에 앞에서 얘기한 바와 같이 일을 할 수 있는 상태가 된 후에 인력을 투입해야 하는 것이고, 반대로 전체 프로젝트의 완료 여부와는 상관없이 우리 회사가 맡은 범위만 빨리 마무리한 후에 철수하려고 노력하기 마련이다.
그 목표와 방법 자체는 틀리지 않지만, 우리 회사의 개발진행과 상관없이 철수가 지연될 가능성이 있는 부분이 있는데, 바로 타 솔루션과의 인터페이스가 발생하는 경우이다. 그런 경우에는 타 솔루션 개발이 지연되면 우리 회사의 철수 일정도 영향을 받을 수밖에 없다. 그러므로, 타 회사와의 인터페이스는 좀 더 적극적으로 개발 진행상황을 챙기고 인터페이스 테스트 일정을 빠르게 가져갈 수 있도록 노력해야 한다.
뛰어난 PL은 다방면에서 뛰어난 역량을 티 나게 드러내 보이지 않고, 소리 없이 조용하게 딱 할 것만 하고 철수하는 PL이라고 생각한다. 산출물 품질도 고객사의 품질관리 수준에 비해 과도하게 높을 필요도 없고, 크게 티 나지 않게 맞춰주는 정도를 목표로 조금은 힘을 빼고 작성하면 될 것 같다.
나는 직장생활을 하는 동안 발주처 PM, 주관사 PM, 협력업체 PM을 모두 경험해보았지만, 역할이 바뀔 때마다 적응하는 게 쉽지는 않았고, 몇 번의 크고 작은 시행착오를 경험한 후에야 내가 어떻게 해야 하는지를 비로소 알게 되었던 것 같다. 만일 누군가 이직을 고려하는 중이고, 그와 같이 역할이 바뀌게 될 예정이라면 바뀐 역할에 따라 어떤 자세로 임할 것인지, 본인이 잘 할 수 있을지, 미리 잘 생각해보고 이직을 결정했으면 한다. 위 역할들은 편의상 그냥 모두 PM이라고 불리지만, 실제로 하는 일의 내용과 방식은 천차만별이다. 일의 내용과 방식이 다르다는 것은 그 역할에서의 성공방정식이 다르다는 것이고, 과거의 내 경험이 옮긴 곳에서의 성공에 크게 도움이 되지 않을 수 있다는 것을 의미하기 때문이다.
