SI 프로젝트에서 성공이란

  SI 프로젝이 시작되면 제일 먼저 팀들에게 교육하는 게 있다. 그 중에 프로젝트의 성공 기준은 어떤 것인가를 장표 하나 분량으로 설명하는데 다음과 같다.

  

완벽한 성공

 일정이 앞서가고, 예산보다 적게 사용, 모든 사람의 기대보다 초과된 성과

 

매우 성공적임

​범위에 맞춰 정해진 일정 및 예산 내에 완료

 

성공적임

​목표한 일정에 완료했으나 스펙을 만족시키기 위해 재작업이 요구되며, 이로 인해 이익에 영향을 미침

 

성공적이지 못함

​약간의 목표 일정 지연과 고객이 만족하지 못함

 

부분적 실패

​늦은 일정과 예산 초과, 산출물이 받아들여지지 않음

 

완전한 실패

​목표를 완료하지 못하고, 수익을 얻지 못하며, 그것이 , 치명적인 이슈가 됨

 

 

​  여기서 보면 성공의 기준은 일정 내에 검수를 받느냐가 기준임을 알 수 있다. 적어도 표면상 지체가 일어나지 않아야 한다는 뜻일 게다. 하지만 진짜 기준은 이게 아니라고 생각한다. SI 프로젝의 성공은 그 무엇보다 고객의 만족이어야 한다. 다시 말해 고객이 원하는 대로 결과물이 나왔는가 이다.

매우 간단한 표현인 것 같지만 사실 이면에는 매우 어려운 내용이 자리 잡고 있다. 전에 언급했지만 고객은 자기들이 발주를 냈지만 사실 스스로 무엇을 원하는지 즉, 요구사항을 정확히 알지 못한다. 그들은 추상적인 아이디어 - 물론 이 아이디어도 누군가 최초 생각한 사람이나 기관이 있겠지만 대부분은 베끼는 것이다. 베낀 것이니 좀 더 구체적으로 세분화할 필요가 있다. 따라서 고객들은 돈을 들여 본격적인 개발에 들어가기 앞서 ISP 나 컨설팅 용역을 실시한다.

 

  그리고 그 결과를 토대로 RFI 와 RFP를 작성하여 개발을 진행한다. 사실 이제부터는 '운'이라고 생각한다. 컨설턴트들은 이론적 또는  템플릿에 맞춰 그림은 훌륭하게 그렸지만 그게 타당한지, 어떻게 진행해야 되는지, 전제조건은 무엇인지? 리포팅하지 않는다. 그러니 막상 개발을 진행할 때 다행히도 큰 문제가 없으면 서로가 좋은 것이니 '운'발이 아니겠는가. 그렇지 않을 경우, 수행팀은 개고생이 시작된다.

일단 컨설팅 결과와 실제 개발에 있어 맞지 않는 부분, 조사가 빠진 부분, 검증하지 않아 새로 도출되는 이슈 등을 개발팀에게 요구하게 된다. 졸지에 기능정의하고 화면과 DB 설계를 하는 이들에게 엔지니어링 업무를 강요하게 되는 것이다.

결과는 뻔하다. 기간 내에 끝내는 즉, 성공적인 프로젝트가 되기 위해 실제 이루어야할 목표와는 상관없는 프로젝트가 되어 버리는 것이다. 아까운 국고만 낭비하게 된다.

이렇게 되는 이유는 크게 세 가지로 나눠 볼 수 있다.

 

 

  우선 컨설팅 내용이 너무나 획일적이고 고객이 같이 참여하지 않는다. 그리고 그 대상에 따라 어떤 인력이 구현해야 하는지 어떤 전제조건이 성립되어야 하는지 필수적으로 해야 할 사전 작업으로 무엇이 있는지 등 기관에서 사업을 진행할 수 있는 구체적인 가이드를 제시해야 한다.

 

  두 번째로 왜 ISP 나 컨설팅은 A/S 가 없는지 모르겠다. SI 개발은 사업이 종료된 후 하자에 대하여 무상 유지보수를 1년간 보증하거나 요구한다. 컨설팅도 마찬가지로 빠진 부분이나 수정, 보완해야할 리포팅이 있을 수 있다. 이에 대해 A/S를 요구하거나 보장해야 하는 것 아닌가? 그들은 개발자보다 급여나 비용도 훨씬 많이 받는다.

 

  마지막으로 고객의 철저한 검증이 필요하다. ISP 의 경우 로드맵과 대략적인 비용만 나오면 대부분 받아들여진다. 컨설팅도 저명한 연구기관이나, 교수, 해외 사례가 붙으면 별로 따지지 않고 넘어가는 것 같다. 물론 일반적이거나 전혀 엉뚱한 추측일 수도 있겠지만 SI 프로젝을 진행하다 이런 이슈에 부딪히는 경우가 그렇다는 얘기다. 비용도 더 많이 지출한 그들은 대충 또는 누락한 내용을 그 부분에 전문가도 아닌 개발자에게 강요당하는 것이다.

 

  이런 프로젝은 사실 보나마나가 되는 것이다. 기간 내에 완료는 되어 검수는 받을 지 모르겠으나 근본적 의미의 완료가 된 것이 아니기 때문에 성공한 프로젝이 아닌 것이다.