박종명의 아름다운 개발 since 2010.06

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=501

---

전문가 책임

‘프로젝트관리전문가’ 인증 프로그램인 PMP(Project Management Professional)는

PMI(Project Management Institute)라는 국제 협회에서 관리하는 인증, 자격 제도이다.

PMI는 전 세계적으로 프로젝트 관리에 관한 전문 지식을 보급하고 전문가를 양성하기 위해 PMP라는 자격제도를
운영하고 있으며 더불어 업무적, 기술적인 평가를 비롯하여 프로젝트관리전문가로써의 직무상 책임과 합법적, 윤리적 그리고 전문가다운 행동 양식에 대해서도 연구, 정의하고 이를 PMP 학습과정에 포함시켰다.

* PM의 직업 의무

1. 전문성의 지속적인 향상

공인 프로젝트 관리자로서 전문성 향상과 개인 역량 강화에 지속적인 노력을 기울여야 한다

이를 위해 다음과 같은 행동 양식이 요구된다

- 자신의 강점과 약점을 파악한다

- 자신의 전문성 향상을 위한 개발 계획을 수립한다

- 회사 또는 프로젝트에 도움이 될 새로운 정보와 사례를 수집한다

- 현업 관련 전문 지식을 지속적으로 배운다

2. 완전성과 전문성 준수

공인 프로젝트 관리자로서 완전성(integrity)과 전문성(professionalism)을 준수하고 이해당사자들과 관련조직을
보호해야 한다. 이를 위해 다음과 같은 행동 양식이 요구된다

- 보고서, 대화 등의 의사소통 시에는 진실(truth)을 말한다

- 법률준수 및 지적 재산권을 보호하고 위반사항을 발견하면 반드시 이를 알린다

- 기업 정보를 외부에 유출하지 않는다

- 프로젝트 관리 시 개인의 이익을 부가하지 않으며 뇌물을 주고 받지 않는다

- 이해관계의 충돌을 파악하고 발생할 경우 이를 적극적으로 처리한다

- 모든 사람을 존중하고 옳은 일과 정확한 프로세스를 따른다

3. 이해당사자 간의 갈등 해소

공인 프로젝트 관리자로서 이해당사자들의 충돌되는 요구 및 목적을 만족시키기 위해 해결 방안을 제시하고
이해관계의 균형을 유지 시킨다. 이를 위해 다음과 같은 행동 양식이 요구된다

- 이해당사자들의 요구 및 목적을 명확히 규정하고 이해한다

- 충돌되는 요구 및 목적을 적극적으로 찾아 공정한 해결 방안을 찾는다

- Crashing, Fast Tracking, Brainstorming, 재산정 등의 기법과 갈등해소, 의사소통, 협상, 정보배포,

 팀 빌딩 및 문제해결 기법을 활용하여 해결하며 회의, 인터뷰 및 토론을 진행한다

- 해결할 수 없는 갈등은 경영층을 개입시킨다

- 프로젝트 헌장과 관련된 변경은 경영진의 승인을 요청한다

4. 문화적 차이의 이해

프로젝트는 다양한 환경 및 다양한 사람들이 모여서 수행하게 되는 경우가 많다

지역이 다르거나 나라가 다를 경우 발생할 수 있는 문화적 차이와 배경을 이해하고 있어야 한다

- 문화적 차이에 대한 다양성을 받아 들이다

- 문화적 차이를 사전에 학습하여 문화적 충격을 방지한다

- 법률을 위반하지 않을 경우에는 다른 나라의 관례를 따른다

5. 프로젝트 관리 지식 공유

프로젝트를 수행하여 얻게 된 지식과 경험을 공유하여 조직과 팀의 전문성을 향상시킬 수 있도록 해야 한다.

- 다른 프로젝트 관리자와 Lesson learned를 공유한다

- 필요한 사람들에게 교육을 실시하고 코치 및 멘토링을 제공한다

- 프로젝트 성공 사례를 발굴하고 연구 하여 이를 공유한다

* PMI 직무 윤리 규정

국제 프로젝트 관리 협회인 PMI 에서는 프로젝트 관리자의 직무 윤리 규정을 정의하고 있다

이 규정은 PMP 취득자는 물론 PMI 회원 그리고 PMI와 직접적인 관계가 없는 일반적인 관리자를 대상으로 나누고
윤리 규정을 정의하고 있다. 규정집의 구성과 내용을 간략히 살펴보자

∥PMI 회원 및 기타 관련자들에게 적용되는 규정

PMI 윤리 및 직무 행위 규정(PMI Code of Ethics and Professional Conduct)

1장) 비전 및 적용 (Vision and Applicability)

2장) 책임감(Responsibility)

3장) 존중심(Respect)

4장) 공정성(Fairness)

5장) 정직성(Honesty)

∥PMI 회원들에게 적용되는 규정

1. PMI 회원 윤리 규정(PMI Member Code of Ethics)

1) 서언(Preamble)

팀원, 동료, 고용인, 고용주, 고객, 대중 및 국제 사회의 존중심을 획득하고 유지하기 위해서는 PMI 회원들이
윤리적으로 직무를 수행하는 것이 대단히 중요하다

2) 회원 윤리 규정(Member Code of Ethics)

- 나는 충직성 및 직무상 높은 표준을 유지한다

- 나는 나의 행동에 대한 책임을 받아 들인다

- 나는 나의 직무 역량의 향상을 꾸준히 추구한다

- 나는 공정하고 정직하게 실무를 수행한다

- 나는 동종 직무에 종사하는 타인의 윤리 규정 준수를 고무한다

2. PMI 회원 행위 표준(PMI Member Standard of Conduct)

1) 직무상 의무

a. 직무상 행위

- 직무 관련 이해 상충의 완전/정확/적시 공개

- 반대 급부의 여지가 있는 대가/보상/혜택의 수수 금지

- 타인의 지적 소유권의 존중과 보호

- 타인의 기여에 대한 공개와 인정

b. 고객, 의뢰인 및 고용주와의 관계

- 고객, 의뢰인, 고용주 및 유사 업무 관련 정보의 기밀 유지

- 기밀 정보 및 사적 정보의 부당한 이용 및 제공의 금지

c. 공공 및 국제 사회와의 관계

- 직무 수행 지역의 법규/규칙/고객 관련 의무의 존중 및 충족

2) PMI에 대한 의무

a. PMI 회원의 의무

- PMI 정관/정책/규정/요건/절차 준수

- PMI 권익을 손상시키는 활동의 의도적 참여 금지

- PMI에 정확/완전/진실한 정보 진술

∥PMP들에게 적용되는 규정

1. PMP 윤리 규정(PMP Code of Ethics)

1) Article 1 (사적 및 직무상 행위에 있어 높은 표준 유지)

- 훈련, 경험 또는 관련 자격이 적합한 경우에만 프로젝트 수행

- 동료들에게 윤리 규정 준수 격려

- 업무 수행 국가의 법률 준수

- 직무 스킬을 최고 수준으로 유지

- 품위 있는 직무 수행을 통한 충직성과 신의 진작

2) Article 2 (PMP의 업무 수행)

- 프로젝트 팀 멤버를 육체적, 정신적 피해로부터 보호

- 비판의 수용과 타인의 공로 인정

- 프로젝트 팀원, 동료의 전문성 개발 지원

- 최신의 프로젝트 관리 도구와 기법의 적용

- 인종, 종교, 성별, 연령, 출신에 관계 없이 공평하게 대우

3) Article 3 (고용주, 고객 관계)

- 이해 상충으로 발전 가능한 상황은 고용주 또는 고객에게 통보

- 고용주나 고객들로부터 선물이나 대가 수수 금지

- 품질, 원가, 시간 보고 시 정직한 보고

- 고용주와 고객의 사업 또는 기술 관련 기밀 유지

4) Article 4 (지역 사회에 대한 책임 완수)

- 공중의 보건과 복지의 보호, 공익 침해 사안의 적극적 반대

2. PMP 직무 행위 규정(PMP Code of Professional Conduct)

1) 직무상 책임(Responsibilities to the profession)

A. 조직의 모든 규칙 및 정책의 준수

B. 응시자 및 자격 보유자로서의 직무 수행

C. 전문 분야의 촉진

- 타인의 저작권을 인정하고 존중할 책임

- 다른 PMI 자격 보유자가 PMP 직무 행위 규정을 준수하도록 지원하고 전파할 책임

2) 고객 및 공공에 대한 책임(Responsibilities to customers & public)

A. 전문 서비스의 자격, 경험 및 수행

- 원가, 서비스 및 기대 결과에 대해 공공에게 정확하고 진실하게 진술할 책임

- 전문 서비스의 범위와 목적을 유지하고 민족 시킬 책임

- 직무 활동 과정에서 획득한 민감한 정보의 기밀 유지 및 존중할 책임

B. 이해 상충 상황 및 기타 금지된 직무상 행위

- 고객/의뢰인의 권익 침해 및 전문가로서의 판단력 손상을 피해야 할 책임

- 개인 이득을 위한 부적절한 대가, 선물 및 기타 형태의 보상을 피해야 할 책임

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=500

---

지금까지 PMI에서 정의한 프로젝트 관리를 위한 9개의 지식 영역과 각 영역에 해당하는 43개의 개별 프로세스에
대해 살펴 보았다

이러한 프로세스들은 '착수/기획/실행/감시및통제/종료'라는 5개의 프로세스 그룹으로 나눌수 있다

아래표는 각 지식 영역과 프로세스 그룹을 매핑한 표이다 

* 9대 지식영역 / 4대 프로세스그룹 매핑표

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=499

---

통합 관리

 지금까지 범위, 시간, 원가, 품질, 인적자원, 의사소통, 위험, 조달 등 프로젝트 수행에 필요한 지식영역에 대해
알아보았다. 프로젝트는 이와 같이 다양한 영역과 과정을 통해 수행된다

통합관리는 말 그대로 프로젝트의 시작부터 종료까지 전 과정에 대한 통합을 원활히 하기 위한 방법론을 다룬다.
프로젝트 수행을 공식적으로 승인 받고 목적과 요구를 확인하고 작업을 지시하고 각 영역의 진행 및 변경 사항을
통합하여 전체 프로젝트에 대한 흐름을 조절하고 프로젝트의 공식적인 종료절차를 밟는 등 프로젝트 수행 전 과정
에 대한 통합적 관리를 다룬다

통합 관리는 PM이 직접 수행해야 하는 아주 중요한 임무이자 의무라 할 수 있겠다.

PM은 통합관리만큼은 다른 (하위) 관리자에게 위임해서는 안 된다. 직접 프로젝트 전반적인 통합관리를 적극적으로 수행해야 한다

통합관리는 다음과 같은 프로세스로 이루어져 있다

프로젝트헌장 개발 -> 예비 프로젝트 범위명세서 개발 -> 프로젝트관리 계획 개발 -> 프로젝트 실행지시 및 관리 -> 프로젝트 작업감시 및 통제 -> 통합변경 통제 -> 프로젝트 종료

* 프로젝트 헌장 개발

프로젝트 헌장은 프로젝트 수행을 승인 받는 공식적인 승인문서이다

PM에게 조직 자원에 대한 사용 및 관리를 공식적으로 승인하고 프로젝트 수행과 관련된 책임과 권한을 명시한다.
보통 프로젝트 수행을 위해 PM이 조기에 임명되는 것이 좋으며 되도록이면 프로젝트 헌장이 작성될 때 임명되는
것이 좋다.

프로젝트 헌장을 만들기 위해 다음과 같은 투입물이 요구된다

1) 계약

외부 고객이 의뢰한 프로젝트 인 경우. 또는 필요한 경우

2) 프로젝트 작업 명세서

프로젝트에 의해 제공되는 제품이나 서비스를 설명한 문서이다

기타 사업적 요구, 제품 범위 명세서, 전략 계획을 포함시킨다

3) 기업 환경 요인

해당 기업의 문화 및 특성, 인적자원, 시장조건 등 기업 환경요인은 프로젝트 성공에 필수적이다

4) 조직 프로세스 자산(OPA)

조직의 표준 프로세스, 가이드, 템플릿, 기준, 절차, 정보시스템 및 과거 프로젝트 경험과 지식 및 학습을 총괄한
조직 프로세스 자산 역시 프로젝트 성공에 중요한 요인으로 작용한다

프로젝트 헌장에는 다음과 같은 것들이 명시된다

-          프로젝트 명칭 및 사업 영역

-          사업 후원자

-          프로젝트 관리자

-          착수 일자와 승인된 완료 일자

-          승인된 예산

-          제품 및 프로젝트 설명

-          사업 사례

-          프로젝트 핵심 성공 요인 및 제약 조건과 가정

-          기타 프로젝트 수행에 필요한 항목 명시

* 예비 프로젝트 범위명세서 개발

프로젝트에서 제공해야 할 제품 및 서비스에 대한 상위수준의 범위 명세서를 개발하는 단계이다

예비 프로젝트 범위명세서에는 다음과 같은 내용들이 포함된다

-          프로젝트/제품 목적

-          제품/서비스 요구사항과 성격

-          제품 인수 기준

-          프로젝트 경계(Boundary), 범위

-          프로젝트 요구사항 및 산출물

-          프로젝트 가정 사항

-          일정 이정표

-          초기 WBS

-          프로젝트 규모(비용 예측)

-          요구사항 승인

* 프로젝트 관리 계획 개발

프로젝트의 전 과정에 대한 관리 계획들을 정의, 준비, 통합, 조정하기 위한 계획을 작성하는 단계이다

프로젝트의 목표와 달성 방법에 관한 사항을 포함하고 있는 프로젝트의 기본이 되는 문서로서 작업 시작 전 참여한 모든 사람들과 공통적인 이해를 구하기 위해 작업 내용, 방법, 시기 등을 정의한다. 프로젝트 관리 방법론 및 프로젝트 관리를 위한 정보 시스템을 활용하여 계획서를 작성하며 다음과 같은 내용들이 기술된다

-          프로젝트 범위 관리 계획

-          일정 관리 계획

-          원가 관리 계획

-          품질 관리 계획

-          프로세스 개선 계획

-          직원 충원 관리 계획

-          의사소통 관리 계획

-          위험 관리 계획

-          조달 관리 계획

-          이정표 목록

-          자원 달력

-          일정 기준선

-          원가 기준선

-          품질 기준선

-          위험 등록부

∥ 프로젝트 관리 계획 수립 기법

프로젝트 관리 계획의 수립을 위해 다음과 같은 접근 방식을 활용할 수 있다

1) 하향식(Top-down)

먼저 큰 틀을 만들고 틀에서 그 틀 내에서 세부 계획을 수립하는 방식이다

추상적인 상위 수준의 계획을 수립한다

일정 및 비용을 맞추기 위해 적용할 만 하다

작성하기가 용이하지만 현실적이지 않을 수 있다

2) 상향식(Bottom-up)

상세한 세부 계획들을 만들고 이를 통합하여 전체 계획을 수립하는 방식이다

계획의 신뢰성은 높으나 시간이 많이 걸리는 단점이 있다

3) 점진적 구체화(Rolling-wave)

일정상 가까운 계획 및 식별이 용이한 항목은 상향식으로 수립하고 먼 계획은 하향식으로 수립하는 방식이다.
즉 점진적으로 구체화 시켜나가는 방식으로서 현실적인 계획 수립이 가능하지만 경험을 활용하여 많은 계획 수립
기법을 적용해야 해야 하는 단점이 있다

* 프로젝트 실행 지시 및 관리

본격적으로 프로젝트를 실행하도록 지시하고 관리하는 단계이다

프로젝트 범위 명세서에 정의된 요구사항을 달성하기 위해 프로젝트 관리 계획의 작업들을 수행하도록 관리한다

이 단계의 투입물은 다음과 같다

1) 프로젝트 관리 계획

2) 승인된 예방 조치 및 교정 조치

   이후에 알아볼 프로젝트 통제 단계에서 승인한 예방과 교정 사항이 실행단계에 다시 투입물로 넘어와서 실제
   수정 작업을 하게 한다.
   참고로 예방조치는 잠재적인 원인을 제거하는 활동이며 교정조치는 현존하는 원인을 제거하는 활동이다

3) 기타 승인된 변경 요청, 하자 보수 등

프로젝트 실행 지시 및 관리 프로세스에서는 주기적으로 수행한 작업에 대한 보고 활동이 있어야 한다

* 프로젝트 작업 감시 및 통제

프로젝트 전 과정을 감시하고 통제하는 단계이다

계획대로 성과 목표를 달성하기 위해 프로젝트를 착수, 계획, 실행, 종료하는 과정과 활동들이 잘 수행되고 있는지를 감시하고 통제하도록 한다

이 단계에서는 다음과 같은 활동을 하도록 한다

- 프로젝트 관리 계획 대비 실제 성과를 비교한다

- 예방 및 교정 조치가 필요한지 판단하기 위해 성과를 평가하고 조치가 필요하다면 권고한다

- 프로젝트의 위험을 분석하고 추적, 감시한다

- 프로젝트 현황 정보를 제공한다

- 승인 받은 변경이 적절히 반영되고 있는지 감시한다

- 기타 프로젝트 전반에 대한 감시 및 통제 활동

감시 및 통제를 통해 교정 조치, 예방 조치, 변경 조치 등을 권고하게 된다

이는 다시 이전 프로세스인 ‘프로젝트 실행 지시 및 관리’로 넘어가 실제 수행하도록 한다

* 프로젝트 종료

프로젝트를 공식적으로 종료하는 단계이다 프로젝트 수행과 관련된 모든 활동들을 종료한다.

프로젝트 종료에는 계약종료와 행정종료로 나누어진다

1) 계약 종료

프로젝트에서 체결된 모든 계약들에 대해 검수 및 정산하고 종료하는 활동이다

행정종료 절차를 지원하기 위한 절차이기도 하다

2) 행정 종료

프로젝트의 기록들을 수집하고 성패를 분석하고 교훈을 모아 프로젝트 정보를 보관하는 활동이다

이렇게 축적한 자료들은 기업의 프로젝트 경험 자료 및 교훈 자료로 활용된다

그리고 팀원을 공식적으로 해체하도록 한다

행정종료가 끝나야 비로서 프로젝트는 공식적으로 종료되는 것이다

이 글은 제가 과거에 운영했던 사이트인 http://mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=498

---

* 계약 행정

계약이 성립되고 계약서에 날인 한 다음에는 계약 행정 업무가 이어진다

계약 행정 프로세스에서는 계약 및 공급업자와 관계를 관리하고 성과 검토 및 문서화를 하며

필요 시 계약 관련 변경을 관리하게 된다.

1) 계약 변경

만일 계약 이후 계약과 관련한 변경사항이 발생하면 변경 관리 시스템에 의해 처리하여야 하며

이는 통합 변경 통제 시스템과 통합되어 관리해야 한다.

2) 성과 검토

그리고 계약된 내용대로 공급 활동이 잘 진행되고 있는지 성과 검토가 필요하다.. 즉 과정과 결과에 대한
검사 및 감사를 실시해야 한다

3) 지불 시스템

계약과 관련해 공급자(판매자)에게 계약된 비용을 지불해야 한다

4) 분쟁 관리

계약 활동 중 발생한 분쟁을 관리한다

클레임은 계약 기간 동안 계약 조항에 따라 문서화되고, 처리, 감시, 관리되어야 한다

분쟁 당사자간 문제 해결이 되지 않는 경우 계약서에 지적된 분쟁 해결 절차에 따라 진행되어야 한다

이러한 계약행정에 있어 PM의 역할도 중요하다. 아래는 계약 형태에 따른 PM의 역할을 설명한다

잘 협상된 계약 및 계약서를 작성하여도 간혹 이해상충이 발생할 수 있다

예를 들어 계약서에 금액을 기재할 때 어떤 곳에는 숫자로 기입하고 어떤 곳에는 문자로 기입하였을 때는
문자가 우선하게 된다.
즉 숫자로 ‘100,000’ 이라 하고 문자로 ‘백만원정’ 이라고 기재되었다면 ‘백만원’이 인정되는 셈이다

이러한 선, 후 관계와 관련한 계약 유권 해석은 다음과 같다

-          문자 > 숫자

-          신법 > 구법

-          특별 조항 > 일반 조항

-          산업 표준 용어 > 일반 용어

-          계약서 사인 시 손으로 추가한 문구 > 계약서 내 인쇄된 내용

* 계약 종료
 

계약과 관련한 모든 것을 종결하는 프로세스이다

모든 미결 항목들에 대한 해결을 포함하여 각 계약을 완료/정산하고 프로젝트 혹은 프로젝트 단계의 각 계약을
종료한다

∥ 조달 감사

조달과 관련한 전 프로세스에 대한 구조적인 검토를 수행한다

조달 감사의 목적은 다른 프로젝트로 전수해 줄 수 있는 성공과 실패를 식별하기 위함이다

∥ 계약 종료

고객 측 계약 관리 책임자가 판매자에게 계약이 완료되었다는 사실을 문서로 공식 통지한다

1) 제품(산출물) 검증

계약의 대상 제품 또는 서비스에 대해 정확히 그리고 만족스럽게 완료되었는지 검증한다

2) 행정 종료
모든 계약과 관련한 기록을 최종 결과를 반영하여 최신 상태로 수정하고 마지막 잔금을 지불하고 비용과 관련한
기록들을 완성하여 다음에 사용하기 위해 이력 정보로 보관하는 행정적인 종류절차이다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=496

---

* 계약 업무 기획

구매 및 획득 계획이 수립되면 본격적으로 계약을 위한 사전 활동인 계약 업무에 대한 계획을 수립해야 한다.
계약 업무 기획 단계에서는 제품, 서비스, 결과물의 요건을 문서화하고 대상 판매자(조달자)를 식별하는 활동을
하게 된다. 계약 업무 기획을 위해 이전 단계에서 산출된 조달 관리 계획과 계약 작업 명세서(SOW)를 참고하게 된다

∥ 조달 문서

조달한 항목이 정해지면 대상 판매자 에게 제안을 하도록 요청해야 한다. 제안 요청을 위한 문서를 조달 문서라 한다. 조달 문서는 판매자가 정확하고 완전한 답변을 할 수 있도록 잘 구조화되어야 한다

조달 문서에는 다음과 같은 사항들이 기술된다

-          제안에 필요한 정보 및 배경
-          표준화된 제안서 양식과 제출 절차 등에 대한 설명
-          제안 평가 기준
-          제안 가격 작성 양식
-          작업 명세서(SOW)
-          계약서 조항

조달문서의 유형으로는 RFP, IFB, RFQ 등이 있다

∥ 평가 기준

판매자가 제안서를 제출하면 등급 및 점수를 부여하기 위한 객관적/주관적 기준을 마련하도록 한다

아래와 같이 평가 기준을 설정할 수 있다

* 판매자 답변 요청

구매 및 획득 기획과 계약 업무 기획을 완료되면 판매자의 답변을 요청하게 된다

즉 조달을 담당하게 될 업체로부터 제안서를 받는 단계이다

∥ 판매자 답변 요청 기법

1) 입찰 설명회

잠재적인 판매자들을 모아놓고 조달과 관련된 설명회 및 회의를 개최하는 방법이다

판매자들이 조달에 대해 분명하고 공통된 이해를 가지도록 해 줘야 한다

이 과정에서 모든 판매자들은 평등한 입장에 있어야 한다

2) 광고

신문이나 저널 등과 같은 간행물에 광고를 실어 판매자를 모으는 방법이다

일부 공공 기관에서는 조달을 할 때 반드시 광고를 하도록 법적으로 요구되기도 한다

3) 적합 판매자 목록 작성

조달에 적합한 판매자를 조직의 경험이나 프로젝트 팀의 경험 혹은 조사 등으로 목록을 작성하는 방법이다.
인터넷, 인명록, 관련협회, 카탈로그와 같은 정보를 활용 할 수 있다

∥ 제안서

‘판매자 답변 요청’ 프로세스의 궁극적인 목적은 업체로부터 제안서를 받는 것이다

제안서는 요청된 제품, 서비스, 결과물을 제공할 수 있는 판매자의 능력과 의지를 판매자가 직접 기술,
작성한 문서이다. 또한 구매자의 요청에 대한 판매자의 대응으로써 공식적이고 법적인 청약(Offer)이다

또한 실제 계약서에서 누락된 항목은 제안서가 기준이 되기도 한다

∥ 비경쟁 조달

보편적으로 조달을 할 때 여러 판매자들을 대상으로 평가하고 검토하여 선정하게 된다

그러나 때로는 이러한 선정과정 없이 한 업체에게 맡겨야 하는 경우가 있을 수 있다

이를 비경쟁 조달이라 하는데 다음과 같은 경우이다

-          일정에 상당한 압박이 있는 경우

-          오직 하나의 판매자만 존재할 경우

-          판매자가 특허를 보유하고 있을 경우

-          기타 판매자에 대한 합리성/신뢰성이 다른 방법에 의해 사전에 보증된 경우

비경쟁 조달의 유형은 다음과 같다

1) Single Source

조달 절차를 거치지 않고 선호하는 단골(지정) 판매자와 직접 계약하는 경우이다

구매자가 선호하는 판매자가 있거나 여러 이유로 해서 다른 판매자를 찾기 원하지 않을 경우이다

2) Sole Source

오직 하나의 판매자만 있거나 판매자가 특허를 보유하고 있는 경우이다

* 판매업자 선정

제안서를 검토하고 판매자를 선정하여 계약 협상을 진행하는 단계이다. 이 단계에서 실질적인 계약서를 작성하게
된다

∥ 판매자 선정 기법

1) 가중치 결정 시스템

선정 과정에 개인적인 선입견을 없애기 위해 정성적 데이터를 계량화하는 방법이다

- 각 평가 기준에 수치적 가중치를 부여함

- 각 기준에 따라 잠재적 판매자의 등급을 부여함

- 가중치와 등급을 곱함

- 곱한 결과들을 합산하여 전체 점수를 계산함

2) 자체 산정(독립 견적)

판매업자의 제안가와 예상했던 예상가를 비교하여 근사치를 찾는다

판매자가 조달 항목에 대해 정확하게 이해했는지 평가하기 위해 미리 내부에서 ‘예가(should cost)’ 를 추정하여 차이가 큰 업체를 제거하는 방법이다

예가와 제안가의 금액 차이가 큰 경우,

계약 작업 명세서를 적절히 만들지 못하여 판매자가 조달 항목을 제대로 이해하지 못하였거나 답을 완벽히 제시하지 못하였거나 또는 시장상황이 바뀐 경우이다

3) 선별 시스템

최소 기준(제약조건)을 제시하는 선별시스템(screening system)을 이용하여 최종 검토대상 업체 리스트를 작성하기 전에 조달 항목 공급에 적합하지 않은 판매자들을 미리 제거하는 방법이다

∥ 계약 협상

본격적인 계약서에 서명하기 전에 계약의 구조와 요구조건을 명확히 하여 상호간에 합의가 이루어지도록 하는
해야 한다. 최종 계약서에는 모든 합의 사항들이 반영되어야 한다

계약 협상의 결론은 판매자와 구매자가 상호 사인한 계약서로 귀결된다

PM이 협상과정에서 선입 협상자가 아닐 수 있으며, 프로젝트 관리자 및 팀은 협상 과정에 참여하여

프로젝트의 기술적, 품질, 관리상의 요구사항을 명확히 제시할 필요가 있다

계약과정에서 PM은 다음과 같은 역할을 해야 한다

-          위험을 식별하여 이에 대한 완화와 분배 조항을 계약서에 포함하도록 한다

-          계약서의 내용이 해당 프로젝트의 요구에 잘 맞도록 계약담당자를 지원한다

-          조달 프로세스의 완료일정이 프로젝트의 공정과 잘 맞아 들어가도록 조치한다

-          계약의 협상과정에 참여한다

-          판매자와의 관계를 보호한다

협상은 공정하고 합리적인 가격을 도출(win-win)해야 하며 판매자와 구매자간 상호 우호적인 관계를 조성하도록
해야 한다

계약을 위한 주요 협상 항목은 다음과 같다

-          책임 및 권한

-          적용 법률 및 조항

-          기술 및 관리 방법

-          기술 솔루션

-          계약 자금 조달

-          일정

-          가격

-          대금 지급

∥ 계약서

판매자 선정과정에서 주요 산출물은 계약서이다

계약서는 판매자에게 명세화된 제품, 서비스, 결과물을 공급할 의무를 지우고, 구매자에게 대가를 지불할 의무를
지우는 상호 구속력 있는 협정이다

∥ 합법적 계약의 조건

계약의 대상인 제품이나 서비스(용역)가 합법적인 것이어야 한다

계약 당사자간에 청약, 승낙, 대가지불과 같은 과정을 거쳐 자발적인 의사표시에 의한 것을 입증할 수 있어야 한다

-          청약(Offer): 상대방에게 계약의 조건을 알리는 의사표시
-          승낙(Acceptance): 상대방이 제시한 청약에 대하여 거래 상대방이 동의한다는 의사표시
-          대가(Consideration): 계약을 체결하여 계약 당사자에게 생기는 이익

계약의 법적 효과는 직접 계약 당사간에만 성립한다

예를 들어 갑과 여러 을이 계약한 경우 을간에는 직접적인 계약관계가 없으므로 반드시 갑을 통하여 의사소통을
수행해야 한다

∥ 계약 관리 조직 유형

조직에 따라 계약 업무를 전담하는 부서가 있을 수도 그렇지 않을 수도 있다

프로젝트에 상관 없이 조직의 계약 업무만을 전담으로 맡아 수행하는 조직 형태를 중앙집권화 계약조직이라 하며
각 프로젝트 별로 계약 업무를 수행하는 분권화 계약조직이 있을 수 있다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=495

---

조달 관리

프로젝트를 수행하기 위해 모든 것을 자체적으로 개발, 생산하지는 않는다.

전문 외부업체로부터 솔루션을 구매하거나 기술을 획득하거나 하는 등의 조달이 필요하다

조달관리에서는 이러한 프로젝트 수명주기 동안 발생하는 조달에 관한 전반적인 관리 방법론을

다룬다. 그리고 간과하지 말아야 할 것은 외부로부터의 조달이라 할 지라도 조달 품목, 자원의

품질에 대한 궁극적인 책임은 여전히 프로젝트 수행 조직에 있음이다

조달관리는 다음과 같은 프로세스로 구성되어 있다

구매 및 획득 기획 -> 계약 업무 기획 -> 판매업자 답변 요청 -> 판매업자 선장 -> 계약 행정 -> 계약 종결

* 구매 및 획득 기획

조달이 필요한 자원이 어떤 것이며, 언제 어떤 식으로 조달하겠다는 계획을 수립하는 단계이다

규모 있는 조직 혹은 프로젝트에서는 ‘구매/계약’을 위한 전담 부서가 존재하지만 그렇지 않은 경우도 있다.
이럴 경우 구매활동에 필요한 인력과 전문적 지식은 프로젝트 팀에서 제공해야 한다

∥ 제작/구매 분석

자체 제작이 나은지 외부 조달이 나은지를 여러 측면에서 판단하여야 한다

비용을 비교할 때 구매와 관련한 직접비용 이외에도 구매 프로세스를 관리하기 위한 간접비용까지 고려되어야 한다. 자체제작과 구매의 의사 결정 기준은 다음과 같다

-          비용
-          자체 기술력
-          지적 재산권
-          인적자원 가용성
-          작업 통제에 대한 수준
-          사업 구조에 따른 필요

예를 들어 이미 타 업체에서 특허를 딴 기술이나 지적 재산권이 존재하는 경우 외부 조달이 필요할 것이다.
반대로 핵심 사업 분야일 경우 자체 생산을 해야 한다. 그리고 보편적으로 자체 생산 비용과 조달 비용을 비교하여
결정한다

∥ 계약 유형

외부 조달 시 계약을 체결하게 되는데 비용과 관련해 다음과 같이 계약 유형이 나누어 진다

1) 총액 계약(고정가 계약)

Fixed Price 또는 lump-sum contracts라 한다

말 그대로 고정된 가격으로 계약을 체결하는 유형이다.

보통 완제품 계약에 해당하며 요구사항이 분명하고 변경 가능성이 희박할 때 적절한 계약 유형이다

이 계약 유형에서는 제품결함으로 인한 추가 비용은 판매자가 책임진다. 즉 판매자가 재무적인 위험을지게 된다.

총액 계약 방식의 가장 단순한 계약 형태는 Purchase Order 이다.

보통 계약은 청약->승낙->대가지불의 단계를 가지는데 Purchase Order은 승낙 단계가 없는 형태이다

즉 계약 양 당사자가 모두 사인하는 것이 아니라 한 쪽만의 사인으로 계약이 이루어지는 거래 관행에서 사용되는 형태이다. 예를 들어 수퍼에서 ‘껌 하나 주세요’ 로 계약이 체결되는 것과 같다

총액 계약은 다음과 같이 세분화 된다

- FFP(Firm Fixed Price)

가장 순수한 총액 계약 형태이다.

- FPPEA(Fixed Price Plus Economic Adjustment)

  원칙은 고정가 이지만 환률, 유가와 같은 경제적 요인을 반영해 주는 개념이다

- FPIF(Fixed Price Plus Incentive Fee)

  원칙은 고정가 이지만 판매자 동기부여를 위한 인센티브를 더해 주는 개념이다

2) 비용 상환 계약

Cost-reimbursable contracts라 한다

총액계약이 고정된 금액이 존재하는 반면, 비용 상환 계약은 실제 발생한 원가와 함께 수수료를 지불하는
계약형태이다. 요구사항이 모호하거나 변경 가능성이 다분할 때 적절한 계약 형태이다

이 계약 유형에서는 구매자가 재무적인 위험에 대한 책임을 지게 된다

비용 상환 계약은 다음과 같이 세분화 된다

- CPPC(Cost Plus Percentage of Cost)

발생한 원가의 몇 %를 더 주는 개념이다. 업체 즉 판매자가 가장 선호하는 방식이지만

원가를 올려 수수료를 많이 받게 되는 형태가 나올 수 있어 미 정부에서는 금지한 계약 유형이다

- CPFF(Cost Plus Fixed Fee)

  원가에 더불어 고정된 수수료를 지급하는 유형이다

- CPIF(Cost Plus Incentive Fee)

원가에 더불어 인센티브를 지급하는 유형이다

3) 단가 계약

T&M(Time and Material) contracts 라 한다

총액 계약과 비용 상환 계약이 혼합된 형태이다. 가장 빠르게 계약을 체결할 수 있는 유형이다

단가는 있지만 총액은 없는 경우를 예로 들 수 있다(ex: 전문가 컨설팅 회 별 단가)

정해진 총액이 없으므로 비용상환계약과 유사하며, 구매자/판매자가 사전에 단가를 정하므로 고정가 계약과 유사하다 할 수 있다. 전문직, 임시직 고용 계약에 많이 사용되는 유형이다.

∥ FPIF vs CPIF

1) FPIF(Fixed Price Plus Incentive Fee)

실제원가(Actual Cost)를 목표원가(Target Cost) 이하로 절감했을 때 인센티브를 제공하되 총 가격을 통제한다.
다시 말해 최고가격(Ceiling Price)를 정해두고 원가가 특정 금액을 넘지 못하도록 억제하는 방법이다.
원가 절감 금액에 대한 ‘구매자비율 : 공급자비율’ 을 사전 합의, 배분한다

최종비용이 목표원가를 초과하여 구매자가 판매자에게 지불해야 하는 금액이 가격 상한선(Price Ceiling)에
도달할 수 있는 시점을 PTA(Point of Total Assumption)라 한다

PTA = (Ceiling Price ? Target Price) / 구매자의 배분 비율 + Target Cost

PTA 지점까지는 구매자, 판매자의 공동부담이지만 그 이상부터는 모두 판매자가 부담해야 한다

2) CPIF(Cost Plus Incentive Fee)

실제 원가를 보장해 준다. 실제원가를 목표원가 이하로 절감했을 때 인센티브를 제공한다

이때 인센티브의 최소 금액과 최대 금액을 둘 수 있다

3) FPIF, CPIF 계산 샘플

문제>

당신은 예상비용이 200,000이고 예상 수수료가 20,000인 계약을 맺고 있다. 그리고 구매자:판매자 분담 비율은 60:40이다. 계약형식이 CPIF이고 실제 비용이 210,000일 때 최종 가격을 계산하시오

그리고 같은 조건일 때 최고가격이 225,000인 FPIF계약일 때 최종 가격을 계산하시오

답>

주어진 조건의 계약상황에서 CPIF 와 FPIF를 구하는 문제이다

목표비용(Target Cost), 목표수수료(Target Fee)가 주어져 있고 이 둘을 합치면 목표가격(Target Price)이 된다. 그리고 분담비율(Sharing Ratio)이 60:40이며 실제비용(Actual Cost)이 제시되어 있다

주어진 값을 기반으로 아래와 같은 표를 만들어 보자

Incentive가 ?(마이너스)가 나올 수 있다. 이 경우에는 인센티브라기 보다는 패널티의 개념이다

∥ 계약 형태별 장단점 비교

∥ 구매 및 획득 기획 산출물

구매 및 획득에 관한 기획, 계획이 완료되면 조달관리계획과 계약 작업 명세서를 산출하고 제작/구매에 대한 의사결정을 해야 한다

1) 조달 관리 계획

조달관리계획에는 조달 문서 작성에서부터 계약 종료 시 까지 조달 프로세스가 어떻게 관리될 것인지를 기술한다

다음의 것들을 포함한다

-          프로젝트에 적용될 계약 유형

-          견적과 관련해 누가 어떤 식으로 준비할 것인가?

-          추정치에 대한 평기 기준

-          조달 담당 부서와 프로젝트 팀의 역할 및 책임의 분담

-          다수 판매자에 대한 관리 계획

-          조달과 관련한 제약사항과 가정들

-          계약 관리 및 판매자 평가 시 사용할 측정 기준

-          필요한 리드타임과 프로젝트의 일정간의 조정

2) 계약 작업 명세서

계약작업명세서는 SOW(Statement of Work)라 한다.

SOW는 관련 계약서에 포함될 프로젝트의 범위에 대해 정의한 문서이다

판매 대상자가 조달 항목들을 공급할 수 있는지 판단할 수 있도록 충분히 상세하고 명확하고 간결하게 작성되어야
한다

∥ SOW(Statement of Work)

조달하게 될 자원에 대해 설명한 문서이다

자원을 조달하게 될 판매자가 조달 자원에 대해 정확히 이해할 수 있도록 정확히 작성해야 한다

나아가 판매자가 더 발전적인 제안을 할 수 있도록 융통성과 여지를 남겨두는 것도 중요하다

SOW는 실제 계약 체결 시 계약서의 일부분으로 포함되는 문서이다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=494

---

* 위험 대응 기획

위험에 대한 식별과 분석 및 정성/정량적 영향도 등이 모두 파악되고 나면 본격적으로 위험을 어떤 식으로
대처할지에 대한 방법론을 기획하는 단계가 위험대응기획 프로세스이다

위험은 회피하거나 전가 시키거나 완화하거나 수용하는 등 여러 형태로 대응을 할 수 있다

위험의 성격이 부정적인 사건인지 긍정적인 사건인지 기회인지 등에 따라 대응 방법을 나누어 볼 수 있다

∥ 위험 대응 전략

1. 부정적 위험에 대응하는 전략

a. 회피(Avoidance)

위험을 회피하는 전략이다. 위험으로부터 프로젝트를 보호하기 위해 원래 계획을 변경하여 회피하는 전략이다.
예로 익숙하지 않은 하청업체를 피하는 방법이나 경험 없는 신기술 보다는 기존 기술을 활용하는 것으로 변경하는 것 등을 들 수 있겠다

b. 전가(Transfer)

위험에 대한 책임을 제 3자에게 전가 시키는 전략이다

이는 위험을 단지 다른 당사자에게 위험 관리의 책임을 주는 것이지 위험을 제거하는 것은 아니다

보험 이나 외주가 전가의 대표적인 사례인데 재무적인 위험을 다룰 때 가장 효과적이라 할 수 있다

c. 완화(Mitigation)

원래 계획은 변경하지 않고 위험이 발생활 확률이나 영향을 최소화하는 전략이다

예를 들어 일정 위험이 있을 경우 기존 일정 계획을 준수하기 위해 자원이나 시간을 투자하여 위험을 완화시킬 수
있다. 직원 교육 역시 위험을 완화하는 활동이라 할 수 있겠다

2. 긍정적 위험에 대응하는 전략

위험(Risk)는 비단 부정적인 사건만을 뜻하지는 않는다

프로젝트 수명주기 동안 발생하는 여러 사건,이슈,이벤트들이 위험의 대상이며 이는 긍적적인 위험도 관리대상에
포함되는 것이다

a. 활용(Exploit)

긍적적인 사건을 최대한 활용하는 전략이다

기회가 실현될 수 있도록 활용하고 긍정적인 영향력을 가진 사건을 선택한다

훌륭한 자원을 보다 많이 배정하여 프로젝트의 일정이나 품질을 초기 계획보다 향상하거나 신시장을 개척하는 것 등을 활용을 사례로 들 수 있겠다

b. 공유(Share)

프로젝트의 이익을 위해 기회를 포착할 수 있는 적절한 제 3자와 공유하는 전략이다

협력 관계 팀, 특수 목적 회사 또는 제휴 체결 등이 공유의 사례이다

c. 향상(Enhance)

긍정적 위험 즉 기회의 영향을 증가시키고 최대화함으로써 기회의 규모를 확장시키는 전략이다

3. 기타(공통)

a. 수용/감수(Acceptance)

위험을 수용하는 전략으로 위험에 대한 별도의 대응을 하지 않고 계획 변경도 하지 않는 전략이다.

위험 발생 시 ‘돌발 상황을 계획’하는 적극적 수용과 아무런 조치도 취하지 않는 소극적 수용이 있다

돌발 상황 계획은 프로젝트 중에 발생하는 위험에 적용된다. 동발 상황을 대처하기 위해 예비비(Reserve)를 계획에
반영한다

b. 우발적 대응 전략

일부 대응책은 특정 사건이 발생하는 경우에만 사용하도록 설계 한다.

위험 대응 기획 단계를 거쳐 위험 등록부에 다음과 같은 항목을 갱신하도록 한다

-          적절한 대응책을 선택하여 합의한 후 이를 기록한다

-          위험을 어떤 식으로 대응하겠다는 상세한 내용을 정의한다

* 위험 감시 및 통제

위험의 징후나 발생 여부를 감시하고 새로운 위험, 잔여 위험을 감시, 식별하며 위험 완화 계획을 실행하여 프로젝트 수명 주기 전체에 걸친 그 효과를 평가하는 단계이다

∥ 위험 감시 점검 항목

-          위험 대응 활동이 계획대로 잘 실행되고 있는가?

-          위험 대응 활동이 예상대로 효과적인가?

-          새로운 대응 방법이 필요하진 않은가?

-          위험 확률이나 영향도가 변경되었는가?

-          위험 증상이나 경고가 발생하였는가?

-          적절한 위험 전략과 정책, 절차를 따르고 있는가?

-          사전에 식별되지 않은 위험이 발생하거나 대응된 위험에 대한 잔여 위험은 없는가?

∥ 위험 통제

1) 비상 계획 실행 (Contingency Plan)

위험이 발생하면 위험 기획, 계획 단계에서 수립한 대응 방법을 실행한다

즉 예상하고 계획된 대로 위험을 통제한다

2) 워크어라운드 계획 실행 (Workaround Plan)

임기응변으로 위험을 대처한다

사전에 식별하지 못했거나 비상 계획이 수립되지 않은 위험을 임기응변으로 통제한다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=493

---

* 정성적 위험분석

‘위험식별’ 단계를 통해 식별된 위험을 심층 분석하기 전에 위험에 대한 우선순위를 정하는 단계이다.

우선순위를 정하기 위해 위험이 발생할 확률 및 영향을 ‘정성적’으로 판단한다

∥ 위험 확률 및 영향 평가

위험 확률과 영향의 등급을 매우 높음/높음/중간/낮음/매우 낮음과 같이 정성적 표현으로 기술한다

위험 확률이란 위험이 발생할 가능성이며 위험 영향이란 위험이 발생할 경우 프로젝트 성공에 미치는 영향을 말한다

∥ 확률 및 영향 매트릭스(PI Matrix)

위험 확률과 영향을 매트릭스 구조로 표현한다

위험에 대한 우선순위는 매트릭스와 각 위험에 대한 위험 척도를 사용하여 완성된다

1) 위험 확률

전문가의 정확한 판단이 있어야 한다

확률의 등급은 서열 척도(거의 가능성 없음, 거의 확실 등) 또는 기수 척도(0.1, 0.2, 0.3……)가 이용될 수 있다. 기수 척도는 선형적(0.1, 0.3, 0.5, 0.7……)일수도 비 선형적(0.1, 0.2, 0.4, 0.8……)일수도 있다

2) 위험 영향

위험이 프로젝트 성공에 미치는 영향의 심각도를 측정한다

영향의 등급은 서수 척도(낮음/중간/높음) 또는 기수 척도(0.1, 0.2, 0.3……)가 이용될 수 있다

PI 매트릭스

정성적 위험분석을 통해 위험을 서열화 하여 위험에 우선순위를 정하게 된다

이 과정을 통해 위험식별 프로세스의 산출물인 ‘위험등록부’에 다음과 같은 항목들을 갱신한다

- 위험 우선순위 목록

- 정성적 위험 분석 결과의 추세

- 추가적인 분석 및 대응이 필요한 위험

* 정량적 위험분석

위험의 영향을 구체적인 수치로 분석하는 단계이다. 정량적 분석을 통해 프로젝트 목표의 달성확률을 구한다

∥ 민감도 분석

프로젝트 성공에 영향을 주는 여러 요인 중 어떤 요인이 잠재적으로 가장 영향을 미칠 것인지를 판단하는 기법이다. 독립변수와 종속변수의 두 변수로 판단하는 기법이며 단순하고 오차가 많은 대신 신속히 파악할 수 있다는 장점이 있다. 어느 한 요인의 변화가 어떤 식으로 영향을 주는지 분석하는 기법으로 다음과 같은 분석을 예로 들 수 있다

-          년도에 따른 소득의 변화(독립변수: 년도, 종속변수: 소득)

-          재료 X의 사용 한도에 따른 생산성의 변화(독립변수: 재료 X 사용 한도, 종속변수: 생산성)

∥ 의사결정수 분석

어떤 의사결정을 했을 때 어떤 결과가 나타나는지 그 경우를 따져보는 기법이다
의사결정 트리를 만들어가면서 의사결정수 분석을 수행한다

∥ 모델링 및 모의 실험(Modeling and Simulation)

몬테카를로 시뮬레이션이라고도 한다

불확실한 분포를 갖는 변수의 계산을 모의 실험으로 수행하는 기법이다.

원가 위험분석의 경우 WBS(Work Breakdown Structure)가 시뮬레이션의 모델이 되고

일정 위험분석의 경우 PDM(선후행 도형법)이 모델이 된다

시뮬레이션 결과를 분석하여 실현 가능한 목표를 설정하게 된다

정량적 위험분석 단계를 통해 다시 ‘위험 등록부’의 다음과 같은 항목들이 갱신된다

-          확률적 프로젝트 분석

-          비용/시간 목표 달성 가능성

-          우선순위가 부여된 정량적인 위험,
정량적인 위험 분석 결과 내의 추세

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=492

---

위험 관리

프로젝트 수행이란 것이 항상 계획한대로 순조롭게 진행될 수는 없다

다양한 내/외부 요인으로 인한 위험요소는 발생하기 마련이다. 위험관리에서는 이러한 위험에 대한

총체적인 관리 방법론을 다룬다.

위험은 발생확률(risk event probability) 미치는 영향(risk impact) 그리고 이 둘을 곱한(확률 * 영향)

위험상태(risk status)를 위험의 3요소라 한다

그리고 위험은 사전에 식별할 수 있는 수준에 따라 구분된다

1) Known unknown

발생 가능성을 사전에 식별할 수 있는 위험. 이러한 위험을 대비하기 위한 적절한 예비비(Contingency Reserve)를 예산에 포함한다

2) unknown unknown

발생 가능성을 사전에 식별할 수 없는 위험. 인지할 수 없으므로 위험을 관리할 수도 없다

이러한 위험이 발생하면 관리 예비비(Management Reserve)가 사용되어야 한다

위험은 다음과 같은 시각으로 접근해야 한다

-          위험은 제거대상이 아니라 관리대상이다

-          모든 위험에 대응해야 하는 것은 아니다

-          위험은 상호 관련성이 있다

-          위험은 지속적으로 변화한다(지속적인 관찰이 필요하다)

위험 관리는 다음의 프로세스로 진행된다

위험관리기획 -> 위험식별 -> 정성적 위험분석 -> 정량적 위험분석 -> 위험대응기획

-> 위험 감시 및 통제

* 위험관리 기획

위험을 어떤 식으로 관리하고 그 책임과 역할은 어떠하며 절차는 어떠한지에 대한 전반적인 위험관리 계획을 수립
하는 단계이다

∥기획 회의

위험관리 계획을 위해 가능한 모든 사람이 참여하여 기획회의를 가져야 한다

PM, 선택된 팀원, 조직의 위험관리책임자, 핵심 이해관계자, 기타 필요한 사람 등이 참여시킨다

∥ 위험관리계획서

기획회의 등을 통해 위험관리 계획이 수립되었다면 이에 대한 계획서를 산출한다

위험관리계획서에는 위험관리가 어떻게 구조화되고 프로젝트 수명주기 동안 수행되는지를 기술한다

다음과 같은 항목이 정의되어 있어야 한다

-          위험관리 방법론
위험을 어떻게 관리해 나갈지 정의한다. 위험관리 접근법/도구/데이터 원천등을 정의한다

-          역할 및 책임
위험 조치의 관리, 지원에 대한 각 팀 및 사람에 대한 역할과 책임을 명시한다

-          관련 예산 수립
위험을 대처하기 위한 예산을 수립한다

-          위험관리 시점
얼마나 자주 위험관리 프로세스가 실행될 것인가를 정의한다
위험관리는 최대한 일찍 개발 그리고 주기적으로 실행되는 것이 좋다

-          위험 분류
RBS(Risk Breakdown structure) 를 개발한다
RBS는 프로젝트에 영향을 줄 수 있는 위험에 대한 분류를 체계적으로 구조화한 표이다.

-          확률/영향

∥RBS(Risk Breakdown structure)

위험은 그 성격에 따라 기술적 위험, 프로젝트 관리적 위험, 외부 위험으로 나눌 수 있다

고객의 요구사항을 기술적으로 구현하는데 발생할 수 있는 다양한 기술적 위험과 프로젝트 예측 및 통제, 계획,
의사소통 등에서 발생할 수 있는 관리적 위험은 조직 내부의 위험이라 할 수 있으며 이러한 내부 위험은 예방에
치중해야 한다. 반면 환율과 법률, 규제, 전쟁, 인플레이션 등과 같은 외부위험은 예방을 하기 힘든 위험으로써

예방보다는 재해복구 및 완화에 치중하는 위험관리가 필요하다

* 위험식별

위험을 어떤 식으로 관리할지에 대한 계획 수립 과정(위험관리기획)이 완료되었다면 이제 본격적으로 프로젝트
수명주기 동안 어떤 위험이 있을지 식별하는 활동을 하게 된다

위험식별 프로세스에서는 어떤 위험이 프로젝트에 영향을 주는지 결정하고, 위험의 특성을 문서화하는 단계이다.
위험을 식별할 때 다음과 같은 사항들을 고려해야 한다

-          위험이 발생할 확률은 얼마인가?

-          위험 발생으로 인한 영향은 어느 정도인가?

-          위험이 발생할 시기는 언제쯤인가?

-          위험이 얼마나 자주 발생할 것으로 예상되는가?

∥ 위험 식별을 위한 정보수집 기법

위험을 식별하기 위해 다음과 같은 활동이 필요하다

1) 자유연상법(Brain Storming)

위험을 식별하기 위해 자유로운 환경에서 아이디어를 모아서 분류하고 정제하여 구체화 시킨다

브레인스토밍에서 주의할 것은 자유롭게 제안하는 아이디어에 대해 비판하거나 비난하지 않아야 한다

각 구성원은 촉진자의 주도 아래 위험에 대한 다양한 시각의 아이디어를 공유하게 된다

2) 델파이기법

전문가들에게 판단을 의뢰하는 기법이다. 전문가들을 익명으로 참여하게 하여 설문 형식으로 위험에 대한 아이디어를 구하게 된다

3) 면담

경험이 많은 관리자 및 사람과 위험과 관련한 면담을 한다

프로젝트에 대한 전반적인 사항을 알려주고 의견을 듣는다

4) SWOT 분석

SWOT는 Strength(강점), Weakness(약점), Opportunities(기회), Threats(위협)의 앞자리 합성어이다

S, W는 내부 역량으로 강점과 약점을 말하며, O, T는 외부환경으로 기회와 위협을 말한다

자신의 강점과 약점을 알고 외부 요인의 파악하면 문제는 정확히 식별할 수 있다는 개념이다

흔히 말하는 지피지기(知彼知己)가 와 지천지지(知天知地)가 SWOT와 일맥상통한다고 하겠다

자신(내부)의 강점과 약점을 외부의 기회와 위협을 교차 시켜 알맞은 전략과 식별을 하는 기법이다

∥ 위험 등록부

위험이 식별되었으면 ‘위험 등록부’를 산출하도록 한다

위험 등록부는 프로젝트의 성공에 긍정적 혹은 부정적 영향을 미치는 불확실한 사건 혹은 조건(이것을 위험,Risk 라 한다)을 등록한 체계이다.

위험등록부에는 다음과 같은 것들이 정의되어야 한다

1) 식별된 위험목록

식별된 위험에 대해 기술한다

2) 잠재적 대응목록

식별된 위험의 경우 잠재적 대응방안을 기술한다

3) 위험 근본원인

식별된 위험이 발생하게 되는 근본적인 원인이나 상황을 기술한다

4) 갱신된 위험범주

위험관리기획 프로세스의 산출물인 RBS를 개선하거나 수정할 수 있다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=491

---

* 품질 보증

품질을 향상하기 위해 진행되어야 할 모든 프로세스를 이행할 것을 보증하는 과정이다

흔히 Q/A라고 하면 제품 테스트에 국한된 의미로 사용되는데, 이는 잘못된 접근방식이다

실제 품질보증이라 함은 품질향상을 위해 일어나는 전 과정을 보증하는 종합적인 활동이라
할 수 있다. 즉 제품 테스트뿐만 아니라 품질과 관련된 모든 프로세스가 보증이 되어야 한다

품질보증 활동을 위해 계획된 산출물이 적시에 도출되었는지, 기술적 성과 지표는 어떠한지 등이

정의된 ‘작업성과정보’와 진행 중 변경사항을 정의한 ‘승인된 변경 요청’, 품질통제 프로세스를 거쳐

산출된 ‘품질통제측정치’ 등의 기준자료가 투입되어야 한다

∥ 품질 감사

프로젝트의 수행하는 과정들이 조직, 정책, 프로세스, 절차 등과 일치하는지 검토하는 행위이다

품질감사는 품질검사와는 다른 개념이다

품질검사는 결과가 요구사항에 적합한지를 판정하기 위해 이루어지는 측정 및 조사, 시험행위인 반면

품질감사는 과정이 요구사항에 적합한지를 검토하는 행위이다

품질감사를 통해 프로젝트에 사용중인 정책, 프로세스, 절차 중 비효율적이거나 비효과적인 부분을 식별하여 조정하는 것이 주 목표이다

다음의 기준들이 품질감사를 통해 보증되는 것들의 예시이다

-          계획된 프로젝트 품질 수준이 달성될 것을 보증

-          제품이 안전하고 사용에 적합할 것을 보증

-          모든 관계 법령과 규제사항을 준수하고 있음을 보증

-          필요 시 적절한 교정조치가 수행되고 있음을 보증

-          개선 기회를 잘 찾아내고 있음을 보증

품질감사는 프로세스를 보증하는 과정이기 때문에 ‘프로세스 분석’이 무엇보다 중요하다

* 품질 통제

품질표준을 준수하는지 판정하기 위해 세부적인 프로젝트 결과들을 감시하고 식별하여 교정조치를 수행하는 과정이다. 앞서 ‘품질보증’이 프로세스에 대한 품질보증 활동이라면 ‘품질통제’는 결과에 대한 품질통제 활동을 말한다

∥ 인과관계도(Case and Effect Diagram)

다양한 요인이 잠재적 문제/결과와 어떻게 연관되는지 보여주는 관계도 이다

원인과 결과를 연계시키기 위한 기법으로 모양이 물고기 뼈와 유사하다 하여 어골도(漁骨圖)라고도 한다. 문제의 결과가 어떤 요인에 의해 야기되는지를 기술하여 문제를 파악하고 해결책을 도출하는 기법으로 problem box에 prime arrow 들을 그려나가며 기술한다. 다음은 예시이다

∥ 통제도

시간의 흐름에 따라 프로세스가 어떻게 동작하였는지를 도해하는 기법이다

프로세스가 In Control(통제된 상태) 인지 Out of Control(통제를 벗어난 상태)인지를 판단하기

위해 사용된다. 통제도의 목적은 프로세스의 안정성을 판단하기 위함이다

∥ 흐름도

이미 발생된 문제가 어떻게 발생하였는지 분석하기 위해 사건의 흐름을 기술하는 기법이다

각 항목들이 어떤 식으로 연관되어 문제가 발생했는지 식별한다

흐름도를 작성하면 어떤 문제가 어디서 발생할지 예상하고 대응책을 준비하는데 도움을 준다

∥ 파레토 차트

히스토그램의 일종으로 문제의 원인이 유형, 종류별로 얼마나 많은 결함이 발생했는지 발생 빈도 순으로 보여주는 차트이다. 이 기법에서 순위는 교정 활동을 위한 지침으로 사용되며 가장 빈도가 높은 문제 유형들에 대해 가장 먼저 교정 활동을 펼쳐야 한다

파레토 법칙(80/20 원칙)에 근간을 두는 기법이다

∥ 런차트

그래프에 데이터를 점선으로 표시하고 선으로 연결한 꺽은 선 그래프로 시간의 흐름에 따른 패턴과 추세를 파악할 수 있는 기법이다. 통제도와 비슷하지만 한계선이 없으며 추이를 파악하기에 좋은 기법이다

∥ 산포도

종속변수와 독립변수를 도표에 그려 두 변수간의 상관관계 패턴을 보여준다

데이터가 대각선에 가깝게 분포할수록 두 변수간에는 밀접한 관계가 있다고 해석된다

품질통제 활등을 거쳐 ‘품질통제측정치’를 도출하고 이 자료는 품질보증 프로세스로 피드백되어

프로젝트 수행 조직의 품질 표준과 프로세스를 분석하는 용도로 사용하게 된다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=490

---

품질 관리

프로젝트의 3대 제약사항인 범위, 시간, 원가를 만족하면 품질이 보장된다고 하였다

즉 고객의 요구한 범위를 제 시간에 정해진 비용으로 수행을 완료했다면 품질이 보장되는 것이다

중요한 것은 품질관리가 제품의 결과에 대해서만 통제하는 활동이 아니라는 것이다

제품의 결과를 테스트하는 것은 물론이고 품질 요건을 충족하는 데 필요한 모든 프로세스가 제대로 이루어지도록
하는 것도 품질관리의 중요한 항목이다

즉 품질관리의 대상은 ‘제품의 품질 + 절차 및 관리상의 품질’을 모두 포함하는 것이다

품질관리는 다음과 같은 프로세스로 이루어 진다

품질 기획 -> 품질 보증 수행 -> 품질 통제 수행

* 품질 기획

품질표준을 정의하고 이를 어떻게 달성할 것인가에 대한 계획을 세우는 단계이다

∥품질 정책

품질표준을 정의하기 위해서는 조직(회사)의 품질정책 및 지침을 따라야 참고해야 한다

만일 조직에 미리 정의된 품질정책이 없거나 다수의 조직이 모여 프로젝트를 진행해야 할 경우

프로젝트 관리 팀에서 품질정책을 마련해야 한다. 또한 프로젝트 관리 팀은 프로젝트의 모든

이해관계자들에게 품질정책을 주지시켜야 한다

∥범위 기술서 참조

범위관리에서 산출한 범위 기술서에는 프로젝트의 주요산출물과 요구사항, 목표, 인수 조건 등이 기술되어 있으므로 품질기획단계에서는 이 문서를 반드시 참조해야 한다

∥ 비용/편익 분석(비용/효익 분석)

품질기획 시 반드시 비용과 편익간의 상관관계(tradeoff)를 고려해야 한다

품질요구사항을 만족시킴으로써 얻을 수 있는 주요 편익은 재 작업을 적게 함으로써 생산성이 올라가

원가가 낮아짐으로써 종국에는 이해관계자들의 만족도가 올라가는 것이다

∥ Gold Plating

품질은 요구사항을 만족했는지에 대한 척도이지 요구사항을 뛰어넘는 만족도는 아니다

PMI에서는 이를 명확히 구분하고 있다

예를 들어 고객이 A를 요구했는데 A++ 를 구현했다고 해서 절대로 좋은 것이 아니라는 것이다

이는 당초 계호기에 비해 고객의 기대 수준을 높이는 불필요한 행위이며 이러한 활동이 대부분은

원래 요구했던 수준도 달성하지 못하는 결과를 초래할 수 있기 때문이다

∥ 실험 설계 법

품질을 효과적으로 달성하는 방법을 찾는 통계적 기법이다

어떤 요인이 결과에 영향을 미치는지 알기 위해 여러 변수를 조합해서 실험을 하여 각 변수의 영향력을 분석, 최적의 값을 도출하는 기법이다.

제품 또는 프로세스를 최적화할 때 사용하는 기법으로 경제성 측면에서 볼 때 가장 효율적인 품질 당성 방법을 찾는 개념이다

잘 설계된 실험은 상대적으로 제한된 경우의 수로부터 최적의 해법을 결정할 수 있게 해 준다

∥ 품질 비용(COQ, Cost of quality)

품질 만족도를 달성하기 위한 모든 노력 및 활동의 총 비용을 말한다

품질비용에는 크게 순응비용(Conformance cost)과 비 순응비용(Nonconformance cost)으로 나눈다

순응비용은 예방비용(Prevention cost)과 평가비용(Appraisal cost)으로 나누어 지며

비 순응비용은 실패비용(Failure cost)과 저 품질비용(Cost of Poor Quality)으로 나누어진다

또한 실패비용은 내부실패비용(Internal failure cost)과 외부실패비용(External failure cost)으로 나눌 수 있다

참고로 A/S 직원들의 교육은 어느 비용에 해당할까?

교육이라는 느낌에서 예방비용 같지만 실제로는 외부실패비용에 해당한다

∥ 품질기획 산출물

품질기획 과정을 거쳐 다음의 산출물이 도출될 수 있다

1) 품질관리계획

프로젝트 관리 팀이 품질정책을 어떻게 구현할 것인지 기술한 것

프로젝트 전체 관리계획의 일부가 된다

2) 품질 척도(지표)

품질을 통제할 때 어떤 것을 어떻게 측정할 것인가를 매우 구체적인 수준으로 기술한 운영상 정의

품질 척도는 품질기획 이후 프로세스인 품질 보증과 품질 통제에서 사용된다

3) 품질 점검 목록

일종의 품질과 관련한 체크리스트라 할 수 있다

계획된 일련의 단계들이 항목별로 수행되었음을 검증하는데 사용되는 구조적 도구이다

~ 하라, ~을 하였는가? 의 형태를 띌 수 있다

품질통제 시 점검결과를 기록하기 위해 사용된다

4) 프로세스 개선 계획

낭비적이고 비 부가가치적인 활동 식별을 촉진하여 고객가치를 증대시키는 일련의 프로세스를 상세히 기술한다. 품질 관리활동을 위한 상세한 프로세스 흐름도(flowchart), 척도, 목표치, 경계등을 기술한다

5) 품질 기준선

프로젝트의 품질목표를 기록한 기준선

품질성과를 측정하고 보고하기 위한 성과 측정 기준선 중 하나이다

* 기타 개념

∥ 품질과 관련한 책임

고객>>

품질에 대한 기준을 정하는 것은 PM이 아니라 고객이다

프로젝트 이해관계자 중 품질 기능에 있어 가장 중요한 역할을 하는 주체 역시 고객이다

고객은 수용가능 한 품질수준에 대한 요구사항을 설정할 책임이 있다

PM>>

프로젝트 최종 목표 제품의 품질에 대하여 궁극적인 책임을 진다

최고 경영자(경영진) >>

최고 경영자는 조직 전체의 품질에 대하여 궁극적인 책임을 진다

특히 조직의 품질 정책 및 프로세스의 혁신은 최고 경영자로부터 출발해야 한다

∥ PDCA Cycle

품질관리 전문가인 W. Edwards Deming이 Dr. Shewhart로부터 영향을 받아

Plan/Do/Check/Act Cycle을 그의 사무직에 적용하였다

계획, 실행, 검사, 통제의 싸이클(Cycle)을 계속 진행하면서 품질은 지속적으로 개선된다는 의미이다

즉 품질을 위한 프로세스의 중요성을 강조한 개념이라 할 수 있다

지속적인 품질 보증을 위하여 프로세스는 반드시 통계적인 분석과 통제 하에 있어야 하며,

품질관리의 궁극적인 목표는 목표치를 할당하는 것이 아니라 점진적으로 프로세스를 개선해 나가는 것이라고 주장하였다

또한 작업 지식 미숙, 작업자 실수, 집중력 저하 등으로 인한 품질저하는 작업자가 스스로 해결해야 하지만 낮은 품질의 원자재 문제, 제품설계 문제, 부적절한 작업환경 등은 경영진에 의해 해결되어야 하는 과제라고 하였다

∥우연원인과 특별원인

저 품질의 원인을 다음과 같이 우연원인과 특별원인으로 나눌 수 있다

1) 특별원인(Special Cause/Assignable Cause)

저 품질의 원인이 명확한 것. 즉 이유(Cause)가 있는 원인이라고 한다

주로 장비 결함, 기계 오작동, 종업원의 실수 또는 미숙함을 들 수 있다

특별원인을 해결하기 위해서는 현재 프로세스에 대한 교정을 가하여야 한다

2) 우연원인(Random Cause/Common Cause)

원인을 통제할 수 없는 것. 명확이 문제의 원인을 단정 지을 수 없어 불가피한 원인이라고 한다

주로 작업 환경 차이, 작업자의 숙련도 차이, 정상 공정상 편차, 원자재나 생산 설비의 차이를 들 수 있다. 우연원인을 해결하기 위해서는 상당한 수준의 프로세스 재구성 없이는 제거할 수 없다

∥ 등급(Grade)과 품질(Quality)

제품의 등급과 품질은 완전히 다른 의미이다

등급은 정해진 수준을 의미한다. 예를 들어 자동차 배기량이 1000cc. 2000cc 구분하는 것이 등급이다

여기서 2000cc 보다 1000cc가 낮다고 하여 문제되진 않는다. 단지 등급일 뿐이다

그러나 요구된 등급인 1000cc 제품을 제대로 만들지 못했다면 품질에 문제가 있는 것이다

즉 Low grade는 문제가 되지 않지만 Low quality는 항상 문제가 된다

다시 말하지만, 등급은 “품질 요구사항의 수준”이고 품질은 “품질 요구사항에 대한 적합성의 수준”이다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=487

---

원가 통제

원가산정과 예산수립 프로세스를 거쳐 계획된 예산과 실제 프로젝트 진행 중 사용된 예산의 차이를

파악하고 그 원인을 분석하고 예산 변경 등을 수행하는 과정이다

계획 대비 실제 원가차이를 파악하기 위해 ‘성과측정분석’을 수행한다

성과측정분석을 통해 ‘원가차이’ 와 ‘일정차이’를 식별할 수 있다

PV(계획가치, Planed Value)

계획가치란 수행하기로 예정된 물리적 작업 및 이의 기대가치라 한다

계획된 비용에 대비한 계획작업진척율을 계산한 값으로 다음과 같이 계산된다

PV = 계획된 비용 * 계획작업진척률

만일 계약금액이 100만원인 계약에, 계약 진척률이 80% 진행되었다면 이 시점의 PV = 80만원이 된다

이전에는 BCWS(Budgeted Cost of Work Scheduled)라고도 불렸다.

EV(실현가치, Earned Value)

실현가치란 실제로 성취된 물리적 작업 및 이의 기대가치라 한다

계획된 비용에 대비한 실제작업진척율을 계산한 값으로 다음과 같이 계산된다

EV = 계획된 비용 * 실제작업진척률

이전에는 BCWP(Budgeted Cost of Work Performed)라 불렸다

EV는 ‘기성고’ 라고도 하는데 이는 일반적으로 프로젝트 기간 중에 기간별 대가 지급 금액 계산의

기준이 되는 중요한 지표이다.

EV는 앞서 식과 같이 실제작업이 진행된 비율에 따라 인정할 수도 있지만 ‘착수시/완료시’

각 몇 % 인정, 이라는 형태로 조건을 달 수도 있다

예를 들어, 20/80 기준을 사용한다면, 이는 착수할 때 20%를 인정해 주고, 완료하면 나머지 80%를 인정한다는 것이다. 만일 대가 비용이 100만원인 작업에 20/80 기준을 적용하고 있다고 가정하면 실제 작업 진척률이 80%라고 하더라도 이 시점에 EV는 (아직 작업을 완수하지 않았기 때문에 20/80 기준에 따라 20%만 인정해 주므로) 20만원이 되는 것이다

AC(실제원가, Actual Cost)

실제원가는 말 그대로 수행하고 있는 작업에 실제로 사용된 비용을 말한다

이 세 가지(PV, EV, AC) 값으로 원가차이 및 일정 차이를 측정할 수 있다

* 차이 분석(Variance Analysis)

CV(원가차이, Cost Variance)

현재 시점에 계획 대비 실제 원가가 얼마나 차이가 발생하고 있는지 계산하는 방법이다

CV = EV ? AC

예산상의 원가와 실제원가의 차이로써 이 값은 다음과 같이 해석된다

1) 0 < CV: 긍정적 차이, 비용이 계획된 범위 안에서 잘 관리되고 있다

2) CV = 0: 계획상 차질이 없다

3) CV < 0: 부정적 차이, 비용이 계획된 범위를 벗어났다. 교정초치가 필요할 수 있다

SV(일정차이, Schedule Variance)

EV와 PV를 이용하면 일정 차이도 예측할 수 있는데 다음의 공식으로 산출한다

SV = EV - PV

실제 수행 작업과 계획한 작업의 가치 차이로써 이 값은 다음과 같이 해석된다

1) 0 < SV: 긍정적 차이

2) SV = 0: 계획상 차질이 없다

3) SV < 0: 부정적 차이, 일정에 위험이 있을 수 있다

* 비율 분석(Ratio Analysis)

CV 와 SV는 원가 및 일정 차이를 분석하는 기법이며 이와 유사하게 비율을 분석하는 지표로써

CPI(Cost Performance Index) 와 SPI(Schedule Performance Index)가 있다

CPI = EV / AC

SPI = EV / PV

이며 CV 와 SV가 0 을 기준으로 차이를 파악했다면 CPI와 SPI는 1이 기준이 된다(나눗셈이니깐……)

CPI만 보자.

1 < CPI: 긍정적 차이

CPI = 1: 계획차질 없음

CPI < 1: 부정적 차이

이제 성과를 분석하는 예를 살펴보자

문제>

공사가 착공한 지 4주가 지난 지금, 각 작업의 계약서 상의 금액과 공정 진척률은 다음의 표와 같다

현재 시점에서 청구해야 하는 대가 금액은?

1) 실제 완성율 기준으로 SV와 CV를 계산하라

2) 20/80 기준으로 SV와 CV를 계산하라

답>>

1) 실제 완성율 기준으로 SV와 CV를 계산하라

SV와 CV를 계산하기 위해서 PV, EV, AC를 먼저 계산해야 한다

PV = 100 + 200 + 100 = 400만원

EV = 100 + 200 + 200 + 201 = 701만원

AC = 120 + 160 + 80 + 200 = 560만원

CV = EV - AC = 701 - 560 = 141만원

SV = EV - PV = 701 - 400 = 301만원

2) 20/80 기준으로 SV와 CV를 계산하라

20/80 기준을 적용하므로 EV 계산 시 착수시 20% 인정, 완료 시 80% 인정이라는 뜻이므로 EV는 다음과 같다

EV = 100 + 200 + 80 + 60 = 440만원

CV = EV - AC = 440 - 560 = -120만원

SV = EV - PV = 440 - 400 = 40만원

* 완료 시점 기준 예측 (EAC, Estimates at completion)

완료시점기준예측치는 원가통제 프로세스의 주요 산출물이다

지금까지 사용된 실제 원가인 AC(Actual Cost)를 근거로 프로젝트 완료 시 소요될 원가를 예측할 수 있게 된다. 이렇게 계산된 EAC는 적절한 이해관계자들에게 보고되어야 하며 프로젝트 상황에 따라 다음과 같은 공식이 사용된다

1) EAC = AC + (BAC ? EV)

프로젝트 초기 단계에 많이 쓰이는 ‘완료시점예측’ 방법으로써

현재의 차이가 전형적이지 않아 향후에는 이와 같은 상황이 발생하지 않을 것 같은 경우 사용됨

참고) BAC(Budget at Completion)는 최초 산정된 예산 금액으로 BAC ? EV 라 함은 최초 예산
금액에서 중간에 대가 지급을 하고 난 이후 금액이 된다)

2) EAC = AC + (BAC ? EV) / CPI = BAC / CPI

현재의 차이가 미래에도 지속적으로 발생할 수 있는 상황에서 사용됨

3) EAC = AC + ETC

ETC(Estimate to Completion)는 프로젝트 완료까지 소요될 추가 예산에 대한 새로운 산정치이다

현재의 차이가 근본적으로 잘못 산출되었거나 프로젝트 조건들이 변경되어 향후에는 더 이상 관련이 없을 경우 사용됨.

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=486

---

원가는 일정과 범위와 더불어 프로젝트의 주요한 3대 제약조건이 된다

원가관리는 일정관리에서 산출된 개별 활동들에 소요되는 원가산정과 이를 집계한 예산 수립,

원가 차이를 분석하고 통제 및 예산 변경을 수행하는 원가통제 프로세스로 이루어진다

* 원가관리 프로세스

원가 산정 -> 원가 예산수립 -> 원가 통제