프로젝트 종료 (프로젝트 성공률 1% 높이기)

프로젝트 종료. 유종의 미!

프로젝트란 Kick-off를 한지가 엊그제 같은데 벌써 종료가 코앞으로 다가왔다. 계절도 바뀌고 그간 수많은 우여곡절과 어려움 속에서도 여기까지 온 모두가 대단한 일들을 해냈다. 이제 마지막 남은 업무를 잘 마무리하고 철수를 해야 한다. 철수에 대한 준비는 만만하지 않다. 하지만 중간과정에서 제대로 된 끝맺음과 시작을 했다면 그리 염려할 사항도 아니다. 잘 정리해서 최종 산출물을 별 탈 없이 인도하고 이제 당분간 머리 아픈 일들은 잠시 잊도록 해보자.
 
 

프로젝트 종료 프로세스

프로젝트 종료는 프로젝트 범위 검증, 계약 종료, 프로젝트 종료로 크게 3가지로 나뉜다.
 
🚩범위검증
 : 프로젝트 이해당사자들로부터 완료된 프로젝트 인도물을 공식적으로 인수 승인한다. 이에 범위관리계획서와 더불어 범위 기술서, 인수 대상 목록(WBS), 인도물을 받아 인스펙션을 진행한다. 인스펙션은 인도물이 기준에 충족하는지를 판별하며 여기엔 검토, 검사, 워크스루, 측정 등이 포함되며 이 과정을 통해 인도물을 인수하고 내용 중 문제가 되는 부분에 대해서는 변경 요청 및 시정조치를 요구한다. 인수에는 선 테스트에 대한 통합결과로서 승인의 결과물을 남기며 참여한 인력의 검증을 받는다.
 
🚩계약 종료
: 프로젝트 내 미결사항에 대한 해결 등을 포함하여 프로젝트 종료를 위한 계약을 완료하고 청산한다. 이때 업무도 종료가 되지만 예산에 대한 결과도 마무리한다. 프로젝트에 필요했던 구매관리, 계약관리계획서를 토대로 계약 검사를 진행하고 계약 파일, 인수확인서 등을 챙겨 계약을 종결시킨다. 계약 종료는 말 그대로 행정적 종료이기 때문에 보통은 실 프로젝트 기간 전에 대부분 완료 처리를 하고 후속 건이 있다면 이에 대한 준비를 시작한다.
 
🚩프로젝트 종료
: 프로젝트를 공식적으로 종료하기 위한 관리 프로세스의 모든 활동을 마무리한다. 이를 위해서는 계약종결(제품 검증 포함, 계약 자체 종결) 절차와 행정 종결(프로젝트 기록 및 조직 해체) 절차가 포함되며 계약문건, 성과물을 바탕으로 계약종결, 행정 종결 순으로 마무리한다. 이러한 종료는 단순히 업무가 끝난 것이 아니라 고객과의 신뢰 관계를 구축한다는 의미에서 계획만큼이나 중요하다. 이를 위해 가시적인 절차를 통해 설명하고 이해시키는 과정이 필요하다. 그렇지 않은 경우 여러 문제가 발생할 소지가 있으며 프로젝트가 종료되지 않고 계속 지연이 되는 경우가 발생할 수 있다.
 
   – 최종산출물에 대한 인수 확인 실시
   – 프로젝트 최종 리뷰
   – 프로젝트 보고서 제출
   – 대금 처리
   – 프로젝트 할당 자원 해제 및 철수
   – 프로젝트 파일 보관
 
이 과정에서 인수 회의가 개최되고 프로젝트 최종 리뷰를 실시한다. 최종 리뷰는 프로젝트 계획, 조직, 수행, 관리, 재정 등 모든 분야를 포함하며 성공적인 부분과 향후 개선이 필요한 부분 등을 인식시킨다. 이는 고객이 프로젝트를 내재화하고 추후 개선 가능성을 확인하는 중요한 일이다. 이 자리엔 모든 이해당사자가 참석하여 회의의 목적을 명확히 하고 그간의 노고를 위로하고 서로 축하는 자리의 역할도 수행한다.
 




 

Lessons Learned

회고 또는 교훈. 이는 프로젝트에서 발생한 변경과 그 원인 및 결과를 기록한 문서이다. 프로젝트 변이의 원인, 채택된 시정 조치의 이면 논리, 범위 변경 통제로부터 얻게 되는 교훈들은 해당 프로젝트뿐만 아니라 수행 조직의 다른 프로젝트를 위한 자료 및 베이스라인 설정과 성과측정 기준으로서 반드시 문서화하여야 한다. 이는 추후 기업 및 조직의 자산으로서 지식경영의 근간이 된다. 이러한 마무리에는 특히 성공만이 있는 것이 아니다. 성공을 위한 여러 실패도 매우 소중하게 다뤄야 하며 이런 경험치들이 쌓여 누구도 갖지 못한 무형자산이 될 수 있다.
 
그렇다면 이 교훈을 보다 잘 습득하는 방법은 뭐가 있을까? 이는 프로젝트 전 생명주기를 통해서 얻어져야 하며 매 주요한 단계의 종료 시마다 빠짐없이 리뷰되어야 하며 모든 사항이 정확하고 자세히 분석되고 기록되어야 한다. 그러면서 이해당사자 간 상호 공유를 통해 같은 인식과 목적을 상기시켜 방향성을 잃지 않도록 해야 하는 과정들을 지켜나가야 하는 것이다. 특히나 성공적인 부분들은 Best Practice로서 반복, 적용할 수 있는 자료화하며 성공도 등급을 나누어 차등화할 수 있도록 한다. 
 
프로젝트는 발주자도 그렇고 수행자도 상기의 절차를 통해 모두 종료 과정을 거친다. 특히 맨 마지막 과정으로서 전체 Warp up 시간을 갖는 것은 매우 가치 있는 작업이다. 이는 후속 단계의 작업 시작을 원활하게 해주고 자연스러운 인수인계가 이뤄질 수 있는 실마리를 제공한다. 투입된 팀원들은 성과를 평가하고 경력을 상담하며 추후 건설적 제안이나 권고를 모두가 할 수 있는 통로를 개설하여 활성화한다면 더할 나위가 없을 것이다. 모든 교훈은 자발적 참여와 함께 얻어질 수 있으며 포괄적 사후검토로서 어쩌면 가장 중요한 끝맺음 작업이다.
 
 
 
 
※ 쫑파티!
짧고도 긴 시간의 끝에서 같이 만나고 헤어지는 자리. 그간 혹시라도 맘에 담아둔 것이 있다면 이 자리를 빌려 털어버릴 수도 있고 서로의 고생을 보듬어주는 뜻깊은 자리이다. 하지만 요새는 이런 분위기도 점점 사라지고 있다. 이유야 여럿이지만도 일을 사람이 할지인데 뭔가 섭섭한 마음이 드는 건 어쩔 수 없다. 하지만 형식은 바뀌어도 마음만은 변하지 않았으면 좋겠다. 그래야 사람 사는 맛이 나지 않을까? 더불어 이런 인연들은 시간이 지나더라도 언젠가 또 만나게 되니 있을 때 잘해보는 것도 나쁘지 않겠다. 사실 원수는 외나무다리에서 만난다고 하지 않았는가? 누구도 아닌 나만의 원수는 결국 만나게 되어 있다. 정말 희한하지 않은가? 정말이다..

외주 관리 (프로젝트 성공률 1% 높이기)

외주

외주(Outsourcing)는 프로젝트 조직이 해당 업무 또는 기술에 대한 노하우나 경험 등이 부족하거나 개발 인력 또는 예산 등이 부족하여 외부 제삼자에게 대상 업무의 일부 또는 일체를 위탁하여 처리하는 방식을 말한다. 이러한 외주를 고려하는 배경에는 자체 기술력이 미흡 또는 없을 때, 자체 개발 시 예산이 부족할 때, 여유가 없고 시간을 절약하고자 할 때 또 개발인력이 부족할 때 많이 활용한다.
 
근래 들어 외주를 심각히 고민하는 경우는 인력난 때문이다. 코로나 때 더 심화한 인력난은 인력이 당장 필요한 기업에는 재앙 같은 수준이다. 웬만한 기술력이 있는 개발자들은 대기업에서 모두 데려가고 시장엔 사람이 있으나 사람이 없는 상황. 그러다 보니 정규직도 직장을 그만두고 프리랜서로 뛰는 경우도 많이 발생하고 있다. 여기엔 급여가 가장 큰 이유가 되고 있으며 워라밸 등을 중요시하는 풍조도 한몫하고 있다.
 
 
그래서 외주가 더욱 중요해지고 이를 사업화하여 서비스하는 곳도 많아지고 있다. 특히나 사람을 구하기 힘들어지니 정규직이 아닌 외주계약 형태로 지속 운영 중인 곳도 많이 생겨나고 있다. 
 
 

외주계약 형태

외주를 주고자 하는 경우, 계약 시 위임을 할 것인지 파견을 할 것인지부터 프로젝트의 전체 또는 부분을 할당할 것인지 아니면 사람만 필요한 것인지도 사전에 확인하고 판단해야 한다. 그러기 위해서는 외주업체를 선정해야 하는데 크게 두 가지가 있다.
 
✔️ 정량적 기준: 초기 비용, 유지보수 비용, 비용 영향력 등을 전반적으로 고려
✔️ 정성적 기준: 조직 또는 프로젝트와의 호환성, 연계성, 업체의 이전 프로젝트 정보, 외주 관리 수행조직의 역량 고려
 
이러한 외주업체에 대한 평가 방법에도 Survey, 이전 프로젝트 리뷰, 품질시스템 등이 있으며 상황에 따라 적절하게 선택하여 평가한다. 이렇게 업체가 선정된다면 외주계약을 진행하게 된다. 이 과정에서 각자의 입장 차로 시일이 오래 소요될 수도 있고 예외 사항들도 나타날 수는 있으나 기본적인 계약 형태 안에서 보면 다음과 같다.
 
🚩고정가격계약
 : 규정된 공사/서비스에 대한 대가가 확정된 계약이다. 이는 사전에 정의된 공사/서비스에 대해서 고정가격을 정하여 진행하는 것으로 계약 단계에서 제품(공사/서비스)에 대한 정의가 명확한 경우 많이 사용된다. 그렇지 않다면 발주자는 원하는 결과물을 얻지 못한 위험성이 있으며 수주자는 발주자의 요구사항에 따라 추가적인 비용이 발생할 수 있는 위험성도 공존한다.
 
🚩실비정산계약
: 실제 발생한 비용에 대해 지불하는 계약이다. 실비는 보통 직접비와 간접비로 구성되는데 직접비는 이윤이 배제된 비용으로 프로젝트 수행을 위해 직접적으로 소요되는 인건비, 재료비, 경비 등이 여기에 포함된다. 간접비는 사업 수행을 위한 비용으로 수행 조직에 의해 프로젝트에 할당된 비용으로 보면 되며 대부분 경비성의 비용이 해당한다. 이 계약 방식은 고정가격계약 대비 계약 특유의 위험이 없으며 내용 변경 등에 대하여 발주자에게 최대한의 유연성을 제공할 수 있다.
 
🚩단가계약
: 사전에 약정된 단가에 의해 대금을 지급하는 계약이다. 단가가 고정되므로 원가 변동에 대한 위험은 수주자가 부담하는데 단가는 예상 수량을 기본으로 산출하기 때문에 실제 수량과의 오차가 일정 범위 이상으로 커지게 되는 경우 단가를 조정할 수 있도록 유연성을 가지고 계약함이 좋다.
 
 

문제점들

외주계약은 외주를 주기 이전에 내부고객을 대상으로 한 외주로서 생각해 볼 수도 있다. 그렇기 때문에 작업 범위와 목적물에 대한 명확한 정의, 항목들, 예산 및 변경 가능성과 빈도, 업무의 전문성과 표준화 정도를 충분히 따져서 계획을 세워봐야 한다. 그러고 나서 자체적인 역량과 상황에 따라 어떤 부분을 의뢰할 것인지 결정하고 이에 맞춰 업체 선정과 계약이 진행되어야 한다.
 
이렇듯 치밀한 계획과 명확한 목표를 가지고 외주계약이 되더라도 발주자와 수주자 사이에는 여러 문제로 간극이 생길 수 있는데 이는 해결해야 할 문제로 계약 전 상호 인식하고 협의해 나간다면 원만히 진행될 것이다.
 
♾️ 수/발주단계
: 무엇보다 상호 간 의사소통을 원활히 하는 데 장애가 있을 수 있어서 이에 따른 이해도가 부족할 경우가 많다. 또한 용역의 범위와 예산도 조정의 대상이 될 수 있으며 개발자의 능력이나 역할도 중요한 잣대가 되고 정해진 시간 내에 인력을 확보해야 하는 어려움도 있다. 하지만 계약까지의 일이다.
 
♾️ 용역수행단계
: 관리상 문제가 항시 있다. 특히 공정과 품질에 대한 이슈는 하나씩 해결해 가야 한다. 잘 진행되고 있는 업무도 이해 부족에 따른 예외 사항을 발견할 수 있으며 이는 의사소통의 폭을 넓혀 소통해야 한다. 예기치 않은 요구사항이 잦아질 수도 있고 뜻하지 않은 인력 변경이 발생하기도 한다. 이런 과정들이 가시성을 확보하기가 쉽지 않아 추가적인 비용 발생에 따른 껄끄러운 상황이 생길 수 있다.
 
♾️ 인수인계단계
: 용역수행의 결과이다. 납품되는 최종산출물에 대한 품질 문제가 실제 인도 단계에서 발생하는 경우도 많다. 이런 사항들은 납기를 못 맞추는 아주 심각한 상황을 초래하며 초과 비용, 소유권 시비 및 불충실한 문서나 인수인계 문제도 많다. 서로의 입장만 내세우다 보면 어느 한쪽의 입장만을 고려할 수도 없다.
 
내 조직 내에서의 일도 힘들지만 이를 외주로 주면서 생기는 문제는 더 많이 생길 수밖에 없다. 하지만 그만큼 서로 신경을 쓰고 업무에 충실하게 임한다면 문제가 아닌 성과로, 더 나아진 모습으로 함께할 수 있는 관계로 발전할 수 있다. 여기엔 업체선정까지의 철저한 과정, 그리고 의사 소통라인의 강화 및 지속적 모니터링과 관리가 병행되어야 함은 당연하다.
 
 
 
 
※ 정규직 싫어요!
시장에 막 들어온 신입사원들을 빼고는 어느 정도 경력과 실력 있는 인력들이 회사를 그만두는 사례가 많아지고 있다. 이런 그들에게 이야기를 들어보면 최우선적으론 급여이고 두 번째는 자신의 조건에 맞는 일자리를 찾을 수 있다는 것이다. 하지만 프리랜서도 마냥 좋은 것만은 아니다. 지속적인 일거리를 스스로 만들어야 하며 시장에서 살아남기 위해선 끊임없이 공부하고 기술력을 계속 보강, 확대하여야 한다. 남이 대신 해주던 일을 스스로 해야 하는 1인 기업가로서 자리매김하지 않으면 사실 어디서 일하던 똑같을 수밖에 없다. 즉 직장인이 아닌 기업가가 되어야 한다.

프로젝트 제안 (프로젝트 성공률 1% 높이기)

프로젝트 발주

프로젝트 발주는 고객의 니즈를 내부적으로 충족할 수 없는 경우 조직 외부로부터 제품, 서비스 또는 특정 결과물을 조달하는 것이다. 이를 전담하는 인력은 흔히 발주 PM이나 발주업무 담당자라고 볼 수 있는데 실제 프로젝트를 진행할 PM의 입장에서도 프로젝트 배경과 필요성을 제대로 파악하는 것이 프로젝트의 요구사항 분석과 성공을 위한 필수적이다.
 
발주는 공개적인 방식 또는 제한된 정보망 등을 통해서 공유된다. 사업자들은 항시 발주 이벤트를 주시하고 있으며 언제든지 진행할 준비를 하고 있다. 누가 먼저 소식을 접했느냐도 중요하지만 제한된 시간 내에 모든 역량을 투입할 수 있는 여건도 또한 중요하다. 어찌 보면 중요하지 않은 것이 하나도 없다.
 
 

프로젝트 제안

제안서는 프로젝트 사업자 선정을 위한 기술평가를 통해서 수주 경쟁화한다. 이를 통해 사업제안자들의 사업수행역량을 체크하고 각 제안 별 핵심 사항과 역량 검증을 통해 최적의 사업자를 하나둘 선별해낸다. 이런 제안의 흐름은 일반적으로 다음의 단계를 거친다.
 
🚩제안요청서
 : RFP(Request For Proposal)라고 말하는 것. 사업에 대한 고객의 세부적 요구사항이 정의되어 있고 제안을 위한 기본 틀과 요건을 제시한다. 다양한 형태의 제안서가 존재하지만 가장 중요한 것은 원하는 것이 무엇인지, 이를 통해 최종 결과물의 이미지가 무엇인지 명확하게 제시하는 것이다. 가끔 고객 스스로가 무엇을 할지 제대로 모르면서 부실한 RFP를 내는 경우가 있는데 이건 시장에서도 매력도가 떨어지며 그 누구도 참여할 이유를 찾지 못하기에 이 또한 잘 만들어야 한다. 그러기 위해선 고객도 공부가 많이 되어 있어야 하며 자신들의 약점과 강점을 알고 조직적인 대응을 해야 한다.
 
🚩제안서
: RFP가 뜨고 나서 사업을 검토 후 제안에 응할 목적으로 작성하는 것. 사업을 어떻게 수행할지 포괄적으로 정리하며 고객이 평가를 통해 결정할 수 있는 근거 자료와 신뢰를 줘야 한다. 즉, 요구사항에 대한 구체적인 방안과 제안사의 사업수행 능력을 명확히 보여줘야 한다. 여기서 최우선은 고객 만족이다. 이를 우선순위로 내용을 작성하며 사업수행을 위한 다양한 투입자원을 고려하여 현실적인 사업 범위를 결정, 제시한다. 특히 경쟁사 대비 차별화는 추후 POC(Proof Of Concept) 나 BMT(Bench Marking Test) 등을 염두에 두고 변별력을 가질 필요가 있다.
 
🚩계약
: 선발된 다수명의 심사자 및 심사조직을 통해서 제안심사가 진행된다. 몇 단계에 걸쳐 심사 결과들이 발표되기도 하는데 계약 성사를 위해 제안서를 토대로 제안프로젝트를 본격적으로 진행한다. 제안 분석과 전략 수립, 목차를 구조화하고 핵심 내용을 선별 후 예상 질의까지 준비한다. 제안발표를 하고 당 제안이 타당하다고 평가되면 사업자가 선정된다. 협상을 통해 최종사업자를 가리게 되면 계약이 진행된다. 계약에는 RFP와 제안서를 토대로 여러 법리해석과 최종견적이 완성된다. 사업 대가는 프로젝트 단계별로 고려하고 규모와 자원투입, 시간을 기준으로 산출한다.
 
 

RFQ, RFI, 그리고

프로젝트 발주를 위한 RFP는 봤는데 이와 비슷한 RFQ, RFI, RFB 등 여러 용어도 볼 수 있다. 이것들은 프로젝트 진행을 위한 분야별 세부 확인을 위해 쓰이는 것들인데 주요한 것만 살펴보면 RFI(Request For Information)는 사전정보요청으로 RFP를 작성하기 전 프로젝트에 필요한 여러 정보나 환경 등을 파악하기 위한 자료로 쓰인다. 특히 기술 부분에 있어 내부 역량에 따른 외주 여부 등을 사전에 파악해 볼 수 있으며 일차적인 필터 기능도 포함한다. RFQ(Request For Quotation)는 제안 견적요청서로 예산 중심의 문건이다. 즉, 적절한 프로젝트 비용을 파악할 필요가 있는데 RFP 요청 시 RFQ도 같이 요구하는 경우가 많으며 두 문건을 같이 검토하여 평가의 기초로 다룬다.

 

프로젝트 수주

제안서 작성의 최종 목적은 프로젝트 수주이다. 아무리 제안서를 훌륭하게 작성하였어도 프로젝트를 수주하지 못하면 그 제안서는 아무런 의미가 없다. 결국 가격 부분을 제외한 나머지 부분, 제안사는 고객의 이번 사업을 다른 누구보다도 잘 이해하고 있으며, 최고의 솔루션(제안된 솔루션을 이행할 계획과 인력, 기술, 그에 대한 풍부한 경험)을 제안하여 제안사를 선택할 경우 성공적인 프로젝트를 수행할 것을 보장한다는 내용을 빠짐없이 담고 있어야 한다. 제안서는 고객의 요구사항을 정확하게 파악하고 고객과의 원활한 커뮤니케이션, 구체적 서비스 내용을 제안서에 어떻게 표현했는가에 따라 그 결과가 좌우된다.
 
다시 말해 제안서는 단순한 제안 문서로서의 의미보다 제안 업체의 사업역량의 위상을 표현하는 최고의 서비스 상품이 되어야 한다. 그렇기 때문에 사업자 스스로 질문과 답을 해야 하고 고객 이전에 먼저 설득이 되어야 한다. 그러고 나서 고객을 설득한다. 그러기 위해서 정말이지 어디에 내놔도 당당한 제안서라는 상품을 만들 필요가 있다.
 
 
 
 
※ 템플릿
요즘처럼 넘쳐나는 정보 속에서 자료가 없이 일을 못 했다는 건 말이 되지 않는 세상이 되었다. 그런데 정작 중요한 것은 형식도 형식이지만 내용이 먼저다. “고객이 원하는 것이 무엇인가?”에 대한 깊은 고민은 책상 앞에서 만으론 해결되지 않는다. 그러니 틀이 짜졌다면 열심히 더 뛰어다녀야 한다. 그러면서 체득한 내용들을 채워 넣어야 한다. 그러나 지금 당장 일어나 움직이자!

PM (프로젝트 성공률 1% 높이기)

PM. 그는 누구인가?
어느 고객이건 사이트이건 프로젝트가 시작될 때 우선순위가 가장 높은 일 중의 하나는 PM, 프로젝트관리자를 구하는 것이다. 우리가 하고자 하는 프로젝트를 맡아줄 최적의 적임자를 찾는 것이다. 다른 구성원이나 조직들이 완비되었어도 PM이 없다면 선장 없는 배나 다름이 없다.

그렇다면 PM은 무엇인가? 프로젝트관리자는 간단히 말해 프로젝트의 성공적 수행을 책임지는 사람이다. 프로젝트의 성공에는 PM이 필수이며 PM은 자신이 원하는 팀을 꾸리고 활동을 지원하며 여러 이해당사자의 업무를 조정하고 협업을 조정한다. 사람과 사람 사이의 갈등도 조율하고 각종 위험 요소를 미연에 방지하고 해결책도 찾아야 하며 이를 통해 궁극의 책임을 지는 사람.

그래서 PM의 어깨 또한 무겁다. 그래서 이를 감당할만한 권한과 책임 또한 같이 주어진다. 작은 프로젝트는 규모의 차이이지 하는 일은 똑같다지만 그래도 부담은 다소 적을 수 있고 최악의 경우 인력수급이 제대로 안 될 경우에는 여러 사람(?)이 합심해서 프로젝트를 꾸려나갈 수도 있다. 그러나 정답은 아니다. PM은 그 자리에 있어야 할 인물이다.

 

프로젝트관리자의 역할들
위에서 보면 과연 PM을 할 사람이 있을까 하는 생각이 절로 든다. 하지만 오랜 경험과 통찰, 이슈 해결에 흥미를 가지고 이력 관리를 하는 사람 또한 적지 않다. 다만 서로가 원하는 인연이 필요할 뿐. 환경 탓은 부차적이다. 그래서 PM은 준비해야 한다.

🚩계획수립, 자원관리, 보고
: 현장을 돌아보고 자리에 앉아 현실적인 계획을 짜야 한다. 단순히 책상머리에 앉아만 있으면 안 된다. 모든 조건이 만족하지 않는다면 더더욱 현장을 뛰어다녀야 한다. 이를 토대로 내가 손에 쥔 것이 무엇인지, 무엇이 필요한지 판단하고 이를 구하고 배정해야 한다. 계획대로 일을 진행하기 위해선 인력과 자원을 필요할 때 지원받을 수 있게끔 상하 위 소통의 끈을 놓지 말고 정확히 보고한다. 단순 문제 제기는 아무런 도움이 되지 않는다. 항시 대안을 마련하여 신속 정확한 의사결정이 될 수 있도록 한다.

🚩책임, 조정, 의사소통
: 프로젝트 초기 고객의 요구사항을 명확히 파악하고 범위 확인을 통해 업무를 수행한다. 하지만 모든 일에는 반드시 예외가 발생하고 계획대로 되는 일은 거의 없다. 그래서 변경 사항에 대한 통찰력과 함께 그 파급효과 등을 사전에 고려하고 원활하게 운영될 수 있도록 조정이 필요하다. 여기서 품질은 기본적으로 챙기면서 모든 단계의 업무가 유기적으로 잘 흘러갈 수 있게 의사소통력 또한 필요하다.

🚩의사결정, 관리, 훈련
: 책임과 권한이 있기에 의사결정을 내릴 수 있다. 다만 올바른 의사결정을 위해선 거시적인 안목과 관리가 필요하다. 그 순간 최선의 의사결정을 내릴 수 있는 데이터가 필요하고 이는 모든 구성원으로부터 교육훈련 등을 통해서 상호 지원받아야 한다. 팀원에 대한 격려와 수행력을 향상하고 여러 자리를 통해 갈등을 해소하는 것. 일보다 사람이 힘들다는 것을 몸소 체험하게 될 자리에 PM이 서 있다.

🚩발주, 계약, 검수
: 관리의 영역은 넓다. 이러한 업무를 지원해 주는 조직이 있을 수도 있지만 우선은 PM의 손을 타게 되어있다. 그래서 단순히 현업업무에만 집중하면 안 된다. 발주자의 역할로서 인력이든 다른 자원이든 PM의 손을 거쳐 움직여야 한다. 특히나 행정적 위험이 곳곳에 도사리고 있는 업무인 만큼 검증과 피드백을 통해 확인에 확인이 필요하다.

🚩조직 지원과 협력
: 위와 같은 외부 조직 등과의 업무를 위한 일도 있지만 내부 조직 또한 하나의 고객으로서 매우 중요하다. 그 말은 이들의 지원 또한 무시할 수 없다는 것을 말한다. 그래서 유관부서와 긴밀한 의사소통과 공유가 필요하고 서로의 업무 영향력을 고려한 협력이 필요하다. 프로젝트를 원만히 진행하기 위한 든든한 버팀목이자 지지자들은 멀어 어딘가가 아닌 바로 내부에 있다.

 

PM. 그들에게 필요한 것들
그렇다면 PM은 무엇을 갖춰야 할까? 너무 많은 것들이 있지만 그래도 중요한 몇 가지를 꼽으라면 다음과 같다.

  – 관리역량
  – 기술력
  – 의사소통력
  – 리더십

관리역량은 하루아침에 만들어지지 않는다. 물론 성향이나 내재적인 역량을 갖춘 사람도 있으나 보통은 학습과 경험을 통해 얻을 수 있다. 이에 따르는 많은 공부 또한 필요하다. 이는 기술력 못지않은 전문성도 필요로 하기에 실제 업무를 통해 하나둘 만들어가는 노력이 따라야 한다.

기술력은 프로젝트의 세부 활동을 지시하고 검증할 수 있는 역량이다. 전문지식을 보유하고 있으면 이해당사자들에게 보다 넓고 깊은 영향력을 행사할 수 있다. 이런 부분이 미흡할 경우에는 당연히 신뢰를 얻기가 어렵다. 물론 PM을 세분화해서 관리 PM이나 기술 PM 등으로 나눌 수도 있지만 이건 그런 환경이 될만한 프로젝트가 아니고서야 꿈도 꿀 수 없다.

성공의 소통이다. 일이 어렵고 쉽고를 떠나 결국 일은 사람이 해내는 것이다. 무엇이 되었던 서로 얼굴을 마주하고 문제를 해결해 나갈 수 있는 서로 간의 영향력이 중요하다.

마지막으로 리더십이다. 관리자라 관리만 하면 되지 무슨 리더십이 뭐냐고 할 수도 있지만 PM은 관리를 기반한 리더이다. 그래서 리더의 역량 또한 가져야 한다. 수많은 가정하에 유연함을 무기로 How가 아닌 What에 집중하면서 책임지는 솔선수범의 자세를 경주한다면 약간은 모자라더라도 PM을 역할을 충분히 해낼 수 있다.

 

※ 어떻게 한번 해볼래?
연차가 쌓이고 직위가 올라가면 한 번쯤 받아보는 자리. 선택의 여지가 주어질 수도 있지만 대부분은 지명을 통해 앉게 되는 그 자리. 왕의 자리까지는 아니지만도 그 무게를 견뎌내야 하는 것은 익히 봐와서 안다. 그래서 도망가고 싶어진다. 난 못할 것 같다. 큰일이 나면 어떨까 싶다. 밥맛이 없어지고 머리가 하나둘 빠진다. 어서 이 프로젝트가 끝나길 기다리지만 달리 생각하면 이때가 아니면 언제 해볼 수 있을까 하는, 기회가 주어짐에 감사하게 된다. 그래서 버틸 힘이 되나 보다. 이 세상 모든 PM 들 파이팅!!!