프로젝트 프로세스 영역에 대해서 알아보겠습니다. 프로젝트 프로세스 영역은 빠르게 비즈니스 가치를 실현하도록 프로세스를 실행하는 영역과 의사 소통 관리, 리스크 평가 관리가 있습니다. 이해관계자를 참여하는 영역과 예산과 자원 계획과 관리, 일정 계획과 관리, 제품 인도물의 품질 계획과 관리, 범위 계획과 관리, 프로젝트 계획 활동의 통합과 관련된 영역입니다.
또한 프로젝트 계획 활동을 통합하고 프로젝트 변경 관리 사항을 관리하며 조달 계획을 수립합니다. 프로젝트 인도물을 관리하며 적절한 프로젝트 방법론 방법을 적용합니다. 프로젝트 거버넌스 구조를 확립하고 프로젝트 이슈를 관리하며 프로젝트 연속성을 위한 지식 전달에 신경 쓰게 됩니다. 프로젝트 단계와 종료, 그리고 이동 계획과 관리에 대한 내용과 관련되어 있습니다.
프로젝트 프로세스 영역의 개요
프로젝트 프로세스 영역에서는 프로젝트를 진행하는 모든 과정과 활동들을 포함합니다. 유사 산정, 모수 산정, 3점 산정, 상향식 산정법의 특징을 이해해야 하고 일정 단축 방법의 개념에 대해서 알고 있어야 합니다. 애자일 릴리즈 기획의 의미와 반복 번다운 차이에 대해서 다룹니다. 선후행 도형법을 사용하는 논리적 관계와 주공정법에 대해서 다릅니다. 원가 관리 계획서에 기술되는 중요한 항목, 우발 사태 예비와 관리 예비의 차이점도 중요합니다. 원가 산정 방법의 종류와 계획 가치, 획득 가치, 실제 원가에 대해서도 알고 있어야 합니다. 일정 차이, 원가 차이, 일정 성과 지수, 원가 성과 지수의 의미들도 여기에 포함됩니다.품질 관리 계획서를 작성할 때의 도구와 기법도 중요합니다.
품질 비용의 종료와 품질 관리 계획서에 포함되는 내용도 중요합니다. 문제 해결 순서와 품질 개선 방법의 의미와 도구에 대해서도 다루는 영역입니다. 프로젝트 프로세스 영역에서는 의사 소통 방법과 의사소통 채널, 그리고 의사소통 관리 계획서에 포함되는 내용에 대해서도 다룹니다. 리스크와 이슈의 차이로 인한 대응 방법의 차이에 대해서도 알고 있어야 합니다. 리스크 관리 계획서와 리스크 분류 체계에 속한 분류 내용도 중요합니다. 리스크 식별 프로세스의 도구와 기법도 함께 알고 있어야 할 것입니다.
프로젝트 착수 회의도 프로젝트 프로세스 상 중요합니다. 요구사항 추적 매트릭스도 적극적으로 활용합니다. 예측형 프로젝트에서 요구 사항을 확정하는 방법과 요구사항정의서, 범위 기술서의 문서에 대해서도 프로젝트 프로세스 영역에서 다뤄지는 주제들입니다. 작업 분류 체계(WBS)와 작업 패키지의 차이에 대해서도 알고 있어야 합니다. 애자일 프로젝트에서는 프로덕트 오너의 역할자가 있습니다.
애자일 프로젝트에서의 프로젝트 매니저(PM)인 스크럼 마스터와 프로덕트 오너(PO)의 역할에 대해서는 구분할 필요가 있습니다. 애자일 프로젝트에서는 데일리 스탠드업 미팅을 진행하며 반복 검토와 회고의 프로세스를 진행합니다. 기준선의 의미와 완료의 정의에 대해서는 확인할 필요가 있습니다. 요구사항정의서와 관련된 유저 스토리도 중요한 문서입니다. 리팩토링의 의미와 실시 시기, 프로젝트 헌장, 조달 SOW의 목적과 포함되는 내용도 함께 알아둬야 합니다. 예측형 프로젝트에서 일정을 확정하는 프로세스는 어떻게 되며 프로젝트를 통해서 얻게 되는 교훈의 의미도 중요합니다.
프로젝트 프로세스 영역에 대한 설명
프로젝트 프로세스 영역에서는 점증적으로 가치를 실현할 수 있는 기회를 평가합니다. 프로젝트 전체에서 비즈니스 가치가 중요합니다. 최소 상품성을 가지는 제품을 찾기 위해서 필요에 따라 프로젝트 과제를 나누도록 프로젝트 팀을 지원할 수 있습니다. 프로젝트 프로세스 영역에서는 모든 이해 관계자들의 의사소통 요구 사항을 분석합니다. 모든 이해 관계자들을 위한 의사 소통 방법을 설계하고 채널과 빈도, 세부적인 수준을 결정해야 합니다. 프로젝트 정보와 업데이트 되는 내용을 프로젝트 이해 관계자들에게 효과적으로 전달할 수 있어야 합니다. 그리고 프로젝트 이해 관계자들이 프로젝트에서 전달한 내용을 이해하고 피드백을 받았는지도 반드시 확인해야 합니다.
리스크 평가와 관리 영역에서는 리스크 관리 옵션을 결정하고 반복적으로 리스크를 평가해야 하며 리스크에 대한 우선순위를 지정해야 합니다. 이해 관계자들의 참여는 프로젝트에서 매우 중요합니다. 이해 관계자들을 권력, 관심, 영향력, 영향에 따라 분석하고 이해 관계자들의 범주를 분류하며 범주 별로 이해 관계자를 참여할 수 있도록 해야 합니다. 이해 관계자들을 참여 시키기 위한 전략을 개발하고 실행하고 검증합니다. 프로젝트 예산 자원 계획과 관리에서는 프로젝트 범위와 이전에 진행했던 프로젝트에서 얻은 교훈을 바탕으로 예산 요구 사항을 추정할 수 있습니다. 그리고 나중에 예산과 관련된 요청을 예측할 수 있습니다.
예산 변화를 감시하고 거버넌스 프로세스를 필요에 따라서 조정할 수 있습니다. 자원 계획과 관리도 매우 중요합니다. 일정 계획과 관리에서는 프로젝트 과제를 추정합니다. 마일스톤, 의존 관계, 스토리 포인트가 있습니다. 벤치 마크와 과거 데이터를 적극적을 활용해야 합니다. 프로젝트 개발 방법론을 기반으로 일정을 준비하고 방법론 기반으로 진행 상황을 측정합니다. 개발 방법론에 따라 필요한 일정 부분을 수정할 수 있습니다. 그리고 다른 프로젝트와 운영 활동을 확인하고 조정할 수 있습니다. 제품과 인도물에 대한 품질 계획도 중요합니다. 프로젝트 인도물에 요구되는 품질 표준을 결정하고 품질 격차에 따라 개선을 위한 옵션을 권유할 수 있습니다. 프로젝트 인도물의 품질을 지속적으로 조사해야 합니다.
프로젝트 범위 계획과 관리 영역에서는 요구 사항을 결정하고 요구 사항의 우선순위를 지정할 수 있습니다. 작업분류체계(WBS)와 백로그를 활용하여 범위를 나누는 것도 하나의 방법입니다. 범위에 대해서는 감시해야 하고 확인합니다. 프로젝트 단계 계획을 통합할 수 있습니다. 프로젝트 계획들 간 의존 관계와 격차, 지속적인 비즈니스 가치를 위한 통합된 프로젝트 계획을 평가할 수 있습니다. 수집된 데이터를 분석하여 인사이트를 얻을 수도 있습니다. 정보에 근거한 프로젝트 결정을 내리기 위해서 데이터를 수집하고 분석해야 합니다. 중대한 정보 요구 사항에 대해서는 프로젝트 매니저가 판단하여 결정합니다.
프로젝트 변경 사항 관리도 중요한 꼭지점입니다. 변경의 필요성에 대해서는 예측하고 수용할 필요가 있는 부분은 수용합니다. 이는 변경 관리 지침을 준수하면서 진행해야 할 것입니다. 변경 요구 사항들에 대해서 대처하기 위한 전략도 구상하고 준비해야 합니다. 프로젝트 개발 방법론에 따라 변경 관리 전략을 실행합니다. 프로젝트 변경 사항에 대한 대응 방법을 결정하고 프로젝트를 진행하면 프로젝트를 체계적으로 진행할 수 있습니다.
프로젝트 프로세스 영역에 대한 이해
프로젝트 프로세스 영역에서 조달 계획과 관리와 관련해서는 자원 요구 사항과 필요성을 정의해야 합니다. 자원 요구 사항을 전달하고 자원을 공급할 수 있는 공급 업체와 계약을 진행하고 계약에 대해서 실행하고 관리할 필요가 있습니다. 조달 전략 계획을 수립하고 관리합니다. 인도 솔루션도 이 때 함께 개발합니다. 프로젝트 인도물 관리 영역에서는 프로젝트 인도물을 관리하기 위한 요구 사항을 결정해야 합니다. 무엇은 언제 어디서 누가 할 것인지에 대해서도 구체적으로 정의해야 합니다. 프로젝트 정보가 최신 상태이고 모든 이해 관계자가 정보에 대해 접근할 수 있는지도 확인합니다.
프로젝트 인도물 관리의 효율성을 지속적으로 평가하는 것이 중요합니다. 적절한 프로젝트 방법론과 방법에 대해서는 중요하게 다뤄져야 합니다. 프로젝트 요구 사항들과 프로젝트 요구 사항에 대한 복잡성, 그리고 규모에 대해서 평가해야 합니다. 프로젝트 실행 전략을 권유하고 프로젝트 방법론 접근 방식을 권유할 필요가 있습니다. 프로젝트를 위한 적절한 거버넌스를 결정하는 것도 중요합니다. 필요에 따라서는 에스컬레이션의 경로와 한계선을 정의합니다. 프로젝트 이슈 관리도 중요합니다. 프로젝트 리스크가 이슈로 변하는 시점을 인식할 필요가 있습니다. 프로젝트 성공을 달성하기 위해서 최적의 조치를 취하여 이슈를 공략합니다.
이슈를 해결하기 위한 접근 방식에 대해서는 관련 이해 관계자들과 협업 해야 합니다. 프로젝트 연속성을 위한 지식 전달도 보장합니다. 팀 안에서 프로젝트 역할자와 역할, 그리고 책임에 대해서는 정의하고 논의할 필요가 있습니다. 업무 환경에 대한 기대 사항을 요약하고 지식 전달을 위한 접근 방식을 확인합니다. 프로젝트는 단계 별로 진행됩니다. 프로젝트 단계를 성공적으로 종료하기 위한 기준도 결정하고 설정합니다. 프로젝트가 종료되면 프로젝트 결과물과 인도물을 인도합니다. 그리고 이후는 운영 단계로 넘어가게 됩니다. 프로젝트가 운영 단계로 이동할 준비가 되었는지 여부도 동시에 확인해야 합니다.
프로젝트 프로세스 상 프로젝트 마무리 단계에서는 프로젝트 단계를 마무리하기 위한 활동을 진행하고 종결 합니다. 마지막으로 얻은 교훈, 회고, 조달, 자금, 자원을 고려해야 합니다. 프로젝트 관리 오피스(PMO)는 프로젝트 관리 방법론을 제정하고 소프트웨어나 템플릿을 제공하며 회사 전체 관점에서 프로젝트를 통합 관리하는 조직 기구입니다. 프로젝트 관리 오피스에서는 프로젝트와 관련된 거버넌스 프로세스를 표준화하고 자원, 방법론, 도구와 기법 등을 공유하고 지원합니다.
프로젝트 관리 오피스의 책임은 프로젝트 관리 자원 기능을 제공하는 것부터 한 가지 이상의 프로젝트를 직접 관리하는 유형 등 다양합니다. 예측형 프로젝트는 프로젝트 초반에 범위와 일정, 원가를 예측하고 확정하고 프로젝트를 진행합니다. 프로젝트 범위 변경은 예측형 프로젝트에 악영향을 주게 됩니다. 따라서 예측형 프로젝트에서는 변경을 통제하고 관리해야 합니다. 변경 관리를 위해 발주사와 수행사 모두 함께 참여하는 변경 통제위원회를 두고 변경 요청사항에 대한 내용을 합의하여 결정하도록 합니다. 기준선을 변경하지 않는 변경 요청에 대한 결정권자는 일반적으로 프로젝트 매니저가 의사 결정 할 수 있습니다.
프로젝트 프로세스 케이스 별 이해
프로젝트 매니저(PM)는 범위 관리 프로세스에 따라 업무 범위를 명확하게 정의하고 범위 달성을 위한 일정과 예산 계획을 수립하게 됩니다. 불필요한 변경을 통제하기 위해서 공식적인 변경 통제 프로세스를 구축할 수 있습니다. 이는 예측형 생애주기 프로젝트에서 진행되는 프로세스입니다. 예측형 생애주기는 계획 중심으로 진행되는 워터폴 프로젝트 방법론입니다. 프로젝트 착수 시점에 범위를 명확하게 하고 범위 달성을 위한 일정, 예산 계획을 철저하게 수립한 다음 계획에 따른 프로젝트를 진행하는 가장 일반적이고 전통적인 프로젝트 방법론입니다. 프로젝트와 제품에 대한 이해도가 높은 경우에 적합한 방법입니다.
프로젝트 생애주기는 일반적으로 제품 생애주기 안에 포함됩니다. 일반적으로 제품의 생애 주기가 프로젝트 생애 주기 보다 길며 프로젝트 생애 주기는 제품 생애 주기 안에 포함되는 경우가 많습니다. 프로젝트 생애주기와 단계에 대해서 하나의 단계 만으로 구성된 프로젝트가 있을 수도 있다는 것을 알아둘 필요가 있습니다. 제품 생애 주기는 일반적으로 개념 정의, 도입 성장과 성숙, 폐기의 과정을 거치게 됩니다. 예측형 방법론을 적용하는 프로젝트에서는 프로젝트 매니저가 새로운 프로젝트를 시작할 때 권한 수준을 알고 싶다면 프로젝트 헌장 문서를 확인하면 됩니다.
프로젝트 헌장은 프로젝트 채택을 공식적으로 승인하고 프로젝트 매니저에게 프로젝트 조직에 대한 권한을 부여하기 위한 문서입니다. 우리나라의 경우 품의서라고 하는 절차를 통해서 프로젝트 매니저의 권한을 기술하는 경우도 많습니다. 프로젝트 헌장에는 회사 별로 업종별로 다릅니다. 하지만 주로 프로젝트 목적, 측정 가능한 프로젝트 목표와 해당하는 성공 기준, 프로젝트의 상위 수준 요구 사항, 상위 수준의 프로젝트 설명과 범위, 중요한 인도물이 기재됩니다. 프로젝트를 진행함에 있어서 포괄적인 리스크도 기술됩니다. 그리고 프로젝트 마일스톤과 일정도 요약해서 기술됩니다.
사전에 승인된 재정 자원, 핵심 이해관계자 목록, 프로젝트 승인 요구사항, 프로젝트 성공의 구성 요건, 프로젝트 여부 결정권자, 프로젝트 승인권자도 정의됩니다. 프로젝트나 단계를 종료하거나 취소하기 위해서 충족해야 할 요건이 기술되며 선임된 프로젝트 매니저, 담당 업무와 권한 수준을 기재하게 됩니다. 프로젝트 헌장을 승인하는 스폰서나 기타 주체의 이름과 권한도 함께 명시됩니다. 프로젝트 헌장을 승인할 수 있는 의사결정권자는 회사의 고위 임원입니다.
프로젝트 매니저는 프로젝트 진행 중에 기준선에 대한 변경이 필요하여 변경 요청을 하였는데 변경통제위원회의 명단에 중요한 고객과 스폰서가 누락되어 있다면 프로젝트 매니저는 변경통제위원회에 포함되지 않았던 중요한 고객과 스폰서의 승인을 모두 받는 것이 좋습니다. 예측형 개발 방법론을 적용한 프로젝트에 새로운 프로젝트 매니저가 투입되었을 때 프로젝트에 대한 전반적인 이해를 위해서 프로젝트 헌장을 살펴 보는 것이 중요합니다. 프로젝트 진행 중에 예상하지 못한 문제에 직면하게 되었을 때 이슈 기록부에 등재하고 관리해야 합니다. 이슈 기록부에는 이슈 제기자와 발생 시점, 우선 순위, 최종 해결책에 대한 내용이 담깁니다. 이슈 기록부에는 모든 이슈를 기록하고 추적하는 프로젝트 문서입니다.
프로젝트 대응 방법에 대한 이해와 설명
프로젝트 대응 방법을 알고 있는 것은 프로젝트를 진행하는 프로젝트 매니저 입장에서는 매우 중요한 역량과 지식입니다. 프로젝트 매니저는 프로젝트를 진행하면서 겪게 될 다양한 상황들에 대해서 합리적이고 체계적으로 접근할 수 있어야 합니다. 특히 프로젝트 프로세스 관점에서는 프로세스에 적합한 대응 방법과 전략을 구사할 수 있어야 합니다. 프로젝트 프로세스 영역에서 프로젝트 매니저가 프로젝트 상황에 적합한 대응할 수 있도록 프로젝트 대응 방법에 대해서 좀 더 자세히 알아보도록 하겠습니다.
프로젝트 대응 방법에 대한 이해
프로젝트 매니저(PM)는 한번 그 역할을 맡게 되면 회사에서 진행하는 프로젝트에서 선임되어 역할을 하게 될 가능성이 높습니다. 따라서 프로젝트 매니저는 한번 역할을 맡게 되는 순간 앞으로도 계속 프로젝트 매니저로서의 역할을 수행해야 할 수 있습니다. 프로젝트 매니저의 역할은 매우 중요하면서 어렵기 때문에 첫 번째의 프로젝트를 진행하고 나서 이어서 두 번째 프로젝트를 진행할 수도 있습니다. 만약 두 번째 프로젝트를 진행하게 되었을 때 두 번째 프로젝트의 업무 범위가 계속 증가한다면 다른 프로젝트들에서 경험 되었던 노하우나 교훈을 적용할 수 있습니다.
물론 프로젝트 매니저 본인이 경험했던 프로젝트에서 얻은 교훈이면 좋지만 만약 그렇지 않다면 회사에서 진행되었던 유사한 프로젝트를 참고할 수 있습니다. 이 때 회사의 프로젝트 관리 오피스(PMO)를 통해서 이전 프로젝트의 교훈 정보를 얻을 수 있습니다. 프로젝트 관리 오피스도 책임과 역할이 있습니다. 프로젝트 관리 오피스는 프로젝트를 중앙 통제 방식으로 관리하기 위해서 필요한 다양한 권한과 책임을 배정 받은 조직입니다. 프로젝트 관리 오피스는 보고만 하는 조직이 아니라 단순 지원 업무에서 부터 직접적인 통제까지 다양한 역할을 맡아야 합니다. 프로젝트 관리 오피스의 역할 중 하나는 바로 프로젝트에 대한 정보를 축적하여 다른 프로젝트에서도 활용할 수 있도록 하는 것입니다.
이전 프로젝트의 정보들을 잘 축적하고 잘 관리해야 하는 의무가 있는 것입니다. 프로젝트 대응 방법으로 문제의 상황에서 프로젝트 매니저가 프로젝트 관리 오피스로부터 이전의 프로젝트 정보와 가이드를 받아서 진행하는 것이 가장 좋은 방법입니다. 예측형 프로젝트의 프로젝트 매니저인데 만약 프로젝트가 종료를 앞두고 프로젝트 범위와 인수 기준에 대해서 최종적으로 다시 한번 확인하고자 한다면 프로젝트 범위 기술서 문서를 확인하면 됩니다. 프로젝트에서는 작업 분류 체계(WBS) 구성 요소 중 프로젝트의 원가와 자원, 그리고 일정을 산정하는 기준이 되는 것은 작업 패키지입니다. 작업 분류 체계의 최하위 수준의 구성 요소는 작업 패키지라고 합니다. 작업 패키지 안에는 계획된 작업들이 포함되고 작업 패키지를 사용하여 작업 일정을 계획하며 작업을 예측하고 감시, 통제하는 활동들을 분류할 수 있습니다.
작업 패키지는 작업을 완료하는데 필요한 일정, 자원, 원가가 기술되어 있어서 산정과 통제의 기준이 됩니다. 작업 분류 체계(WBS)는 일반적으로 상세하게 분할하면 할수록 원가나 일정의 추정이 더 정확해지기 때문에 가능한 만큼 상세하게 분할하는 것이 좋습니다. 다만, 작업 분류 체계를 너무 상세하게 분류하면 작성 시간이 증가하여 프로젝트에 불필요한 부담이 될 수 있는 것도 알아야 합니다.
프로젝트 작업 분류 체계는 의미 있는 산출물을 산출할 수 있을 때까지 분할하면 가장 좋습니다. 프로젝트를 효과적으로 관리하거나 통제할 수 있는 수준까지 분할하면 좋습니다. 작업 분류 체계는 현실적인 일정 추정이 가능할 때까지 분할하는 것이 좋습니다. 작업 분류 체계에는 작업 내용과 함께 그 작업을 수행할 인력이 배정되어 있어 작업 패키지에 대한 책임감을 높일 수 있습니다. 이를 통해 누가 무슨 작업을 책임지고 있는지도 알 수 있습니다. 만약 서로 다른 팀원이 동일한 업무를 하고 있다면 작업 분류 체계 문서를 다시 한번 확인해봐야 할 것입니다.
프로젝트 대응 방법에 대한 설명
프로젝트 매니저(PM)가 프로젝트 착수 회의를 마무리하고 프로젝트 요구사항 정의를 준비하고 있을 때 가장 먼저 참고해야 할 내용은 프로젝트 범위 기술서입니다. 프로젝트에서 가장 먼저 해야 할 일은 프로젝트 헌장을 작성하고 프로젝트 시작을 공식적으로 승인 받는 것입니다. 그 다음 프로젝트 이해 관계자들을 식별하고 이해관계자 관리 대장을 만들어야 합니다. 이후 프로젝트 관리 계획서를 작성하고 그 중 이해관계자 참여 관리 계획서도 함께 작성해야 합니다. 이후 프로젝트 범위를 보다 구체화하기 위해서 프로젝트 요구 사항을 수집하고 요구 사항을 정리하며 요구 사항을 확정하고 프로젝트 범위 기술서를 작성하는 것입니다. 프로젝트 요구 사항을 정의하기 위해서는 프로젝트 범위 기술서가 중요합니다. 이를 통해 프로젝트의 개발 단계를 본격적으로 시작할 수 있는 것입니다.
프로젝트를 진행하다 보면 프로젝트 기간이 길다 보니 때에 따라서 프로젝트를 승인해준 대표이사나 중요한 이해 관계자가 변경될 수 있습니다. 이러한 경우 프로젝트 매니저는 새로운 대표이사와 새로운 이해 관계자를 찾아가서 새로운 요구 사항이 무엇인지를 파악할 필요가 있습니다. 프로젝트 중간에 대표이사와 새로운 이해 관계자가 변경되지 않는 것이 가장 좋습니다. 하지만 부득이한 상황으로 변경될 경우 새로운 대표이사와 이해 관계자의 지원을 계속 받을 수 있도록 프로젝트를 설명하고 방향성과 요구사항을 확인해야 합니다. 프로젝트 매니저가 변경되는 경우도 있습니다. 새로운 프로젝트 매니저로 선임된 사람은 프로젝트에 대해서 빠르게 이해하고 파악해야 합니다. 만약 이전 프로젝트 매니저가 누락한 부분이 있으면 이를 보완해서 정상적인 궤도로 돌려 놓을 필요도 있습니다.
예를 들어 프로젝트 작업 분류 체계가 작성되지 않은 상태로 프로젝트가 진행되고 있다면 프로젝트 현황을 파악하여 프로젝트 헌장을 수정하고 작업 분류 체계를 작성한 후 일을 다시 체계적으로 진행해야 합니다. 프로젝트 팀은 검수가 완료된 인도물을 고객에게 전달하였는데 고객이 인수하지 않으려고 한다면 프로젝트 매니저는 요구사항 추적 매트릭스를 주기적으로 관리하지 않은 것입니다. 프로젝트 검수가 완료되었으면 법적으로는 프로젝트가 종료된 것입니다. 하지만 프로젝트를 완료하고 나서 고객이 불만이나 불안으로 인수하지 않으려고 하는 경우도 있습니다. 이러한 경우 고객이 안심하고 인수할 수 있도록 요구한 내용이 제품에 반영이 되었다는 신뢰를 주어 불안감을 없애주는 것이 필요합니다. 이러한 작업을 하기 위해서 고객에게 요구 사항 추적 매트릭스를 보여주는 것이 효과적입니다.
다만, 만약 시스템에 오류가 너무 많아 문제가 많을 것으로 예상이 된다면 프로젝트를 종료 시키지 말고 오류 조치와 함께 계속 안정화 단계를 진행해야 할 것입니다. 실제 프로젝트를 진행할 때 오류가 많은 상태임에도 불구하고 무리하게 오픈을 강행하여 회사의 명성에 문제를 발생 시키고 사용자들에게 피해를 주는 경우도 있습니다. 프로젝트 매니저는 모든 팀원들을 선발하는 경우도 있지만 팀원들이 지정되어서 구성되는 경우도 있습니다. 팀원들이 구성되었을 때 경쟁력 수준이 낮은 팀원이 배치되는 경우도 있습니다.
이 경우 해당 팀원을 프로젝트에서 제외 시키거나 다른 팀원들에게 업무를 넘기는 것은 사실상 올바르지 않습니다. 변경된 경쟁력 수준에 맞게 활동 기간을 조정하고 프로젝트 일정 단축을 위한 대안을 찾는 것이 가장 올바른 방법입니다. 주공정법를 이용하여 프로젝트 기간을 산정할 수 있습니다. 주 경로는 다수로 발생할 수 있습니다. 프로젝트 달력은 일반적으로 작업 활동의 가용 여부를 알기 위해서 근무일, 휴일, 교대 일정 등에 대한 내용을 기록한 것입니다. 이는 프로젝트 만을 위한 달력인 셈입니다.
프로젝트 대응 방법에 대한 부연 설명
프로젝트 매니저(PM)가 보았을 때 한 작업이 지연되고 있고 일정 기준선은 어느 정도 여유가 있는 상황일 경우 일정 기준선에는 문제가 없더라도 특정 작업이 지연되고 있으면 해당 원인을 조사하고 해당 원인에 의거하여 대책을 수립해야 합니다. 프로젝트가 거의 끝나가는 종료 시점에 고객 쪽에서 큰 변경을 요청하는 경우가 있습니다. 이러한 변경을 진행하기 위해서는 예산이 더 필요한 상황일 경우 프로젝트에서 우발 사태 예비로 책정해 놓은 예산을 사용할 수 있습니다. 하지만 이 경우 변경 통제 프로세스를 진행해야 합니다.
모든 변경 사항에 대해서는 변경 요청서가 필요합니다. 변경 요청서가 발행되면 발주사와 수주사가 협의하여 변경 여부를 결정하게 됩니다. 변경 여부가 결정 되어야지만 비용을 사용할 수 있습니다. 우발 사태 예비를 사용할지 말지에 대한 결정에 앞서 변경 사항에 대한 합의를 먼저 하는 것이 중요합니다. 우발 사태 예비는 경영진의 승인 없어도 프로젝트 매니저가 집행할 수 있습니다. 우발 사태 예비는 예측이 가능한 리스크를 해결하기 위해서 사용되는 비용입니다. 예측 가능한 리스크였기 때문에 해당 리스크에 대한 해결을 위해서 해당 예산에 대해서는 미리 사전에 경영진의 승인을 받아 놓았기 때문입니다. 이에 따라 프로젝트 매니저의 권한 만으로도 사용하며 원가 기준선에 포함되어 있는 비용입니다.
프로젝트 매니저는 프로젝트 리스크에 대비하여 우발 사태 예비와 관리 예비를 확보하게 됩니다. 프로젝트 설계 때 투입되기로 한 인력이 이전 프로젝트에서 해지 되지 않고 그대로 있는 상황이라면 우발 사태 예비를 사용해야 할 수 있습니다. 우발 사태 예비는 예측 가능한 리스크에 대응하기 위해서 확보하는 비용이기 때문에 프로젝트 매니저가 미리 예측할 수 있는 리스크에 사용할 수 있습니다. 물론 프로젝트 투입 예정 인력이 시간에 맞춰서 해지 될 수 있는지 여부도 관건이 될 것입니다. 만약 프로젝트를 진행할 때 여러 업체들과 함께 프로젝트를 진행하는 프로젝트 매니저라면 여러 업체를 관리해야 합니다.
프로젝트 진행 과정에서 프로젝트 매니저의 활동으로 인해 어떤 업체의 원가가 증가하여 추가 비용을 요청한다면 가정 먼저 원가 증가에 대한 추가 정보를 요청해야 합니다. 가장 중요한 점은 무조건 먼저 실행하는 것이 아니라 원인 파악을 먼저 하는 것이 중요합니다. 원인 파악 없이 대책을 실행할 수는 없기 때문입니다. 프로젝트 유형 중 만약 신제품 개발과 관련된 프로젝트 매니저라면 프로젝트를 진행하는 도중에 시제품 테스트를 진행해보니 품질 결과가 좋지 않았을 때 온도가 품질에 영향을 줄 것이라는 의견이 나왔다면 프로젝트 매니저는 산점도 기법을 사용하여 검증해볼 수 있습니다.