"변경 관리"는 어디에서 끝나고 "프로젝트 실패"는 시작됩니까?

Question

최근에 "프로젝트 실패"에 관해 상사와 미니 혐의를 받았습니다. 3 년 후, 코드베이스를 새로운 플랫폼으로 마이그레이션하는 프로젝트 (1.5 년 동안 프로젝트를 진행했지만 팀 리드가 몇 개월 동안 켜져 있음)가 실시되었습니다.그 사람은 우리 회사와 고객의 고위 경영진과 함께 있습니다(저는 여러분이 많이 듣는 끔찍한 컨설턴트 중 한 명입니다.내 계약은 "애플리케이션 아웃소싱"입니다.) 프로젝트가 성공했음을 선언했습니다.나는 동의하지 않았으며, 내가 찾은 이전 프레젠테이션에 따르면 원래 일정과 비교하여 배포 지연은 몇 달 만에 측정하는 것이 가장 좋으며 잠재적으로 몇 년 만에 측정할 수 있다는 것이 나타났습니다.나는 프로젝트 실패에 대해 내가 알고 있는 것과 실패율에 대한 연구 및 통계를 설명했습니다.그는 그것이 모두 학계였으며, 자신이 이끄는 프로젝트 중 실패한 프로젝트는 하나도 실패하지 않았다고 답했습니다. 변화/위험 관리의 경이로움 덕분입니다. 이는 지연을 설명하고 새로운 데이터를 기반으로 일정을 재평가하는 것으로 귀결되는 것 같습니다.

이런 컨설팅이 다른 프로젝트와 다를 수도 있지만, 시간, 예산, 전체 기능을 제공하지 못했다는 오명을 피하기 위해 더 예쁜 이름으로 포장된 실패인 것처럼 보입니다.우리 회사가 최대 예산 내에서 프로젝트를 완료하기 위해 몇 시간의 작업 시간을 무료로 제공했다고 그가 설명했다는 사실은 많은 것을 말해줍니다.

그래서 나는 여러분에게 이렇게 묻습니다.

• 변경 관리란 무엇이며 프로젝트에 어떻게 적용됩니까?
• "변경 관리"는 어디에서 끝나고 "프로젝트 실패"는 시작됩니까?

---

@shog9:
나는 컨설턴트와의 비난 게임에 대해 묻지 않았습니다. 특히 이 경우에는 제가 대표하다 컨설턴트.필요한 기능이 있는지 여부에 관계없이 프로젝트가 언제 "실패"한 것으로 간주되어야 하는지에 대한 견해를 찾고 있었습니다. ~였다 드디어 구현했습니다.
저는 "실제로는 우리가 생각했던 것보다 조금 더 복잡하고, 또 한 주가 걸릴 것입니다"라고 예상하는 것과 "프로젝트 실패" 사이의 차이점을 찾고 있습니다. 그러나 실패를 어떻게 정의하든 상관없습니다.심지어 차이가 있나요?이 사소한 수준의 일정 지연이 통계적 "프로젝트 실패"를 의미합니까?

Answer 1

대부분의 경우 우리 개발자들은 우리 모두가 하는 일이 결국 비즈니스에 관한 것임을 잊어버리고 있는 것 같습니다.

그러한 관점에서 볼 때 클라이언트가 기꺼이 비용을 지불할 의사가 있는 한 프로젝트는 실패가 아닙니다.그것은 모두 클라이언트에 달려 있습니다. 일부 클라이언트는 더 많은 인내심을 갖고 소프트웨어 개발의 위험을 더 잘 이해하지만 다른 클라이언트는 상당한 지연이 있는 경우 비용을 지불하지 않을 것입니다.

어쨌든, 귀하의 질문에 대해.프로젝트를 발전시킬 때마다 위험이 수반됩니다. 특정 날짜에 프로젝트 종료를 예약할 수도 있지만 예상보다 6개월 정도 더 오래 걸릴 수도 있습니다.그러한 경우에는 이미 지출한 금액과 감수하고 있는 위험을 대비하여 얻을 수 있는 금액의 균형을 맞춰야 합니다.실제로 소프트웨어 수준에서 이를 연구하는 "의사결정"이라는 전체 과학이 있으므로 상사의 말이 전혀 틀리지 않습니다.

몇 가지 질문을 살펴보겠습니다. 고객이 프로젝트를 기다릴 의향이 있습니까?그는 특정 초과 비용을 기꺼이 감수할 의향이 있습니까?그렇지 않더라도 이미 완료된 작업을 모두 버리는 것보다 추가 비용을 감수하고 프로젝트를 완료할 가치가 있습니까?회사는 이미 손실된 것을 가정할 수 있습니까?

문제에 대한 실제 답은 그 질문 뒤에 있습니다.요점을 확립하고 여기서 프로젝트가 지금까지 완료되지 않으면 실패라고 말할 수 없습니다.귀하의 구체적인 상황은 누가 알겠습니까?당신의 상사는 아마도 당신이 가지고 있는 더 많은 정보를 갖고 있을 것이므로 당신의 임무는 그에게 프로젝트가 어떻게 진행되고 있는지, 얼마나 걸릴지, 비용이 얼마나 들 것인지(원하는 경우 시간/인원 단위로) 알려주는 것입니다.

Answer 2

프로젝트의 시작 부분에서 목표가 명확하게 언급되지 않는 한, "성공"과 "실패"사이에는 명확한 선이 없습니다. 종종 프로젝트는 다양한 수준의 성공/실패를 가질 수 있습니다.

어떤 사람에게는 코드에서 몇 가지 개념을 얻는 것만으로도 성공할 수 있지만, 다른 사람에게는 모든 투자를 회수하고 수익을 창출하는 것으로 성공을 측정할 수도 있습니다.잘 알려진 두 가지 실패 모드는 일정 지연과 품질 저하이지만, 실제로 사람들은 이에 대해 별로 신경을 쓰지 않는 것 같습니다.

일정을 늦추는 간단한 방법은 관리자가 원할 때마다 요청하도록 하고(기능이 계속 추가됨) 프로그래머가 자신이 옳다고 생각하는 모든 코드를 작성하도록 하는 것입니다(카우보이 코딩).다음과 같은 변경 관리 프로세스 스프린트 계획 스크럼과 기획 게임 XP의 몇 가지 예가 있습니다.이는 경영진과 개발자가 신뢰할 수 있는 제품을 제 시간에 출시하기 위한 시도 중 일부입니다.어느 쪽이든 신뢰성이나 정시에 관심이 없다면 변경 관리는 유용하지 않습니다.

Answer 3

프로젝트의 성공 여부는 고객이 누구인지에 달려 있다고 생각합니다.클라이언트가 회사의 이사이고 그들이 만족한다면, 도중의 실패에 관계없이 프로젝트는 성공한 것입니다.

Answer 4

앤디 러틀리지 성공에 관한 매우 흥미로운 기사를 작성했습니다.제목은 그렇지만 사전 입찰 토론, 기사는 정의합니다 성공적인 프로젝트를 가지고, Andy에게는 다음이 수반됩니다.

1. 나 또는 우리 팀이 최선을 다해 최종 결과를 얻을 수 있습니까?
2. 고객이 프로젝트에 적절하게 참여할 준비가 되어 있습니까?
3. 고객이 이 프로젝트를 시작할 준비가 되어 있습니까?
4. 고객은 나 또는 내 팀의 아이디어에 신뢰를 투자할 준비가 되어 있습니까?
5. 나 또는 내 팀은 프로젝트 요구 사항을 충족하거나 초과할 준비가 되어 있습니까?

이 기사는 성공적인 컨설턴트인 Obie Fernandez가 자신의 저서에서 지적한 것입니다. 허슬을 해보세요 컨설팅에 관한 회의.

Answer 5

변경 관리란 무엇이며 프로젝트에 어떻게 적용됩니까?

변경 관리는 변경 사항이 발생하기 전에 프로젝트에 대한 변경 사항을 승인하고 전달하는 것입니다.프로젝트에 누군가(사용자, 스폰서, 팀원..누구든지) 기능을 추가하고 싶다면 변경 사항을 문서화하고 효과를 분석해야 합니다.범위, 예산 및 일정에 대한 모든 변경 사항은 변경을 수행하기 전에 승인되어야 합니다.이러한 변경 사항은 일반적으로 스폰서, 운영 위원회 또는 고객의 승인을 받습니다.

변경 사항이 승인되고 수락되면 이것이 귀하의 새로운 계획입니다.원래 예산이나 일정이 어떠했는지는 중요하지 않습니다.

프로젝트의 변경 관리는 "놀라움이 없음"이라는 원칙에 관한 것입니다.적절한 사람(변경 통제 위원회)은 범위, 일정 및 예산에 대한 변경 사항을 실행하기 전에 승인해야 합니다.

기억해야 할 한 가지는 변경에 대한 특정 명시적 또는 암시적 제약과 허용 오차가 있을 수 있다는 것입니다.정부 규제 요구 사항을 충족하기 위해 특정 날짜까지 프로젝트를 제공해야 할 수도 있습니다.또는 조직에서 프로젝트 예산이 원래 예산의 30%를 초과하면 "C" 수준으로 올라가지 않으면 프로젝트가 중단된다는 임계값이 있을 수 있습니다.이러한 임계값과 허용 오차를 미리 조사하고 명시적으로 명시하는 것은 보다 성공적인 프로젝트를 수행하는 좋은 방법입니다.

"변경 관리"는 어디에서 끝나고 "프로젝트 실패"는 시작됩니까?

프로젝트가 승인된 범위, 일정 및 예산에 맞춰 이행되면 성공적인 것입니다.

그러나 여전히 실패라고 볼 수 있습니다.구현 후 검토는 상사뿐만 아니라 이해관계자들과 함께 이를 검증할 수 있는 좋은 도구입니다.또한 이익 실현은 프로젝트의 블랙박스 외부와 비즈니스 전체에 미치는 영향을 살펴보는 것도 가치가 있을 것입니다.