예산을 늘려 프로젝트를 성공시킬 수있는 방법은 무엇입니까?
그래서 저는 이 답변 을 읽고 있었는데 한동안 가지고 있었지만 결코 묻지 않은 질문이 떠 올랐습니다.
범위, 일정 및 품질이 고정 된 늦은 프로젝트가있는 경우 예산을 늘려 문제를 해결할 수 있어야하지만 ... 어떻게?
범위를 제거하거나 일정을 늘리면 실패한 프로젝트를 어떻게 줄일 수 있는지 분명합니다. 그러나 The Mythical Man-Month에 따르면 (그리고 내 경험에 따라) 이미 늦은 프로젝트에 사람들을 추가하면 프로젝트가 더 나아질 것입니다.
그렇다면 ... 정확히 어떻게 무한한 돈을 사용하여 고정 된 범위 / 일정 / 품질 프로젝트를 저장할 수 있을까요?
답변
답변은 개별 프로젝트에 따라 다릅니다. 월리스의 프로젝트 관리 법칙 PM의 주요 업무는 범위, 일정 및 품질에 대한 변경의 영향을 이해 관계자에게 알리는 것입니다.
귀하의 질문은 지각 적입니다. PM을 고용하는 이유입니다. 좋은 PM은 항상 "추가 N % 예산을 주면 어떻게 지출 하시겠습니까? 추가 비용으로 범위, 일정 또는 품질을 어떻게 향상시킬 수 있습니까?"라는 대답을 항상 갖게됩니다.
일부 답은 프로젝트 계획에 있습니다. 프로젝트 계획을 통해 중요 체인과 대체 중요 경로를 계산했습니다. 추가 예산으로 더 그럴듯한 대안은 무엇입니까?
답변 중 일부는 이미 개발 한 다른 질문에 있습니다. 당신의 제약은 무엇입니까? 예산이 증가하면 변경 될 예산 선택 때문에 어떤 선택을해야 했습니까?
대부분 의 답변은 위험 / 문제 로그에 있습니다. 추가 예산이있는 경우 어떤 위험 / 문제가 기회가 될 수 있습니까?
사소한 말다툼; 예산은 프로젝트를 성공시킬 수 없습니다. 무한한 예산은 무한한 성공 확률을 생성하지 않습니다. 예산은 제약이며 프로젝트 성공 확률은 항상 가장 제한적인 제약에 의해 결정됩니다. 예산이 무한하다면 범위 또는 일정이 프로젝트를 지배합니다. 가스 탱크가 비어 있으면 차는 갈 수 없지만, 가스 탱크가 가득 차면 더 빨리 갈 수 없습니다. 예산이 프로젝트를 제한 할만큼 충분히 낮 으면 예산 증가가 성공 확률을 어떻게 향상 시킬지 예측하기 쉽습니다. 예산이 충분히 높으면 추가 예산이 프로젝트 성공에 어떤 영향을 미칠지 예측하기 어렵습니다. 질문의 표현은 실제 문제에서 다소 산만합니다. "예산을 늘려 프로젝트를 성공시킬 수있는 방법은 무엇입니까?" 프로젝트가 예산의 제약을받지 않기 때문에 불가능한 시간의 2/3입니다. 그러나 그것은 질문의 문구와 함께 문제가됩니다.
언 바운드 제약으로서의 예산
매몰 비용으로 돈을 투자한다고해서 실패한 프로젝트가 "절약"되지는 않지만 다른 프로젝트 제약을 충족하기 위해 적절한 리소스를 할당하지 않으면 프로젝트가 처음에 성공할 수 없습니다. 예를 들어, 7 명이 필요한 프로세스를 관리하는 3 명의 개발자가있는 경우 프로젝트가 제 시간에 완료 될 가능성이 낮습니다. 프로젝트가 출시되기 1 주일 전에 개발자 4 명을 더 추가하는 것은 도움이되지 않지만 ( Brooks의 법칙 참조 ), 마지막 책임있는 순간에 적절한 리소스를 추가 하여 장비, 프로세스 및 인력을 신속하게 처리 할 수있는 시간을 허용 할 수 있습니다. 시간 또는 범위 제약을 충족하는 프로젝트.
예산을 미리 적절하게 조정하는 것이 좋습니다. 예산이 클수록 좋은 인력, 프레임 워크 및 기술 교육, 효율성 향상 도구, 고품질 재료 및 장비 등에 투자 할 수 있습니다. 프로젝트 자금을 부족하게하면 제약이 발생하지만 일반적으로 예산만으로는 충분하지 않습니다. Enabler.
다음 예를 고려하십시오.
- 을 감안할 때 프로젝트가 이제 (정해진 일정)로부터 6 개월의 하드 마감 시간을 가지고,
- 그리고 비 negotiatiable (고정 영역) 인 기능 세트
- 프로젝트가 계획 될 때
- 그런 다음 예산 (비용)을 범위와 일정에 맞게 조정해야합니다.
즉, 서로 영향을주는 세 개의 슬라이더가 있습니다. 예를 들어 "속도, 비용 또는 기능; 둘 중 하나를 선택하십시오!"와 같이 두 개만 잠글 수 있습니다. 다른 슬라이더가 더 제한 될수록 언 바운드 차원에서 더 많은 유연성이 필요합니다.
당신이 경우 하지 않는 고정 정점의 요구 사항을 충족하기 위해 예산 정점을 조정, 당신이와 끝까지하지 않는 삼각형 당신은 종종 일시 차입 (또는 자금 부족) 관리 대상으로 끝낼. 그런 일이 발생하면 즉시 프로젝트 비전을 수정해야합니다. "우리는 마법의 사고를 통해 실패를 만듭니다."
비용, 범위, 시간의 철의 삼각형, 두를 선택 , 프로젝트 제약의 모델입니다. 좋은 모델이지만 때로는 한 차원에서만 작업 할 수 있다고 생각하고 나머지 두 가지는 고정 된 상태로 유지하는 사람들을 혼란스럽게합니다. 프로젝트의 시간과 범위가 함께 너무 제한되어있어 금액이이를 상쇄 할 수 없다면 예산을 늘려서 프로젝트가 성공하지 못할 것입니다. 내일 오후까지 다른 사람을 달에 태워주기 위해 1 조 달러를 주면 당신은 할 수 없을 것입니다. 소프트웨어 프로젝트도 마찬가지입니다.
당신이 문제에 너무 늦게 돈을 던지거나 그것으로부터 많은 것을 기대한다면 여전히 문제가 있습니다. 프로젝트가 늦어지고 돈을 너무 늦게 가져 오면 프로젝트가 저장되지 않습니다. Todd의 대답은 이것을 잘 다루므로 더 이상 주장하지 않을 것입니다. 제가 지적하고 싶은 것은 돈이 원동력 이라는 사실입니다 . "고정 된"것들은 갑자기 더 이상 고쳐지지 않을 수도 있습니다.
예를 들어, 프로젝트가 소규모 가상 머신에서 효율적으로 실행되도록 애플리케이션을 최적화하고 하드웨어 리소스를 효율적으로 사용하여 클라우드 비용을 낮게 유지하고 향후 더 효율적인 수평 호출을 허용하는 것으로 구성되어 있다고 가정 해 보겠습니다. 수행해야 할 작업을 식별했으며 2 개월 이내에 수행해야합니다 (어떤 이유로). 한 달 후 팀은 마감일을 놓칠 가능성이 높다는 사실을 알게됩니다. 모든 것이 작동하려면 거기에 정의 된 모든 것이 필요하기 때문에 범위를 줄일 수 없습니다. 그리고 그들은 고정되어 있기 때문에 기한을 이동할 수 없습니다. 그래서 당신은 돈을 가져옵니다. 많이.
더 많은 사람들을 데려 올 수 있지만 그렇게함으로써 Brooks의 법칙이 적용된다는 것을 알게되고 이제 팀은 그들이 더 늦게 될 것이라고 생각합니다. 그러나 시간과 범위는 여전히 고정되어 있습니다. 아니면 그들은?
돈을 가져 와서 찾을 수있는 가장 큰 가상 기계에 넣으면 더 이상 프로젝트의 범위에 대해 전혀 신경 쓰지 않습니다. 고정 범위가 갑자기 완전히 사라집니다. 결국 그렇게 고정되지 않았습니다. 이제 애플리케이션이 클라우드에서 리소스를 많이 차지할 수 있으며 청구서를 지불 할 돈이 있기 때문에 신경 쓰지 않습니다.
결론적으로 :
- 세 가지 제약이 아니라 두 가지만 선택하십시오. 그것은 실제로 모든 것의 균형이며 하나의 변화는 다른 방식으로 다른 영향을 미칩니다.
- 예산을 늘리면 프로젝트를 절약 할 수 있지만 적시에 적절한 작업에 적용해야 합니다.
범위, 일정 및 품질은 프로젝트가 제공해야하는 "무엇"을 정의하지만 제공 할 "방법"은 정의하지 않습니다. 다른 답변에서 언급했듯이 예산이 많을수록 "방법"을 유연하게 조정할 수 있습니다. 내 마음 속에는 "황금 삼각형"이 "황금 피라미드"와 비슷하다고 생각합니다. 여기서 기본 삼각형은 "비용, 시간, 범위"제약 조건으로 구성되고 피라미드의 높이는 "품질"을 정의합니다. 따라서 네 가지 모두 서로 연결되어 있습니다.
프로젝트에 무차별 적으로 자원을 투입하는 것은 거의 효과적이지 않지만시기가 적절하다면 더 많은 자원이 프로젝트를 제 시간에 품질로 가져올 수 있습니다. 어떻게? -글쎄, 정답은 하나도 없지만 프로젝트를 더 관리하기 쉬운 부분으로 나누고 프로젝트의 올바른 요소에 올바른 리소스를 할당하는 것이 일반적으로 프로젝트를 조정하지 않고 더 많은 개발자를 혼합에 투입하는 것보다 낫습니다.
또는 더 많은 자금이 완전히 다른 접근 방식을 허용 할 수도 있습니다. 예를 들어, 비싸지 만 상업적으로 이용 가능한 솔루션을 구입하는 비용을 피하기 위해 사내에서 솔루션을 구축하는 대신 추가 비용이 그 결정을 바꿀 수 있습니다. 예상되는 결과를 계속 제공하지만 솔루션을 구축하는 대신 구매하게됩니다. 그러나 다시 한 번 프로젝트에서 너무 늦게까지 기다리면 실패 할 것입니다.
제가 말하고자하는 것은 문제를 조기에 파악하면 프로젝트를 제공하기 위해 더 많은 비용을 효과적으로 지출 할 수있는 조치를 취할 수 있다는 것입니다. 이것이 핵심입니다. 타이밍이 전부입니다. 당신의 손가락을 꼬집고 그것이 안될 것이라는 것이 분명해질 때까지 "밤에도 괜찮아 질 것"을 바라는 것은 재앙의 비결입니다. 적절한 프로젝트 관리, 추적, 모니터링, 위험 분석, 계획 및 프로젝트 스폰서와의 대화는 항상 배당금을 지급하고 가능한 한 빨리 문제를 식별 한 다음 필요한 돈을 지출함으로써 효과를 발휘할 수있을만큼 일찍 변경할 수 있습니다. (또는 접근 방식의 다른 측면을 변경) 새로운 문제를 해결합니다.
예, "돈을 모으는 방법"에 대한 보편적 인 대답을 갖는 것이 좋을 것입니다. :) 그러나 당신이 선택해야한다면 나는 대부분의 시간에 고품질 비트가 제때에 있다고 생각 합니다.
물론 우리는 종종 일정을 늦추고 위의 누군가가 압박을 시작하고 포기하고 속도를 높입니다. 그러나 우리가 나쁜 제품으로 끝날 경우 우리는 항상 나쁜 프로그래머로 기억 될 것입니다. 사람들이 몇 년 전에 완성 된 제품의 품질에 대해 불평하는 것을 들었습니다. 사용자는 불편한 도구를 계속 사용하기 때문에 여전히 개발자를 싫어합니다 (실제로 개발자는 나쁘지 않았습니다).
동시에 몇 가지 중요한 기능을 완료하지 않으면 잠시 개집에있을 것이지만 비즈니스 요구로 인해 프로젝트에 추가 자금 이 지원 될 가능성이 있습니다 .
하지만 문제가 많은 프로젝트에 참여했다면 문제를 해결하고 속도를 높일 수 있습니다.
저는 Brooks Law의 신자이지만 100 % 프로젝트에서 100 % 100 % 사실이라는 개념에 동의하지 않습니다. 작업에 따라 작업자를 추가하면 결과에 영향을 미치는 알려진 변수와 알려지지 않은 변수에 따라 작업, 환경, 사용 가능한 작업 자료에 따라 일정과 품질 모두에서 다양한 결과를 얻을 수 있습니다.
그래서 저는 무한한 예산이 현실이라면, 특정 유형의 근본 원인 문제에 대해 일부 프로젝트, 일부 환경에서 일정이나 품질 문제에 직면 한 문제 프로젝트에 유리하게 영향을 미칠 수 있다고 생각합니다. 나는 그것이 PM과 팀이 사례별로 평가해야 할 것이라고 생각하며 우리 결과에 영향을 미치는 다른 무작위 변수를 사용하면 때때로 이기고 다른 시간을 잃을 것이라고 생각합니다.
내 대답이 모호하고 모호하다고 느낍니다. 그러나 복잡한 환경에서 복잡한 인간을 다루는 복잡한 프로젝트도 마찬가지로 모호하고 모호하다고 생각합니다. 분석, 혁신, 실험 및 위험 감수가 필요합니다.