MS Project - 기간을 입력할 때 (기간)단위 기준은?

기간 필드

영문날짜형식

 

기간을 입력할 때, 어떤 단위(hour, day, week, month 등) 입력하는 것이 정확하고 효율적인지 알아보기 위해, MS Project 입장에서 기간이 입력되면 어떻게 작동하는지 그 원리와 함께 살펴보려 합니다.

우선, PM이 작업(Activity, Task 등)에 기간 값을 입력하려면 팀원들(자원 들과) 함께 몇몇 산정 기법을 통하여 산출합니다. 이 때 해당 작업을 수행할 자원도 어느정도 정해지죠.

참고로 제가 좋아하는 산정 기법은 와이드밴드 델파이 기법과 PERT & 몬테카를로 시뮬레이션입니다. (느므 좋아...)

자 다시 (제가)정신차리고 돌아와서, PM이 기간 필드(열)에 ① 기간 값을 입력하면, ② MS Project는 옵션의 기준을 살펴봅니다.  ③ 옵션의 기준을 기반으로 Bar 길이(기간)을 표시합니다. 

위 이미지는 옵션 기준값이 1 달은 20일이라는 기준입니다. 그래서 PM이 기간 값에 1달을 입력하면 20일의 근무일이 표시됩니다. 우리(사람)가 보통 알고 있는 한달과는 좀 차이가 있습니다. 그마저도 어떤 달은 30일, 어떤 달은 31일에 휴무가 많은 달(예, 설 연휴, 추적 연휴 등)은 근무일 기준 20일도 안되는 달도 있습니다.
그렇다고 전체 적용(어떤 달에만 적용되는 것이 아니라 모든 달에 공통으로 적용)되는 옵션의 한 달 작업일 (기본 값은 20day)을 변경하는 것도 적당한 방법은 아닙니다.  

그래서 다시 질문으로 올라가면, 기간을 입력할 때, 어떤 단위(hour, day, week, month 등) 입력하는 것이 정확하고 효율적인가?

우선 옵션의 한 달 작업일은 변경하지 않습니다. 그리고 옵션의 한 달 작업일의 기준이 20일 이므로 PM은 기간 값을 입력할 때 월(Month) 기준으로 입력하지 않습니다. PM은 일(day) 기준 또는 주(Week) 기준으로만 입력합니다.

팀원들과 함께하는 기간(공수)산정 때에도 피드백 단위는 day가 가장 많습니다. 또 WBS 규칙 중에 Work Package의 80hour Rule(유의미한 산출물이 나오는데 즉, 작업하는데 80시간 즉 2주를 넘지는 않도록 하자는 거죠)도 있습니다.  

여기까지가 MS Project의 기간 표시 메커니즘(작동 원리)과 기간 값을 입력할 때 사용해야할 단위(day 또는 week)에 대한 내용입니다. 

참고로, 조직 문화가 주 6일 근무라면, 옵션의 일주일 작업 시간을 40 → 48 시간으로 변경합니다. 그리고 프로젝트 달력에서도 주 5일에서 주 6일로 변경해줘야 합니다. 
MS Project의 파일 탭 - 옵션 - (옵션 창의) 일정 - 이 프로젝트의 달력 옵션 항목을 변경하면 반드시 작업 시간 바꾸기 메뉴를 통해서 변경된 내용을 적용해 줘야 합니다. 그래야 일정 계산 오류를 방지할 수 있습니다.
그래서 저는 일정 옵션을 안 바꿉니다. 건딜면 생산성과 관련없는 의미없는 일이 발생하자나요. 

기간 값 입력 단위는 day(일) 또는 week(주) 로만 하는 것을 권장합니다만, 월 단위가 정책일 경우(월 단위로 관리하는 것이 정책)에는 월 단위로 입력하시면 됩니다. (1mo 또는 1달) 

MS Project - 기간을 입력할 때 (기간)단위 기준은?

 

※ 기간을 시간으로 또는 다른 단위로 설정

일정 옵션

 

WBS

개요 수준 필드

2022년 10월 - 노션으로 이동하려 합니다. 
노션 이동 사유는 데이터 센터 화재 이후 블로그의 몇 몇 글들은 수정할 경우 에러 발생으로 수정이 안되고 있습니다. 
복구를 아직도 못한?? 것이 아니라 아예 할 생각이 없는것 같습니다. (2023년 3월 현재)

2007년 7월에 시작했으니 띄엄띄엄이라도 15년 넘게 사용한 Tistory 블로그는 없애지 않고 백업 개념으로 글을 올릴(?) 수도 있지만 MS Project, Agile, PMBOK 등의 글은 주로 노션에 올릴 예정입니다.
이제 천천히, 점진적으로 메인 블로그는 노션으로 가볼 예정입니다.