brunch

You can make anything
by writing

C.S.Lewis

by 김민환 Sep 19. 2020

PM의 메인 업무

최초 대응부터 프로젝트 계획 수립까지

보통 프로젝트를 시작하거나 관여하면 "날짜_프로젝트명"으로 폴더를 만들고 나서 업무를 시작하는데,

얼마 전 갑자기 궁금한 마음에 얼마나 되나 세어보니 총 250개가 넘습니다.


지금의 회사에서 내가 진행하거나 관여했던 프로젝트가 250여 개라는 이야기가 되는데,

재직기간으로 나누면 1년 평균 20개가 넘는 프로젝트에 참여했다는 뜻입니다.


물론 그중에는 단순 견적 대응만 하다가 그친 프로젝트도 있고, 제안했다가 떨어져서 이후 아무런 진행을 하지 않은 프로젝트도 포함되어 있습니다.

어쨌거나 250여 개의 폴더가 있다는 것은, 그 수만큼 내가 무언가 업무를 진행했다는 뜻이고, 짧게는 며칠 길게는 1년이 넘는 기간 동안 내가 그 폴더에 여러 가지 문서와 산출물을 쌓아가며 그 일을 했다는 것입니다.

다른 누군가에게는 적을 수도 혹은 많을 수도 있을 것 같습니다.




보통 프로젝트는 의뢰인의 아웃소싱 문의로부터 시작됩니다.

홈페이지나 온라인 서비스를 만들려면, 혹은 지금 있는 것들을 개선하려면 얼마만큼의 기간과 비용이 들지에 대해 대략적으로 답변을 합니다.

또는 이미 예산과 기간까지 정해놓고(언제 오픈해야 되는지) 연락을 줄 때도 있도 있습니다.

그 예산과 기간 동안 제작이 가능한지 문의하거나 아니면 제안요청을 할 테니 제안할 의향이 있느냐는 연락입니다.

우리는 그 사업이 우리 회사에 메리트(매출/이익, 홍보, 경험)가 있는지를 판단하고 업무를 담당 또는 제안하겠다고 하거나 진행하기 어려울 것 같다는 피드백을 합니다.


의뢰인은 여러 곳에서 견적서나 의견을 받아보고 업체를 선정을 합니다.

제안을 받는 경우 제안서와 제안 PT를 평가하여 업체를 고릅니다.

수행 업체로 선정되면 계약과 추가적인 업무 요건 협의를 거쳐 사업이 착수됩니다.

짧게는 1~2개월부터 2년여에 이르기까지 프로젝트의 진행 기간은 천차만별입니다.




보통은 제안한 부서에서 수행을 진행하지만, 때로는 제안부서와 수행부서가 다를 때도 있습니다.

어찌 되었던 계약을 마치고 착수일이 결정되면 가장 먼저 결정되는 것은 사업관리 담당자와 PM(Project Manager)입니다.

사업관리 담당자는 계약, 구축 비용을 제때에 받는다거나, 인력 운용, 예산 집행 등 실제 프로젝트를 진행하는 데 있어서 인력들이 서비스를 만드는 것 외에 필요한 업무들을 진행합니다.

PM은 그러한 사업관리 담당자의 지원을 받아 주어진 리소스(인력, 비용, 기간 등) 내에서 좋은 서비스를 만들 수 있도록 하는 일을 합니다. 사업관리와 PM은 서로 보완적인 관계가 됩니다. 전쟁터에서 서로의 등을 맡기고 싸우는 동료인 것입니다.(말이 그렇다는 것이지 '프로젝트 = 전쟁터'라는 뜻은 아닙니다. ^^)


경우에 따라 사업관리 담당자와 PM을 겸임하는 경우도 많이 있습니다.

의사결정이 빠르다는 장점이 있으나, 한편으로 업무가 과중되어 힘이 들 때도 있습니다.

하지만 저는 최초 영업 대응부터 제안서 작성과 발표까지 사업관리를 겸하면서 PM이 직접 하는 경우를 선호합니다.

그만큼 초기부터 고민할 시간을 가질 수 있고, 제안 내용과 프로젝트 결과물의 차이도 줄일 수 있기 때문입니다.




일반적으로 제안요청과 제안을 통해 프로젝트가 착수되면 PM에게는 2개의 문서가 주어집니다.

하나는 1)제안요청서 또는 요구사항 정의서, 다른 하나는 2)제안서입니다.


제안요청서나 요구사항 정의서에는 고객이 이 프로젝트를 어떤 목적으로 진행하기로 했으며 어떤 결과물을 원하는지에 대해 정의되어 있습니다. 제안서는 수행사가 프로젝트의 목적과 요구사항을 우리는 이렇게 이해했으며, 어떠한 과정을 거쳐 원하는 결과물을 납품하겠다는 내용이 들어 있습니다.


PM이 본인의 회사 입장에서 제안한 제안서만 보지 않고 그 이전 자료인 제안요청서와 요구사항 정의서를 함께 참조하는 이유는 혹시라도 꼭 필요한 부분인데 제안 과정에서 누락된 것이 있을 수 있기 때문입니다.

핵심 요구사항이 중간 과정에서 누락되어있다가 프로젝트 종반에 발견되는 경우도 흔히 발생합니다.

상당히 큰 리스크이기 때문에 이러한 실수를 없애기 위해서 고객 사이드에서 정리된 문서를 꼼꼼히 확인해야 합니다.




PM은 수행사 입장에서 요구사항 정의서를 보완하고 나서, 곧 수행계획을 세웁니다.

보통은 수행계획서라는 문서 형태로 정리해가며 계획을 세우는데, 이 수행계획서에는 제안할 때의 모호한 표현과 항목들을 최대한 구체화해서 적고, 그것들을 진행하기 위해 어떠한 방법으로 어떠한 인력들이 투입해서 어느 기간(항목별 대략적인 일정) 동안 제작을 진행할지가 정리됩니다.

수행계획서 작성과 동시에 바로 WBS 작성에 착수합니다.


WBS는 'Work Breakdown Structure'의 약자로, 전체 TF가 해야 할 업무를 계층적으로 나눠서 실행하고 서로가 확인할 수 있는 수준으로 업무를 리스트업 하여 관리하기 위한 문서입니다.

이 문서를 날짜와 선후관계 순으로 정리하면 Gantt 차트가 됩니다.

보통 WBS상태로 놔두기보다는 간트챠트화 하여 공유하는 경우가 많습니다.

일정에 대해 서로가 감을 잡기 위해서입니다.

시안 디자인이 이 날짜에 착수하기 위해서는 내가 00일까지 시안용 화면 기획안을 고객 담당자에게 컨펌받아 전달해야겠구나 등의 업무에 대한 일정을 확인할 수 있습니다.




일단 여기까지 진행되면 PM으로서의 역할은 절반은 끝난 샘입니다.(시작이 반)

이후는 프로젝트 일정대로 업무가 진행될 수 있도록 각 작업자들이나 현업 담당자들과 커뮤니케이션하고, 중간에 이슈가 발생하면 해당 이슈를 트래킹 해서 해결하는 업무들을 진행하면 됩니다.


프로젝트가 클수록 요구사항이 많고, 그만큼 여러 인력들이 업무를 진행하게 되므로 이슈도 많이 발생합니다.

팀원들 개개인간 또는 파트 간 사이가 좋지 않아 업무가 매끄럽지 않게 진행되기도 하고, 혹은 인력의 이탈(개인 사정, 건강상의 문제)이 발생되면 그 부분도 PM이 사업관리 담당자와 협의해가며 조율해야 합니다.


이러한 프로젝트 진행 시 주요 업무는 다음 편에 계속됩니다.

매거진의 이전글 PM의 정체성
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari