IT 프로젝트의 형편이 좋지 않으면 어떻게 해야 합니까

형편이 좋지 않은 IT 프로젝트를 만났을 때 CIO 인 당신은 어떻게 합니까? 중지 또는 계속? < P > "IT 프로젝트를 중단하기로 한 결정은 IT 프로젝트를 전개하는 것보다 훨씬 고통스럽고, 때로는 상상도 할 수 없을 때가 있다. 그래도 억지로 두피를 하고 해나가야 한다. 끊임없이 변화할지 모르지만, 이 프로젝트 건설은 이미 원래의 의도에서 벗어났다. " 많은 CIO 들이 이렇게 감개무량하다. 그러나 멈추는 것은 자신을 부정하는 것을 의미하며, 이런 결정을 내리려면 너무 큰 용기가 필요하다! 기자와의 인터뷰에 따르면 이 문제에 대해 국내 CIO 와 외국 CIO 는 전혀 다른 견해와 의견을 갖고 있는 것으로 나타났다. 결국 두 환경이 크게 다르기 때문이다 ... < P > 외국 CIO 의 생각: 11: 1 종료 < P > 는 프로젝트 책임자에게 형편이 좋지 않은 IT 프로젝트를 언제 총살할지 판단한다. 환영받지 못하고, 자원을 소모하고, 뚜렷한 상업적 수익이 없는 프로젝트를 중단하는 것은 확실히 충분한 용기가 필요하다. 하지만 집행 과정에서 약간의 요동을 겪으면서 중요한 프로젝트를 취소한다면 자신과 이사회 사이에 많은 마찰이 생길 수 있다는 것을 알게 될 것이다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 스포츠명언) < P > 최근 silicon.com 은 이 문제에 대해' CIO 배심원단' 에 대한 답을 구했고, IT 업계 지도자들은 11 대 1 의 투표 결과를 통해 문제가 있는 IT 프로젝트를 중단하는 것이 이사회의 요구에 순전히 맞추는 것보다 낫다고 밝혔다. M a n p o w e r 의 CIO K e v I n Fitzpatrick 은 기업이 실패한 프로젝트를 계속하는 것은 범죄 행위라고 생각한다. 그는 "IT 구현에서 가장 큰 실패의 원인은 일부 작업이 중단되어야 한다는 것을 일찍 깨닫지 못하고, 방향을 바꾸거나, 심지어 이 프로젝트를 완전히 취소할 용기가 부족하다는 것" 이라고 말했다. 때때로 성공하려면, 어디에서 멈추고 자원을 적절한 곳에 배치하여 가치를 높일 수 있도록 긴급 조치를 취하는 법을 배워야 한다. " < P > "불량프로젝트를 중단한 기업들은 후회할 가능성이 높다. 내가 말한 것은 종결된 결정을 후회하는 것이 아니라 왜 불량프로젝트를 계속했는지 후회하는 것이다. 물론 종결 결정을 내리는 것도 쉽지 않다. " Government Planning Portal 의 IT 책임자인 David Jemitus 는 이렇게 생각합니다.

Barclays 의 CTO 인 Kevin Lloyd 는 성공을 위해 기업이 문제 프로젝트 구현을 중단하거나 계획을 재개한다고 밝혔다. TV 5 대 IT 책임자인 켄 다비스는 CIO 가 어떤 결정을 내리기 전에 이사회와 충분히 소통하는 것이 중요하다고 말했다. < P > "사실, 이미 투자한 돈이 모두 물거품이 될까 봐' 죽은 말' 을 살아있는 말 의사로 삼아야 한다는 생각이 많이 들지만, 나쁜 프로젝트를 계속하는 것이 IT 부서와 업무에 장기적이고 심대한 나쁜 재정적 영향을 미칠 것이라고는 생각하지 않았습니까? (윌리엄 셰익스피어, 윈스턴, 일명언) (윌리엄 셰익스피어, 윈스턴, 일명언) (윌리엄 셰익스피어, 윈스턴, 일명언)." 보험회사 Carole Nash 의 IT 책임자인 Les Boggia 가 자신의 관점을 이야기했다.

John Menzies Distribution 의 IT 책임자인 Frank Coyle 은 문제 프로젝트 취소에 대해 이야기하는 것이 옳다고 판단했습니다. 실제 문제는 언제 프로젝트를 중단할 것인가입니다. < P > 유일하게 반대 의견을 제기한 사람은 BBA 그룹의 IT 이사인 존 오델 (John Odell) 뿐이다. 그는 "이 프로젝트가 이사회의 목표에 직접적인 영향을 미친다면 이사회가 이 문제를 처리해야 한다. IT 부서의 책임은 정보의 피드백과 제안이다" 고 말했다. < P > 그래서 이 주제에 대한 토론은 또 다른 논란을 불러일으켰다. 어떤 상황에서 문제가 있는 IT 프로젝트를 계속해야 하는가? < P > 런던 ICT 의 책임자인 Richard Steel 은 "문제가 극복되고 이득이 실현될 수 있다면, 재평가와 재계획을 한 번 하지 않는 게 어때?" 라고 말했다. 그러므로 문제가 어디에 있는지, 어려움을 극복하는 방법을 항상 알아야 한다. " < P > 대기업이 이런 문제에 직면해 있다면 점진적으로 추진하는 것도 좋은 방법이다.

Blue Square 회사의 CTO 인 Peter Pedersen 은 문제가 있는 IT 프로젝트가 회사 전략의 핵심 부분이고 투자 수익을 가져올 수 있다면 이 프로젝트를 취소해서는 안 된다고 판단했습니다.

edgeIPK 의 CTO 인 Dharmesh Mistry 는 CIO 와 다른 회사 구성원 간의 의사 소통이 중요하다고 판단했습니다. 그는 "이사회가 달성해야 할 것이 주가와 같은 회사 수익에 직접 반영된다면 CIO 는 이 IT 프로젝트를 진행하고 이사회의 요구를 충족시키기 위해 노력해야 한다" 고 말했다. 즉, IT 부서의 직원들이 역할을 하고자 한다면, 그들은 단순히 IT 목표를 달성하기 위해서가 아니라 회사의 관점에서 문제를 보는 것이다. " < P > 때때로' 회사 정치' 도 CIO 들이 내린 결정에 영향을 미친다. Davis Langdon 의 유럽 파트너인 Steve Anderson 은 이사회와의 관계를 유지하기 위해 CIO 들이 번거로운 IT 프로젝트를 중단해서는 안 된다고 말합니다. 그는 이렇게 말합니다. "당신은 이사회를 화나게 하고, 그들의 견해와 어긋나게 하고, 이사회와의 관계를 멀어지게 하고 싶지 않을 것입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 이사회명언) 그래서 온갖 어려움을 극복하고 이 프로젝트를 완성하기 위해 노력해야 한다. "

따라서 이사회가 이미 결정을 내렸기 때문에 대부분의 경우 IT 부서는 어떠한 조치도 취해서는 안 됩니다. Amtrak Express Parcels 의 IT 책임자인 Phil Young 은 "문제가 있는 IT 프로젝트를 중단하는 것은 이사회의 일이라고 생각한다" 고 말했다. 프로젝트 관리자는 존재하는 문제, 왜 이 프로젝트가 중단되었는지 등을 설명해야 한다. "

OneTel 의 CIO 인 Phil Pavitt 는 "프로젝트를 중단하면 종종 내부 문제가 더욱 분명하게 드러날 수 있다" 고 말했다. 한 프로젝트를 취소하는 것만큼 이사회의 주의를 끌 수 있는 것은 없다. " 런던 ICT 의 Richard Steel 은 "사실, 많은 지식을 배우는 것은 하나의 프로젝트 구현에서 얻은 것이며, 물론 실행에 실패한 프로젝트도 포함된다" 고 덧붙였다. < P > 물론, 이 문제를 논의하기 전에 CIO 들이 언제 IT 프로젝트에 문제가 발생하고 실패할 가능성이 있는지를 분명히 알 수 있다는 점을 강조해야 합니다. British Sugar 의 IT 책임자인 Neil Hammond 는 "IT 프로젝트는 너무 많은 자금을 투입한 후에야 프로젝트에 문제가 있다는 것을 발견하고 회사의 명성에 영향을 주지 않도록 효과적인 경보 기술이 필요하다" 고 말했다. < P > 국내 CIO 목소리: < P > 의사 결정을 계속할 때 침몰 비용은 이론적으로 고려하지 않을 수 있지만, 그것은 결국' 비용' 이기 때문에, 정말로' 물수제비' 에 갈 때, 우리는 모두 외국이 반드시 가장 적합한 것은 아니라는 것을 느낄 수 있다. < P > 저는 최근 1 년 동안 기업 정보화 사업에 종사해 정보화 프로젝트 실패 사례를 많이 들었습니다. 하지만 정보화 담당자들에게는 실패할 프로젝트를 중단하기로 한 결정은 정말 힘들었다. (윌리엄 셰익스피어, 윈스턴, 정보화, 정보화, 정보화, 정보화, 정보화, 정보화, 정보화, 정보화) 다음 세 가지 상황이 발생하지 않는 한, CIO 들은 프로젝트를 진행할 수 있도록 최선을 다할 것이라고 생각합니다. 첫 번째 경우, 진행 중인 시스템 공급업체의 도산, 제품에 대한 후속 지원 및 서비스가 없습니다. 둘째, 선택한 제품이 심각한 결함이나 결함을 발견했습니다. 마지막으로, 회사는 생존 위기를 겪었습니다. 그래서, 만큼 프로젝트가 시작 되 면, 우리는, 물론, 프로젝트의 성공을 보장 하기 위해, 쉽게 패배 하지, 계속 해야 합니다. < P > 프로젝트 구현 전에 프로젝트가 실패할지 여부를 알 수 있다고 생각합니다. < P > 필자의 한 친구가 있는 회사는 합자기업으로 당시 해당 회사의 기술부에서 R&D 업무를 담당했다. 제품 구조와 판매 모델이 비교적 특수하기 때문에 ERP 시스템의 판매 모듈은 줄곧 쓸모가 없다. 판매 관리를 강화하고 주문을 효과적으로 통제하기 위해 이 회사의 외국인 IT 관리자는 주문 계획과 통제 시스템을 개발하여 기존 ERP 시스템과 통합하기로 결정했습니다.

시스템 프로토타입이 나올 때 IT 관리자는 사업부가 참여하는 프로젝트 오리엔테이션 세션을 조직했습니다. 프로젝트 소개에서 필자의 친구들은 이 시스템의 설계 아이디어에 8% 이상의 주문이 표준화되고 시리즈화된 제품이라는 중요한 가정이 있다는 것을 알게 되었다. 그러나 국내에서 판매되는 제품으로 인해 고객의 개인화 수요가 비교적 많아 주문의 약 2% 만이 표준화되고 시리즈화된 제품이다. 따라서 이런 설계는 업무 현황에 전혀 적응할 수 없다. 친구가 이에 대해 의문을 제기하다. 그 외국인 IT 매니저는 오만하게 대답했다. "당신들의 임무는 이 소프트웨어를 어떻게 사용하는지 배우는 것입니다. 다른 일은 신경 쓸 필요가 없습니다." 결과는 상상할 수 있다. 사용 6 개월 후, 어쩔 수 없이 이 시스템의 사용을 중단하고, 1 여만원의 개발비가 동류하게 되었다. 나중에 필자는 이 소프트웨어의 일부 문서를 접할 수 있는 특권을 누렸다. 소프트웨어 자체만으로는 디자인이 매우 우수하며, 많은 독창적인 디자인 아이디어들이 ERP 소프트웨어 개발자들의 본보기가 될 수 있다. (윌리엄 셰익스피어, 윈스턴, 소프트웨어, 소프트웨어명언) < P > 이 사례에서 이 프로젝트의 실패는 사실 수요 분석 때부터 이미 정해져 있다는 것을 알 수 있다. 물론 최종 사용자의 비협조도 프로젝트 실패의 중요한 원인이다. < P > 따라서 프로젝트 계획을 실시하기 전에 프로젝트 실패의 위험이 매우 크다고 판단한다면 이 프로젝트를 중단하거나 진행하기로 섣불리 결정하지 마십시오. 이때 프로젝트 책임자가 어떤 요인으로 인한 위험이 더 큰지 자세히 분석해야 합니까? 이러한 요소 중 내부 요소와 외부 요소는 무엇입니까? 제어 가능한 요소와 제어 불가능한 요소는 무엇입니까? 그 중 통제 가능한 요소를 해결하고, 통제할 수 없는 요소들을 분석하다. 통제할 수 없는 요소 제품 또는 파트너의 선택 문제인 경우 완전히 다시 선택할 수 있습니다. 자금 문제라면 추가 투입을 신청할 수 있다. < P > 물론, 프로젝트 구현 전에 비교적 정확한 판단을 내리려면 프로젝트 팀 구성원이 프로젝트 분석 단계에서 프로젝트의 목표와 사용자 요구 사항을 명확히 해야 합니다. 선택형 단계에서 공급자와 제품에 대해 세밀하고 치밀한 고찰을 진행하다. 프로젝트 계획을 세울 때 각 방면과의 효과적인 소통 등.