Professional Documents
Culture Documents
(경영) 프로젝트 관리자의 책
(경영) 프로젝트 관리자의 책
(경영) 프로젝트 관리자의 책
1 of 109
이 문서는 또한 다음과 같은 전문적인 개발 프로그램에 대해 일관성 있는 구조를 제공하기 위해
PMI에 의해서 사용되고 있다.
·PMPs의 인증
·프로젝트 관리에서 학위 수여 교육 프로그램의 인정
·인간에 의해 수행된다.
·제한된 자원에 의해 제한된다.
·계획, 수행, 관리된다.
2 of 109
1.2.1. 임시적(Temporary)
3 of 109
각 프로젝트의 결과가 유일하기 때문에 제품 또는 서비스를 구별하는 특성들이 점진적으로 상세
(정교)해진다.
4 of 109
프로젝트 관련자의 필요와 기대를 충족 또는 초월한다는 것은 다음과 같은 여러 가지 요건의
균형을 추구하는 것을 포함한다.
4장, 프로젝트 통합관리는 프로젝트의 다양한 요소들이 적정하기 위한 필요한 절차를 다룬다.
5 of 109
절차를 다룬다.
8장, 프로젝트 품질관리는 수행되는 프로젝트의 요구를 만족시키기 위해 필요한 절차를 다룬다.
9장, 프로젝트 인적자원 관리는 프로젝트에 참여한 사람들의 가장 효과적인 이용에 필요한
절차를 다룬다.
11장, 프로젝트 리스크 관리는 프로젝트 리스크를 파악, 분석 그리고 대응하는 것과 관련된
절차를 다룬다.
12장, 프로젝트 구매 관리는 수행조직 외부에서의 상품과 서비스를 확보하기 위해 필요한 절차를
다룬다.
6 of 109
특정 유형의 노력은 프로젝트와 밀접하게 관련되어 있다. 이러한 관련된 일(undertaking)은
다음과 같다.
1) Program
프로그램은 개별적으로 관리해서는 얻을 수 없는 이익을 확보하기 위해 조정된 방법으로
관리되는 프로젝트의 집합이다. 대부분의 프로그램은 또한 지속적인 작업(operation) 요소를
포함하고 있다. 예를 들면
·"XYZ" 항공기 프로그램은 항공기 분야의 지속적인 제조와 지원뿐만 아니라 항공기를 설계하고
개발하기 위한 프로젝트 또는 프로젝트들을 포함한다.
·대부분의 전자 회사는 "프로그램 관리자"가 두고 있으며 이들은 각각의 제품발매(프로젝트)
뿐만 아니라 시간이 지나 다중적인 제품발매(지속적인 작업)의 조정에 대한 책임이 있다.
2) 하위 프로젝트(sub-project)
7 of 109
2.1 Project Phase and The Project Life Cycle
8 of 109
이전에 시작된다. 이러한 단계의 중복 실무를 fast tracking이라 부른다.
1993년 2월에 개정된 미국 국방성 훈령 5000.2은 그림 2-2에 설명한 것처럼 방어시설 확보의
마일스톤과 단계를 규정하고 있다.
·임무 필요의 결정 - 개념조사의 승인으로 종료
·개념 탐색과 정의 - 개념 논증 승인으로 종료
·논증과 확인 - 개발승인으로 종료
·엔지니어링과 제조 개발 - 생산 승인으로 종료
·생산 및 배치 - 지속적인 운영 및 지원과 중복
9 of 109
2) Construction(건설)
·타당성 - 프로젝트 공식화, 타당성 조사, 그리고 전략적 설계 및 승인. 이 단계에서 수행할
것인가 아닌가의 결정을 하게 된다.
· 계획 및 설계 - 기본설계, 비용과 일정, 계약내용과 조건, 상세 계획. 이 단계에서 주요
계약이 이루어진다.
·생산 - 제조, 조달, 토목공사, 설치, 그리고 시험. 이 단계에서 시설은 실질적으로 완성된다.
·인계와 시험가동 - 최종 시험과 유지. 이 단계에서 시설이 완전히 운영된다.
3) Pharmaceutical(제약)
Muench는 그림 2-5와 같이 소프트웨어 개발을 4개의 주기와 4분면을 가진 나선형 모델로 설명하고
있다.
·개념 증명 주기
·첫 번째 구축 주기
·두 번째 구축 주기
·최종 주기
프로젝트 관련자는 프로젝트에 적극적으로 참여되는 개인과 조직으로 그들의 관심은 프로젝트
수행 또는 성공적인 프로젝트 완성에 긍정적 또는 부정적인 영향을 미치게 된다.
프로젝트 관리팀은 프로젝트 관련자를 파악해야 하며, 그들의 요구와 기대가 무엇인지를
결정해야 하고, 프로젝트를 성공으로 이끌기 위해 그들의 기대를 관리하고 영향을 주어야 한다.
10 of 109
·프로젝트 관리자 - 프로젝트 관리에 책임있는 자
·고객 - 프로제트 결과를 이용하게 될 개인 또는 조직
·수행 조직 - 프로젝트의 작업을 수행하는데 직접적으로 그 직원이 참여한 기업체
·스폰서 - 프로젝트에 현금 또는 물품으로 재정적 자원을 지원하는 수행조직내의 개인 또는
집단
이외에도 프로젝트 관련자의 명칭과 범주는 아주 다양하다. 즉 외부와 내부, 발주자와 자금주,
공급자와 계약자, 팀원과 그의 가족, 정부 부서와 지방방송국, 시민, 임시 또는 영구 로비 조직,
사회 등. 프로젝트 관련자의 명칭 또는 분류는 주로 어떤 조직 또는 집단이 자신들을 프로젝트
관련자로 바라보는가를 파악하는 데 도움이 된다. 프로젝트 관련자의 역할과 책임은 엔지니어링
회사가 설계하고 있는 플랜트의 금융을 제공할 때처럼 중복될 수도 있다.
프로젝트 관련자들은 결국에는 갈등이 될 수 있는 매우 상이한 목적을 가지고 있기 때문에
이들의 기대를 관리하는 것이 어렵다.
11 of 109
프로젝트 관리팀은 어떻게 조직 체계가 프로젝트에 영향을 주는 가를 명확히 알아야 한다.
대부분의 조직들은 독특하고 기술할 수 있는 문화를 개발해 왔다. 이러한 문화는 그들의 공유된
가치, 표준, 신념, 그리고 기대, 그리고 그들의 정책과 절차 등에 반영되어 있다. 조직 문화는
종종 프로젝트에 직접적인 영향력을 가지고 있다.
12 of 109
다양한 기능부서의 전임 직원을 포함할 것이고, 그 자체의 운영절차를 개발할 것이며, 표준화되고
공식화된 보고체계를 운영할 것이다.
2.4.1 Leading
13 of 109
다양한 시간에 다양한 사람에 의해 발휘되어야 한다. 리더십은 프로제트의 모든 수준(프로젝트
리더십, 기술적 리더십, 팀 리더십)에서 발휘되어야 한다.
2.4.2 Communicating
의사소통은 정보의 교환을 포함한다. 전달자는 수신자가 정확히 받을 수 있도록 정보를 명확히,
모호하지 않게, 완전하게 할 책임이 있다. 수신자는 정보가 완전하게 전달되었고 정확히
이해했다는 것을 확실히 할 책임이 있다. 의사소통은 많은 차원을 가진다. 즉 다음과 같다.
2.4.3 Negotiating
14 of 109
·계약 내용과 조건
·할당(assignment)
·자원
문제정의는 원인과 징후의 구별을 필요로 한다. 문제는 내부적일 수도(주요 직원인 다른
프로젝트에 재배치된다) 또는 외부적일 수도(작업 시작에 필요한 승인이 지연된다) 있다. 문제는
기술적(제품을 설계하는 최고의 방법에 대한 의견 차이), 관리적(기능 집단이 계획에 따라
생산하지 않음), 또는 대인관계(개성 또는 스타일 충동)일 수 있다.
여기서 말하는 권력과 정치, 이 양자는 긍정적인 의미로 사용되었다. Pfeffer는 힘(power)은 "
행동에 영향을 주는, 사상(event)의 과정을 변화시키는, 저항을 극복하는, 그리고 그렇지 않다면
할 수 없는 일을 할 수 있도록 하는 잠재적인 능력"으로 정의한다. 이와 마찬가지로 Eccles는 "
정책은 서로 아주 상이한 관심을 가진 사람들의 집단으로부터 집단적인 행동을 하는 것이다.
이것을 기꺼이 갈등과 불일치를 창조적으로 이용하려는 것이다. 물론 부정적인 의미는 이런
관심을 조정하기 위한 시도는 결과적으로 권력 투쟁을 가져온다는 사실과 때때로 철저하게 조직
자체의 비생산적인 수명을 가질 수 있는 조직 게임으로부터 파생된다."고 말한다.
일반적 관리와 마찬가지로 사회경제적 영향은 넓은 범위의 주제와 문제를 포함한다. 프로젝트
관리팀은 이 분야의 현재 조건과 경향이 프로젝트에 대한 주요 영향을 이해해야 한다. 즉 여기서
15 of 109
조그만 변화가 보통은 시간적 간격을 가지고 프로젝트 자체의 격변으로 바뀌어 질 수 있다. 많은
잠재적인 사회경제적 영향 중 프로젝트에 자주 영향을 미치는 몇 개의 주요 범주가 이하에 간략히
소개된다.
이 두 개념간에는 다소 모호한 영역이 있기 때문에 표준과 규정을 논의할 때에는 주의해야 한다.
2.5.2 Internationalization
문화는 "사회적으로 전달되어 온 행동 양식, 예술, 신념, 제도, 인간의 모든 작업과 사고의
결과의 총체"이다. 모든 프로젝트는 한 두 개 이상의 문화적 표준의 의미 내에서 운영되어야
한다. 이러한 영역의 영향에는 사람과 조직의 상호작용 방법에 영향을 주는 정치적, 경제적,
16 of 109
인구학적, 교육적, 윤리적, 민족적, 종교적 그리고 기타 관행, 신념, 그리고 태도를 포함한다.
17 of 109
프로젝트 관리 프로세스는 각각 하나 또는 그 이상의 프로세스를 가진 다섯 개의 그룹으로 구성될
수 있다.
18 of 109
(links)에 중점을 둠으로써, 각각의 프로세스를 인풋, 툴과 테크닉(도구와 기법), 아웃풋이라는
말로 설명할 수 있다.
3.3.1 착수 프로세스
3.3.2 계획 프로세스
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) - 다른 계획 프로세스들의 결과를 수집하고, 이것을 일관성
있는 문서에 담는다.
20 of 109
3.3.3 실행 프로세스
3.3.4 관리 프로세스
프로젝트 성능은 계획으로부터의 변화를 규정하기 위해서 규칙적으로 측정해야 한다. 변화량은
다양한 지식영역에서 관리 프로세스로 공급된다. 상당한 변화량이 관측되는 범위까지, 계획에
대한 조정은 적절한 프로젝트 계획 프로세스들을 반복함으로써 만들어진다. 예를 들면, 실수한
액티비티 마감일은 직원계획(staffing plan), 시간외 노동에의 의지 또는 예산과 일정 목표사이의
상관분석의 조정을 필요로 할 것이다. 관리는 또한 발생할 수 있는 문제점들을 예측하여
예방조치를 취하는 것을 포함한다.
관리 프로세스 그룹은 3.3.2의 계획 프로세스에서 설명한 핵심 프로세스와 촉진 프로세스를
포함한다.
그림 3-7은 다음의 프로세스들이 어떻게 상호작용하는지를 보여준다.
21 of 109
3.3.5 종료 프로세스
규정된 프로세스와 3.3절에서 설명된 상호작용은 일반적인 승인의 테스트를 충족해야 한다(
이것들은 대부분의 경우에 대부분의 프로젝트에 적용된다). 그러나 모든 프로젝트에서 모든
프로세스가 필요하지는 않을 것이고, 모든 프로젝트에서 모든 상호작용이 적용되지는 않을
것이다. 예를 들면 다음과 같다.
22 of 109
프로세스가 어느정도 통합적인 것인 반면에 4장에서 설명하는 프로세스는 근본적으로 통합적이다.
그림 4-1은 다음의 주요 프로세스들의 개요(overview)를 제공한다.
·프로젝트 집행의 지침
·프로젝트 계획 추정(가정)을 문서화
·선정된 대안들을 고려하는 프로젝트 계획 결정의 문서화
23 of 109
·프로젝트 관련자들간의 의사소통을 촉진
·내용, 정도, 그리고 시기에 관하여 핵심 관리검토 사항을 정의
·진도관리와 프로젝트 관리(project control)에 관한 기선을 제공
.3 조직 방침(organizational policies).
.4 제약요소(constraints).
제약요소는 프로젝트 관리팀의 옵션을 제한하는 요소이다. 예를 들면, 미리 정해진 예산은 범위,
직원, 일정에 관한 팀의 옵션을 매우 제한하기 쉬운 제약요소이다. 프로젝트가 계약하에 수행될
때, 계약규정은 일반적으로 제약요소가 된다.
.5 추정(가정-assumptions).
24 of 109
예를 들면, 핵심적인 사람을 이용할 수 있는 날짜가 불확실하다면, 팀은 특별한 착수 일을 추정
(가정)할 것이다. 추정(가정)은 일반적으로 어느 정도의 리스크를 수반한다.
25 of 109
프로젝트에서 수행조직의 관리는 그다지 상세하지 않은 넓은 적용범위를 필요로 하는 반면에
수급업자는 완전한 디테일을 요구할 것이다).
프로젝트 도면과 프로젝트 수행 측정 기준선 사이에는 명확한 구별이 있어야 한다. 프로젝트
도면은 프로젝트에 관해서 더욱 많은 정보들이 이용 가능하게 됨으로써 공사기간을 변경하도록
기대되는 문서나 문서의 집합이다. 수행측정기준은 간헐적으로 변경될 것이고 일반적으로 승인된
범위변경에 대해서만 변경되는 관리통제(management control)를 나타낸다.
프로젝트 도면을 구성하고 나타내는 데에는 많은 방법이 있지만, 보통 다음을 전부 포함한다(이
항목들은 다른 곳에서 상세하게 설명된다).
.2 지원도면(supporting detail).
26 of 109
이러한 자료는 프로젝트 도면의 실행 동안에 사용을 용이하게 하기 위해서 필요에 따라
구성되어야 한다.
.2 지원도면(Supporting detail).
.3 조직 방침(Organizational policies).
.4 수정조치(Corrective action).
수정조치는 예상되는 미래의 프로젝트 수행이 프로젝트 도면이 가진 기준을 따르게 하기 위해서
행하는 것이다. 수정조치는 효과적인 프로젝트 관리를 확실하게 하게 위해 필요한 feedback loop
을 완성하는 인풋으로써 다양한 통제 프로세스의 아웃풋이다.
27 of 109
Leadership, 의사소통, 협상 등과 같은 일반 관리기술들은 프로젝트 계획을 효과적으로
실행하는데 필수적인 것이다. 일반 관리기술들은 2.4에 설명되어 있다.
.1 작업 결과(Work results).
28 of 109
.2 변경 요구(Change requests).
전반적인 변경관리는
① 변경이 이롭다는 것을 보장해 주는 변경 유발요인들에게 영향을 미치고
② 변경의 발생을 결정하며
③ 변경 발생시 실질적인 변경을 관리하는 것과 관련된다. 전반적인 변경관리는 다음의 사항을
요구한다.
.3 변경요구(Change requests).
29 of 109
4.3.2 Tools and Techniques for Overall Change Control
30 of 109
수정조치를 필요로 하는지를 평가하는 것을 돕는다.
.4 부가계획(Additional Planning).
.2 수정 조치(Corrective action).
31 of 109
이 장은 착수(조직이 프로젝트의 다음단계를 시작하도록 함), 범위계획(향후 프로젝트 결정의
바탕이 되는 범위진술을 서면으로 작성), 범위정의(주요 프로젝트 성과물들을 작고 관리하기 쉬운
구성요소로 나눔), 범위확정, 범위 변경관리의 순서로 전개된다.
이런 과정들은 서로간 및 다른 지식영역의 과정들과도 상호작용한다. 각 과정은 프로젝트의
요구에 기반을 둔 각 과정의 하나 혹은 그 이상의 개개 또는 그룹으로부터 나온 노력을 포함할
수도 있다. 통상, 각 과정은 모든 프로젝트 단계에서 적어도 한번은 나온다.
비록, 과정들이 여기서는 잘 정의된 경계면을 가진 분리된(불연속적인) 요소로서 제시되었지만,
실제로는 중첩될 수도 있고, 여기에 설명되지 않은 방식으로 상호교류를 한다(과정들 간의
상호교류는 3장 참조).
프로젝트 범위 관리에 사용된 이러한 과정, 도구, 기법들은 이 장의 핵심이다. 생산물의 범위를
관리하기 위해 사용된 과정, 도구, 기법들은 적용영역에 따라 다양하고, 통상 프로젝트
생애주기의 일부로 정의된다(2. 1 참조)
프로젝트는 단일의 생산물로 구성되지만, 자체적으로 분리되면서 상호의존적인 생산물의 범위를
가진 하부요소들을 포함할 수도 있다. 예를 들면, 새로운 전화시스템은 일반적으로 4개의
하위요소(H/W, S/W, 훈련, 이행)를 포함한다.
프로젝트 범위의 완성이 계획에 대하여 측정되는 반면, 생산물 범위의 완성은 요구조건에 대해
측정된다. 범위관리의 양쪽 형태는 프로젝트의 작업이 규정된 생산물이 확실히 배달될 수 있도록
잘 통합되어야 한다.
5.1 착수(着手)
32 of 109
프로젝트를 허가했다.
·사업요구(Training Company가 수입을 증가시키기 위해 새로운 과정을 신설하는 프로젝트를
허가했다).
·고객의 요구(전기회사가 새로운 공단에 제공할 지점을 짓는 프로젝트를 허가했다).
·기술적 진보(전자회사가 Video casset recorder가 소개된 후 Video game player를 개발하는
새로운 프로젝트를 허가했다).
·법적인 요구사항(Paint 제조업체가 유독물질을 취급하는 지침을 설정하는 프로젝트를
허가했다).
이러한 자극요소들은 문제, 기회, 사업의 요구조건 등으로 불려질 수 있다. 이런 모든 용어들의
중심적인 주제는 `통상 관리진이 대응방법에 대한 결정을 내려야 한다'는 것이다.
5.1.2 착수의 도구 및 기법
33 of 109
·효용측정 방법: 비교법, 점수모델, 효용분담금액, 경제적 모델
·구속 최적화 방법: 선형, 비선형, 역학, 정수, 다목적용 프로그래밍 연산방식을 이용한
수학적 모델
5.1.3 착수단계의 결과
프로젝트 헌장은 프로젝트 외부인으로서 프로젝트의 요구에 적합한 수준의 관리자가 발행해야
한다. 그것은 프로젝트 관리자에게 조직의 자원을 프로젝트 액티비티에 적용시킬 수 있는 권한을
제공한다.
프로젝트가 계약하에서 수행될 때, 서명된 계약은 통상 판매자를 위한 프로젝트 헌장의 역할을
한다.
34 of 109
.4 가정(假定) 가정사항들은 계획의 목적으로 사실적, 실제적, 확실한 것으로 고려될
요인들이다. 예를 들어 만약, 중요한 사람이 참여하게 될 날짜가 불확실하다면, 팀은 특정
시작일을 가정해야 한다. 가정은 통상 리스크를 함유한다. 가정사항들은 여기서 확인될 수도
있고, 리스크 확인의 결과로 나올 수도 있다(11.1).
5.2 범위 계획
.1 생산물 설명 (5.1.1.1)
.2 프로젝트 헌장 (5.1.3.1)
.3 제약조건 (5.1.3.3)
.4 가정사항 5.1.3.4 참조
5.2.2 범위계획을 위한 도구 및 기법
35 of 109
브레인 스토밍과 측면사고(側面思考)다.
.4 전문가 판단 5.1.2.2 참조
5.2.3 범위계획의 결과
36 of 109
5.3 범위 정의
.1 범위진술 5.2.3.1 참조
.3 가정사항 5.1.3.4 참조
5.3.2 범위정의를 위한 도구 및 기법
.1 작업분류체계 型板(바탕-templates)
37 of 109
단계로부터 요구되는 동일한 혹은 유사한 성과물들을 가지게 될 것이다.
많은 적용영역에는 형판으로 사용될 수 있는 표준적인 혹은 반표준적인 WBS들이 있는데 예를
들면, 미국방성은 국방성 자재품목을 위한 표준 WBS들을 정의했다(그림 5-2 참조).
.2 분해(Decomposition)
분해에는 성과물들이 미래의 프로젝트 액티비티(계획, 실행, 관리, 완료)를 지원하기에 충분히
상세하게 정의될 때까지 주요 프로젝트 성과물들을 작고, 관리하기 쉬운 구성요소들로 나누는
것이 포함된다. 분해는 다음의 주요 단계들을 포함한다:
적절함의 의미는 프로젝트의 과정에 따라 달라질 수 있다. 먼 미래에 생산될 성과물의 분해는
불가능할 수도 있다. 각 요소를 위해 적당하게 상세하다면 4단계로 가고, 그렇지 않으면 3단계로
가라. 이것은 곧 요소가 다르면 분해의 수준이 달라질 수 있다는 의미이다.
38 of 109
그렇지 않다면, 구성요소들은 변경되어야 한다(더하거나, 삭제하거나, 재정의 되어야 함).
·각 항목은 명백하고 완전하게 정의되었는가? 만약 그렇지 않다면, 설명이 수정되거나
덧붙여져야 한다.
·각 항목이 적절하게 계획될 수 있는가? 예산이 책정될 수는 있는갸? 이 항목의
만족스런 완성에 대한 책임을 질 특정 조직단위(부서, 팀, 개인)에 할당될 수 있는가? 만약
그렇지 않다면, 적절한 관리통제를 위해 개정(수정)이 필요하다.
39 of 109
범위 확인은 참여자들이(후원자, 고객, 의뢰인 등) 프로젝트 범위를 받아들이는 것을 공식화하는
과정이다. 이것은 모든 것이 올바르고 만족스럽게 완성되었다는 것을 보장하기 위해 작업생산물과
결과에 대한 검토를 요구한다. 프로젝트가 초기에 끝날 경우에는, 범위확인 과정에서 완성의 수준
및 정도에 대한 확인(establish), 문서화가 이루어져야 한다. 범위확인은 작업결과를 승인하는
것과 주로 관련되기 때문에 작업결과의 적절성(correctness)과 주로 관련되는 품질관리와는(8.3절
참조) 다르다
5.4.2 범위확인의 도구 및 기법
5.5 범위변경 관리
40 of 109
.1 작업분류체계 프로젝트 범위의 기준선을 정의한다(5.3.3.1 참조)
.4 범위관리 계획 5.2.3.3 참조
41 of 109
발생하는 모든 수정을 말하는데, 빈번히 비용, 시간, 품질, 기타 프로젝트 목표에 대한 정정(
조정)을 요구한다.
범위변경은 계획과정을 통해 피드백 되고, 기술 및 계획 문서들은 필요 시마다 갱신되며,
참여자들은 적절하게 통지 받는다.
42 of 109
일치가 없다.
6.1 액티비티 정의
43 of 109
자주 새로운 프로젝트를 위한 형판으로 사용될 수 있다. 더구나, 현재 프로젝트로 부터의 WBS를
위한 액티비티 목록은 다른 유사한 WBS 요소를 위한 형판으로 사용될 수 있다.
.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이라 불린다.
.6 제약조건 6.1.1.4 참조
.7 가정사항 6.1.1.5 참조
45 of 109
시작하여야 한다.
·시작에서 종료로: "-로부터의" 액티비티는 "-로 향한" 액티비티가 종료되기 전에
시작하여야 한다.
46 of 109
액티비티(hammocks)를 가질 수도 있다.
프로젝트 네트워크 다이어그램은 빈번히 PERT 圖라고 부적절하게 불려지기도 한다(Program
Evaluation and Review Technique). PERT 圖는 오늘날 거의 사용되지 않는 프로젝트 네트워크
다이어그램의 특정 형태이다.
.1 액티비티 목록 6.1.3.1
.2 제약조건 6.1.1.4
.3 가정사항 6.1.1.5
.5 자원능력 대부분의 액티비티의 기간은 그들에게 할당된 인적·물적 자원의 능력에 상당한
영향을 받는다. 예를 들어 만약, 둘 모두가 전임으로(full-time) 할당되면 우수한 직원들은 통상
47 of 109
열등한 직원들보다 더 짧은 시간에 주어진 액티비티를 완성할 것으로 기대된다.
.2 유사(類似) 기간산정: Top-down 산정이라 불리기도 하는데, 미래의 액티비티 기간을 산정하는
기반으로서 이전의 유사한 액티비티의 실제기간을 이용하는 것을 의미한다. 이것은 프로젝트에
대한 상세정보의 量이 제한된 곳에서 프로젝트 기간을 산정하는데 빈번히 이용된다(
초기단계에서). 유사견적은 전문가 판단의 일종이다(6.3.2.1 참조)
유사견적은 (1)이전의 액티비티가 사실상 비슷하고 外見은 다를 때 (2)기간산정을 준비하는
개인이 필요한 경험을 지니고 있을 때 가장 신뢰할 만 하다.
48 of 109
다음과 같다.
·2주±2일: 액티비티가 최소 8일에서 12일까지를 필요로 할 때를 지시
·3주를 초과하는 15%의 확률: 액티비티가 3주 정도를 필요로 할 확률이 높을 때(85%)
11장의 프로젝트 리스크관리에서는 불확실성을 산정하는 더욱 상세한 논의가 있을 것이다.
.3 액티비티 목록 갱신 6.2.3.2 참조
.3 자원 요구조건 6.3.1.4
49 of 109
.6 제약조건 (6.1.1.4 참조) 일정도출기간 동안 고려되어야 할 제약조건에 는 2개의 주요 범주가
있다.
·부과된 날짜: 특정 날짜에 의한 특정 성과물의 완공은 프로젝트의 후원자 및 고객,
기타의 외부요인들에 의해 요구될 수도 있다(기술 프로젝트에서의 시장 창구, 환경개선
프로젝트에서 법정에서 강제하는 완공일 등).
·핵심사건(key events) 및 주요 중간관리일: 정해진 날짜에 의한 특정 성과물의 완공은
프로젝트의 후원자 및 고객, 기타의 주요 참여자에 위해 요구될 수도 있다. 일단 일정이
계획되면, 이런 날짜들이 예상되어 가끔 어렵게 옮겨지기도 한다.
.7 가정사항 6.1.1.5 참조
6.4.2 일정도출의 도구 및 기법
50 of 109
모색하는 수학적 분석의 특별한 경우이다(주어진 날짜와 다른 일정 목표를 만족시키기 위해).
기간단축은 다음과 같은 기법을 포함한다.
·Crashing: 비용을 최소한으로 증가시키면서 어떻게 하면 최대한의 단축양을 얻을
것인가를 결정하기 위해 비용과 일정의 상호관계가 분석된다. Crashing은 항상 viable한 대안만을
가져다 주는 것은 아니고, 가끔 비용의 증가를 가져온다.
·Fast-tracking: 통상 순차적으로 수행될 액티비티들을 평행하게 하는 것(S/W
프로젝트에서 설계가 완성되기 전에 코드를 쓰기 시작하는 것, 정유공장에서 설계가 25%
진행되었을 때 기초공사를 시작하는 것). Fast-tracking은 가끔 재작업과 리스크의 증가를
가져온다.
.3 모의실험 6.3.2.3 참조
51 of 109
보여준다. 그러나, 통상 상호관계를 보여주지는 않는다. 그들은 비교적 읽기도 쉽고, 관리
설명회에도 빈번히 사용된다.
·중간관리일 챠트(milestone charts-그림 6-7)은 바챠트와 유사하지만, 주요 성과물과
중요한 외부경계(external interfaces)들의 일정상의 시작 또는 완공을 확인한다.
·시간이 표시된 네트워크 다이어그램(그림 6-8)들은 프로젝트 네트워크 다이어그램들과
바챠트들을 섞어 놓은 것인데, 프로젝트 논리, 액티비티 기간, 일정정보 등을 보여준다.
지원상세로서 빈번히 제공되는 정보는 다음의 것들을 포함한다. 다만, 아래사항에 제한 받지는
않는다.
·일정 기간에 의한 자원 요구조건(빈번히 자원 히스토그램의 형태로)
·대안의 일정(최고/최악의 경우, 평준화 되거나/안된 자원, 부과된 날짜가 있든가/
없든가)
·일정연기 또는 일정리스크의 평가(11.3.3 참조)
6.5 일정관리
52 of 109
.1 프로젝트 일정 (6.4.3.1 참조). 승인된 프로젝트 일정은 `일정기준선'이라 불리기도 하는데,
4.1.3.1에 설명된 전반적인 프로젝트 계획의 구성요소이다. 이것은 일정수행을 측정하고 보고하는
기준을 제공한다.
.4 일정관리 계획 6.4.3.3 참조
6.5.2 일정관리를 위한 도구 및 기법
53 of 109
수도 안할 수도 있다.
개정(변경-revisions)들은 일정갱신의 특별한 범주이다. 개정들은 승인된 프로젝트 일정속에서
일정상의 시작 및 종료날짜에 대한 변경이다. 이런 날짜들은 통상 범위변경에 대응하여서만
개정된다. 일부의 경우에, 일정지연은 너무 심각하여 "기준선 재조정-rebaselining"이 수행을
평가하기 위한 현실적인 자료를 제공하기 위해 필요하다.
54 of 109
일이다. 그러나 다른 부분(capital facilities project 같은)에서는 그런 일도 프로젝트
비용관리에 속한다. 그러한 예측과 분석이 포함된 프로젝트 비용관리는 부가적인 프로세스나 많은
일반적인 관리 기술을 포함하게 된다. 그런 것에는 투자금 상환(return on investment), 할인된
자금 흐름(discounted cash flow), 자본회수 분석(payback analysis) 등이 있다.
프로젝트 비용관리는 프로젝트에 관련된 사람들의 정보요구도 고려해야 한다. - 각 당사자들은
각기 다른 시간에 다른 방법으로 프로젝트 비용을 측정할 것이다. 예를 들면, 조달 아이템
(procurement item)의 비용은 그것을 위탁하거나(committed), 주문하거나, 배달하거나, 사고가
나거나, 계정의 목적으로 기록하고자 할 때 측정될 수 있다.
프로젝트 비용관리가 보상 및 인정시스템(9.3.2.3에서 설명)의 한 요소로 사용될 때는 보상이
실제 수행을 반영하도록 하기 위해 조절이 가능한 비용과 조절이 불가능한 비용을 분리해서
견적하고 예산을 할당해야 한다.
규모가 작은 프로젝트에서는 자원계획, 비용견적, 비용 예산할당이 아주 긴밀하게 연계되어
있어서 마치 하나의 프로세스처럼 보이기도 한다.(이것은 개인에 의해 비교적 단기간에 수행될 수
있다.) 각 프로세스의 도구와 기법이 서로 다르기 때문에 여기서는 각각 개별적인 프로세스로
설명할 것이다.
.1 작업 분류 체계. WBS란 자원이 필요한 프로젝트 요소를 확인하는 것이다. 때문에 자원계획의
기초적인 입력자료가 된다. 다른 계획 프로세스의 관련 결과물도 적절한 관리(control)를
위해서는 WBS를 통해서 제공되어야만 한다.
55 of 109
.3 범위 진술. 자원계획을 하는 동안 프로젝트의 정당성, 프로젝트의 목표를 명백히 밝혀야 한다.
.2 대안의 확인
7.2 비용 견적
56 of 109
7.2.1 비용 견적의 입력자료
.1 작업 분류 체계
.2 자원 요구사항
57 of 109
가지고 있는 경우(거대한 프로젝트나 소규모 프로젝트 모두에 적용할 수 있는)에 가장 신뢰할 수
있다.
58 of 109
.3 비용관리 계획 비용관리 계획은 비용의 편차를 어떻게 관리할 것인가를 묘사한다. 비용관리
계획은 공식적일 수도 있고 비공식적일 수도 있다. 혹은 아주 상세할 수도 개략적일 수도 있는데
이는 관련당사자의 요구에 따른 것이다. 이것은 전반적인 프로젝트 계획의 보완적인 요소이다.
(4.1.3.1)
7.3 비용 예산할당(Budgeting)
.1 비용 견적
.2 작업분류체계
.3 프로제트 스케줄 프로젝트 스케줄은 앞으로 비용이 할당될 프로젝트 요소에 대한 계획된
시작일과 예상되는 종료일을 포함한다. 이것은 비용이 발생하는 기간에 비용을 할당하기 위해서
필요한 정보이다.
7.4 비용 조절관리
비용 조절관리는
⒜변화가 유용한 것이라는 확신에 의해 비용 기준선을 변경하는 요소를 반영하는 것,
⒝변경된 비용기준선을 결정하는 것,
⒞실제 변경이 발생했을 경우 이를 관리하는 것과 관련이 있다.
59 of 109
비용 조절관리는 다음을 포함한다:
비용관리는 "도대체 왜" 긍정적인 편차나 부정적인 편차가 발생하는가를 찾아내는 것과도 관련이
있다. 이것은 다른 조절관리 프로세스와도 완전하게 통합되어야 한다. 예를 들어 비용 편차에
대한 부적절한 대응은 후에 품질문제나 일정문제를 야기시킬 수도 있고, 받아들일 수 없을 정도의
리스크를 초래할 수도 있다.
.1 비용 기준선
.4 비용 관리 계획
60 of 109
.3 부가적인 계획 계획된 그대로 진행되는 프로젝트는 거의 없다. 예상되는 변경은 새롭거나
수정된 비용견적 혹은 대안의 분석을 필요로 한다.
61 of 109
품질계획, 품질관리(QC), 품질보증, 품질개선 등의 품질 시스템을 통해 이루어진다. 그림 8-1은
다음의 주요 프로세스에 대한 개요를 보여준다:
8.1 품질 계획(Quality Planning) - 어떤 품질 표준이 프로젝트에 적합한 것인지
확인하고, 어떻게 그것을 만족시킬 것인지 결정하는 것
8.2 품질 보증(Quality Assurance) - 프로젝트가 적합한 품질표준을 만족할 것이라는
확신을 주기 위해 정식적으로 프로젝트 수행을 평가하는 것
8.3 품질 관리(Quality Control) - 프로젝트가 적합한 품질표준을 따르고 있는지
결정하기 위해 프로젝트의 결과를 관찰하는 것, 그리고 불만족스러운 수행의 원인을 제거하는
방법을 확인하는 것
이번 장에서 설명하고 있는 품질관리의 기본적인 접근방식은 ISO의 ISO 9000과 10000 시리즈의
표준과 지침에 부합하도록 되어있다. 또한 이런 일반화된 접근방식은 ⒜Deming, Juran, Crosby
등에 의해 추천된 proprietary 품질관리 접근방식과 ⒝TQM, 지속적인 개선(Continuous
Improvement) 등과 같은 non-proprietary 품질관리 접근방식 모두와 부합되어야 한다2.
프로젝트 품질관리는 프로젝트의 관리와 프로젝트의 생산품 양자 모두를 다루어야 한다. 모든
범위에서의 품질요구사항을 만족시키지 못하면, 프로젝트 관련당사자에게 부정적인 결과를 가져올
수도 있다. 예를 들면:
·프로젝트팀에게 과도한 일을 부과하여 소비자의 요구를 만족시키는 것은 고용비용 증가라는
형태의 부정적인 결과를 초래할 수 있다.
·급하게 계획된 품질검사를 시행하여 프로젝트 일정 목표를 만족시키는 것은 발견되지 않았던
오류가 드러나는 경우 부정적인 결과를 초래할 수 있다.
62 of 109
프로젝트팀은 현대의 품질관리가 프로젝트관리와 상호보완적이라는 것을 알아야만 한다. 예를
들면 두 분야 모두 다음을 중요하게 취급한다:
·고객의 만족도 - 고객의 요구사항을 이해하고, 관리하며, 이를 반영해서 고객의 기대를
만족시키거나 그 보다 더 잘하는 것. 이것은 시방에의 순응성(conformance to specifications)과
이용에의 적합성(fitness for use)의 결합을 필요로 한다.
·검사보다 예방 - 실수를 피하기 위한 비용은 이를 개선하는 비용보다 항상 적은 법이다.
·관리 책임 - 성공을 위해서는 팀의 모든 멤버들이 참가해야 한다. 그러나 성공을 위해 필요한
자원을 공급하는 것은 팀의 책임이다.
·단계 안에서의 프로세스 - 계획-실행-검사-조치(plan-do-check-act) 사이클의 반복은 3장에서
설명한 프로세스와 단계의 결합과 무척 유사하다.
또한, 수행조직에 의해서 이루어지는 품질개선의 착수는 프로젝트 생산품의 품질뿐만 아니라
프로젝트관리의 품질까지도 향상시킨다.
그러나 프로젝트팀이 확실하게 알아야할 중요한 차이점이 있다. - 프로젝트가 임시적이라는
사실은 생산품의 품질 향상에 대한 투자가 수행조직에 의해서 이루어져야 한다는 것을 의미한다.
왜냐하면 프로젝트는 보상을 받을 정도로 충분히 오랫동안 남아있지 않기 때문이다.
63 of 109
.2 범위 진술 (5.2.3.1)
.5 다른 프로세스의 결과물
64 of 109
8.1.3 품질계획의 결과물
.4 다른 프로세스로부터의 결과물
8.2 품질 보증
65 of 109
8.2.1 품질보증의 입력자료
.1 품질관리 계획
.2 품질 관리(QC) 측정의 결과치
.3 운영상의 정의
.1 품질계획의 도구와 기법
66 of 109
·특수한 원인(색다른 사건)과 무작위적 원인(일반적인 프로세스의 편차)
·허용치(결과가 허용치로 규정된 범위내에 있다면 그 결과를 인정)와 관리한계(결과가
관리한계내에 있다면 그 프로세스는 통제하에 있다)
.4 체크리스트(Checklists) 8.1.3.3
.1 검사(Inspection)
.2 관리도(Control charts)
67 of 109
.3 파레토도(Pareto diagrams)
.4 통계샘플링(Statistical sampling)
.5 플로우차트(Flowcharting)
.6 추세분석(Trend analysis)
추세분석은 역사적 결과에 기반하여 미래 결과물을 예측하는 수학적 기법을 사용하는 것이다.
추세분석은 종종 다음을 관찰(monitor)하기 위해 사용된다.
·기술적 수행(Technical performance)-얼마나 많은 오류나 결점들이 규명되었고, 얼마나
많은 것들이 수정되지 않은 채로 남아있는가.
·비용과 일정 수행(Cost and schedule performance)-단위기간(period)당 얼마나 많은
액티비티들이 주요한 변수를 지닌 채 완수되었는가.
68 of 109
.3 재작업(Rework) 재작업은 결함이 있는 항목이나 조건에 따르지 않는 항목들을 요구조건이나
시방서에 따르도록 하는 조치이다. 재작업, 특히 예상하지 못한 재작업은 대개의 응용분야에서
프로젝트 초과비용(project overruns)의 주요 요인이다. 프로젝트팀은 재작업을 최소화하기 위해
가능한 모든 합리적인 노력을 해야 한다.
이러한 대부분의 주제는 프로젝트의 사람을 지도, 관리하는 데 직접적으로 적용할 수 있으며 PMr
69 of 109
와 PM팀은 이러한 것을 잘 알아야 한다. 그러나 이러한 지식을 프로젝트에 적용하는 방법에
대해서도 잘 알고 있어야 한다. 예를 들어
프로젝트의 임시적인(temporary) 성격은 대인 및 조직적 관계가 일반적으로 임시적이고 새롭다는
것을 의미한다. PM팀은 그러한 임시적인 관계에 적정한 기법을 선정하는데 주의를 기울여야 한다.
프로젝트 관련자들의(stakeholder) 성격과 수는 종종 프로젝트가 라이프사이클의 각 단계로
진행됨에 따라 변할 것이다. 그 결과 한 단계에서 효과적인 기법은 다른 단계에서 효과적이지
않을 수 있다. PM팀은 프로젝트의 현재 필요에 적당한 기법을 이용하는 데 주의를 기울여야 한다.
인적자원관리 액티비티는 PM팀의 직접적인 책임은 아니다. 그러나 PM팀은 이에 따르도록 관리
요건을 충분히 알고 있어야 한다.
조직 계획은 프로젝트의 역할, 책임, 보고 관계를 확인, 문서화, 할당하는 것을 의미한다. 역할,
책임 그리고 보고 관계는 개인 또는 집단에 할당될 수 있다. 개인 및 집단은 프로젝트 수행
조직의 일부일 수도 있으며 또는 그런 조직의 외부일 수도 있다. 종종 내부 집단은 엔지니어링,
마케팅, 회계와 같은 특정한 기능적 부서와 관련된다.
대부분의 프로젝트에서 대다수의 조직 계획은 프로젝트의 가장 초기 단계의 일부로 행해진다.
그러나 이런 과정의 결과는 계속적인 적용가능성을 확보하기 위해 프로젝트 전과정을 통하여
정기적으로 검토되어야 한다. 초기 조직이 더 이상 효과적이지 않다면 즉시 변경되어야 한다.
조직 계획은 종종 프로젝트 조직 구조가 프로젝트 의사소통 요건에 영향을 미치기 때문에
의사소통 계획(10장에서 기술됨)과 밀접히 연계되어 있다.
70 of 109
설계 회사에 고용된 건축가가 주요 설계 고려사항을 관련 없는 시공자의 프로젝트 관리팀에게
설명할 때와 마찬가지로 이러한 인터페이스는 종종 동시에 발생한다.
9.1.2 조직 계획의 도구 및 기법
71 of 109
것을 확증하기 위해 그들의 다양한 요구가 분석되어야 한다. (10.2.1 참조)
72 of 109
조직적 영향 (Organizational impact) - 어떤 대안은 이런 방법으로 조직화함으로써
제외된다.
작업기술(job description) - 주어진 작업 수행에 포함되는 기술(skill), 책임, 지식,
권한, 물리적 환경, 그리고 기타 특성과 같이 작업지위(직위)별로 개략적으로 기술된 문서. "직위
기술"으로도 불린다.
훈련 필요(Training needs) - 배치된 직원이 프로젝트에 필요한 기술을 갖지 못했다면
그러한 기술은 프로젝트의 일부로써 개발될 필요가 있다.
9.2.2 직원확보를 위한 도구 및 기법
73 of 109
수행조직내의 기타 PM팀 (희귀한 또는 전문화된 자원을 적정하게 배치하기 위해)
.1 임명된 프로젝트 임(직)원 Project staff assigned 적당한 사람이 프로젝트의 작업에
배치되었을 때 그 프로젝트는 직원이 구성된다. 직원은 전임으로 또는 시간제로 프로젝트의
필요에 따라 다양하게 배치된다.
74 of 109
.1 프로젝트 임(직)원 Project staff 프로젝트 직원충원은 9.3.2.1절에서 기술되었다. 직원
배치는 개인적인 기술(skill)과 팀 기술이 이용 가능해야 한다는 것을 암시하고 있다.
9.3.2 팀 개발을 위한 도구 및 기법
75 of 109
말아야 한다.
보상 및 인정 체계는 또한 문화적인 차이를 고려해야 한다. 예를 들어 개인주의를 존중하는
문화에서 팀 보상 메커니즘을 개발하는 것은 상당히 어려울 수 있다.
프로젝트 의사소통 관리는 적시에, 적정한 프로젝트 정보의 발생, 수집, 저장 그리고
궁극적으로는 그러한 정보를 처리하기 위해 필요한 절차를 포함한다. 이것은 성공을 위해 필요한
사람, 아이디어, 정보간의 중요한 연계를 제공한다. 프로젝트에 참여한 모든 사람들은 프로젝트
76 of 109
"언어"로 된 의사소통을 받고 보낼 준비가 되어 있어야 하며, 개인이 전체 프로젝트에 영향을
주는 것처럼 그들이 어떻게 의사소통에 참여할 것인지 이해해야 한다.
77 of 109
적용가능성을 확보하기 위해서는 필요에 따라 변경되어야 한다.
종종 의사소통계획은 조직 계획(9.1 참조)과 밀접히 연계된다. 왜냐하면 프로젝트 조직의 구조가
프로젝트의 의사소통 요건에 영향을 미치게 될 것이기 때문이다.
의사소통 요건은 프로젝트 관련자들의 정보 요건의 총합이다. 그러한 요건들은 필요한 정보의
유형과 형식을 그 정보의 가치 분석과 결합함으로써 정의된다. 프로젝트 자원은 성공에
기여하거나 또는 정보의 부족이 실패를 가져오는 그러한 정보 전달(communicating information)
에만 사용되어야 한다.
프로젝트 의사소통을 결정하기 위해 필요한 정보는 다음을 포함한다.
프로젝트 조직 및 프로젝트 관련자 책임 관계
프로젝트에 참여한 학문분야, 부서, 그리고 전문분야
얼마나 많은 사람이 프로젝트에 참여할 것인가 그리고 어느 곳에서 참여할 것인가에
대한 병참술
외부 정보 요구 (예, 미디어를 통한 의사소통)
.3 제한 조건 Constraints
78 of 109
프로젝트가 계약으로 수행될 때 종종 의사소통 계획에 영향을 주는 특정한 계약규정이 있게
된다.
.4 가정 Assumptions
가정은 계획의 목적으로 진실, 실제, 또는 확실하다고 생각되는 요인들이다. 일반적으로 가정은
어느 정도의 리스크를 포함한다. 그러한 것들은 여기에서 파악될 수도 있으며 또는 리스크 파악의
결과가 될 수도 있다. (11.1 참조)
79 of 109
의사소통관리 계획은 프로젝트의 필요에 따라 공식적 또는 비공식적, 고도의 상세 또는 개략적일
수 있다. 이것은 전체 프로젝트 계획의 보조적인 요소이다. (4.1 참조)
10.2.2 정보배포의 도구 및 기법
의사소통 기술은 정보를 교환하는데 이용된다. 송신자는 수신자가 정확하게 수신할 수 있도록
정보를 명확하고, 모호하지 않게 그리고 완전하게 할 책임이 있으며 그리고 올바르게 이해하도록
할 책임이 있다. 수신자는 정보가 완전하게 수신되었고 정확하게 이해되었다는 것을 확실히 할
책임이 있다. 의사소통은 다음과 같이 다양한 차원을 가지고 있다.
문서 및 구두, 듣기와 말하기
내부(프로젝트 내) 및 외부(고객, 미디어, 공중 등)
공식적(보고서, 브리핑 등) 그리고 비공식적(메모, 임시대화 등)
수직적(조직의 상향 및 하향) 그리고 수평적(동료)
프로젝트 정보는 프로젝트 모임, 문서 사본 배포, 네트웍 전자 DB로의 접근, 팩스, 전자메일,
80 of 109
음성메일, 비디오 회의등을 포함하는 다양한 방법을 이용하여 배포될 수도 있다.
.1 프로젝트 계획 Project plan 프로젝트 계획은 4.1.3.1에 기술되어 있다. 프로젝트 계획은
프로젝트 실행에 평가하는데 이용되는 다양한 기준을 가지고 있다.
81 of 109
10.3.2 실행보고의 도구 및 기법
.1 실행 검토 Performance reviews
.2 편차 분석 Variance analysis
.3 추세 분석 Trend analysis
82 of 109
제공하기 위해 조합하여 사용된다. 가장 흔히 사용되는 측정방법은
83 of 109
행정적인 종료 액티비티는 프로젝트가 완성될 때까지 지연되지 말아야 한다. 프로젝트의 각
단계는 프로젝트의 각 단계는 중요하고 유용한 정보가 손실되지 않도록 적절하게 종료되어야
한다.
프로젝트 결과를 기술하기 위해 만들어진 문서(계획, 시방서, 기술적 문서, 도면, 전자파일 등)는
행정적인 종료 동안 검토목적으로 이용할 수 있어야 한다.
10.3.2 참조
적정한 주체가 보관할 수 있도록 색인을 단 완전한 프로젝트 기록 세트가 준비되어야 한다.
프로젝트와 관련된 어떤 특정 프로젝트 또는 프로그램의 DB가 갱신되어야 한다. 프로젝트가
계약으로 수행될 때 또는 특정 조달을 포함하고 있을 때 재정적 기록의 저장에 특히 주의해야
한다.
84 of 109
발주자 또는 스폰서가 프로젝트(또는 단계)의 결과를 승인한 문서가 준비되어 배포되어야 한다.
85 of 109
동안에 통상적인 기반(regular basis)에서 수행되어야 한다.
리스크 규명은 내적리스크와 외적리스크로 다루어져야 한다. 내적리스크는 조직할당(staff
assignments)과 비용견적(cost estimates) 같은 프로젝트팀이 통제할 수 있고 영향을 줄 수 있는
것이다. 외적리스크는 시장의 이동이나 정부가 내린 조치와 같은 프로젝트팀의 통제나 영향을
넘어서는 것이다.
엄격히 말하자면, 리스크는 단지 해(harm)나 손실(loss)을 겪을 가능성을 포함하고 있다. 그러나
프로젝트의 맥락에서, 리스크 규명은 위험(부정적인 결과)인 동시에 기회(긍정적인 결과)와도
관련된다.
리스크 규명은 원인과 결과(어떤 일이 발생하고 결과로서 어떤 일이 발생하는가?) 또는 결과와
원인(회피해야 할 결과물과 장려되어야 할 결과물이 어떤 것인가와 어떻게 각각의 결과물이
발생되는가?)을 규명하는 것에 의해서 달성된다.
프로젝트의 생산물의 성질은 규명된 리스크에 주요한 영향을 끼칠 것이다. 증명된 기술을
적용하는 생산물은 혁신(innovation)이나 발명(invention)을 필요로 하는 생산물보다 적은
리스크를 가지고 있다. 프로젝트의 생산물과 관련한 리스크는 종종 비용과 공기에 대한 영향으로
설명된다. 5.1.1.1은 생산물 설명에 대한 부가적인 정보를 나타낸다.
86 of 109
이전의 프로젝트에서 실제 발생한 역사적 정보는 잠재적인 리스크를 규명하는데 특히 도움이 될
수 있다. 역사적 결과에 대한 정보는 종종 다음과 같은 소스로부터 활용가능하다.
·프로젝트 파일 - 프로젝트에 관여한 하나 또는 그 이상의 조직은 리스크를 규명하는데
충분하게 상세한 과거의 프로젝트 결과에 대한 기록을 가지고 있다. 어떤 응용분야에서는 개별
팀 구성원들이 그와 같은 기록을 가지고 있을 수도 있다.
·상업용 DB - 많은 응용분야에서 역사적 정보가 상업적으로 이용가능하다.
·프로젝트팀의 지식 - 프로젝트팀의 개별 구성원들은 이전의 사건이나 가정들을
기억하고 있을 수 있다. 그와 같은 회상들은 유용할 수 있는 반면, 일반적으로 문서화된
결과들보다 신뢰도가 떨어진다.
.1 체크리스트(Checklists).
.2 흐름도(Flowcharting).
.3 면접(Interviewing).
87 of 109
·설계상의 오류, 생략, 오해(잘못이해됨)
·빈약하게 정의되거나 이해된 역할과 책임
·조악한 견적
·불충분한 전문인력
리스크의 출처에 대한 설명(description)은 일반적으로 다음에 대한 견적을 포함해야 한다
(a) 그 출처로부터 리스크 이벤트가 발생할 확률,
(b) 발생가능한 결과의 범위,
(c) 예상시기,
(d) 그 출처에 의한 리스크 이벤트의 예상 빈도
확률과 결과 양자는 연속적인 기능 또는 별개의 기능으로서 상세될 수 있다. 게다가, 초기
프로젝트 단계동안에 만들어진 확률과 결과(outcome)에 대한 견적은 프로젝트의 후반부에
만들어지는 그것에 비해 광범위하기 쉽다.
88 of 109
프로젝트 단계동안에 만들어진 확률과 결과(outcome)에 대한 견적은 프로젝트의 후반부에
만들어지는 그것에 비해 광범위하기 쉽다.
상이한 조직들과 상이한 개인들은 리스크에 관한 상이한 포용력을 가지고 있다. 예를 들면,
·고수익을 가지는 회사는 10억불짜리 계약에 대한 제안서(proposal)를 작성하는데
500,000불을 기꺼이 쓸 수 있는 반면, 손익이 거의 없는 회사는 그렇지 않다.
89 of 109
다른 조직은 낮은 리스크로 파악한다.
공사관련자의 리스크 포용력은 리스크 계량에 대한 투입과 결과 양자에 있어서 스크린(screen)을
제공한다.
.4 비용견적(Cost estimates).
90 of 109
"method of moments"기법의 이용을 보여준다.
.3 시뮬레이션(Simulation).
.4 의사결정나무(Decision trees).
91 of 109
리스크 계량 프로세스는
(a) 리스크의 출처와 프로젝트 관리팀이 의식적으로 수용하거나 무시하기로 결정한 리스크
이벤트(risk events),
(b) 누가 그런 결정을 하였는가 에 대해 문서화하여야 한다.
.1 구매(Procurement).
92 of 109
포함한다.
.3 대안 전략(Alternative strategies).
.4 보험(Insurance).
93 of 109
.4 비축금(Reserves).
계약적 협정은 위협을 피하거나 완화하기 위해서 적절한 보험, 용역, 기타 항목에 가입하는 것일
수 있다. 계약내용 및 조건(contractual terms and conditions)들은 리스크 저감의 정도에 상당한
영향을 끼칠 것이다.
규명된 리스크 이벤트의 일부는 발생할 것이고 나머지는 발생하지 않을 것이다. 발생하는 것들은
실제적인 리스크 이벤트이거나 리스크의 출처이므로, 프로젝트팀은 개발된 대응이 수행될수
있도록 하기 위해 규명된 리스크가 발생했다는 것을 인지해야 한다.
프로젝트 수행이 측정되고 보고됨에 따라, 이전에는 규명하지 못했던 잠재적인 리스크 이벤트나
리스크의 출처가 나타날 수 있다.
94 of 109
.1 Workarounds.
.1 수정조치(Corrective action).
예상된 리스크 이벤트가 발생하거나 발생하지 않음에 따라, 그리고 실제적인 리스크 이벤트
영향이 평가됨에 따라, 리스크 관리 계획의 다른 측면과 마찬가지로 확률과 가치의 견적은
갱신되어야 한다.
95 of 109
12.4 자원선택(Source Selection) - 잠정적인 판매자들 중에서 선택하는 것
12.5 계약관리(Contract Administration) - 판매자들과의 관계를 관리하는 것
12.6 계약완료(Contract Close-out) - 끝나지 않은 항목(open item)의 해결을 포함한
계약의 완료 및 문제해결
96 of 109
12.1.1 조달계획의 입력자료
.1 범위진술(Scope statement)
.2 생산품묘사(Product description)
.3 조달자원(Procurement resources)
.4 시장상황(Market condition)
.6 제한(Constraints)
97 of 109
.7 가정(Assumption)
98 of 109
지급(상환금)과 관련이 있다. 비용은 일반적으로 직접비용과 간접비용으로 구분된다. 직접비용은
프로젝트의 이득이 아닌 것(the exclusive benefit)에 대해 발생한 비용이다(예를 들면 전시간
고용인원에 대한 봉급). 간접비용은 overhead cost라고도 불리며, 수행조직에 의해 사업비로
할당된 비용이다(예를 들면, 회사 경영진에 대한 봉급). 일반적으로 간접비는 직접비에 대한
백분율의 형태로 계산된다. 비용상환계약도 일정목표나 총공사비 같은 프로젝트의 목적을
만족시키거나 초과하여 달성했을 경우 격려금을 포함할 수 있다.
·단가계약(Unit price contract) - 판매자는 서비스에 대해서 사전에 정해진 단가로
지불을 받는다(예를 들어, 전문가 서비스는 시간당 70$이고, 토사제거는 cubic yard당 1.08$
이다). 계약의 총액은 공사를 완료하는데 필요한 물량에 달려있다.
99 of 109
수도 있다. 각각의 조달품목은 각기 분리된 SOW를 필요로 한다. 그러나 다중의 생산품이나
서비스는 하나의 조달품목으로 묶어져서 단일 SOW로 나타낼 수도 있다.
이 SOW는 가능한 명료하고, 완결되어 있으며, 일관성을 지녀야 한다. 이것은 수행 보고서 혹은
프로젝트 후 운영상의 지원 등과 같은 부차적인 서비스에 대한 기술도 포함해야 한다. 어떤
적용분야에 있어서는 SOW에 특별한 내용이나 공식상의 요구사항이 있을 수 있다.
.1 표준서식(Standard forms)
.1 조달문서(Procurement documents)
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)
12.3 수배 (Solicitation)
101 of 109
수배는 프로젝트의 요구사항을 어떻게 만족시킬 것인지 대해 장래의 판매자로부터 정보(입찰서와
제안서)를 얻는 것과 관련이 있다. 이 프로세스에서의 실질적인 노력의 대부분은 장래의 판매자가
지불하게 되며, 일반적으로 프로젝트에서의 지출은 없다.
.1 조달문서(Procurement documents)
어떤 조직들은 잠정적인 판매자의 정보에 대한 목록이나 파일을 보유하고 있다. 이러한 목록은
대부분 잠정적인 판매자의 관련된 경험이나 기타 특징 등에 대한 정보를 포함하고 있다.
만약 이런 목록을 쉽게 이용할 수 없다면, 프로젝트팀은 스스로의 자원을 개발해야 할 것이다.
일반적인 정보는 자료집(library directories), 관련 지역연합, 직종별 카달로그, 그리고 이와
유사한 자원들 등으로부터 얻어질 수 있다. 특수한 자원에 대한 상세한 정보는 더욱 광범위한
노력을 필요로 할 수도 있으며, 그런 노력에는 현장방문, 예전고객과의 계약(에 관한 자료) 등이
있다.
조달문서는 잠정적인 판매자의 일부 혹은 모두에게 보내질 것이다.
.2 공고(Advertising)
102 of 109
.1 제안서(Proposals)
.1 제안서(Proposals)
.2 평가기준(Evaluation criteria)
.1 계약 협상(Contract negotiation)
103 of 109
계약협상은 계약에 서명하기 전 계약의 구성과 요구사항에 대해 설명하거나 상호 동의하는 것과
관련이 있다. 가능한 범위 내에서 최종계약어휘는 모든 동의사항을 반영해야 한다. 일반적으로
포함되는 주제는 책임과 권한, 적용 가능한 약관 및 법령, 기술관리방법 및 사업관리방법,
계약재정, 가격 등이지만 이것이 전부는 아니다.
복잡한 조달품목의 경우, 계약협상이 자신만의 독자적인 입력(예를 들어, issues or open item
list) 과 출력(예를 들면, memorandum of understanding)을 가진 프로세스일 수도 있다.
계약협상은 "협상(negotiation)"이라고 불려지는 일반적인 관리기술의 특수한 경우이다. 협상의
도구, 기법, 양식은 일반적인 관리관련 문헌에서 광범위하게 논의되고 있으며, 이는 계약협상에도
적용 가능한 것이다.
.3 Screening system
.4 독립견적(Independent estimate)
.1 계약(Contract)
계약이란 판매자는 특별한 생산품을 제공할 의무가 있고, 구매자는 그것에 대한 비용을 지불할
104 of 109
의무가 있다는 상호간의 구속력 있는 동의이다. 계약은 법정에서 변상해야 하는 법적인 관계이다.
협약(agreement)는 간단할 수도 있고, 복잡할 수도 있는데 이는 생산품의 단순성과 복잡성에
따른다(항상 그런 것은 아니다). 이것은 다른 명칭으로 불려질 수도 있는데, a contract, an
agreement, a subcontract, a purchase order, 혹은 a memorandum of understanding 등이다.
대부분의 조직은 누가 조직을 대신하여 그런 계약에 서명할 것인가에 대한 방침과 절차를 가지고
있다.
비록 모든 프로젝트문서가 검토와 승인이라는 형식을 가지고 있어야 하지만, 계약이 가진 법적
구속력이라는 본성은 그것의 승인 프로세스가 훨씬 확장되어야 한다는 것을 의미한다. 모든 경우,
검토와 승인프로세스의 기본적인 초점은 그 계약어휘가 생산품이나 서비스가 요구사항을 만족시킬
것이라고 기술했는가를 확인하는데 있어야 한다. 공공기관에 의해서 수행되는 대형 프로젝트의
경우 검토프로세스는 계약에 대한 공공의 검토까지 포함할 수도 있다.
.1 계약(Contract)
.2 작업 결과(Work result)
105 of 109
판매자의 작업결과 -성과물이 완성되었는지 아닌지, 어느 정도의 품질기준을 만족했는지,
얼마만큼의 비용이 발생했으며 지불되었는지 등- 는 프로젝트계획 수행의 일부분으로써 모아진다.
.3 변경요청(Change request)
판매자는 수행한 작업에 대한 지불을 요청할 때마다 송장을 제출해야 한다. 필요한 지원문서 및
송장을 만드는데 필요한 사항은 계약에 정의되어 있다.
.2 수행 보고서작성(Performance reporting)
.3 지급시스템(Payment system)
106 of 109
12.5.3 계약관리의 결과물
.1 교환문서(Correspondence)
.2 계약변경(Contract change)
.3 지불요청(Payment request)
.1 계약증거서류(Contract documentation)
107 of 109
.1 조달 감사(Procurement audit)
.1 계약파일(Contract file)
6) 두 수의 결과라 함은 리스크 이벤트 확률과 리스크 이벤트 가치의 곱에 의해서 EMV가 계산되기
때문으로 생각됨.
108 of 109
109 of 109