모든 프로젝트는 끝내기 위해 시작하고 프로젝트의 끝에는 운영의 시작이 있다. 프로젝트와 운영의 경계가 명확할수록 프로젝트를 끝내기 힘들다. 프로젝트 수행과 운영의 회사가 다른 SI 프로젝트가 대표적인 예이다.
SI 프로젝트에서는 프로젝트 종료 이후에는 모든 업무를 고객사의 책임 하에 수행하기 때문에 고객사는 다양한 이해관계자들의 요구 사항을 충족한 후 운영에 필요한 문서를 확인하고 프로젝트 종료 문서에 서명한다.
프로젝트 종료가 힘든 상황은 프로젝트 업무를 끝내기 힘든 상황, 종료에 대한 검수를 받기 힘든 상황, 운영으로 인수인계가 어려운 상황으로 구분할 수 있다. 참고로 ‘검수’란 프로젝트팀에서 이해 관계자에게 업무에 대한 완료를 확인받고 최종 승인을 획득하는 절차이고, ‘인수’란 운영조직이 프로젝트 팀으로부터 시스템 운영 전반을 이관받고 확인하는 절차이다.
1) 프로젝트 업무를 끝내기 힘든 상황
프로젝트 업무를 끝내기 힘든 상황은 종료 프로세스 관리로 대응하기 힘들며 평소 프로젝트 관리를 잘해야 문제를 해결하거나 부작용을 최소화할 수 있다.
– 프로젝트 목표에 대한 공감대가 미흡함
프로젝트 목표는 종료를 판단할 수 있는 기준이기 때문에 이해관계자들의 그 목표에 공감해야 한다. 이해관계자들이 상충된 목표를 주장하면 프로젝트 종료는 정치게임으로 변한다.
옳고 그르고에 상관없이 잘못된 목표라도 이해관계자들이 공감해야 프로젝트 종료할 수 있다. 현실을 고려한 점진적인 개선과 이상적인 일괄개선을 주장하는 상충된 주장이 그 예다.
예를 들어 B2B 솔루션 기업에서 고객지원 시스템을 구축하기 위해서는 고객정보, 판매정보, 기술지원 정보를 통합하여 관리해야 하는데 수많은 기준정보의 정합성을 유지하는 것이 힘들기 때문에 일부 정보를 별도의 수작업으로 관리해야 할 수도 있다. 이러한 방식은 현실적이긴 하지만 자동화되지 않은 프로세스, 부정확한 데이터의 중복 관리의 문제를 안고 있다. 만일 빅 마우스의 임원이 이러한 문제점을 프로젝트 후반부에 주장한다면 프로젝트 종료는 힘들어진다.
– 기술적으로 구현이 힘든 성능목표를 설정함
기술적으로 달성하기 힘든 요구사항을 설정하면 프로젝트 종료가 힘들다. 안면인식률, 지문인식률, 음성인식률 99.9%는 무척 달성하기 힘들 뿐만 아니라 목표달성을 위해 설계를 하면 다른 부작용도 발생한다. 육지나 강에 CCTV를 설치하여 적군의 침입을 탐지하는 보안시스템도 마찬가지다. 육지에서는 눈이나 비가 내릴 수도 있고, 강속에서는 다른 부유물이 있는 상황에서 동물과 사람을 정확하게 구분하는 것은 힘들다. 1990년대 미국의 덴버 국제공항은 완전 자동화된 수하물 처리 시스템을 구축하려 했지만 수차례의 프로젝트 지연 끝에 결국 자동화를 포기하고 기존의 수작업 분류 시스템을 유지해야 했었다.
기술의 한계를 인정하고 허용가능한 오차 수준을 정해야 하는데 특정 개인의 정치적인 욕심으로 무리한 목표를 추구하는 이해관계자를 만나면 목표달성이 힘들다. 특히 현행만 유지해도 문제가 없다면 고객입장에서는 프로젝트 종료에 대한 압박이 없어 목표 수준을 조정할 수 없고 이 때문에 프로젝트 종료가 더욱 힘들어진다.
2) 프로젝트 종료에 대한 검수가 힘든 상황
검수가 힘든 상황은 검수조직의 복잡함, 추가 요구사항의 발생이 대표적이다.
– 업무 종료를 확인하는 검수조직이 복잡함
동일 업무에 대해 종료를 확인하는 조직이 많아지면 검수조직 간에도 이견이 발생하여 프로젝트 종료도 힘들어진다. 예를 들어 공공기관을 대상으로 10개의 하위시스템을 구축하는 프로젝트에서 16개 시도의 업무담당자별로 종료를 위한 검수를 받는다면 160개의 종료확인서가 필요하다. 이런 프로젝트에서 고객사 내 이견을 조정하고 검수를 리딩하는 조직이 없다면 프로젝트 수행조직에서 이러한 역할을 담당해야 하는데 프로젝트를 어떻게 종료할지 상상조차 힘들다.
– 프로젝트 종료시점에 추가 요구사항이 발생함
고객이 모든 요구사항을 상세하게 정의하는 것은 불가능하며 프로젝트 결과물이 분명해지는 종료시점에서야 모든 요구사항이 분명해진다. 특히 폭포수 방법론을 적용한다면 이해관계자들이 통합테스트에서 동작하는 시스템을 처음 접하기 때문에, 통합테스트에서 오류사항뿐만 아니라 크고 작은 추가 요구사항을 요청한다.
종료시점에서 발생하는 요구사항은 요구사항에 대한 쌍방의 오해, 틀린 요구사항, 이해관계자의 변심으로 구분할 수 있지만 추가 요구사항이 어떤 유형인지는 쌍방의 생각이 다르다. 프로젝트 팀은 추가 요구사항을 많이 수용할수록 프로젝트가 지연되고, 고객사는 추가 요구사항을 반영하지 않으면 운영단계에서 보완해야 하기 때문에 조직의 이익을 대변하지 못했다는 질책을 받을 수 있다. 따라서 종료의 전제조건에 포함할 요구사항을 결정하는 이해관계가 첨예하게 대립되고 이러한 조정이 종료를 힘들게 만든다.
따라서 검수기준의 불명확은 정도의 차이가 있을 뿐이고, 어느 정도 선에서 절충할 것인가만 문제다. 고객사와 프로젝트 팀 모두를 만족시키는 절충방안은 존재하지 않는다. 고객사와 프로젝트팀 모두 역지사지의 관점에서 이 문제를 접근하면 좋겠지만, 현실은 그렇게 녹록지 않다. 최악의 경우에는 프로젝트 진행과정에서 모호하게 덮어두었던 모든 불씨들이 다시 살아나서 서로 얼굴을 붉히기도 한다. 물론 그때 절대적으로 불리한 입장은 프로젝트 팀이다.
– 종료감리 대응
종료시점에서는 결함제거, 여러 가지 개선요구 대응, 사용자 교육, 행정처리등을 동시에 수행하느라 정신이 없다. 그 와중에 SI프로젝트는 종료감리까지 수행해야 하는 경우도 많다. 감리에서 지적하는 내용들은 대부분 문서작업과 관련된 내용이다. 그 시점에서 프로젝트 팀원들은 문서작업이 아니라 기술적인 내용과 씨름하고 있기 때문에 문서작업은 프로젝트 팀원에게 또 다른 짐이 된다. 물론 프로젝트를 종료하고 안정적인 운영을 위해서는 필요한 문서가 있어야 하며, 그 내용 또한 정확해야 한다. 문제는 감리조직이나 감리인의 성향에 따라 프로젝트의 본질적인 내용과 벗어난 건수 위주의 지적을 할 수 있다는 것이다.
그것이 중요한 지적이든 아니든 검수에 대한 부담감을 줄이기 위해 고객사 입장에서는 외부 감리에서 지적한 내용을 모두 조치했다는 확인을 감리조직으로부터 받아야 종료검수를 시작하는 경우도 많다.
3) 운영을 위한 인수인계가 어려운 상황
운영을 위한 인수인계가 어려운 상황은 프로젝트 오픈 이후 안정화가 힘들거나 시스템을 운영할 준비가 미흡한 상황이 대표적이다.
– 시스템 오픈 후 사용자들의 VoC가 폭주함
프로젝트는 기존에 없던 것을 만들거나 변화하기 위해 시작하지만 변화를 좋아하는 사용자들은 없다. 프로젝트 결과물을 적용하는 초기에는 기존과는 달라진 프로세스, 익숙하지 않은 화면에 대한 사용자 VoC가 많이 발생한다. 프로젝트와 운영이 중첩되는 ‘안정화’의 시기는 짧을수록 프로젝트 종료가 쉬워진다. 프로젝트 품질 수준이 낮다면 문제를 해결하는 개선활동이 또 다른 문제를 발생시키기 때문에 사용자 불만은 줄어들지 않아 이해관계자들도 프로젝트 종료를 승인하기 부담스럽다. 특히 프로젝트 결과물을 글로벌하게 적용한다면 프로젝트 적용 환경의 다양성, 사용자들의 다양성으로 예상하지 못했던 문제점들이 많이 발생하기 때문에 프로젝트 안정화 기간이 길어진다.
– 시스템을 운영할 준비가 미흡함
프로젝트 팀과 운영조직은 이해관계가 상충할 수밖에 없다. 프로젝트 팀은 빨리 끝내고 싶지만 운영조직은 사용자들의 요구사항을 최대한 해결한 뒤 인수인계를 받고자 한다. 다른 사람이 개발한 시스템을 인수받아서 운영하는 것은 쉽지 않다. 운영에 문제가 발생하면 본인이 책임져야 하는 부담감 때문에 프로젝트 시스템을 충분히 이해했다는 자신감이 있어야 한다. 운영에 대한 자신감이 부족하면 이런저런 핑계로 프로젝트 운영을 위한 인수인계를 미루게 된다.
김병호 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
모비인사이드의 뉴스레터를 구독해보세요
