삼성SDS

SI 프로젝트 검수를 잘 받는 방법

프로젝트 종료는 빨리 끝내고자 하는 프로젝트 팀과 허용범위내에서 최대한 늦게 끝내고자 하는 이해관계자 또는 운영조직의 상충되는 이해관계가 대립하는 활동이다. 따라서 검수와 인수인계에 대한 사전준비가 미흡하면 프로젝트 종료의 실타래가 꼬여 납기가 지연될 뿐만 아니라 종료를 앞두고 이해관계자와 갈등이 발생하기 쉽다. 프로젝트 팀과 운영조직이 다를 경우에는 프로젝트 종료에 대해 보수적으로 접근해야 한다. 프로젝트 검수와 인수인계에 대한 구체적인 방법과 종료기준과 프로세스에 대한 확신이 없으면 종료할 준비가 덜 된 것이다.   - 검수기준을 정의한다. 프로젝트 종료를 승인하는 검수확인서(또는 준공확인서)에 고객의 승인을 받기 위해서는 행정적인 요건을 충족함과 동시에 이해관계자들의 기대수준을 충족시켜야 한다. 검수항목은 보통 계약서에 명시되기 때문에 항목자체는 이슈가 되지 않고 검수 프로세스를 구체화하기 위해 검수항목별로 검수내용, 검수방법, 검수자, 템플릿을 정의해야 한다.  SI 프로젝트의 검수항목중 이슈가 될 수 있는 내용은 ‘응용시스템’이다. 응용시스템 검수는 인수테스트 또는 통합테스트에 고객이 참여하여 요구사항이 오류 없고 불편하지 않게 작동하는지 확인하는 활동이기 때문에 프로젝트 팀과 고객의 의견이 많이 다를 수 있다.    - 검수항목별 검수책임자를 결정한다.   고객사의 적용조직이 큰 경우에는 동일한 업무를 지역별 또는 국가별로 검수 받아야 할 수 있다. 이런 경우에는 고객측에서 이견을 조정하고 검수와 관련된 의사결정을 할 수 있는 조직(의사결정기구)을 구성해야 한다. 예를 들어 전국에 흩어진 조직이라서 수시로 모이기 힘들면 검수 워크숍 또는 각 업무별 분과회 운영을 통해 최종 검수요건을 결정하도록 하는 것도 좋은 방안이다. 지역별로 검수를 받는 다면 시간의 문제가 발생할 뿐 아니라 지역별로 상충되는 의견을 조정하기란 불가능에 가깝다.   - 종료시점에 도출된 요청사항에 대한 수용기준을 협의한다.   프로젝트 종료 및 안정화 시점에 도출된 고객 요청사항은 관점이 다르기 때문에 대응하기 힘들다. 종료시점에는 중요한 변경요청에 대해선 합의가 된 상황이어야 한다. 만일 종료시점에 규모가 큰 변경요청사항이 논의된다면 종료할 준비가 되지 않은 상태이다. 종료시점에서는 기존에 합의한 화면 개선 또는 데이터 추가와 같은 세부 요청사항이 있을 수 있다. 종료시점에 고객과 협의 할 수 있는 추가 요청사항에 대한 수용기준의 예는 다음과 같다.   • 요청사항의 접수기한을 한정한다. 종료시점에 도출되는 요청사항은 기한을 정해야 한다. 예를 들어 통합테스트 기간 동안 도출된 요청사항 또는 안정화기간의 일부기간 동안 도출된 요청사항으로 한정하는 것이다. • 요청사항의 유형별로 수용기준을 정의한다. 종료시점에 파악한 오류는 당연히 수용해야 한다. 그러나 프로세스를 변경하는 요청사항은 수용하지 않는 것을 원칙으로 해야 한다. 사용성 개선을 위한 화면 변경 또는 조회 데이터 변경은 지원가능한 MM를 고려하여 우선순위를 결정하는 것이 바람직하다. 모든 개선요청사항들이 사용자 입장에서는 필요하기 때문에 우선순위 결정을 위한 제약조건에 대해 협의를 해야 한다. 프로젝트 관리자는 고객과 협의하기 전에 프로젝트 마무리를 위한 작업이 계획된 일정 또는 MM를 초과한다면 본사 경영층과 협의하여 마무리 지원방안을 결정해야 한다.   - 주요 이해관계자는 개별적으로 검수에 대한 승인을 사전에 획득한다. 프로젝트를 종료해도 좋다는 최종 의사결정은 고객사 경영층이 하는 경우가 많다. 따라서 이러한 경영층에게는 운영자・사용자의 검수에 앞서 프로젝트 결과를 설명하고 검수에 대한 승인을 받는 것이 좋다. 고객측 경영층이 검수에 긍정적인 평가를 한 상태에서 운영자・사용자 검수에 들어가면 프로젝트가 크게 흔들릴 일은 없다. 반대로, 아래로부터 개별 검수를 다 받았는데, 경영층에서 막히면 종료의 전체 구도가 틀어지는 경우가 많다. 고객측 경영층을 만나기 전에는 경영층의 이해관계와 관심사항이 프로젝트에 어떻게 반영되었는지와 프로젝트를 통해 해결한 문제 혹은 좋아진 점을 명확하게 설명할 준비를 해야 한다.   -  고객측 검수 책임자와 공동의 이해관계를 형성한다. 종료시점에서 검수 책임자와 프로젝트 관리자는 사이좋은 부부처럼 일심동체가 되어 고객측 이해관계자의 다양한 이해관계에 대응하는 것이 이상적이다. 프로젝트 팀의 프로젝트 관리자 못지 않게, 고객측 검수 책임자도 프로젝트를 잘 끝내고 싶다. 프로젝트를 잘 끝내야 각자의 조직에서 검수 책임자와 프로젝트 관리자는 좋은 평가를 받을 것이다. 먼저 프로젝트 관리자가 고객측 검수 책임자의 입장을 최대한 배려한다는 느낌과 신뢰를 주어야 한다. 프로젝트 관리자와 검수 책임자가 같은 배에 타고 있고, 같이 안전하게 배에서 내릴 준비를 해야 한다. 프로젝트 관리자가 빨리 종료하려는 마음이 급해 먼저 배에서 내리려고 한다는 인식을 준다면 검수책임자는 프로젝트 관리자를 결코 쉽게 보내주지 않을 것이다. 프로젝트 관리자의 이해타산만 따져서는 원만한 종료를 할 수 없다. 작은 것을 손해볼 때 큰 것을 얻을 수 있다. - 프로젝트 종료계획을 수립한다. 프로젝트 착수시 수립하는 프로젝트 계획 못지 않게, 프로젝트 종료를 위한 계획수립도 중요하다. 늦어도 프로젝트 진척률 80퍼센트 정도 시점에서는 프로젝트 종료계획을 수립하여 종료시점까지 계속 업데이트해야 한다. 종료계획 수립시 고려할 요소는 다음과 같다.   • 업무진행 현황 점검 계약서에 정의된 업무범위 대비 이행 여부, 최종 제품에 요구사항이 반영되 었는지 여부는 요구사항 추적표를 활용하여 확인한다. 종료시점에 이슈가 될 수 있는 미진한 업무나 추가 요구사항도 같이 식별한다. 검수전략과 검수계획 수립 검수의 목적물별로 누구를 상대로 어떻게 검수를 받을 것인지에 대한 계획을 수립한다. 검수전략에서는 전체 업무를 일괄적으로 검수 받을 것인지 아니면 단위업무별로 검수를 받고 관련 인력을 철수할 것인지를 결정한다. 대형의 복잡한 프로젝트에서는 단위업무별로 검수를 받고 관련 인력을 철수하는 것도 좋은 방안이다.   • 잔여업무 처리를 위한 일정계획 수립 종료시점에서는 잔여업무 목록 혹은 실행항목을 정의한 다음 고객 검수조직과 합의해야 한다. 잔여업무 목록 혹은 실행항목은 프로젝트의 실질적인 검수기준이 되는 경우가 많기 때문에 목록으로 만들어 완료 여부를 고객과 확인해야 한다. 잔여업무와 실행항목이 없어질 때 비로소 프로젝트 업무범위의 이행을 완료한 것이다. 이때 잔여업무 혹은 실행항목은 WBS에 업데이트하여 관리할 수도 있고, 별도로 엑셀과 같은 목록으로 관리할 수도 있다.   • 이슈 및 위험종료 계획수립 프로젝트 진행 도중 이슈 혹은 위험목록을 관리하고 있었다면 종료시점에서 이를 완료했다는 확인을 해야 한다. 종료시점까지 해결되지 않은 이슈나 위험 은 위에서 이야기한 잔여업무 혹은 실행항목에 통합해서 관리해도 무방하다.   • 비용 정산과 집행 계획수립 프로젝트를 종료한다는 것은 예산집행을 막는다는 것을 의미한다. 따라서 프로젝트와 관련하여 집행할 예산이 있다면 모두 집행해야 한다. 종료 이후 누락된 예산을 집행하기 위해서는 번거로운 행정절차를 거쳐야 한다.   • 인력해제 계획수립 프로젝트 팀원이 모두 동일한 날짜에 철수하기란 힘들다. 보통 몇 차례로 나누어 인력을 해제하는 것이 일반적이다. 인력철수는 고객이 민감하게 생각하는 이슈이기 때문에, 사전에 계획을 수립하여 고객과 합의를 해야 한다. 힘든 프로젝트를 끝낸 팀원들이 다음 프로젝트 투입 전까지 재충전을 할 수 있는 기간을 배려하는 것도 프로젝트 관리자가 해야 할 일이다.   • 전사 지원 요청사항 정리 프로젝트 이슈 해결을 위하여 프로젝트 수행조직의 지원부서에 요청할 내용을 계획한다.

SI 프로젝트를 끝내기 어려운 이유는 ?

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