SI 프로젝트가 계획대로 되지않는 이유

프로젝트 관리에 있어 제일 중요한 것이 뭐냐고 묻는 다면 나는 '계획'이라고 확신한다. 프로젝트가 실패하는 가장 주된 원인이 뭐냐고 묻는다면 역시 '계획'이라고 생각한다. 그러면, SI 프로젝트에서 계획은 어떻게 세워지는지 그 긴 여정을 따라가 보자.

​

​

1. 프로젝트 계획을 잘 세우려면 '기획'을 잘 해야 한다.

​

왜냐하면 어찌된 영문인지 모르지만 기획단계에서 시작 날짜와 종료 날짜가 이미 정해지기 때문이다. 이는 시사하는 바가 매우 크다. 사실 수행팀은 일정에 대한 헤게모니를 갖고 있지 않다.

잘 아는 바와 같이 계획은 이미 RFP에 명시되어 있다. 즉. 일정, 품질, 결과물의 책임은 전적으로 - 분명히 얘기하는데 - 발주처의 기획자에게 있다. 그들이 요구사항과 일정과 품질 수준을 이미 기획단계에서 정하고 있지 않는가. SI 프로젝트에 일정이 잘 지켜지지 않는 원인은 처음 시작할 때 이미 결정나 있었던 것이다.

​

​

 

요구사항이나 그 과제의 위험성, 목적 등을 얼마나 치밀하게 기획하는냐에 그 프로젝트의 성패가 달려있다. 내가 경함한 대부분의 발주처 담당자, 위탁 운영자, 수행사 임원은 이 과정을 대충 떼운다. 아마 한 번도 그 책임을 묻거나 점검하지 않았고, 성공이나 실패도 확인하지 않았고, 그에 대한 책임도 묻지 않았으리라.

​

그래도 계획을 잘 세울 기회가 없는 건 아니다.

이런 부패(?)가 존재하는 이유는 수행사에게 전가해도 그들이 대체적으로 잘 해냈기 때문이다. SI 수행팀에게 '기획' 작업을 전가 시켜 다시 한번 기회를 만회하려고 한다.

​

2. 프로젝트 계획을 잘 세우려면 '요구사항'을 잘 도출해야 한다.

​

대충 작성된 RFP 요구사항을 보고, 발주처가 뭘 필요로 하는지 알아내는 것 쉽지않다. 자기들도 잘 모르고 있는데다, SI가 특징중 하나인 비가시성을 가지고 있어서다. 해당 업무 전문가가 아니면 잘 알지 못하면서 폼만 잡는 발주처 담당자가 무엇을 필요로 하는지 '요구'를 끄집어 내는 것부터 계획에 차질이 발생한다.

​

​

SI 프로젝트에서 사실 '요구사항'은 발주처가 명확히 해야하고 수행팀은 그에대해

무엇을 어떻게 개발해 줘야 하는지 '분석'을 해야 하는데, 프로젝트에 초기부터 뒷짐지고 있는 담당자에게 '그대가 요구하는게 이게 맞냐'는 확인 작업을 반복해서 하게 된다.

발주처 담당자는 내가 정확히 뭘 요구하는지는 모르지만 수행팀 니가 알아내서 분석자료를 가져 오면 '맞다' '아니다'는 말해 줄 수 있다. 돈을 주고 있으니 능력을 보여라. <= 이런 애티듀드인 것이다.

수행팀에 얼마나 업무 전문가나 경험자가 있는지에 따라서, 도출되는 요구사항이 다르다. 최악의 경우 수행팀의 수준에 따라 요구사항이 도출되고 최대 발주처 수준만큼 나온다. 적당히 불완전하게 도출된 요구사항을 가지고 설계를 진행하는데, 그 프로젝트가 잘 진행될리가 없다.

​

​

그동안 이렇게 위험하게 프로젝트를 진행했는데도, 지금껏 진행되어 온 것은 요구분석 단게를 지나 구현단계에서라도 요구사항이 완성되기도 했던 것이다. 이른바 '변경'이다. 요구사항이 변경되면, 많은 문제가 발생한다. 이 부분에 대해 할 말은 많지만 다음으로 자세히 다루도록 하겠다. 아무튼 일정에 영향을 주고 계획대로 되지 않는다.

​

그래도 계획을 잘 세울 기회는 여전히 남아 있는 시점이다. 수행팀이 이런 경험을 많이 해서, 대충 짐작으로 버퍼를 잡아 일정게획을 수립한다.

​

3. 프로젝트 계획을 잘 세우려면 WBS를 잘 만들어야 한다.

​

수행팀은 보통 WBS를 만들고 일정을 수립할 때, 개발자를 과대평가하지 않고는 해당 미션을 끝낼 수 없었다. 즉, 대충 했다. 굳이 핑계를 대자면, 전체 일정을 너무 빠른 시간에 WBS 를 포함하여 제출하는 것을 독촉 받는다. 분석이나 설계가 완료되지 않고 어떻게 명확한 WBS를 수립할 수 있단 말인가. 시작해서 2주안에 제출하는 사업수행계획서의 일정계획은 아예 무시하고, 프로젝트 진행 중 적어도 2번의 WBS 및 일정을 수립 또는 변경하는 계획을 가져가야 한다.

먼저 요구분석이 완료된 후 분석 결과에 따라 WBS를 만들어야 한다. WBS를 만들기 위해서는 먼저 그 일(Work)을 정의하는 사전(Work Dictionary)을 만들고, 기능 모듈별로 워크패키지(Work Package)를 나누고 세부 관리 항목을 정의해야 한다. 해야하는 일만큼이나 개발자, 소요기간, 선.후행 등도 매우 중요한 요소이다. WBS가 완성되면 PND(Project Network Diagram)를 작성한 후 일정 계획을 수립해야 한다.

 

 

정확하게 일감을 정의하고, 그 일감 간의 관계를 정립하고, 그 순서에 따라 일감에 다른 소요기간을 감안하여 일정을 세우면 거의 완벽한 일정이 될 것이다. 여기에 감안해야할 복병이 있다. 프로젝트 전체 기간이다. 완료해야할 기간이 있는데, 앞의 방법 대로 했더니, 정해진 기간을 넘어간다면 문제아닌가.

이게 바로 '위험'이다. 이를 해결할 방법을 찾아야 한다. 만약 그러지 않고 늘 하던 방식대로 그냥 완료일로 부터 역산하여, 전개, 통합테스트 기간을 정하고 남은 기간에 개발을 그냥 분배 시켜 버린다면, 계획대로 되지 못할 것이다. 한정된 자원에서 달성할 수 있는 최선의 방향과 방법을 논의로 이끌어내는 것이 아니라, '까라면 까'. '그냥 시키는대로 해' 라는 구태방식으로는 전혀 해결 될 수 없다.

​

​

그래도 계획을 잘 세울 기회는 실날 같지만 남아 있는 시점이다.

설계가 끝나면 가장 정확한 WBS가 나온다. 이 때 일정을 다시 한번 변경할 수 있다.

​

4. 프로젝트 계획대로 진행하려면 설계 완료 후 정확한 WBS 와 일정을 변경할 수 있어야 한다.

​

여기서 전제되어야 하는 조건은 앞서 3장과 다를 게 없다. 단지 한 번 더 보다 정확한 일정게획을 세울 수 있으니 실행 가는한 계획 수립을 위한 찬스가 남았다는 것 뿐이다. 단순하게 생각하면, 수행팀이 이익을 포기하는 것은 물론 손해를 감수하고 자원을 더 투입하는 것외에는 방법이 없다고 생각할 수도 있다. 하지만 근본적인 방법이나 사고 방식은 그게 아니다.

일정이나 결과를 책임지는 사람은 PM이나 개발자가 아니다. 요구사항과 그 명세를 결정하는 사람 즉, 발주처 담당자나 프로젝트 스폰서가 책임져야 한다. 그들이 이미 그런 일정과 자원을 계획하지 않았는가. 이들이 요구사항 기능, 품질 요건 등을 제거하거나 변경함으로써 조정할 수 있기 때문이다. 즉, 모든 일정과 품질은 이들에게 달려있는 거다.

​

​

이런 걸 무시하고 그냥 일정수립과 그 이행을 PM과 개발자에게 전적으로 떠안겨 버리면, 프로젝트는 게획대로 진행되지 않는다. 이런 고객이나 임원은 SI는 물론 프로젝트 관리에 대해선 무지하거나, 능력이 형편 없다는 걸 뜻하느느 것이다. 그 결과는 불 보듯이 뻔하다. 프로젝트는 실패하고, 그 조직이나 회사는 망한다.

​

5. 결론

​

프로젝트 계획을 잘 세우지 않으면, 그 진척을 측정하는 것은 무의미하고, 따라서 프로젝트 진행 상태를 알 수 없으니, 그 프로젝트는 성공할 리가 없다.

​

​

6. 반론

​

그 럼에도 불구하고 성공하는 프로젝트는 무엇인가라는 질문을 할 수 있을 텐데, 내가 알기로 성공한 프로젝트는 거의 드물다. 혹 납기내에 검수 도장 받았으니 성공한 거 아니냐는 어리석은 정의를 하는 자가 있다면 할 말이 없다.

​

​

그래도 성공하는 경우가 있다면, 그것은 정말로 운이 억세게 좋은 것이다.