IT 프로젝트의 불행한 결말을 암시하는 11가지 징후

IT 세계에서 프로젝트가 비극적인 결말을 맞는 경우는 드물지 않다. 사실 누구도 부러워하지 않을 실패한 IT 프로젝트에 참가했던 사람은 실제 사건이 발생하기 전에 분명 종말을 예견했을 것이다. 육감은 IT 같은 경쟁이 치열한 영역에서 매우 중요하지만, 적재적소에 발휘될 때에만 그 효과를 논할 수 있다.

어려움에 빠져 허우적대는 상황을 피하거나 종말을 피하고 싶다면 반드시 그런 일이 발생하기 전에 임박한 미래를 암시하는 징조를 알아챌 수 있어야 한다. 이를 통해 자신을 위기로부터 구할 수 있다.

IT 프로젝트의 성공 가능성을 가늠할 수 있는 11가지 불운한 징조를 모아보았다. 이 중 하나라도 보이게 되면 미리 조치를 취하거나, 가능하다면 피하기 바란다. 경우에 따라 잘못 엮여든 프로젝트 때문에 열심히 일하고 경력은 꼬이면서 인생이 달라질 수도 있기 때문이다.

불길한 징조 1. 경영진의 동의 없이 프로젝트가 시작됐다
확실한 IT 프로젝트의 실패 공식을 원하는가? 경영진의 동의를 얻기 전에 먼저 시작하라.

보통 이런 일이 어떻게 일어나는지 살펴보자. 기업 내에서 성격이 강한 사람은 "멋진" 아이디어 또는 솔루션을 갖고 있으며, 경영진의 동의 여부를 살피지 않고 회의를 계획하며 자원을 할당하기 시작한다. 이런 프로젝트는 자금을 실제로 집행해야 하는 시점까지 진행되다가 완전히 무너지게 된다. 시작한 사람을 제외하고는 프로젝트 참가자 모두가 프로젝트가 승인되지 않았다거나 예산이 편성되지 않았다는 사실을 까마득히 모르는 경우가 많다.

이런 프로젝트에 엮이지 않으려면 경영진의 누가 지원을 하고 있으며 할당된 예산은 얼마인지 항상 묻도록 한다. 프로젝트가 진행될 때까지 비용이 어느 정도인지 모르기 때문에 예산이 편성되지 않았다는 핑계에 넘어가지 말기 바란다.

프로젝트에 참여한 컨설턴트라면 두 번째 회의에 참석하기 전에 상당한 금액의 예산이 편성되었는지 반드시 확인하기 바란다. 최종적인 예산 금액을 알 필요는 없지만, 경영진이 해당 프로젝트를 진지하게 지원하고 있으며 실제적인 비용에 관한 실마리를 갖고 있는지 알아야 할 필요가 있다. 필자는 종국에 수백만 달러의 비용이 소요될 것이 뻔하지만 경영진은 수천 달러 수준으로 생각한 대형 프로젝트에 참여한 경험이 있다. 이런 프로젝트에 엮이지 않도록 한다.

불길한 징조 2. 프로젝트의 세부 계획이 존재하지 않는다
프로젝트 기획 소프트웨어는 사용이 복잡하고 어려울 수 있다. 필자가 프로젝트 세부 계획을 짜는 것보다 더 싫어하는 것은 계획이 없는 프로젝트에 엮이는 것이다. 공식적인 프로젝트 계획에 따라 프로젝트 관리자와 참여한 모든 사람들이 필요한 모든 단계와 속도뿐만이 아니라 진행 순서를 고려하게 된다. 자주 인용되는 말을 빌리자면 "계획에 실패하는 것은 실패를 계획하는 것과 같다."

2주 이상이 소요될 것으로 예상되는 프로젝트는 탄탄하며 세부적인 프로젝트 계획이 있어야 한다. 계획이 없는 프로젝트를 제안 받는다면 자신의 계획을 세우기 바란다. 모두가 모든 작업과 전략을 고려함과 동시에 현실적인 시간 계획을 수립하게 될 것이다. 프로젝트 세부 계획은 "최선을 다한 짐작" 또는 직감보다 훨씬 낫다.

불길한 징조 3. 팀 구성원의 일정에 상관 없이 회의가 소집된다
프로젝트 책임자 또는 팀 리더가 이미 예정된 중요한 회의와 충돌하는 회의를 임의로 소집하곤한다면, 프로젝트가 불운한 결과를 맞이할 것임을 알 수 있다. 이렇게 함으로써 중요한 팀 구성원이 빠지게 되고 회의의 목적과 효과가 반감될 것이다.

해결책은 간단하다. 프로젝트 회의를 계획하기 전에 중요한 참석자의 현재 일정을 확인하기만 하면 된다. 더욱 중요한 것은 공통 일정을 찾고 시간대를 선택하는 것이다. 참석자들이 여러 시간대 중에 선택할 수 있는 정도까지 진행하면 시간대를 지정했다가 거절당한 사람이 실망할 수 있으므로 주의한다. 대신에 직책이 높은 사람이 모두에게 적절한 시간을 선택하도록 한다. 필요하다면 추후에 변경도 가능하다. 또한 계획된 팀 회의 시간을 공개해 다른 사람들이 실수로 중복되는 일정을 계획하지 않도록 한다.

또한, 한 가지 팁이 있다. 가능하다면 점심 시간 이전에 회의를 계획한다. 일반적으로 생산성이 더욱 높고 회의 장소에 일찍 도착할 가능성이 높다. 점심 시간 이후의 회의는 포만감으로 인한 나태함과 싸우고 오전 중에 발생한 우선순위 및 각자의 아이디어도 모두 다루어야 한다. 점심 시간 이후 또는 업무 종료 시간에 가까운 회의는 참석자가 적고 생산성이 떨어질 가능성이 높다.

불길한 징조 4. 사용자들의 초기 참여가 거의 없다
대학에서 기본적인 IT 수업을 들은 사람들이라면 프로젝트 또는 의사결정 프로세스를 시작하는초기에 사용자들을 개입시켜야 한다는 사실을 알고 있다. 그래서 사용자들이 참여해 조언을 하기도 전에 막바지에 이르는 크고 복잡한 프로젝트들이 많다는 사실에 놀라지 않을 수 없다.

필자는 사용자들이 책임자들에게 특정 프로세스가 누락된 채로 프로젝트가 오랫동안 진행되었고 새로운 프로세스가 효과가 없다고 말하는 바람에 완전히 망쳐버린 대형 프로젝트에 여러 번 참여했다.

실제 사용자들 또는 지지자들이 처음부터 참여할 수 있도록 한다. 빠르면 빠를수록 좋다. 사용자들의 참여가 빠를수록 성공의 가능성은 높아진다. 프로젝트에 여러 부서가 관련되어 있다면 각 부서의 사용자 대표를 참여시키도록 한다. 또한 초대를 받은 사용자들이 프로젝트의 목적을 개방적으로 받아 들이고 자신의 의견을 피력할 수 있도록 한다. 일반적으로 사용자들이 조기에 참여하면 문제가 발생하거나 달갑지 않은 프로세스 변경이 필요할 때 더욱 신속하게 대응하게 된다.

불길한 징조 5. 프로젝트에 최소 사양 하드웨어가 계획되어 있다
최소한의 하드웨어를 구매하는 것만큼 프로젝트의 성공 가능성을 말살하는 것도 없을 것이다.

장비업체들은 최적의 결과를 위해 필요한 하드웨어를 싼 가격에 공급하여 프로젝트 비용을 낮추는 것으로 악명 높다. 또한 종종 "최소한의" 사양을 제시하고 추천한 하드웨어를 구매하도록 유도한다. 현명한 프로젝트 책임자라면 추천한 하드웨어 사양보다 높은 사양을 선택하면 문제가 발생했을 때 최소한 장비업체와 고객이 얼마 되지도 않는 하드웨어 구매 결정을 지적하는 일은 발생하지 않을 것이다. 또한 구매한 모든 하드웨어와 소프트웨어가 각각 호환되는지 테스트하도록 한다. 무엇인가 잘못 되었을 때 어느 한 쪽에서라도 지적을 받고 싶지 않을 것이다.

IT 구매에는 종종 함정이 도사리고 있다. 예를 들어, 장비업체가 리눅스로 운용한 MySQL이 괜찮았었다고 말한다면, 윈도우 상에서 운용하는 MySQL 선택에는 각별한 주의가 필요하다. 장비업체는 경험이 없더라도 할 수 있다고 말한다. 업체가 추천하는 것과 다른 것을 선택할 때는 업체의 승인을 서면으로 기록하도록 한다. 또한 유사한 환경설정을 공유한 고객을 확인해 추천하는 사양에서 약간이라도 달라질 경우에 어떤 일이 발생하는지 파악하는 것도 좋다.

불길한 징조 6. 테스트를 나중에 생각한다
테스트는 프로젝트의 성공에 필수적이다. (시스템의 일부를 테스트하는) 유닛 테스트든 아니면 (기본의 인터페이스 시스템을 포함하여 모든 구성요소를 테스트하는) 통합 테스트든, 테스트는 현재의 직원이 테스트 스크립트에 따라 실시해야 한다. 테스트 스크립트에는 모든 단계별 투입요소가 포함되어야 한다. 그리고 모든 결과물이 어떠해야 하는지에 대한 구상도 미리 해 두어야 한다.

테스트 데이터와 과정은 좋은 데이터와 좋지 않은 데이터를 포함하여 모든 시나리오를 고려해야 한다. 때로는 알려진 좋지 않은 데이터가 원하는 결과물보다 더욱 흥미로울 때도 있다. 테스트에는 시스템과 네트워크의 대응을 살펴보는 부하 테스트도 포함되어야 한다. 테스트 진행자는 예상되는 결과를 파악하고 모든 차이점을 보고해야 한다.

불길한 징조 7. 실패를 대비한 복구 계획이 없다
최선을 다한다고 해서 모든 것이 항상 계획대로 진행되는 것은 아니다. 모든 프로젝트 책임자는 성공했을 경우의 결과와 실패를 인정하고 다시 시작할 시기를 알아야 한다. 모든 프로젝트는 실패할 수밖에 없는 상황이 닥쳤을 경우의 예비 계획이 있어야 한다.

"잘못될 리가 없다"는 생각 때문에 너무 많은 일들이 발생한다. 이런 프로젝트의 책임자들은 건전한 예비 계획을 세우고 검증하지 않는 경우가 많다. 그들은 성공을 정의하거나 미리 실패의 결과가 어떠할지를 생각해보지 않는다. 문제가 발생했을 때 팀이 무엇을 해야 하는지 준비하지 않는다. 많은 신규 프로젝트가 문제에 직면했을 때 돌이킬 수 없는 결과를 얻고 마는데, 바로 엉성한 계획 때문이다.

몇몇 예외를 제외하고 프로젝트는 실패에 대비해야 하며 문제가 너무 심각하다면 예전의 시스템으로 되돌릴 수 있어야 한다. 물론, 실패는 창피한 일이며 누구도 실패를 계획하지는 않는다. 하지만 복구 중 서비스를 제공할 수 없는 시간이 길어지면 최악의 상황이 발생할 수도 있다.

경영진에게 자신이 예비 계획을 준비했고 문제가 발생했을 때 이를 따랐음을 알려주는 것이 현명하다. 다운타임이 길어지고 경영진에게 현 상황을 되돌이킬 수 없으며 앞으로도 막막하다고 보고하는 상황은 그야말로 최악이다. 성공을 계획하되 실패를 대비한 계획도 준비하도록 한다.

불길한 징조 8. 결과를 테스트하지도 않고 전문가의 권고사항을 거절했다
매번 전문가의 자문을 구해 듣고 나서 다른 길을 선택하는 사람이 있다. 그리고 그들은 무엇인가 잘못되었다고 불평한다.

이런 사람이 되지 말자. 이런 사람이 팀에서 중요한 의사를 결정하도록 하지 말자. 전문가의 자문을 구하고 나서 다른 것을 선택하는 일은 충분히 있을 수 있는 일이다. 이것이 인간의 본성이며, 좋은 리더의 자질이기도 하다. 하지만 강제적으로 그러는 일은 없어야 한다. 더욱 중요한 것은 권고사항을 무시하고는 결과가 좋지 못할 때, 컨설턴트를 탓하지는 않아야 한다.

장비업체 컨설턴트의 권고사항과 다른 선택을 하는 경우에는 자신의 선택으로 인한 결과를 시험해 봐야 한다. 장비업체 또는 컨설턴트의 권고사항 중 서로 다른 선택에 동의하더라도 반드시 이를 검증하도록 한다. 프로젝트 책임자가 장비업체나 컨설턴트가 뒤에서 고개를 가로 젓는 "얼마 안되는 변화"를 결정하는 바람에 많은 프로젝트가 실패하곤 한다.

얼마나 많은 전문가들이 경험이 많은 컨설턴트보다 더 많이 아는 것처럼 말하는 고객의 면전에서 침묵을 지키는지 알면 깜짝 놀랄 것이다. 모두들 친구가 되고 싶어 한다. 모두가 잘 되기를 바란다. 바라지 말고, 시험해 보기 바란다. 그리고 항상 전문가의 말에 귀를 기울이기 바란다.

불길한 징조 9. 본격 가동 일자가 주말 또는 휴일이다
많은 프로젝트 책임자들이 직원 또는 고객을 위한 서비스에 문제가 발생할 가능성이 낮기 때문에 주말 또는 휴일에 실질적인 시스템 가동을 계획한다. 괜찮은 생각이지만, 기술 지원 또한 받기 어렵다는 문제가 있다. 1차 업체는 대비를 하고 있어도 서드파티 기술 지원이 제대로 제공되지 않을 수 있으며, 이는 프로젝트 팀도 마찬가지이다. 가족과 휴가를 즐기는 최고의 데이터베이스 문제 해결 전문가와 전화로 대화를 나누는 상황은 절대로 최선일 수 없다.

불길한 징조 10. 기대치를 설정하지 않았다
기존의 시스템을 대체하기 위해 새로운 시스템을 도입할 때, 모두가 새로운 기대치를 이해하는 것이 도움이 된다. 새로운 시스템은 어떤 결과를 가져올까? 트랜잭션은 얼마나 잘 처리되고, 또 처리 시간은 얼마나 달라질까? 최종 사용자에게 문제가 발생하면 누구를 찾아야 하는가? 문제 해결팀이 현장에 도착하는데 걸리는 시간을 얼마나 될까? 사람들은 항상 새로운 시스템 때문에 긴장하지만 현실적인 기대치를 수립하고 사람들에게 신속한 지원 옵션을 제공한다면, 문제는 더 빨리 해결되고 고객들의 만족도 또한 향상될 것이다.

불길한 징조 11. 교육에 인색하다
얼마나 많은 프로젝트 책임자들이 예산 초과 문제가 발생할 때 교육 예산으로 이를 충당하는지 알고 있는가? 이런 책임자는 시스템이 너무 간단해서 사용자들을 위한 교육 따위는 필요 없다고 말한다.

"이런... 둘 중 한 명만 교육에 참여시키고 서로 정보를 공유하도록 해야겠다." 또는 "사용자들이 똑똑하니까 며칠이면 이 새로운 시스템을 파악할 수 있을 거야."라는 말을 듣는다면 실패를 예감해야 한다. 사용자뿐만이 아니라 프로젝트 책임자, 문제 해결사, 지원 인력 모두 교육이 필요하다. 적절한 교육을 제공하지 않는다면 프로젝트를 지연시킬 준비를 해야 한다.