IT프로젝트가 망가지고 있다는 11가지 징조

불길한 징조 1. 경영진의 동의 없이 프로젝트가 시작됐다 IT프로젝트에 실패하고 싶은가? 그렇다면, 경영진의 동의를 얻기 전에 시작하면 된다. 보통 이런 일이 어떻게 일어나는지 살펴보자. 기업 내에서 성격이 강한 사람은 ‘멋진’ 아이디어나 방안을 가지고 있으며, 경영진의 동의 여부를 살피지 않고 회의를 계획하며 인력을 배분하기 시작한다. 이런 프로젝트는 실제 자금을 집행해야 하는 시점까지 진행되다가 완전히 무너지게 된다. 시작한 사람을 제외하고는 프로젝트 참가자 모두가 프로젝트가 승인되지 않았다거나 예산이 편성되지 않았다는 사실을 전혀 모르는 경우가 많다. 이런 프로젝트에 엮이지 않는 방법이 있다. 어떤 경영진이 이 프로젝트를 지원하며 예산은 얼마인지 먼저 확인하면 된다. 프로젝트가 시작될 때까지 비용이 얼마나 들지 모르기 때문에 예산이 편성되지 않았다는 핑계에 절대 속지 말기 바란다. 이미지 출처 : photo : gpalmer1477

불길한 징조 2. 프로젝트 세부 계획이 없다 프로젝트를 계획하는 소프트웨어는 사용이 복잡하고 어려울 수 있다. 필자가 프로젝트 세부 계획을 짜는 것보다 더 싫어하는 것은 계획이 없는 프로젝트에 엮이는 것이다. 공식적인 프로젝트 계획에 따라 프로젝트 관리자와 참여한 모든 사람들이 필요한 모든 단계와 속도뿐만 아니라 진행 순서를 고려하게 된다. 자주 인용되는 말을 빌리자면 "계획에 실패하는 것은 실패를 계획하는 것과 같다." 2주 이상이 소요될 것으로 예상되는 프로젝트는 탄탄하며 세부적인 프로젝트 계획이 있어야 한다. 계획이 없는 프로젝트를 제안 받는다면 자신의 계획을 세우기 바란다. 모든 작업과 전략을 고려함과 동시에 현실적인 시간 계획을 수립하게 될 것이다. 프로젝트 세부 계획은 ‘최선을 다한 짐작’ 또는 직감보다 훨씬 낫다. 이미지 출처 : iStockphoto

불길한 징조 3. 팀원들의 일정에 상관 없이 회의가 소집된다 프로젝트 책임자 또는 팀 리더가 이미 예정된 중요한 회의와 충돌하는 회의를 임의로 소집하곤 한다면, 그 프로젝트의 운명이 어떨지 예감할 수 있다. 중요한 팀 구성원이 빠진 채 진행되는 회의는 목적과 효과가 반감될 수밖에 없다. 해결책은 간단하다. 프로젝트 회의를 계획하기 전에 중요한 참석자의 현재 일정을 확인하기만 하면 된다. 더욱 중요한 것은 공통 일정을 찾고 시간대를 선택하는 것이다. 참석자들이 여러 시간대 중에 선택할 수 있는 정도까지 진행하면 시간대를 지정했다가 거절당한 사람이 실망할 수 있으므로 주의한다. 대신 직책이 높은 사람이 모두에게 적절한 시간을 선택하도록 한다. 필요하다면 추후에 변경도 가능하다. 또한 계획된 팀 회의 시간을 공개해 다른 사람들이 그 시간을 피해 일정을 잡도록 한다. 이미지 출처 : iStockphoto

불길한 징조 4. 사용자들이 프로젝트 초기에 거의(전혀) 참여하는 않는다 대학에서 기본적인 IT 수업을 들은 사람들이라면 프로젝트 또는 의사결정 프로세스를 시작하는 초기에 사용자들을 개입시켜야 한다는 사실을 알고 있을 것이다. 사용자들이 의견을 주기 전에 대규모의 복잡한 프로젝트들이 거의 끝나버리는 것을 목격하는 것은 그다지 놀랄만한 일도 아니다. 필자는 사용자들이 책임자들에게 특정 프로세스가 빠진 채로 프로젝트가 이미 진행됐고 새로운 프로세스가 효과가 없다고 말하는 바람에 망가진 대형 프로젝트에 여러 번 참여했다. 실제 사용자들이나 지지자들을 처음부터 참여시켜야 한다. 빠르면 빠를수록 좋다. 사용자들의 참여가 빠를수록 성공의 가능성은 높아진다. 프로젝트에 여러 부서가 관련되어 있다면 각 부서의 사용자 대표를 참여시키도록 한다. 또한 초대를 받은 사용자들이 프로젝트의 목적을 개방적으로 받아 들이고 자신의 의견을 피력할 수 있도록 한다. 이미지 출처 : photo : pojoslaw

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

불길한 징조 6. 테스팅을 나중 문제로 생각한다 테스팅은 프로젝트의 성공에 필수적이다. (시스템의 일부를 테스트하는) 유닛 테스트든 아니면 (기본의 인터페이스 시스템을 포함하여 모든 구성요소를 테스트하는) 통합 테스트든, 테스트는 현재의 직원이 테스트 스크립트에 따라 실시해야 한다. 테스트 스크립트에는 모든 단계별 투입요소가 포함되어야 한다. 그리고 모든 결과물이 어떠해야 하는지에 대한 구상도 미리 해 두어야 한다. 테스트 데이터와 과정은 좋은 데이터와 좋지 않은 데이터를 포함하여 모든 시나리오를 고려해야 한다. 때로는 알려진 좋지 않은 데이터가 원하는 결과물보다 더욱 흥미로울 때도 있다. 테스팅에는 시스템과 네트워크의 대응을 살펴보는 부하 테스트도 포함되어야 한다. 테스팅 진행자는 예상되는 결과를 파악하고 모든 차이점을 보고해야 한다. 이미지 출처 : iStockphoto

불길한 징조 7. 실패를 대비한 복구 계획이 없다 최선을 다한다고 해서 모든 것이 항상 계획대로 진행되는 것은 아니다. 모든 프로젝트 책임자는 성공했을 경우의 결과와 실패를 인정하고 다시 시작할 시기를 알아야 한다. 모든 프로젝트는 실패할 수밖에 없는 상황이 닥쳤을 때를 고려한 대안이 있어야 한다. "잘못될 리가 없다"는 생각 때문에 너무 많은 일들이 발생한다. 이런 프로젝트의 책임자들은 건전한 예비 계획을 세우고 검증하지 않는 경우가 많다. 그들은 성공을 정의하거나 미리 실패의 결과가 어떠할지를 생각해보지 않는다. 문제가 발생했을 때 팀이 무엇을 해야 하는지 준비하지 않는다. 많은 신규 프로젝트가 문제에 직면했을 때 돌이킬 수 없는 결과를 얻고 마는데, 바로 엉성한 계획 때문이다. 이미지 출처 : iStockphoto

불길한 징조 8. 결과를 검증하지도 않고 전문가의 권고사항을 무시했다 매번 전문가의 자문을 구하고 나서 꼭 그와 다른 길을 선택하는 사람이 있다. 그리고 그들은 무엇인가 잘못되었다고 불평한다. 이런 사람이 되지 말자. 이런 사람이 팀에서 중요한 의사를 결정하도록 하지 말자. 전문가의 자문을 구하고 나서 다른 것을 선택하는 일은 충분히 있을 수 있는 일이다. 이것이 종종 훌륭한 리더의 자질이기도 하다. 하지만 강제적으로 그러는 일은 없어야 한다. 더욱 중요한 것은 권고사항을 무시하고는 결과가 좋지 못할 때, 컨설턴트를 탓하지는 말아야 한다. IT업체나 컨설턴트의 권고사항 중 서로 다른 선택에 동의하더라도 반드시 이를 검증하도록 한다. 프로젝트 책임자가 IT업체나 컨설턴트가 말리는 ‘아주 작은 변화’를 단행하는 바람에 많은 프로젝트가 실패하곤 한다. 이미지 출처 : iStockphoto

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

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

불길한 징조 11. 교육에 인색하다 얼마나 많은 프로젝트 책임자들이 예산 초과 문제가 발생할 때 교육 예산으로 이를 충당하는지 알고 있는가? 이런 책임자는 시스템이 너무 간단해서 사용자들을 위한 교육 따위는 필요 없다고 말한다. "이런... 둘 중 한 명만 교육에 참여시키고 서로 정보를 공유하도록 해야겠다" 또는 "사용자들이 똑똑하니까 며칠이면 이 새로운 시스템을 파악할 수 있을 거야"라는 말을 듣는다면 실패를 예감해야 한다. 사용자뿐만이 아니라 프로젝트 책임자, 문제 해결사, 지원 인력 모두 교육이 필요하다. 적절한 교육을 제공하지 않는다면 시스템 개통일정을 늦춰야 한다. 이미지 출처 : TimeStock