[프로젝트 실패의 원인] 프로젝트 실패 인적자원 때문인 경우는 작다.

많은 통계와 사례를  IT프로젝트 성공율에 대한 평가가 좋지 못한 것이 사실입니다.

IT프로젝트 성공율은 30%도 체 도달하지 못하는 경우가 많습니다.
(CHAOSR보고서를 보면 시간이 지날수록 성공율은 올라가긴 하지만, 30%를 넘지 못하는 경우가 많다고 보고하고 있습니다.)

이런 현상은 프로젝트의 규모가 클수록  (성공률) 더 낮게 나오고 있습니다.

프로젝트 실패의 원인에 대해서 우리는 흔히 인력에 대한 부분이 가장 높다고 생각하는 경우가 많습니다.
인력관리는 프로젝트 성공을 위한 중요한 활동임에 틀림이 없습니다.
투입시기 및 일정, 외주관리, 스킬함양등등 인력활동이 중요한 요건이라고 생각하고 있으며 특히 인력 투입시기와 기술적 요건을 실패를 가져오는 직접적인 요인이라고 말하곤 합니다.

하지만 인력에 의한 프로젝트 실패는 큰 비율을 차지 하지 않습니다. 오히려 팀원보다 Manager의 역량에 의한 실패는 더 큰 이유입니다.

“무능력한매니저밑에서는외계인으로부터인류를구하는것이프로젝트의목표라고하여도팀원들은노력하려고애쓰지않는다.”–에드워드요든

팀원이 제대로 움직이도록 하는 것은 매니저에 있습니다.

팀원의 숫자가 생산성에 비례한다는 것은 잘못된 생각 입니다.

어느 회사의 임원급 사람이 자신의 회사가 가지고 있는 힘은 직원이 많다는 것이라며 공공연하게 말하곤 했습니다. "수행하고 있는 많은 프로젝트중 문제가 발생하면 회사내 가용할 수 있는 인력을 많이 넣어 반드시 수행한다."

얼핏 듣기로는 맞는 말 같지만, 프로젝트 관리라는 차원으로 본다면 얼마나 위험한 생각을 가지고 있는지 금방 알 수 있습니다.
시간은 한정되어 있고, 프로젝트 일정에 따라 또는 팀원의 경험 혹 스킬 부족의 해석으로, 밀어 붙이면 된다는 판단은 어리석은 생각입니다.

일 정이 지연되는 것은 팀원의 스킬이나 경험 부족이 잘못된 것이 아니라, 잘못된 일정계획과 그런 상황에 대한 무감각한 결정권자들의 무능력함이 더 큰 이유일 것입니다. - 물론 팀원의 스킬이나, 경험부족이 원인이 될 수 있을지 모르나, 그런 팀원을 적정하게 배정하지 못하는 매니저의 능력부족이 더 큰 원인인 것입니다. -
일정의 지연은 팀원(능력이 되던 안되던, 경험이나 스킬이 부족하던 탁월하던)에 따란 제대로된 일정 계산과 계획의 문제가 원천적인 이유라고 봐야 할 것입니다.

그래도 아직 매니저는 할 말이 있습니다. 제대로 된 인력만 준다면 문제 없이 프로젝트를 순조롭게 할 수 있다.

Bruce Wayne Tuckman 는 오히려 팀의 진화를 말하고 있습니다.

● 팀개발의 단계. 프로세스

1. 탐색기(Forming). 프로젝트 팀 개시 단계.
   • 프로젝트 팀은 테스트를 통해 1차로 달성된 오리엔테이션과 관계가 있다. 그러한 테스트는 개인간 행동과 과제행동의 경계를 확인하는 기능을 한다. 개인과 리더, 다른 그룹 구성원 또는 기존의 표준과 의존관계의 구축은 개인간 영역에서 테스트와 일치한다.
   • 팀원은 매우 독립적으로 행동한다. 그들은 동기부여가 되어 있을 수 있지만 보통은 팀의 목표와 문제에 대해 상대적으로 잘 알지 못한다. 일부 팀 구성원들은 불확실하고 우려하는 특징을 보여줄 수 있다.
   • 프로젝트 매니저는 팀원들이 서로 신뢰하고 작업관계를 개발하는 능력을 보유할 수 있도록 하며 팀을 단결시킨다. 지시 또는 스타일. 탐색기, 준비기, 형성기, 수행기의 개념을 팀과 공유하는 것은 도움이 될 수 있다.
2. 준비기(Storming). 다양한 아이디어가 종종 격렬하게 고려된다.
   • 프로젝트 팀은 신뢰를 얻는다, 그러나 개인간 문제점을 둘러싸고 대립과 갈등이 있다.
   • 팀원은 각자의 아이디어와 관점이 서로 대치하게 되면 자신들의 개성을 보여준다. 목표, 기대, 역할 그리고 책임에 대한 실망 또는 의견 불일치는 공개적으로 표현된다.
   • 프로젝트 매니저는 이러한 혼란스런 변화단계을 통해 프로젝트팀을 안내한다. 코칭 스타일. 각 팀원 및 그들의 차이에 대한 포용력은 강조될 필요가 있다.
3. 형성기(Norming). 규칙, 가치, 행동, 방법, 공구는 설치되고 있다.
   • 프로젝트 팀의 효과는 증가하고 팀은 팀의 아이덴터티를 개발하기 시작한다.
   • 팀원은 팀이 좀 더 자연스럽고 유동적으로 만들기 위한 의견일치를 해나감에 따라 자신들의 행동을 서로에게 맞춘다. 문제해결과 그룹의 조화를 위한 의식적인 노력. 동기부여 수준은 증가하고 있다.
   • 프로젝트 담당자는 팀이 좀 더 자율적이 되도록 한다. 참여적인 스타일.
4. 실행기(Performing). 개인간 구조는 업무 활동의 도구가 된다. 역할은 유연하고 기능적이며 그룹 에너지는 업무에 집중된다.
   • 프로젝트 팀은 이제 하나의 단위로 기능할 수 있다. 부적절한 갈등 또는 외부감독의 필요없이 작업을 부드럽고 효과적으로 마무리한다.
   • 팀원은 하나의 업무수준에서 자신들에게 필요로하는 것을 분명히 이해하고 있다. 팀원은 역량이 갖추고 자율적이며 감독없이 의사결정 과정을 다룰 수 있다. "할 수 있다"는 태도가 보여진다. 서로 도움이 되는 제안을 한다.
   • 프로젝트 매니저는 팀이 스스로 필요한 결정을 내리도록 한다. 권한위임 스타일.
5. 휴지기(Adjourning). 과제는 완료되고 팀은 해체된다.
   • 프로젝트 팀. 일부 저자들은 그룹구성원들이 느끼는 상실감을 인식하여 5단계를 변화기와 애도기(Deforming and Mourning)로 묘사한다.
   • 미래에 대한 불확실성이 나타나기 시작하면 팀원들의 동기부여 수준은 떨어질 수 있다.
   • 프로젝트 담당자: 팀 발달의 형성기를 재개하기 위하여 새로운 프로젝트를 도입하기 좋은 시점. 분산 스타일.

                                                                                     - Bruce Wayne Tuckman

출처 : http://www.12manage.com/methods_tuckman_stages_team_development_ko.html 발췌.

팀원과 기술적 구현은 프로젝트 실패의 큰 원인은 아니다.

프로젝트팀에나쁜영향을미치는요인들

1.비합리적인프로젝트범위와데드라인
2.끊임없이변경되는요구사항
3.나쁜프로젝트매니저
4.오버타임과일중독자
5.정치적혼란
6.비전문가들에의한부적절한작업
7.커뮤니케이션통로의부재
8.프로젝트목표와상관없는겉치레와같은몸짓들

팀빌딩 및 동기여부의 기술

– 팀원들이종결감을느끼게하라
– 엘리트의식을느끼게하라
– 이질성을허락하고격려하라
– 성공적인그룹을잘보호하고유지하라
– 전술적인것이아니라전략적인방향을제시하라
– 불완전한제품(싸구려제품)을만드는일에, 공동의만족감이란있을수
   없음을기억하라

동기부여와관련해서알아야할것

– 뛰어난개발자는평범한개발자에비해5~28배까지뛰어나다
   • 하지만급여는2배가되지못한다
– 개인간5배이상의생산성차이는일반적이다
– 소프트웨어개발에있어기술이부족한다수의사람보다뛰어난소수의사람이
   훨씬낫다
– 작업환경은생산성과품질에상당한영향을미친다
– 중요한점은“팀원의생산성을어떻게최대한이끌어내는가?”이다

- 자료출처 : PM관련 MS 세미나 TechNet_RC840_presentation

freepower님께서 강팀장의 글을 읽고 "인력이 제때 들어오지 않으면 결국 프로젝트에는 큰 위험이 발생하게 되는 것 아닙니까? 그 자체가 인적자원의 문제인것 같습니다" 라는 글을 보내 주셨습니다.

맞습니다. 이 글은 한가지 전제를 두고 있어야 합니다. "회사에서 인력투입을 프로젝트 진행 계획대로 투입을 시켰을때"의 상황을 말하는 것입니다.

넓 은 의미의 프로젝트를 본다면 적절한 인력투입 시기와 투입여부 또한 프로젝트의 인적자원관리라고 볼 수 있습니다만, 더 중요한 것은 투입시기 산출과 투입여부 또한 매니저의 역활중 하나 입니다.  회사가 인력을 투입해 주던 안 해주던 매니저는 그 역활을 위해 최선 다해 활동을 해 주어야하고 그에 따른 책임을 가져야 할 것입니다. 반면 회사는 매니저가 그런 활동을 하도록 매니저로써 권한을 명확히 해야 합니다.



우리는 2가지 고질적인 문제점을 가지고 있습니다.

1. 거의 대부분의 회사에서는 인적자원이 확보 여부와 관계 없이 프로젝트를 진행하고자 한다.
회 사는 간혹 이후 프로젝트를 위한 프로젝트를 하는 경우가 많습니다. 이런 경우는 주로 정치적인 프로젝트가 될 가능성이 높습니다.정치적 프로젝트는 그 자체가 많은 위험요소를 지니고 있는데 그중 가장 고질적인 부분이 최소로 최대한 이라는 생각을 가지고 있다는 것 입니다. 

2. 매니저에게 정확한 권한과 책임이 주어지지 않는다.
프 로젝트를 진행할때 매니저의 역활은 굉장히 중요합니다. 하지만 그에 따른 권한과 책임을 주지 않고 이중적 잣대를 가지고 본다는 것입니다.  간혹 권한은 없고 책임만 묻는 것이 거의 대부분 회사의 행태인 것 같습니다. 전 이 또한 매니저를 관리하는 윗 사람들의 자질에 문제가 있다고 봅니다.

1번째를 어느정도 완화시킬 수 있는 대안은 2번에 있습니다만.... 여전히 회사도 매니저도 할말이 많을 것 같습니다.