brunch

You can make anything
by writing

C.S.Lewis

by 정재헌 Jun 04. 2020

PM 컨버팅 #31 : 회사편(3/4)

#31 프로젝트 리더 또는 대표가 준비할 사항

프로젝트를 회사 차원에서 왜? 하는가란 질문에 돈을 벌기 위해 한다라고 하면 제일 어리석은 답 일 것이다. SI 관련 프로세스와 좋은 인력들을 보유하고 있는 대기업 및 중견기업의 손익을 보면 대부분 한 자릿수 정도 수준이다. 중소기업이 그 이상의 손익을 볼 수 있는 사례를 별로 보지 못했다. 손해를 안 보면 오히려 다행이다.


그럼 IT 중소기업 또는 SW개발사가 공공 SI에 뛰어드는 사례는 무엇일까?


첫 번째. 자사의 개발 루션의 시장 확대

자사에서 만든 제품을 민간 또는 제조분야에 설치 및 서비스가 되고 있는 제품을 공공에서도 그 제품 또는 서비스를 사용하게 하고 싶은 경우


두 번째. 자사의 개발 루션의 고도화

자사에서 개발한 핵심 엔진이 있는데, 공공사업을 하면서 그 설루션 및 제품을 고도화하고 싶은 경우


세 번째. 회사의 매출 증대를 위하여 SI사업을 수주

어느 정도 규모 및 안정성이 있는 회사에서 회사의 대외적인 매출 증대를 위하여 SI 사업을 수주하여 수행


네 번째. 회사의 생존을 위한 SI

단지 회사의 생존을 위하여 개발인력을 운영하면서 공공정보화 사업을 수행




SI를 처음 경험하게 되는 조직의 경우 대표이사 또는 SI를 총괄하는 임원이 할 일 중 가장 중요한 일은 공감대 형성이다. 처음부터 SI를 했던 회사나 조직의 경우 이런 과정이 거의 필요치 않지만, 신규로 SI사업에 진출하고자 하는 조직이나 회사의 경우 이 과정이 필수적으로 선행이 되어야 한다.


그럼 SI를 총괄하는 리더의 입장에서 무엇을 준비하여야 하는가.


첫번째. SI 선언을 해야한다. 그리고 가장먼저 영업대표와 PM을 정한다.

우리회사 또는 우리조직은 앞으로 SI를 한다. 그리고 SI를 수행하는 조직을 분리하여야 하고, PM을 하는 인력 또는 프로젝트 수주를 담당하는 영업대표 또는 PM에게 모든 권한을 주어야 한다. 여기에서 이야기하는 권한은 타겟 프로젝트를 정하고, 제안팀원을 셋팅하고 수행조직을 결정하는 권한을 일임하여야 한다. 그러나 제안서를 제출할지 말지하고 금액을 투찰하는 권한은 조직이나 회사내부에 체계적인 원가검증 프로세스를 갖추고, 내부협의를 거쳐서 의사결정하는 체계를 갖추어야 한다.


두번째. SI전문조직 또는 팀을 만들어야 한다.

기존 회사의 개발자나 기획자들 특히 SI를 해보지 않은 직원들을 SI에 투입하면 그 직원들은 그 프로젝트 도중 퇴사를 마음먹는 경우가 부지기수다. 물론 한두번은 직원들의 동의하에 프로젝트에 나가겠지만 지속적으로 SI를 원하지 않는 직원을 SI에 내보낸다고 하면, 그건 결국 그 직원은 퇴사를 하게 된다.


우선 팀을 빌딩한다. SI를 했던 인력 또는 SI를 원하는 인력, 조직에서 SI를 원하는 인력을 만들고자 하면은 별도의 인센티브 전략을 만들어서 프로젝트에 나갈경우 급여의 인상, 교통비 증액, 체재비 등을 주는 프로세스를 만들어서 기존 조직과 SI를 하는 조직의 차별화를 두어야 한다.


세번째. SI지원조직 또는 지원팀을 만들어야 한다.

전체 인력을 풀로 투입하는 프로젝트도 있지만 예를 들면 디자이너가 프로젝트 전기간에 투입할 필요가 없고, 특정기간에만 투입하는 경우, 인프라 엔지니어가 개발 인프라와 운영 인프라 구성 단계에만 투입되면 되듯이 특정업무와 특정시기에만 지원하는 팀을 만들어서 SI 전문조직을 지원하여야 한다. 이 인력들은 내부업무도 하면서 대외업무도 함께 수행하는 조직으로 운영을 하면 된다.


 네번째. 조직의 프로세스를 바꾸어야 한다.

SI를 할려면 손익관리와 구매관리프로세스가 회사에 있어야 한다. 손익관리는 제안부터 프로젝트 종료까지 이루어지는 모든 경비를 PM과 사업관리 그리고 회사의 재무담당과 임원진 모두 공유를 할 수 있는 프로세스를 갖추어야 하며, 구매관리 프로세스를 갖추어서 프로젝트에 들어가는 각종 비용을 합리적이고 체계적으로 관리할 수 있어야 한다.


다섯번째. 사업모니터링 프로세스가 있어야 한다.

SI프로젝트에는 많은 위험요소가 있고, 그 위험요소를 체계적으로 관리할 수 있어야 한다. 그러나 많은 경우 그 위험요인을 프로젝트 팀 내부에서 해결할려고 하고, 해결이 되면 문제가 안되지만 해결을 못하면 프로젝트 손익에 문제가 생긴다.  프로젝트에서 발생되는 많은 위험요소나 리스크한 부분들은 문제 초기단계부터 회사에 공유가 되어야 하고 관리가 되어야 한다. 이런 역할은 조직의 리더가 고객을 지속적으로 만나서 청취할 수 있고, 영업대표가 확인할 수 있다. 가장 좋은 것은 PM이 정기적으로 보고를 하고 조직에서 이슈들을 체계적으로 관리하는 것이 가장 좋다.


조직에 이런 프로세스가 없으면 프로젝트에 나가 있는 PM과 팀원들은 마치 무인도에 갖쳐있다라는 고립된 감정을 가질 수 밖에 없다. 프로젝트는 PM과 팀원이 하는게 하니라 회사 전체가 하는 것이다.



지금 읽으신 글은 책으로 출판되어 있습니다.

내일부터 Project Manager가 되어야 한다.

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&linkClass=130509&barcode=9791165457037

http://www.yes24.com/Product/Goods/108921595




매거진의 이전글 PM 컨버팅 #30 : 회사편(2/4)
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari