기대효과 분명히 하고 예산, 조직체계의 원칙을 지켜라

시작이 반이라고 한다. IT프로젝트 역시 시작 단계 즉, 프로젝트를 수행할만한 자격과 능력을 갖춘 SI사업자를 잘 선정하여 최적의 조건으로 계약을 체결하는 것이 성공에서 가장 중요한 요소이다.

하지만 현실적으로 이러한 과정은 순탄하게 진행되지 않는 경우가 많다. 업체를 선정한 다음에도 정작 계약에 이르기까지의 과정이 너무 복잡하고 시간을 많이 소요하는 경우도 많다.

IT프로젝트에서 SI 사업자와의 계약은 대개 △프로젝트 준비 △SI업체 선정 △우선협상 △계약 체결 등의 단계를 거치게 된다. 일단 프로젝트 준비에서 고려할 사항부터 살펴보자.

프로젝트 준비 단계에서는 프로젝트의 기대효과를 명확하게 하고, 예상 견적을 뽑으며, 프로젝트 조직체계를 구상하고, SI업체를 선정하는 전략 등을 수립하게 된다.

SI업체 선정 단계에서는 업체 평가 기법을 비교하고, 평가 프로세스를 정립한다. 우선협상 단계에서는 협상 상대방에 대한 이해, 주요 점검항목 체크, 협상 프로세스 확립 등이 필요하다. 계약체결 단계에서는 주요 계약항목의 내용을 점검하고 사업수행계획서의 체크리스트를 작성해야 한다.

차세대시스템 프로젝트의 기대효과
이 기대 효과는 복합적이다. 따라서 단위 시스템의 특성에 따라 적합한 효과를 산출해내야 한다. 가령 컴플라이언스의 경우 반드시 구축해야 하는 시스템이기 때문에 기대효과가 불필요하거나 그다지 높지 않다.

운영시스템이나 ERP는 필요성이 높고 또 재무효과를 기대할 수 있는 시스템이며, CRM이나 BI는 절박한 필요성보다 장기적으로 비재무적 효과를 노리는 시스템이라고 할 수 있다.

프로젝트의 목표가 기대효과의 원천이라는 점에서 기대효과의 크기는 바로 프로젝트의 목표 수준과 현재 수준의 격차(gap)라고 표현할 수도 있을 것이다.

프로젝트 기대효과는 가급적 계량화해야 하며, 시작 시점에서 현재 수준을 측정하고, 진행 단계에서는 목표 달성도를 평가하고, 종료 시점에서는 결과를 평가해야 한다. 프로젝트가 준비, 분석, 설계, 구축, 운영 단계로 진전함에 따라 성과지표 설정과 목표수준 계량화 등의 작업이 병렬로 진행되어야 하는 것이다.

프로젝트 예산 견적
견적은 다양한 기법을 종합적으로 적용해서 산출해야 한다. 이 가운데 가장 바람직하지 않은 방식은 공급자에게 견적서를 요청하고 거기에 기초하여 예산을 산정하는 것이다. 프로젝트의 예산 견적은 철저하게 갑의 권한이자 책임이다.

그리고 을은 대부분 갑의 예산에 맞추어서 제안 내용을 조정해야 한다. 그런데도 공급자의 견적서에 근거하여 예산을 산정한다는 것은 갑의 고유한 책임과 권한을 스스로 팽개치는 행위라고 봐야 한다.

예산 견적 방식은 기능점수(Function Point) 산정 방식과 참조 방법론(Reference Method) 방식, 델파이 방법론(Delphi Method) 등이 많이 알려져 있다.

기능점수 방식은 사용자의 요구 기능을 파악하여 그 결과를 기초로 소프트웨어 규모를 추정하고 전체 예산 규모를 산정하는 방식이다. 이 방식은 비교적 정확한 예산 산정이 가능하다는 것이 장점이지만 프로젝트의 세부 내용까지 분석을 마친 뒤에야 적용 가능하다는 점에서 현실성이 떨어지는 편이다.

이 방식의 한계를 극복하는 대안으로는 미니 차세대(pre-PMO) 사업을 통해 예산규모를 산정하는 방식을 적용할 수 있다.

참조 방법론 방식은 과거의 비슷한 프로젝트 비용의 평균값을 찾고 이를 근거로 프로젝트 예산을 산정하는 방식이다. 이 방식은 상대적으로 정확한 예산 산정이 가능하지만, 다른 프로젝트와의 유사성 외에도 고유한 특성과 차별성도 예산 산정에 주의깊게 반영할 필요가 있다.

비슷한 사례가 있어야 적용이 가능하기 때문에 후발 사업자들에게 유리한 방식이기도 하다. 이 방식은 또 SI업체와의 가격협상에도 유리한 자료를 제공해주며 경영진을 설득할 수 있는 근거자료로도 매우 유용하다.

델파이 방법론 방식은 전문가의 브레인스토밍을 통해서 사업 예산을 추정하는 방식이다. 이 방식은 어느 정도 객관적인 예산을 산정할 수 있지만, 논의 과정에 참가한 전문가들의 역량에 따라 오차가 생길 가능성이 크다는 문제점이 있다.

이 방식을 활용할 경우 단계별로 보다 결론을 정련하는 한편, 보조적인 방법도 적용할 필요가 있다. 사업자로부터 사전 견적서를 받아서 비교 참조하는 방식도 고려할 수 있다.

프로젝트 조직체계
프로젝트의 조직체계는 갑의 관리 역량에 따라 적합한 조직 형태를 선택하는 것이 좋다. 확실한 것은 어떤 조직 형태를 선택하더라도 프로젝트에서 PMO의 독립성과 객관성은 반드시 존중되고 유지되어야 한다는 점이다. 프로젝트 규모가 크고 복잡할수록 PMO의 역할은 더욱 중요해진다는 사실을 잊으면 안된다.

일반적으로 프로젝트 조직체계는 여섯 가지 정도로 구분한다.

즉 1)가장 일반적인 조직 형태로, 갑이 SI사업자와 PMO를 등거리에 두고 전체를 총괄하는 방식
2)SI사업자가 PMO 조직을 흡수 포괄하는 형태. 이것은 그룹 IT계열사가 규모가 크고 갑이 제대로 프로젝트를 관장하는 데 한계를 느끼는 경우에 많이 채용한다.
3)갑이 PMO를 직접 자신의 조직 안에 흡수하고 SI사업자를 직접 통솔하는 형태. 이것은 갑이 대형 IT조직을 보유한 경우에 많이 사용한다.

4)는 1)의 수정 형태로 그룹 IT회사가 PMO 조직을 포괄하고 갑이 SI사업자와 그룹IT 회사를 함께 통제하는 방식이다.

5)PMO와 그룹 IT계열사가 나란히 갑의 지휘 통제를 받으며 SI사업자는 그룹 IT 계열사 산하에서 지휘를 받는 형태. 이 경우는 그룹 IT계열사의 규모가 큰 경우에 많이 발견되는데, SI 사업자의 책임소재가 불분명해진다는 단점이 있다.

6)갑이 PMO와 SI사업자를 나란히 지휘 통제하며 SI사업자가 그룹 IT계열사를 지휘하는 방식. 이것은 그룹 IT계열사의 조직이 작은 경우에 많이 나타나며 내용상으로는 1)안과 비슷하다고 할 수 있다.