프로젝트 일정의 7가지 대죄

이 문서는 "트렌치에서" 컬렉션의 일부입니다.

이 문서에서는 프로젝트 일정에서 발생하는 일반적인 실수에 대해 설명하고 실용적인 조언을 제공합니다. 모든 버전의 Microsoft Project와 관련된 실용적인 조언과 권장 사항을 제공합니다.

더 많은 문서를 보려면 "참호에서" 백서를 참조하세요.

프로젝트 일정의 7가지 대죄

일정 예약은 프로젝트의 단순한 구성 요소가 아니며, 그러나 지난 20년 동안 저는 제가 일하거나 일정과 관련하여 상담한 모든 조직에서 동일한 기본 문제를 반복적으로 겪었습니다. 여기서 나는 프로젝트 일정의 일곱 치명적인 죄를 배치하고 몇 가지 해독제를 제공합니다. 이 조언을 사용하여 일정을 사용할 때 성공적인 프로젝트 관리를 위한 올바른 기반을 마련할 수 있기를 바랍니다.

죄 #1: 일정이 너무 복잡합니다!

왼쪽에서 오른쪽으로보다 더 많은 선이 북쪽에서 남쪽으로 실행되는 일정이 있는 경우 문제가 발생합니다. 관련자가 일정을 이해하는 데 몇 주 또는 며칠이 걸리는 경우 모델이 너무 복잡합니다. 임원이나 팀에게 설명하기가 너무 어렵다면 누구나 혜택을 누릴 수 있더라도 어떻게 기대할 수 있을까요?

프로젝트가 너무 복잡한지 어떻게 알 수 있나요? 일정에서 중요한 경로를 찾는 것이 얼마나 쉬운지 자문해 보세요.

죄 #2: 일정에 작업이 너무 많습니다.

이것은 무엇보다도 일정이 길가에 떨어지는 이유에 기여할 것입니다. 프로젝트 관리자는 일정이 완료해야 하는 모든 항목의 검사 목록이어야 한다는 인상을 받습니다. 할 일 항목 및 미리 알림은 작업 분석 구조에 속하지 않습니다. 이 방법은 프로젝트의 모델을 나타내는 일정의 전체 목적을 완전히 무용지식으로 만듭니다.

요점을 설명하기 위해 예제를 공유해 보겠습니다. 당신이 목재 공급 사람 또는 건설되는 집을 건립 할 프레임러라고 가정합니다. 목재 패키지를 배달해야 하는 시기 또는 작업을 시작하기 위해 승무원과 함께 표시해야 하는 시기를 알아야 합니다. 이는 일반적으로 기초가 완료되면 발생합니다.

다음과 같은 일정을 작성할 수 있습니다.

또는 다음과 같습니다.

작성기 및 스케줄러인 경우 실제 항목을 업데이트하고 유지 관리하는 방법을 선호하시겠습니까?

이제 동시에 30채의 주택이 건설되고 있다고 상상해 보십시오. 어떤 것을 선호하시겠습니까?

즉, 나열된 다른 모든 작업이 중요하지 않거나 다른 작업을 수행할 필요가 없다는 것을 말하는 것은 아닙니다. 여기서 진짜 질문은 추적하고 유지하는 방법입니다. 위에 표시된 한 줄 작업에 대한 메모로 세부 작업만 나열할 수도 있습니다.

다음은 Eric Uyttewaal의 저서인 Microsoft Project 2010의 예측 일정 예약에서 사용하는 엄지 손가락 규칙입니다. 최소 기간은 프로젝트 기간의 1%입니다. 최대값은 기간의 10%입니다.

죄 #3: 네트워크 논리가 불완전하거나 동적이 아닙니다.

불완전한 네트워크 논리는 일정이 제대로 예측되지 않거나 동적으로 발전하지 못하는 가장 큰 이유입니다. 이에 대한 종속성이 너무 적습니다. 너무 많은 제약 조건을 사용하면 올바르게 배치된 네트워크의 동적 특성도 크게 손상됩니다. 표시기 열에 대부분 제약 조건이 표시되는 경우 이는 실제로 무엇을 하고 있는지 모를 수 있음을 나타냅니다. 프로젝트 관리자는 일정에 많은 제약 조건이 있음을 숨기기 위해 이 열을 숨기는 경우가 많습니다.

여기에 당신을위한 쉬운 테스트입니다. 일정에서 중요한 경로를 찾은 다음(할 수 없는 경우 이미 큰 문제가 있는 경우) 일정 초기에 가장 긴 불완전한 작업 중 하나를 수행하고 기간을 두 배로 찾습니다. 프로젝트 완료 날짜가 변경됩니까? 그렇지 않은 경우 작업 일정이 없습니다. 작업 및 기간을 예측하고 프로젝트 관리자로서 결과를 더 잘 제어하는 데 사용할 수 있는 동적 일정을 갖는 기본 테넌트의 이점을 활용할 수 없습니다.

죄 #4: 일정이 기준이 지정되지 않음

일정을 기본으로 지정하지 않으면 불가능하지는 않지만 분산을 측정하는 것이 어려워집니다. 기본 설정은 작업을 시작하기 전에 일정을 캡처하는 데 도움이 되며, 현실이 설정되면 분산에서 학습할 수 있습니다. 측정할 수 없는 경우 제어할 수 없습니다.

죄 #5: 일정이 업데이트되지 않음

내가 본 일정의 대부분은 오래된. 프로젝트 관리자는 프로젝트가 진행 중이면 일정을 포기하고 실행 중인 동안 화재를 진압하는 경우가 많습니다. 일정이 너무 상세하고 최신 상태로 유지하기 위해 너무 많은 작업이 필요한 경우 이러한 일이 발생할 가능성이 크게 증가합니다. 결론: 일정을 업데이트하지 않으면 향후 날짜를 예측할 수 없습니다.

죄 #6: 일정에 리소스 할당이 없거나 초과 할당됨

일정은 리소스 할당 없이 만들어지는 경우가 많습니다. 이것은 좋은 그림을 만들 수 있지만 타임 라인을 달성 할 수 있다는 잘못된 인상을 줄 수도 있습니다. 리소스가 추가되고 평준화되면 완전히 다른 타임라인이 나타날 수 있습니다.

리소스가 할당되면 "내부"(리소스 사용량 보기 사용)를 볼 때보다 더 자주 할당됩니다. 기본 고정 단위로 시작하면 잘못된 발에서 시작됩니다. 시간을 내어 사용자의 용량 내에서 할당된 시간과 작업 측면에서 현실적인 과제를 수행했는지 여부를 평가합니다.

또한 자동 리소스 평준화 기능을 사용할 때는 매우 주의해야 합니다. 수동 모드에서 사용하는 것이 가장 좋습니다. 또한 다른 프로젝트 워크로드에 대한 가시성을 제공하는 엔터프라이즈 솔루션을 사용하면 작업을 수행할 수 있다는 자신감이 높아져야 합니다.

죄 #7: 작업 유형이 무엇인지 모릅니다.

프로젝트 예약 엔진의 작동 방식과 수식에서 작업 유형이 작동하는 방식을 이해하지 못하는 경우

기간 * 단위 = 작업 시간

당신은 영원히 당신의 머리를 당겨 도구에 좌절하게 될 것입니다.

메시지를 받지 못하는 경우 좋은 자원을 얻고 연구하는 것이 좋습니다. Microsoft Project 2010을 사용하여 예약을 예측하는 것이 좋습니다.

작성자 정보

25년 이상의 프로젝트 관리 경험을 갖춘 Kevin Watson, PMP, MCT, MCTS는 Microsoft Project 및 Microsoft Project Server의 블랙 벨트입니다. Kevin은 프로젝트 관리와 프로젝트 서버의 고유한 조합을 현장으로 가져오며, Microsoft의 수석 컨설턴트입니다. 에서 kevinw@microsoft.com그에게 문의하세요.