프로젝트가 실패하는 10가지 이유(1)

프로젝트가 실패하는 10가지 이유(1)

Frank Winters

 

많은 프로젝트(특히 IT프로젝트)가 실패한다. 몇몇 통계를 보면 성공하는 프로젝트보다 실패하는 것이 더 많다는 것을 알 수 있다. Standis그룹, Gartner, 카네기 멜론 대학, PMI 및 다른 기관의 연구를 보면, 프로젝트가 실패하거나 지연되고 예산이 초과되며, 자신들이 설계한 후 만들기로 한 제품을 인도하지 못하고, 어떤 경우는 전혀 제품을 만들어 내지 못하는 경우가 너무 많다는 등 동일한 현실을 지적하고 있다.

 

물건을 빨리 싸게 그것도 좋은 것을 두 개씩이나 고를 수 있는 싸구려 잡화점의 선전 문구를 자주 볼 수 있다. 필자는 최근에 자신의 직원을 오직 고객/사용자 부서의 만족만을 책임지도록 한 상급 IT임원의 말을 들은 적이 있다. 고객 만족도에 의해 측정되는 것이 아니면 스케줄, 예산, 심지어는 품질도 소용이 없다.

 

전혀 쓸모가 없는 대부분의 프로젝트의 인력을 확보하는데 자신이 참여하고 있었다고 이야기하는 고객을 보면 그의 이러한 접근방법에는 합리성이 있는 것 같다. 그는 어떤 대가를 치르더라도 그런 일을 피하고 싶다고 이야기 한다. 이 상황에서 실패는 하나 이상의 이해관계자 그룹이 제대로 돈을 지불하지 않는 것을 의미하는 것은 아니다. 이 특이한 임원은 고객이 원하는 좋은 제품을 만들지 못하는 경우만 제외하고 거의 모든 방법에서 실패하기를 원한다. 이러한 방법으로 그는 자신의 가장 중요한 이해관계자를 즐겁게 하고 있다. 필자가 생각하기에는 그것보다 더 높은 성공의 기준이 있을 것이며 있어야 한다고 본다(독자는 어떻게 생각하는지 궁금하다).

 

프로젝트 실패보다 더 회자되는 것은 실패에 대한 이유이다. 모든 사람들이 의견을 하나씩은 가지고 있는 것 같다. 기대 관리는 일반적으로 엉성하다. 적절하지 못한 계획을 수립하는 것과는 또 다르다. 일반 사람들은 엉성한 변경관리와 모호한 요구 또는 계속 바뀌는 요구 등도 원인이라고 믿고 있다. 수많은 이유 때문에 프로젝트가 실패한다는 것은 명백하다. 독자가 프로젝트 실패를 일으키는 원인이 될 수 있다고 볼 때, 일부 프로젝트가 성공하는 것은 어찌 되었던 간에 기적이다!.

 

필자가 알고 있는 10가지 또는 다른 어떤 10가지에 한하지 않은 많은 요인이 프로젝트를 성공 또는 실패시킨다는 것을 필자는 알고 있다. 카르마, 마약, 전환시점에서 아무런 조치를 취하지 않는 것, 부두 등이 목록에 오르지는 않았지만, 언제가는 올라갈 수도 있을 것으로 본다.

 

이런 모든 실패와 실패의 위험을 고려할 때, 성공의 확률을 높이기 위해 무엇을 할 수 있는가?

잘못될 수 있다는 것을 아는 것은 매우 중요한 수단이다. 그리고 그것이 이글의 목적이다. 이 글은 관련된 위험의 완화에 관해 강조하면서, 실패의 공통적인 원인의 대부분을 찾아낼 프로젝트 실패의 원인에 관한 일련의 기사를 소개한다. 실패의 원인을 이해함으로써 모르긴 몰라도 원인이 예기치 못하게 나타날 때 함정을 피할 수 있다.

 

아래의 내용은 실용적인 상위 10가지 목록이다. 이들은 아래로 내려갈수록 중요하다고 예상할 수 있는 순서로 된 잘 알려진 프로젝트 실패의 이유 가운데 일부이다. 기사 연재에 덧붙여, 곧 논의에 착수하여 실마리를 잡으려고 한다. 틀림없이 실패하기 위한 새롭고 창조적인 결론이 될 것이다. 물론 우리의 목표는 (미리 경계하는 것이 미리 지식을 갖게 하는 것이라는 통속적인 이야기처럼), 가능한 한 재앙을 수시로 피하면서, 사전 경고의 매커니즘을 통해 독자가 지식을 갖게 하는 것이다.

 

프로젝트가 실패하는 10가지 이유

1.     훈련을 제대로 받지 못하고 경험이 미숙한 프로젝트 관리자

2.     기대를 설정하고 관리하는 데 실패

3.     어떤 수준 또는 모든 수준의 엉성한 리더십

4.     적절하게 요구를 확인, 문서화 그리고 추적하는데 실패

5.     엉성한 계획서 및 계획 수립 프로세스

6.     엉성한 인력 견적

7.     문화와 윤리에 제대로 적응하지 못함

8.     프로젝트 팀과 협업 부서 또는 그들을 지원하는 조직 간의 협력 미흡

9.     부적절하거나 잘못 사용된 방법

10.   프로세스 추적과 보고를 포함한 부적절한 의사소통

 

필자는 이것들이 올바른 순서인지에 대해서는 잘 모른다. 그러나 이것이 시작이다. 목록과 순서는 필자의 경험에 근거한 것이며 과학적으로 연구한 것은 아니다. 이 분양의 연구는 주로 여론조사에 의지하는 경향이 있는데 그 이유는 성공 또는 실패의 원인을 가려내는 것이 거의 불가능하기 때문이다.

 

성공 또는 실패에 대한 질문은 그 자체가 마찬가지로 의견에 관한 것이다. 어떤 경우라도, 이번 연재에서 필자가 제공하는 것은 대부분이 프로젝트 관리와 관련된 40년 이상의 IT경험의 혜택 이상도 그 이핟 아니다. 필자는 목록 상에 첫 번째로 올라있는 훈련을 제대로 받지 못하고 경험이 미숙한 프로젝트 관리자가 첫째 원인이라는 것에 강하게 공감하고 있다. 이것이 암시하는 것은 실패는 통제가 가능하며 피할 수 있는 강한 신념이며, PM은 많은 책임과 회계책임을 지며 따라서 그들에게 적절하게 직무를 수행할 수 있도록 권한이 부여되어야 한다는 점이다. 이것은 매트릭스 조직을 사용하는 기업으로서는 상당한 도전이다.

 

그러나 독자의 PM이 권위가 거의 없는 관리자나 촉진자일 경우, 효과적으로 될 것을 기대하는 것은 무리이다. 따라서 매트릭스 조직의 도전은 매트릭스 내에서 프로젝트 관리자의 권한을 키워주는 것이다. 다음 글 에서는 이러한 현안에 대해 좀더 자세하게 다룰 예정이며, 바라건대 독자들에게서도 많은 현안을 주기 바랍니다.

 

필자는 PM 역할의 성격에 대해서도 마찬가지로 논의 할 계획이다. 필자는 대부분의 독자들이 매트릭스 조직에서 PM으로 성공한 방법에 대해 경험을 가지고 있다고 확신한다. 필자의 이야기는 성공과 실패에 대한 경험담이 될 것이다. 독자의 경험담이 있으면 공유하기 바란다.

원문 출처 : 지식스폰지

프로젝트 관리라는 키워드로 찾아낸 정보입니다.
내용을 단순히 긁어서 붙혀 넣은 것이 일일이 타이핑하면서 올렸습니다.
지식스폰지님에게 감사의 말씀을 드립니다.