해결 방법을 원하는 고객을 위한 정보
이 문서는 "트렌치에서" 컬렉션의 일부입니다. 프로젝트를 예약할 때 발생할 수 있는 몇 가지 일반적인 문제에 대해 설명합니다. 작업 기간을 결정하고 프로젝트 일정을 최적화하기 위해 수행해야 하는 작업 수를 결정하려고 할 때 가장 좋은 방법을 설명합니다. 다양한 산업이 일반적으로 다양한 유형의 일정(예: 소프트웨어 개발, EPM(엔지니어링, 조달 및 건설) 및 플랜트 종료)를 요구하는 방법에 대해 설명합니다. 또한 프로젝트 해결을 선택하는 몇 가지 요인(예: 프로젝트 길이, 관련된 리소스, 리소스 관리 또는 분할, 데이터 수집에 필요한 속도 및 노력, 데이터 업데이트 일정)에 대해서도 설명합니다.
이 문서의 Word 버전을 다운로드하려면 해결 방법을 원한다고 말합니다. 백서(Project Server 2010)를 참조하세요.
더 많은 문서를 보려면 "참호에서" 백서를 참조하세요.
해결 방법을 원하는 고객을 위한 정보
타이틀에 대한 비틀즈의 사과와 함께, 오늘의 주제는 프로젝트의 해결이다.
일정을 만드는 방법에 사용할 수 있는 자료가 많지만 가장 중요한 단원 중 하나는 프로젝트 일정에 수행해야 하는 작업 수와 각 작업이 얼마나 길어야 하는지 등 매우 어렵습니다.
일정이 요약 수준에 있기 때문에 일정에서 문제를 정확히 파악하는 데 무력해 보이는 프로젝트 관리자나 매우 복잡해 보이는 프로젝트 일정에 정기적으로 직면합니다. 저는 100년이 넘는 긴 프로젝트(예, 정말로)를 보았는데, 이 프로젝트는 길이가 완벽하게 적절하고 수십 년 동안 진행된 몇 가지 작업이 있었습니다. 또한 완벽하게 적절하고 일부 작업이 단 1분만 지속된 프로젝트 일정은 한 시간 이하로 지속되는 것을 보았습니다. 소수의 작업만 있는 프로젝트와 100,000개가 넘는 작업을 가진 프로젝트를 보았습니다.
현재 사용하는 소프트웨어는 수천 개의 작업과 광범위한 기간을 처리할 수 있습니다.
그렇다면 올바른 접근 방식은 무엇일까요?
작업은 얼마나 걸리고 프로젝트 일정을 최적화해야 하는 기간은 몇 개입니까? 나는 이것을 프로젝트의 해결이라고 부를 것이다.
다른 사람들을 위한 다른 스트로크
요구 사항은 다른 산업, 다양한 종류의 프로젝트 및 다양한 상황에 따라 다를 수 있으므로 일정에 넣을 작업 수와 작업 기간을 결정하는 방법을 살펴보겠습니다.
프로젝트의 다른 종류는 자연스럽게 일정의 다른 종류를 요구합니다. 다음 세 가지 예제를 살펴보겠습니다.
소프트웨어 개발. 많은 소프트웨어 프로젝트에는 일반적인 특성이 있습니다. 모든 소프트웨어 프로젝트는 고유하지만 일반적으로 디자인 단계, 프로그래밍 단계, 품질 보증 단계, 문서 단계 및 배포 단계가 있습니다. 소프트웨어 프로젝트는 일반적으로 몇 주 또는 몇 달 단위로 측정되며, 이는 하루에서 2주까지의 작업에 도움이 됩니다. 여기서 리소스 할당은 종종 개별 수준에 할당됩니다.
소프트웨어 개발을 위한 Agile 프로세스를 수용한 사람들은 1~2주 동안의 짧은 "스프린트"와 그 스프린트 내에서 짧은 기간의 작업을 배치하지만 전체 프로젝트 기간은 여전히 몇 주 안에 측정됩니다. 나중에 Agile 개발에 대해 자세히 살펴보겠습니다.
EPC - 엔지니어링, 조달 및 건설. EPC 프로젝트는 중요한 경로 예약 방법론이 시작된 곳입니다. 이런 종류의 프로젝트에서 매우 큰 무언가가 개발되고 있습니다. PERT 다이어그램을 시작한 폴라리스 미사일 프로젝트와 같은 대규모 방어 프로젝트이거나 해상 석유 굴착 장치, 새로운 선박 또는 발전소일 수 있습니다. 이러한 종류의 프로젝트에는 완료된 프로젝트가 구상되는 엔지니어링 단계가 있습니다. 엔지니어링 단계에는 일반적으로 이전에 디자인된 적이 없는 몇 가지 측면이 있습니다. 조달 단계에서는 프로젝트 요소에 대한 공급 또는 하위 계약의 전달을 찾고, 계약하고, 관리하는 것을 살펴봅니다. 건설 단계에서 최종 제품이 생성되고 사용 시운전됩니다. 일반적으로 몇 개월 또는 몇 년 동안의 EPC 프로젝트 일정을 생각하며 활동 기간은 몇 주에서 몇 달까지 지속됩니다. 이러한 프로젝트에 5,000~20,000개 작업을 수행하는 것은 전혀 드문 일이 아닙니다. 여기서 리소스 예약은 거의 항상 개인이 아닌 기술 수준에 할당되며( 재미를 더하기 위해) 관리 용이성을 위해 프로그램 또는 마스터 프로젝트로 만든 많은 하위 프로젝트가 있을 수 있습니다.
공장 가동 중지. 공장 가동 중지 및 유지 관리를 위한 소요 시간 동안 프로젝트 일정을 수행하는 경우 가능한 가장 어려운 일정 예약 환경 중 하나에서 작업하게 됩니다. 유지 관리를 위한 공장 가동 중단은 계획 및 비상 사태의 두 가지 버전으로 제공됩니다. 잠시 비상 유형을 제쳐두겠습니다. 그것은 그 자체로 세계입니다. 계획된 공장 가동 중단 기간은 공장 유형에 따라 크게 달라집니다. 예를 들어 원자력 발전소는 12개월 만에 "빠른" 공장 가동 중단 및 턴어라운드를 수행할 수 있습니다. 정유 공장은 4~6주 동안 지속될 수 있습니다. 그러나 가장 흥미로운 공장 프로젝트 일정의 유형은 제철소, 제지 공장 또는 이와 유사한 제조 공장입니다. 전 세계에는 수천 또는 수만 개의 식물이 있으며 매년 정기적으로 유지 관리해야 합니다.
이러한 상황에 대한 종료 비용은 일반적으로 기회 비용으로 측정됩니다. 공장이 유휴 상태이고 유지 관리를 진행하는 동안 생산되지 않을 제품의 비용. 이 비용은 시간 단위로 측정되며 비용은 시간당 $150,000에서 $250,000 이상일 수 있습니다! 그래서 작업을 완료하기 위해 분당 압력이 있습니다. 이러한 상황에서 종료는 일반적으로 5-8일 동안 지속되며 하루의 지연은 수백만 으로 계산됩니다. 더 길고 전통적인 일정에만 익숙한 경우 며칠 안에 "일반적으로 몇 개의 작업이 있을 수 있습니까?"라고 생각할 수 있지만, 이러한 종료가 각각 15분에서 2시간까지 지속되는 2,000~4,000개의 태스크가 있는 것은 전혀 드문 일이 아닙니다. 여기서 리소스 할당은 기술로 수행되지만 리소스 평준화는 인력에서 거의 수행되지 않습니다. 시간당 비용이 너무 강렬하기 때문에 프로젝트에 더 많은 사람들을 배치하면 문제가되지 않으며 서둘러 완료하십시오. 이 상황에서 리소스 평준화는 종종 매우 제한된 병목 현상에 대해 수행됩니다. 예를 들어 "전기실에 두 사람만 맞출 수 있으므로 별도로 관리해야 합니다."
이제 세 가지 종류의 예제가 있으며 더 많은 예제가 있지만, 이 세 가지는 토론의 목적을 잘 제공할 것입니다. 유형 1(소프트웨어 개발)에서는 일반적으로 하루 또는 이틀에서 2주까지 걸리는 작업을 가져옵니다. EPC(유형 2)에서는 몇 주 또는 몇 달이 긴 작업을 가져옵니다. 유형 3(공장 종료)에서는 최대 6분(1/10분의 시간), 10분, 15분(시간당 1/4)의 단위로 측정된 작업을 최대 2시간 동안 가져옵니다. 경우에 따라 짧은 작업이 의미가 있고 다른 경우에는 긴 작업이 더 적합하다는 것이 분명합니다. 동일한 논리에 따라 때로는 많은 수의 작업을 수행하는 것이 합리적이며 때로는 그렇지 않을 수도 있습니다.
프로젝트 해상도를 선택하는 요인
이러한 세 가지 차이점으로 인해 2개월 간의 EPC 프로젝트 작업이 6일 간의 종료 일정에서 우스꽝스럽게 보이고 EPC 또는 소프트웨어 프로젝트에서 15분 작업이 중단될 것이라는 점을 쉽게 알 수 있습니다. 그러나 이 문서를 다시 언급하고 "Vandersluis는 소프트웨어 프로젝트라고 말하므로 작업은 1-10 일 밖에 걸리지 않습니다"(그리고 제발, 그렇게하지 마십시오)프로젝트의 특징은 우리에게 어떤 수준의 해상도를 선택할 수 있는지 알려줍니다. 몇 가지 명백한 사항을 살펴보겠습니다.
프로젝트 기간은 얼마인가요?
가장 명백한 것으로 시작해 보겠습니다. 종료 예제와 같이 프로젝트가 며칠이 소요될 것으로 예상되는 경우 며칠에 걸친 작업을 갖는 것은 전혀 의미가 없습니다. 하향식 접근 방식으로 시작하는 것은 범위를 하위 분할하는 것에 대해 생각할 때 생산성이 높은 경우가 많습니다. 작업 분석 구조 사고를 사용합니다. 주요 구성 요소부터 시작합니다. 항목이 4개 이하이고 항목이 20개 이하인 경우를 생각해 보세요.
규칙인가요? 아니 당연히 아니지.
그것은 상식이다. 4 미만은 당신이 전혀 작업을 분할하고 20 이상은 한 번에 하나의 마음에 개최하기에 너무 어려운 이유를 궁금해합니다. 개인적으로 나는 WBS 요소 당 8 개 이하의 항목으로 가서 팔각형이 마음이 즉시 인식 할 수있는 가장 복잡한 간단한 모양이라고 제안 몇 년 전에 읽은 일부 기사 때문입니다.
잠시 생각해 보십시오. 원, 삼각형, 사각형, 펜타곤, 6면이 있는 육각형, 7면이 있는 헵타곤(확인, 시각화하기 어려운 것) 및 팔각형을 식별할 수 있습니다.
계산하지 않고 9면 셰이프를 식별할 수 있나요? 할 수 없습니다. 그것은 당신이 퀴즈 버프를 위해 "nonagon"이라고합니다.
그래서, 개인적으로, 나는 8 항목 제한을 위해 노력하지만 엄지 손가락의 내 규칙은 4-20입니다.
살펴본 각 요소에 대해 작업을 분할하는 방법에 대해 생각해 보세요. 다시 말하지만, 4-20 규칙을 생각해보십시오. 그러나 언제 멈출지 아는 것은 비밀입니다. 최신 프로젝트 관리자는 복도의 모든 단계가 관리되는 작업일 때까지 하위 분할 및 하위 분할 및 하위 분할을 수행합니다. 작업의 길이에 대해 스스로에게 물어볼 수 있는 몇 가지 좋은 분수령 질문은 다음과 같습니다.
이 작업이 늦으면 어떤 조치를 취할까요? 대답이 'nothing'이면 생각 중인 작업이 너무 작아서 관리할 가치가 없다는 좋은 표시입니다. 그렇다면 당신은 너무 많은 세부 사항을 찾고 있습니다. 수준을 백업하고 한 걸음 뒤로 물러서서 완료되었는지 확인합니다.
이 작업의 업데이트에 대한 데이터를 수집하는 데 작업 자체보다 오래 걸리나요? 우리는 항상 예약 된 작업을 관리하는 데 걸리는 노력의 종류를 생각하지 않습니다, 하지만 잠시 동안하더라도 생각하는 것이 좋습니다. 완료하는 데 걸리는 작업보다 작업을 관리하는 데 더 많은 노력이 소요되는 경우 작업이 너무 미세하게 세부 수준에서 정의되고 있음을 나타내는 좋은 지표입니다.
이 작업은 얼마나 걸리나요? 작업을 하위 분할할 때 작업이 얼마나 미미해지는지 시야를 잃을 때가 있습니다. 최상위 수준의 큰 단계는 아마도 몇 주 길이였지만, 몇 가지 수준의 세분성을 낮추면 몇 분밖에 걸리지 않는 관리해야 할 작업을 정의하는 함정에 쉽게 빠질 수 있습니다. 우리가 작은 작업에 도착하면, 우리는 그들을 관리하는 이점이 무엇인지 물어봐야 합니다.
방금 얘기한 내용에 현실 검사를 적용해 보겠습니다. 2년 EPC 프로젝트에서 1주일의 작업이 하루 늦은 경우 조치를 취할 가치가 거의 없습니다. 6개월 소프트웨어 프로젝트에서 하루 늦은 1주일의 작업은 조치를 취할 가치가 없을 것입니다. 6일간의 종료 프로젝트에서 하루 늦은 1주일의 작업은 엄청난 비상사태입니다. 즉, EPC 프로젝트의 1주일 작업이 너무 세부적인 수준일 수 있습니다. 소프트웨어 프로젝트에서는 거의 옳을 것입니다. 종료 프로젝트에서는 세부 정보로 세분화해야 합니다.
얼마나 많은 리소스가 관련되어 있나요?
저는 우리가 그 범위에서 작업하고 있다는 것을 알고 있지만, 어떤 종류의 해결이 필요한지 살펴볼 때, 얼마나 많은 사람들이 작업을 할 것인지 생각해 보는 것이 좋습니다. 예를 들어 대규모 EPC 프로젝트에서는 작업 단계에 관련된 한 기술에서 수십 명의 작업자가 있을 수 있습니다. 그러나 동일한 작업에서 다양한 기술을 습득하게 되면 불가능하지는 않더라도 해당 작업을 관리하는 것이 매우 어려워집니다. 그래서, 그 상황에서, 많은 다른 기술을 필요로하는 작업은 아마 분할해야합니다.
소프트웨어 프로젝트에서는 거의 모든 개인을 고유한 기능을 갖춘 고도의 기술 리소스로 생각하는 경향이 있습니다. 또한 소프트웨어 프로젝트에서는 부서 내에서 다시 할당할 수 있지만 한 사람에게 할당된 태스크는 하나만 할당하는 것이 일반적입니다. 따라서 특정 리소스 그룹 또는 부서의 1인 수준(예: 인터페이스 프로그래밍)에 할당된 작업이 있는 경우 더 자세한 정보가 필요하지 않다고 말할 수 있을 만큼 가깝습니다.
리소스는 어떻게 관리되거나 하위로 나뉘나요?
리소스를 관리하는 방법은 작업을 하위 분할하는 방법에 큰 영향을 줍니다. 예를 들어 대규모 EPC 프로젝트에서 프로젝트는 종종 거대한 하청업체에 구획되는 하위 프로젝트로 잘려나갔습니다. 이 상황에서는 다음과 같은 몇 가지 작업을 수행해야 합니다.
프로젝트 관리자가 진행이 큰 요인이라는 확신을 가지고 하청업체를 감독할 수 있는 방식으로 작업을 정의합니다.
하청업체의 프로젝트 관리 및 엔지니어링 직원이 모호성 없이 무엇을 의미하는지 이해하는 방식으로 작업을 정의합니다.
표준으로 채택한 해결 수준이 하청업체에서 이해하고 동의하는지 확인합니다.
소프트웨어, 생물학적 연구 또는 엔지니어링과 같은 화이트 칼라 프로젝트를 살펴보면 프로젝트 관리자가 리소스를 소유하지 않는 행렬 관리 구조가 발생할 가능성이 가장 높으며 여러 프로젝트에 해당 리소스를 할당하는 부서 관리자 간에 작업해야 합니다. 이 경우 주요 질문은 다음과 같습니다.
하루 동안 작업할 수 있는 리소스는 몇 개입니까?
직원이 한 프로젝트에서 다른 프로젝트로 전환하는 데 얼마나 걸리나요?
직원과 리소스 부서 관리자가 올바른 기술을 할당하는 방법을 이해하도록 작업이 정의되어 있나요?
종료 또는 건설 프로젝트를 살펴보면, 특별히 제작된 승무원 간에 작업하는 경향이 있습니다. 이러한 상황에서 리소스 팀 리더는 전기 팀(목수 및 파이프 피터를 포함하더라도), 배관 팀 또는 보일러 유닛 리퍼비시 팀을 관리하고 있을 수 있습니다. 이 작업은 교대 근무 내내 승무원이 바쁘게 지낼 수 있고 이미 그 지역에서 일하고 있는 다른 승무원의 위에 도착하지 않도록 구성되어야 합니다. 종료 프로젝트를 완료해야 한다는 강한 압박을 감안할 때 작업은 종종 작업별로 먼저 구성되고, 예약된 다음, 리소스 팀 리더에 의해 다시 그룹화되고 하위 분할되므로 각 팀 리더는 한 문서에서 작업만 수행하고 전체 프로젝트를 다른 문서의 컨텍스트에서 작업할 수 있습니다. 따라서 직원과 리소스 팀 리더가 이해할 수 있는 방식으로 작업을 정의해야 합니다. 여기서의 작업은 아마도 시간까지 또는 시간의 10분의 1 또는 1/4까지 더 세분화되어 정의되어 있습니다.
얼마나 빨리 데이터를 수집할 수 있으며 얼마나 많은 노력이 필요한가요?
프로젝트 데이터를 검토하기 위해 주말 에 잘 줄지어 있는 프로젝트 데이터를 보는 데 익숙할 때 어리석은 질문처럼 들리지만 프로젝트의 해상도 수준을 결정하려고 할 때 이것이 핵심 질문이 될 수 있습니다. 예를 들어 수많은 하청업체를 통해 작업하는 경우 주간 또는 월별 업데이트를 받을 수 있습니다. 실제로 프로젝트 관리 업데이트 절을 계약에 빌드하는 것이 필수적입니다. 이 상황에서는 이러한 서로 다른 회사의 데이터를 사용자 고유의 데이터에 통합하고 진행률 데이터가 적합한지 유효성을 검사한 다음 자체 분석 및 보고를 수행해야 합니다. EPC 모드에서는 월별 발생일 수 있습니다.
종료 프로젝트에서는 교대 근무마다 프로젝트를 업데이트하고, 신속하게 업데이트하고, 다음 교대 근무 중에 리소스 팀 리더에 대한 업데이트를 받아야 합니다. 이러한 상황에서 프로젝트 직원은 교대 근무 중에 공장 전체에 몰려들어 가능한 한 실시간으로 데이터를 수집하고 자원 팀 리더와 Foremen이 '테이크다운' 시트를 사용하여 과제 진행 상황을 '테이크다운'하도록 합니다. 소프트웨어 또는 연구 프로젝트에서는 주별 일정이나 개인들이 자신의 진행 상황을 보고하고 하루 이틀에 걸쳐 승인을 거치는 것과 같은 작업을 하고 있을 것입니다.
데이터를 수집하는 데 비용이 들기 때문에 프로젝트에 필요한 작업 수를 확인할 때 고려해야 할 중요한 지점입니다.
따라서 데이터를 수집하는 비용과 수집되는 데이터의 투자 수익률을 고려할 때와 마찬가지로 정기적으로 데이터를 수집, 승인, 통합, 분석 및 보고할 수 있는 횟수에 대해 생각하는 것이 중요합니다.
얼마나 자주 업데이트합니까?
수집 및 포함할 수 있는 데이터의 양을 결정하는 두 가지 키는 다음과 같습니다.
데이터를 수집하는 방법을 생각해 보세요.
프로젝트를 합리적으로 업데이트하고 프로젝트와 리소스를 올바른 방향으로 안내하는 데 필요한 의사 결정 도구를 경영진에게 제공할 수 있는 빈도를 생각해 보세요.
일부 프로젝트 관리자는 '실시간' 프로젝트 관리 및 프로젝트 수집으로 이동하고 싶다고 주장하는 것을 보았으며 이론적으로는 가능할 수 있지만 실제로는 실현하기가 매우 어렵습니다.
프로젝트 관리 데이터를 볼 때 몇 가지 가정을 합니다. 다음을 가정합니다.
데이터가 모두 있습니다. 업데이트된 일부 작업과 업데이트되지 않은 작업을 살펴볼 것으로 예상하지 않습니다.
데이터는 모두 비슷한 시간에 업데이트되었습니다. 몇 분 전에 작업의 절반이 업데이트되었지만 나머지 절반은 2주 동안 업데이트되지 않았습니다.
데이터에는 모두 어느 정도의 승인이 있었습니다. 우리는 프로젝트 관리자가 제시되는 데이터 뒤에 서서 "이것은 프로젝트의 공정하고 정확한 표현"이라고 말할 수 있기를 기대합니다.
데이터는 함께 속합니다. 이러한 방식으로 보고서와 분석을 구체적으로 설계하지 않는 한 비용 및 리소스로 위험이 흐려질 것으로 예상하지 않습니다.
저는 종종 실시간 프로젝트 관리의 개념에 대해 흥분하는 임원들에게 방금 위에서 제기한 점을 극복할 수 있다면 어떻게 할 것인지 물어봅니다. "일주일 내내 경영진의 결정을 내릴 준비가 되어 있습니까?" 나는 물어 볼게요. 응답은 해상도 수준에 따라 달라집니다. 종료 프로젝트에서 대답은 '예'입니다. 소프트웨어 프로젝트에서 대답은 아마도 '아니요, 매주 할 것입니다.'입니다. 그리고 EPC 프로젝트에서 대답은 '월별'입니다.
어떤 시점에서 감소 반환의 법은 말을 시작, "프로젝트 보고서를 더 빨리 전달하는 것은 우리에게 효율성의 증가를 제공하지 않습니다."
작업 검토
이제 생각할 수 있는 음식이 있었고, 작업 분석 방법을 사용하여 데이터를 하위 분할했으며, 데이터가 너무 세밀하게 정의되었다는 몇 가지 경고 징후를 확인했습니다. 이제 일정을 벽에 기대고, 뒤로 물러서서, 몇 가지 관점으로 프로젝트를 살펴볼 때입니다. 놀랍게도 많은 프로젝트 관리자는 이 작업을 수행하지 않습니다. 그들은 마지막 세부 사항을 정의하는 데 너무 사로 잡히고 너무 바빠서 작업을 몇 번이고 분할하여 라이브 마감일까지 자신을 밀어 붙이고 그들이 만든 것이 관리하기에 악몽이 될 지 여부를 보지 않습니다.
경우에 따라 경영진은 모든 MBA 교육에서 "더 자세한 내용이 더 낫다"고 확신하며 6 개월 간의 프로젝트에 대한 5 분 또는 15 분 작업을 추진하고 있습니다.
프로젝트를 시작하기 전에 변경하는 것이 항상 나중에 어느 때보다 쉽기 때문에 필요한 경우 일정을 다시 작업하기 위해 일정 빌드 작업으로 시간을 빌드합니다.
너무 많은가요?
때로는 프로젝트 관리자가 만든 내용의 범위를 살펴보고 세부 수준이 너무 큽니다. 이 경우 수정 사항이 분명합니다. 그것은 많은 일이 될 수 있습니다,하지만 당신은 레벨을 이동하여 일정을 더 간단하게 나중에 자신을 감사드립니다.
때로는 그림이 그렇게 쉽지 않습니다. 경우에 따라 전체 일정이 어셈블된 후에만 프로젝트 관리자가 얼마나 복잡한지 확인할 수 있습니다. 복잡한 프로젝트는 본질적으로 오늘날의 경제에서 위험하고 위험하며 프로젝트의 주요 선택 요소입니다. 이러한 복잡한 프로젝트가 진행되기 전에 고려해야 할 몇 가지 질문은 다음과 같습니다.
우리는 조각으로 그것을 할 수 있습니까? 일부 위험한 프로젝트는 작은 한입 크기의 부분으로 나눌 수 있으며 작은 프로젝트로 위험이 감소합니다. 그러나 이 전략을 사용하는 경우 각 불연속 프로젝트에는 완료 시 고유한 값이 있어야 합니다.
범위를 재고해야 하나요? 경우에 따라 가장 간단한 작업은 처음에 작업의 디자이너로 돌아가서 일정에서 명백해 보이는 복잡성을 설명하고 작업을 다시 작성할 수 있는지 확인하는 것입니다. 이것은 수시로 일어날 기회가 없었을 혁신적인 생각으로 이끌어 납니다.
우리는 전혀 그것을해야합니까?
일부 프로젝트는 결코 의도되지 않았으며 취소하는 가장 저렴한 시간은 시작하기 전날입니다. 프로젝트의 위험이 이제만 명백하다면 나중에 보다 지금 실현하는 것이 좋습니다. 일정을 다시 PPM(프로젝트 포트폴리오 관리) 프로세스로 짜는 경우 더 복잡한 프로젝트의 위험이 투자 수익률 규모에서 작업 점수가 훨씬 더 나빠질 수 있습니다.
민첩한... 아니요, Agile 프로젝트
나는 Agile 프로젝트 관리에 대해 몇 가지를 말할 것을 약속하고 당신이 Agile 팬이고 당신이 지금까지 읽은 경우, 나는 당신의 인내심을 주셔서 감사합니다. Agile 메서드를 통해 소프트웨어 프로젝트를 관리하는 것은 철학이지만 실패한 대규모 소프트웨어 개발 프로젝트에 불타버린 사람들에게 점점 더 인기 있는 철학입니다.
Agile 소프트웨어 개발 환경에서는 프로젝트를 한입 크기의 1~3주 "스프린트"로 나누려고 노력하며, 각 미니 프로젝트의 목표는 사용 가능한 코드로 끝나는 것입니다. 이 경우 우리는 우리의 해상도 수준이 거의 우리를 위해 선택되도록 몇 가지 상당히 잘 알려진 제약 조건 내에서 작업하고 있습니다.
1~3주 기간이 있고, 리소스를 사용할 수 있으며, 각 리소스에 작업을 할당할 예정입니다. 해당 구조에서 정의할 수 있는 가능한 작업의 수는 유한하며 이는 적절한 수준의 해상도를 유지하는 데 도움이 됩니다. 예, 너무 짧은 작업을 정의하여 Agile에서 문제가 발생할 수 있습니다. "Field1 정의: 10분, 필드 2 정의: 10분, 필드 3 정의: 10분" 등은 일반적이지 않습니다.
Agile은 사내에서 사용할 소프트웨어를 만드는 기업 개발 환경을 위해 설계되었으며, 해당 용도는 상용 소프트웨어 개발로 확장되는 경우가 많습니다. (여기서는 TimeControl의 자체 개발을 위해 HMS에서 메서드를 사용합니다.) Agile 메서드는 더 기동적이고 민첩한 개발 부서를 생성하지만 모든 산업 또는 모든 소프트웨어 회사에는 적용되지 않을 것입니다. 소프트웨어 환경에서 프로젝트 관리를 수행하는 경우 Agile을 읽고 학습한 다음 가장 효과적인 요소(모두, 일부 또는 없음)를 채택하는 것이 좋습니다.
래핑업
프로젝트 관리의 대부분의 측면과 마찬가지로 처음에는 그렇게 명백한 것처럼 보이는 질문에 대한 정해진 답변이 없습니다. 프로젝트에 있는 작업 수와 각 작업이 얼마나 오래 있어야 하는지는 스스로 결정해야 하는 작업입니다. 하지만 결정해야 합니다.
프로젝트 수준의 해상도를 선택하는 것은 프로젝트 일정 관리의 주요 성공 요소가 될 수 있는 프로젝트 관리 책임입니다.
작성자 정보
Chris Vandersluis는 캐나다에 본사를 둔 HMS 소프트웨어인 Microsoft Certified Partner인 몬트리올의 사장 겸 설립자입니다. 그는 맥길 대학교에서 경제학 학위를 취득했으며 프로젝트 제어 시스템의 자동화 분야에서 30년 이상의 경험을 보유하고 있습니다. 그는 PMI(프로젝트 관리 연구소)의 오랜 회원이며 MPUG(Microsoft Project Users Group)의 몬트리올, 토론토 및 퀘벡 지부를 설립하는 데 도움을 주었습니다. Chris가 저술한 출판물에는 포춘, 헤비건설 뉴스, 컴퓨팅 캐나다 잡지, PMI의 PMNetwork 등이 있으며, 프로젝트 타임즈의 정기 칼럼니스트입니다. 그는 McGill 대학에서 고급 프로젝트 관리를 가르치고 종종 북아메리카 및 전 세계의 프로젝트 관리 협회 기능에서 연설합니다. HMS Software는 TimeControl 프로젝트 지향 시간 유지 시스템의 게시자이며 1995년부터 Microsoft 프로젝트 솔루션 파트너로 활동해 왔습니다.
Chris Vandersluis는 다음에서 전자 메일로 연락할 수 있습니다. chris.vandersluis@hms.ca
Chris Vandersluis에서 더 많은 EPM 관련 문서를 읽으려면 HMS의 EPM 지침 사이트(https://www.epmguidance.com/?page_id=39)를 참조하세요.