MS Project

Client의 요구사항 중 시작 날짜와 완료 날짜 필드에 시간까지 표시하자는 부분을 반영한 Gantt Chart 테이블입니다. Activity 2 작업에 배정된 자원(초아)은 50% 단위로 할당되었습니다. 초아는 Activity 2 작업을 1일 기간이지만 8h가 아닌 4h (50%)만 수행합니다. 그러나 시작/완료 필드에서는 8 to 5로 표시되고 있습니다. 마치 8h 작업 시간인듯 오해할 수 있습니다만, 시작(날짜), 완료(날짜) 필드에 표시되는 시간은 작업 시간(작업량, 투입량, 공수) 개념이 절대 아닙니다. 단지 Activity의 작업 시작일의 시작 시간과 완료일의 완료 시간을 의미할 뿐입니다. 참고로 시작/완료 필드의 시간은 9 to 6로도 변경 가능합니다.

[광고가 노출될 경우 클릭하지마세요. 저는 광고를 올리지 않습니다. 티스토리는 카카오가 강제로 광고를 올리는 곳입니다.] Blog - H·K MS Project 기반 사업관리(외주) 지원, 컨설팅 및 자문, MS Project 교육(기업 출강 및 교육센터) PMP 인증 교육, Agile 실무 교육, PM 실무 교육 및 사업 관리 지원 - 문의 : ineeju @ yahoo . com ineeju.notion.site Gantt Chart의 눈금선을 사용하면 작업 표시줄을 날짜와 정렬하여 Bar Chart를 보다 쉽게 ​​읽을 수 있습니다. 수백개의 작업들과 의존관계, 기준선과 진척 사항 등 다양한 정보가 혼재된 실무 환경에서 기본 Bar Chart 형식을 사용하시면 일정이나 기타 정보를 읽기가 어렵습니다..

[광고가 노출될 경우 클릭하지마세요. 저는 광고를 올리지 않습니다. 티스토리는 카카오가 강제로 광고를 올리는 곳입니다.] ※ 완료율, 작업 완료율, 실제 완료율 상세 내용은 강의 교재 참조 전체 과정 강의 교재 | Notion Microsoft Project 강의 교재 판매 ineeju.notion.site 이 글의 목적은 실제 완료율 필드의 요약(최상위 요약 포함)작업에 roll up이 되는 경우가 있고 안되는 경우가 있어서 사용자(PM) 분들이 궁금해하시는 부분을 해결해주는 글입니다. ※ 완료율과 관련된 Roll up MS Project에서 Roll up은 요약 작업과 최상위 요약 작업 관점에서 진행율을 표시하는 것을 의미합니다. 각 Activity의 완료 정도를 모두 합산해서 Activity 개수로..

■ 에스컬레이션(Escalation) 리스크를 프로젝트 상위 수준으로 넘기는 것입니다. 프로젝트에서 리스크를 상위 수준인 프로그램이나 포트폴리오 수준의 리스크 전문 부서로 넘겨 처리할 수 있도록 하는 것이 에스컬레이션입니다. 에스컬레이션 이후 해당 리스크는 프로젝트 팀이 모니터링을 하지 않지만, 관리 차원에서 리스크 관리대장에 기록할 수는 있습니다. 해당 리스크 담당은 이관된 조직 내 담당자로 변경됩니다. 리스크가 프로젝트 범위를 벗어나거나 제안된 대응 계획이 프로젝트 관리자의 권한을 넘어서는 경우에 적용 가능하며, 프로젝트 관리자나 프로젝트 팀에서 관리할 대상도 관리할 수 있는 범위가 아닐 경우에 에스컬레이션 전략을 취합니다. 리스크 에스컬레이션은 사전에 프로젝트 관리자가 경영진과 함께 에스컬레이션이 ..

몬테카를로 시뮬레이션의 상세 내용이 아닌 결과 예제입니다. 프로젝트 원가 산정치가 37(O), 50(M·L), 65(P)일 경우 몬테카를로 시뮬레이션을 Tool을 이용해 돌려보면, 59 정도의 원가가 시그마 2 (95%)의 신뢰도를 나타냅니다. 우리 프로젝트의 원가 예측치가 50이였다면, 우리 프로젝트는 원가 50으로 완료할 확률은 50%라고 보고할 수 있고 59 정도의 원가에 우발사태 예비비 10%, 관리 예비비 10% 추가해야 95% 정도의 확률이 나온다 라고 보고할 수 있습니다. 참고로, 몬테카를로 시뮬레이션은 최소 10,000번을 돌려야(10,000개 sampling)하는데, 간편 예제라서 1,000번(1,000개 sampling)만 돌린 결과 값입니다.

PMBOK 6th 기준으로 브레인스토밍(Brainstorming) 기법을 사용하는 프로세스들입니다. ITO 즉 입력, 도구 및 기법, 산출 관계를 학습할 때 보통 암기보다는 이해를 하라는 말씀을 많이 들으시는데요. 각 프로세스에서 어떤 입력물을 브레인스토밍을 해서 (물론 다른 기법도 추가합니다) 산출물이 나오는지의 상관 관계를 먼저 살펴보시면 "이해" 라는 것을 하시기 쉬어집니다. 아래는 11.2.2.2 리스크 식별 프로세스의 도구 및 기법(데이터 수집) 중 브레인스토밍이 입력물과 산출물 사이에서 어떤 관계를 보여주는지 생각해 볼 수 있도록 한 다이어그램입니다. 나머지 프로세스들은 여러분들이 노트해 보시면 더 빨리 숙지할 수 있으실겁니다.

프로젝트 문서를 변경(업데이트 포함)하려면 변경 요청 절차를 밟아 승인된 이 후에 변경을 해야 하는가? 우선 변경이 주어가 될 때를 보시면, 어떤 인도물(또는 통제받고 있는 프로젝트관리 계획서, 보조관리 계획서, 기준선 등)의 변경 요청이 승인되고 변경을 할 경우 영향을 받는 모든 프로젝트 문서는 업데이트를 해야합니다. 참고로 여기서 업데이트라는 것은, 변경이 되는 부분을 삭제하고 변경된 부분을 새로 쓰는 것은 아닙니다. 예를 들어, A를 B로 업데이트해야한다면, A를 지우고 B를 기재하는게 아니고, A는 그대로 두고 A 옆에 주석이나 기타 표시로 B로 변경되었다는 것을 기록한 후에 변경된 최신 버전을 다시 생성해서 첨부합니다. 일종의 버전관리나 history 관리로 보시면 됩니다. 이제 프로젝트 문서가..

변경 요청이 어떤 프로세스를 거쳐 최종 결과물로 진행 되는지에 대한 흐름입니다. Input → Process → Output/Input 개념으로 변경요청(서)가 순차적으로 진행되어 최종 제품, 서비스 및 결과의 이전까지의 흐름입니다.