|
3장 프로젝트 관리 프로세스(PROJECT MANAGEMENT PROCESS)
프로젝트 관리는 총체적인 노력(integrative endeavor)이다.(한 분야에서의 행위는 다른 분야에 영향을 미친다) 상호작용(interactions)은 간단하고 잘 이해될 수도 있고, 미묘하고 불확실할 수도 있다.
이들 상호작용은 프로젝트의 목표들 간에 상관분석(대안분석, 연관분석, trade-off)을 필요로 하게 되는데, 한 분야의 성능은 다른 분야의 성능을 희생하는 것에 의해서만 높일 수 있다. 성공적인 프로젝트 관리(PM)는 이들 상호작용들을 능동적으로 관리하는 것을 요구한다.
프로젝트 관리의 총체적인 성격(integrative nature of project management)을 이해하는데 도움을 주고, 통합의 중요성을 강조하기 위해서 프로젝트 관리를 요소 프로세스(component process)와 그들의 통합(integration)이라는 점에서 설명한다.
·프로젝트 프로세스(Project Process)
·프로세스 그룹(Process Groups)
·프로세스 상호작용(Process Interactions)
·프로세스 상호작용의 적합화(Customizing Procee Interactions)
3.1 Project Process
프로젝트는 프로세스들로 구성되며, 프로세스는 "결과를 야기하는 일련의 행위들(a series of actions bringing about a result)"이다. 프로젝트 프로세스는 사람에 의해 수행되며, 일반적으로 두 개의 주요 범주중 하나에 해당된다.
·프로젝트 관리 프로세스(Project management process)는 프로젝트의 작업을 기술하고 구성하는 것과 관련된다. 대부분의 경우에, 대부분의 프로젝트에 적용가능한 프로젝트 관리 프로세스를 간략하게 3장에서 설명하고, 4장부터 12장에 걸쳐 상세하게 설명한다.
·생산 지향 프로세스(Product-oriented process)는 프로젝트 생산물을 상세하게 기술하고 창조하는 것과 관련된다. 생산 지향 프로세스는 일반적으로 project life cycle에 의해 정의되며, 적용분야에 따라 변한다.(생산물에 기반한 프로세스)
프로젝트 관리 프로세스와 생산물 지향 프로세스는 프로젝트가 진행되는 동안 중첩되고 상호작용을 한다.
3.2 Process Groups
프로젝트 관리 프로세스는 각각 하나 또는 그 이상의 프로세스를 가진 다섯 개의 그룹으로 구성될 수 있다.
·착수 프로세스(Initiating processes) - 프로젝트나 단계가 시작되어야 한다는 것을 인식하고 그렇게 행하는 것(착안, 고안, 기안, 시작)
·계획 프로세스(Planning processes) - 프로젝트에서 하기로 약속된 사업요구를 달성하기 위하여 작업가능계획을 고안하고 지속하는 것
·실행 프로세스(Executing processes) - 계획을 실행하기 위해 인력과 자원들을 조정하는 것
·관리 or 통제 프로세스(Controlling processes) - 모니터링에 의해 프로젝트의 목표들을 충족시키는 것을 보장하고, 진도를 측정하고, 필요할 때 수정조치하는 것
·종료 프로세스(Closing processes) - 프로젝트나 단계(phase)의 승인을 정식화하고, 정연하게 끝내는 것
프로세스 그룹들은 그들이 생산하는 결과에 의해 연결된다(하나의 프로세스 그룹의 결과는 다른 프로세스 그룹의 인풋이 된다). 주요한 프로세스 그룹들 간, 연결은 반복된다(계획은 조기에 문서화된 프로젝트 계획을 가지고 집행하게 하고, 프로젝트가 진행함에 따라 계획이 문서화되어서 update 되도록 한다. 이러한 연결은 그림 3-1에 설명되어 있다. 게다가 프로젝트 관리 프로세스 그룹은 분리된, 일회성 사건(events)이 아니다(프로젝트 관리 프로세스 그룹은 프로젝트의 각 단계를 통하여 다양한 강도의 레벨에서 발생하는 중첩된 액티비티들이다. 그림 3-2는 어떻게 프로세스 그룹들이 중첩되고 단계 내에서 변화하는지를 설명한다.
마지막으로 프로세스 그룹 상호작용은, 한 단계의 종료가 다음단계를 착수하기 위한 인풋을 제공하는 것과 같이, 단계들이 교차한다. 예를 들면, 설계단계의 종료는 고객에게 설계도의 승인을 요구한다. 동시에, 설계도는 이어지는 실행단계(implementation phase)를 위한 생산물의 설명을 규정한다. 이런 상호작용은 그림 3-3에 설명되어 있다.
각 단계의 처음에서 착수 프로세스의 반복은 해야하는 프로젝트를 수행해야 할 사업요구에 중점을 두도록 유지하는데 도움이 된다. 이것은 또한 사업요구가 더 이상 존재하지 않거나 프로젝트가 그 요구를 만족시킬 것 같지 않으면 프로젝트가 중지되는 것을 확실하게 하는데 도움이 될 것이다. 사업상의 요구는 5.1절 착수(Initiation)의 도입부분에서 상세하게 논의된다.
비록 그림 3-3이 별개의 단계와 별개의 프로세스를 그렸다고 하더라도, 실제 프로젝트에서는 많은 중첩이 있다. 예를 들면, 계획 프로세스는 프로젝트의 현재단계를 성공적으로 완성하기 위해 행해지는 작업을 상세하게 제공해야 할뿐만 아니라, 다음단계에서 수행될 작업에 대한 어느 정도의 예비설명을 제공해야 한다. 이러한 진행을 하는 프로젝트 계획의 상세화는 종종 rolling wave planning이라고 불린다.
3.3 Process Interactions
각 프로세스 그룹 안에서, 개개의 프로세스들은 인풋과 아웃풋에 의해 연결된다. 이러한 연결(links)에 중점을 둠으로써, 각각의 프로세스를 인풋, 툴과 테크닉(도구와 기법), 아웃풋이라는 말로 설명할 수 있다.
·인풋: 수행되어야 하는 문서나 문서화할 수 있는 항목
·도구와 기법: 아웃풋을 창출하기 위해 인풋에 적용되는 매카니즘
·아웃풋: 프로세스의 결과인 문서나 문서화할 수 있는 항목
대부분의 적용지역에서 대부분의 프로젝트에 공통적인 프로젝트 관리 프로세스는 3장에 나열되어 있고, 4장부터 12장에 걸쳐 상세하게 설명된다. 덧붙여 말하면, 프로세스 이름 뒤에 숫자는 이것이 설명되어 있는 장과 절을 밝히고 있다. 여기서 설명된 프로세스 상호작용은 대부분의 적용지역에서 대부분의 프로젝트에 사용되는 표준적인 것이다. 3.4절은 프로세스 설명과 상호작용을 적합화(customizing)하는 것에 대해 논의한다.
3.3.1 착수 프로세스
그림 3-4는 착수 프로세스 그룹의 단일 프로세스를 나타내고 있다.
·Initiation(5.1) - 프로젝트의 다음단계를 시작하기 위해 조직을 구성하는 것.
3.3.2 계획 프로세스
계획은 프로젝트가 전에는 수행한 적이 없는 어떤 것을 포함하고 있기 때문에 프로젝트에 있어서 매우 중요하다. 결론적으로, 이 절에는 상대적으로 많은 프로세스들이 있다. 그러나, 많은 프로세스가 "프로젝트 관리는 주로 계획이다"라는 것을 의미하지는 않는다. 수행되는 많은 계획은 프로젝트의 범위와 개발된 정보의 유용성에 비례해야 한다.
프로젝트 계획 프로세스들간의 관계는 그림 3-5에서 보여진다. 이 프로세스들은 계획이 완성되기 전에 종종 반복되는 것을 필요로 한다. 예를 들면, 초기의 완성일자가 수락되지 않는다면 프로젝트 자원, 비용, 심지어 범위까지 재 정의될 필요가 있을 수 있다. 게다가 계획이 정확한 과학이 아니기 때문에 두 개의 다른 팀은 동일 프로젝트에 대해 매우 다른 계획을 생성할 것이다.
핵심프로세스(Core processes). 일부 계획 프로세스들은 대부분의 프로젝트에서 동일한 순서로 수행되는 것이 요구되는 명확한 의존관계(종속관계-dependencies)를 가지고 있다. 예를 들면, 액티비티는 일정을 잡고 비용을 계산하기 전에 정의되어야 한다. 이러한 핵심 프로세스는 프로젝트의 어떤 한 단계 동안에 수차례 반복될 것이다. 핵심 프로세스는 다음을 포함한다.
·Scope Planning(5.2) - 향후 프로젝트 결정의 기초로서 서면으로 된 범위기술(scope statement)을 개발
·Scope Definition(5.3) - 주요 프로젝트 성과물을 소형의 보다 관리하기 쉬운 요소로 분할
·Activity Definition(6.1) - 다양한 프로젝트 성과물을 생산하기 위해 수행되어야만 하는 특수한 액티비티들을 규정
·Activity Sequencing(6.2) - 엑티비티들 상호간의 의존관계(종속관계)를 규정하고 문서화
·Activity Duration Estimating(6.3) - 개개의 액티비티들을 완수하는데 필요할 작업기간의 수를 계산
·Schedule Development(6.4) - 프로젝트 일정을 세우기 위해 액티비티 순서, 액티비티 공기, 자원요구조건을 분석
·Resource Planning(7.1) - 프로젝트 액티비티들을 수행하기 위해 어떤 자원이 얼마만큼 필요한가를 결정
·Cost Estimating(7.2) - 프로젝트 액티비티들을 수행하기 위해 필요한 자원의 비용에 대한 개산견적(approximation)을 개발
·Cost Budgeting(7.3) - 전반적인 견적비용을 개개의 작업 항목으로 할당
·Project Plan Development(4.1) - 다른 계획 프로세스들의 결과를 수집하고, 이것을 일관성있는 문서에 담는다.
촉진 프로세스(Facilitating processes). 다른 계획 프로세스들간의 상호작용은 프로젝트의 성격에 많이 의존한다. 예를 들면, 어떤 프로젝트에서, 대부분의 계획이 시행되고, 프로젝트팀이 비용목표와 일정목표가 매우 빠듯하다는 것을 인식하기 직전까지는 규정할 수 있는 리스크가 거의 없거나 아예 없고, 그런 까닭에 상당한 리스크가 수반된다. 비록 이런 촉진 프로세스들이 프로젝트 계획동안에 간헐적으로 필요에 따라 수행된다고 하더라도, 촉진 프로세스들은 옵션이 아니다. 촉진 프로세스들은 다음을 포함하고 있다.
·Quality Planning(8.1) - 어떤 품질기준이 프로젝트와 상관이 있는지를 규정하고, 기준들을 어떻게 충족시킬지를 결정
·Organizational Planning(9.1) - 프로젝트 역할, 의무, 보고관계를 규정하고 문서화하고 할당
·Staff Acquisition(9.2) - 배속된 필요 인적자원을 모아서 프로젝트를 수행
·Communication Planning(10.1) - 관련자들의 정보와 의사소통 요구를 결정. 누가 어떤 정보를 필요로 하며, 언제 이 정보가 필요하고, 어떻게 이것이 관련자들에게 주어질 것인가.
·Risk Identification(11.1) - 어떤 리스크가 프로젝트에 영향을 미칠 것인가를 결정하고 각각의 특성을 문서화
·Risk Quantification(11.2) - 가능한 프로젝트 결과물의 범위를 사정하기 위해서 리스크와 리스크의 상호작용을 평가
·Risk Response Development(11.3) - 위험에 대해서 기회와 반응을 위한 강화단계(enhancement steps)를 정의
·Procurement Planning(12.1) - 무엇을 구매하고 언제 구매할지를 결정
·Solicitation Planning(12.2) - 생산물 요구조건을 문서화하고, 잠재적인 소스(sources)를 규정
3.3.3 실행 프로세스
실행 프로세스는 3.3.2절의 계획 프로세스에서 설명한 것처럼 핵심 프로세스와 촉진 프로세스를 포함한다. 그림 3-6은 다음의 프로세스들이 어떻게 상호작용하는지를 보여준다.
·Project Plan Execution(4.2) - 포함된 액티비티들을 수행함으로써 프로젝트 계획을 실행
·Scope Verification(5.4) - 프로젝트 범위의 수락을 공식화
·Quality Assurance(8.2) - 프로젝트가 관련 품질기준을 만족시킬수 있다는 확신을 제공하기 위해 정상적인 기반에서 전체적인 프로젝트 성능을 평가
·Team Development(9.3) - 프로젝트 성능을 향상시키기 위해 개인과 그룹의 기술을 발전시킴
·Information Distribution(10.2) - 필요한 정보를 프로젝트 관련자들이 시의적절하게 이용할 수 있도록 함
·Solicitation912.3) - 적절하게 견적, 입찰, 신청, 제안을 함
·Contract Administration(12.5) - 판매자와의 관계를 관리
3.3.4 관리 프로세스
프로젝트 성능은 계획으로부터의 변화를 규정하기 위해서 규칙적으로 측정해야 한다. 변화량은 다양한 지식영역에서 관리 프로세스로 공급된다. 상당한 변화량이 관측되는 범위까지, 계획에 대한 조정은 적절한 프로젝트 계획 프로세스들을 반복함으로써 만들어진다. 예를 들면, 실수한 액티비티 마감일은 직원계획(staffing plan), 시간외 노동에의 의지 또는 예산과 일정 목표사이의 상관분석의 조정을 필요로 할 것이다. 관리는 또한 발생할 수 있는 문제점들을 예측하여 예방조치를 취하는 것을 포함한다.
관리 프로세스 그룹은 3.3.2의 계획 프로세스에서 설명한 핵심 프로세스와 촉진 프로세스를 포함한다.
그림 3-7은 다음의 프로세스들이 어떻게 상호작용하는지를 보여준다.
·Overall Change Control(4.3) - 프로젝트 전체에 걸쳐 변경(changes)을 조정
·Scope Change Control(5.5) - 프로젝트 범위에 대한 변경을 관리
·Schedule Control(6.5) - 프로젝트 일정에 대한 변경을 관리
·Cost Control(7.4) - 프로젝트 예산에 대한 변경을 관리
·Quality Control(8.3) - 관련품질기준을 따르고 있는지를 결정하기 위해 특별한 프로젝트 결과를 모니터링하고, 불만족한 성능의 원인을 제거하기 위한 방법을 규명
·Performance Reporting(10.3) - 성능정보를 수집하고 유포. 성능보고에는 현황보고(status reporting), 진도측정(progress measurement), 예측(forecasting)을 포함한다.
·Risk Response Control(11.4) - 프로젝트 과정상에서 리스크의 변경에 대응
3.3.5 종료 프로세스
그림 3-8은 다음의 프로세스들이 어떻게 상호작용하는지를 보여준다.
·Administrative Closure(10.4) - 단계나 프로젝트의 종료를 공식화하기 위해 정보를 발생시키고, 모으고, 유포하는 것
·Contract Close-out(12.6) - 남아있는 항목의 해결을 포함한 계약의 종료와 결산
3.4 프로세스 상호작용의 적합화
규정된 프로세스와 3.3절에서 설명된 상호작용은 일반적인 승인의 테스트를 충족해야 한다(이것들은 대부분의 경우에 대부분의 프로젝트에 적용된다). 그러나 모든 프로젝트에서 모든 프로세스가 필요하지는 않을 것이고, 모든 프로젝트에서 모든 상호작용이 적용되지는 않을 것이다. 예를 들면 다음과 같다.
·많은 수급업자들을 사용하는 조직은 계획 프로세스에서 각각의 구매 프로세스가 발생하는 곳을 명백하게 기술할 것이다.
·프로세스의 부재는 이것이 수행될 수 없다는 것을 의미하지 않는다. 프로젝트 관리팀은 성공적인 프로젝트를 보장하기 위해 필요한 모든 프로세스들을 규정하고 관리해야 한다.
·특수한 자원(unique resources - 상업용 software 개발, 생화학약물 제조 등)에 의존하는 프로세스는 수행되어야 할 것이 이것을 활용할 사람의 기능이 될 수도 있기 때문에 범위의 정의에 앞서 역할과 책임을 규정할 것이다.
·어떤 프로세스 아웃풋은 제한요소로서 미리 정해질 수 있다. 예를 들면, 관리는 계획 프로세스에서 결정된 완공일자를 따르기보다는 목표완공일자를 지정할 것이다.
·대형 프로젝트는 상대적으로 더욱 상세한 것을 필요로 할 것이다. 예를 들면, 리스크 규명은 각각 비용 리스크, 일정 리스크, 기술적 리스크, 품질 리스크를 집중적으로 규명하기 위해 더 세분될 수 있다.
·하위프로젝트와 소규모 프로젝트에서, 프로젝트 레벨(예를 들자면, 하수급업자들은 원수급업자에 의해 명백하게 예상된 리스크를 무시할 것이다)에서 규정된 프로세스 또는 최저의 설비(marginal utility)를 제공하는 프로세스에서는 상대적으로 적은 노력이 소요될 것이다.
변경을 필요로 할 때, 변경은 명백히 규정되고, 조심스럽게 평가되고, 적극적으로 관리되어야 한다.
프로젝트 통합관리는 프로젝트의 다양한 요소들이 적절하게 조정된다는 것을 보증하기 위해 필요한 프로세스들을 포함한다. 이것은 프로젝트 관련자들의 요구(needs)와 기대(expection)를 충족시키기 위해서 경쟁 목표들과 대안들 간의 상관분석을 수반한다. 모든 프로젝트 관리 프로세스가 어느정도 통합적인 것인 반면에 4장에서 설명하는 프로세스는 근본적으로 통합적이다. 그림 4-1은 다음의 주요 프로세스들의 개요(overview)를 제공한다.
4.1 프로젝트 계획 개발 - 다른 계획 프로세스들의 결과를 수집하고, 이것들을 일관성있는 문서에 담는다.
4.2 프로젝트 계획 집행 - 포함된 액티비티들을 수행함으로써 프로젝트 계획을 실행
4.3 전체적인 변경 관리 - 프로젝트 전체에 걸쳐 변경(changes)을 조정
이들 프로세스들은 서로간 상호작용을 하고 마찬가지로 다른 지식분야의 프로세스들과 상호작용한다. 각 프로세스들은 프로젝트의 요구(needs)에 기초한 하나 또는 그 이상의 개인 또는 개인으로 이루어진 그룹으로부터 노력을 수반할 수 있다. 각 프로세스들은 일반적으로 모든 프로젝트 단계에서 최소한 한번은 발생한다.
비록 여기서 프로세스들이 잘 정의된 인터페이스를 지닌 별도의 요소로서 나타나고는 있지만, 실제상 여기서 상세하게 다루지 않는 방법으로 중첩되고 상호작용한다. 프로세스 상호작용은 3장에서 상세하게 토론되었다.
프로젝트 관리 프로세스를 통합하기 위해 사용되는 프로세스, 도구, 기법들이 4장의 중점사항이다. 예를 들면, 프로젝트 통합관리는 비용견적이 예비비 계획을 위해 필요한 때나 다양한 조직 대안들과 관련된 리스크가 규정되어야 할 때 역할을 한다. 그러나 성공적으로 수행되어야 하는 프로젝트에 있어서, 통합은 많은 다른 분야에서 마찬가지로 발생해야 한다.
·프로젝트의 작업은 수행조직의 지속적인 운영과 통합되어야 한다.
·생산범위와 프로젝트 범위는 통합되어야 한다(생산범위와 프로젝트범위의 차이는 5장에서 설명된다).
·다른 기능을 가진 공종으로부터의 성과물(deliverables-토목, 전기, 엔지니어링 설계 프로젝트를 위한 기계 도면과 같은 것들)은 통합되어야 한다.
4.1 Project Plan Development
프로젝트 계획 개발은 프로젝트의 집행과 프로젝트 관리(project control)를 가이드 하기 위해 사용될 수 있는 일관된 문서를 만들기 위해서 다른 계획 프로세스의 결과물을 사용한다. 이 프로세스는 거의 매번 수차례 반복된다. 예를 들면, 최종도면이 특별한 자원과 명백한 일자를 반영하는 반면에 초기도면은 일반적인 자원과 갱신된 공기를 포함한다. 프로젝트 도면은 다음과 같이 사용된다.
·프로젝트 집행의 지침
·프로젝트 계획 추정(가정)을 문서화
·선정된 대안들을 고려하는 프로젝트 계획 결정의 문서화
·프로젝트 관련자들간의 의사소통을 촉진
·내용, 정도, 그리고 시기에 관하여 핵심 관리검토 사항을 정의
·진도관리와 프로젝트 관리(project control)에 관한 기선을 제공
4.1.1 Inputs to Project Plan Development
.1 다른 계획 아웃풋(other planning outputs). 다른 지식분야에서 계획 프로세스의 모든 아웃풋은 다른 프로젝트 계획을 개발하기 위한 인풋이다. 다른 계획 아웃풋은 지원도면(supporting detail)은 물론 WBS와 같은 기본문서를 포함한다. 많은 프로젝트들은 적용지역의 특수한 인풋을 필요로 할 것이다(예를 들면, 많은 건설프로젝트들은 소요자금예측을 필요로 할 것이다).
.2 역사적 정보(historical information). 이용가능한 역사적 정보(견적 DB, 과거의 프로젝트 성능 기록)는 다른 프로젝트의 계획 프로세스 동안에 참고가 되어야 한다. 이 정보는 추정(가정)을 증명하고 이 프로세스의 일부로서 확인된 대안들을 평가하는 것을 돕기 위한 프로젝트 계획 개발 동안에 이용가능해야 한다.
.3 조직 방침(organizational policies). 프로젝트에 관련된 어떤 혹은 모든 조직은 그것들의 영향이 고려되어야 하는 공식적 방침과 비공식적 방침을 가지고 있을 것이다. 고려되어야만 하는 조직 방침은 다음을 포함하지만 제한은 없다.
·품질관리 - 프로세스 감사(process audit), 지속적인 향상목표
·직원운영 - 고용과 해고기준, 종업원 수행능력 검토
·재정관리 - 시간 보고서(time reporting), 소요 지출과 지급 검토, 회계코드, 표준계약규정
.4 제약요소(constraints). 제약요소는 프로젝트 관리팀의 옵션을 제한하는 요소이다. 예를 들면, 미리 정해진 예산은 범위, 직원, 일정에 관한 팀의 옵션을 매우 제한하기 쉬운 제약요소이다. 프로젝트가 계약하에 수행될 때, 계약규정은 일반적으로 제약요소가 된다.
.5 추정(가정-assumptions). 계획목적에 있어서, 추정(가정)은 진실, 사실 또는 확실하게 되도록 고려되어야 할 요소이다. 예를 들면, 핵심적인 사람을 이용할 수 있는 날짜가 불확실하다면, 팀은 특별한 착수일을 추정(가정)할 것이다. 추정(가정)은 일반적으로 어느정도의 리스크를 수반한다.
4.1.2 프로젝트 계획 개발을 위한 도구와 기법
.1 프로젝트 계획 방법론(project planning methodology). 프로젝트 계획 방법론은 프로젝트 계획을 개발하는 동안에 프로젝트팀을 지도하기 위해 사용되는 구조적 접근방법(structured approach)이다. 이것은 표준형식이나 템플리트처럼 단순하거나 일련의 필요한 시뮬레이션처럼 복잡할 수도 있다. 대개의 프로젝트 계획 방법론은 프로젝트 관리 소프트웨어와 같은 하드 툴과 촉진을 위한 시작미팅(start-up meeting)과 같은 소프트 툴의 조합을 이용한다.
.2 프로젝트 관련자의 기술과 지식(stakeholder skills and knowledge). 모든 관련자들은 프로젝트 계획을 수립하는데 도움이 될 수 있는 기술과 지식을 가지고 있다. 프로젝트 관리팀은 관련자들이 적절하게 기여할 수 있는 환경을 만들어야만 한다. 누가, 무엇을, 언제 기여하는가는 달라질 것이다. 예는 다음과 같다.
·총액계약하에 수행되고 있는 건설프로젝트에서, 전문적인 비용 엔지니어는 계약금이 결정될 때 입찰서 준비(proposal preparation) 동안에 수익성에 관한 목표에 있어서 커다란 기여를 할 것이다.
·사전에 직원이 정해진 프로젝트에서, 각각의 기여자는 합리적으로 공기와 노력 견적을 검토함으로써 비용목표와 일정목표를 조화하는데 상당히 기여할 것이다.
.3 프로젝트 관리정보시스템(Project management information system, PMIS). 프로젝트 관리정보시스템은 다른 프로젝트 관리 프로세스의 아웃풋을 모으고, 통합하고, 유포하는 데 사용되는 툴과 테크닉으로 구성된다. 이것은 착수부터 종료까지 프로젝트의 모든 면을 지원하기 위해 사용되고 일반적으로 수작업과 자동화된 시스템 양자를 포함한다.
4.1.3 Outputs from Project Plan Development
.1 프로젝트 도면(Project plan). 프로젝트 도면은 프로젝트 실시를 관리하고 통제하기 위해 사용되는 공식적이고 승인된 문서이다. 이것은 의사소통 관리 계획에서 정의된 것처럼 분류되어야 한다(예를 들어, 단일 프로젝트에서 수행조직의 관리는 그다지 상세하지 않은 넓은 적용범위를 필요로 하는 반면에 수급업자는 완전한 디테일을 요구할 것이다).
프로젝트 도면과 프로젝트 수행 측정 기준선 사이에는 명확한 구별이 있어야 한다. 프로젝트 도면은 프로젝트에 관해서 더욱 많은 정보들이 이용가능하게 됨으로써 공사기간을 변경하도록 기대되는 문서나 문서의 집합이다. 수행측정기준은 간헐적으로 변경될 것이고 일반적으로 승인된 범위변경에 대해서만 변경되는 관리통제(management control)를 나타낸다.
프로젝트 도면을 구성하고 나타내는 데에는 많은 방법이 있지만, 보통 다음을 전부 포함한다(이 항목들은 다른곳에서 상세하게 설명된다).
·프로젝트 헌장(project charter)
·프로젝트 관리방식이나 전략에 대한 기술(다른 지식분야로부터 각각의 관리계획의 요약)
·프로젝트 생산물과 프로젝트 목표를 포함하는 범위선언(제시-statement)
·관리가 행해지는 레벨에서의 작업분류체계
·관리가 행해지는 WBS의 레벨에서 비용견적, 계획된 착수일자, 책임할당
·일정과 비용에 관한 수행측정기준
·주요 마일스톤과 각각에 대한 목표일
·핵심직원 또는 필요한 직원
·제약요소와 추정(가정)을 포함하는 주요 리스크와 각각에 대한 계획된 대응(plannde response)
·범위관리도면, 일정관리도면 등을 포함하는 부수적인 관리도면
·공개된 문제와 임박한 결정사항(open issues and pending decisions)
다른 프로젝트 계획 아웃풋은 각각의 프로젝트의 요구에 기초한 공식도면(formal plan)을 포함해야 한다. 예를 들면, 대형 프로젝트에 있어서 프로젝트 도면은 일반적으로 프로젝트 구성차트를 포함한다.
.2 지원도면(supporting detail). 프로젝트 도면을 위한 지원도면은 다음을 포함한다.
·프로젝트 도면을 포함하고 있지 않은 다른 계획 프로세스로부터의 아웃풋
·프로젝트 도면의 개발중에 생성된 부가정보나 문서(예를 들면, 미리 알려지지 않았던 제약요소와 추정(가정))
·요구조건, 시방서, 설계와 같은 기술적인 문서
·관련표준 문서
이러한 자료는 프로젝트 도면의 실행동안에 사용을 용이하게 하기 위해서 필요에 따라 구성되어야 한다.
4.2 Project Plan Execution
프로젝트 도면 실행은 프로젝트 도면을 실행하는데 중요한 프로세스이다. 프로젝트 예산의 매우 주요한 것이 이 프로세스를 수행하면서 소비될 것이다. 이 프로세스에서, PMr과 프로젝트 관리팀은 프로젝트에 존재하는 다양한 기술적 인터페이스와 조직적 인터페이스를 조정하고 지시해야 한다. 이것은 프로젝트의 생산물이 실제적으로 창조되는 프로젝트 적용 분야에 의해 직접적으로 대부분의 영향을 받는 프로젝트 프로세스이다.
4.2.1 Input to Project Plan Execution
.1 프로젝트 도면(Project plan). 프로젝트 도면은 4.1.3.1절에 설명되어 있다. 부수적인 관리도면(범위관리도면, 리스크관리도면, 구매관리도면 등)과 수행측정기준은 프로젝트 도면 실행의 주요 인풋이다.
.2 지원도면(Supporting detail). 지원도면은 4.1.1.3절에 설명되어 있다.
.3 조직 방침(Organizational policies). 조직 방침은 4.1.1.3절에 설명되어 있다. 프로젝트에 관련되는 일부 혹은 모든 조직들은 프로젝트 도면의 실행에 영향을 끼칠수도 있는 공식과 비공식의 방침을 가지고 있을 것이다.
.4 수정조치(Corrective action). 수정조치는 예상되는 미래의 프로젝트 수행이 프로젝트 도면이 가진 기준을 따르게 하기 위해서 행하는 것이다. 수정조치는 효과적인 프로젝트 관리를 확실하게 하게 위해 필요한 feedback loop을 완성하는 인풋으로써 다양한 통제 프로세스의 아웃풋이다.
4.2.2 프로젝트 계획 실행을 위한 도구 및 기법
.1 일반 관리기술(General management skills). Leadership, 의사소통, 협상 등과 같은 일반 관리기술들은 프로젝트 계획을 효과적으로 실행하는데 필수적인 것이다. 일반 관리기술들은 2.4에 설명되어 있다.
.2 Product skills and knowledge(생산기술 및 생산지식). 프로젝트 팀은 프로젝트 생산품(완공된 시설물)에 관한 일련의 적당한 기술 및 지식을 활용해야 한다. 필요한 기술들은 계획(특히 7.1의 자원계획)의 일부로 규정되고 9.2에 설명된 직원 충원과정을 통해 제공된다.
.3 Work authorization system(작업 인증 시스템). 작업 인증(認證)시스템은 작업이 제 시간에 올바른 순서로 완성되었음을 보장하기 위해 프로젝트 작업을 인가(認可)하는 공식절차이다. 주로 이용되는 것은(the primary mechanism)은 통상 "작업이 특정 액티비티 혹은 작업 패키지에서 시작되어야 한다"는 서면 인증이다.
작업 인증시스템의 계획은 관리의 대가로 제공된 가치들을 조정해야 한다(예, 많은 소형 프로젝트에서는 구두(口頭)인증이 적합할 것이다).
.4 Status review meetings(상황검토 모임). 상황검토 모임들은 프로젝트관련 정보를 교환하기 위해 열리는 정기모임이다. 대부분의 프로젝트에서 상황검토 모임들은 다양한 빈도 및 수준(직급-level)에서 열릴 것이다(프로젝트 관리팀은 자체적으로 周마다, 고객(발주자)와는 月마다 만날 것이다).
.5 프로젝트 관리정보 시스템(Project Management Information System-이하 PMIS) 4.2.1.3에서 설명되어 있다.
4.2.3 Outputs from Project Plan Execution
.1 작업 결과(Work results). 작업결과는 프로젝트를 달성하기 위해 수행된 액티비티(작업)의 결과이다. 작업결과와 관련된 정보 즉, 어떤 작업이 완성되었으며, 어떤 것은 완성되지 않았으며, 품질의 표준은 어느 정도까지 충족되었으며, 얼마의 비용이 발생 혹은 집행되었는지 등이 프로젝트 계획 실행의 일부분으로써 수집되어 프로젝트 수행 보고과정에 제공된다(수행보고에 대한 자세한 사항은 10.3절 참조).
.2 변경 요구(Change requests). 변경요구(프로젝트 범위의 수축 혹은 확장, 비용 혹은 일정의 변경 등)들은 프로젝트의 작업이 수행중일 때 자주 확인된다.
4.3 Overall Change Control (전반적인 변경 관리)
전반적인 변경관리는 ①변경이 이롭다는 것을 보장해 주는 변경 유발요인들에게 영향을 미치고 ②변경의 발생을 결정하며 ③변경 발생시 실질적인 변경을 관리하는 것과 관련된다. 전반적인 변경관리는 다음의 사항을 요구한다.
·프로젝트 수행측정의 기준선(基準線)의 보존을 유지한다. 즉, 모든 승인된 변경들은 프로젝트 계획에 반영되어야 하고, 단지 프로젝트 범위변경들은 프로젝트 수행측정의 기준에 영향을 줄 수 있다.
·생산품(시설물)의 범위에 대한 변경사항들이 프로젝트의 범위의 정의에 반영되었음을 보장한다. (시설물과 프로젝트 범위간의 차이는 제 5장의 서문에서 논의됨)
·그림 4-2에 나타나는 지식영역에 걸쳐 있는 변경들을 조정한다. 예를 들면, 제안된 일정변경은 빈번히 비용, 리스크, 품질, 직원배치 등에 영향을 미친다.
4.3.1 Inputs to Overall Change Control
.1 프로젝트 계획(Project plan). 프로젝트 계획은 변경사항들이 관리되어야 할 기준선을 제공한다(4.1.3.1 참조).
.2 프로젝트 수행 보고서(Performance reports). 10.3절에 설명된 프로젝트 수행 보고서들은 프로젝트 수행에 정보를 제공한다. 수행보고서들은 또한, 프로젝트 팀이 미래에 문제를 야기시킬수도 있는 사안들을 알도록 일깨워 준다.
.3 변경요구(Change requests). 변경요구는 구두 혹은 서면, 직접 혹은 간접, 외부제공 혹은 내부제공, 법적 강제 혹은 선택 등의 다양한 형태로 발생할 수 있다.
4.3.2 Tools and Techniques for Overall Change Contral
.1 변경관리 시스템(Change control system). 변경관리 시스템은 직무상의 프로젝트 문서들이 변경될 수 있는 각 단계들을 정의하는 공식적이고, 문서화된 절차들을 모아 놓은 것이다. 여기에는 서면작업, 공사추적 시스템(tracking system), 변경을 정식으로 인가하는 데 필요한 승인 관리수준 등이 포함된다.
많은 경우에, 프로젝트 수행조직은 프로젝트에서 사용될 "as is"로 채택될 수 있는 변경관리시스템을 사용할 것이다. 그러나, 만약, 적당한 시스템이 사용될 수 없다면, 프로젝트 관리팀은 프로젝트의 일부로써 하나의 시스템을 개발할 필요가 있을 것이다.
많은 변경관리 시스템에는 변경요구들의 승인 혹은 거절을 책임 질 변경관리위원회(Change Control Board-CCB)가 포함된다. CCB의 권한과 책임은 잘 규정되어 주요 참여자들의 동의를 받아야만 한다. 대개, 복잡한 프로젝트에서 서로 다른 책임을 가진 다양한 CCB들이 포함될 수도 있다.
변경관리 시스템에는 사전 검토없이 승인될 수도 있는(예, 비상사태 발생시) 변경들을 처리할 절차들을 포함해야 한다. 통상, 변경관리 시스템은 변경사항들의 명확한 범주를 자동적으로 승인하는 것을 포함할 것이다. 이런 변경사항들은 프로젝트의 후반에 문제를 야기하지 않도록 계속 문서화되고 포획되어야 한다.
.2 설치물 확인 관리(Configuration Management). 설치물 확인 관리는 아래 사항에 대한 기술적 및 행정적 지시 및 감독을 적용하는데 사용되는 모든 문서화된 절차이다.
·항목(item) 혹은 시스템의 기능적 및 물리적 특성들을 확인 하고 문서하 하기 위해
·그러한 특성들에 대한 모든 변경사항들을 관리하기 위해
·변경사항 및 그것의 이행 상황을 기록 및 보고하기 위해
·요구조건(requirements)에 부합함을 증명하기 위해 항목과 시스템을 감사(鑑査)하기 위해
많은 적용영역에서 설치물 확인 관리는 하부의 변경관리 시스템이고, 프로젝트 산물(시설물)에 대한 설명이 정확하고 완전함을 보장하는데 사용된다. 그러나, 일부 적용영역에서는 `설치물 확인 관리' 라는 용어는 특정의 엄격한 변경관리 시스템을 설명하는데 사용된다.
.3 프로젝트 수행 측정(Performance measurement). 10.3.2.4에 설명된 기성(earnde-value)과 같은 프로젝트 수행의 측정기법들은 계획과의 차이가 수정조치를 필요로 하는지를 평가하는 것을 돕는다.
.4 부가계획(Additional Planning). 프로젝트가 계획대로 수행되는 경우는 거의 없다. 가망성 있는 변경사항들은 새로운 혹은 수정된 비용계획, 변경된 액티비티(작업) 순서, 리스크 대응방안의 분석, 기타 프로젝트 계획에 대한 조정 등을 요구할 수도 있다.
.5 프로젝트 관리정보 시스템(Project management information system). 프로젝트 관리정보 시스템은 4.1.2.3에 설명되어 있다.
4.3.3 Outputs from Overall Change Control
.1 프로젝트 계획의 갱신(Project plan updates). 프로젝트 계획의 갱신은 4.1.3.1 및 4.1.3.2에 각각 설명된 프로젝트 계획과 상세 지원서류들의 내용을 어떤 방식으로든 수정하는 것을 말한다. 적당한 참여자들에게는 필요시마다 통지해야 한다.
.2 수정 조치(Corrective action). 수정조치는 4.2.1.4 에 설명되어 있다.
.3 경험적 교훈(Lessons Learned). 차이(差異)의 원인, 선택된 수정조치 배면(背面)의 합리성, 기타 다른 형태의 경험적 교훈들을 문서화시켜 당해 프로젝트 및 수행조직의 또 다른 프로젝트들의 양쪽 모두를 위한 역사적인 D/B의 일부가 되도록 해야 한다.