IT 전문가들이 두려워하는 '시궁창' 프로젝트 상황 6가지

ERP와 레거시 하드웨어를 연계할 때는 늘 위험이 도사리고 있다. 특히 언어와 문화 장벽이 더해지면 엄청난 재난이 예상된다고 영국에 위치한 기술 서비스 기업 IT 랩(IT Lab)의 비즈니스 성과 및 컨설팅 이사 댄 콜레비가 말했다.

2000년대 중반 콜레비는 런던에 있는 빅 4(Big 4) 컨설팅 기업에서 근무하고 있었으며 다국적 대기업의 일본 지사가 글로벌 ERP시스템을 출시할 수 있도록 도와 달라는 요청을 받았다. 콜레비가 도착했을 때는 프로젝트가 시작된 지 2년이 넘었고 예산을 크게 초과한 상태였다. 그 이유는 하드웨어 중 일부가 정말로 구형이었기 때문이다.

"이런 시스템 중 하나는 너무 오래되어 고장에 대비해 도쿄에 있는 국립컴퓨터박물관(National Computer Museum)에 있는 전시물 중 파워 서플라이를 빌려와야 했었다"라고 그가 회고했다.

그는 이어 "ERP시스템을 새 데이터로 갱신할 수 있는 시간은 밤에 8시간뿐이었지만 인터페이스를 구동하는데 20시간이 소요되었기 때문에 소용이 없었다"라고 덧붙였다.

하지만 가장 큰 장벽은 기술이 아니라 사람과 정치였다. 콜레비는 아무도 체면을 잃지 않는 방법을 찾아내야 했다.

콜레비는 "아키텍처, 전략, 기술에 대한 해당 기업의 글로벌 접근방식에 대해 질문할 수 없었다. 나는 결국 그들이 비즈니스 프로세스를 바꾸어 더 적은 정보를 사용하도록 그들을 설득했다. 데이터의 약 90%를 잘라내어 시스템이 8시간 안에 구동할 수 있도록 했다"라고 말했다.

교훈 : 기술만으로는 해결할 수 없다. 사람과 과정도 그만큼 중요하다. 그는 "IT 랩에서는 항상 IT의 조직, 구조, 프로세스, 관리측면을 다룬다. 왜냐하면 기술 자체만큼이나 중요한 부분이기 때문이다"라고 말했다.

5. 과소 범위 산정과 과대 공약
과도한 낙관론, 상사에게 깊은 인상을 주고 싶은 소망, 적절한 프로젝트 범위 설정 실패 등으로 인해 애플리케이션 제공에 필요한 시간과 노력을 과소평가하면 어려운 프로젝트가 지옥으로 변모할 수 있다.

PME(Project Management Essentials)의 설립자 알랜 주커는 "짧은 시간 안에 제공할 수 있을 것이라고 낙관하는 경향이 있다. 빠르게 움직이는 기업에서는 더욱 그렇다"라고 말했다.

1990년대 말, 주커는 포춘 100 통신사의 회계 부서에서 프로젝트 관리자로 근무하고 있었다. 해당 통신사는 월 10억 달러 이상의 청구서를 발행했고 수 백 개의 상호 연계된 스프레드시트와 데이터베이스를 이용해 이 모든 것을 추적하고 있었다. 파워 빌더(Power Builder) 인터페이스를 통해 사이베이스(Sybase)를 백엔드(Back End)에서 사용해 단일 애플리케이션을 구축하여 매월 장부를 마감한다는 계획이 부상했다

기업 재정비 후 주커의 그룹이 해당 프로젝트를 담당하게 되었다. 그는 "모든 것을 데이터베이스에 로딩하고 회계 부서 사람들이 스스로 비즈니스 규칙을 구축하도록 하는 매우 우아한 아이디어를 IT 부문이 내놓았다"라고 회고했다.

그들은 9개월 후에 앱을 제공하겠다고 약속했다. 주커가 프로젝트를 승계했을 때는 4개월이 되도록 한 줄의 코드도 작성되지 않은 상태였다. IT 그룹은 여전히 사용자 요건을 수집하고 있었다. 그리고 그들은 그 작업이 예상했던 것보다 훨씬 복잡하다는 점을 깨닫고 있었다.

이 때 책임 전가가 시작되었다고 주커가 말했다. 그는 "IT조직에 있는 인력들이 매우 방어적으로 행동하기 시작했다. 수 페이지에 달하는 이메일을 작성했고 경찰 조사처럼 느껴졌다. '이 날, 이 시간까지 그렇고 그렇게 말하고...' 식이었다. 상황이 진행되면서 건설적인 대화를 진행할 수 없게 되었다"라고 말했다.

IT관리자가 재할당되었고 주커는 새로운 파트너를 얻은 후에야 좀 더 여유 있는 시한이 설정되었다. 이 앱은 결국 성공했지만 2년이나 더 지나서야 완성될 수 있었다.

교훈 : 주커는 앞으로는 한 걸음 물러서서 양 당사자에게 유익할 수 있는 방법을 찾아야 한다는 사실을 깨달았다. 또한 그는 더 많은 자원을 요청하고 본래의 프로젝트 기간을 재설정해도 괜찮다는 사실을 배웠다. 그리고 마지막으로 하나의 자원(또는 사람)을 바꾸는 것이 팀 전체의 역학을 얼마나 개선할 수 있는지에 대한 교훈이기도 했다.

6. 임원진의 특수 요청
글로벌 조직을 안드로이드에서 표준화했을 수도 있지만 CEO가 아이폰을 쥐고 있을 수 있다. 아니면 한 이사가 자신의 부서를 위한 맞춤형 솔루션을 요청할 수 있다.

이상적인 시나리오에서는 프로젝트 요청을 전략적인 계획에 비추어 고려하여 승인과 예산 제공에 앞서 기업이 구체적인 목표를 달성하기 위해 필요한 것을 판단한다. 마이클은 “그러나 대부분의 조직은 그렇지 않다. 정치적인 영향력이 가장 큰 사람이 원하는 것을 얻는 경우가 많다"라고 말했다.

심지어 프로세스가 꽤 탄탄한 기업도 영향력이 가장 큰 사람의 변덕의 희생물이 될 수 있다고 그가 말했다. CIO에게 거부할 수 있는 정치적인 힘이 없기 때문이 이런 일이 벌어지는 경우가 많다.

마이클은 "다른 대안이 없으면 그들은 입을 꾹 다문다. 추수감사절 식탁에 앉아 통조림 크랜베리 소스를 먹는 아이와 같다"라고 말했다.

교훈 : IT프로젝트에 대한 유입 프로세스가 없다면 영향력이 가장 큰 사람이 우선순위를 마음대로 바꾸어 놓을 수 있다. 자신의 핵심 거버넌스, 위험, 준수성 이해당사자가 누구인지 파악하고 IT가 각 운영 위원회에 참여할 수 있도록 해야 한다.

마이클은 "IT프로젝트의 유입 및 워크플로를 효과적으로 관리하려면 임원을 자신의 편으로 만들어야 한다. 그렇지 않으면 IT예산이 모든 임원의 변덕에 놀아나면서 자원이 말라버릴 것이며 필수적인 인프라와 네트워킹 등의 프로젝트에는 부스러기만 남을 것이다"라고 말했다. ciokr@idg.co.kr