3
나는 최근에 "프로젝트 실패"와 관련하여 사장과 미니 논쟁을 벌였습니다. 3 년 후, 코드베이스를 새로운 플랫폼으로 마이그레이션하는 프로젝트 (1.5 년 동안 진행되었지만 팀 리더가 단 몇 개월 만에 진행된 프로젝트)가 시작되었습니다. 그는 내 회사와 고객 모두의 고위 경영진과 함께 (나는 당신이 그토록 많이 듣는 신중한 컨설턴트 중 하나입니다. 나의 참여는 "Application Outsourcing"입니다) 프로젝트가 성공으로 선언되었습니다. 나는 발견 한 오래된 프레젠테이션이 원래의 일정과 비교할 때 배포 지연이 몇 달 만에 가장 잘 측정되었으며 잠재적으로 수 년 내에 측정 될 수 있다는 것을 보여 주면서 동의하지 않았습니다. 나는 프로젝트 실패에 대해 내가 알고있는 것과 실패율에 대한 연구와 통계를 설명했다. 그는 그것이 모든 학계라고 응답했으며, 변화/위험 관리의 경이로움 덕분에 실패한 프로젝트는 없었습니다. 새로운 데이터를 기반으로 일정을 지연하고 일정을 재평가하는 것으로 보입니다."변경 관리"종료 및 "프로젝트 실패"는 어디에서 시작합니까?
이와 같은 컨설팅은 다른 프로젝트와 다를 수 있습니다.하지만 시간이 흐르거나 예산이 부족하거나 기능이 완벽하지 않은 오명을 피하기 위해 실패한 것 같습니다. 우리 회사가 최대한 예산 범위 내에서 프로젝트를 끝내기 위해 무료로 여러 시간의 일을 허락했다고 그가 설명했다는 사실은 많은 것을 말해줍니다.
그래서 나는 당신에게 부탁이 :
- 어떤 변화 관리이며, 어떻게 프로젝트에 적용 되는가?
- "변경 관리"종료 및 "프로젝트 실패"는 어디에서 시작됩니까? shog9 @
:
나는이 경우 내가 컨설턴트를 대표 특히 이후, 컨설턴트와 비난 게임에 대해 물어되지 않았습니다. 나는 필요한 기능이 이 마지막으로 구현 된 인 경우 프로젝트가 "실패한"것으로 간주되어야 할 시점에 대한 견해를 찾고있었습니다.
저는 "이것은 실제로 우리가 생각한 것보다 조금 더 복잡합니다. 그리고 그것은 또 하나의 주일 것입니다"라고 생각합니다. 다소 전형적이며 "프로젝트 실패"라고 예상 할 수 있습니다. 실패. 차이점이 있습니까? 이 작은 수준의 일정 미끄러짐은 통계적 "프로젝트 실패"를 구성합니까?