1장 서 론 (INTRODUCTION)

PMBOK은 프로젝트 관리 전문분야의 모든 지식체계를 기술하는 포괄적인 용어로서 법률, 의학,

회계와 같은 전문분야와 마찬가지로 지식체계는 그것을 적용하고 개선시키려는 실무자, 학계에
달려있다. 완전한 PMBOK은 제한적으로 사용되는 혁신적이고 개선된 실무 지식뿐만 아니라 널리
적용되고 있는 입증된 전통적인 실무적 지식을 포함한다.

1.1. Purpose of This Document

주목적은 일반적으로 인정된 PMBOK 체계를 파악하고 기술

일반적으로 인정되었다는 것은 기술된 지식 및 실무가 대부분의 프로젝트에 적용가능 하다는

것과 그것의 가치와 유용성에 대해 폭넓은 동의를 얻고 있다는 것을 의미
일반적으로 인식되었다는 것은 기술된 지식 및 실무가 모든 프로젝트에 동일하게 적용될 수
있다는 것을 의미하지는 않는다. 프로젝트 관리팀은 주어진 프로젝트에 대해 어떤 것이 적정한지
결정할 책임이 있다.

프로젝트 관리라는 전문분야 내의 일반적인 어휘를 제공하고자 함

프로젝트 관리는 상대적으로 새로운 전문분야로써, 무엇이 행해져야 하는 가에 대한 실제적인

공통성이 있지만, 사용되는 용어에는 상대적으로 공통성이 거의 없다.

이 문서는 프로젝트 관리 분야에 관심을 가진 다음과 같은 사람에게 기본적인 참고자료를

제공하고자 한다.

·프로젝트 관리자 및 기타 프로젝트 팀원

·프로젝트 관리자의 관리자들
·프로젝트 고객 및 기타 프로젝트에 관여하는 자
·프로젝트팀에 배치되어 노무자를 관리하는 기능적 관리자
·프로젝트 관리 및 관련 주제를 가르치는 교육자
·프로젝트 관리 및 관련 분야의 컨설턴트 및 기타 전문가
·프로젝트 관리 교육 프로그램을 개발하는 trainer

기본적인 참고자료로서 이 문서는 포괄적이라거나 모든 것을 포함하고 있는 것은 아니다. 부록 E

는 적용분야를, 부록 F는 프로젝트 관리에 대한 자료들을 나타내었다.

1 of 109
 이 문서는 또한 다음과 같은 전문적인 개발 프로그램에 대해 일관성 있는 구조를 제공하기 위해
PMI에 의해서 사용되고 있다.
·PMPs의 인증
·프로젝트 관리에서 학위 수여 교육 프로그램의 인정

1.2. What is a Project

조직은 일(work)을 수행한다. 일반적으로 일(work)은 운영(operation) 또는 프로젝트(project)를

의미하며 이러한 작업과 프로젝트는 중복될 수도 있다.

작업과 사업은 다음과 같은 특징을 공유한다.

·인간에 의해 수행된다.
·제한된 자원에 의해 제한된다.
·계획, 수행, 관리된다.

운영(operation)이 계속적이고 반복적인 반면 사업(project)은 임시적이고 유일

하나의 사업(project)은 다른 것과 구별되는 특성으로 "프로젝트는 유일한 제품 또는 서비스를

창출하기 위해 수행하는 임시적인 노력"으로 정의된다.
임시적(temporary)이라는 말은 모든 프로젝트는 명확한 시작과 끝을 가지고 있다는 의미이며,
유일하다는 것은 제품 또는 서비스가 유사한 모든 제품 또는 서비스와 뚜렷하게 다르다는 것을
의미한다.

프로젝트는 한 조직의 단일 부서를 포함할 수도 있고 또는 JV 또는 파트너링으로 여러 조직을

포함할 수도 있다. 프로젝트는 조직의 사업전략을 추진하기 위한 주요 요소이다.

프로젝트의 예는 다음과 같다.

·신제품 또는 서비스 개발
·조직의 구조, 인사, 스타일의 효율적 변화
·신규 차량 개발
·새로운 또는 개선된 정보 시스템 개발
·건물 또는 시설 건설
·정치적 사무소의 캠페인 실행
·새로운 업무 절차 실행

2 of 109
1.2.1. 임시적(Temporary)

모든 프로젝트가 명확한 시작과 끝을 가지고 있다는 것을 의미

프로젝트의 목적이 달성되거나, 또는 프로젝트의 목적을 달성할 수 없어 프로젝트가 종료되었을

때 끝나게 된다.
임시적이라는 것은 반드시 기간이 짧다는 것을 의미하지 않는다. 즉 대부분의 프로젝트는 몇
년이 걸린다. 그러나, 어떤 경우이든지 프로젝트의 기간은 명확하며, 프로젝트는 지속적인 노력이
아니다.
임시적이라는 것은 일반적으로 프로젝트에 의해 창출된 제품 또는 서비스에 적용되지 않는다.
대부분의 프로젝트는 지속적인 결과를 창출하기 위해 수행된다.
대부분의 작업(undertakings)은 언젠가는 끝나게 될 것이라는 면에서 임시적이다
예를 들어 자동차 플랜트의 조립 작업은 결국에는 중지될 것이고 플랜트 그 자체는 해체될
것이다. 프로젝트는 그 목적이 달성되었을 때 중지되는 반면, 非-프로젝트 작업(undertakings)은
새로운 목표를 세워 작업을 계속한다는 측면에서 근본적으로 다르다)

프로젝트의 임시적인 성격은 다음과 같은 다른 측면의 노력에도 적용된다.

·기회 또는 시장은 보통 임시적이다 - 대부분의 프로젝트는 제품 또는 서비스를 생산하는 시간이

제한된다.
·하나의 팀으로서 프로젝트 팀은 좀처럼 프로젝트를 넘어 지속되지 않는다 - 대부분의
프로젝트는 프로젝트를 수행하는 유일한 목적을 위해 만들어진 팀에 의해 수행되며, 프로젝트
팀은 해산되며 팀원은 프로젝트가 완성되었을 때 재배치된다.

1.2.2. 유일한 제품 또는 서비스

프로젝트는 과거에 하지 않았던 무엇인가를 행한다 - 유일하다(unique).

제품 또는 서비스는 그것이 속한 범주(category)가 거대하다 하더라도 유일하다.

어떠한 반복적인 요소들의 존재가 전체적 노력의 근본적인 유일성을 변화시키지는 않는다. 예를
들어,

·신규 상업 정기 여객기를 개발하기 위한 프로젝트는 다양한 원형(prototype)을 필요로 할 수도

있다.
·신규 약품을 시장에 내놓기 위한 프로젝트는 임상시험을 입증하기 위해 약품의 수천 개의
복용량을 필요로 할지 모른다.
·부동상 개발 프로젝트는 수천 개의 단위를 필요로 할 수도 있다.

3 of 109
 각 프로젝트의 결과가 유일하기 때문에 제품 또는 서비스를 구별하는 특성들이 점진적으로 상세
(정교)해진다.

점진적이란(progressively) 것은 "단계를 거치는 즉, 지속적이고 안정적으로 증대한다"는 것을

의미하는 반면, 상세(정교, elaborated)해진다는 것은 "조심하여 상세하게 작업하는 즉, 철저하게
발전시킨다(develop)는 것"을 의미한다.
이러한 특성은 프로젝트의 초기에는 폭 넓게 정의될 것이며, 프로젝트 팀이 결과를 이해하게
되면서 명확하고 상세해진다.

프로젝트 결과의 특성이 점진적으로 상세해진다는 것은 신중하게 프로젝트 범위 정의와

조정되어야 하며, 계약으로 프로젝트를 수행하는 경우에는 특히 그러하다.
프로젝트 범위가 적정하게 정의되었을 때, 비록 제품 특성이 점진적으로 상세해진다 할지라도
프로젝트 범위 - 수행해야 하는 작업 -는 일정해야 한다. (제5장)

다음 두 가지 예는 두 개의 다른 분야에서 점진적인 상세화를 설명한다.

사례 1: 화학 처리 공장은 프로세스의 특성을 정의하기 위해 프로세스 엔지니어링으로 시작한다.

이런 특성은 주요 프로세스 단위를 설계하는 데 이용된다. 이런 정보는 상세 플랜트 배치와
프로세스 단위 및 보조적인 시설물의 기계적 특성을 정의하는 엔지니어링 설계의 기초가 된다.
이런 모든 것은 결국 조립 도면(시공 아이소메트릭)을 만들기 위해 상세 설계도면이 된다. 시공
중 해석 및 채택은 필요에 따라 이루어지고 적정한 승인을 받게 된다. 이러한 특성이 더욱
상세화되어 "준공도면(as built drawing)"이 된다. 시험 및 인수하는 동안 최종 작동 조정의
형태로 이들 특성의 상세화가 더욱 이루어지게 된다.

사례 2: 생물약제학 연구 프로젝트 결과는 임상시험의 수와 각각의 크기가 알려져 있기 않기

때문에 처음에는 "XYZ의 임상시험"으로 정의될 수 있다. 프로젝트가 진행됨에 따라 결과는 "
세번의 1단계 시험, 네 번의 2단계 시험, 두 번의 3단계 시험"으로 더욱 명확히 정의될 수 있다.
점진적 상세화의 다음 단계는 1단계의 시험을 위한 프로토콜 - 얼마나 많은 환자가 얼마만큼의
복용량과 횟수를 가져야 하는가 - 에 중점을 둘 수도 있다. 프로젝트의 최종 단계에서 3단계
시험은 1단계 및 2단계 시험동안에 수집되고 분석된 정보에 기초하여 명확히 정의될 수 있다.

1.3. What is Project Management?

프로젝트 관리는 프로젝트의 관련자(stakeholder)의 필요와 기대를 충족하거나 또는 초월하기

위해 프로젝트 활동에 지식, 기술, 도구, 기법을 응용하는 것이다.

4 of 109
 프로젝트 관련자의 필요와 기대를 충족 또는 초월한다는 것은 다음과 같은 여러 가지 요건의
균형을 추구하는 것을 포함한다.

·범위, 시간, 비용, 품질

·다른 필요, 기대를 가진 프로젝트 관련자(stakeholder)
·파악된 요구(필요)와 파악되지 않은 요구(기대)

프로젝트 관리(project management)란 용어는 때때로 계속적인 운영(operation) 관리에 대한

조직적인 (접근)방법을 기술하는데 이용된다. 더 정확히 말해서 프로젝트별 관리(management by
projects)로 불리는 이런 방법은 프로젝트 관리를 운영에 적용하기 위해 프로젝트로서 계속적인
운영의 여러 측면을 다룬다. 프로젝트 관리를 이해하는 것이 프로젝트별 관리를 하는 조직에
명백하게 중요하다 할지라도 이런 방법 자체의 상세한 논의는 이 문서의 범위를 넘어선다.

1.3.1. The Project Management Framework

1절, 프로젝트 관리 체계에서는 프로젝트 관리를 이해하는 기본적인 구조

1장, 도입(introduction)에서는 주요 용어를 정의하고 문서의 개략적 소개

2장, 프로젝트 관리 배경(The Project Management Context)에서는 프로젝트가 운영되는 환경에
대한 기술
3장, 프로젝트 관리 절차에서는 다양한 프로젝트 관리 절차가 어떻게 상호작용 하는가에 대한
일반화된 견해 기술.

1.3.2. The Project Management Knowledge Area

2절, 프로젝트 관리 지식 영역에서는 각 요소의 프로세스의 측면에서 프로젝트 관리 지식과

실무를 다룬다. 이러한 절차는 아래에 기술된 9개의 지식 영역으로 구성되며, 그림 1-1과 같다.

4장, 프로젝트 통합관리는 프로젝트의 다양한 요소들이 적정하기 위한 필요한 절차를 다룬다.

5장, 프로젝트 범위 관리는 프로젝트에는 필요한 모든 작업, 필요한 바로 그 작업을 포함하기

위해 그리고, 성공적으로 프로젝트를 마치기 위해 필요한 절차를 다룬다.

6장, 프로젝트 시간관리는 시간내에 프로젝트의 완성을 하기 위해 필요한 절차를 다룬다.

7장, 프로젝트 비용관리는 프로젝트가 승인된 예산내에서 완성한다는 것을 확실히 하기 위한

5 of 109
절차를 다룬다.

8장, 프로젝트 품질관리는 수행되는 프로젝트의 요구를 만족시키기 위해 필요한 절차를 다룬다.

9장, 프로젝트 인적자원 관리는 프로젝트에 참여한 사람들의 가장 효과적인 이용에 필요한
절차를 다룬다.

10장, 프로젝트 커뮤니케이션 관리는 시기적절하고 적정한 의사소통(발생)에 필요한 절차를

다룬다.

11장, 프로젝트 리스크 관리는 프로젝트 리스크를 파악, 분석 그리고 대응하는 것과 관련된
절차를 다룬다.

12장, 프로젝트 구매 관리는 수행조직 외부에서의 상품과 서비스를 확보하기 위해 필요한 절차를
다룬다.

1.4. Relationship to Other Management Disciplines

프로젝트를 관리하기 위해 필요한 대부분의 지식은 독특하거나 또는 거의 프로젝트마다 유일하다

(예: 크리티컬 패스 분석과 작업분류 체계). 그러나 PMBOK은 그림 1-2와 같이 다른 관리 분야와
중복된다.

일반적인 관리는 계속적인 기업의 운영(operation) 계획, (조직)구성, 인원구성(staffing),

수행, 그리고 관리를 포함하며, 또한 컴퓨터 프로그래밍, 법률, 통계, 확률론, 병참술, 인사 등과
같은 지원 분야를 포함한다. PMBOK은 몇 가지 예를 든다면 조직 행동, 재무예측, 계획 기법과
같은 여러 분야에서 일반적인 관리와 중복된다. 2.4절에서 일반관리에 대해 더 상세히 다루고
있다.

응용 분야는 모든 프로젝트에 존재하지 않거나 또는 필요치 않지만, 프로젝트에서 상당히

공통적인 요소를 가지는 프로젝트 범주이다. 응용분야는 다음과 같이 정의된다.

·소프트웨어 개발, 제약, 또는 건설 엔지니어링과 같은 기술적인 요소

·정부계약, 신규 제품 개발과 같은 관리 요소
·자동차, 화학, 또는 재정 서비스와 같은 산업 집단
부록 E에서 프로젝트 관리 응용분야에 대해 더욱 상세히 다루고 있다.

1.5. Related Endeavors

6 of 109
특정 유형의 노력은 프로젝트와 밀접하게 관련되어 있다. 이러한 관련된 일(undertaking)은
다음과 같다.

1) Program
프로그램은 개별적으로 관리해서는 얻을 수 없는 이익을 확보하기 위해 조정된 방법으로
관리되는 프로젝트의 집합이다. 대부분의 프로그램은 또한 지속적인 작업(operation) 요소를
포함하고 있다. 예를 들면

·"XYZ" 항공기 프로그램은 항공기 분야의 지속적인 제조와 지원뿐만 아니라 항공기를 설계하고
개발하기 위한 프로젝트 또는 프로젝트들을 포함한다.
·대부분의 전자 회사는 "프로그램 관리자"가 두고 있으며 이들은 각각의 제품발매(프로젝트)
뿐만 아니라 시간이 지나 다중적인 제품발매(지속적인 작업)의 조정에 대한 책임이 있다.

프로그램은 또한 반복적 또는 순환적인 작업을 포함할 수도 있다.

일부 응용분야에서 프로그램 관리 및 프로젝트 관리는 동의어로 취급된다. 그리고 어떤 경우에는

프로젝트 관리는 프로그램 관리의 집합(subset)으로 취급된다. 때에 따라 프로그램 관리는
프로젝트 관리의 집합으로 간주되기도 한다. 이와 같은 다양한 의미는 프로그램 관리 對 프로젝트
관리에 대한 어떠한 논의도 각 용어의 명확하고 일관된 정의에 대한 동의가 선행되어야 할 필요가
있다는 것을 의미한다.

2) 하위 프로젝트(sub-project)

프로젝트는 종종 관리하기 쉬운 요소 또는 하위 프로젝트로 분리된다. 하위 프로젝트는 외부

기업에게 완전히 계약되거나 또는 수행 조직내의 다른 기능 조직단위에 의해 수행된다.
그러나 수행조직의 입장에서 살펴볼 때 하위 프로젝트는 종종 제품이라기보다는 서비스로
간주되며 그러한 서비스는 유일하다. 따라서 하위 프로젝트는 전형적으로 프로젝트로 간주되고
또한 그렇게 관리된다.

2장 프로젝트 관리의 문맥 (PROJECT MANAGEMENT CONTEXT)

프로젝트 및 프로젝트 관리는 프로젝트 그 자체보다는 환경적인 경계에서 운영된다. 프로젝트

관리팀은 이러한 경계의 의미를 이해해야 한다 - 프로젝트의 하루하루의 액티비티를 관리하는
것은 성공에 필요하지만 충분하지는 않다. 이 장에서는 이 문서의 다른 곳에서 포함되지 않은
프로젝트 관리의 주요 측면을 다룬다.

7 of 109
2.1 Project Phase and The Project Life Cycle

프로젝트는 유일한 작업(undertaking)이기 때문에 불확실성 내포.

프로젝트를 수행하는 조직은 보통 각 프로젝트를 여러 프로젝트 단계로 나누어 더 나은 관리

조정 및 수행조직의 지속적인 작업(operation)과 적정한 연계를 꾀한다. 프로젝트 단계는
프로젝트 라이프사이클로 알려져 있다.

2.1.1 Characteristic of Project Phase

프로젝트 각 단계는 한 두 개 이상의 성과물(deliverables)의 완성이라는 특성

성과물(deliverable)은 타당성 조사, 상세설계, 또는 작업 원형(prototype)과 같이 유형적이고,

입증 가능한 작업 결과이다. 성과물 즉 단계는 프로젝트 결과의 적정한 정의를 확보하기 위해
고안된 순차적인 논리의 일부이다.

일반적으로 프로젝트 한 단계의 결말은 (a)프로젝트가 다음 단계로 계속되는가를 결정하고 (b)

비용 효율적으로 오류를 탐지하고 교정하기 위해서 주요한 성과물과 프로젝트 성능을 검토한다는
특징이 있다. 이러한 단계-결말(phase-end) 검토는 종종 단계 출구(phase exits), 단계 관문
(stage gates), 또는 죽음의 지점(kill points)으로 불리기도 한다.
프로젝트 각 단계는 보통 바람직한 수준의 관리(management control)를 설정하기 위해 고안된
일련의 정의된 작업 결과를 포함한다. 이러한 항목의 대부분은 주요 조달 단계와 관련되어
있으며, 전형적으로 이러한 항목에서 그들의 이름을 짓는다. 즉 요건, 설계, 시공, text, 시운전,
인계, 기타. 대표적인 몇 개의 프로젝트 라이프사이클이 2.1.3에 기술하였다.

2.1.2 Characteristic of the Project Life Cycle

프로젝트 라이프사이클은 프로젝트의 시작과 끝을 정의하기 위해 이용된다.

예를 들어, 한 조직이 대응하고자 하는 기회를 파악할 때 종종 프로젝트를 수행해야 하는가를

결정하기 위해 타당성 조사를 할 것이다. 프로젝트 라이프사이클 정의는 타당성조사가 프로젝트의
첫 번째 단계 또는 개별적인 하나의 프로젝트로 취급할 것인가를 결정할 것이다.
대부분의 프로젝트 라이프사이클에 의해 정의된 단계별 순서는 일반적으로 요구조건을 설계로,
건설을 작업으로, 설계를 제조로 만드는 것과 같은 기술이전의 형태 또는 이전(hand-off)을
포함한다. 이전 단계로부터의 조달은 보통 다음 단계의 작업을 시작하기 전에 승인을 받는다.
그러나 때로는 하위순서 단계는 내포된 리스크가 승인될 수 있을 때는 이전 단계의 성과물 승인

8 of 109
이전에 시작된다. 이러한 단계의 중복 실무를 fast tracking이라 부른다.

프로젝트 라이프사이클은 일반적으로 다음과 같은 것을 정의한다.

·어떤 기술적 작업이 각 단계에서 수행되어야 하는가?

·각 단계에서 포함되어야 하는 사람은 누구인가?

대부분의 프로젝트 라이프사이클 기술(description)은 수많은 공통적인 특성을 공유한다.

·비용과 인원 수준은 처음에는 매우 낮지만, 진행됨에 따라 높아지며, 프로젝트가 종결됨에

따라 급격히 떨어진다. 이러한 양상은 그림 2-1에 나타나 있다.
·프로젝트를 성공적으로 완성할 확률은 매우 낮으며, 따라서 프로젝트 시작 시에 리스크와
불확실성이 매우 높다. 성공적인 완성의 확률은 일반적으로 프로젝트가 계속됨에 따라 점점
높아진다.
·프로젝트 결과의 최종 특성과 프로젝트의 최종 비용에 영향을 주는 프로젝트 관련자
(stakeholder)1의 능력은 시작 시에는 매우 높으며 프로젝트가 계속됨에 따라 점차적으로
낮아진다.

프로젝트 라이프사이클과 제품의 라이프사이클을 구별에 주의가 필요하다. 예를 들어 새로운

데스크 탑 컴퓨터를 시장에 내놓기 위해 수행된 프로젝트는 제품 라이프사이클의 한 단계이다.

2.1.3 Representative Project Life Cycles

다음 프로젝트 라이프사이클은 사용되는 방법의 다양함을 설명하기 위해 선정되었다. 단계의

명칭과 주요 조달은 저자에 의해 기술된 것이다.

1) Defense acquisition(방어시설 확보)

1993년 2월에 개정된 미국 국방성 훈령 5000.2은 그림 2-2에 설명한 것처럼 방어시설 확보의
마일스톤과 단계를 규정하고 있다.
·임무 필요의 결정 - 개념조사의 승인으로 종료
·개념 탐색과 정의 - 개념 논증 승인으로 종료
·논증과 확인 - 개발승인으로 종료
·엔지니어링과 제조 개발 - 생산 승인으로 종료
·생산 및 배치 - 지속적인 운영 및 지원과 중복

9 of 109
2) Construction(건설)

모리스는 건설프로젝트 라이프사이클을 그림2-3과 같이 설명한다.

·타당성 - 프로젝트 공식화, 타당성 조사, 그리고 전략적 설계 및 승인. 이 단계에서 수행할
것인가 아닌가의 결정을 하게 된다.
· 계획 및 설계 - 기본설계, 비용과 일정, 계약내용과 조건, 상세 계획. 이 단계에서 주요
계약이 이루어진다.
·생산 - 제조, 조달, 토목공사, 설치, 그리고 시험. 이 단계에서 시설은 실질적으로 완성된다.
·인계와 시험가동 - 최종 시험과 유지. 이 단계에서 시설이 완전히 운영된다.

3) Pharmaceutical(제약)

머피는 미국에서 신규 약품 개발 프로젝트 라이프사이클을 그림 2-4와 같이 설명한다.

·발견 및 선별
·임상전 개발
·등록된 사람(들)의 정밀검사
·제출 후 활동

4) Software development(소프트웨어 개발)

Muench는 그림 2-5와 같이 소프트웨어 개발을 4개의 주기와 4분면을 가진 나선형 모델로 설명하고
있다.

·개념 증명 주기
·첫 번째 구축 주기
·두 번째 구축 주기
·최종 주기

2.2 Project Stakeholders

프로젝트 관련자는 프로젝트에 적극적으로 참여되는 개인과 조직으로 그들의 관심은 프로젝트
수행 또는 성공적인 프로젝트 완성에 긍정적 또는 부정적인 영향을 미치게 된다.
프로젝트 관리팀은 프로젝트 관련자를 파악해야 하며, 그들의 요구와 기대가 무엇인지를
결정해야 하고, 프로젝트를 성공으로 이끌기 위해 그들의 기대를 관리하고 영향을 주어야 한다.

모든 프로젝트의 주요 프로젝트 관련자는 다음을 포함한다.

10 of 109
 ·프로젝트 관리자 - 프로젝트 관리에 책임있는 자
·고객 - 프로제트 결과를 이용하게 될 개인 또는 조직
·수행 조직 - 프로젝트의 작업을 수행하는데 직접적으로 그 직원이 참여한 기업체
·스폰서 - 프로젝트에 현금 또는 물품으로 재정적 자원을 지원하는 수행조직내의 개인 또는
집단
이외에도 프로젝트 관련자의 명칭과 범주는 아주 다양하다. 즉 외부와 내부, 발주자와 자금주,
공급자와 계약자, 팀원과 그의 가족, 정부 부서와 지방방송국, 시민, 임시 또는 영구 로비 조직,
사회 등. 프로젝트 관련자의 명칭 또는 분류는 주로 어떤 조직 또는 집단이 자신들을 프로젝트
관련자로 바라보는가를 파악하는 데 도움이 된다. 프로젝트 관련자의 역할과 책임은 엔지니어링
회사가 설계하고 있는 플랜트의 금융을 제공할 때처럼 중복될 수도 있다.
프로젝트 관련자들은 결국에는 갈등이 될 수 있는 매우 상이한 목적을 가지고 있기 때문에
이들의 기대를 관리하는 것이 어렵다.

일반적으로 프로젝트 관련자간의 차이는 고객을 우선함으로써 해결되어야 한다. 그러나 다른

프로젝트 관련자의 요구와 기대가 무시되어야 한다는 것을 의미하지는 않는다. 이러한 차이를
해결하기 위한 적절한 방법을 찾는 것은 프로젝트 관리의 주요 도전적 업무의 하나가 된다.

2.3 Organizational Influences

프로젝트는 전형적으로 프로젝트보다 더 큰 조직의 일부이다. 즉 기업, 정부 부서, 보건 기구,

국제기구, 전문 단체 등 프로젝트가 비록 조직(JV, 파트너링)이라 할지라도 프로젝트는 그것이
만들어진 조직 또는 조직들의 영향을 받을 것이다. 다음절에서는 프로젝트에 영향을 미치게 되는
이들 조직 구조의 주요 측면을 기술할 것이다.

2.3.1 Organizational Systems

프로젝트-기반의 조직들은 운영(operation)이 주로 프로젝트로 구성된다.

이들 조직은 다음의 두 범주로 구분된다.

·다른 이를 위한 프로젝트를 수행하여 주 수입을 갖는 조직 - 건축회사, 엔지니어링 회사,

컨설턴트, 시공자, 정부 계약자 등
·프로젝트별 관리를 채택한 조직(1.3절)

非 프로젝트 기반의 조직들(제조 회사, 재정서비스 회사 등)은 프로젝트 요구를 충분히

효율적으로 지원하도록 고안된 관리 체계를 가지고 있지 않다. 프로젝트 위주의 체계 부재는 보통
프로젝트 관리를 더욱 어렵게 만든다. 어떤 경우에는 非 프로젝트 기반의 조직들이 프로젝트
기반의 조직을 운영하는 부서 또는 하위 부서(단위)를 가질 것이다.

11 of 109
 프로젝트 관리팀은 어떻게 조직 체계가 프로젝트에 영향을 주는 가를 명확히 알아야 한다.

2.3.2 Organizational Culture and Style

대부분의 조직들은 독특하고 기술할 수 있는 문화를 개발해 왔다. 이러한 문화는 그들의 공유된
가치, 표준, 신념, 그리고 기대, 그리고 그들의 정책과 절차 등에 반영되어 있다. 조직 문화는
종종 프로젝트에 직접적인 영향력을 가지고 있다.

2.3.3 Organizational Structure

수행 조직의 구조는 종종 자원의 유용성을 제한하거나 또는 프로젝트에 이용 가능한 자원을 가진

팀을 제한한다. 조직 구조는 기능적인 조직에서 프로젝트(projected) 조직으로 된 스펙트럼(이
양자 사이에 다양한 매트릭스 구조를 가진다)으로 연결되어 있다는 특성이 있다. 그림 2-6에서
주요 기업구조 유형의 프로젝트와 관련된 특성을 상세히 보여주고 있다. 프로젝트 조직은 9.1
조직 계획에서 논의된다.

그림 2-7과 같은 전통적인 기능적 조직은 각자가 한 명의 명확한 상사를 가지는 계층구조이다.

상위수준에서 생산, 마케팅, 엔지니어링 회계와 같이 전문적으로 분류된 스태프는 기계, 전기로
세분화된다. 기능 조직은 여전히 프로젝트를 가지고 있지만, 프로젝트의 범위는 기능의 경계로
제한된다. 즉 기능적 조직의 엔진니어링 부서는 제조 또는 마케팅 부서와 독립하여 작업을 수행할
것이다.

스펙트럼의 반대편에는 그림 2-8과 같은 프로젝트 조직이 있다. 이 조직에서는 종종 팀원들이

배치된다. 대부분의 조직 자원이 프로젝트 작업에 참여하게 되고 프로젝트 관리자는 상당한
독립성과 권한을 지닌다. 프로젝트 조직은 부서로 불리는 조직 단위를 가지지만, 이들 집단은
프로젝트관리자에게 직접 보고하거나 또는 여러 프로젝트에 지원서비스를 제공한다.

그림 2-9에서 2-11과 같은 매트릭스 조직은 기능 조직과 프로젝트 조직의 혼합된 형태이다. 약한

매트릭스는 기능적 조직의 대부분의 특성을 가지고 있으며 프로젝트 관리자의 역할은
관리자보다는 조정자 또는 촉진자(expeditor)의 역할을 한다. 이와 유사하게 강한 매트릭스는
프로젝트 조직의 많은 특성(상당한 권한을 가진 전임 프로젝트 관리자와 전임 프로젝트 행정직원)
을 지닌다.

대부분의 현대 조직은 그림 2-12에 나타낸 것처럼 다양한 수준에서 이런 모든 구조를 포함하고

있다. 예를 들어, 근본적으로 기능 조직이라도 중요한 프로젝트를 다루기 위해 특정 프로젝트팀을
구성할 수도 있다. 그런 팀은 프로젝트 조직내의 대부분의 프로젝트 특성을 가질 것이다. 즉

12 of 109
다양한 기능부서의 전임 직원을 포함할 것이고, 그 자체의 운영절차를 개발할 것이며, 표준화되고
공식화된 보고체계를 운영할 것이다.

2.4 Key General Management Skills

일반적인 관리는 지속적인 기업을 관리하는 모든 측면을 다루는 폭 넓은 주제이다. 기타 주제로는

다음과 같은 것이 포함된다.

·재정과 회계, 판매와 마케팅, 연구 및 개발, 제조와 유통

·전략적 계획, 전술적인 계호기, 운영 계획
·조직 구조, 조직 행동, 인사관리, 보상, 혜택, 경력(career path)
·동기부여, 위임, 감독, 팀 구성, 갈등 관리, 기타 기법을 이용한 작업관계 관리
·개인적 시간관리, 스트레스 관리, 기타 기법을 이용한 자신의 관리

일반적인 관리 기술은 프로젝트 관리 기술을 쌓는 토대를 제공한다. 때로 이러한 것들은 프로제트

관리자에게 필수적이다. 어떤 프로젝트에서 일반적인 관리분야의 수많은 기술이 필요할 수도
있다. 이번 절에서는 대부분의 프로젝트에 상당한 영향을 미칠 수 있는 일반 관리의 주요 기술을
설명한다. 이러 기술은 일반 관리 문헌에 잘 나와 있으며 이들을 프로젝트에 적용하는 것은
기본적으로 동일하다.
또한 특정 프로젝트에만 관련되거나 또는 특정 응용 분야에 관련된 많은 일반 관리 기술이 있다.
예를 들어 팀원의 안전은 사실상 모든 건설프로젝트에서 중요하지만, 대부분의 소프트웨어 개발
프로젝트에서는 거의 고려되지 않는다.

2.4.1 Leading

Kotter는 지도(지휘)와 관리 양자의 필요성을 강조하면서 이 양자를 구별하고 있다. 즉 하나가

없으면 불행한 결과를 초래할 것이다. 그는 관리는 주로 "프로젝트 관련자에 의해 기대된 주요
결과를 일관되게 만드는 것"을 다루는 반면, 지도(지휘)는 다음을 포함한다고 주장한다.

·방향 설정 - 미래의 비젼과 그런 비젼을 달성하기 위해 필요한 변화에 대한 전략, 이 양자를

개발
·타인과 공조 - 비젼을 달성하기 위해 회사에서 필요한 모든 것을 말과 행동으로 전달
·동기부여와 (사상)고취(inspiring) - 변화에 대한 정치적, 관료적, 자원 장애를 극복하도록
사람들 스스로를 격려하도록 돕는다.

프로젝트, 특히 대규모 프로젝트에서 프로젝트 관리자는 일반적으로 또한 프로젝트 리더의 역할을

한다. 그러나 리더십은 프로젝트 관리자에게만 제한되는 것은 아니다. 즉 이것은 프로젝트 중의

13 of 109
다양한 시간에 다양한 사람에 의해 발휘되어야 한다. 리더십은 프로제트의 모든 수준(프로젝트
리더십, 기술적 리더십, 팀 리더십)에서 발휘되어야 한다.

2.4.2 Communicating

의사소통은 정보의 교환을 포함한다. 전달자는 수신자가 정확히 받을 수 있도록 정보를 명확히,
모호하지 않게, 완전하게 할 책임이 있다. 수신자는 정보가 완전하게 전달되었고 정확히
이해했다는 것을 확실히 할 책임이 있다. 의사소통은 많은 차원을 가진다. 즉 다음과 같다.

·문서와 구두, 듣기와 말하기

·내부적인 것(프로젝트 내부)과 외부적인 것(고객, 미디어, 대중에 대한 것 등)
·공식적인 것(보고서, 브리핑 등)과 비공식적인 것(메모, 임시적인 대화 등)

일반적인 의사소통 관리 기술은 프로젝트 의사소통 관리(10장에서 다룬다)와 관련되어 있지만

동일한 것은 아니다. 의사소통은 폭 넓은 주제로서 프로젝트 의미에서 유일하지 않은(공통적인)
실제적인 지식체계를 포함하고 있다. 예를 들어

·전달자-수신자 모델 - 피드백 루프, 의사소통 장애 등

·미디어 선택 - 문서로, 구도로, 비공식적인 메모, 공식적인 보고서로 의사소통을 할 때 등
·작성 유형
·표현 기법
·모임 관리 기법

프로젝트 의사소통 관리는 프로젝트의 특정한 필요에 따라 이런 폭 넓은 개념을 적용하는 것이다.

어떻게, 언제, 어떤 형태로, 누구에게 프로젝트 성능을 보고할 것인가를 결정하는 것이 그 예가
된다.

2.4.3 Negotiating

협상은 협약 또는 계약에 이르기 위해 타인과 협의하는 것을 의미한다. 계약은 직접 또는 도움을

받아 협상될 수 있다. 즉 조정(mediation)과 중재(arbitration)는 도움을 받는 협상의 두 가지
형태이다.
협상은 프로젝트의 다양한 문제, 다양한 시기에, 다양한 수준에서 발생한다. 전형적인 프로젝트의
과정 중에 프로젝트 스태프는 다음의 어떤 것 또는 모든 것에 대해 협상할 것이다.

·범위, 비용, 그리고 일정 목적

·범위, 비용, 일정의 변경

14 of 109
·계약 내용과 조건
·할당(assignment)
·자원

2.4.4 Problem Solving

문제해결은 문제 정의와 의사결정의 조합이다. 이것은 이미 발생한 문제(잠재적 문제를 기술하는

리스크 관리와 반대된다)와 관계된다.

문제정의는 원인과 징후의 구별을 필요로 한다. 문제는 내부적일 수도(주요 직원인 다른
프로젝트에 재배치된다) 또는 외부적일 수도(작업 시작에 필요한 승인이 지연된다) 있다. 문제는
기술적(제품을 설계하는 최고의 방법에 대한 의견 차이), 관리적(기능 집단이 계획에 따라
생산하지 않음), 또는 대인관계(개성 또는 스타일 충동)일 수 있다.

의사결정은 존속 가능한 해결책을 파악하기 위해 문제를 분석하고 그런 후 그들 중 하나를

선택하는 것을 의미한다. 결정을 하거나 또는 얻는다(관습, 팀, 또는 기능적 관리자로부터). 일단
결정이 이루어지면, 그 결정은 실행되어야 한다. 또한 결정은 시간적 요소를 가지고 있다. 즉
올바른 의사결정도 너무 늦거나 빠르다면 최선의 결정이 될 수 없다.

2.4.5 Influencing the Organization

조직에 영향을 주는 것은 "일을 잘하는" 능력을 포함한다. 이는 참여한 모든 조직의 공식적

비공식적 구조 모두를 이해할 것을 필요로 한다. 또한 힘과 정책(power and politics) 역학의
이해를 필요로 한다.

여기서 말하는 권력과 정치, 이 양자는 긍정적인 의미로 사용되었다. Pfeffer는 힘(power)은 "
행동에 영향을 주는, 사상(event)의 과정을 변화시키는, 저항을 극복하는, 그리고 그렇지 않다면
할 수 없는 일을 할 수 있도록 하는 잠재적인 능력"으로 정의한다. 이와 마찬가지로 Eccles는 "
정책은 서로 아주 상이한 관심을 가진 사람들의 집단으로부터 집단적인 행동을 하는 것이다.
이것을 기꺼이 갈등과 불일치를 창조적으로 이용하려는 것이다. 물론 부정적인 의미는 이런
관심을 조정하기 위한 시도는 결과적으로 권력 투쟁을 가져온다는 사실과 때때로 철저하게 조직
자체의 비생산적인 수명을 가질 수 있는 조직 게임으로부터 파생된다."고 말한다.

2.5 Socioeconomic Influences

일반적 관리와 마찬가지로 사회경제적 영향은 넓은 범위의 주제와 문제를 포함한다. 프로젝트
관리팀은 이 분야의 현재 조건과 경향이 프로젝트에 대한 주요 영향을 이해해야 한다. 즉 여기서

15 of 109
조그만 변화가 보통은 시간적 간격을 가지고 프로젝트 자체의 격변으로 바뀌어 질 수 있다. 많은
잠재적인 사회경제적 영향 중 프로젝트에 자주 영향을 미치는 몇 개의 주요 범주가 이하에 간략히
소개된다.

2.5.1 Standard and Regulations

국제 표준화 기구(ISO)는 표준과 규정을 다음과 같이 구별한다.

·표준은 "이를 따르는 것이 의무적이 아닌 제품, 절차, 서비스에 대한 공통적이고 반복적인

이용, 규칙, 지침을 제공하는 인정된 기구에 의해 승인된 문서"이다. 유체의 열적 안정에서
컴퓨터 디스켓에 이르기까지 모든 것을 포괄하여 이용되는 수많은 표준이 있다.
·규정은 "이를 지키는 것이 의무적인 것으로 적용 가능한 행정 규정을 포함하여 제품, 절차,
서비스의 기초가 되는 문서이다." 빌딩법규는 규정의 한 예가 된다.

이 두 개념간에는 다소 모호한 영역이 있기 때문에 표준과 규정을 논의할 때에는 주의해야 한다.

·표준은 더 나은 방법을 기술하는 지침으로 출발하여 나중에는 널리 채택되어 사실상의 규정이

된다. (예, 건설프로젝트의 일정계획에 CPM의 이용)
·다양한 수준에서 이를 따르는 것이 강제될 수 있다. (예, 정부부서, 수행조직의 관리부서,
또는 프로젝트 관리팀에 의해)

대부분의 프로젝트에서 표준과 규정은(어떻게 정의하든) 잘 알려져 있으며, 프로젝트 계획은

그들의 효력을 반영한다. 또 다른 경우에는 그 영향이 불확실하거나 알려져 있지 않고, 프로젝트
리스크 관리에서 고려되어야 한다.

2.5.2 Internationalization

국가적 경계를 넘어서는 작업에 더 많은 조직이 참여하게 될수록 더 많은 프로젝트가 국가적

경계를 넘어선다. 범위, 비용, 시간, 그리고 품질과 같은 전통적인 관심사 이외에도 국가적
그리고 지역적 휴일, 직접 모임을 위한 여행 조건, 원격회의 장치, 종종 불안정한 정치적 차이에
대한 노력을 고려해야 한다.

2.5.3 Cultural Influences

문화는 "사회적으로 전달되어 온 행동 양식, 예술, 신념, 제도, 인간의 모든 작업과 사고의
결과의 총체"이다. 모든 프로젝트는 한 두 개 이상의 문화적 표준의 의미 내에서 운영되어야
한다. 이러한 영역의 영향에는 사람과 조직의 상호작용 방법에 영향을 주는 정치적, 경제적,

16 of 109
인구학적, 교육적, 윤리적, 민족적, 종교적 그리고 기타 관행, 신념, 그리고 태도를 포함한다.

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

17 of 109
프로젝트 관리 프로세스는 각각 하나 또는 그 이상의 프로세스를 가진 다섯 개의 그룹으로 구성될
수 있다.

·착수 프로세스(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

각 프로세스 그룹 안에서, 개개의 프로세스들은 인풋과 아웃풋에 의해 연결된다. 이러한 연결

18 of 109
(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) - 주요 프로젝트 성과물을 소형의 보다 관리하기 쉬운 요소로 분할

19 of 109
·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)를 규정

20 of 109
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) - 프로젝트 과정상에서 리스크의 변경에 대응

21 of 109
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)를
충족시키기 위해서 경쟁 목표들과 대안들 간의 상관분석을 수반한다. 모든 프로젝트 관리

22 of 109
프로세스가 어느정도 통합적인 것인 반면에 4장에서 설명하는 프로세스는 근본적으로 통합적이다.
그림 4-1은 다음의 주요 프로세스들의 개요(overview)를 제공한다.

4.1 프로젝트 계획 개발 - 다른 계획 프로세스들의 결과를 수집하고, 이것들을

일관성있는 문서에 담는다.
4.2 프로젝트 계획 집행 - 포함된 액티비티들을 수행함으로써 프로젝트 계획을 실행
4.3 전체적인 변경 관리 - 프로젝트 전체에 걸쳐 변경(changes)을 조정

이들 프로세스들은 서로간 상호작용을 하고 마찬가지로 다른 지식분야의 프로세스들과

상호작용한다. 각 프로세스들은 프로젝트의 요구(needs)에 기초한 하나 또는 그 이상의 개인 또는
개인으로 이루어진 그룹으로부터 노력을 수반할 수 있다. 각 프로세스들은 일반적으로 모든
프로젝트 단계에서 최소한 한번은 발생한다.
비록 여기서 프로세스들이 잘 정의된 인터페이스를 지닌 별도의 요소로서 나타나고는 있지만,
실제상 여기서 상세하게 다루지 않는 방법으로 중첩되고 상호작용한다. 프로세스 상호작용은 3
장에서 상세하게 토론되었다.
프로젝트 관리 프로세스를 통합하기 위해 사용되는 프로세스, 도구, 기법들이 4장의
중점사항이다. 예를 들면, 프로젝트 통합관리는 비용견적이 예비비 계획을 위해 필요한 때나
다양한 조직 대안들과 관련된 리스크가 규정되어야 할 때 역할을 한다. 그러나 성공적으로
수행되어야 하는 프로젝트에 있어서, 통합은 많은 다른 분야에서 마찬가지로 발생해야 한다.

·프로젝트의 작업은 수행조직의 지속적인 운영과 통합되어야 한다.

·생산범위와 프로젝트 범위는 통합되어야 한다(생산범위와 프로젝트범위의 차이는 5장에서
설명된다).
·다른 기능을 가진 공종으로부터의 성과물(deliverables-토목, 전기, 엔지니어링 설계
프로젝트를 위한 기계 도면과 같은 것들)은 통합되어야 한다.

4.1 Project Plan Development

프로젝트 계획 개발은 프로젝트의 집행과 프로젝트 관리(project control)를 가이드 하기 위해

사용될 수 있는 일관된 문서를 만들기 위해서 다른 계획 프로세스의 결과물을 사용한다. 이
프로세스는 거의 매번 수차례 반복된다. 예를 들면, 최종도면이 특별한 자원과 명백한 일자를
반영하는 반면에 초기도면은 일반적인 자원과 갱신된 공기를 포함한다. 프로젝트 도면은 다음과
같이 사용된다.

·프로젝트 집행의 지침
·프로젝트 계획 추정(가정)을 문서화
·선정된 대안들을 고려하는 프로젝트 계획 결정의 문서화

23 of 109
·프로젝트 관련자들간의 의사소통을 촉진
·내용, 정도, 그리고 시기에 관하여 핵심 관리검토 사항을 정의
·진도관리와 프로젝트 관리(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).

계획목적에 있어서, 추정(가정)은 진실, 사실 또는 확실하게 되도록 고려되어야 할 요소이다.

24 of 109
예를 들면, 핵심적인 사람을 이용할 수 있는 날짜가 불확실하다면, 팀은 특별한 착수 일을 추정
(가정)할 것이다. 추정(가정)은 일반적으로 어느 정도의 리스크를 수반한다.

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).

프로젝트 도면은 프로젝트 실시를 관리하고 통제하기 위해 사용되는 공식적이고 승인된

문서이다. 이것은 의사소통 관리 계획에서 정의된 것처럼 분류되어야 한다(예를 들어, 단일

25 of 109
프로젝트에서 수행조직의 관리는 그다지 상세하지 않은 넓은 적용범위를 필요로 하는 반면에
수급업자는 완전한 디테일을 요구할 것이다).
프로젝트 도면과 프로젝트 수행 측정 기준선 사이에는 명확한 구별이 있어야 한다. 프로젝트
도면은 프로젝트에 관해서 더욱 많은 정보들이 이용 가능하게 됨으로써 공사기간을 변경하도록
기대되는 문서나 문서의 집합이다. 수행측정기준은 간헐적으로 변경될 것이고 일반적으로 승인된
범위변경에 대해서만 변경되는 관리통제(management control)를 나타낸다.
프로젝트 도면을 구성하고 나타내는 데에는 많은 방법이 있지만, 보통 다음을 전부 포함한다(이
항목들은 다른 곳에서 상세하게 설명된다).

·프로젝트 헌장(project charter)

·프로젝트 관리방식이나 전략에 대한 기술(다른 지식분야로부터 각각의 관리계획의
요약)
·프로젝트 생산물과 프로젝트 목표를 포함하는 범위선언(제시-statement)
·관리가 행해지는 레벨에서의 작업분류체계
·관리가 행해지는 WBS의 레벨에서 비용견적, 계획된 착수일자, 책임할당
·일정과 비용에 관한 수행측정기준
·주요 마일스톤과 각각에 대한 목표일
·핵심직원 또는 필요한 직원
·제약요소와 추정(가정)을 포함하는 주요 리스크와 각각에 대한 계획된 대응(plannde
response)
·범위관리도면, 일정관리도면 등을 포함하는 부수적인 관리도면
·공개된 문제와 임박한 결정사항(open issues and pending decisions)

다른 프로젝트 계획 아웃풋은 각각의 프로젝트의 요구에 기초한 공식도면(formal plan)을

포함해야 한다. 예를 들면, 대형 프로젝트에 있어서 프로젝트 도면은 일반적으로 프로젝트
구성차트를 포함한다.

.2 지원도면(supporting detail).

프로젝트 도면을 위한 지원도면은 다음을 포함한다.

·프로젝트 도면을 포함하고 있지 않은 다른 계획 프로세스로부터의 아웃풋

·프로젝트 도면의 개발중에 생성된 부가정보나 문서(예를 들면, 미리 알려지지 않았던
제약요소와 추정(가정))
·요구조건, 시방서, 설계와 같은 기술적인 문서
·관련표준 문서

26 of 109
 이러한 자료는 프로젝트 도면의 실행 동안에 사용을 용이하게 하기 위해서 필요에 따라
구성되어야 한다.

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).

27 of 109
 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절 참조).

28 of 109
.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).

변경요구는 구두 혹은 서면, 직접 혹은 간접, 외부제공 혹은 내부제공, 법적 강제 혹은 선택

등의 다양한 형태로 발생할 수 있다.

29 of 109
4.3.2 Tools and Techniques for Overall Change Control

.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)과 같은 프로젝트 수행의 측정기법들은 계획과의 차이가

30 of 109
수정조치를 필요로 하는지를 평가하는 것을 돕는다.

.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의
일부가 되도록 해야 한다.

5장 프로젝트 범위 관리 (PROJECT SCOPE MANAGEMENT)

범위관리에는 프로젝트를 성공적으로 완성하는데 꼭 필요한 모든 작업을 프로젝트가 확실히

포함하도록 해주는 데 필요한 과정이 포함된다. 주로, 프로젝트에 무엇을 포함시키고, 포함시키지
말아야 할 것인지를 정의, 관리하는 것과 관련된다. 그림 5-1은 주요한 프로젝트 범위관리 과정의
개요를 보여준다.

31 of 109
이 장은 착수(조직이 프로젝트의 다음단계를 시작하도록 함), 범위계획(향후 프로젝트 결정의
바탕이 되는 범위진술을 서면으로 작성), 범위정의(주요 프로젝트 성과물들을 작고 관리하기 쉬운
구성요소로 나눔), 범위확정, 범위 변경관리의 순서로 전개된다.
이런 과정들은 서로간 및 다른 지식영역의 과정들과도 상호작용한다. 각 과정은 프로젝트의
요구에 기반을 둔 각 과정의 하나 혹은 그 이상의 개개 또는 그룹으로부터 나온 노력을 포함할
수도 있다. 통상, 각 과정은 모든 프로젝트 단계에서 적어도 한번은 나온다.
비록, 과정들이 여기서는 잘 정의된 경계면을 가진 분리된(불연속적인) 요소로서 제시되었지만,
실제로는 중첩될 수도 있고, 여기에 설명되지 않은 방식으로 상호교류를 한다(과정들 간의
상호교류는 3장 참조).

"범위"는 프로젝트의 맥락에서 다음과 관련된다.

·생산물 범위: 생산물이나 용역(services)에 포함되어야 할 특징이나 기능.

·프로젝트 범위: 시방서가 요구하는 특징 및 기능들을 가진 생산물을 조달하기 위해 행해져야
하는 작업.

프로젝트 범위 관리에 사용된 이러한 과정, 도구, 기법들은 이 장의 핵심이다. 생산물의 범위를
관리하기 위해 사용된 과정, 도구, 기법들은 적용영역에 따라 다양하고, 통상 프로젝트
생애주기의 일부로 정의된다(2. 1 참조)
프로젝트는 단일의 생산물로 구성되지만, 자체적으로 분리되면서 상호의존적인 생산물의 범위를
가진 하부요소들을 포함할 수도 있다. 예를 들면, 새로운 전화시스템은 일반적으로 4개의
하위요소(H/W, S/W, 훈련, 이행)를 포함한다.
프로젝트 범위의 완성이 계획에 대하여 측정되는 반면, 생산물 범위의 완성은 요구조건에 대해
측정된다. 범위관리의 양쪽 형태는 프로젝트의 작업이 규정된 생산물이 확실히 배달될 수 있도록
잘 통합되어야 한다.

5.1 착수(着手)

착수는 새로운 프로젝트가 존재하거나 기존의 프로젝트가 다음 단계로 진행되어야 함을

공식적으로 인정하는 과정이다(프로젝트 단계는 2.1참조). 이런 공식적인 착수는 프로젝트를
수행조직의 지속적인 작업과 연계시킨다. 일부 조직에서는 타당성 연구, 예비계획, 별도로 시작된
기타의 분석 등이 끝나기 전까지는 프로젝트가 공식적으로 착수되지 않는다. 프로젝트의 일부
형태들은 특히, 내부업무 프로젝트와 새로운 제품개발 프로젝트 등은 작업이 비공식적으로
착수되고, 공식적인 착수에 필요한 승인을 확보하기 위해서 일정의 제한된 양의 작업이
이루어진다. 프로젝트는 일반적으로 아래의 하나 혹은 그 이상의 결과로 인가를 받는다.

·시장의 요구(정유회사가 만성적인 가솔린 부족에 대응하기 위해 새로운 정유공장을 짓는

32 of 109
프로젝트를 허가했다.
·사업요구(Training Company가 수입을 증가시키기 위해 새로운 과정을 신설하는 프로젝트를
허가했다).
·고객의 요구(전기회사가 새로운 공단에 제공할 지점을 짓는 프로젝트를 허가했다).
·기술적 진보(전자회사가 Video casset recorder가 소개된 후 Video game player를 개발하는
새로운 프로젝트를 허가했다).
·법적인 요구사항(Paint 제조업체가 유독물질을 취급하는 지침을 설정하는 프로젝트를
허가했다).
이러한 자극요소들은 문제, 기회, 사업의 요구조건 등으로 불려질 수 있다. 이런 모든 용어들의
중심적인 주제는 `통상 관리진이 대응방법에 대한 결정을 내려야 한다'는 것이다.

5.1.1. 착수단계에 대한 투입물(Inputs to Initiation)

.1 생산물 설명 생산물 설명은 프로젝트가 만들려고 착수한 생산물 혹은 Service의 특성을

문서화 한다. 생산물 설명은 통상 초기단계에서는 다소 덜 상세하고, 생산물 특징이 점점 더
정교해지는 나중 단계에서는 더욱 상세해 질 것이다.
생산물 설명은 건설중인 생산물 또는 Service와 프로젝트에서 발생한 사업요구 또는 기타의
자극요인 간의 관계를 문서화해야 한다. 생산물에 대한 설명의 형식과 실체는 다양해 질 수
있지만, 나중의 프로젝트 계획을 지원하기에 충분할 만큼 늘 상세해야 한다.
많은 프로젝트들은 계약 하에서 타인(구매자)을 위해 일하는 하나의 조직(판매자)을 포함한다.
그러한 환경에서, 초기의 생산물 설명은 보통 구매자가 제공한다. 만약, 구매자의 작업 그 자체가
프로젝트라면, 생산물에 대한 구매자의 설명은 12.1.3.2에 설명된 작업진술이다.

.2 전략적 계획 모든 프로젝트는 수행조직의 전략적 목표를 지원해야 한다. 즉, 수행조직의

전략적 계획은 프로젝트의 선택결정의 요인으로 고려되어야 한다.

.3 프로젝트 선택을 위한 규준 프로젝트 선택규준은 전형적으로 프로젝트 생산물의 측면에서

정의되고, 가능한 관리상의 관심사항의 전 범위를 포함할 수 있다(재무상환, 시장점유, 대중의
인식 등).

.4 역사적인 정보 이전 프로젝트 선택결정의 결과와 이전에 수행된 프로젝트 모두에 대한

역사적인 정보는 이용가능한 한 고려되어야 한다. 착수에 프로젝트의 다음 단계를 위한 승인이
포함될 때, 이전 단계의 결과에 대한 정보는 중요할 때가 많다.

5.1.2 착수의 도구 및 기법

.1 프로젝트 선정 방법 프로젝트 선정 방법은 일반적으로 하나 또는 두 개의 큰 범주에 속한다.

33 of 109
 ·효용측정 방법: 비교법, 점수모델, 효용분담금액, 경제적 모델
·구속 최적화 방법: 선형, 비선형, 역학, 정수, 다목적용 프로그래밍 연산방식을 이용한
수학적 모델

이런 방법들은 자주 의사결정모델로 언급된다. 의사결정모델은 특별한 것들(AHP-Analytec

Hierarchy Process, Logical Framework Analysis 등) 뿐만 아니라 보편적인 기법(의사결정 tree,
강제적 선택-forced choice 등)을 포함한다. 정교한 모델속에서 복잡한 프로젝트 선정규준을
적용하는 것은 가끔 별개의 프로젝트 단계로 취급된다.

.2 전문가 판단 전문가 판단이 가끔 이 과정에 투입되는 것들을 평가하도록 요청된다. 이런

전문지식은 특별한 지식이나 훈련을 가진 그룹 또는 개인이 제공할 것이고, 다음과 같은 많은
곳에서 이용가능하다.

·수행조직 내부의 다른 부서, 컨설턴트, 전문 및 기술 협회, 산업단체

5.1.3 착수단계의 결과

.1 프로젝트 헌장(憲章) 프로젝트 헌장은 프로젝트의 존재를 공식적으로 인정하는 문서이다.

이것은 직접 혹은 다른 문서에 언급하여 아래사항을 포함해야 한다.

·프로젝트가 착수되어야 하는 사업요구

·생산물 설명(5.1.1.1에 설명된 것)

프로젝트 헌장은 프로젝트 외부인으로서 프로젝트의 요구에 적합한 수준의 관리자가 발행해야
한다. 그것은 프로젝트 관리자에게 조직의 자원을 프로젝트 액티비티에 적용시킬 수 있는 권한을
제공한다.
프로젝트가 계약하에서 수행될 때, 서명된 계약은 통상 판매자를 위한 프로젝트 헌장의 역할을
한다.

.2 프로젝트 관리자의 발굴/임명 일반적으로, 프로젝트 관리자는 타당성 조사단계 처럼 프로젝트

초기단계에서 발굴 및 임명되어야 한다. 프로젝트 관리자는 항상 프로젝트 계획이 실행되기 전에
임명되어야 하고(4.2참조), 가급적 많은 프로젝트 계획이 행해지기 이전이 좋다(3.3.2 참조)

.3 제약조건 제약조건은 프로젝트 관리팀의 선택을 제한하는 요인들이다. 예를 들면, 사전정의된

예산은 범위, 직원충원, 일정 등과 관련하여 팀의 선택을 상당히 제한할 수 있는 제약조건이다.
프로젝트가 계약 하에서 수행될 때 계약조항도 통상 제약조건이 된다.

34 of 109
 .4 가정(假定) 가정사항들은 계획의 목적으로 사실적, 실제적, 확실한 것으로 고려될
요인들이다. 예를 들어 만약, 중요한 사람이 참여하게 될 날짜가 불확실하다면, 팀은 특정
시작일을 가정해야 한다. 가정은 통상 리스크를 함유한다. 가정사항들은 여기서 확인될 수도
있고, 리스크 확인의 결과로 나올 수도 있다(11.1).

5.2 범위 계획

범위계획은 특히, 프로젝트 혹은 단계가 성공적으로 완성되었는지의 여부를 결정하는데 사용되는

규준을 포함한 미래의 프로젝트 결정을 위한 기반으로써 서면(書面)의 범위진술을 도출하는
과정이다. 서면의 범위진술은 프로젝트나 하위 프로젝트 모두를 위해 필요하다. 예를 들면,
정유공장의 설계를 위해 계약한 설계회사는 설계 하위프로젝트에 대한 작업경계를 정의하는
범위진술을 해야 한다. 범위진술은 프로젝트 목적과 주요한 프로젝트 성과물 모두를 확인함으로써
프로젝트 팀과 프로젝트 고객간의 협약(agreement)을 위한 기반을 형성한다.
만약, 모든 범위진술의 요소들이 이미 이용 가능하다면(예, 제안서 요구는 주요 성과물을 확인할
수 있고, 프로젝트 헌장은 프로젝트 목적을 정의할 수 있다), 이 과정은 단지 물리적으로
서면문서를 만드는 것만을 포함할 것이다.

5.2.1 범위계획에 대한 투입물

.1 생산물 설명 (5.1.1.1)
.2 프로젝트 헌장 (5.1.3.1)
.3 제약조건 (5.1.3.3)
.4 가정사항 5.1.3.4 참조

5.2.2 범위계획을 위한 도구 및 기법

.1 생산물 분석 프로젝트의 생산물에 대한 더 나은 이해를 불러일으키는 것을 포함한다.

시스템공학, 가치공학, 가치분석, 기능분석, 품질기능 전개(deployment) 등과 같은 기법이
포함된다.

.2 효용/비용 분석 효용/비용 분석에는 유형 및 무형의 비용(지출, 경비), 다양한 프로젝트

대안들의 효용(수익)에 대한 견적, 확인된 대안의 상대적인 바람직함을 평가하기 위한 투자에
대한 상환이나 환불기간 등의 재무 도구(measures)의 이용이 포함된다.

.3 대안의 확인 프로젝트에 대한 다른 방법들을 발생시키는 데 사용되는 모든 기법에 적용되는

용어이다. 여기에는 자주 사용되는 여러 일반관리 기법들이 있는데, 그 중 가장 보편적인 것이

35 of 109
브레인 스토밍과 측면사고(側面思考)다.
.4 전문가 판단 5.1.2.2 참조

5.2.3 범위계획의 결과

.1 범위진술 범위진술은 미래의 프로젝트에 대해 의사결정을 하고 프로젝트 범위에 대한

참여자들간의 공통적인 이해를 확인 또는 도출시키기 위한 문서화된 기반을 제공한다. 프로젝트가
진행함에 따라, 범위진술은 프로젝트 범위변경을 반영하기 위해 개정 또는 세련될 필요가 있다.
범위진술은 직접적이든 혹은 다른 문서들을 언급하든지 간에 아래의 것을 포함해야 한다.

·프로젝트 정당화: 프로젝트가 착수되도록 한 사업요구. 프로젝트 정당화는 미래의

상관관계(trade-offs)를 평가하는 기반을 제공한다.
·프로젝트 생산물: 프로젝트 설명(5.1.1.1 참조)에 대한 간단한 요약
·프로젝트 성과물: 개략적인 수준의 하위생산물 목록. 이것들의 완전하고 만족스런
조달이 프로젝트의 완성을 뜻함. 예를 들면, Software 개발 프로젝트를 위한 주요한 성과물에는
작동중인 컴퓨터 코드, 사용자 지침서, 상호 호환적인 指導(an interractive tutorial) 등이
포함된다. 이러한 것들이 알려졌을 때 배제사항이 확인되어야 한다. 그러나 명백하게 포함되지
않은 것은 모두 은연중에 배제된다.
·프로젝트 목표: 프로젝트가 성공적이라고 고려되기 위해 만족되어져야 할 정량화
가능한 규준. 프로젝트 목표는 최소한, 비용, 일정, 품질의 기준(measures)을 포함해야 한다.
프로젝트 목표는 속성(예, 비용), 척도(예, 달러), 절대적 혹은 상대적 가치(예, 150만 이하)
등을 가져야 한다. 비정량적인 목표(예, 고객만족)들은 높은 리스크를 수반한다.
일부 적용영역에서는 프로젝트 목표들이 결정적인 성공인자로 불리는 반면, 프로젝트 성과물들은
프로젝트 목표라 불린다.

.2 지원상세(支援詳細) 범위진술을 위한 지원상세는 다른 프로젝트 관리 과정에서 그것의 사용을

촉진시키기 위해 필요할 때마다 문서화되고 조직화되어야 한다. 지원상세는 항상 모든 확인된
가정사항과 제약조건을 포함해야 한다. 부가적인 상세의 양은 적용영역에 따라 다양하다.

.3 범위관리 계획 이 문서는 프로젝트 범위가 어떻게 관리되고, 범위변경들이 어떻게 프로젝트

속으로 통합될 것인가를 설명한다. 이것은 프로젝트 범위의 기대되는 안정성에 대한 평가를
포함해야 한다(즉, 얼마나 잘, 얼마나 자주, 얼마나 많이 변하려 하는지). 범위관리계획은 또한,
범위변경들이 어떻게 확인되고 분류될 것인지에 대한 명백한 설명을 포함해야 한다(이것은
특별나게 어려워서 생산물 특성이 여전히 정교하게 만들어지고 있을 때는 절대적으로 중요하다).
범위관리 계획은 프로젝트의 요구에 근거해서 공식적 또는 비공식적, 상당히 상세하거나 또는
폭넓게 형성될 수도 있다. 이것은 프로젝트 관리계획의 부수적인 요소이다(4.1.3.1 참조).

36 of 109
5.3 범위 정의

범위정의는 범위진술에서 확인된 주요한 프로젝트 성과물들을 작고, 관리하기 쉬운 구성요소로

세분하는 것을 포함한다. 그 목적은 다음과 같다.

·비용, 시간, 자원 견적의 정확성을 향상시키기 위해

·프로젝트 수행의 측정 및 관리를 위한 기준선을 정의하기 위해
·분명한 책임할당을 촉진시키기 위해

프로젝트 범위정의는 프로젝트 성공에 상당히 중요하다. "범위정의가 잘 되어있지 않을때에는

최종 프로젝트 비용은 더욱 높아질 것으로 기대되는데, 그 이유는 프로젝트 리듬을 방해하고,
재작업을 야기시키고, 프로젝트 시간을 증가시키며, 작업원의 생산성과 사기를 떨어뜨리는 변경을
피할 수 없기 때문이다.

5.3.1 범위정의에 대한 투입물

.1 범위진술 5.2.3.1 참조

.2 제약조건 5.1.3.3 참조. 프로젝트가 계약 하에서 끝났을 때, 계약조항에 의해 정의된

제약조건들은 자주 범위정의 동안 중요한 고려사항들이다.

.3 가정사항 5.1.3.4 참조

.4 기타의 계획 결과물 다른 지식영역에 있는 과정들의 결과물들은 프로젝트 범위정의에 영향을

미칠 수 있으므로 검토되어야 한다.

.5 역사적인 정보 이전 프로젝트들에서의 역사적인 정보는 범위 정의기간 동안 고려되어야 한다.

이전 프로젝트에서의 실수와 누락에 관한 정보는 특히 유용하다.

5.3.2 범위정의를 위한 도구 및 기법

.1 작업분류체계 型板(바탕-templates)

이전 프로젝트의 작업분류체계(WBS, 5.3.3.1 참조)는 가끔 새로운 프로젝트를 위한 형판으로

사용될 수 있다. 비록, 각 프로젝트는 독특하지만 대부분의 프로젝트들이 어느 정도까지는 다른
프로젝트와 유사점이 있기 때문에 WBS들은 재사용될 수 있다. 예를 들면, 주어진 조직내에서의
대부분의 프로젝트들은 동일하거나 유사한 프로젝트 생애주기를 가질 것이고, 이렇게 하여 각

37 of 109
단계로부터 요구되는 동일한 혹은 유사한 성과물들을 가지게 될 것이다.
많은 적용영역에는 형판으로 사용될 수 있는 표준적인 혹은 반표준적인 WBS들이 있는데 예를
들면, 미국방성은 국방성 자재품목을 위한 표준 WBS들을 정의했다(그림 5-2 참조).

.2 분해(Decomposition)

분해에는 성과물들이 미래의 프로젝트 액티비티(계획, 실행, 관리, 완료)를 지원하기에 충분히
상세하게 정의될 때까지 주요 프로젝트 성과물들을 작고, 관리하기 쉬운 구성요소들로 나누는
것이 포함된다. 분해는 다음의 주요 단계들을 포함한다:

(1) 프로젝트의 주요 요소들을 확인한다.

통상, 주요 요소들은 프로젝트 성과물들 및 프로젝트 관리의 대상이 될 것이다. 그러나, 주요

요소둘은 항상 프로젝트가 어떻게 실질적으로 관리될 것인지의 측면에서 정의되어야 한다. 예를
들면,
·그림 5-3에서 처럼, 프로젝트 성과물들이 두 번째 수준에서 되풀이 되는 동안 프로젝트
생애주기의 각 단계는 분해의 첫 번째 수준으로 이용될 수도 있다.
·그림 5-4에서 처럼, WBS의 각 가지내에서 구성 원칙들은 다양하다.

(2) 이런 상세수준에서 각 요소들을 위해 적절한 비용 및 기간의 산정이 가능한지를 결정하라.

적절함의 의미는 프로젝트의 과정에 따라 달라질 수 있다. 먼 미래에 생산될 성과물의 분해는
불가능할 수도 있다. 각 요소를 위해 적당하게 상세하다면 4단계로 가고, 그렇지 않으면 3단계로
가라. 이것은 곧 요소가 다르면 분해의 수준이 달라질 수 있다는 의미이다.

(3) 성과물의 구성요소들을 확인하라.

구성요소들은 프로젝트 수행의 측정을 용이하게 하기 위해 유형적이고(tangible) 입증할 수 있는

(verifiable) 측면에서 정의되어야 한다. 주요 요소들과 함께 구성요소들은 프로젝트의 작업이
실제로 어떻게 달성될 수 있는 가의 측면에서 정의되어야 한다. 유형적이고 입증할 수 있는
결과에는 생산물뿐만 아니라 Services도 포함될 것이다(예, 상황보고는 주간 상황보고서로 설명될
수 있다. 공장제작 항목을 위한 구성요소에는 몇 개의 개별적인 요소와 최종조립까지 더하여
포함될 것이다). 각 구성요소에 대해 2단계를 반복하라.

(4) 분해의 타당성(correctness)을 증명하라

·항목의 완성을 위해 필요하고도 충분한 낮은 수준의 항목들이 분해되었는가? 만약

38 of 109
그렇지 않다면, 구성요소들은 변경되어야 한다(더하거나, 삭제하거나, 재정의 되어야 함).
·각 항목은 명백하고 완전하게 정의되었는가? 만약 그렇지 않다면, 설명이 수정되거나
덧붙여져야 한다.
·각 항목이 적절하게 계획될 수 있는가? 예산이 책정될 수는 있는갸? 이 항목의
만족스런 완성에 대한 책임을 질 특정 조직단위(부서, 팀, 개인)에 할당될 수 있는가? 만약
그렇지 않다면, 적절한 관리통제를 위해 개정(수정)이 필요하다.

5.3.3 범위정의의 결과물

.1 작업분류체계 작업분류체계는 프로젝트 전체 범위를 조직, 정의하는 프로젝트 요소들을

성과물 지향으로 묶은 것이다. WBS 속에 있지 않은 작업은 프로젝트 범위밖에 있는 것이다.
범위진술과 함께, WBS는 자주 프로젝트 범위에 대한 공통의 이해를 도출 혹은 확인하는데
사용된다. 하향하는 각 수준은 프로젝트 요소들을 더욱 더 상세하게 설명한다. 5.3.2.2는 WBS를
만들기 위한 가장 보편적인 방법이다. WBS는 그림 5-2^4에서 보여지는 것처럼 보통 차트형식으로
표현된다. 그러나, WBS는 설명(presentation)방법과 혼동되어서는 안 된다. 즉, 챠트에
구조화되지 않은(unstructured) 액티비티 목록을 그리는 것이 WBS는 아니다.
WBS에 있는 각 항목은 통상 독특한 변별자(identifier)를 할당한다. 이런 변별자들은 집합적으로
계정코드(account code)라고 불려진다. WBS의 가장 낮은 수준의 항목들은 작업패키지로 자주
언급되는 데, 이 작업 패키지들은 6.1의 액티비티 정의에서 설명되듯이 더욱 분해될 것이다.
작업요소 설명은 가끔 WBS사전에 모아진다. WBS사전은 전형적으로 공정표상 날짜(schedule
date), 비용예산, 직원배치 등과 같은 기타의 계획정보뿐만 아니라 작업패키지 설명까지
포함한다.
WBS는 프로젝트 정보를 제시하는데 사용되는 다른 종류의 "분류체계"와 혼동되어서는 안된다.
다른 구조들은 공통적으로 아래와 같은 일부 적용영역에서 사용되고 있다.
·계약 WBS(CWBS): 판매자가 구매자에게 제공하게 될 보고수준을 정의하기 위해
사용한다. CWBS는 일반적으로 판매자가 판매자의 작업을 관리하기 위해 사용하는 WBS보다 덜
상세하다.
·조직분류체계(OBS): 어느 작업요소들이 어느 조직단위에 배당되었는지를 보여주기 위해
사용된다.
·자원분류체계(RBS): OBS의 변종이고 통상 작업요소들이 개인에게 할당될 때 사용된다.
·자재 수량서(Bill Of Materials - BOM): 공장제작된 생산품을 조립하는데 필요한
물리적인 조립재, 하위조립재, 구성부품 등에 대한 위계를 보여준다.
·프로젝트 분류체계(PBS): 올바르게 행해진 WBS와 근본적으로 동일하다. PBS라는 용어는
WBS가 BOM를 언급하기 위해 올바르게 사용되지 않는 적용영역에서 광범위하게 사용된다.

5.4 범위 확인(SCOPE VERIFICATION)

39 of 109
범위 확인은 참여자들이(후원자, 고객, 의뢰인 등) 프로젝트 범위를 받아들이는 것을 공식화하는
과정이다. 이것은 모든 것이 올바르고 만족스럽게 완성되었다는 것을 보장하기 위해 작업생산물과
결과에 대한 검토를 요구한다. 프로젝트가 초기에 끝날 경우에는, 범위확인 과정에서 완성의 수준
및 정도에 대한 확인(establish), 문서화가 이루어져야 한다. 범위확인은 작업결과를 승인하는
것과 주로 관련되기 때문에 작업결과의 적절성(correctness)과 주로 관련되는 품질관리와는(8.3절
참조) 다르다

5.4.1 범위확인에 대한 투입물

.1 작업결과 프로젝트 계획을 실행한 결과로써(4.2절 참조), 완전히 혹은 부분적으로 완성된

성과물, 발생 혹은 집행된 비용 등이다.

.2 생산물의 문서화 프로젝트의 생산물들을 설명하기 위해 작성된 문서들은 검토가능 해야 한다.

이 문서화를 설명하는 데 사용되는 용어는 적용영역에 따라 다양하다(설계도면, 시방서,
기술문서, 제도도면 등)

5.4.2 범위확인의 도구 및 기법

.1 검사 결과가 요구조건에 적합한지의 여부를 결정하기 위해 실시하는 측정(평가), 검사, 시험

등과 같은 작업(activity)이 포함된다. 검사는 검토, 생산물 검토, 감사, 상세검토(walk through)
등 다양하게 불려진다. 일부의 적용영역에 있어서 이렇게 다른 용어들은 범위가 좁고 특수한
의미를 가진다.

5.4.3 범위확인의 결과물

.1 공식적인 승인 발주자나 후원자가 프로젝트 혹은 단계의 생산물을 승인했다는 문서가 마련,

배포되어야 한다. 그러한 승인은 조건적인데 특히, 단계의 마지막에서 그러하다.

5.5 범위변경 관리

범위변경 관리는 (1)변경이 이롭다는 것을 보장하기 위해 범위변경을 야기시키는 요인들에게

영향을 미치고, (2)범위변경이 발생했음을 결정하며, (3)범위변경이 발생했을 경우 실질적인
변경을 의미하는 것과 관련된다. 범위변경 관리는 기타의 관리과정과 철저하게 통합되어야 한다
(시간관리, 비용관리, 품질관리, 기타 4.3절에서 논의된 것 등).

5.5.1 범위변경 관리에 대한 투입물

40 of 109
.1 작업분류체계 프로젝트 범위의 기준선을 정의한다(5.3.3.1 참조)

.2 프로젝트 수행보고서 잠정 생산물의 완성여부와 같이 범위 수행에 대한 정보를 제공한다

(10.3.3.1 참조). 수행보고서들은 프로젝트 팀이 미래에 문제를 야기시킬 사안들을 알도록 일깨워
준다.

.3 변경 요청서 구두 혹은 서면, 직접 혹은 간접, 외부발생적 혹은 내부발생적, 법적인 강제

혹은 선택 등의 많은 형태로 일어난다. 변경들은 범위의 확장을 요구하거나 범위의 축소를 허락할
수도 있다. 대부분의 변경들은 아래사항의 결과이다.
·외부사건(정부규정의 변화)
·생산물의 범위를 정의하는데 있어서 실수 혹은 누락(원거리 통신시스템에서 설계의
필요한 그림을 포함시키지 못함)
·프로젝트 범위정의 과정상의 실수 혹은 누락(작업분류체계 대신 자재(물량) 수량서(
산출서)를 사용함)
·가치가 더해진 변경(환경개선 프로젝트는 범위가 처음에 정의될 때 이용할 수 없었던
기술을 이용하므로써 비용을 절감할 수 있다).

.4 범위관리 계획 5.2.3.3 참조

5.5.2 범위변경 관리를 위한 도구 및 기법

.1 범위변경 관리시스템 범위변경 관리시스템은 프로젝트 범위가 변경될 수 있는 절차를

정의한다. 여기에는 변경을 승인하는데 필요한 서류작업, 공사추적 시스템, 승인수준 등이
포함된다. 범위변경 관리시스템은 4.3절에 설명된 전반적인 변경관리 시스템과 통합되어야 하고
특히, 생산물 범위를 관리하기 위한 모든 시스템과도 통합되어야 한다. 프로젝트가 계약하에서
행해질 때, 범위변경 관리시스템은 모든 관련 계약조항에 적합해야 한다(comply with).

.2 프로젝트 수행평가 10.3.2에서 설명된 수행 평가기법들은 발생한 어떠한 변동량의 크기도

평가(査定)할 수 있도록 돕는다. 범위변경 관리의 중요한 부분은 차이를 유발시키는 것이
무엇인가를 결정하고, 차이가 수정조치를 필요로 하는가를 결정하는 것이다.

.3 부가적인 계획 계획에 따라 정확하게 수행되는 프로젝트는 드물다. 장차 기대되는

범위변경들은 WBS에 대한 수정 혹은 대안의 분석을 요구할 것이다.

5.5.3 범위변경 관리의 결과물

.1 범위변경 범위변경은 승인된 WBS에 의해 정의된 대로 상호 동의한 프로젝트 범위에 대해

41 of 109
발생하는 모든 수정을 말하는데, 빈번히 비용, 시간, 품질, 기타 프로젝트 목표에 대한 정정(
조정)을 요구한다.
범위변경은 계획과정을 통해 피드백 되고, 기술 및 계획 문서들은 필요 시마다 갱신되며,
참여자들은 적절하게 통지 받는다.

.2 수정조치 수정조치는 기대되는 미래의 프로젝트 수행을 프로젝트의 계획에 맞게 가져가기

위해 행하는 모든 것이다.

.3 경험적 교훈 차이(variance)의 원인, 선택된 수정조치 이면의 합리성, 범위변경 관리로부터

습득된 기타 여러 형태의 교훈들은 문서화되어 이런 정보가 당해 프로젝트 및 수행조직의 또 다른
프로젝트 모두를 위한 역사적인 D/B의 일부가 되어야 한다.

6장 프로젝트 시간 관리 (PROJECT TIME MANAGEMENT)

프로젝트 시간관리는 프로젝트의 적시완공을 보장하는데 필요한 과정들을 포함한다. 그림 6-1은

아래의 주요 과정들의 전체적인 흐름을 보여준다.

6.1 액티비티 정의: 다양한 프로젝트 성과물들을 생산하기 위해 수행되어야 하는 특정

액티비티의 확인
6.2 액티비티 순서정하기: 액티비티들 간의 상호의존성을 확인 및 문서화
6.3 액티비티 기간 산정: 개별 액티비티들의 완성에 필요하게 될 작업기간 산정
6.4 일정 도출: 프로젝트 일정을 짜기 위해 액티비티 순서, 액티비티 기간, 자원 상황(
요구조건) 등의 분석
6.5 일정 관리: 프로젝트 일정에 대한 변경 관리

이 과정들은 서로 그리고 다른 지식영역에 있는 과정들과 상호작용한다. 각 과정에는 프로젝트

요구에 기반을 둔 개별의 하나 혹은 그 이상의 단일 또는 그룹으로부터의 노력이 포함될 수도
있다. 각 과정은 통상 모든 프로젝트 단계에서 최소한 한번은 일어난다.
비록, 과정들이 여기서는 잘 정의된 경계면을 가진 분리된(불연속적인) 요소로서 제시되었지만,
실제로는 중첩될 수도 있고, 여기에 설명되지 않은 방식으로 상호교류를 한다(과정들 간의
상호교류: 3장 참조).
어떤 프로젝트에서는(특히 소규모) 액티비티 순서정하기, 액티비티 기간산정, 일정도출은 상당히
밀접하게 연결되어 있어서 단일의 과정으로 보여진다(그들은 비교적 짧은 기간에 걸쳐 한 사람에
의해 수행될 수도 있다). 각각을 위한 도구 및 기법들이 다르기 때문에 여기서는 구분된 과정으로
제시되었다.
현재, 액티비티와 직무(task)간의 관계에 대해서는 프로젝트 관리 분야(profession)내에 의견의

42 of 109
일치가 없다.

·많은 적용영역에서, 액티비티들은 직무들로 구성되어 있음을 볼 수 있다. 이것은 가장

일반적이면서도 선호되어 사용된다.
·다른 영역에서, 직무들은 액티비티들로 구성된 것 처럼 보인다.
그러나, 중요한 고려사항은 사용된 용어가 아니라 수행되어야 할 작업이 그 작업을 할 사람에게
정확하게 설명되고 이해되는 가의 여부이다.

6.1 액티비티 정의

액티비티 정의에는 작업분류체계 내에서 확인된 성과물 및 하위성과물들을 생산하기 위해

수행되어야 하는 특정 액태비티들을 확인, 문서화하는 것이 포함된다. 이 과정에 함축된 것은
프로젝트 목적을 충족시켜 줄 액티비티들을 정의하기 위한 필요성이다.

6.1.1 액티비티 정의에 대한 투입물

.1 작업분류체계 액티비티 정의에 가장 중요한 input이다(5.3.3.1 참조)

.2 범위진술 범위진술에 포함된 프로젝트 정당화 및 프로젝트 목표는 액티비티 정의기간 동안

분명하게 고려되어야 한다(5.2.3.1 참조)

.3 역사적인 정보 이전의 유사 프로젝트에서 실제로 어떤 액티비티가 요구되었는가가 프로젝트

액티비티 정의기간 동안 고려되어야 한다.

.4 제약조건 프로젝트 관리팀의 선택을 제한하는 요인들

.5 가정사항 계획의 목적으로써 사실이고, 실제적이고, 확실한 것으로 간주될 요인들로써 통상

어느 정도의 리스크를 포함하며, 보통은 리스크 확인의 결과물이다(11.1 참조)

6.1.2 액티비티 정의를 위한 도구 및 기법

.1 분해 프로젝트 요소들을 개선된 관리통제를 위해 더 작고, 관리하기 용이한 구성성분으로

프로젝트 요소들을 구분하는 것이다(5.3.2.2 참조). 여기서 설명된 분해와 범위정의 간의 주된
차이는 여기서의 최종 결과물들이 성과물(유형의 항목)이라기 보다는 액티비티(조치단계-actions
steps)로 설명된다. 일부 적용영역에서는 WBS와 액티비티 목록이 동시에 만들어 진다.

.2 형판 액티비티 목록(6.1.3.1 참조) 또는, 이전 프로젝트로 부터의 액티비티 목록의 일부는

43 of 109
자주 새로운 프로젝트를 위한 형판으로 사용될 수 있다. 더구나, 현재 프로젝트로 부터의 WBS를
위한 액티비티 목록은 다른 유사한 WBS 요소를 위한 형판으로 사용될 수 있다.

6.1.3 액티비티 정의의 결과물

.1 액티비티 목록 액티비티 목록에는 프로젝트에서 수행될 모든 액티비티들이 포함되어야 한다.

이것은 완전하고 또한 프로제트 범위의 일부로서 불필요한 액티비티는 어떠한 것도 포함시키지
않기 위해 WBS의 연장으로써 조직되어야 한다. WBS와 함께, 액티비티 목록에는 작업이 어떻게
수행되어야 하는가를 프로젝트 팀원들이 확실히 이해하도록 하기 위해 각 액티비티에 대한 설명이
포함되어야 한다.

.2 지원상세 액티비티 목록을 위한 지원상세는 다른 프로젝트 관리과정에서 그것의 사용을

촉진시키기 위해 필요에 따라 문서화, 조직화되어야 한다. 지원상세는 확인된 모든 가정사항과
제약조건들에 대한 문서화를 포함해야 한다. 부가상세의 양은 적용영역에 따라 다양하다.

.3 작업분류체계 갱신 프로젝트 팀은 어떤 액티비티가 필요한 가를 확인하기 위해 WBS를

사용함에 있어, 빠진(부족한-missing) 성과물들을 확인하거나, 성과물에 대한 설명이
명백해지거나 정정될 필요가 있다고 결정할 수 있다. 그러한 모든 갱신들은 WBS나 비용견적 등과
같은 관련문서에 반영되어야 한다. 이러한 갱신들은 가끔 개선(refinement)으로 불리는데
프로젝트가 새롭거나 증명되지 않은 기술을 포함할 때 가장 바람직하다.

6.2 액티비티 순서정하기(ACTIVITY SEQUENCING)

액티비티 순서정하기에는 액티비티간의 상호의존성을 확인, 문서화하는 것이 포함된다.

액티비티들은 나중의 현실적이고 성취가능한 일정의 도출을 지원하기 위해 순서가 정확하게
정해져야 한다. 순서정하는 것은 컴퓨터(프로젝트 관리 S/W 사용)나 수작업으로 수행될 수 있다.
수작업은 소규모 프로젝트나 자세한 것을 활용할 수 없는 대규모 프로젝트의 초기단계에 더욱
효과적이다. 수작업과 자동화된 기법이 조합되어 사용될 수도 있다.

6.2.1 액티비티 순서정하기에 대한 투입물

.1 액티비티 목록 6.1.3.1 참조

.2 생산물 설명 (5.1.1.1 참조). 생산물 특성들은 빈번히 액티비티 순서정하기에 영향을 미친다
(건설되어야 할 공장의 물리적인 배치). 이러한 영향들이 자주 액티비티 목록에서 명백한 반면,
생산물 설명은 통상 정확성의 확인을 위해 검토되어야 한다.

44 of 109
.3 의무적인 상호의존(mandatory dependencies) 의무적인 상호의존은 수행중인 작업의 본성에
내재하는 것이다. 그들은 빈번히 물리적인 제한사항을 포함한다(건설 프로젝트에서는 기초가
완성되기 전에는 상부구조를 세운다는 것이 불가능하고, 전자(電子)프로젝트에서는 시험 전에
원형이 만들어져야 한다). 강제적인 종속들은 "hard logic"이라 불린다.

.4 임의의 상호의존 임의의 상호의존은 프로젝트 관리팀에 의해 정의된 것들이다. 그들은 나중의
일정선택을 제한하므로 주의 깊게 다루어져야 한다(완전하게 문서화 되어야 함). 임의의
상호의존은 통상 다음의 지식을 바탕으로 정의된다.
·특정 적용영역내에 있는 "최고의 실제 사례-Best practices"
·다른 수용가능한 순서가 있음에도 불구하고 특정의 순서가 바람직한 프로젝트의 특이한
측면
임의의 상호의존은 또한 preferred logic, preferential logic, soft logic이라 불린다.

.5 외부의 상호의존(External dependencies) 외부의 상호의존은 프로젝트 액티비티들과 非

프로젝트 액티비티들간의 관계를 포함하는 것들이다. 예를 들면, S/W 프로젝트에서 시험(試驗)
액티비티는 외부로부터의 H/W조달에 의존할 것이고, 건설 프로젝트에서의 환경청문회는 대지가
준비되기 전에 개최 될 필요가 있다.

.6 제약조건 6.1.1.4 참조

.7 가정사항 6.1.1.5 참조

6.2.2 액티비티 순서정하기의 도구 및 기법

.1 선행다이어 그램(Precedence diagramming method-PDM) 액티비티를 나타내는 노드(node)를

상호관계를 보여주는 화살표로 연결시켜서 프로젝트 네트워크 다이어그램을 만드는 방법이다
(6.2.3.1 참조). 그림 6-2는 PDM을 사용하여 그려진 단순한 프로젝트 네트워크 다이어그램을
보여준다. 이 기법은 또한 AON(activity-on-node)라 불리고, 대부분의 프로젝트 관리 S/W패키지에
사용되는 방법이다. PDM은 손으로 또는 컴퓨터로 가능하다.

이것은 다음과 같은 4 가지 형태의 상호관계 또는 선행관계를 포함한다.

·종료에서 시작으로: "-로부터의" 액티비티는 "-로 향한" 액티비티가 시작하기 전에

종료되어야 한다.
·종료에서 종료로: "-로부터의" 액티비티는 "-로 향한" 액티비티가 종료되기 전에
종료되어야 한다.
·시작에서 시작으로: "-로부터의" 액티비티는 "-로 향한" 액티비티가 시작하기 전에

45 of 109
시작하여야 한다.
·시작에서 종료로: "-로부터의" 액티비티는 "-로 향한" 액티비티가 종료되기 전에
시작하여야 한다.

PDM에서 `종료에서 시작으로'(finish-to-start)는 가장 공통적으로 사용되는 논리관계의

형태이다. `시작에서 종료로'의 관계는 가장 드물게 사용되고, 단지 전문적인 일정기술자만
사용한다. 프로젝트 관리 S/W와 `시작에서 시작으로', `종료에서 종료로' 또는 `시작에서
종료로'의 관계를 사용할 경우에는 이런 형태의 관계가 일관성 있게 이행되지 않을 것이므로
예기치 않았던 결과를 가져올 수도 있다.

.2 화살형 다이어그램 방법(Arrow diagramming method-ADM) 이것은 액티비티를 나타내는

화살표를 상호관계를 보여주는 노드에 연결시킴으로써 프로젝트 네트워크 다이어그램을
만들어내는 방법이다(6.2.3.1 참조). 그림 6-3은 ADM을 사용하여 그려진 단순한 프로젝트
네트워크 다이어그램을 보여준다. 이 기법은 AOA(activity-on-arrow)라고도 불려지며, 비록, PDM
보다는 덜 사용되지만, 여전히 일부 적용영역에서는 사용되고 있는 기법이다. ADM은 단지 `
종료에서 시작으로'의 상호관계만을 사용하고 모든 논리적인 관계를 정확하게 정의하기 위해 `
더미 액티비티'가 요구될 수도 있다. ADM은 손으로 또는 컴퓨터로 행해질 수 있다.

.3 조건적인 다이어그램 방법(Conditional diagramming methods) GERT(Graphical Evaluation and

Review Technique)과 시스템 역학모델에서는 loop(한번이상 반복되어야 하는 시험)나 conditional
branches(檢査를 통해 실수가 발견되었을 때에만 필요한 설계갱신) 등과 같은 비순서적인
액티비티를 참작할 수 있다(allow for). PDM과 ADM은 모두 loop 또는 conditional branches를
참작할 수 없다.

.4 네트워크 형판(型板) 표준화된 네트워크들은 프로젝트 네트워크 다이어그램의 준비를

촉진시키기 위해 사용될 수 있다. 그들은 전체 프로젝트 또는 단지 일부분을 포함할 수 있다.
네트워크의 부분들은 자주 subnet나 fragnet로 불려진다. Subnet들은 초고층 오피스 건물의
바닥판, 제약연구 프로젝트에서의 임상실험, S/W 프로젝트에서의 프로그램 module(기본치수) 등과
같은 프로젝트의 몇 개가 동일하거나 혹은 거의 동일하지 않은 것들을 포함하는 프로젝트에
유용하다.

6.2.3 액티비티 순서정하기의 결과물

.1 프로젝트 네트워크 다이어그램 이것은 프로젝트 액티비티들과 그들간의 논리적 관계(

상호관계)들을 개념적으로 보여주는 圖式이다. 그림 6-2와 6-3은 프로젝트 네트워크 다이어그램을
그리는 서로 다른 두 가지 방법을 보여준다. 프로젝트 네트워크 다이어그램은 손이나 컴퓨터로
그릴 수 있다. 이것은 전체 프로젝트의 세부사항을 포함할 수도 있고 하나 혹은 그 이상의 요약된

46 of 109
액티비티(hammocks)를 가질 수도 있다.
프로젝트 네트워크 다이어그램은 빈번히 PERT 圖라고 부적절하게 불려지기도 한다(Program
Evaluation and Review Technique). PERT 圖는 오늘날 거의 사용되지 않는 프로젝트 네트워크
다이어그램의 특정 형태이다.

.2 액티비티 목록 갱신 액티비티 定意과정이 WBS에 갱신을 불러일으키는 것과 상당히 유사하게

프로젝트 네트워크 다이어그램을 준비하는 동안 액티비티가 구분되어야 하는데, 그렇지 않을 경우
정확한 논리관계를 도식화하기 위해 재정의되어야 하는 실례를 보여줄 수도 있다.

6.3 액티비티 기간산정

액티비티 기간산정은 각각의 확인된 액티비티들을 완성하는데 필요할 것 같은 작업기간을

평가하는 것이다. 특정 액티비티의 성격을 가장 잘 아는 프로젝트 팀 내의 개인 혹은 그룹은
기간산정(estimate)을 하거나 최소한 승인해야 한다.
액티비티를 완성하는 데 필요한 작업기간을 산정할 때는 경과시간도 가끔 고려해야 한다. 예를
들면, 만약 "콘크리트 양생"이 4일을 필요로 한다면, (1)일주일의 어느 날에 시작할건지 (2)
주말이 작업기간으로 취급될 것인지 말 것인지를 기반으로 하여 2-4일의 작업기간을 요구할 수도
있다. 대부분의 컴퓨터화된 일정 S/W는 이 문제를 자동적으로 다룬다.
전체 프로젝트 기간은 여기에 제시된 도구 및 기법들을 이용하여 산정될 수 있으나, 일정도출의
결과로서 더욱 타당하게 계산된다(6.4 참조).

6.3.1 액티비티 기간산정에 대한 투입물

.1 액티비티 목록 6.1.3.1

.2 제약조건 6.1.1.4

.3 가정사항 6.1.1.5

.4 자원 요구조건 자원 요구조건들은 7.1.3.1에 설명되어 있다. 액티비티 대부분의 기간은

그들에게 할당된 자원에 의해 상당히 영향받는다. 예를 들면, 같이 일하는 두 사람은 그들 각자가
일할 때 드는 시간의 반정도 만에 설계 액티비티를 완성할 수 있다. 반면, 하나의 액티비티에
반정도의 시간을 일하는 한 사람은 일반적으로 전임으로 같이 일하는 두 사람 보다 최소한 2배는
더 일하게 될 것이다(협동이 좋다는 말).

.5 자원능력 대부분의 액티비티의 기간은 그들에게 할당된 인적·물적 자원의 능력에 상당한
영향을 받는다. 예를 들어 만약, 둘 모두가 전임으로(full-time) 할당되면 우수한 직원들은 통상

47 of 109
열등한 직원들보다 더 짧은 시간에 주어진 액티비티를 완성할 것으로 기대된다.

.6 역사적인 정보 많은 범주의 액티비티들의 가능한 기간에 대한 역사적인 정보는 다음의 하나

혹은 그 이상으로부터 이용가능하다.
·프로젝트 서류철(files): 프로젝트에 참여한 하나 혹은 그 이상의 조직들은 기간산정에
도움을 주기에 충분히 상세한 이전 프로젝트의 결과에 대한 기록을 유지할 것이다. 일부의
적용영역에서는 개별 팀원들이 그러한 기록을 보유하고 있을 것이다.
·상업 기간산정 D/B: 역사적인 정보는 가끔 상업적으로 이용가능하다. 이런 D/B들은
액티비티 기간들이 실제적인 작업내용에 의해 주도되지 않을 때 특히 유용한 경향이 있다(
콘크리트가 양생하는데 얼마나 걸리는가, 정부당국이 통상 특정형태의 요구에 응답하는데는
얼마나 걸리는가 등).
·프로젝트 팀의 지식: 프로젝트 팀의 개인들은 이전의 실상 및 예측을 기억하고 있을
수도 있다. 그러한 기억들이 유용한 반면에 통상 문서화된 것들 보다 신뢰성이 떨어진다.

6.3.2 액티비티 기간산정의 도구 및 기법

.1 전문가 판단 (5.1.2.2 참조). 기간에 영향을 미칠 수 있는 요소들이 많으므로 산정하기가

어려운 경우가 많다(자원평균, 자원생산성 등). 역사적인 정보에 의한 전문가의 판단은
가능할때는 항상 사용되어야 한다. 만약, 그런 경험이 이용가능하지 않다면, 기간산정은
본질적으로 불확실하고 위험이 많다(11장 리스크 관리 참조).

.2 유사(類似) 기간산정: Top-down 산정이라 불리기도 하는데, 미래의 액티비티 기간을 산정하는
기반으로서 이전의 유사한 액티비티의 실제기간을 이용하는 것을 의미한다. 이것은 프로젝트에
대한 상세정보의 量이 제한된 곳에서 프로젝트 기간을 산정하는데 빈번히 이용된다(
초기단계에서). 유사견적은 전문가 판단의 일종이다(6.3.2.1 참조)
유사견적은 (1)이전의 액티비티가 사실상 비슷하고 外見은 다를 때 (2)기간산정을 준비하는
개인이 필요한 경험을 지니고 있을 때 가장 신뢰할 만 하다.

.3 모의실험(Simulation) 모의실험에는 다양한 가정사항을 지닌채 다양한 기간을 산정하는 것이

포함된다. 가장 일반적인 것은 Monte Carlo Analysis인데, 그 속에서 가능성 있는 결과분포가 각
액티비티를 위해 정의되고, 전체 프로젝트에 대한 가능성 있는 결과분포를 계산하는데 이용된다
(11.2.2.3 참조)

6.3.3 액티비티 기간산정의 결과물

.1 액티비티 기간산정 액티비티를 완성하는데 필요한 작업기간을 정량적으로 평가하는 것이다.

액티비티 기간산정에는 가능한 결과의 범위에 대한 약간의 지수가 항상 포함된다. 예를 들면

48 of 109
다음과 같다.
·2주±2일: 액티비티가 최소 8일에서 12일까지를 필요로 할 때를 지시
·3주를 초과하는 15%의 확률: 액티비티가 3주 정도를 필요로 할 확률이 높을 때(85%)
11장의 프로젝트 리스크관리에서는 불확실성을 산정하는 더욱 상세한 논의가 있을 것이다.

.2 산정의 기초 산정할 때 만들어진 가정사항은 문서화되어야 한다.

.3 액티비티 목록 갱신 6.2.3.2 참조

6.4 일정 도출(SCHEDULE DEVELOPMENT)

일정도출은 특정 액티비티를 위한 시작 및 종료 날짜를 결정하는 것을 의미한다. 만약, 시작 및

종료 날짜가 현실적이지 않다면 프로젝트는 일정대로 종료되지 않을 것이다. 일정도출 과정은
프로젝트 일정을 결정하기에 앞서 가끔 반복되어야 한다(특히, 기간산정과 비용산정 등을
투입하는 과정과 함께).

6.4.1 일정도출에 대한 투입물

.1 프로젝트 네트워크 다이어그램 6.2.3.1

.2 액티비티 기간산정 6.3.3.1

.3 자원 요구조건 6.3.1.4

.4 자원 풀 설명(Resource Pool Description) 일정도출에는 어느 때, 어떤 형식의 무슨 자원이

이용가능한가에 대한 지식이 필요하다. 예를 들면, 특히 공유된 자원들은 그들의 유용성이 상당히
변하기 쉬우므로 일정을 잡기가 어렵다.
자원 풀 설명에서 상세한 양과 특이성의 정도는 변할 것이다. 예를 들면, 사람들은 컨설팅
프로젝트의 예비 일정도출에서는 단지 특정 시간의 틀에서 두 명의 컨설턴트가 이용가능 할
것이라는 것만을 알기를 원한다. 그러나, 동일 프로젝트의 최종일정에서는 특정의 컨설턴트의
이용가능성을 확인해야 한다.

.5 달력 프로젝트와 자원달력들은 작업이 부여되면 기간을 확인한다. 프로젝트 달력들은 모든

자원에 영향을 미친다(일부 프로젝트들은 단지 정상적인 영업시간에만 수행되는 반면, 다른
것들은 전임 3교대로 수행될 것이다). 자원달력들은 특정 자원 혹은 자원의 범주에 영향을 미친다
(프로젝트 팀원들은 휴가 중이거나 훈련 프로그램에 있을 것이고, 노무계약은 특정 작업원을
주간의 어느 날에 한정시킬 수도 있다).

49 of 109
.6 제약조건 (6.1.1.4 참조) 일정도출기간 동안 고려되어야 할 제약조건에 는 2개의 주요 범주가
있다.
·부과된 날짜: 특정 날짜에 의한 특정 성과물의 완공은 프로젝트의 후원자 및 고객,
기타의 외부요인들에 의해 요구될 수도 있다(기술 프로젝트에서의 시장 창구, 환경개선
프로젝트에서 법정에서 강제하는 완공일 등).
·핵심사건(key events) 및 주요 중간관리일: 정해진 날짜에 의한 특정 성과물의 완공은
프로젝트의 후원자 및 고객, 기타의 주요 참여자에 위해 요구될 수도 있다. 일단 일정이
계획되면, 이런 날짜들이 예상되어 가끔 어렵게 옮겨지기도 한다.

.7 가정사항 6.1.1.5 참조

.8 여유와 지연 상호관계의 어떤 것도 관계를 정확하게 정의하기 위해 여유 혹은 지연에 대한

명세서(시방서)를 요구할 수도 있다(장비의 주문과 설치 또는 사용간에는 2주간의 유예기간이
있을 수 있다).

6.4.2 일정도출의 도구 및 기법

.1 수학적인 분석 수학적인 분석에는 어떤 자원 풀 제한사항을 고려함이 없이 모든 프로젝트

액티비티를 위해 이론적인 조기 및 늦은 시작과 종료날짜를 계산하는 것이 포함된다. 결과로
도출된 날짜들이 일정이라기 보다는, 주어진 자원제한과 기타의 알려진 제약조건 내에서
액티비티가 계획되어야 할 기간을 지시한다. 대부분의 널리 알려진 수학적 분석기법은 다음과
같다.
·주공정 방법(Critical Path Method-CPM): 각 액티비티에 대한 단일의 결정적인 조기 및
늦은 시작이나 종료 날짜를 특정의 순서적인 네트워크 논리와 단일의 기간산정을 바탕으로
계산한다. CPM의 초점(핵심)은 액티비티가 일정상 최소한의 융통성을 갖도록 여유시간을 계산하는
것이다. 기본적인 CPM 연산(알고리듬)은 자주 다른 형태의 수학적인 분석에 사용된다.
·도식적인 검토 및 평가기법(GERT): 네트워크 논리와 액티비티 기간산정 모두를
확률적으로 취급할 수 있게 한다(어떤 액티비티는 전혀 수행될 수 없고, 어떤 것들은 단지
부분적으로 수행될 수 있으며, 또 다른 것들은 한번 이상 수행될 수 있다)
·프로그램 평가 및 검토 기법(Program Evaluation and Review Technique-PERT):
프로젝트 기간을 계산하기 위해 순차적인 네트워크 논리와 가중치가 부여된 평균계산을 활용한다.
비록, 피상적인 차이는 있지만, PERT는 CPM에서 원래 사용되는 최적의 계산 대신 배분의 평균(
기대 값)을 사용한다는 점에서 주로 CPM과는 다르다(그림 6-4). 비록 PERT와 비슷한 계산이
(estimate) CPM계산에서 가끔 사용되지만, PERT 그 자체는 오늘날 거의 사용되지 않는다.

.2 기간단축 기간단축은 프로젝트 범위를 변경하지 않고 프로젝트 일정을 단축하기 위한 방법을

50 of 109
모색하는 수학적 분석의 특별한 경우이다(주어진 날짜와 다른 일정 목표를 만족시키기 위해).
기간단축은 다음과 같은 기법을 포함한다.
·Crashing: 비용을 최소한으로 증가시키면서 어떻게 하면 최대한의 단축양을 얻을
것인가를 결정하기 위해 비용과 일정의 상호관계가 분석된다. Crashing은 항상 viable한 대안만을
가져다 주는 것은 아니고, 가끔 비용의 증가를 가져온다.
·Fast-tracking: 통상 순차적으로 수행될 액티비티들을 평행하게 하는 것(S/W
프로젝트에서 설계가 완성되기 전에 코드를 쓰기 시작하는 것, 정유공장에서 설계가 25%
진행되었을 때 기초공사를 시작하는 것). Fast-tracking은 가끔 재작업과 리스크의 증가를
가져온다.

.3 모의실험 6.3.2.3 참조

.4 자원 평준화(Resource leveling heuristics) 수학적인 분석은 가끔 특정 시간동안 이용가능한

것 보다 더 많은 자원을 요구하거나, 자원수준에서 관리할 수 없는 변화를 요구하는 예비일정을
만들어 낸다. "빈약한 자원을 주공정 작업에 먼저 할당한다"와 같은 경험은 그러한 제약조건을
반영하는 일정을 도출하는데 적용될 수 있다. 자원평준화는 가끔 프로젝트 기간이 예정일정보다
더 길어지는 결과를 가져온다. 이 기법은 때로 "자원기반 방법"으로 불리는데 특히, 컴퓨터를
통한 최적화로 수행될 때 그러하다.
자원의 제약을 받은 일정은, 관련된 경험이 이용가능한 자원의 양에 제한이 될 때 자원평준화의
특별한 경우가 된다(Resource constrained scheduling is a special case of resource leveling
where the heuristic involved is a limitation on the quantity of resources available).

.5 프로젝트 관리 S/W 프로젝트 관리 S/W는 일정도출을 지원하기 위해 널리 사용된다. 이런

생산물들은 수학적인 분석과 자원평준화의 계산을 자동화하여 많은 일정대안들이 신속하게
고려되도록 한다. 또한, 그들은 일정도출의 결과를 출력하거나 내보이는 데도 널리 사용된다.

6.4.3 일정도출의 결과물

.1 프로젝트 일정 프로젝트 일정에는 최소한 각 상세 액티비티에 대해 계획된 시작일 및 예기된

종료일이 포함된다(주의: 프로젝트 일정은 자원할당이 확실해지기 전까지는 예비적인 상태를
유지한다. 이것은 통상, 4.1절의 프로젝트 계획이 완전히 도출되기 전까지만 그렇다).
프로젝트 일정은 요약된 형태(master schedule) 또는 상세한 형태로 제시된다. 비록, 表의
형태로 나타날 수도 있지만, 통상은 아래의 형식 중 하나 혹은 그 이상의 것을 사용하여 圖式的
으로 표시된다.
·날짜정보가 추가된 프로젝트 네트워크 다이어그램(그림 6-5). 이런 차트들은 통상
프로젝트 논리와 프로젝트 주공정작업 모두를 보여준다(6.2.3.1 참조).
·바챠트(Fantt charts-그림 6-6)는 예상기간뿐만 아니라 액티비티의 시작 및 종료날짜를

51 of 109
보여준다. 그러나, 통상 상호관계를 보여주지는 않는다. 그들은 비교적 읽기도 쉽고, 관리
설명회에도 빈번히 사용된다.
·중간관리일 챠트(milestone charts-그림 6-7)은 바챠트와 유사하지만, 주요 성과물과
중요한 외부경계(external interfaces)들의 일정상의 시작 또는 완공을 확인한다.
·시간이 표시된 네트워크 다이어그램(그림 6-8)들은 프로젝트 네트워크 다이어그램들과
바챠트들을 섞어 놓은 것인데, 프로젝트 논리, 액티비티 기간, 일정정보 등을 보여준다.

.2 지원상세 프로젝트 일정정보를 위한 지원상세에는 최소한 확인된 모든 가정사항과 제약조건에

대한 문서화가 포함된다. 부가적인 상세의 양은 적용영역에 따라 달라진다. 예를 들면 다음과
같다.
·건설 프로젝트에서는 대체로 자원 히스토그램, 자금흐름 예측, 순서 및 조달 일정 등과
같은 항목들이 포함될 것이다.
·전자 프로젝트에서는 대체로 자원 히스토그램만 포함될 것이다.

지원상세로서 빈번히 제공되는 정보는 다음의 것들을 포함한다. 다만, 아래사항에 제한 받지는
않는다.
·일정 기간에 의한 자원 요구조건(빈번히 자원 히스토그램의 형태로)
·대안의 일정(최고/최악의 경우, 평준화 되거나/안된 자원, 부과된 날짜가 있든가/
없든가)
·일정연기 또는 일정리스크의 평가(11.3.3 참조)

.3 일정관리 계획 일정에 대한 변경이 어떻게 관리될 것인지를 정의한다. 프로젝트의 요구에

따라 공식적/비공식적일 수도 있고, 상당히 상세하거나 또는 광범위하게 구성될 수도 있다. 전체
프로젝트 계획의 부수적인 요소이다(4.1 참조).

.4 자원 요구조건의 갱신 자원평준화와 액티비티목록의 갱신은 자원 요구조건들의 예비산정에

중대한 영향을 미칠 수 있다.

6.5 일정관리

일정관리는 『(1)변경이 확실히 이득이 되도록 하기 위해 일정변경을 야기시키는 요인들에게

영향을 주고 (2)일정이 변경되었음을 결정하고 (3)변경이 발생함에 따라 실제 변경을 관리하는』
것 등과 관련된다. 일정관리는 4.3의 전반적인 변경관리에 설명된 기타의 관리과정과 철저하게
통합되어야 한다.

6.5.1 일정관리에 대한 투입물

52 of 109
.1 프로젝트 일정 (6.4.3.1 참조). 승인된 프로젝트 일정은 `일정기준선'이라 불리기도 하는데,
4.1.3.1에 설명된 전반적인 프로젝트 계획의 구성요소이다. 이것은 일정수행을 측정하고 보고하는
기준을 제공한다.

.2 수행보고서 (10.3.3.1 참조). 계획된 날짜가 충족되었거나 그렇지 않다는 등의 일정수행에

대한 정보를 제공한다. 수행보고서들은 프로젝트 팀이 미래에 문제를 야기시킬 사안들을 알도록
일깨워준다.

.3 변경요청서 구두/서면, 직접/간접, 외부발생/내부발생, 법적인 강제/선택적 등의 많은 형태로

발생한다. 변경들은 일정을 연장시키거나 촉진시킬 수 있다.

.4 일정관리 계획 6.4.3.3 참조

6.5.2 일정관리를 위한 도구 및 기법

.1 일정변경 관리시스템 프로젝트 일정이 변경될 수도 있는 절차를 정의한다. 변경을 승인하는데

필요한 서류작업, 공사추적시스템, 승인수준 등이 포함된다. 일정변경 관리는 4.3에 설명된
전체적인 변경관리 시스템과 통합되어야 한다.

.2 수행 평가(measurement) 10.3.2에 설명된 것과 같은 수행평가 기법들은 발생하는 모든

변동량의 크기를 평가하는 것을 돕는다. 일정관리의 중요한 부분은 일정의 변동량이 수정조치를
요구하는 가를 결정하는 것이다. 예를 들면, 주공정 혹은 주공정에 가까운 액티비티의 짧은
지연은 즉각적인 조치를 요구하는 반면, 非주공정 액티비티에 있어서의 주된 지연은 전체
프로젝트에 거의 영향을 미치지 않는다.

.3 부가계획 계획에 따라 정확하게 수행되는 프로젝트는 드물다. 장래의 가망성이 있는 변경들은

새롭거나 혹은 개정된 액티비티 기간산정, 변경된 액티비티 순서, 대안일정의 분석 등을
요구한다.

.4 프로젝트 관리 소프트웨어 (6.4.2.5 참조). 계획된 날짜 對 실제날짜를 추적하고, 일정변경

(실제 혹은 잠재적)의 효과를 예측하기 위한 프로젝트 관리 소프트웨어는 일정관리를 위한 유용한
도구가 된다.

6.5.3 일정관리의 결과물

.1 일정갱신 프로제트 관리에 이용되는 일정정보에 대한 모든 변경이다. 적절한 참여자들은

필요시마다 통지를 받아야 한다. 일정갱신은 전체 프로젝트 계획의 또 다른 측면에 조정을 할

53 of 109
수도 안할 수도 있다.
개정(변경-revisions)들은 일정갱신의 특별한 범주이다. 개정들은 승인된 프로젝트 일정속에서
일정상의 시작 및 종료날짜에 대한 변경이다. 이런 날짜들은 통상 범위변경에 대응하여서만
개정된다. 일부의 경우에, 일정지연은 너무 심각하여 "기준선 재조정-rebaselining"이 수행을
평가하기 위한 현실적인 자료를 제공하기 위해 필요하다.

.2 수정조치 예기되는 미래의 일정수행을 프로젝트 계획에 맞추기 위해 행하는 모든 것이다.

시간관리 영역에서의 수정조치는 가끔 공사촉진을 포함한다(공사촉진: 액티비티를 제시간에
완공하거나 또는 가능한 최소한의 지연을 위해 취해지는 특별 수정조치).

.3 경험적 교훈 차이의 원인, 선택된 수정조치 이면의 타당성, 기타 일정관리로부터 획득된

경험적 교훈의 형태들은 문서화되어 당해 프로젝트와 수행조직의 또 다른 프로젝트 모두를 위한
역사적인 D/B의 일부가 되어야 한다.

7장 프로젝트 비용 관리 (PROJECT COST MANAGEMENT)

프로젝트 비용관리는 승인된 예산안에서 프로젝트를 완성하는데 필요한 프로세스를 포함한다.

그림 7-1은 다음의 주요 프로세스에 대한 개요를 보여준다:
7.1 자원 계획(Resource Planning) - 프로젝트 액티비티를 수행하는데 어떤 자원(사람,
장비, 자재)을 얼마나 사용할 것인지 결정하는 것
7.2 비용 견적(Cost Estimating) - 프로젝트 액티비티를 완수하는데 필요한 자원에 드는
비용을 개략적으로 산정하는 것
7.3 비용 예산할당(Cost Budgeting) - 각 작업 아이템에 비용 견적을 할당하는 것
7.4 비용 조절관리(Cost Control) - 프로젝트 예산의 변화를 조절관리하는 것

이런 과정들은 각 프로세스끼리는 물론 다른 지식영역들의 프로세스들과도 상호작용을 한다. 각

프로세스는 프로젝트의 요구에 기반을 둔 개인이나 그룹의 노력과도 관련이 있다. 각 프로세스는
모든 프로젝트 단계에서 적어도 한번은 발생한다.
여기서 설명하고 있는 프로세스들이 비록 분리된 요소들로 보일 수도 있지만, 실제에 있어서는
서로 겹쳐지며, 상호작용을 한다. (3장 참조)
프로젝트 비용관리는 프로젝트 액티비티를 완수하는데 필요한 자원의 비용과 관련이 있다.
그러나 프로젝트 비용관리는 프로젝트 생산품의 이용에 드는 비용에 대한 의사결정의 영향도
고려해야 한다. 이런 광범위한 관점에서의 프로젝트 비용관리를 생애-주기 비용(life-cycle cost)
이라고 부른다.
많은 부분에서 프로젝트 생산품에 대한 미래 재정 수행을 예측하고 분석하는 것은 프로젝트 외의

54 of 109
일이다. 그러나 다른 부분(capital facilities project 같은)에서는 그런 일도 프로젝트
비용관리에 속한다. 그러한 예측과 분석이 포함된 프로젝트 비용관리는 부가적인 프로세스나 많은
일반적인 관리 기술을 포함하게 된다. 그런 것에는 투자금 상환(return on investment), 할인된
자금 흐름(discounted cash flow), 자본회수 분석(payback analysis) 등이 있다.
프로젝트 비용관리는 프로젝트에 관련된 사람들의 정보요구도 고려해야 한다. - 각 당사자들은
각기 다른 시간에 다른 방법으로 프로젝트 비용을 측정할 것이다. 예를 들면, 조달 아이템
(procurement item)의 비용은 그것을 위탁하거나(committed), 주문하거나, 배달하거나, 사고가
나거나, 계정의 목적으로 기록하고자 할 때 측정될 수 있다.
프로젝트 비용관리가 보상 및 인정시스템(9.3.2.3에서 설명)의 한 요소로 사용될 때는 보상이
실제 수행을 반영하도록 하기 위해 조절이 가능한 비용과 조절이 불가능한 비용을 분리해서
견적하고 예산을 할당해야 한다.
규모가 작은 프로젝트에서는 자원계획, 비용견적, 비용 예산할당이 아주 긴밀하게 연계되어
있어서 마치 하나의 프로세스처럼 보이기도 한다.(이것은 개인에 의해 비교적 단기간에 수행될 수
있다.) 각 프로세스의 도구와 기법이 서로 다르기 때문에 여기서는 각각 개별적인 프로세스로
설명할 것이다.

7.1 자원 계획 (Resource Planning)

자원계획은 프로젝트 액티비티를 수행하기 위해 어떤 자원(사람, 장비, 자재)을 얼마나 사용할

것인지 결정하는 것과 관련이 있다. 이것은 비용견적과 잘 조화를 이루어야 한다. 예를 들면:
·프로젝트팀은 그 지역 빌딩코드에 친숙해 질 필요가 있다. 그런 지식은 지역 노동자를
이용한다면 비용을 들이지 않고도 손쉽게 얻을 수 있다. 그러나 지역 노동 시장(labor pool)에
숙련자나 특수기술자가 없다면, 지역 빌딩코드의 지식을 확보하기 위한 가장 효과적인 방법은
컨설턴트에게 추가의 비용을 지불하는 것이 될 것이다.
·자동화 설계팀은 최근의 자동 조립기술에 친숙해야한다. 컨설턴트를 고용하거나, 설계자를
로봇공학의 세미나에 보내거나, 제조업으로부터 누군가를 영입하여 팀의 일원으로 만드는 것에
의해서 필수적인 지식을 얻을 수 있을 것이다.

7.1.1 자원계획의 입력자료

.1 작업 분류 체계. WBS란 자원이 필요한 프로젝트 요소를 확인하는 것이다. 때문에 자원계획의
기초적인 입력자료가 된다. 다른 계획 프로세스의 관련 결과물도 적절한 관리(control)를
위해서는 WBS를 통해서 제공되어야만 한다.

.2 역사적인 정보. 가능하다면 예전의 비슷한 프로젝트에서 요구되었던 자원의 형태가

무엇이었나를 고려해야 한다.

55 of 109
.3 범위 진술. 자원계획을 하는 동안 프로젝트의 정당성, 프로젝트의 목표를 명백히 밝혀야 한다.

.4 자원 집합(resource pool) 기술. 자원계획을 위해서는 어떤 자원이 이용될 수 있는 지 아는

것이 필요하다. 자원 집합 기술의 상세의 양과 특성의 수준은 다양할 수 있다.

.5 조직의 정책 임원을 구성하고, 장비 등을 빌리거나 구입하는 것에 대한 조직의 정책을

고려한다.

7.1.2 자원계획의 도구와 기법

.1 전문가 판단 전문가 판단은 이 프로세스의 입력자료를 평가하기 위해 필요하다. 이런

전문기술은 특별한 지식이나 훈련을 받은 개인 혹은 그룹에 의해서 제공되며, 다양한 곳에서
얻어진다:
·수행 조직의 다른 단위
·컨설턴트
·전문가 연합이나 기술자 연합
·산업 그룹

.2 대안의 확인

7.1.3 자원계획의 결과물

.1 자원 요구사항 자원계획 프로세스의 결과물은 WBS의 각 요소에 대해서 어떤 형태의 자원이

얼마나 필요할 것인지 묘사하는 것이다. 이런 자원은 임원 획득(staff acquisition)과 조달
(procurement)을 통해서도 얻어진다.

7.2 비용 견적

비용견적은 프로젝트 액티비티를 완수하는데 필요한 자원에 드는 비용을 개략적으로 산정하는

것과 관련이 있다.
프로젝트가 계약하에서 진행될 때는 비용견적(cost estimating)과 가격책정(pricing)을 구분하는
것이 중요하다. 비용견적은 예상되는 정량적인 결과에 대한 평가를 개발하는 것이다.- 수행조직이
관련된 생산품이나 서비스를 제공하는데 얼마나 비용이 들것인가?, 가격산정은 사업적인 결정이며
많은 고려사항 중 하나로 비용견적을 사용한다.- 수행조직이 생산품이나 서비스에 대해서 얼마나
값을 매길 것인가?
비용견적은 다양한 비용상의 대안을 확인하고 고려하는 것도 포함한다.

56 of 109
7.2.1 비용 견적의 입력자료

.1 작업 분류 체계

.2 자원 요구사항

.3 자원 비율 프로젝트 비용을 계산하기 위해서는 각 자원의 단위 비율을 알아야 한다.(시간당

임금, 입방야드당 자재비 등) 만약 실제 비율이 알려지지 않았다면, 비율 자체도 예측해야 한다.

.4 액티비티 기간산정 프로젝트 예산에 금융비용에 대한 것이 포함되어 있는 경우에는 액티비티

기간산정은 비용견적에 영향을 줄 것이다.

.5 역사적인 정보 다양한 범주의 자원에 대한 비용정보는 다음과 같은 곳에서 얻어진다.

·프로젝트 파일 - 하나 혹은 그 이상의 프로젝트 관련조직은 예전의 프로젝트에 대한
기록을 보유하고 있으며 이것은 비용을 견적하는 것을 도와줄 수 있다.
·상업적인 비용견적 데이터베이스
·프로젝트팀의 지식 - 프로젝트팀의 개인이 예전의 프로젝트에 대한 실제비용이나
견적을 기억하고 있을 수도 있다. 그런 기억은 유용한 반면, 기록에 비해서는 신뢰성이 떨어진다.

.6 계정에 대한 도표(Chart of accounts) 계정도표는 금융정보를 보고하기 위해 수행조직에

의해서 사용되는 코딩구조이다. 프로젝트 비용견적은 현재계정 범주에 할당되어야 한다.

7.2.2 비용견적에 사용되는 도구와 기법

.1 유사 견적(analogous estimating) top-down estimating이라고도 불리며 예전의 비슷한

프로젝트의 실제 비용을 이용해서 현재 프로젝트의 비용을 견적하는 방법을 말한다. 이것은
프로젝트에 대한 상세정보가 제한적일 경우(초기 단계) 프로젝트 총비용을 견적하는데 이용된다.
유사견적은 전문가 판단(7.1.2.1)의 한 형태이다.
유사견적은 비용은 적게 들지만 그 정확도는 떨어지는 편이다. 이 기법은 ⒜예전의 프로젝트가
그 외양뿐만 아니라 내용도 유사할 경우, ⒝견적을 준비하는 개인 혹은 그룹이 필요한 전문기술을
가지고 있는 경우에 가장 신뢰할 수 있다.

.2 Parametric modeling 이 기법은 프로젝트의 특징(parameters)을 이용한 수학적 모델로

프로젝트 비용을 예측하는 것이다. 모델은 간단할 수도 있고(주택의 평당 가격산정) 복잡할 수도
있다.(각각 5-7개씩의 point를 가진 13개의 분리된 조정요소를 이용하는 소프트웨어)
Parametric model의 비용이나 정확성은 매우 다양하다. 이 기법은 ⒜모델을 개발할 때 이용한
역사적 정보가 정확할 경우, ⒝모델에 사용된 파라메터가 정량적일 경우, ⒞모델이 scalable을

57 of 109
가지고 있는 경우(거대한 프로젝트나 소규모 프로젝트 모두에 적용할 수 있는)에 가장 신뢰할 수
있다.

.3 Bottom-up estimating 이것은 각 작업아이템의 비용을 견적해서 이를 합산하거나 rolling-up

하여 프로젝트 총비용을 구하는 기법이다.
이 기법의 비용과 정확성은 개별 작업아이템의 크기에 의해서 좌우된다. 작업아이템이 작을수록
비용과 정확성은 상승한다. 프로젝트팀은 부가적인 정확성과 부가적인 비용을 비교 검토해야 한다.

.4 Computerized tools 프로젝트 관리 소프트웨어나 스프레드시트 같은 도구가 비용견적에 널리

이용되고 있다. 그런 제품들은 위에서 설명한 기법들을 간편하게 이용하도록 해 줄 수 있으며,
많은 대안들을 빠르게 고려할 수 있도록 도와준다.

7.2.3 비용견적의 결과물

.1 비용 견적 비용견적은 프로젝트 액티비티를 완수하는데 필요한 자원에 소요될 것 같은 비용을

정량적으로 사정한 것이다. 이것은 요약해서 나타낼 수도 있고, 상세하게 나타낼 수도 있다.
프로젝트에 소요되는 모든 자원에 대한 비용이 견적되어야 한다. 이것에는 노동력, 자재,
공급품, 그리고 인플레이션 참작, 비용 유보(cost reserve) 등과 같은 특별한 범주의 것도
포함된다.
비용견적은 프로젝트 내에서의 비교나 프로젝트간의 비교를 쉽게 하기 위해서 일반적으로 단가
형식으로 표현된다.(달러, 프랑, 옌 등) 시급(staff hour)이나 일당(staff days) 등의 단위를
이용하지 않는다면 프로젝트 비용을 빠뜨릴 수도 있다. 어떤 경우에는 적절한 관리를 위해 복수의
단위가 사용되어야 할 때도 있다.
비용견적은 프로젝트 과정동안 부가되는 상세를 반영함으로써 개선(refine)될 수 있다. 실제에
있어서는 그런 개선(refinement)을 언제 해야 하며, 어느 정도 정확도를 기대할 수 있는지에 대한
지침이 있다. 예를 들면 AACE International 의 5가지 형태의 견적과정이 있다: order of
magnitude, conceptual, preliminary, definitive, control

.2 지원 상세 지원상세는 다음을 포함한다:

·견적작업의 범위에 대한 묘사. 주로 WBS의 참고문헌으로 제공된다.
·견적의 기초에 관한 문서.
·어떤 가정이 이루어졌는가에 관한 문서.
·가능한 결과에 대한 범위 지적.
부가적인 상세의 양과 형태는 적용현장에 따라 다양하다. 비록 개략적인 사항이라도 보유하고
있는 것이 가치 있는 것으로 판명될 수도 있다. 견적이 어떻게 개발되었는지 잘 이해되도록
해주기 때문이다.

58 of 109
 .3 비용관리 계획 비용관리 계획은 비용의 편차를 어떻게 관리할 것인가를 묘사한다. 비용관리
계획은 공식적일 수도 있고 비공식적일 수도 있다. 혹은 아주 상세할 수도 개략적일 수도 있는데
이는 관련당사자의 요구에 따른 것이다. 이것은 전반적인 프로젝트 계획의 보완적인 요소이다.
(4.1.3.1)

7.3 비용 예산할당(Budgeting)

비용 예산할당은 프로젝트의 수행을 측정하기 위한 비용 기준선(baseline)을 확립하기 위해 각

작업 아이템에 비용 견적을 할당하는 것과 관련이 있다.

7.3.1 비용 예산할당의 입력자료

.1 비용 견적
.2 작업분류체계
.3 프로제트 스케줄 프로젝트 스케줄은 앞으로 비용이 할당될 프로젝트 요소에 대한 계획된
시작일과 예상되는 종료일을 포함한다. 이것은 비용이 발생하는 기간에 비용을 할당하기 위해서
필요한 정보이다.

7.3.2 비용 예산할당의 도구와 기법

.1 비용견적 도구와 기법 (7.2.2)

7.3.3 비용 예산할당의 결과물

.1 비용 기준선(baseline) 비용 기준선은 프로젝트의 비용수행을 측정하고 관찰하는데 사용될

시간단계별 예산이다. 이것은 기간별 견적비용을 합산함으로써 만들어지며 그림 7-2처럼 주로 S자
곡선의 형태이다.
대규모 프로젝트에서는 다른 측면의 비용수행을 측정하기 위한 복수의 비용 기준선을 가질 수도
있다. 예를 들면 지출계획이나 자금흐름예측은 지불금을 측정하기 위한 비용기준선이다.

7.4 비용 조절관리

비용 조절관리는
⒜변화가 유용한 것이라는 확신에 의해 비용 기준선을 변경하는 요소를 반영하는 것,
⒝변경된 비용기준선을 결정하는 것,
⒞실제 변경이 발생했을 경우 이를 관리하는 것과 관련이 있다.

59 of 109
비용 조절관리는 다음을 포함한다:

·계획과의 편차를 추적하기 위해 비용수행을 관찰하는 것

·모든 변경이 비용기준선에 정확하게 기록되었는지 확인하는 것
·부정확하고, 부적절하며, 인정받지 못한 변경이 비용기준선에 포함되지 않도록 하는 것
·인정된 변경에 대해 관련당사자가 잘 알 수 있도록 하는 것

비용관리는 "도대체 왜" 긍정적인 편차나 부정적인 편차가 발생하는가를 찾아내는 것과도 관련이
있다. 이것은 다른 조절관리 프로세스와도 완전하게 통합되어야 한다. 예를 들어 비용 편차에
대한 부적절한 대응은 후에 품질문제나 일정문제를 야기시킬 수도 있고, 받아들일 수 없을 정도의
리스크를 초래할 수도 있다.

7.4.1 비용 조절관리의 입력자료

.1 비용 기준선

.2 수행 보고서 수행보고서(10.3.3.1)는 예산이 적절했는지 그렇지 않았는지 와 같은 비용수행

정보를 제공한다. 또한 수행보고서는 프로젝트팀이 미래에 발생할 문제의 원인이 되는 사건에
대해 경고하도록 한다.

.3 변경 요청 변경요청은 다양한 형태로 발생한다.- 구두로 혹은 서면으로, 직접적으로 또는

간접적으로, 외부의 원인에서 혹은 내부의 원인에서, 법적인 명령일 수도 혹은 선택적일 수도
있다. 변경은 예산을 증가시킬 수도 있으며 감소시킬 수도 있다.

.4 비용 관리 계획

7.4.2 비용 조절관리의 도구와 기법

.1 비용변화 조절 시스템 이것은 비용기준선을 변경하는 것에 대한 절차를 규정한다. 이것은

사무 처리, 시스템의 추적, 변경을 인정하는데 필요한 승인의 수준 등을 포함한다. 이 비용 조절
시스템은 4.3에서 언급한 전반적인 변경조절 시스템과 통합되어야 한다.

.2 성능 측정 10.3.2에서 설명할 성능 평가 기술은 발생한 편차의 중대함을 평가하는 것을

도와준다. 10.3.2.4에서 설명할 실행기성(Earned Value)은 비용조절관리에 매우 유용하다.
비용관리에 있어서 중요한 점은 편차가 어떤 원인에 의해서 발생했으며, 편차가 개선작업을
필요로 하는지 아닌지를 결정하는 것이다.

60 of 109
 .3 부가적인 계획 계획된 그대로 진행되는 프로젝트는 거의 없다. 예상되는 변경은 새롭거나
수정된 비용견적 혹은 대안의 분석을 필요로 한다.

.4 Computerized tools 프로젝트 관리 소프트웨어나 스프레드시트 같은 도구는 계획된 비용과

실재 비용을 비교(track)하는 데 사용되며, 비용변화의 영향을 예측하는데도 사용되다.

7.4.3 비용 조절관리의 결과물

.1 개정 비용견적 개정 비용견적은 프로젝트를 관리하는데 이용되는 비용정보에 대한 수정이다.

필요하다면 관련당사자에게 통지해야 한다. 개정 비용견적은 전체 프로젝트 계획 중 어떤 측면의
조정을 필요로 할 수도 있고, 그렇지 않을 수도 있다.

.2 예산 갱신 예산 갱신은 개정 비용견적의 특별한 범주이다. 이것은 승인된 비용 기준선에 대한

변경이다. 이 수치는 일반적으로 범위 변경에 의해서만 수정된다. 어떤 경우에는 비용 편차가
너무 심해서 실제적인 수행을 측정하기 위해서는 "rebaselining"이 필요할 수도 있다.

.3 수정 작업 수정작업은 미래의 수행을 계획대로 맞추기 위한 행동이다.

.4 완성시의 비용견적 완성시의 비용견적(EAC)은 프로젝트의 수행에 기초해서 프로젝트 총비용을

예측한 것이다. 일반적인 방법에는 몇가지가 있다:
·EAC = 현재까지의 실제비용 + 수행 요소(performance factor)에 의해 수정된 남아있는
프로젝트 예산. 비용 수행 지수는 10.3.2.4에서 설명한다. 이 방법은 현재의 편차가 앞으로
일어날 편차의 전형(typical)처럼 보여질 때 가장 많이 사용된다.
·EAC = 현재까지의 실재비용 + 남아있는 모든 작업에 대한 새로운 프로젝트 예산. 이
방법은 원래 견적 할 때의 가정이 기본적으로 결점이 있거나 상황의 변화로 인해 더 이상 적절한
것이 아님을 과거의 수행이 보여줄 때 가장 많이 사용된다.
·EAC = 현재까지의 실재비용 + 남은 예산. 이 방법은 현재의 편차가 전형적인 것이
아니며 프로젝트팀이 그러한 편차가 미래에 발생하지 않을 것이라고 했을 때 가장 많이 사용된다.

.5 교훈 편차의 원인, 수정작업의 선택이유, 그리고 비용 조절관리에서의 기타 교훈들은

문서화되어 역사적인 데이터베이스가 되어야 한다. 이는 해당 프로젝트 뿐 아니라 수행조직이
담당한 다른 프로젝트를 위해서도 그리해야 한다.

8장 프로젝트 품질 관리 (PROJECT QUALITY MANAGEMENT)

프로젝트 품질관리는 프로젝트가 요구하는 사항을 만족시키기 위해 필요한 프로세스를 포함한다.

그것은 품질의 방침, 목표, 책임과 수행 등을 결정하는 관리기능의 모든 행위를 포함하며, 이는

61 of 109
품질계획, 품질관리(QC), 품질보증, 품질개선 등의 품질 시스템을 통해 이루어진다. 그림 8-1은
다음의 주요 프로세스에 대한 개요를 보여준다:
8.1 품질 계획(Quality Planning) - 어떤 품질 표준이 프로젝트에 적합한 것인지
확인하고, 어떻게 그것을 만족시킬 것인지 결정하는 것
8.2 품질 보증(Quality Assurance) - 프로젝트가 적합한 품질표준을 만족할 것이라는
확신을 주기 위해 정식적으로 프로젝트 수행을 평가하는 것
8.3 품질 관리(Quality Control) - 프로젝트가 적합한 품질표준을 따르고 있는지
결정하기 위해 프로젝트의 결과를 관찰하는 것, 그리고 불만족스러운 수행의 원인을 제거하는
방법을 확인하는 것

이런 과정들은 각 프로세스끼리는 물론 다른 지식영역들의 프로세스들과도 상호작용을 한다. 각

프로세스는 프로젝트의 요구에 기반을 둔 개인이나 그룹의 노력과도 관련이 있다. 각 프로세스는
모든 프로젝트 단계에서 적어도 한번은 발생한다.

여기서 설명하고 있는 프로세스들이 비록 분리된 요소들로 보일 수도 있지만, 실제에 있어서는

서로 겹쳐지며, 상호작용을 한다. (3장 참조)

이번 장에서 설명하고 있는 품질관리의 기본적인 접근방식은 ISO의 ISO 9000과 10000 시리즈의
표준과 지침에 부합하도록 되어있다. 또한 이런 일반화된 접근방식은 ⒜Deming, Juran, Crosby
등에 의해 추천된 proprietary 품질관리 접근방식과 ⒝TQM, 지속적인 개선(Continuous
Improvement) 등과 같은 non-proprietary 품질관리 접근방식 모두와 부합되어야 한다2.
프로젝트 품질관리는 프로젝트의 관리와 프로젝트의 생산품 양자 모두를 다루어야 한다. 모든
범위에서의 품질요구사항을 만족시키지 못하면, 프로젝트 관련당사자에게 부정적인 결과를 가져올
수도 있다. 예를 들면:
·프로젝트팀에게 과도한 일을 부과하여 소비자의 요구를 만족시키는 것은 고용비용 증가라는
형태의 부정적인 결과를 초래할 수 있다.
·급하게 계획된 품질검사를 시행하여 프로젝트 일정 목표를 만족시키는 것은 발견되지 않았던
오류가 드러나는 경우 부정적인 결과를 초래할 수 있다.

품질이란 "규정되었거나 암시되었던 요구사항을 만족시키기 위한 능력과 관련된 것들이 가진

특성의 총합"이다. 프로젝트 문맥에서의 품질관리의 주요한 측면은 암시되었던 요구사항을
프로젝트 범위관리를 통해 명백히 규정된 요구사항으로 변환시킬 필요가 있다는 것이다. 이것은 5
장에서 다루었다.
프로젝트팀은 품질(quality)과 등급(grade)을 혼동치 않아야 한다. 등급(grade)이란 "같은
기능적 쓰임을 가지고 있지만 품질에 대해서는 다른 요구사항을 가진 것들에 주어지는 구분이나
등위"이다. 낮은 품질은 항상 문제가 되지만, 낮은 등급은 그렇지 않을 수도 있다. 품질과 등급에
요구되는 수준을 결정하고 이를 조달하는 것은 프로젝트관리자(PMr)이나 프로젝트팀의 책임이다.

62 of 109
 프로젝트팀은 현대의 품질관리가 프로젝트관리와 상호보완적이라는 것을 알아야만 한다. 예를
들면 두 분야 모두 다음을 중요하게 취급한다:
·고객의 만족도 - 고객의 요구사항을 이해하고, 관리하며, 이를 반영해서 고객의 기대를
만족시키거나 그 보다 더 잘하는 것. 이것은 시방에의 순응성(conformance to specifications)과
이용에의 적합성(fitness for use)의 결합을 필요로 한다.
·검사보다 예방 - 실수를 피하기 위한 비용은 이를 개선하는 비용보다 항상 적은 법이다.
·관리 책임 - 성공을 위해서는 팀의 모든 멤버들이 참가해야 한다. 그러나 성공을 위해 필요한
자원을 공급하는 것은 팀의 책임이다.
·단계 안에서의 프로세스 - 계획-실행-검사-조치(plan-do-check-act) 사이클의 반복은 3장에서
설명한 프로세스와 단계의 결합과 무척 유사하다.

또한, 수행조직에 의해서 이루어지는 품질개선의 착수는 프로젝트 생산품의 품질뿐만 아니라
프로젝트관리의 품질까지도 향상시킨다.
그러나 프로젝트팀이 확실하게 알아야할 중요한 차이점이 있다. - 프로젝트가 임시적이라는
사실은 생산품의 품질 향상에 대한 투자가 수행조직에 의해서 이루어져야 한다는 것을 의미한다.
왜냐하면 프로젝트는 보상을 받을 정도로 충분히 오랫동안 남아있지 않기 때문이다.

8.1 품질 계획 (Quality Planning)

품질계획은 어떤 품질 표준이 프로젝트에 적합한 것인지 확인하고, 어떻게 그것을 만족시킬

것인지 결정하는 것과 관련이 있다. 이것은 프로젝트 계획 프로세스의 주요 지원프로세스
(facilitating process)이며(3.3.2), 규칙적으로 수행되어야 하고, 다른 계획프로세스와 병행하여
수행되어야 한다. ISO 9000 시리즈가 개발되기 전에는, 여기서 품질 계획으로 표현되고 있는
활동들은 품질 보증의 한 부분으로 논의되었었다.
여기서 설명하는 품질계획 기법은 프로젝트에서 가장 빈번하게 사용되는 것들이다.
프로젝트팀은 현대 품질관리의 기본적인 주의(主義)에 대해서 알고 있어야 한다. - 품질은
검사되는 것이 아니라 계획되는 것이다.

8.1.1 품질계획의 입력자료

.1 품질 방침 품질방침이란 "최고 경영진에 의해서 공식적으로 표현된 품질에 대한 조직의

전반적인 의도나 방향"이다. 수행조직의 품질방침이 프로젝트에 "그대로" 받아들여질 수도 있다.
그러나 수행조직이 공식적인 품질방침을 가지고 있지 않거나 프로젝트가 복수의 수행조직과
관련되어 있을 경우에는 프로젝트팀이 품질방침을 개발할 필요가 있다.
품질방침이 어디에서 유래하였건, 프로젝트팀은 관련당사자 모두가 이 품질방침에 대해 잘 알 수
있도록 해야한다.

63 of 109
.2 범위 진술 (5.2.3.1)

.3 생산품 설명 이것은 범위진술의 한 요소이지만(5.1.1.1) 품질계획에 영향을 줄 수 있는

사항이나 기술적인 문제 등의 상세를 설명하기도 한다.

.4 표준과 규정(Standards and regulations) (2.5.1)

.5 다른 프로세스의 결과물

8.1.2 품질계획의 도구와 기법

.1 Benefit/cost 분석 5.2.2.2 참조. 품질요구를 만족시키는 것의 기본적인 이득은 재 작업이

적어지는 것이다. 이것은 높은 생산성, 낮은 비용, 관련당사자의 만족도 증가 등을 의미한다.
품질요구를 만족시키는 것의 기본적인 비용은 프로젝트 품질관리 활동과 관련된 지출이다.
비용보다 이득이 커야 하는 것은 자명한 것이다.

.2 Benchmarking 벤치마킹은 개선을 위한 아이디어를 창출하거나, 수행을 평가하기 위한 기준을

제공하기 위해 당해 프로젝트의 실재상황이나 계획을 다른 프로젝트와 비교해 보는 것이다. 다른
프로젝트는 같은 수행조직에 의해서 진행된 것일 수도 있고 아닐 수도 있으며, 같은 적용분야일
수도 있고 아닐 수도 있다.

.3 Flowcharting 플로우차트는 시스템의 요소들이 어떻게 관련되어 있는가를 보여준다.

·특성요인도(Cause-and-effect diagrams) - Ishikawa diagrams 혹은 fishbone diagrams
라고 불리며, 잠재적인 문제점이나 어떤 결과에 대한 다양한 원인들을 보여준다. 그림 8-2
·System or process flowcharts - 시스템의 요소들이 어떻게 관련되어 있는가를
보여준다. 그림 8-3
플로우차트는 품질문제가 어디서 어떻게 발생할 것인지 프로젝트팀이 예측하는 것을 도와주며,
이를 적절하게 취급하는 방법을 개발하는 것도 도와준다.

.4 실험의 설계 실험의 설계는 다양한 변수 중에 어떤 것이 전반적인 결과에 가장 영향을

미치는지 확인하는 것을 도와주는 분석기법이다. 이것은 프로젝트 생산의 문제에 가장 빈번하게
사용되는 기법이다.
그러나 이것은 비용과 일정의 상관분석(trade-offs)같은 프로젝트 관리의 문제에 대해서도
적용할 수 있다. 적절히 설계된 "실험"은 그 경우의 수가 제한적일 때에는 최적의 해법을
결정하는 것을 허가한다.

64 of 109
8.1.3 품질계획의 결과물

.1 품질관리 계획 품질관리계획은 프로젝트팀이 품질방침을 어떻게 수행할 것인지를 설명해야

한다. ISO 9000 용어법에서는, 프로젝트 품질 시스템을 설명해야 한다: "품질관리를 위해 필요한
조직 구조, 책임, 절차, 프로세스, 자원 등"
품질관리계획은 전체 프로젝트 계획의 입력자료를 제공한다. 그리고 품질관리(QC), 품질보증
(QA), 품질개선에 대해서도 언급해야 한다.
품질관리계획은 공식적일 수도 있고 비공식적일 수도 있으며, 상세할 수도 있고 개략적일 수도
있다. 이는 프로젝트의 요구에 따라 다르다.

.2 운영상의 정의(Operational definitions) 운영상의 정의는, 매우 특별한 용어로, 품질 관리

(QC) 프로세스를 통해서 무엇을 측정할 것이며, 또한 어떻게 측정할 것인가를 설명한다. 예를
들어, 계획된 일정을 만족하는 것만으로는 관리품질을 측정할 수 없다; 프로젝트팀은 모든
액티비티들이 제시간에 시작했는지, 아니면 종료만 제시간에 이루어졌는지를 표현해야한다; 혹은
각각의 액티비티들을 측정할 것인지 아니면 특정한 성과물만 측정할 것인지 표현해야한다. 어떤
곳에서는 운영상의 정의를 메트릭스(metrics)라고 부르기도 한다.

.3 체크리스트 체크리스트는 수행되었어야 하는 일련의 단계를 수정하기 위해 사용되는 구조화된

도구이다. 이것은 단순할 수도 있고, 복잡할 수도 있다. 이것은 주로 명령형(이것을 하라!)이나
의문형(이것을 했는가?)의 형태로 나타난다. 많은 조직들이 수행된 액티비티가 모순이 없는가를
확인하는 기준이 되는 체크리스트를 보유하고 있다. 어떤 곳에서는 이것이 전문가조직이나 상업적
서비스 제공자에 의해 이루어질 수도 있다.

.4 다른 프로세스로부터의 결과물

8.2 품질 보증

품질보증이란 프로젝트가 적합한 품질표준을 만족할 것이라는 확신을 주기 위해 품질 시스템에서

이루어지는 모든 계획되고 체계화된 활동을 말한다. 이것은 프로젝트 내내 수행되어야 한다. ISO
9000 시리즈가 개발되기 전에는, 품질계획에서 설명된 활동들이 품질보증의 한 부분으로
포함됐었다.
품질보증은 품질보증 부서나 이와 유사한 명칭을 가진 조직단위에 의해서 제공되지만, 꼭 그래야
하는 것은 아니다.
보증은 프로젝트팀이나 수행조직에 의해서 제공될 수도 있고(내부적 품질보증), 고객이나
프로젝트의 작업과 직접적으로 관련이 없는 당사자들에 의해서 제공될 수도 있다(외부적
품질보증).

65 of 109
8.2.1 품질보증의 입력자료
.1 품질관리 계획
.2 품질 관리(QC) 측정의 결과치
.3 운영상의 정의

8.2.2 품질보증의 도구와 기법

.1 품질계획의 도구와 기법

.2 품질감사(Quality audits) 품질감사는 다른 품질관리 활동을 구조적으로 검토하는 것이다.

이것의 목적은 당해 프로젝트나 혹은 당수행조직에 의해 진행되는 다른 프로젝트의 성능을
개선시킬 수 있는 교훈을 확인하기 위한 것이다. 품질감사는 일정에 따라 할 수도 있고,
무작위적으로 할 수도 있다. 또한 내부사원에 의해서 이루어질 수도 있고, 제 3자에 의해서
이루어질 수도 있다.

8.2.3 품질보증의 결과물

.1 품질 향상 품질향상은 프로젝트 관련당사자에게 부가의 이득을 제공하기 위해서 프로젝트의

효율성을 증가시키려는 조치를 취하는 것을 포함한다. 어떤 경우에선, 품질 개선의 시행은
변경요청이나 개선조치를 필요로 할 수도 있다. 그리고 품질개선은 전체 변경 관리(change
control)의 절차에 따라 이루어져야 한다.(4.3)

8.3 품질 관리 (Quality Control)

품질관리(QC)는 프로젝트의 결과들이 관련 품질기준을 따르는 지를 결정하기 위해 프로젝트

결과를 관찰하고 불만족스런 결과의 원인을 제거하기 위한 방법을 규명하는 것을 포함한다.
이것은 프로젝트 내내 수행되어야 한다. 프로젝트의 결과는 성과물(deliverables)과 같은
생산결과(product results)와 비용과 일정수행과 같은 관리결과(management results) 양자를
포함한다. 품질관리는 종종 품질관리부서 또는 비슷한 이름의 조직에 의해 수행되지만, 그렇지
않을 수도 있다.
프로젝트 관리팀은 품질관리 결과물을 평가하는데 도움을 주는 통계적 품질관리의 업무지식
(working knowledge), 특히 표본조사(sampling-이하 샘플링)와 확률(probability) 등을 알고
있어야 한다. 그들은 여러 주제들 사이의 다음과 같은 차이점들을 알고 있어야 한다.

·예방(프로세스에서 오류를 제거)과 검사(소비자에게서 오류를 제거)

·특성 샘플링(결과는 합치하거나 일치하지 않는다)과 가변 샘플링(결과는 일치의 정도를
측정하는 연속적인 scale로 나타난다)

66 of 109
·특수한 원인(색다른 사건)과 무작위적 원인(일반적인 프로세스의 편차)
·허용치(결과가 허용치로 규정된 범위내에 있다면 그 결과를 인정)와 관리한계(결과가
관리한계내에 있다면 그 프로세스는 통제하에 있다)

8.3.1 품질관리(QC)의 입력자료

.1 작업결과(Work results) 작업결과는 프로세스 결과와 생산결과 양자를 포함한다. 계획 또는

예상 결과에 대한 정보는 실제 결과에 관한 정보와 함께 활용되어야 한다.

.2 품질관리계획(Quality management plan) 8.1.3.1

.3 운영상의 정의(Operational definitions) 8.1.3.2

.4 체크리스트(Checklists) 8.1.3.3

8.3.2 품질관리(QC)에 사용되는 도구와 기법

.1 검사(Inspection)

검사는 결과가 요구조건들을 따르는지를 결정하기 위한 측정(measuring), 시험(examining), 실험

(testing)과 같은 활동을 포함한다. 검사는 어떤 수준에서도 이루어질 수 있다(예를 들면, 단일
액티비티의 결과가 검사될 수도 있고, 프로젝트의 최종생산물이 검사될 수도 있다). 검사는 검토
(reviews), 생산검토(product reviews), 감사(audits), walk-throughs 등과 같이 다양한 이름으로
불린다. 어떤 응용분야에서는 이들 용어는 협의의 특별한 의미를 가진다.

.2 관리도(Control charts)

관리도는 프로세스의 결과와 경과시간의 그래픽 디스플레이이다. 관리도는 프로세스가 통제하에

있는가의 여부를 결정하기 위해 사용된다.(예를 들면, 확률변수에 의해 만들어진 결과에 차이점이
있는가 또는 그 원인이 규정되고 수정되어야만 하는 유별난 사건이 발생하는가?). 프로세스가
통제하에 있다면, 그 프로세스는 조정되지 않아야 한다. 개선하기 위해서 프로세스가 변경될 수도
있지만, 프로세스가 통제하에 있다면 조정되지 않아야 한다.
관리도는 다양한 결과물을 관찰하기 위해 사용되기도 한다. 제조롯트와 같은 반복적인
액티비티를 추적하는데(track) 가장 많이 사용되기는 하지만, 관리도는 PM프로세스가 통제하에
있는지의 여부를 결정하는데 도움을 주도록 비용과 일정의 변동, 범위변경의 규모와 빈도,
프로젝트 문서의 오류, 또는 다른 관리결과 등을 관찰하는데 사용될 수도 있다. 그림 8-4는
프로젝트 일정수행에 대한 관리도이다.

67 of 109
.3 파레토도(Pareto diagrams)

파레토도는 발생빈도순으로 정렬된 히스토그램인데, 규명된 원인의 유형 또는 범주에 의해

얼마만한 결과가 발생되었는지를 보여준다(그림 8-5). 정열순서는 수정조치의 지침으로 사용된다.
프로젝트팀은 우선 가장 큰 결점의 원인이 되는 문제들을 해결하기 위한 조치를 취해야 한다.
파레토도는 개념적으로 파레토의 법칙과 관련되는데 파레토의 법칙은 상대적으로 적은 수의
원인이 일반적으로 대다수의 문제나 결점들을 만들어낸다는 것이다.

.4 통계샘플링(Statistical sampling)

통계샘플링은 검사에 있어서 모집단의 일부를 선정하는 것을 포함한다(예를 들면, 75개의

엔지니어링 도면으로부터 랜덤으로 10개를 추려내는 것). 적절한 샘플링은 종종 품질관리의
비용을 낮출 수 있다. 통계샘플링에는 상당한 지식체계가 있다. 어떤 응용분야에서는 PM팀이
다양한 샘플링 기법에 정통해야 할 필요가 있다.

.5 플로우차트(Flowcharting)

(8.1.2.3) 플로우챠트는 어떻게 문제점들이 발생하는가를 분석하는데 도움을 주기 위해

품질관리에 사용된다.

.6 추세분석(Trend analysis)

추세분석은 역사적 결과에 기반하여 미래 결과물을 예측하는 수학적 기법을 사용하는 것이다.
추세분석은 종종 다음을 관찰(monitor)하기 위해 사용된다.
·기술적 수행(Technical performance)-얼마나 많은 오류나 결점들이 규명되었고, 얼마나
많은 것들이 수정되지 않은 채로 남아있는가.
·비용과 일정 수행(Cost and schedule performance)-단위기간(period)당 얼마나 많은
액티비티들이 주요한 변수를 지닌 채 완수되었는가.

8.3.3 품질관리(QC)의 결과물

.1 품질향상(Quality improvement) 8.2.3.1

.2 승인결정(Acceptance decisions) 검사된 항목들은 승인되든지 거절되든지 할 것이다. 거절된

항목들은 재작업을 필요로 할 것이다.(8.3.3.3에서 설명)

68 of 109
.3 재작업(Rework) 재작업은 결함이 있는 항목이나 조건에 따르지 않는 항목들을 요구조건이나
시방서에 따르도록 하는 조치이다. 재작업, 특히 예상하지 못한 재작업은 대개의 응용분야에서
프로젝트 초과비용(project overruns)의 주요 요인이다. 프로젝트팀은 재작업을 최소화하기 위해
가능한 모든 합리적인 노력을 해야 한다.

.4 완성 체크리스트(Completed checkists) 8.1.3.3 체크리스트가 사용되면, 완성 체크리스트는

프로젝트 기록의 일부가 되어야 한다.

.5 프로세스 조정(Process adjustments) 프로세스 조정은 품질관리측정(quality control

measurements)의 결과로서, 즉각적인 수정조치나 예방조치를 포함한다. 몇몇 경우에, 프로세스
조정은 4.3에서 설명된 전반적인 변경관리에 대한 절차에 따라서 다루어져야 할 수도 있다.

9장 프로젝트 인적자원관리(PROJECT HUMAN RESOURCE MANAGEMENT)

프로젝트 인적자원 관리는 프로젝트에 참여한 사람들을 가장 효과적으로 이용하는 데 필요한

절차를 포함하고 있다. 또한 모든 프로젝트 관련자(stakeholder) - 스폰서, 고객, 기여자 및 2.2
에서 설명한 기타 사람들 - 를 포함한다.

9.1 조직 계획 Organizational Planning - 프로젝트 역할, 책임 및 보고관계를 파악, 문서화,

할당
9.2 임(직)원 확보 Staff Acquisition - 인적자원을 프로젝트에 배치하여 작업 수행
9.3 팀 개발 Team Development - 프로젝트 성능(실행)을 향상시키기 위해 개인 및 집단 기술
개발

이들 절차들은 서로간에 그리고 다른 지식 영역의 절차와 상호작용 한다. 각 프로세스는 한 사람

또는 그 이상, 또는 프로젝트의 필요에 의한 집단을 포함할 수도 있다. 비록 여기에서는 그
절차가 잘 정의된 별개의 요소로서 제시되었지만 실제로 그것들은 중복되고 상호작용 할 수 있다.
프로세스 상호작용은 제3장에서 자세히 논의되었다.

사람을 다루는 일부 주제는 다음과 같다.

2.4절 주요 일반관리기술에서 기술된 논의된 지도(leading), 의사소통, 협상 및 기타
개인을 다루는 것과 관련된 (권한)위임, 동기부여, 지도, 교육 및 기타
집단을 다루는 것과 관련된 팀 구성, 갈등 관리, 기타
인적 자원을 관리하는 것과 관련된 성능평가, 채용, 유보, 노무관계, 안전 및 보건 규제, 기타
주제

이러한 대부분의 주제는 프로젝트의 사람을 지도, 관리하는 데 직접적으로 적용할 수 있으며 PMr

69 of 109
와 PM팀은 이러한 것을 잘 알아야 한다. 그러나 이러한 지식을 프로젝트에 적용하는 방법에
대해서도 잘 알고 있어야 한다. 예를 들어
프로젝트의 임시적인(temporary) 성격은 대인 및 조직적 관계가 일반적으로 임시적이고 새롭다는
것을 의미한다. PM팀은 그러한 임시적인 관계에 적정한 기법을 선정하는데 주의를 기울여야 한다.
프로젝트 관련자들의(stakeholder) 성격과 수는 종종 프로젝트가 라이프사이클의 각 단계로
진행됨에 따라 변할 것이다. 그 결과 한 단계에서 효과적인 기법은 다른 단계에서 효과적이지
않을 수 있다. PM팀은 프로젝트의 현재 필요에 적당한 기법을 이용하는 데 주의를 기울여야 한다.
인적자원관리 액티비티는 PM팀의 직접적인 책임은 아니다. 그러나 PM팀은 이에 따르도록 관리
요건을 충분히 알고 있어야 한다.

4.1 조직 계획 Organizational Planning

조직 계획은 프로젝트의 역할, 책임, 보고 관계를 확인, 문서화, 할당하는 것을 의미한다. 역할,
책임 그리고 보고 관계는 개인 또는 집단에 할당될 수 있다. 개인 및 집단은 프로젝트 수행
조직의 일부일 수도 있으며 또는 그런 조직의 외부일 수도 있다. 종종 내부 집단은 엔지니어링,
마케팅, 회계와 같은 특정한 기능적 부서와 관련된다.
대부분의 프로젝트에서 대다수의 조직 계획은 프로젝트의 가장 초기 단계의 일부로 행해진다.
그러나 이런 과정의 결과는 계속적인 적용가능성을 확보하기 위해 프로젝트 전과정을 통하여
정기적으로 검토되어야 한다. 초기 조직이 더 이상 효과적이지 않다면 즉시 변경되어야 한다.
조직 계획은 종종 프로젝트 조직 구조가 프로젝트 의사소통 요건에 영향을 미치기 때문에
의사소통 계획(10장에서 기술됨)과 밀접히 연계되어 있다.

9.1.1 조직 계획의 입력자료 Inputs to Organizational Planning

.1 프로젝트 인터페이스 (Project Interfaces) 프로젝트 인터페이스는 일반적으로 다음과 같이

세 범주로 분류된다.
조직적 인터페이스 - 다양한 조직 단위간 공식·비공식적 보고 관계. 조직적
인터페이스는 매우 복잡하거나 또는 매우 단순할 수 있다. 예를 들어 복잡한 원격통신시스템을
개발하는 것은 몇 년에 걸쳐 수많은 하수급자를 조정하는 것을 필요로 하는 반면 한 지역에
설치된 시스템의 오류를 수정하는 것은 완성되었을 때 사용자와 운영직원에게 알리는 것과 같은
정도를 필요로 할 것이다.
기술적 인터페이스 - 다양한 기술 분야간 공식·비공식적 보고 관계. 기술적
인터페이스는 프로젝트 단계 내에서(예: 토목기술자에 의해 작성된 현장 도면은 구조기술자에
의해 작성된 상부구조물과 호환되어야 한다) 그리고 프로젝트 단계간에서 (예: 자동차 설계팀이
작업결과를 차량 제조 용량을 만들어 내는 기계설비재정비 팀에게 넘겼을 때) 모두 발생한다.
대인간 인터페이스 - 프로젝트에서 일하는 다양한 개인들간의 공식·비공식적 보고 관계

70 of 109
 설계 회사에 고용된 건축가가 주요 설계 고려사항을 관련 없는 시공자의 프로젝트 관리팀에게
설명할 때와 마찬가지로 이러한 인터페이스는 종종 동시에 발생한다.

.2 직원충원 요건 (Staffing Requirements) 직원충원 요건은 어떠한 사람 또는 집단으로부터,

어떤 시간대에 어떤 종류의 기술(skill)이 필요한가를 정의한다. 직원충원 요건은 자원계획(7.1절
참조) 동안 확인된 전반적인 자원요건의 일부이다.

.3 제한조건 (Constraints) 제한조건은 프로젝트팀의 선택의 폭을 제한하는 요인이다.

프로젝트의 조직적 선택은 여러 가지 방법으로 제한될 수 있다. 팀을 조직하는 방법을 제한할 수
있는 공통적인 요인은 다음과 같은 요인을 포함한다.(그러나 꼭 이런 요인에 한정할 수는 없다.)
수행조직의 조직 구조 Organizational structure of the performing organization -
조직의 기본 구조가 강한 매트릭스인 조직은 약한 매트릭스를 가진 조직보다 프로젝트 관리자에
대한 역할이 상대적으로 강하다. (2.2.3절 조직 구조 참조)
단체 교섭 협약 Collective bargaining agreements - 노동조합 또는 노동자 단체와의
협약은 특정 역할 또는 보고관계를 요구할 수도 있다.(본질적으로 노동자 단체는 프로젝트관련자
(stakeholder)이다)
PM팀의 선호 Preference of the project management team - PM팀의 팀원이 특정 구조로
성공을 했었다면 그들은 장래에서도 비슷한 구조를 옹호할 것이다.
예상된 임(직)원 임명 Expected staff assignments - 프로젝트가 어떻게 조직되는가
하는 것은 종종 특정 개인의 기술과 능력에 영향을 받는다.

9.1.2 조직 계획의 도구 및 기법

.1 기본형 Templates 각각의 프로젝트가 유일한 것이라 할지라도 대부분의 프로젝트는 어느

정도는 다른 프로젝트와 유사한 면이 있다. 유사 프로젝트의 역할과 책임 정의 또는 보고관계를
이용하는 것은 조직 계획의 절차를 진척시키는데 도움이 될 수 있다.

.2 인적 자원 실무 Human resource practices 대부분의 조직은 다양한 정책, 지침 및 절차를

가지고 있으며 이러한 것은 프로젝트관리팀이 조직 계획의 여러 측면을 다루는데 도움이 된다.
예를 들어 관리자를 "coach"로 취급하는 조직은 어떻게 "coach"의 역할을 수행할 것인가에 대해
문서화를 할 것이다.

.3 조직 이론 Organizational theory 많은 문헌에서 조직이 구성되어야 하는 방법에 대해

기술하고 있다. 이러한 문헌중의 일부가 프로젝트 조직을 목표로 하고 있다 할지라도 일반적으로
PM팀은 프로젝트 요구조건에 더욱 잘 대응하기 위해 조직 이론을 잘 알고 있어야 한다.

.4 프로젝트 관련자 분석 Stakeholder analysis 프로젝트 관련자들의 요구가 충족될 수 있다는

71 of 109
것을 확증하기 위해 그들의 다양한 요구가 분석되어야 한다. (10.2.1 참조)

9.1.3 조직 계획의 결과 Outputs from Organizational Planning

.1 역할 및 책임 할당 Role and responsibility assignments 프로젝트 역할(누가 무엇을 하는

것)과 책임(누가 무엇을 결정하는 것)은 적당한 프로젝트 관련자에게 할당되어야 한다. 역할과
책임은 시간에 따라 변화한다. 대부분의 역할과 책임은 프로젝트의 작업에 적극적으로 참여하는
프로젝트관련자(PMr, PM팀의 다른 팀원, 개인적 기여자와 같은 사람)에게 할당될 것이다.
일반적으로 PMr의 역할과 책임은 대부분의 프로젝트에 중요하지만 응용분야에 따라 상당히
다양하다.
프로젝트 역할과 책임은 프로젝트 범위 정의와 밀접히 연계되어야 한다. 책임할당 매트릭스
(Responsibility Assignment Matrix: RAM, 그림9-2)는 종종 이런 목적으로 이용된다. 거대
프로젝트에서 RAM은 다양한 수준에서 개발될 수도 있다. 예를 들어 높은 수준의 RAM은 어떤 집단
또는 단위가 작업분류체계의 각 요소에 책임이 있는가를 정의하는 반면, 낮은 수준의 RAM은 특정
액티비티의 역할과 책임을 특정 개인에 할당하기 위해 집단내부에서 사용된다.

.2 직원 충원 관리 계획 Staffing management plan 직원충원관리 계획은 언제 어떻게 인적자원을

프로젝트팀에 합류시킬 것인가를 기술한다. 직원충원계획은 프로젝트 필요에 의해 공식 또는
비공식, 매우 상세하거나 또는 개략적일 수 있다. 이것은 전체 프로젝트 계획의 보조적인
요소이다. (4.1 참조)
직원충원관리계획은 그림 9.3에서 설명한 것처럼 자원 히스토그램을 포함한다.
프로젝트 팀원이 더 이상 프로젝트에 필요 없을 때 그들을 어떻게 "해제(release)"할 것인가에
대해 세심한 주의가 필요하다. 적정한 재 배치절차는 다음과 같다.
이번 배치와 다음 번 배치간의 시간을 채우기 위해 "일을 만드는" 경향을 줄이거나 또는
제거함으로써 비용을 절감한다.
장래 고용기회에 대한 불확실성을 감소 또는 제거함으로써 사기를 향상시킨다.

.3 조직도 Organization chart 조직도는 프로젝트 보고관계의 도식적 표현이다. 이것은

프로젝트의 필요에 의해 공식적 또는 비공식적, 고도로 상세하거나 또는 대략적일 수 있다. 예를
들어 3-4명의 내부 용역 프로젝트의 조직도는 3,000명의 원자력 발전소 프로젝트의 조직도의
엄격하고 상세함을 가지지는 않을 것이다.
조직분류체계(OBS)는 어떤 조직부서(단위)가 어떤 작업에 책임이 있는가를 나타내는 특정유형의
조직도이다.

.4 지원상세 Supporting detail 조직계획의 지원상세는 응용분야 및 프로젝트 규모에 따라

다양하다. 때때로 지원상세로서 제공되는 정보에는 다음을 같은 것을 포함한다(그러나 반드시
이런 항목으로 제한되지는 않는다).

72 of 109
 조직적 영향 (Organizational impact) - 어떤 대안은 이런 방법으로 조직화함으로써
제외된다.
작업기술(job description) - 주어진 작업 수행에 포함되는 기술(skill), 책임, 지식,
권한, 물리적 환경, 그리고 기타 특성과 같이 작업지위(직위)별로 개략적으로 기술된 문서. "직위
기술"으로도 불린다.
훈련 필요(Training needs) - 배치된 직원이 프로젝트에 필요한 기술을 갖지 못했다면
그러한 기술은 프로젝트의 일부로써 개발될 필요가 있다.

9.2 임(직)원 확보 Staff Acquisition

임원확보는 필요한 인적자원(개인 또는 집단)을 프로젝트에 배치하고 작업을 행하는 것을

의미한다. 대부분의 환경에서 "최적(best)"의 자원을 이용할 수 없을 수 있으며, PM팀은 이용
가능한 자원이 프로젝트 요건을 충족시킬 수 있도록 주의를 기울여야 한다.

9.2.1 임(직)원 확보의 입력자료 Inputs to Staff Acquisition

.1 임(직)원 충원 관리계획 Staffing management plan 직원충원 관리 계획은 9.1.3.2에서

기술하였다. 이것은 9.1.1.2에서 기술된 것처럼 프로젝트 직원충원 요건을 포함한다.

.2 임(직)원 풀 기술 Staffing pool description PM팀이 직원 배치에 영향을 주거나 또는 지시할

때, 잠재적으로 이용가능한 직원의 특성을 고려해야 한다. 고려해야 할 사항은 다음과 같다.
과거 경험 - 개인 또는 집단이 과거에 유사하거나 또는 관련된 작업을 한 적이 있는가?
그들은 작업을 훌륭히 해냈는가?
개인적 관심사 - 개인 또는 집단은 이번 프로젝트에서 수행하는 작업에 관심을 가지고
있는가?
이용가능성 - 대부분의 바람직한 개인 또는 집단을 필요한 시간에 이용할 수 있는가?

.3 채용 실무 Recruitment practice 하나 이상의 조직이 프로젝트에 참여할 때 이들 조직은 직원

배치를 관리하는 정책, 지침, 절차를 가질 수 있다. 이러한 것들이 존재할 때 그런 실무는 임(직)
원 확보절차의 제한조건이 된다.

9.2.2 직원확보를 위한 도구 및 기법

.1 협상 Negotiations 직원 배치는 대부분의 프로젝트에서 협상되어야 한다. 예를 들어 PM팀은

다음의 사람들과 협상할 필요가 있을 수 있다.
책임이 있는 기능적 관리자(필요한 시간에 적정한 기술을 갖춘 직원을 확실히 보충하기
위해)

73 of 109
 수행조직내의 기타 PM팀 (희귀한 또는 전문화된 자원을 적정하게 배치하기 위해)

팀의 영향력 있는 기술 skill (2.4.5절 조직에 대한 영향 참조)은 참여한 조직의 정책과

마찬가지로 임(직)원 배치를 협상함에 있어 중요한 역할을 한다. 예를 들어 기능적 관리자는 임
(직)원 활용을 근거로 보상받을 수도 있다. 이것은 관리자로 하여금 프로젝트의 모든 요건을
충족시킬 수 없지만 이용 가능한 임(직)원을 배치하도록 하는 인센티브가 될 것이다.

.2 사전 배치 Pre-assignment 어떤 경우에는 임(직)원은 프로젝트에 미리 배치될 수도 있다.

이것은 프로젝트가 경쟁입찰이고 특정 임(직)원이 (입찰)제안서의 일부로 계약되었을 때, 또는
프로젝트가 내부 서비스 프로젝트이며 직원 배치가 프로젝트 헌장 내에서 정의될 때가 그러하다.

.3 구매(계약) Procurement 프로젝트구매관리(12장 참조)는 프로젝트의 액티비티를 수행하기

위해 특정 개인 또는 집단의 서비스를 확보하기 위해 이용될 수 있다. 구매는 수행조직이
프로젝트를 완성하기 위해 필요한 내부직원이 부족한 경우에 필요하다.

9.2.3 임(직)원 확보의 결과 Outputs from Staff Acquisition

.1 임명된 프로젝트 임(직)원 Project staff assigned 적당한 사람이 프로젝트의 작업에
배치되었을 때 그 프로젝트는 직원이 구성된다. 직원은 전임으로 또는 시간제로 프로젝트의
필요에 따라 다양하게 배치된다.

.2 프로젝트 팀 주소록 Project team directory 프로젝트 팀 주소록은 모든 프로젝트 팀원과

기타 주요 프로젝트관련자(stakeholder)를 목록으로 만든 것이다.

9.3 팀 개발 Team Development

팀 개발은 개인으로서 기여하는 프로젝트관련자(stakeholder)의 능력을 향상시킬 뿐만 아니라

팀으로서 기능을 하는 팀의 능력을 향상시키는 것을 모두 포함한다. 개인적인 개발(development,
관리적·기술적인)은 팀을 개발하기 위해 필요한 토대가 된다. 팀으로서 개발은 프로젝트의
목적을 충족시키기 위한 프로젝트의 능력에 중요하다.
종종 프로젝트 팀 개발은 개인적인 팀원이 기능적 관리자와 프로젝트 관리자 모두에 책임을 지닐
때 아주 복잡해진다(매트릭스 구조에 대해서는 2.3.3절 참조). 이런 이중적인 보고관계의
효과적인 관리는 종종 프로젝트의 중요한 성공요인이며, 일반적으로 PMr의 책임이다.
3장에서 팀 개발은 실행 절차의 하나로서 위치해 있지만, 팀 개발은 프로젝트 전반에 걸쳐
발생한다.

9.3.1 팀 개발의 입력자료 Inputs to Team Development

74 of 109
 .1 프로젝트 임(직)원 Project staff 프로젝트 직원충원은 9.3.2.1절에서 기술되었다. 직원
배치는 개인적인 기술(skill)과 팀 기술이 이용 가능해야 한다는 것을 암시하고 있다.

.2 프로젝트 계획 Project plan 프로젝트 계획은 4.1.3.1절에서 기술하였다. 프로젝트 계획은

팀이 운용해나가는 기술적 배경(context)을 기술하고 있다.

.3 직원충원 관리계획 Staffing management plan 직원충원관리계획은 9.1.3.2에서 기술하였다.

.4 실행보고서 Performance reports 실행보고서(10.3.3.1절에서 기술)는 프로젝트팀에 프로젝트

계획에 대한 실행에 관한 피드백을 제공한다.

.5 외부 피드백 External feedback 프로젝트팀은 주기적으로 프로젝트 외부인의 실행

(performance) 기대치에 대하여 자신들을 측정해야 한다.

9.3.2 팀 개발을 위한 도구 및 기법

.1 팀 구성 액티비티 Team-building activities 팀 구성 액비티비는 주로 팀 성능(performance)

을 향상시키기 위해 취하는 관리적, 개인적 행동을 의미한다. 계획절차에서 非-관리적 수준의
팀원을 포함하거나, 또는 갈등을 살피고 다루기 위한 토대를 구축하는 것과 같은 많은 행동은
부대효과로 팀 성능을 향상시킬 수 있다. 팀구성 액티비티는 정기적인 상황보고 모임에서 5분
정도의 의사일정으로부터 보다 확대되어 주요 프로젝트관련자(stakeholder)간의 대인관계를
향상시키기 위해 고안된 현장이외의 전문적인 경험에 이르기까지 다양하다.
팀 구성에 대해서는 많은 문헌이 있다. 프로젝트 관리팀은 일반적으로 다양한 팀 구성
액티비티에 친숙해야 한다.

.2 일반적인 관리 기술 General management skills 일반적인 관리 기술(2.4절에서 논의됨)은 팀

구성에 특히 중요하다.

.3 보상 및 인정 시스템 Reward and recognition systems 보상 및 인정체계는 바람직한 행동을

이끌어 내기 위한 공식적인 관리 행동이다. 효과적이기 위해서 이러한 체계는 실행과 보상의
관계를 명확하고 달성가능하도록 연계시켜야 한다. 예를 들어 프로젝트 비용 목적을 달성했다는
이유로 보상을 받게 되는 PMr는 직원충원 및 구매 결정에 대해 적정한 수준의 통제를 해야 할
것이다.
수행조직의 체계가 부적정할 수 있기 때문에 프로젝트는 종종 나름대로의 보상 및 인정체계를
가져야만 한다. 예를 들어 적극적인 스케줄 목적을 충족시키기 위해 기꺼이 잔업을 하려는 것은
보상받고 인정되어야 한다. 즉 잘못된 계획의 결과로 잔업을 필요로 하는 것은 인정, 보상하지

75 of 109
말아야 한다.
보상 및 인정 체계는 또한 문화적인 차이를 고려해야 한다. 예를 들어 개인주의를 존중하는
문화에서 팀 보상 메커니즘을 개발하는 것은 상당히 어려울 수 있다.

.4 배치(병치) Collocation 배치는 가장 적극적인 모든 또는 거의 모든 프로젝트 팀원을

물리적으로 동일한 위치에 위치시켜, 이들이 한 팀으로서 그들의 수행능력을 높이기 위한 것이다.
배치는 거대한 프로젝트에서 널리 사용되고 있으며, 또한 소규모 프로젝트에서도 효과적이다.

.5 훈련 Training 훈련은 프로젝트팀의 기술, 지식, 능력을 향상시키기 위해 의도된 모든

액티비티를 포함한다. 일부 저자는 훈련, 교육, 그리고 개발을 구별하지만, 그런 구별은 일관성이
있다거나 널리 인정된 것은 아니다. 훈련은 공식적이거나 또는 비공식적일 수 있다. 성인에게
어떻게 훈련을 제공해야 하는가에 대한 문헌이 많이 있다.
프로젝트 팀원에게 필요한 관리 또는 기술적 기술이 부족하다면, 그런 기술은 프로젝트의
일부로써 개발되어야 하며 또는 프로젝트에 알맞게 직원을 재배치하는 조치가 취해져야 한다.
일반적으로 훈련을 위한 직접 및 간접비용은 수행조직에 의해 지불된다.

9.3.3 팀 개발의 결과 Outputs from Team Development

.1 성능 향상 Performance improvements 팀 개발의 주요 결과는 프로젝트 성능향상이다.

성능향상은 많은 자원으로부터 파생될 수 있으며, 프로젝트 실행의 많은 영역에 영향을 줄 수
있다. 예를 들면 다음과 같다.
개인적인 기술측면의 개선은 특정한 사람이 그들의 할당된 액티비티를 더 효과적으로
수행하도록 한다.
팀 행동측면의 개선(예, 갈등을 살피고 다루는 것)은 프로젝트팀이 그들의 노력의 더
많은 부분을 기술적인 액티비티에 전념하도록 한다.
개인적이 기술 또는 팀 능력 측면의 개선은 프로젝트 작업 수행의 더 좋은 방법을
파악하고 개발하도록 한다.

.2 실행 평가에 대한 입력자료 Inputs to performance appraisals 일반적으로 프로젝트 임원

(staff)은 어떤 프로젝트 직원(staff members)의 실행평가에 대한 입력자료를 제공할 것이다.

10장 프로젝트 의사소통 관리(PROJECT COMMUNICATION MANAGEMENT)

프로젝트 의사소통 관리는 적시에, 적정한 프로젝트 정보의 발생, 수집, 저장 그리고
궁극적으로는 그러한 정보를 처리하기 위해 필요한 절차를 포함한다. 이것은 성공을 위해 필요한
사람, 아이디어, 정보간의 중요한 연계를 제공한다. 프로젝트에 참여한 모든 사람들은 프로젝트

76 of 109
"언어"로 된 의사소통을 받고 보낼 준비가 되어 있어야 하며, 개인이 전체 프로젝트에 영향을
주는 것처럼 그들이 어떻게 의사소통에 참여할 것인지 이해해야 한다.

10.1 의사소통 계획 Communications Planning - 프로젝트 관련자의 정보 및 의사소통

요구 결정, 즉 누가 어떤 정보를 필요로 하고 언제 그것을 필요로 하는가, 그리고 어떻게 전달할
것인가?
10.2 정보 배포 Information Distribution - 필요한 정보를 적시에 프로젝트 관련자가
이용가능토록 함
10.3 실행보고 Performance Reporting - 실행 정보를 수집하고 배포. 이것은 상태보고,
진보 측정, 그리고 예측을 포함한다.
10.4 행정적인 완료 Administrative Closure - 단계 또는 프로젝트 완성을 공식화하기
위해 정보를 발생, 수집, 배포하는 것

이러한 절차는 각 프로세스는 물론 다른 지식영역의 프로세스와 상호작용 한다. 각 프로세스는

프로젝트의 필요에 기반을 둔 개인 또는 집단의 노력을 포함할 것이다. 일반적으로 각 프로세스는
최소한 모든 프로젝트 단계에서 한번은 발생한다.
여기에서 프로세스가 개별적으로 분리된 요소로 제시되어 있지만, 실제로는 여기에서 상세히
다루지 않는 방법으로 중복되고 상호작용을 한다. (3장 참조)
일반적인 의사소통 관리기술(2.4.2에 기술됨)은 프로젝트 의사소통관리와 관계는 있지만 동일한
것은 아니다. 의사소통은 폭 넓은 주제이며 프로젝트 환경에 유일하지 않은 실제적인 지식영역을
포함한다. 예를 들면 다음과 같다.
송신자-수신자 모델 - 피드백 루프, 의사소통의 장애 등
미디어의 선택 - 문서로 의사소통 할 때와 구두로 의사소통 할 때, 비공식적 메모를
작성할 때와 공식적 보고서를 작성할 때 등
문체 writing style - 적극적인 어투와 소극적인 어투, 문장 구조, 어휘 선택 등
발표 기법 - 몸짓(body language), 시각적 보조도구의 고안 등
회의 관리기법 - 의사일정 준비, 갈등 관리 등

10.1 의사소통 계획 Communications Planning

의사소통 계획은 프로젝트 관련자의 정보 및 의사소통 요구를 결정하는 것을 의미한다. 즉 누가

어떤 정보를 필요로 하는가, 필요로 할 때는 언제인가?, 그리고 어떤 방법으로 전달할 것인가?
모든 프로젝트는 프로젝트 정보를 전달할(communicate) 필요가 있지만, 정보 요구와 배포 방법은
다양하다. 프로젝트 관련자의 정보 요구를 파악하고 그들의 요구를 충족시킬 적절한 수단을
결정하는 것은 프로젝트 성공에 중요한 요인이다.
대부분의 프로젝트에서 대부분의 의사소통 계획은 프로젝트의 가장 초기단계의 일부로 행해진다.
그러나 이러한 절차의 결과는 프로젝트 전 기간에 걸쳐 정규적으로 검토되어야 하며 지속적인

77 of 109
적용가능성을 확보하기 위해서는 필요에 따라 변경되어야 한다.
종종 의사소통계획은 조직 계획(9.1 참조)과 밀접히 연계된다. 왜냐하면 프로젝트 조직의 구조가
프로젝트의 의사소통 요건에 영향을 미치게 될 것이기 때문이다.

10.1.1 의사소통 계획의 입력자료 Inputs to Communications Planning

.1 의사소통 요건 Communications requirements

의사소통 요건은 프로젝트 관련자들의 정보 요건의 총합이다. 그러한 요건들은 필요한 정보의
유형과 형식을 그 정보의 가치 분석과 결합함으로써 정의된다. 프로젝트 자원은 성공에
기여하거나 또는 정보의 부족이 실패를 가져오는 그러한 정보 전달(communicating information)
에만 사용되어야 한다.
프로젝트 의사소통을 결정하기 위해 필요한 정보는 다음을 포함한다.
프로젝트 조직 및 프로젝트 관련자 책임 관계
프로젝트에 참여한 학문분야, 부서, 그리고 전문분야
얼마나 많은 사람이 프로젝트에 참여할 것인가 그리고 어느 곳에서 참여할 것인가에
대한 병참술
외부 정보 요구 (예, 미디어를 통한 의사소통)

.2 의사소통 기술 Communications technology

프로젝트 요소들간의 정보의 전달(back and forth)에 사용되는 기술 또는 방법은 매우 다양하다.

즉 간단한 대화에서 모임에 이르기까지, 간단히 작성된 문서에서 즉각적으로 접속 가능한 온-라인
스케줄과 데이터베이스에 이르기까지 다양하다. 프로젝트에 영향을 주는 의사소통 기술 요인은
다음을 포함한다.
정보 요구의 긴급성 - 프로젝트 성공이 자주 갱신되어 그 순간에 이용 가능한 정보에
달려있는가 또는 정규적으로 작성 발행되는 보고서로 충분한 것인가?
기술의 이용가능성 - 이미 존재하는 시스템이 적정한가 또는 프로젝트 요구가 변경을
보증하는가?
예상된 프로젝트 직원 충원 -제안된 의사소통체계는 프로젝트 참여자의 경험과
전문지식과 호환되는가? 또는 훈련과 교육이 필요한가?
프로젝트의 기간(length) - 프로젝트가 끝나기 전에 이용 가능한 기술이 변할 것인가?

.3 제한 조건 Constraints

제한조건은 PM팀의 선택을 제한하는 요인이다. 예를 들어 실제적인 프로젝트 자원이

구매되었다면 계약정보를 다루는데 더 많은 주의를 해야 할 필요가 있다.

78 of 109
 프로젝트가 계약으로 수행될 때 종종 의사소통 계획에 영향을 주는 특정한 계약규정이 있게
된다.

.4 가정 Assumptions

가정은 계획의 목적으로 진실, 실제, 또는 확실하다고 생각되는 요인들이다. 일반적으로 가정은
어느 정도의 리스크를 포함한다. 그러한 것들은 여기에서 파악될 수도 있으며 또는 리스크 파악의
결과가 될 수도 있다. (11.1 참조)

10.1.2 의사소통 계획의 도구 및 기법

.1 프로젝트 관련자 분석 Stakeholder analysis

다양한 프로젝트 관련자들(stakeholder)의 정보 요구가 분석되어 그들의 요구를 충족시키기 위해

그들의 정보요구 및 정보원에 대한 조직적이고 논리적인 관점을 구축해야 한다. (프로젝트
관련자는 2.2절 참조) 분석은 필요한 정보를 제공하게 될 프로젝트에 적당한 방법과 기술을
고려해야 한다. 불필요한 정보 또는 부적당한 기술에 자원을 낭비하지 않도록 세심한 주의가
필요하다.

10.1.3 의사소통 계획의 결과 Outputs from Communications Planning

.1 의사소통 관리계획 Communications management plan

의사소통 관리계획은 다음과 같은 것을 제공하는 문서이다.

다양한 정보를 수집하고 저장하는데 이용하게 될 방법을 상술한 정보수집 및
서류정리구조. 절차는 수집 및 배포, 그리고 이미 배포된 자료에 대한 갱신과 교정을 포함해야 할
것이다.
정보(상태보고서, 자료, 일정, 기술적 문서 등)를 누구에게 주어야 하며, 다양한 정보를
배포하기 위해 어떤 방법(문서작성, 모임 등)을 사용할 것인가를 상술한 배포구조. 이런 구조는
프로젝트 조직도에 의해 기술된 책임 및 보고 관계와 호환되어야 한다.
배포된 정보에 대한 기술(description)로 형식, 내용, 상세 수준, 그리고 사용된 범례/
정의가 포함된다.
각 의사소통 유형(type)이 만들어지게 될 때를 나타낸 생산일정(production schedule)
일정 계획된 의사소통 사이의 정보 접근방법(method for accessing information)
프로젝트가 전개되어 감에 따라 의사소통관리계획을 갱신하고 구체화(refine)하는 방법

79 of 109
의사소통관리 계획은 프로젝트의 필요에 따라 공식적 또는 비공식적, 고도의 상세 또는 개략적일
수 있다. 이것은 전체 프로젝트 계획의 보조적인 요소이다. (4.1 참조)

10.2 정보 배포 Information Distribution

정보배포는 프로젝트 관련자들이 필요한 정보를 적시에 이용할 수 있도록 하는 것을 의미한다.

그것은 예상치 않았던 정보요청에 대한 대응뿐만 아니라 의사소통 관리 계획을 실행하는 것을
포함한다.

10.2.1 정보 배포의 입력자료 Inputs to Information Distribution

.1 작업 결과 work results 4.2.3.1 참조

.2 의사소통관리계획 Communications management plan 10.1.3.1 참조
.3 프로젝트 계획 project plan 4.1.3.1 참조

10.2.2 정보배포의 도구 및 기법

.1 의사소통 기술 Communications skills

의사소통 기술은 정보를 교환하는데 이용된다. 송신자는 수신자가 정확하게 수신할 수 있도록
정보를 명확하고, 모호하지 않게 그리고 완전하게 할 책임이 있으며 그리고 올바르게 이해하도록
할 책임이 있다. 수신자는 정보가 완전하게 수신되었고 정확하게 이해되었다는 것을 확실히 할
책임이 있다. 의사소통은 다음과 같이 다양한 차원을 가지고 있다.
문서 및 구두, 듣기와 말하기
내부(프로젝트 내) 및 외부(고객, 미디어, 공중 등)
공식적(보고서, 브리핑 등) 그리고 비공식적(메모, 임시대화 등)
수직적(조직의 상향 및 하향) 그리고 수평적(동료)

.2 정보 검색시스템 Information retrieval systems

정보는 수작업의 서류정리 체계, 전자 문서 DB, 프로젝트 관리 소프트웨어, 엔지니어링 도면과

같은 기술적 문서에 접근할 수 있는 시스템을 포함하는 다양한 방법을 통하여 팀원과 공유될 수
있다.

.3 정보 배포 시스템 Information distribution system

프로젝트 정보는 프로젝트 모임, 문서 사본 배포, 네트웍 전자 DB로의 접근, 팩스, 전자메일,

80 of 109
음성메일, 비디오 회의등을 포함하는 다양한 방법을 이용하여 배포될 수도 있다.

10.2.3 정보배포의 결과 Outputs from Information Distribution

.1 프로젝트 기록 Project records

프로젝트 기록은 문서수발(correspondence), 메모, 보고서 그리고 프로젝트를 기술한 문서를

포함한다. 이러한 정보는 가능한 정도로 적정하게 조직화된 방법으로 유지되어야 한다. 종종
프로젝트팀원은 프로젝트 기록(notebook)에 개인적 기록을 유지할 수도 있다.

10.3 실행보고 Performance Reporting

실행보고는 실행정보(performance information)를 수집하고 배포하는 것을 의미하는 것으로,

프로젝트 관련자에게 프로젝트 목적을 달성하기 위해 어떻게 자원을 사용할 것인가에 대한 정보를
제공하기 위한 것이다. 이 절차는 다음을 포함한다.
상태보고(서) Status reporting - 프로젝트의 현재 상황을 기술
진도보고(서) Progress reporting - 프로젝트팀이 달성한 것을 기술
예측 Forecasting - 프로젝트의 미래 상태와 진도를 예측

실행보고(서)는 일반적으로 범위, 일정, 비용 그리고 품질에 대한 정보를 제공해야 한다. 또한

대부분의 프로젝트는 리스크와 조달에 대한 정보를 필요로 한다. 보고서는 포괄적인 보고서로
또는 예외(보고서)로 준비될 수 있다.

10.3.1 실행보고(서)의 입력자료Inputs to Performance Reporting

.1 프로젝트 계획 Project plan 프로젝트 계획은 4.1.3.1에 기술되어 있다. 프로젝트 계획은
프로젝트 실행에 평가하는데 이용되는 다양한 기준을 가지고 있다.

.2 작업 결과 Work results 작업결과 - 완전히 또는 부분적으로 완성된 성과물, 발생되거나 또는

집행된 비용 -는 프로젝트 계획 수행의 결과이다. (4.2.3.1 참조) 작업결과는 의사소통 관리
계획에 의해 제공된 틀 안에서 보고되어야 한다. 작업결과에 대한 정확하고 일정한 정보는 유용한
실행보고(서)에서 근본적으로 필요하다.

.3 기타 프로젝트 기록 Other project records 프로젝트 기록은 10.2.3.1에서 논의되었다.

프로젝트 계획과 프로젝트 작업결과에 이외에도 기타 프로젝트 문서는 종종 프로젝트 실행을
평가할 때 고려되어야 하는 프로젝트에 관계된 정보를 포함한다.

81 of 109
10.3.2 실행보고의 도구 및 기법

.1 실행 검토 Performance reviews

실행검토는 프로젝트 상태 또는 진도를 평가하기 위해 개최되는 모임이다. 실행보고는

전형적으로 이하에 기술되어 있는 한가지 이상의 실행보고 기법과 결합되어 이용된다.

.2 편차 분석 Variance analysis

편차분석은 실제 프로젝트 결과와 계획된 또는 예상된 결과와 비교하는 것을 의미한다. 비용 및

일정 편차는 가장 흔하게 분석되지만 범위, 품질, 리스크 영역의 계획으로부터 편차는 이와
동등하거나 또는 더 중요하다.

.3 추세 분석 Trend analysis

추세분석은 실행이 개선되고 있는가 또는 악화되고 있는가를 결정하기 위해 장시간에 걸쳐

프로젝트 결과를 조사하는 것이다.

.4 실행기성 분석 Earned Value analysis

여러 가지 형태의 실행기성분석은 실행(performance)을 측정하기 위한 가장 흔하게 이용되는

방법이다. 이것은 범위, 비용, 그리고 일정의 측정을 통합하여 프로젝트 관리팀이 프로젝트
실행을 평가하는 데 도움이 되도록 한 것이다. 실행기성은 각 액티비티에 대해 다음 세 가지의
계산을 하게 된다.
예산(budget), 또는 실행(할 예산)(Budgeted Cost of Work Scheduled: BCWS)3으로
부르기도 하는데, 이것은 주어진 기간동안 액티비티에 지출할 것을 계획한 승인된 견적의
일부분을 말한다.
실비(actual cost), 또는 실투입비(Actual Cost of Work Performed: ACWP)4으로
부르기도 하는데, 이것은 주어진 기간동안 액티비티의 작업을 완료하는데 발생된 직·간접비용의
총합이다.
실행기성(earned value), 또는 실행기성(Budgeted Cost of Work Performed: BCWP)5으로
부르기도 하는데, 이것은 실제 완성된 작업의 백분율과 동등한 총 예산의 백분율이다. 실행기성의
이행(implementation)은 자료 수집을 단순화하기 위해 단지 몇 개의 백분율(예를 들면 30%, 70%,
90%, 100% )을 이용한다. 일부 실행기성 이행은 실행의 객관적인 측정을 확보하는데 도움이
되도록 단지 0% 또는 100%를 이용하기도 한다.

이런 세 개의 기성(value)은 작업이 계획된 대로 완성되었는가의 여부에 대한 측정(치)을

82 of 109
제공하기 위해 조합하여 사용된다. 가장 흔히 사용되는 측정방법은

원가분산(Cost Variance: CV, CV= BCWP-ACWP),

공기분산(Schedule Variance: SV, SV=BCWP-BCWS),
그리고 원가수행지수(Cost Performance Index: CPI, CPI=BCWP/ACWP)이다.
CPI 누계는 완성시 프로젝트 비용을 예측하기 위해 널리 사용된다. CPI 누계는 각 BCWP를 더한
총액을 각 ACWP의 총액으로 나눈 것이다. 일부 응용분야에서는 공기수행지수(SPI=BCWP/BCWS)가
프로젝트 완성일을 예측하기 위해 이용된다.

.5 정보 배포 도구 및 기법 Information distribution tools and techniques

실행보고서는 10.2.2에 기술된 도구 및 기법을 이용하여 배포된다.

10.3.3 실행보고(서)의 결과 Outputs from Performance Reporting

.1 실행보고서 Performance reports

실행보고서는 수집된 정보를 조직하고 요약하며, 분석결과를 제시한다. 보고서는 의사소통

관리계획에서 문서화된 것처럼 다양한 프로젝트 관련자가 필요로 하는 여러 종류의 정보와
상세수준을 제공한다.
실행보고서의 일반적인 형식은 바-차트(또는 간트차트로 불림), S-커브, 히스토그램, 표(table)
를 포함한다. 그림 10-2에서는 누계적인 실행기성 분석 자료를 나타내기 위해 S-커브를 이용한
반면 그림 10-3에서는 표 형식으로 실행기성 자료를 나타내고 있다.

.2 변경요청 Change requests

종종 프로젝트 실행 분석은 프로젝트 일부 측면에 대한 변경요청을 발생시킨다. 이러한 변경

요청은 다양한 변경관리(control) 절차에서 기술된 대로 처리된다. (예를 들면 변경관리,
일정관리(control) 등)

10.4 행정적인 종료 Administrative Closure

목적을 달성하거나 또는 기타 이유로 종결된(terminate) 이후에 프로젝트 또는 단계는 종료를

필요로 한다. 행정적인 종료는 프로젝트 결과를 검증하고 문서화하는 것으로 구성되며, 이는
스폰서, 발주자, 고객이 프로젝트 결과(product)에 대한 승인을 공식화하기 위한 것이다. 이것은
최종 시방, 프로젝트 성공 및 효과성 분석을 반영했는가를 확보하기 위해 프로젝트 기록들을
수집하고 그러한 정보를 장래에 이용하기 위해 저장하는 것을 포함한다.

83 of 109
 행정적인 종료 액티비티는 프로젝트가 완성될 때까지 지연되지 말아야 한다. 프로젝트의 각
단계는 프로젝트의 각 단계는 중요하고 유용한 정보가 손실되지 않도록 적절하게 종료되어야
한다.

10.4.1 행정적인 종료의 입력자료 Inputs to Administrative Closure

.1 실행측정 문서 Performance measurement documentation

프로젝트 실행을 기록하고 분석하기 위해 만들어진 모든 문서(실행측정을 위한 기본 틀을

구성했던 계획문서를 포함)는 행정적인 종료 동안 검토목적으로 이용할 수 있어야 한다.

.2 프로젝트 결과에 대한 문서 Documentation of the product of the project

프로젝트 결과를 기술하기 위해 만들어진 문서(계획, 시방서, 기술적 문서, 도면, 전자파일 등)는
행정적인 종료 동안 검토목적으로 이용할 수 있어야 한다.

.3 기타 프로젝트 기록 Other project records

프로젝트 기록은 10.2.3.1 참조

10.4.2 행정적인 종료를 위한 도구 및 기법

.1 실행보고(서 작성) 도구 및 기법 Performance reporting tools and techniques

10.3.2 참조

10.4.3 행정적인 종료의 결과 Outputs from Asministrative Closure

.1 프로젝트 기록보관 Project archives

적정한 주체가 보관할 수 있도록 색인을 단 완전한 프로젝트 기록 세트가 준비되어야 한다.
프로젝트와 관련된 어떤 특정 프로젝트 또는 프로그램의 DB가 갱신되어야 한다. 프로젝트가
계약으로 수행될 때 또는 특정 조달을 포함하고 있을 때 재정적 기록의 저장에 특히 주의해야
한다.

.2 공식적 승인 Formal acceptance

84 of 109
발주자 또는 스폰서가 프로젝트(또는 단계)의 결과를 승인한 문서가 준비되어 배포되어야 한다.

.3 시사점 Lessons learned 4.3.3.3 참조

11장 프로젝트 리스크 관리(PROJECT RISK MANAGEMENT)

프로젝트 리스크관리는 프로젝트 리스크를 규명하고, 분석하고, 대응하는 것과 관련된

프로세스들을 포함한다. 리스크관리는 긍정적 사건의 결과를 극대화하고 부정적인 결과를
최소화하는 것을 포함한다. 그림 11-1은 다음의 주요한 프로세스들의 개요를 제공한다.
11.1 리스크 규명 - 어떤 리스크가 프로젝트에 영향을 미칠 것인가를 결정하고 각각의
특성을 문서화
11.2 리스크 계량 - 가능한 프로젝트 결과물의 범위를 산정하기 위해서 리스크와 리스크
상호작용을 평가
11.3 리스크 대응책 개발 - 위험에 대한 기회와 대응을 위한 증진단계를 규정
11.4 리스크 대응관리 - 프로젝트의 과정상에서 리스크를 변화시키기 위한 대응

이들 프로세스들은 서로간 상호작용을 하고 마찬가지로 다른 지식분야의 프로세스들과

상호작용한다. 각 프로세스들은 프로젝트의 요구(needs)에 기초한 하나 또는 그 이상의 개인 또는
개인으로 이루어진 그룹으로부터 노력을 수반할 수 있다. 각 프로세스들은 일반적으로 모든
프로젝트 단계에서 최소한 한번은 발생한다.
비록 여기서 프로세스들이 잘 정의된 인터페이스를 지닌 별도의 요소로서 나타나고는 있지만,
실제상 여기서 상세하게 다루지 않는 방법으로 중첩되고 상호작용한다. 프로세스 상호작용은 3
장에서 상세하게 토론되었다.
다른 응용분야에서는 종종 여기에 기술된 프로세스들에 대해서 다른 이름을 사용한다. 예를 들면
·리스크 규명과 리스크 계량은 가끔 하나의 프로세스로 취급되며, 이것은 리스크 분석(risk
analysis) 또는 리스크 평가(risk assessment)로 불릴 수 있다.
·리스크 대응관리는 가끔 대응 계획(response planning) 또는 리스크 완화(risk mitigation)로
불린다.
·리스크 대응책 개발과 리스크 대응 관리는 가끔 하나의 프로세스로 취급되며, 이것은 리스크
관리로 불릴 수 있다.

11.1 리스크 규명(RISK IDENTIFICATION)

리스크 규명은 어떤 리스크가 프로젝트에 영향을 끼칠 것 같은가에 대한 결정과 그 각각의

특징들을 문서화하는 것으로 구성된다. 리스크 규명은 일회성 이벤트가 아니다. 이것은 프로젝트

85 of 109
동안에 통상적인 기반(regular basis)에서 수행되어야 한다.
리스크 규명은 내적리스크와 외적리스크로 다루어져야 한다. 내적리스크는 조직할당(staff
assignments)과 비용견적(cost estimates) 같은 프로젝트팀이 통제할 수 있고 영향을 줄 수 있는
것이다. 외적리스크는 시장의 이동이나 정부가 내린 조치와 같은 프로젝트팀의 통제나 영향을
넘어서는 것이다.
엄격히 말하자면, 리스크는 단지 해(harm)나 손실(loss)을 겪을 가능성을 포함하고 있다. 그러나
프로젝트의 맥락에서, 리스크 규명은 위험(부정적인 결과)인 동시에 기회(긍정적인 결과)와도
관련된다.
리스크 규명은 원인과 결과(어떤 일이 발생하고 결과로서 어떤 일이 발생하는가?) 또는 결과와
원인(회피해야 할 결과물과 장려되어야 할 결과물이 어떤 것인가와 어떻게 각각의 결과물이
발생되는가?)을 규명하는 것에 의해서 달성된다.

11.1.1 리스크 규명의 입력자료(Inputs to Risk Identification)

.1 생산물 설명(Product description).

프로젝트의 생산물의 성질은 규명된 리스크에 주요한 영향을 끼칠 것이다. 증명된 기술을
적용하는 생산물은 혁신(innovation)이나 발명(invention)을 필요로 하는 생산물보다 적은
리스크를 가지고 있다. 프로젝트의 생산물과 관련한 리스크는 종종 비용과 공기에 대한 영향으로
설명된다. 5.1.1.1은 생산물 설명에 대한 부가적인 정보를 나타낸다.

.2 다른 계획 결과물(Other planning outputs).

다른 지식분야에서의 프로세스 결과물은 발생가능한 리스크를 규명하기 위해 검토되어야 한다.

예를 들면
·작업분류체계(Work breakdown structure) - 세부적인 성과물(deliverables)에 있어서
범위진술서(scope statement)에서 규명한 보다 상위 레벌의 성과물로부터는 명확하지 않은 기회를
반 전통적인 방식(non-traditional approaches)이 제공할 수 있다.
·비용견적과 기간견적(Cost estimates and duration estimates) - 과감한 견적
(aggressive estimates)과 제한된 양의 정보로부터 얻어지는 견적은 더욱 많은 리스크를 수반한다.
·직원배치계획(Staffing plan) - 규명된 팀 조직원들은 대체하기에는 곤란한 고유기술을
가지고 있거나 그들의 유용성을 미약하게 하는 행위를 할 수도 있다.
·구매관리계획(Procurement management plan) - 불경기(sluggish)의 지역 경제와 같은
시장여건은 계약비용을 절감할 수 있는 기회를 제공할 수도 있다.

.3 역사적 정보(Historical information).

86 of 109
이전의 프로젝트에서 실제 발생한 역사적 정보는 잠재적인 리스크를 규명하는데 특히 도움이 될
수 있다. 역사적 결과에 대한 정보는 종종 다음과 같은 소스로부터 활용가능하다.
·프로젝트 파일 - 프로젝트에 관여한 하나 또는 그 이상의 조직은 리스크를 규명하는데
충분하게 상세한 과거의 프로젝트 결과에 대한 기록을 가지고 있다. 어떤 응용분야에서는 개별
팀 구성원들이 그와 같은 기록을 가지고 있을 수도 있다.
·상업용 DB - 많은 응용분야에서 역사적 정보가 상업적으로 이용가능하다.
·프로젝트팀의 지식 - 프로젝트팀의 개별 구성원들은 이전의 사건이나 가정들을
기억하고 있을 수 있다. 그와 같은 회상들은 유용할 수 있는 반면, 일반적으로 문서화된
결과들보다 신뢰도가 떨어진다.

11.1.2 리스크 규명의 도구와 기법

.1 체크리스트(Checklists).

일반적으로 체크리스트는 리스크의 출처에 의해 구성된다. 원인으로는 프로젝트 상황(project

context), 다른 프로세스 결과물, 프로젝트나 기술에 의한 생산물, 팀 구성원의 기술과 같은 내적
원인 등을 포함한다. 어떤 적용분야들은 리스크의 출처에 대한 분류계획을 폭넓게 사용해 왔다.

.2 흐름도(Flowcharting).

흐름도는 프로젝트팀이 리스크의 원인과 결과를 잘 이해하는데 도움을 줄 수 있다.

.3 면접(Interviewing).

다양한 관련자와의 리스크에 관한 인터뷰는 일반적인 계획활동 동안에 규명되지 않은 리스크를

규명하는데 도움이 될 수 있다. 사전 프로젝트 인터뷰의 기록(예를 들면 타당성검토기간 동안에
도출된 것) 역시 활용될 수 있다.

11.1.3 리스크 규명의 결과물(Outputs from Risk Identification)

.1 리스크의 출처(Sources of risk).

리스크의 출처는 프로젝트에 좋거나 나쁜 영향을 미칠 수 있는 발생가능한 리스크 이벤트의

범주이다. 출처의 목록은 포괄적이어야 하는데, 일반적으로 발생의 빈도와 확률 또는 이득과
손실의 크기에 상관없이 모든 규명된 항목들을 포함해야 한다. 리스크의 일반적인 출처는 다음을
포함한다.
·요구조건의 변경

87 of 109
 ·설계상의 오류, 생략, 오해(잘못이해됨)
·빈약하게 정의되거나 이해된 역할과 책임
·조악한 견적
·불충분한 전문인력
리스크의 출처에 대한 설명(description)은 일반적으로 다음에 대한 견적을 포함해야 한다
(a) 그 출처로부터 리스크 이벤트가 발생할 확률,
(b) 발생가능한 결과의 범위,
(c) 예상시기,
(d) 그 출처에 의한 리스크 이벤트의 예상 빈도
확률과 결과 양자는 연속적인 기능 또는 별개의 기능으로서 상세될 수 있다. 게다가, 초기
프로젝트 단계동안에 만들어진 확률과 결과(outcome)에 대한 견적은 프로젝트의 후반부에
만들어지는 그것에 비해 광범위하기 쉽다.

.2 잠재적인 리스크 이벤트(Potential risk events).

잠재적인 리스크 이벤트는 자연재해나 프로젝트에 영향을 끼칠 수 있는 특정 팀 구성원의 이탈과

같은 별개의 사건이다. 잠재적인 리스크 이벤트는 사건의 확률이나 손실의 규모가 상대적으로 클
때 리스크의 출처와 더불어 규명되어야 한다. 잠재적인 리스크 이벤트는 적용분야가 특별히
정해진 것은 아니지만(application-area-specific), 일반적으로 보편적인 리스크는 존재한다.
예를 들면
·프로젝트에 있어서 결핍(need)을 제거할 새로운 기술의 개발은 전자분야에서는
보편적인 것이지만 부동산개발에서는 드문 것이다.
·큰 폭풍에 의한 손실은 건설에서는 보편적인 것이지만 생물공학에서는 드문 것이다.

잠재적인 리스크의 기술은 일반적으로 다음에 관한 견적을 포함해야 한다.

(a) 그 출처으로부터 리스크가 발생할 확률,
(b) 발생가능한 결과물의 대안,
(C) 사건의 예상시기,
(d) 예상 빈도(예를 들면 잠재적인 리스크가 한번 이상 발생할 것인가?)

잠재적 리스트 이벤트에 대한 설명(description)은 일반적으로 다음에 대한 견적을 포함해야

한다
(a) 그 출처로부터 리스크 이벤트가 발생할 확률,
(b) 발생가능한 결과의 범위,
(c) 예상시기,
(d) 그 출처에 의한 리스크 이벤트의 예상 빈도
확률과 결과 양자는 연속적인 기능 또는 별개의 기능으로서 상세될 수 있다. 게다가, 초기

88 of 109
프로젝트 단계동안에 만들어진 확률과 결과(outcome)에 대한 견적은 프로젝트의 후반부에
만들어지는 그것에 비해 광범위하기 쉽다.

.3 리스크 증상(Risk symptoms).

가끔 방아쇠(trigger)로 불리는 리스크 증상은 실제적인 리스크 이벤트의 간접적인 표현

(manifestation)이다. 예를 들면, 빈약한 사기(poor morale)는 임박한 일정지연의 조기경보가 될
수 있고 또는 초기의 액티비티상에서 비용의 초과는 조악한 견적을 나타낼 수도 있다.

.4 다른 프로세스의 입력자료(Inputs to other processes).

리스크 규명 프로세스는 다른 분야에서 그 이상의 액티비티에 있어서 요구조건(need)을 규명할

것이다. 예를 들면, 작업분류체계는 적절하게 리스크를 규명하기에 충분히 상세하지 않을 것이다.
리스크는 종종 제한사항이나 가정으로써 다른 프로세스의 입력자료가 된다.

11.2 리스크 계량(Risk Quantification)

리스크 계량은 발생가능한 프로젝트 결과물의 범위를 산정하기 위한 리스크와 리스크

상호작용들을 평가하는 것을 포함한다. 이것은 기본적으로 어떤 리스크 이벤트에 대응할 수
있는지에 대해 결정하는 것과 관련된다. 이것은 포함하고 있는 다수의 요소들 때문에 복잡하지만
아래의 것들이 전부는 아니다.
·기회와 위험은 예측못한 방법으로 상호작용 할 수 있다.(예를 들면 공기지연은 전반적인
프로젝트의 공기를 줄이도록 새로운 전략을 고려하도록 할 것이다.)
·하나의 리스크는 다양한 결과의 원인이 된다.(주요한 구성부재의 조달지연은 공사비초과,
공기지연, 벌금, 저품질의 생산물을 만들어낸다.)
·한 공사관련자의 기회는 다른 공사관계자에게 위협이 될 수 있다.
·사용되는 수학적 기법은 정확도와 신뢰도의 잘못된 영향(false impression)을 창출할 수 있다.

11.2.1 리스크 계량의 투입자료(Inputs to Risk Quantification)

.1 공사관련자의 리스크 포용력(Stakeholder risk toleratances).

상이한 조직들과 상이한 개인들은 리스크에 관한 상이한 포용력을 가지고 있다. 예를 들면,
·고수익을 가지는 회사는 10억불짜리 계약에 대한 제안서(proposal)를 작성하는데
500,000불을 기꺼이 쓸 수 있는 반면, 손익이 거의 없는 회사는 그렇지 않다.

·한 조직은 초과(overrunning)확률이 15%라는 견적을 높은 리스크로 파악하는 반면,

89 of 109
다른 조직은 낮은 리스크로 파악한다.
공사관련자의 리스크 포용력은 리스크 계량에 대한 투입과 결과 양자에 있어서 스크린(screen)을
제공한다.

.2 리스크의 출처(Source of risk).

.3 잠재적인 리스크(Potential risk events)

.4 비용견적(Cost estimates).

.5 액티비티 공기 산정(Activity duration estimates)

11.2.2 리스크 계량의 도구와 기법

.1 기대 금전가치(Expected monetary value).

리스크 계량을 위한 도구로써 기대 금전가치는 두 수의 결과6(product of two numbers)이다.

·리스크 이벤트 확률(Risk event probability) - 주어진 리스크 이벤트가 일어날
것인가에 대한 확률의 견적
·리스크 이벤트 가치(Risk event value) - 리스크 이벤트가 실제로 발생한다면
그것으로부터 발생되는 이익과 손실에 대한 견적
리스크 이벤트 가치는 유형의 것과 무형의 것 양자를 반영해야 한다. 예를 들면, A프로젝트와 B
프로젝트는 불리하게 가격책정된 제안서의 결과로써 100,000불의 실체적인 손실이라는 대등한
확률을 가지고 있다. 만약 A프로젝트가 무형의 결과가 거의 없거나 아예 없는 반면, B프로젝트는
그와 같은 손실이 수행조직을 사업에서 퇴출시킬 것이 예상된다면, 두 리스크는 동등한 것이
아니다.
유사하게, 이 계산에서 무형의 것을 포함하는 것에 대한 실패는 높은 확률의 적은 손실을 낮은
확률의 큰 손실과 동일시함으로써 결과를 심하게 왜곡할 수 있다.
기대 금전가치는 리스크 이벤트가 개별적으로 또는 무리지어, 병행하여 또는 순차적으로 발생할
수 있기 때문에 일반적으로 다음단계의 분석(further analysis)을 위한 투입자료로써 사용된다.

.2 통계적 합계(Statistical sums).

통계적인 합계는 개별적인 작업항목(work item)에 대한 비용견적으로부터 총 프로젝트 비용의

범위를 계산하기 위해 사용될 수 있다.
총 프로젝트 비용의 범위는 대안 프로젝트 예산이나 제안가격(proposal prices)의 상대적인
리스크를 계량하기 위해 사용될 수 있다. 그림 11-2는 프로젝트 범위견적을 계산하기 위한

90 of 109
"method of moments"기법의 이용을 보여준다.

.3 시뮬레이션(Simulation).

시뮬레이션은 시스템의 반응이나 성능을 분석하기 위해 시스템의 표현(representation)이나

모델을 사용한다. 프로젝트에서 시뮬레이션의 가장 일반적인 형태는 프로젝트의 모델로써
프로젝트 네트워크를 사용하는 일정 시뮬레이션(schedule simulation)이다. 대개의 일정
시뮬레이션은 몬테카를로 분석의 어떤 형태에 기반한다. 일반관리(general management)로부터
개작된(adapted from) 이 기법은 그림 11-3에서 설명된 것처럼 계산된 결과들의 통계적 분포
(distribution)를 제공하기 위해 프로젝트를 여러번 수행한다.
일정 시뮬레이션의 결과는 다양한 일정 대안, 상이한 프로젝트 전략, 네트워크를 통한 상이한
경로(path), 개별 액티비티의 리스크를 계량하는데 사용될 수 있다.
일정 시뮬레이션은 CPM이나 PERT와 같은 전통적인 수학적 분석기법들이 경로 수렴(path
convergence)를 설명하지 못하고 프로젝트의 공기를 과소평가하기 때문에 대규모이거나 복잡한
프로젝트에 사용되어야 한다.
몬테카를로 분석과 시뮬레이션의 다른 형태는 가능한 비용결과(possible cost outcomes)의
범위를 산정하기 위해서도 사용될 수 있다.

.4 의사결정나무(Decision trees).

의사결정나무는 다이어그램으로써 의사결정자들이 이해하도록 의사결정(decision)과 관련 기회

(associated chance events)간 핵심적인 상호작용을 기술한 것이다. 의사결정나무의 가지는 다른
의사결정이나 기회(chance event)를 나타낸다. 그림 11-5는 의사결정나무의 예이다.
.5 전문가의 판단(Expert judgement). 전문가의 판단은 종종 위에서 설명한 수학적 기법을
대신하거나 수학적 기법에 더해서 적용될 수 있다. 예를 들면, 리스크는 발생확률이 높다.
중간이다, 낮다로 설명될 수 있고, 영향이 심각하다, 보통이다. 제한적이다 등으로 설명될 수
있다.

11.2.3 리스크 계량의 결과물(Outputs from Risk Quantification)

.1 추구할 기회, 대응할 위협(Opportunities to pursue, threats to respond to).

리스크 계량으로부터의 주요한 결과물은 추구할 기회와 주의를 필요로 하는 위협에 대한

목록이다.

.2 무시할 기회, 받아들일 위협(Opportunities to ignore, threats to accept).

91 of 109
리스크 계량 프로세스는
(a) 리스크의 출처와 프로젝트 관리팀이 의식적으로 수용하거나 무시하기로 결정한 리스크
이벤트(risk events),
(b) 누가 그런 결정을 하였는가 에 대해 문서화하여야 한다.

11.3 리스크 대응책 개발(Risk Response Development)

리스크 대응책 개발은 기회에 대한 고취단계와 위협에 대한 대응책을 규정하는 것을 포함한다.

위협에 대한 대응책은 일반적으로 3분류로 나뉜다.
·회피(Avoidance) - 일반적으로 원인을 제거함으로써 특정한 위협을 제거. PM팀이 모든
리스크를 제거할 수는 없지만 특정한 리스크 이벤트는 제거될 수 있다.
·완화(Mitigation) - 발생확률을 줄이거나 리스크 이벤트 가치를 줄이거나 또는 양자를
사용해서 리스크 이벤트의 기대 비용가치를 줄이는 것.
·수용(Acceptance) - 결과를 받아들임. 수용은 능동적이 될 수도 있고 수동적이 될 수도 있다.

11.3.1 리스크 대응책 개발의 입력자료

.1 추구할 기회, 대응할 위협(Opportunities to pursue, threats to respond to).

.2 무시할 기회, 받아들일 위협(Opportunities to ignore, threats to accept). 이 항목들은

리스크 관리계획에서 문서화되어야 하기 때문에 리스크 대응책 개발 프로세스의 입력자료가 된다.

11.3.2 리스크 대응책 개발의 도구와 기법

.1 구매(Procurement).

외부의 즉각적인(immediate) 프로젝트 조직으로부터 상품이나 용역을 획득하는 구매는 종종 어떤

종류의 리스크에 대한 적절한 대응책이다. 예를 들면, 특수한 기술의 사용과 관련한 리스크는 그
기술에 대한 경험을 가진 조직과 계약하는 것에 의해서 완화될 수 있다.
구매는 종종 하나의 리스크를 다른 것으로 교체하는 것을 포함한다. 예를 들면, 정액계약에 의한
비용 리스크의 완화는 판매자(seller)가 수행할 능력이 없다면 일정에 관한 리스크를 발생시킬
것이다. 유사하게, 모든 기술적 리스크를 판매자에게 전가하려는 시도는 받아들이기 어려울
정도의 높은 비용제안을 야기할 수 있다.

.2 Contingency 계획수립(Contingency planning).

예비비 계획은 만약에 규명된 리스크가 발생한다면 취해야 할 조치단계를 규정하는 것을

92 of 109
포함한다.

.3 대안 전략(Alternative strategies).

리스크는 계획된 접근방식을 바꾸는 것에 의해 예방하거나 피할 수 있다. 예를 들면, 부가적인

설계작업은 이행단계(implementation)나 시공단계 동안에 다루어져야 하는 많은 변경들을 감소할
수 있다. 많은 응용분야는 다양한 대안 전략의 잠재적 가치에 대한 상당한 문헌(substantial body
of literature)을 가지고 있다.

.4 보험(Insurance).

보험 또는 보증과 같은 보험류의 약정들이 종종 어떤 범주의 리스크를 처리하는데 활용가능하다.

활용할 수 있는 적용범위의 유형과 적용범위의 비용은 적용분야에 따라 다양하다.

11.3.3 리스크 대응책 개발의 결과물(Outputs from Risk Response Development)

.1 리스크 관리 계획(Risk management plan).

리스크 관리 계획은 프로젝트를 통하여 리스크를 관리하는데 사용되도록 절차를 문서화하여야

한다. 리스크 규명과 리스크 계량 프로세스를 문서화하는 것과 더불어, 리스크 관리 계획은
리스크의 다양한 분야를 관리하는데 대한 책임이 누구에게 있으며, 최초의 규명과 계량의
결과물이 어떻게 유지되어야 하는지, 예비비 계획이 어떻게 수행되어야 하는지, 어떻게 비축금
(reserves)이 할당되어야 하는지를 다루어야 한다.
리스크 관리 계획은 프로젝트의 요구에 기초하여 공식적 또는 비공식적, 매우 상세하거나
개괄적인 구조일 수 있다. 리스크 관리 계획은 전반적인 프로젝트 계획의 부수적인 요소이다.

.2 다른 프로세스의 입력자료(Inputs to other process).

선정되거나 제안된 대안 전략, 예비비 계획, 예상 구매, 기타 리스크 관련 결과물은 전부 다른

지식분야에 있어서 적절한 프로세스로 피드백되어야 한다.

.3 Contingency 계획(Contingency plan).

예비비 계획은 만약 규명된 리스크가 발생한다면 취해야 할 미리 규정된 조치 단계(pre-defined

action steps)이다. 예비비 계획은 일반적으로 리스크 관리계획의 일부이지만 전반적인 프로젝트
계획의 다른 부분과도 통합될 수 있다.

93 of 109
.4 비축금(Reserves).

비축금은 프로젝트 계획에서 비용이나 일정에 대한 리스크를 완화하기 위한 준비이다. 이 용어는

어떤 유형의 리스크가 완화되기로 되어있는가에 대한 보다 상세한 것을 제공하기 위해 수식어구
(modifier)와 함께 사용된다. 수식어의 특별한 의미는 종종 적용분야에 따라 다르다. 게다가
비축금의 사용과 비축금에 포함되어야 할 것에 대한 정의는 적용분야의 특성(application-area-
specific)이다.

.5 계약적 협정(Contractual agreements).

계약적 협정은 위협을 피하거나 완화하기 위해서 적절한 보험, 용역, 기타 항목에 가입하는 것일
수 있다. 계약내용 및 조건(contractual terms and conditions)들은 리스크 저감의 정도에 상당한
영향을 끼칠 것이다.

11.4 리스크 대응 관리(Risk Response Control)

리스크 대응 관리는 프로젝트의 과정 중에 리스크에 대응하기 위해서 리스크 관리 계획을

집행하는 것을 포함한다. 변경이 발생하면, 규명, 계량, 대응이라는 기본적인 체계(basic cycle)
가 반복된다. 아주 철저하고 포괄적인 분석도 모든 리스크와 확률을 정확하게 규명할 수 없다는
것을 이해하는 것이 아주 중요하다. 관리(control)와 반복이 필요하다.

11.4.1 리스크 대응의 투입자료(Inputs to Risk Response Control)

.1 리스크 관리 계획(Risk management plan).

.2 실제적인 리스크 이벤트(Actual risk events).

규명된 리스크 이벤트의 일부는 발생할 것이고 나머지는 발생하지 않을 것이다. 발생하는 것들은
실제적인 리스크 이벤트이거나 리스크의 출처이므로, 프로젝트팀은 개발된 대응이 수행될수
있도록 하기 위해 규명된 리스크가 발생했다는 것을 인지해야 한다.

.3 부가적인 리스크 규명(Additional risk identification).

프로젝트 수행이 측정되고 보고됨에 따라, 이전에는 규명하지 못했던 잠재적인 리스크 이벤트나
리스크의 출처가 나타날 수 있다.

11.4.2 리스크 대응 관리의 도구와 기법

94 of 109
.1 Workarounds.

Workarounds 는 부정적인 리스크 이벤트에 대한 계획되지 않은 대응이다. Workarounds는 대응이

리스크 이벤트가 발생하기에 앞서서 규정되지 않았다는 의미에서 계획되지 않은 것이다.

.2 부가적인 리스크 대응책 개발(Additional risk response development).

리스크 이벤트가 예견되지 않았다면, 또는 그 영향이 예상보다 훨씬 크다면, 계획된 대응은

적절하지 않을 것이고, 대응 개발 프로세스 외에 아마도 리스크 계량 프로세스를 반복하는 것이
필요할 것이다.

11.4.3 리스크 대응 관리의 결과물(Outputs from Risk Response Control)

.1 수정조치(Corrective action).

수정조치는 우선적으로 계획된 리스크 대응을 수행하는 것으로 이루어진다.

.2 리스크 관리 계획의 갱신(Updates to risk management plan).

예상된 리스크 이벤트가 발생하거나 발생하지 않음에 따라, 그리고 실제적인 리스크 이벤트
영향이 평가됨에 따라, 리스크 관리 계획의 다른 측면과 마찬가지로 확률과 가치의 견적은
갱신되어야 한다.

12장 프로젝트 조달 관리 (PROJECT PROCUREMENT MANAGEMENT)

프로젝트 조달관리는 수행조직의 외부로부터 상품(goods)이나 서비스를 획득하기 위해 필요한

프로세스를 포함한다. 간략하게 말하면, 상품이나 서비스는 그것이 하나이건 여러 개이건 간에
일반적으로는 "생산품(product)"이라고 간주된다. 그림 12-1은 다음의 주요 프로세스에 대한
개관을 보여준다.
12.1 조달계획(Procurement Planning) - 무엇을 획득(procure)할 것이며 언제할 것인가를
결정하는 것
12.2 수배계획(Solicitation Planning) - 생산품의 요구사항을 문서화하고 장래에 필요한
(potential) 자원을 확인하는 것
12.3 수배(Solicitation) - 견적서(quotation), 입찰서(bids), 신청서(offers), 혹은
정당한 제안서(proposals)를 획득하는 것

95 of 109
 12.4 자원선택(Source Selection) - 잠정적인 판매자들 중에서 선택하는 것
12.5 계약관리(Contract Administration) - 판매자들과의 관계를 관리하는 것
12.6 계약완료(Contract Close-out) - 끝나지 않은 항목(open item)의 해결을 포함한
계약의 완료 및 문제해결

이런 과정들은 각 프로세스끼리는 물론 다른 지식영역들의 프로세스들과도 상호작용을 한다. 각

프로세스는 프로젝트의 요구에 기반을 둔 개인이나 그룹의 노력과도 관련이 있다. 각 프로세스는
모든 프로젝트 단계에서 적어도 한번은 발생한다. 여기서 설명하고 있는 프로세스들이 비록
분리된 요소들로 보일 수도 있지만, 실제에 있어서는 서로 겹쳐지며, 상호작용을 한다. (3장
참조)
프로젝트 조달관리는 구매자-판매자 관계에서 구매자의 시각으로 논의된다. 구매자-판매자
관계는 하나의 프로젝트에서도 다양한 수준으로 존재할 수 있다. 적용분야에 따라 판매자(the
seller)는 수급업자(a contractor), 매각인(a vendor), 공급업자(a supplier) 등으로 불려진다.
다음과 같은 경우 판매자는 그들의 일을 프로젝트처럼 관리할 것이다:
·구매자가 고객이 되어 이로 인해 그 사람이 판매자에게 주요한 관련인사가 되는 경우
·판매자의 프로젝트관리팀에 대해 프로젝트관리의 모든 프로세스에서 고려해야만 하는 경우
·계약의 약관과 조건이 판매자의 프로세스 중 많은 부분에서 주요 입력자료가 되는 경우
이번 장에서는 판매자가 수행조직의 바깥에 있다고 가정한다. 그러나 논의의 대부분은
수행조직단위와 관련된 공식적인 동의(agreements)에 대해서도 동등하게 적용된다. 비공식적인
동의의 경우에는 더욱 잘 적용될 것이다.

12.1 조달계획 (Procurement Planning)

조달계획은 프로젝트 조직의 외부로부터 생산품이나 서비스를 조달하는 것이 과연 프로젝트의

요구사항을 가장 잘 만족시키는 것인지 확인하는 프로세스이다. 그것은 조달을 할 것인지 말
것인지, 어떻게 할 것인지, 무엇을 할 것인지, 얼마나 할 것인지, 언제 할 것인지 등을 고려하는
것이다.
프로젝트가 수행조직의 외부로부터 생산품이나 서비스를 획득하는 경우, 수배계획(12.2 절)부터
계약완료(12.6 절)까지의 프로세스가 각 생산품이나 서비스 항목별로 한번씩은 수행될 것이다.
프로젝트관리팀은 필요하다면 계약이나 조달분야의 전문가들로부터의 지원을 요청해야 한다.
프로젝트가 수행조직의 외부로부터 생산품이나 서비스를 획득하지 않는 경우, 수배계획(12.2 절)
부터 계약완료(12.6 절)까지의 프로세스는 수행되지 않을 것이다. 이것은 수행조직이
프로젝트기술을 공유하는 것을 거부하는 경우의 연구·개발 프로젝트나 외부의 자원을 찾아
관리하는 것이 장래의 비용절감 액보다 비용이 더 드는 경우의 소규모 사내 프로젝트에서
그러하다.
조달계획은 장래의 하도급계약에 대하서도 고려해야 한다. 특히 구매자가 하도급 결정에 대해서
일정정도 영향력을 가지거나 관리하기를 희망하는 경우에 그러하다.

96 of 109
12.1.1 조달계획의 입력자료

.1 범위진술(Scope statement)

범위진술(5.2.3.1 절)은 현재 프로젝트의 한계를 나타낸다. 그것은 조달계획 중에 고려해야할

프로젝트의 요구사항이나 전략에 대한 주요정보를 제공한다.

.2 생산품묘사(Product description)

프로젝트의 생산품에 대한 묘사(5.1.1.1 절)는 조달계획 중에 고려되어야할 기술적 사항 등에

대한 주요정보를 제공한다.
일반적으로 생산품묘사는 작업에 대한 진술(statement of work)보다 광범위하다. 생산품묘사는
프로젝트의 궁극적인 최종 생산품을 나타내는 것이다; 작업에 대한 진술(12.1.3.2 절)은 판매자에
의해서 프로젝트에 제공되는 생산품의 양(portion)을 나타내는 것이다. 그러나, 수행조직이
완전한 생산품을 조달하기로 결정했다면 두 용어사이의 차이는 흐려진다(moot).

.3 조달자원(Procurement resources)

만약 수행조직이 공식적인 계약업무그룹을 가지고 있지 않다면, 프로젝트팀은 프로젝트

조달활동을 지원하기 위한 자원과 전문기술을 제공해야 할 것이다.

.4 시장상황(Market condition)

조달계획프로세스는 시장에서 이용할 수 있는 생산품과 서비스가 무엇이며, 누구에게서 얻을 수

있는지, 그것이 어떤 약관과 조건을 따르는지 고려해야만 한다.

.5 다른 계획에서의 결과물(Other planning outputs)

조달계획 중에는 다른 계획에서의 결과물을 일정정도 이용하는 것을 고려해야만 한다. 자주

고려되는 결과물은 다음과 같다: 비용과 일정의 기본(preliminary)견적, 품질관리(QM)계획,
자금흐름예측, WBS, 확인된 리스크, 인력배치계획

.6 제한(Constraints)

제한은 구매자의 선택을 제한하는 요소이다. 대부분의 프로젝트에서 가장 일반적인 제한의

하나는 자금력이다.

97 of 109
.7 가정(Assumption)

가정은 계획을 위해 그것이 사실이라고 고려한 요소이다.

12.1.2 조달계획의 도구와 기법

.1 만들 것인가-구매할 것인가의 분석(Make-or-buy analysis)

이것은 수행조직이 어떤 특별한 생산품을 비용-효과적으로 생산할 수 있는지 결정하는데

이용되는 가장 일반적인 관리기술이다. 분석의 양측 모두 간접비와 직접비를 포함한다. 예를 들어
"구매한다"측의 분석은 생산품의 구입을 위한 실제지출비용과 함께 구입 프로세스를 관리하는데
필요한 간접비용까지도 포함한다.
만들 것인가-구매할 것인가의 분석은 프로젝트의 즉각적인 요구사항뿐 아니라 수행조직의 시각도
반영한다. 예를 들어, 핵심물품(개인용 컴퓨터부터 건설용 크레인에 이르기까지)을 구입하는 것은
그것을 빌려쓰는 것보다 비용 효과면에서 나쁘다. 그러나 수행조직이 그 물품을 계속해서 쓸
필요가 있다면, 이를 구입하기 위해 할당된 비용이 빌리는 비용보다 적어질 수도 있다.

.2 전문가의 판단(Expert judgement)

전문가의 판단은 이 프로세스에서의 입력자료를 평가하기 위해 필요한 것이다. 이런 전문기술은

특수한 지식을 가지고 있는 그룹이나 개인에 의해 제공될 수 있으며 다음과 같은 곳에서 얻어진다:
·수행조직의 다른 단위
·컨설턴트
·전문가 연합이나 기술자 연합
·산업단체

.3 계약형태의 결정(Contract type selection)

구매의 형태에 따라 계약의 형태도 다양하게 적용된다. 계약은 보통 3개의 커다란 범주 중에

하나에 속하게 된다.
·정액 혹은 총액 계약(Fixed price or lump sum contract) - 이 범주는 잘 정의된
생산품에 대한 고정된 총액과 관련이 있다. 생산품 중에 일정부분이 잘 정의되지 않을 경우,
구매자와 판매자 모두가 리스크를 가진다-구매자는 기대했던 생산품을 받을 수 없고, 판매자는
이를 만들기 위해 추가의 비용을 들여야 할 수도 있다. 정액계약은 일정목표와 같은 프로젝트의
목적을 만족시키거나 초과하여 달성했을 경우 격려금도 포함할 수 있다.
·비용상환계약(Cost reimbursable contract) - 이 범주는 판매자의 실제비용에 대한

98 of 109
지급(상환금)과 관련이 있다. 비용은 일반적으로 직접비용과 간접비용으로 구분된다. 직접비용은
프로젝트의 이득이 아닌 것(the exclusive benefit)에 대해 발생한 비용이다(예를 들면 전시간
고용인원에 대한 봉급). 간접비용은 overhead cost라고도 불리며, 수행조직에 의해 사업비로
할당된 비용이다(예를 들면, 회사 경영진에 대한 봉급). 일반적으로 간접비는 직접비에 대한
백분율의 형태로 계산된다. 비용상환계약도 일정목표나 총공사비 같은 프로젝트의 목적을
만족시키거나 초과하여 달성했을 경우 격려금을 포함할 수 있다.
·단가계약(Unit price contract) - 판매자는 서비스에 대해서 사전에 정해진 단가로
지불을 받는다(예를 들어, 전문가 서비스는 시간당 70$이고, 토사제거는 cubic yard당 1.08$
이다). 계약의 총액은 공사를 완료하는데 필요한 물량에 달려있다.

12.1.3 조달계획의 결과물

.1 조달관리계획(Procurement management planning)

조달관리계획은 남아있는 조달프로세스(수배계획에서 계약완료까지)를 어떻게 관리할 것인가를

기술해야 한다. 예를 들어:
·어떤 형태의 계약을 할 것인가?
·만일 평가기준으로써의 독립견적이 필요해진다면, 누가 언제 그것을 준비할 것인가?
·만약 수행조직이 조달부서를 보유하고 있다면, 프로젝트팀은 어떠한 행동을 할 수
있는가?
·만일 표준적인 조달문서가 필요하다면, 어디서 찾을 것인가?
·복수의 공급자를 어떻게 관리할 것인가?
·조달이 일정이나 수행 보고서 등 프로젝트의 다른 측면과 어떻게 조정되어야 하는가?
조달관리계획은 프로젝트의 필요에 따라 공식적일 수도 비공식적일 수도 있고, 상세할 수도
개략적일 수도 있다. 이것은 4.1 절에서 기술한 전체 프로젝트 계획의 보충적인 요소이다.

.2 작업에 대한 진술(Statement of work)

작업에 대한 진술(SOW)은 조달항목에 대해 충분히 상세하게 설명하는 것이며, 이는 판매자가 그

물품을 제공할 능력이 있는지 결정하기 위해서이다. "충분한 상세"는 물품의 성질, 구매자의
요구사항, 계약형태 등에 따라 다양해 질 수 있다.
어떤 적용분야에서는 SOW를 다른 형태로 인식한다. 예를 들어, 어떤 관할구역 하에서는 SOW라는
용어가 명료하게 규정된 생산품이나 서비스인 조달품목이라는 의미로 이용된다. 그리고
요구사항에 대한 진술(Statement of Requirements: SOR)이란 용어는 해결해야 할 문제를 지닌
조달항목이라는 의미로 이용된다.
작업에 대한 진술은 조달프로세스가 진행되는 동안 개선되고 세련되어진다. 예를 들어, 잠정적인
(prospective) 판매자가 원래의 것보다 더욱 효율적인 방법이나 가격이 낮은 생산품을 제안할

99 of 109
수도 있다. 각각의 조달품목은 각기 분리된 SOW를 필요로 한다. 그러나 다중의 생산품이나
서비스는 하나의 조달품목으로 묶어져서 단일 SOW로 나타낼 수도 있다.
이 SOW는 가능한 명료하고, 완결되어 있으며, 일관성을 지녀야 한다. 이것은 수행 보고서 혹은
프로젝트 후 운영상의 지원 등과 같은 부차적인 서비스에 대한 기술도 포함해야 한다. 어떤
적용분야에 있어서는 SOW에 특별한 내용이나 공식상의 요구사항이 있을 수 있다.

12.2 수배계획 (Solicitation Planning)

수배계획은 수배를 지원하는데 필요한 문서를 준비하는 것과 관련이 있다. (수배에 대한

프로세스는 12.3 절에서 설명한다)

12.2.1 수배계획의 입력자료

.1 조달관리계획(Procurement management planning)

.2 작업에 대한 진술(Statement of work)
.3 다른 계획에서의 결과물(Other planning outputs) 조달계획의 일부분으로서 고려되어
수정되었던 다른 계획에서의 결과물은 수배의 일부분으로 다시 한번 검토되어야 한다. 특히
수배계획은 프로젝트 일정과 밀접하게 조정되어야 한다.

12.2.2 수배계획의 도구와 기법

.1 표준서식(Standard forms)

표준서식은 표준계약서, 조달품목에 대한 표준설명서, 필요한 입찰문서의 일부나 전체에 대한

표준화된 문서(version) 등을 포함한다. 많은 양의 조달업무를 하는 조직은 이러한 표준문서를
많이 보유하고 있어야한다.

.2 전문가의 판단(Expert judgement)

12.2.3 수배계획의 결과물

.1 조달문서(Procurement documents)

조달문서는 미래의(prospective) 판매자로부터 제안서를 청구하는 경우 사용된다. "입찰(bis)"과

"견적서(quotation)"약관은 자원선택결정을 가격에 의해서 해야 하는 경우에 일반적으로 사용된다
(상업적인 물품을 사는 경우). 반면 "제안서(proposal)"약관은 기술이나 그 방법이 가장 중요할

100 of 109
때와 같이 금전적인 고려를 할 필요가 없는 경우에 주로 사용한다(전문가 서비스를 사는 경우).
그러나 약관은 상호 교환할 수 있다. 또한, 사용약관의 의미(implication)에 대한 공인되지 않은
가정을 하지 않도록 주의하여야 한다. 다른 형태의 조달문서의 일반적인 명칭은 다음과 같다:
입찰안내서(Invitation for Bib: IFB), 입찰요청서(Request for Proposal: RFP), 견적요청서
(Request for Quotation: RFQ), 협상안내서(Invitation for Negotiation), 수급업자 착수응답
(Contractor Initial Response) 등
조달문서는 미래의 판매자가 확실하고 완결된 응답을 할 수 있도록 구성되어야 한다. 또한
그것은 관련된 작업에 대한 진술(SOW), 응답시 요구되는 형식에 대한 설명, 그리고 기타 계약상
필요한 요구사항 등을 포함해야 한다(예를 들면, 계약서 모델이나 미발표 조항의 사본).
조달문서의 내용이나 구성의 일부 혹은 전부는, 특히 그것이 정부기관에 의해서 준비되었을 경우,
법령에 의해서 정의될 수도 있다.
조달문서는 일관성을 확인할 수 있도록 엄정해야 하며, 응답들을 비교할 수 있어야 하지만,
판매자가 더 좋은 방안을 제시할 수 있을 정도의 융통성은 가지고 있어야한다.

.2 평가기준(Evaluation criteria)

평가기준은 제안의 등급을 매기고(rate) 점수를 부여하는데(score) 사용된다. 그것은 객관적일

수도 있고(예를 들면 "제안된 PMr은 규정된 PMP여야 한다"), 주관적일 수도 있다(예를 들면 "
제안된 PMr은 예전의 유사프로젝트에 대한 경험이 문서화되어 있어야 한다").
만약 조달품목이 많은 수용가능자원들로부터 쉽게 얻어질 수 있는 것이라고 알려진 것이라면,
평가기준은 구매가격(purchase price)에 의해서 제한될 수도 있다(이 문맥에서의 "구매가격
(purchase price)"은 물품의 가격뿐 아니라 배달비용 같은 부차적인 지출도 포함하는 것이다).
이런 경우가 아니라면, 기타의 기준은 통합된 평가의 지원을 위해 확인되고 문서화되어야 한다.
예를 들면:
·필요에 대한 이해 - 판매자의 제안서에 의해서 묘사된 것처럼
·전체비용 및 L.C.C. - 선택된 판매자가 가장 낮은 비용(구매비용+운영비용)으로
생산하는가?
·기술적인 능력 - 판매자가 필요한 기술과 지식을 보유하고 있는가?
·관리방법 - 판매자가 프로젝트를 성공하기 위한 절차와 프로세스를 기지고 있는가?
·재정능력 - 판매자가 필요한 재정적인 자원을 보유하고 있는가?

.3 작업에 대한 진술 갱신(Statement of work updates)

수배계획 동안 하나나 그 이상의 SOW에 대한 수정이 이루어질 수 있다.

12.3 수배 (Solicitation)

101 of 109
수배는 프로젝트의 요구사항을 어떻게 만족시킬 것인지 대해 장래의 판매자로부터 정보(입찰서와
제안서)를 얻는 것과 관련이 있다. 이 프로세스에서의 실질적인 노력의 대부분은 장래의 판매자가
지불하게 되며, 일반적으로 프로젝트에서의 지출은 없다.

12.3.1 수배의 입력자료

.1 조달문서(Procurement documents)

.2 자질이 충분한 판매자의 목록(Qualified seller lists)

어떤 조직들은 잠정적인 판매자의 정보에 대한 목록이나 파일을 보유하고 있다. 이러한 목록은
대부분 잠정적인 판매자의 관련된 경험이나 기타 특징 등에 대한 정보를 포함하고 있다.
만약 이런 목록을 쉽게 이용할 수 없다면, 프로젝트팀은 스스로의 자원을 개발해야 할 것이다.
일반적인 정보는 자료집(library directories), 관련 지역연합, 직종별 카달로그, 그리고 이와
유사한 자원들 등으로부터 얻어질 수 있다. 특수한 자원에 대한 상세한 정보는 더욱 광범위한
노력을 필요로 할 수도 있으며, 그런 노력에는 현장방문, 예전고객과의 계약(에 관한 자료) 등이
있다.
조달문서는 잠정적인 판매자의 일부 혹은 모두에게 보내질 것이다.

12.3.2 수배의 도구와 기법

.1 입찰자 회의(Bidder conference)

입찰자 회의, 혹은 수급업자 회의(contractor conference), 매각인 회의(vendor conference),

입찰전 회의(pre-bid conference)라고도 불려진다, 는 제안서를 준비하기 전 잠정적인 판매자
들과의 모임이다. 이것은 판매자들이 조달에 대해 일반적이고 명료한 이해(기술적인 요구사항,
계약상의 요구사항 등)를 하고 있는지를 확인하기 위해 사용된다. 질문에 대한 응답이 개정안
(amendment)으로써 조달문서에 통합될 수도 있다.

.2 공고(Advertising)

잠정적인 입찰자에 대한 현존목록은 신문과 같은 일반출판물에 공고를 하거나, 혹은 전문가

저널과 같은 특수출판물에 공고를 함으로써 확장될 수 있다. 어떤 관할구역에서는 일부 형태의
조달항목에 대해서 공개적인 공고를 할 것을 요구하기도 한다; 대부분의 관할구역에서는 對
정부계약의 하도급계약만을 공개적으로 공고할 것을 요구한다.

12.3.3 수배의 결과물

102 of 109
.1 제안서(Proposals)

제안서는 판매자에 의해서 준비되는 문서이며 판매자의 능력 및 필요한 생산품을 제공하겠다는

의지를 보여주는 것이다. 그것은 조달문서의 요구사항에 따라 준비되어야 한다.

12.4 자원선택 (Source Selection)

자원선택은 제공자를 선택하기 위해 입찰서나 지원서를 받아서 평가기준에 맞추어 보는 것과

관련이 있다. 이 프로세스는 일직선이 아니다:
·가격은 기성품(off-the-shelf)에 대한 기본적인 결정인자가 될 수 있다. 그러나 만약
판매자가 시의적절한 방법으로 생산품을 조달할 수 없게 된다면, 최저가격(price)이 최저비용
(cost)이 되지는 않는다.
·제안서는 종종 기술적인 부분과 상업적인(가격)측면으로 분리되어지며, 평가도 따로
한다.
·중요한 생산품에 대해서는 다중의 자원이 필요할 수도 있다.
아래의 도구와 기법은 홀로 쓰일 수도 있고, 결합되어 쓰일 수도 있다. 예를 들면, 가중치체계가
그러하다:
·표준계약에 서명할 것을 요청 받은 단일한 자원을 선택
·협상절차를 확립하기 위해 모든 제안서를 순서대로 정렬
주요한 조달품목에 대해서는 이 절차는 여러번 반복될 수도 있다. 자질을 갖춘 판매자에 대한
short list는 기본제안에 의해서 선택되어질 것이며, 그 후에 상세하고 포괄적인 제안을 통해
더욱 상세한 평가가 이루어질 것이다.

12.4.1 자원선택의 입력자료

.1 제안서(Proposals)

.2 평가기준(Evaluation criteria)

.3 조직의 방침(Organizational politices) 프로젝트와 관련된 조직의 일부 혹은 전부는

공식적이거나 비공식적인 방침을 가지고 있으며 그것은 제안서의 평가에 영향을 끼친다.

12.4.2 자원선택의 도구와 기법

.1 계약 협상(Contract negotiation)

103 of 109
계약협상은 계약에 서명하기 전 계약의 구성과 요구사항에 대해 설명하거나 상호 동의하는 것과
관련이 있다. 가능한 범위 내에서 최종계약어휘는 모든 동의사항을 반영해야 한다. 일반적으로
포함되는 주제는 책임과 권한, 적용 가능한 약관 및 법령, 기술관리방법 및 사업관리방법,
계약재정, 가격 등이지만 이것이 전부는 아니다.
복잡한 조달품목의 경우, 계약협상이 자신만의 독자적인 입력(예를 들어, issues or open item
list) 과 출력(예를 들면, memorandum of understanding)을 가진 프로세스일 수도 있다.
계약협상은 "협상(negotiation)"이라고 불려지는 일반적인 관리기술의 특수한 경우이다. 협상의
도구, 기법, 양식은 일반적인 관리관련 문헌에서 광범위하게 논의되고 있으며, 이는 계약협상에도
적용 가능한 것이다.

.2 가중치 시스템(Weight system)

가중치 시스템은 자원선택에 대한 개인적인 선입관의 영향을 최소화하기 위해 정성적인 자료를

정량화하는 방법이다. 이런 시스템의 대부분은
⑴각 평가항목별로 가중수치를 할당하고,
⑵각 기준에 따라 잠정적인 판매자를 평가한 후,
⑶평가에 의해 가중치를 중복 부여하여,
⑷전체 점수를 계산하기 위해 생산품을 총합하는 것과 관련이 있다.

.3 Screening system

Screening system은 하나 혹은 다수의 평가를 수행해야 할 필요성을 최소화하는 것과 관련이

있다. 예를 들어, 잠정적인 판매자는 제안의 나머지 사항들을 고려하기 전 PMP인 PMr을
제안하라고 요청 받을 수도 있다.

.4 독립견적(Independent estimate)

조달 조직은 수많은 조달품목에 대해서 그 조달품목이 제시한 가격을 체크하기 위해 자신만의

견적을 준비할 수도 있다. 이런 견적의 중요한 차이점은 무엇인가 하면, SOW이 받아들여지지
않거나, 잠정적인 판매자가 SOW에 대해서 오해하거나 완전히 이해하지 못한 것에 대한 지표가
된다는 점이다. 독립견적은 때때로 "should cost"견적이라고 불려진다.

12.4.3 자원선택의 결과물

.1 계약(Contract)

계약이란 판매자는 특별한 생산품을 제공할 의무가 있고, 구매자는 그것에 대한 비용을 지불할

104 of 109
의무가 있다는 상호간의 구속력 있는 동의이다. 계약은 법정에서 변상해야 하는 법적인 관계이다.
협약(agreement)는 간단할 수도 있고, 복잡할 수도 있는데 이는 생산품의 단순성과 복잡성에
따른다(항상 그런 것은 아니다). 이것은 다른 명칭으로 불려질 수도 있는데, a contract, an
agreement, a subcontract, a purchase order, 혹은 a memorandum of understanding 등이다.
대부분의 조직은 누가 조직을 대신하여 그런 계약에 서명할 것인가에 대한 방침과 절차를 가지고
있다.
비록 모든 프로젝트문서가 검토와 승인이라는 형식을 가지고 있어야 하지만, 계약이 가진 법적
구속력이라는 본성은 그것의 승인 프로세스가 훨씬 확장되어야 한다는 것을 의미한다. 모든 경우,
검토와 승인프로세스의 기본적인 초점은 그 계약어휘가 생산품이나 서비스가 요구사항을 만족시킬
것이라고 기술했는가를 확인하는데 있어야 한다. 공공기관에 의해서 수행되는 대형 프로젝트의
경우 검토프로세스는 계약에 대한 공공의 검토까지 포함할 수도 있다.

12.5 계약관리(Contract Administration)

계약관리는 판매자의 수행이 계약상의 요구조건을 만족시키는가를 확인하는 프로세스이다.

다중의 생산품과 서비스제공자를 지닌 대형 프로젝트의 경우, 계약관리의 핵심적인 부분은 다양한
제공자간의 접촉(interface)을 관리하는 것이다. 계약상의 관계라는 법적인 특성은 계약관리를
필수적인 것으로 만들며, 프로젝트관리팀은 계약관리시 행하는 행동의 법적인 의미에 대해 잘
알고 있어야 한다.
계약관리는 계약상의 관계에 대해서 적당한 프로젝트관리 프로세스를 적용하는 것과 이런
프로세스에서의 결과물을 프로젝트의 전체 관리에 통합하는 것을 포함한다. 이런 조정과 통합은
다중의 판매자와 다중의 생산품이 관련되어 있을 경우 여러 층위에서 발생할 것이다. 반드시
적용되어야 할 프로젝트관리 프로세스는 다음과 같다:
·적당한 시간에 수급업자의 작업을 인정하기 위한 프로젝트 계획 실행(4.2 절)
·수급업자의 비용, 일정, 기술적인 수행을 관찰하기 위한 수행보고서(10.3 절)
·수급업자의 생산품의 적합성을 검사하고 확인하기 위한 품질관리(QC)(8.3 절)
·변경이 적절한 승인을 받았으며 그런 변경에 대해 알려져야 할 모든 것이 알려졌음을
확인하기 위한 변경관리(4.3 절)
또한 계약관리는 재정적인 관리요소도 가지고 있다. 지급기간은 계약에 정의되어 있어야 하며,
진도와 보수 사이에 연계되어 있어야 한다.

12.5.1 계약관리의 입력자료

.1 계약(Contract)

.2 작업 결과(Work result)

105 of 109
판매자의 작업결과 -성과물이 완성되었는지 아닌지, 어느 정도의 품질기준을 만족했는지,
얼마만큼의 비용이 발생했으며 지불되었는지 등- 는 프로젝트계획 수행의 일부분으로써 모아진다.

.3 변경요청(Change request)

변경요청은 계약의 약관에 대한 변경이나 제공되는 생산품이나 서비스에 대한 기술의 수정을

포함할 것이다. 만약 판매자의 작업이 만족스럽지 못하다면, 계약의 파기에 대한 결정은
변경요청에 의해서 다루어질 것이다. 이론(異論)이 있는 변경, 즉 판매자와 프로젝트관리팀이
변경에 관한 보수에 대하여 합의하지 못하였을 경우, 은 클레임(claims), 분쟁(dispute), 혹은
appeals이라고 부른다.

.4 판매자의 청구서(Seller invoice)

판매자는 수행한 작업에 대한 지불을 요청할 때마다 송장을 제출해야 한다. 필요한 지원문서 및
송장을 만드는데 필요한 사항은 계약에 정의되어 있다.

12.5.2 계약관리의 도구와 기법

.1 계약변경관리시스템(Contract change control system)

계약변경관리 시스템은 계약의 수정에 대한 프로세스를 정의한 것이다. 그것은 문서작업,

시스템추적, 분쟁해결절차, 변경을 인정하는데 필요한 승인수준 등을 포함한다. 계약변경관리
시스템은 전체 변경관리시스템(4.3 절)과 통합되어야 한다.

.2 수행 보고서작성(Performance reporting)

수행 보고서는 어떻게 해서 판매자가 계약의 요구사항(objectives)을 효율적으로 완수하였는지에

대한 정보를 가지고 있는 관리를 제공하는 것이다. 계약수행보고서는 10.3절에서 설명한 전체
프로젝트 수행보고서와 통합되어야 한다.

.3 지급시스템(Payment system)

일반적으로 판매자에 대한 지불은 수행조직의 지불용 계정시스템(the accounts payable system)

에 의해서 이루어진다. 많거나 복잡한 조달 요구사항을 지닌 대규모 프로젝트의 경우에는
독자적인 시스템을 개발할 수도 있다. 어떤 경우에라도 시스템은 프로젝트팀에 의한 정당한
검토와 승인을 거쳐야한다.

106 of 109
12.5.3 계약관리의 결과물

.1 교환문서(Correspondence)

계약약관 및 계약조건은 종종 구매자/판매자간의 의사소통에 대한 서면으로 된 문서를

요구하기도 한다. 그런 것에는 불만족스러운 수행에 대한 경고나 계약변경 등이 있다.

.2 계약변경(Contract change)

변경(승인된 것이나 승인되지 않은 것)은 적당한 프로젝트계획과 프로젝트 조달프로세스로

되돌아가게 되며, 프로젝트 계획 혹은 다른 관련 문서는 적당히 갱신된다.

.3 지불요청(Payment request)

이것은 프로젝트가 외부의 지불시스템을 이용하고 있다고 가정한 것이다. 만약 프로젝트가

자신의 내부 시스템을 보유하고 있다면, 여기에서의 결과물은 단순히 "지불(payments)"이 될
것이다.

12.6 계약종료(Contract Close-out)

계약종료는 행정적인 종료(10.4 절)과 유사하다. 그것은 생산품의 확인(완성된 모든 작업이

정확하고 만족스럽게 되었는가?)과 행정적인 종료(최종결과를 반영하기 위해 기록을 갱신하는
것과 미래에 이용하기 위해 그런 정보를 보관하는 것) 모두와 관련이 있다. 계약약관 및
계약조건에서 계약종료에 대한 것을 기술할 수도 있다. 계약의 조기해지는 계약종료의 특수한
형태이다.

12.6.1 계약종료의 입력자료

.1 계약증거서류(Contract documentation)

계약증거서류는 계약서 그 자체와, 모든 지원일정표, 요구되고 승인된 계약변경들, 기타

판매자에 의해 개발된 기술적 서류, 판매자 수행보고서, 송장이나 지급기록 같은 재정관련 문서,
그리고 기타 계약관련 검사의 결과 등과 같은 것을 포함하지만 이것이 전부는 아니다.

12.6.2 계약종료의 도구와 기법

107 of 109
.1 조달 감사(Procurement audit)

조달감사는 조달계획부터 계약관리까지의 조달프로세스에 대한 구조적인 검토이다. 조달 감사의

목적은 성공과 실패의 원인이 당 프로젝트의 다른 조달항목 혹은 당 수행조직의 다른 프로젝트에
전가될 수 있는지를 확인하기 위함이다.

12.6.3 계약종료의 결과물

.1 계약파일(Contract file)

최종 프로젝트 기록을 포함한 완성된 일련의 기록이 준비되어야 한다.

.2 공식적인 승인과 종료(Formal acceptance and closure)

계약관리를 책임지고 있는 개인이나 조직은 판매자에게 계약이 완료되었음을 알리는 공식적인

서면통지서를 제공하여야 한다. 공식적인 승인과 종료에 필요한 요구사항은 일반적으로 계약에
정의되어 있다.

1) A stakeholder is defined as some individual or organization that has a vested interest

in the sucessful completion of a project. 출처: Partnering for Sucess, Thomas R. Warne

2) 데밍의 정의: "품질관리란 가장 유용하게 또한 구매자가 요구하는 제품을 가장 경제적으로

생산하는 방법을 말한다" - 경영주체로서의 품질관리
화이겐바움의 정의: "종합적 품질관리(TQM)란 모든 소비자의 만족을 고려한 가장 경제적인
수준으로 매매(賣買), 기술, 생산 및 서비스를 할 수 있도록 조직내의 여러 부분의 품질개발,
품질유지, 및 품질개선 노력을 종합하는 효과적인 체계이다" - 경영 전반에 걸친 조직의 체계를
통해 본 품질관리
신현식, "공사관리핸드북", 태림문화사, 1997, pp. 251-252

3) BCWS 는 실행할 물량 ×실행할 단가, 건설관리 및 경영, 보성각, p 311

4) ACWP는 실제물량 ×실투입단가, 건설관리 및 경영, 보성각, p 312

5) BCWP는 실제물량 × 실행할 단가, 건설경영 및 관리, 보성각, p 312

6) 두 수의 결과라 함은 리스크 이벤트 확률과 리스크 이벤트 가치의 곱에 의해서 EMV가 계산되기
때문으로 생각됨.

108 of 109
109 of 109