[프로젝트 실패의 원인] 프로젝트 실패 인적자원 때문인 경우는 작다.
http://ebizstory.com/eyg/330
위 글에서 나온 것처럼 IT산업에서 진행되는, 특히 SI형태의 프로젝트는 그 성공율이 낮다.
약 30%정도 되는데 이 수치는 당초 계약상의 기준에 의한 성공수치이어서 실질적인 수치는 더 클 것이다.

수 많은 돈과 시간을 들여 진행하는 프로젝트인데, 일정도 다 계획하여 진행하는데
도대체 원인은 어디에 있는가?
그 원인의 답은 관.리.자.에 있다.
하지만 PM, 팀장은 이에 동의 못할 것이다. 실패의 원인은 요청사항이 바뀌거나, 일에 양에 비해 당초 일정이 부족했다고 이야기 할 것이다. 하.지.만 이것들도 PM,팀장들의 능력이다. 당신이 프로젝트를 진정 성공으로 이끌고 싶다면 위와 같은 것들을 사전에 다 확정하고 시작했어야 옳다. 그 모든건 관리자의 책임이다.
의외로 인력이 성공여부에 있어서 그 portion이 작다는걸 알게되었다.
훌륭한 계획이 있다면 다른것이 부족해도 성공에 이르게 할 수 있다는 것이다.
단, 그 훌륭한 계획은 회사경영진들이나 고객의 외압이 없을 경우에나 제대로 세워질 수 있지 않을까. 한국에서는 말이다...
톰 디마르코와 키모시 리스터는 'Waltzing with Bears-리스크관리" 책에서 말하는 모든 소트웨어 프로젝트에 공통적인 리스크로 5가지.
1. 일정의 결함
2. 요구사항의 확대
3. 투입인원의 불확실성
4. 설계 명세서의 불확실성
5. 팀원의 낮은 수행능력
http://ebizstory.com/eyg/330
위 글에서 나온 것처럼 IT산업에서 진행되는, 특히 SI형태의 프로젝트는 그 성공율이 낮다.
약 30%정도 되는데 이 수치는 당초 계약상의 기준에 의한 성공수치이어서 실질적인 수치는 더 클 것이다.

위 그림과 같이 성공의 수치는 크게 나아지지 않는 형국이다.
여기서 우리가 가지는 궁금증.
그럼 원인은 어디에 있는가?
여기서 우리가 가지는 궁금증.
그럼 원인은 어디에 있는가?
수 많은 돈과 시간을 들여 진행하는 프로젝트인데, 일정도 다 계획하여 진행하는데
도대체 원인은 어디에 있는가?
그 원인의 답은 관.리.자.에 있다.
하지만 PM, 팀장은 이에 동의 못할 것이다. 실패의 원인은 요청사항이 바뀌거나, 일에 양에 비해 당초 일정이 부족했다고 이야기 할 것이다. 하.지.만 이것들도 PM,팀장들의 능력이다. 당신이 프로젝트를 진정 성공으로 이끌고 싶다면 위와 같은 것들을 사전에 다 확정하고 시작했어야 옳다. 그 모든건 관리자의 책임이다.
의외로 인력이 성공여부에 있어서 그 portion이 작다는걸 알게되었다.
훌륭한 계획이 있다면 다른것이 부족해도 성공에 이르게 할 수 있다는 것이다.
단, 그 훌륭한 계획은 회사경영진들이나 고객의 외압이 없을 경우에나 제대로 세워질 수 있지 않을까. 한국에서는 말이다...
프로젝트팀에나쁜영향을미치는요인들
1.비합리적인프로젝트범위와데드라인
2.끊임없이변경되는요구사항
3.나쁜프로젝트매니저
4.오버타임과일중독자
5.정치적혼란
6.비전문가들에의한부적절한작업
7.커뮤니케이션통로의부재
8.프로젝트목표와상관없는겉치레와같은몸짓들
2.끊임없이변경되는요구사항
3.나쁜프로젝트매니저
4.오버타임과일중독자
5.정치적혼란
6.비전문가들에의한부적절한작업
7.커뮤니케이션통로의부재
8.프로젝트목표와상관없는겉치레와같은몸짓들
팀빌딩 및 동기여부의 기술
- 팀원들이종결감을느끼게하라
- 엘리트의식을느끼게하라
- 이질성을허락하고격려하라
- 성공적인그룹을잘보호하고유지하라
- 전술적인것이아니라전략적인방향을제시하라
- 불완전한제품(싸구려제품)을만드는일에, 공동의만족감이란있을수
없음을기억하라
- 엘리트의식을느끼게하라
- 이질성을허락하고격려하라
- 성공적인그룹을잘보호하고유지하라
- 전술적인것이아니라전략적인방향을제시하라
- 불완전한제품(싸구려제품)을만드는일에, 공동의만족감이란있을수
없음을기억하라
동기부여와관련해서알아야할것
- 뛰어난개발자는평범한개발자에비해5~28배까지뛰어나다
• 하지만급여는2배가되지못한다
- 개인간5배이상의생산성차이는일반적이다
- 소프트웨어개발에있어기술이부족한다수의사람보다뛰어난소수의사람이
훨씬낫다
- 작업환경은생산성과품질에상당한영향을미친다
- 중요한점은"팀원의생산성을어떻게최대한이끌어내는가?"이다
• 하지만급여는2배가되지못한다
- 개인간5배이상의생산성차이는일반적이다
- 소프트웨어개발에있어기술이부족한다수의사람보다뛰어난소수의사람이
훨씬낫다
- 작업환경은생산성과품질에상당한영향을미친다
- 중요한점은"팀원의생산성을어떻게최대한이끌어내는가?"이다
- 자료출처 : PM관련 MS 세미나 TechNet_RC840_presentation
● 팀의진화과정
-포밍(forming) 단계
• 목표, 역할, 팀의방향을정의한다
-스토밍(storming) 단계
• 규칙과프로세스를정의하고종종팀원의역할을재조정한다
-노밍(norming) 단계
• 표준, 절차, 여러가지기준에대해합의한다
-퍼포밍(performing) 단계
• 팀이하나의시스템처럼기능을수행한다
- 로버트 바인더
-포밍(forming) 단계
• 목표, 역할, 팀의방향을정의한다
-스토밍(storming) 단계
• 규칙과프로세스를정의하고종종팀원의역할을재조정한다
-노밍(norming) 단계
• 표준, 절차, 여러가지기준에대해합의한다
-퍼포밍(performing) 단계
• 팀이하나의시스템처럼기능을수행한다
- 로버트 바인더
톰 디마르코와 키모시 리스터는 'Waltzing with Bears-리스크관리" 책에서 말하는 모든 소트웨어 프로젝트에 공통적인 리스크로 5가지.
1. 일정의 결함
2. 요구사항의 확대
3. 투입인원의 불확실성
4. 설계 명세서의 불확실성
5. 팀원의 낮은 수행능력