차세대시스템 등 대규모 IT프로젝트에 내재된 리스크는 10가지 정도로 정리할 수 있다.

즉 △현업의 참여 미흡 △핵심 요원 변동 △참여 업체의 경영 위기 발생 △요구사항의 잦은 변경 △업무 범위의 과도한 증가 △지나치게 많은 신기술의 도입 △검증되지 않은 솔루션으로 인한 기능 장애 발생 △운영 장비의 용량 부족 △핵심공정(critical path)의 병목현상 발생 △보고서 상태와 실제 상태의 괴리 확대 등이 그것이다.

이러한 리스크들은 프로젝트 조건에 따라 조금씩 다른 모습을 띠고 나타나며 그에 따라 대응방식도 조금씩 달라지는 것이 당연하다. 하지만 분명한 것은 프로젝트의 리스크는 관리할 수 있는 요소들이란 점이다. 중요한 것은 문제를 해결하려는 의지와 합리적인 접근방식에 대한 신뢰를 가지는 것이다.

이제 이러한 리스크들의 성격과 대처 방식을 하나씩 살펴보기로 하자.

1. 현업의 참여 미흡

말을 물가에 데려갈 수는 있지만 물을 먹일 수는 없다고 한다. IT프로젝트도 마찬가지다. 오랜 준비를 거쳐 SI 사업자를 선정하고 계약까지 마쳤다 해도 고객사 현업이나 이해관계자들이 모두 흔쾌히 이 프로젝트에 참여하고 자신의 역할을 다할 것이라고 기대할 수는 없다.

이해관계자들 사이에서는 100%라 해도 좋을 만큼 해당 프로젝트에 대해서 불만을 갖는 사람이 생겨나고 결국 프로젝트 참여를 기피하거나 적당히 형식적으로만 참여하게 된다. 그 원인은 천차만별이지만 또 그만큼 전형적이기도 하다.

◆원인은 후원임원의 스폰서십 부족, 현업부서의 주인의식 부재 = 대표적인 원인으로 먼저 경영진 등 후원임원의 스폰서십이 부족하다는 것을 들 수 있다. 이것은 프로젝트 전반의 리더십 실종으로 이어지기 쉽다. 결국 프로젝트의 목표(TO-BE) 요건을 제시하지 못하고, 기존 업무 프로세스가 개선되지 못하는 결과를 낳게 된다. 이는 결과적으로 프로젝트가 애초에 의도했던 투자효과를 제대로 얻기 힘들다는 얘기이다.

또 다른 원인으로 담당 현업부서가 프로젝트에 대한 주인의식을 갖추지 못한 경우를 들 수 있다. 이러한 경우 가장 자주 나타나는 현상이 프로젝트의 구축 단계 이후 시스템 테스트 과정에 들어가서야 잘못 적용된 요건을 발견하는 것이다. 이것은 프로젝트의 납기 차질로 이어지며 심한 경우 아예 프로젝트의 품질이 기준에 현저히 미치지 못하는 현상이 생길 수도 있다.

프로젝트 조직에 현업 전담요원을 투입하지 못하는 일도 생길 수 있다. 이런 경우에는 프로젝트 수행 기간 동안에 발생한 업무 변화 또는 프로젝트의 완료로 인해 불가피하게 발생하는 업무나 프로세스의 변화를 현업 업무에 충분히 반영하지 못하게 된다.

결국 프로젝트를 마치고 시스템을 가동한 이후에 변경사항이 너무 많아져서 이를 관리하기 무척 어렵게 되고 이는 다시 현업들의 불만과 참여 부족을 낳는 악순환으로 이어진다.

◆현업의 참여 미흡 해결방식 세가지 = 이렇게 다양한 원인으로 발생하는 현업의 프로젝트 참여 미흡 현상에 대응하여 문제를 해결하는 방식은 어떤 것이어야 할까? 가장 일반적으로 수행하는 방식은 다음 세 가지이다.

먼저 현업의 참여를 이끌어내는 전담요원을 확보하는 방법이 있다. 현업의 적극적인 참여는 프로젝트의 성공에서 필수불가결의 요인이다. 따라서 무슨 일이 있어도 이 문제는 해결하고 나아가지 않으면 안된다. 현업들을 전담하여 프로젝트를 이해시키고 현업 각자의 역할을 주지시키고 참여를 이끌어내는 역할을 수행하는 전담요원은 그래서 반드시 필요한 존재이다.

내부에서 적절한 인력을 찾기 어렵다면 외부의 인력에서 계약직을 구하는 한이 있더라도 반드시 필요한 역량을 갖춘 현업 전담요원을 확보해야 한다. 이러한 인력을 구하는 것이 쉽지 않을 수도 있지만 어느 정도의 역량을 갖춘 인력이라면 필요한 교육을 병행하면서 주어진 역할을 수행하고, 다양한 피드백을 거쳐서 역량을 제고할 수도 있다.

대부분의 경우 이런 역할을 하는 인력이 전혀 없는 것보다는 역량이 좀 부족하더라도 이 역할을 전담하는 인력이 있는 경우가 프로젝트 전체의 품질에는 훨씬 좋은 영향을 미친다는 것을 강조하고 싶다.

다음으로 현업 주관부서에 책임을 부여하는 방법이 있다. 광범위한 프로젝트의 업무 영역을 적절하게 분할해서 그 업무 영역을 담당하는 현업 부서를 지정하는 것이다. 한마디로 말해 프로젝트 성공과 실패의 책임소재를 보다 분명히 하자는 것이다. 프로젝트 전체의 성공과 실패는 모두의 책임이지만 이런 식의 막연한 규정은 동시에 누구나 자신의 책임은 아니라고 피해갈 수 있는 길을 열어주게 된다. 보다 구체적으로 업무와 책임을 연결해줄 때 현업부서들의 참여도가 높아지게 된다.

또 하나 빼놓을 수 없는 것이 CEO보고회이다. 이 보고회를 정례화하고 그 효과를 극대화하기 위해서 최선의 노력을 기울여야 한다. 이 보고회의 품질과 효과가 프로젝트 전체의 성패에 매우 큰 영향을 미친다는 사실을 잊으면 안된다.

각 업무의 주관부서는 담당하는 업무의 진행상황을 철저히 파악해서 이를 전체 프로젝트의 진전 상황이란 맥락 속에서 이해하고 정리해야 한다. 그리고 CEO에게 해당 업무의 추진 경과 및 향후 추진계획 등을 직접 보고해야 한다. 중요한 것은 간접적이거나 조직적으로 한 단계 건너뛰는 방식의 보고가 아니라 가급적 직접 CEO와 대면해서 보고하는 방식이어야 한다는 점이다.

보고 내용은 현업과 수행업체 등 관계자들의 동의를 충분히 얻어낸 결과물이어야 하며, 보고 내용을 두고 끝내 이견을 해소하기 어려운 경우 이 이견을 그대로 드러내서 CEO에게 보고하는 방식도 검토할 수 있다. 또한 보고의 형식과 내용에서 지나치게 IT관점에서 접근하기보다는 경영자의 관점과 경영 목표, 마인드를 충분히 반영할 필요가 있다.

이러한 전반적인 노력을 통해 현업의 참여 부족이라는 문제는 어느 정도 극복할 수 있다. 물론, 아무리 노력해도 현업의 참여를 100% 만족스럽게 이끌어내는 것은 불가능하다. 그럼에도 이러한 노력의 크기와 그 결과의 차이는 그대로 프로젝트의 품질과 성패에도 그대로 반영된다는 사실을 잊으면 안된다. <계속>