by
Feb 28. 2022
PM컨버팅 Part3 : #43 트러블
#43 트러블
팀을 운영하다 보면 트러블은 필연적이다. 트러블은 순기능과 역기능이 있다. 순기능은 서로간에 생기는 트러블을 해결해가면서 좀 더 단단한 팀웍을 갖춘 조직으로 발전할 수 있다는 점이다. 그러나 그 트러블을 적당한 시기에 해결하지 못하면 그 트러블로 인하여 팀이 해체되는 경우도 발생되고, 프로젝트의 경우 인원의 결원으로 납기와 품질에 큰 영향을 끼칠 수도 있다.
리더의 입장에서 팀원간의 트러블 또는 리더와 팀원의 트러블에는 적극적으로 개입을 하여야 한다. 이러한 트러블은 필수적으로 관리가 되어야 한다.
그러나 리더가 관리할 수 없는 트러블이 있다. 이 트러블은 팀원과 팀원의 트러블이 아니라 프로세스 또는 조직문화와 리더와의 트러블이다.
이편에서는 리더와 프로세스와 관련된 트러블에 대하여 다뤄보고자한다.
리더와 조직문화 또는 프로세스와 관련된 트러블은 항상 존재하고 리더는 힘든 외부고객만 상대하는게 아니라 프로젝트에 대한 이해도가 극히 낮은 수많은 내부조직원과도 많은 소통을 해야한다. 이들은 리더가 쓰는 용어에 대한 개념도 없을 것이고, 이 업에는 상식으로 통하는 모든 것에 대한 설명을 요구할 것이다. 특히 재무파트 그리고 C-Level 들과 트러블은 필연적이고 대표이사와의 소통부재는 프로젝트 입장에선 치명적이다.
SI를 주업으로 하는 대기업이나 중견기업에서는 사실 이러한 트러블이 생길 요소가 극히적다. 왜냐하면 조직문화가 프로젝트 수행에 최적화되어있고, 재무회계, 관리 그리고 지원조직도 프로젝트에 최적화된 문화를 갖추고 있어서 현장에서 일어나는 많은 일들에 대하여 큰 무리없이 지원과 관리를 받을 수 있다. 그러나 이제 막 공공사업 즉 SI나 ITO에 뛰어든 기업이라면 어찌보면 리더가 하나하나 길을 만들어가면서 프로젝트를 해야하는 어려움에 봉착할 가능성이 매우 높다.
하나하나 정리해보면 우선 리더의 입장에서 C-Level에 전폭적인 신뢰하에서 프로젝트를 수행하기 쉽지않다. 그리고 임원들과는 리소스와 권한에 대한 문제, 자금쪽과 원활한 자금집행의 어려움이 있을 것이다. 영업과는 R&R의 정의에 문제가 있을 것이다. 내부에서 온 즉 외부프로젝트 경험이 없는 개발자 팀원과는 소통에 대한 문제가 있을 것이다. 프로젝트를 수행하는 리더의 입장에선 최악의 상황에서 프로젝트를 수행하여야 한다. 그러나 이러한 상황은 꽤 자주 여러 회사와 다양한 조직에서 항상 존재하는 문제이다.
우선 밑에서 부터 하나하나 해결해 나가보자.
대외 프로젝트 또는 이런 팀 플레이 자체가 생소한 개발자들과는 가장 먼저 용어사전 부터 정리해야 한다. 그리고 개발자들 모두와 합의를 거쳐 개발툴, 표준 프레임워크, 배치 방법, 테스트 방법, 개발환경 셋팅 등등 개발과 관련된 제반사항과 방법론 그리고 각종 프로세스에 대하여 모두 동의하는 합의를 거쳐야 한다. 예전 프로젝트에서 개발경험이 없는 개발자와 일을 했는데 내 역할은 PMO였는데 그 개발자는 PMO를 PM으로 인식을 하고 있었다. 용어사전을 만들어서 배포하고 이슈가 있을떄 마다 업데이트해서 관리하면 된다.
이때에는 업무를 늘리면 안된다, 항상 모여서 이야기하는 모든것들이 숙지되거나 암기되지 않는다. 산출물도 최소화 시켜야 된다. 처음부터 타이트하게 또는 깊게 모든 것을 정의하면 오히려 이러한 요건들이 진도에 발목을 잡게한다
이러한 요건들은 업무를 하면서 수시로 이슈가 있을때마다 바로잡아 나아가면 된다. 그러나 자주 체크를 해야한다,
임원 또는 대표이사와의 관계이다. 프로젝트의 어느 단계에서 PM 또는 PO가 관여했냐에 따라서 트러블 요소들이 차이가 있다. 만약 임원 및 대표이사가 발굴한 프로젝트이고 수주가 된 프로젝트라며 PM이나 PO가 그 이후 시점에 투입이 된다고 하면 사실 임원과 대표이사와는 프로젝트와 관련하여 조직문화 관점에서는 큰 문제가 없을 것이다. 다만 고객이 PM이나 PO를 배제하고 바로 임원이나 대표이사에게 민원을 제기할 경우에는 이야기가 달라진다. 여기에서 고객만족도와 관련된 트러블이 발생한다. PM의 입장에서는 납기와 손익과 품질 모두를 지켜야하지만 임원이나 대표이사의 경우에는 고객만족도에 가장 높은 배점을 둔다. PM의 입장에선 납기와 손익을 지키기 위하여 고객과 수 많은 밀당과 수싸움을 하여야 하는데, 경험이 풍부한 고객은 PM을 배제하고 바로 대표이사에게 전화해서 해결하려고 하는 꼼수를 쓰기도 한다, 사실 대표임장에선 고객의 이런 전화를 무시하기가 쉽지 않다. PM이나 PO의 입장에선 참 난감한 경우이다. 고객과의 신뢰도 잃을 수 있고, 임원이나 대표에게 문제가 있는 프로젝트란 인식을 심어주고 최악의 경우 무능한 PM으로 찍히기도 한다. 경험상 이러한 문제가 가장 빈번히 이루어진다. 그리고 이러한 문제를 해결하기는 의외로 수월하다. 우선 정기적으로 본사에 회의를 하여야 하고, 회의를 통해서 프로젝트의 다양한 이슈 및 리스크가 경영진에 보고를 통한 인식과 해결방안에 대한 공감대가 이루어져어야 한다. 사실 프로젝트를 하다보면 고객이 어떻게 움직일지 대부분 예측이 된다, 그 예측이 가능한 상황을 정기적으로 경영진과 정보공유가 되고 필요하면 솔루션까지 제공할 수 있는 수준까지 보고를 통하여 경영진이 사전에 대응할 수 있는 준비를 갖추어 놓아야 한다.
두번째로 리소스문제이다. 프로젝트를 진행하다보면 추가적인 인적 비용적 리소스가 투입될 수 있다. 프로젝트 수행전 VRB를 통하여 사전에 소요되는 예산에 대하여 보고와 확인을 거친 이후 손익에 대한 마진율을 통하여 경영진의 프로젝트 수행여부를 의사결정 받는 절차가 있지만, 프로젝트를 수행하다보면 예측하지 못한 수 많은 비용지출 요건들이 생긴다. 작은 것은 커피값 인쇄비 부터 크게는 추가 인건비까지 아무리 경험이 많은 PM도 이부분은 피해가기가 쉽지 않다, 이 부분을 해결하기 위하여서는 완충비용을 만들어 놓는 것이다. 예를 들어 회사의 목표 마진이 10%라고 하면 완충경비를 3~5% 정도 책정을 하고, 직접경비나 외주 용역비에서 충분한 여분한 리소스를 배치해 놓는 것이다. 여기에서 핵심은 이런 자금 집행을 변경할 수 있는 변경프로세스가 있어야 하고, 경영진은 이러한 변경요건에 대하여 열린마음을 가지고 있어야 한다, 그리고 상호간의 합의가 된다면 프로젝트 종료 시 정산을 통하여 남는 완충비용의 일부를 성과급 또는 인센티브로 프로젝트 팀원들에게 주는 방법도 함께 고려가 된다면 더욱 좋다.
경영관리에서는 긴급하게 올라오는 PM의 요청에 대응할 수 있는 프로세스가 있을 수 있다라는 것에 대한 사전인식이 있어야 한다. 예를 들어 정상적인 프로세스라면 5일이 걸리는 프로세스를 긴급하게 하루나 이틀사이에 집행을 해야하는 경우가 종종 발생한다, 물론 이런 프로세스는 대표이사나 임원의 승인이 있어야 한다,라는 전제를 두고 긴급하게 업무처리가 가능해야 한다,
끝으로 회사나 경영진에서는 프로젝트를 모니터링 할 수 있는 방법을 최대 3가지 정도는 가지고 있어야 한다. 첫째가 PM이나 PL의 보고체계이고 두번째가 영업을 또는 고객과 친밀한 임원을 통한 정기적인 프로젝트에 대한 VOC 청취이고 끝으로 프로젝트 자체를 관리하기 위한 PMO제도이다, 프로젝트는 PM이 수행하는게 아니라 회사가 수행하는 것이다. 프로젝트가 망가져서 팀이 깨지고 PM은 퇴사하면 되지만 그 데미지는 최종적으로 회사가 입는 것임을 명심해야 한다. 최악의 경우 부정당이나 지체산금을 물게 되면 회사는 더이상 외부 프로젝트를 할 수 없다.
프로젝트의 트러블 요소는 정말 많고 다양하다, 그러나 핵심은 그 트러블에 대한 상호간의 공감대형성과 이해가 전제되어야 한다는 것이다. 프로젝트에 가장 중요한 것은 결국 소통이다.
지금 읽으신 글은 책으로 출판되어 있습니다.
내일부터 Project Manager가 되어야 한다.
