IT 프로젝트 관리 (2) - 현실 세계속

 

어디까지나 개인의 경험에 의한 일반화이므로, 모든 외국계 회사가 이렇지는 않다는 점 이해 부탁드립니다.

현재 회사 분위기는?

우선 이해를 돕기 위해 다니고 있는 회사에 대해 간단히 이야기하겠다. 

 

현 회사는 자체 브랜드를 보유하고 있는 도소매/유통 회사로 글로벌과 로컬 인지도를 모두 가지고 있다.

 

글로벌적으로는 대기업이나 한국지사 기준으로는 매출이 1조 정도라, 중견기업에 속한다. 참고로 대기업은 국내 매출 5조원 이상될 경우만 가능하다.

 

부서는 전체 약 10개 부서로 나뉘어져있고, 10개 부서장의 50%는 외국인 30%는 한국인, 20%는 공석이다. 곧 공석인 자리도 외국인이 뽑힐 가능성이 아주 높다. 

한국 지사 IT 프로젝트 유형

 

10개 부서 중 하나가 바로 IT팀인데, 영업과 마케팅 부서와 같이 고객 앞단에 나서는 부서가 아닌 '지원부서 및 파트너'로 일을 한다.

 

이런 기업의 한국 지사 IT팀은 '비지니스 솔루션 파트너' 라는 포지션으로 각 부서의 업무를 지원하고, 프로젝트가 생겨도 비지니스 부서가 오너인 프로젝트에 참여할 가능성이 높다. 

 

회사 주 판매종목이 'IT솔루션'이 아닌 이상, IT팀은 기존 솔루션의 운영업무와 로컬, 글로벌 프로젝트 지원업무를 주로 맡게 된다. 

 

이번 글의 주제는 프로젝트 관리 방법론이니, '로컬/글로벌 프로젝트 지원업무'에 집중해보자.

 

한국지사 IT가 경험할 수 있는 프로젝트는 흔히 다음과 같다.

• 기존 사용하고 있던 로컬 어플리케이션이 글로벌 어플리케이션으로 전환되는 경우 /글로벌 니즈로 한국 지사로 목표가 내려오는 케이스/

• 한국 파트너사들(백화점, 대형 총판 등) 의 요청으로 기존 어플리케이션과 연동을 해야 되는 경우  /로컬 니즈로 글로벌 본사로 요청이 되야 하는 케이스/
  
  

• 글로벌 솔루션으로 대체하기 힘들고,  로컬 어플리케이션을 도입하는 경우 /로컬 니즈로 글로벌 본사로 요청이 되야 하는 케이스/

• 국내 법 규정 변경으로 빠르게 기존 어플리케이션에 적용이 필요한 경우 /로컬 니즈로 글로벌 본사로 요청이 되야 하는 케이스/

• 매장 및 사무실 인프라 정책 변경으로 하드웨어 교체가 전체적으로 필요한 경우 /글로벌 니즈로 한국지사로 목표가 내려오는 케이스/

 

 

3번째 파란색 케이스를 제외하면, 나머지는 글로벌 어플리케이션을 사용하고 전환하는 작업이라 보면 된다. 3번째 케이스는 정말 희귀한 케이스로, 본사 정책 상으로도 꺼리는 옵션 중 하나다.  보통 국내 노동법 문제로 억지로 해야 되는 경우는 제외하고는, 가급적 로컬 솔루션으로 가지 않는다. 

 

따라서, 글로벌 본사 주도하에 한국 지사 IT팀이 프로젝트를 서포트 하는 방향으로 가는데, 이때 글로벌 프로젝트 리더는 글로벌 본사 담당자가 하게 된다. 한국 지사 IT팀은 로컬 IT PM 역할을 주로 하게 된다.  

 

 

프로젝트 조직 구조

 

공통적인 프로젝트 조직 구조. 하위 지원 부서는 N개이다.

 

글로벌 본사와 로컬 지사가 같이 프로젝트를 하면 공통적으로 세팅되는 프로젝트 조직 구조이다. 

 

글로벌 솔루션이 한국 지사로 도입되는 경우, 

 

'글로벌 프로젝트'로 분류되고 글로벌 프로젝트 리더 및 관련 팀들이 세팅된다.  또한 이 프로젝트 팀들과 협조하여 한국 지사의 요구사항을 인풋(Input) 하고 도입 지원을 같이 할 로컬 프로젝트 팀 세팅이 후속적으로 진행된다. 

 

 

펀딩하는 조직이 어디냐에 따라, 상위 조직의 입김이 달라질 수 있는데 보통 이런 프로젝트는 글로벌 펀딩으로 진행된다.

 

글로벌 펀딩, 글로벌 프로젝트 리더로 진행되는 프로젝트는 이미 프로젝트 방법론이 세팅된 채로 온다.

 

프로젝트 킥오프 미팅 (프로젝트의 시작을 공식적으로 각 프로젝트 멤버들과 관련자들에게 알리고, 향후 계획을 설명하는 미팅) 때 프로젝트 방법론까지 같이 설명하는 편이다.

 

 

프로젝트 진행 방식 

글로벌 프로젝트의 경우, 로컬 지사 니즈와 상황을 사전 파악하는 Pre assessment (사전 분석) 단계가 있다. 

 

예를 들어 ERP 솔루션을 한국 지사에 도입하고자 할 경우, 현재 사용하는 시스템, 사용자 수, 유지보수 비용, 로컬 상위 매니저의 사전 동의, 프로젝트 펀딩 관련 논의를 먼저 한다. 

 

대략 프로젝트 비용이 얼마이다 가 계산이 나오면, ROI 분석 및 왜 이 프로젝트를 진행해야 되는지에 대한 글로벌 상위 레벨 임원급들을 위한 자료를 준비하고 펀딩 요청을 진행한다. 

 

보통 펀딩 요청 미팅은 정기적인 임원급 미팅을 통해 보고 되고, 펀딩에 대한 승인이 이루어진다. 펀딩이 어렵지, 이후 프로젝트 시작까지는 일사천리에 가깝다.

 

글로벌 프로젝트 리더와 글로벌 조직이 사전 셋업되고, 이후 글로벌 킥오프 미팅 , 이후 로컬 마켓 킥오프 미팅을 하면 프로젝트가 본격적으로 시작된다. 

 

분석(Analysis) 단계에서는 글로벌이 이미 가지고 있는 스탠다드 템플릿 기준으로 로컬 지사의 업무가 어디까지 수용 가능한지 분석한다. 분석 후 나오는 GAP (갭. 현실과의 차이)을 가지고 글로벌 솔루션의 변경을 할지, 로컬 지사의 업무 프로세스를 변경할지 등 세부적인 논의가 나온다. 이때 로컬 지사의 요구사항이 글로벌에 잘 전달 되지 않으면, 상당히 불편한 상황이 연출된다. (시스템 Go-live 후 사용자에게 엄청 욕을 먹는 시스템이 된다)

 

분석이 완료되면 비지니스 팀 요구사항을 확정짓는 Business Requirement Sign-off 단계가 이뤄지고 Sign off된 내용 기반으로 설계가 들어간다. 

 

설계(Design) 단계는 글로벌 아키텍트가 글로벌 솔루션의 상황과 비지니스의 요구사항에 맞춰 전체적인 디자인을 하고, 글로벌 솔루션의 기존 디자인을 크게 해치지 않는 선에서 진행한다. 

 

설계를 완료하면, 이후 각 업무를 단위별로 세부적으로 쪼개어 프로젝트 작업 리스트에 등록을 하고, (보통 프로젝트 관리 툴을 활용하여 작업 리스트를 관리하고, 진척을 확인한다) 개발을 진행한다.

 

개발(Development) 단계는 개발자가 본격적으로 할당된 작업을 시작한다. 기능 단위가 하나씩 완성될 때마다 진척 상태를 업데이트하고 개발 리더와 프로젝트 리더는 그 진척을 매일, 매주 확인 가능하다. 

 

개발자 테스트가 완료된 기능 단위는 프로젝트 방법론에 따라 사용자 테스트 시작 시점이 다른데, 위터폴 프로젝트 방식이면 개발이 다 완료된 후 사용자 테스트가 진행되고, 애자일 프로젝트 방식이면 기능 단위가 완성될 때마다 그룹으로 묶어 사용자 테스트가 일찍 진행된다. 

 

테스트까지 완료되어, 로컬팀 확인까지 다 되면 프로젝트 GO / NO GO 결정이 되고, 이후 시스템 운영 오픈 및 안정화 작업이 진행된다. 

 

이 방식은 위터폴이냐 애자일이냐에 따라 사이클이 다르고, 단계가 조금씩 다를 수 있지만, 지사의 솔루션을 새로 도입하는 프로젝트는 위 방식을 따르는 편이다.

 

 

애자일 프로젝트 방법론으로 변화하고 있는 중 

불과 3년 전만 해도, 워터폴 프로젝트 방식으로 진행 했었다.

그러나 최근에는 '애자일' 이라는 이름을 내세워 프로젝트가 진행되고 있다. 이미 글로벌 조직이 애자일 형식으로 변화되었고 글로벌 솔루션을 그들의 제품 (Product)로 인식하여 Product owner를 내세우고 더 좋은 제품을 만들기 위해 회사 목표를 세우고 팀을 움직이고 있기 때문이다. 

 

이미 각 지사들의 솔루션 도입이 완료된 상태에서는 애자일 프로젝트 방법이 유효할 수 있겠다. 그러나 지사 솔루션을 처음 도입하는 프로젝트의 경우 애자일 방법론이 잘 맞지 않는 현실적인 문제에 종종 마주치곤 한다. 

 

다음에는 경험 위주로, 어떤 현실적인 문제에 부딪치는지 이야기해보겠다.