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

이 글은 제가 과거에 운영했던 사이트인 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대 제약조건이 된다

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

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

* 원가관리 프로세스

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

* 원가 산정

프로젝트를 수행하기 위해 분할된 활동(Activity)들을 완료하는 데 필요한 원가를 추정하여 근사값(산정치)를 산출하는 과정이다. 이러한 원가 산정치는 보통 화폐 단위로 제시되며 경우에 따라서는 일일 인건비와 함께 예상 인원 및 일수로 산정하기도 한다

원가산정을 위한 기법으로는 다음과 같은 것들이 있다

1) 유사 산정(Analogous estimating)

이전의 유사한 프로젝트에서 소요된 원가를 현재 프로젝트 원가산정의 근간으로 이용하는 기법이다

경험을 근간으로 원가를 산정하기 때문에 ‘전문가 판단’의 한 가지 형태이며 유추산정이라고도 한다

또한 큰 그림을 기반으로 세부 항목들의 원가를 산정하게 되므로 하향식 산정(Top-down estimating)이라고도 한다.

많은 정보가 구체화 되기 이전인 프로젝트 초기 단계에 많이 사용되는 기법이며

이전에 아주 유사한 경험이 있거나 전문적 지식을 보유하였을 경우 매우 신뢰할 만한 산정치를 도출할 수 있지만 다른 기법들에 비해 정확성을 덜 할 수 있다

2) 상향식 산정(Bottom-up estimating)

유사 산정(=하향식 산정)과 반대되는 개념이다

수행해야 할 각 세부 활동들에 대한 원가를 개별적으로 산정한 후 이를 합산하여 산정하는 기법이다

개별 활동에 대한 원가를 일일이 산정하기 때문에 다른 기법에 비해 정확도가 가장 높다고 할 수 있다. 물론 산정 기준이 되는 개별 활동들의 정확성이 사전에 요구된다

3) 모수 산정(Parametric estimating)

프로젝트 원가를 산정하기 위해 모수(수학적 모형 내에 있는 프로젝트 특성)를 사용하는 기법이다

특히 모수가 계량화 될 수 있을 때 매우 신뢰할만한데 간단한 예를 들어 집 한평(방미터) 인테리어에

100이 들었다면 10평이면 1000이 든다고 추정할 수 있다

4) 원가비율 산정

원가를 산정하는 사람은 시간당 임금, 평방 미터당 원자재 원가 등의 원가 비율의 단위를 알고 있어야 한다. 업체 견적의 경우 비율을 얻는 방법 중 하나이다

통상 위의 산정 기법 중 정확도 순은 다음과 같다

상향식 산정 > 모수 산정 > 하향식 산정

원가산정 과정을 거쳐 ‘활동원가산정치’ 라는 산출물을 도출해야 한다

활동원가산정치에는 원가에 대한 정량적 평가치, 인건비, 재료비, 소모품비, 물가상승충당금 등이 정의되어야 한다. 또한 돌발 상황을 대비 할 수 있는 예비비(Reserve)도 고려되어야 한다

* 원가 예산수립

앞서 개별 활동들에 대한 원가산정을 모두 모아 집계하여 원가기준선을 정의하는 과정이다

즉 예산은 활동별 추정원가의 합계이다

종합적인 예산수립 시 돌발상황과 같은 예측하기 힘든 이슈에 사용되어질 비용도 같이 고려되어야 하는데 이러한 예비비는 다음과 같은 두 가지 종류가 있다

1) 돌발상황충당금(Contingency Allowance)

‘원가산정’ 프로세스에서 정의하도록 한다. 이 비용에 대한 재량권은 PM이 가지고 있다

이 비용은 원가기준선에 포함되며 통상 조직 정책에 따라 금액이 책정된다

2) 관리예비비(Management Reserve)

‘원가 예산수립’ 프로세스에서 정의하도록 한다. 이 비용에 대한 재량권은 고위 경영진에게 있다

이 비용은 원가기준선에 포함되지 않으며 통상 5% 정도의 금액이 책정된다

예산수립 과정을 거쳐 ‘원가기준선’ 이라는 산출물이 도출해야 한다

원가기준선은 원가에 대한 성과를 측정하고 감시하는데 사용되는 단계별 예산을 기록하며

기간에 따른 누적 비용을 그리는데 보통 S 곡선 형태를 띄게 된다

* 참고
1. 원가란
특정 목적을 달성하기 위해 희생해야 하는 자원의 화폐적 가치

2. 원가의 유형
1) 원가 할당 방법에 따른 분류
- 직접비: 원가 발생 이유를 직접적으로 추적(tracing)할 수 있는 원가
             ex) 급여, 출장비, 인센티브 등
- 간접비: 원가 발생 이유를 직접적으로 추적할 수 없는 원가
             ex) 관리비(전기세, 세금 등)

2) 조업도 변화에 따른 원가 형태
- 고정비: 조업도 수준과 무관하게 원가가 일정하게 발생하는 원가
             ex) 프로젝트 착수 비용 등
- 변동비: 조업도에 따라 비례하여 발생하는 원가
             ex) 재료비, 인건비 등

3. 기회원가란
특정 대안을 선택했기 때문에 포기한 다른 대안을 통해 얻을 수 있었던 효익

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

---

프로젝트의 범위는 일정과 비용에 직접적인 영향을 주는 근간이 된다
흔히 말하는 스펙(Spec)인데, 무엇을(What?) 만들 것인가에 대한 정의라 할 수 있다

범위는 제품범위(Product Scope)와 프로젝트범위(Project Scope)로 나눌 수 있는데,
제품범위는 최종 결과물에 대한 스펙 정의이며
프로젝트 범위는 최종 결과물은 물론 중간 산출물, 중간에 수행되어야 하는 일등을 모두 포함한 개념이다

PM(Project Manager)은 제품범위를 만족시키는 것은 물론 프로젝트 범위도 만족시켜야 한다

* 범위관리 프로세스
범위기획 -> 범위정의 -> WBS 생성 -> 범위검증 -> 범위통제

범위기획에서는 프로젝트의 범위를 식별하고 범위에 대한 관리,통제를 위한 기준 및 절차를 정의하는 과정이다

범위정의에서는 이해관계자들을 식별하고 상세한 프로젝트 범위 명세서를 만드는 과정이다
여기서 재밌는 것은 범위정의 단계에서 이해관계자를 식별한다는 것이다
인적자원관리나 의사소통관리에서나 등장할 법한 이해관계자 식별 활동이 왜 범위정의에 포함되어 있는 것일까?

이는 바로, 이해 관계자들의 기대치를 제품 및 과정에 반영하고자 하는 이유에서다
즉 이해관계자를 분석해서 다양한 이들의 영향력과 관심사를 식별하고, 그들의 요구, 희망사항 및 기대치를
관리함으로써 프로젝트를 보다 효과적으로 수행하고자 하는 의미가 담겨져 있다

물론 범위정의 단계이 핵심 산출물은 '범위 명세서' 임은 두말 할 것이 없다
범위명세서에는 프로젝트 목표, 제품 범위, 프로젝트 요구사항, 인도물, 인수 기준, 위험, 일정 이정표, 자금 한계,
형상 관리 요구사항, 사양서 등을 구체적으로 기술하도록 한다

* WBS (Work Breakdown Structure)
작업분류체계라 해석되는 WBS는 범위관리에 핵심 산출물이라 할 수 있다
프로젝트의 범위와 인도물, 작업을 더 작고 관리하기 쉬운 구성요소로 분할한 것이다
WBS는 일정과 비용의 기준선이 되며 의사소통의 도구로써 활용된다

다음과 같은 과정으로 범위는 구체화 된다
요구사항 -> 예비 프로젝트 범위 명세서 -> 프로젝트 범위 명세서 -> WBS

중요한 것은 WBS는 관리가능한 수준으로 분할 한다는 것이다
WBS를 어느 정도 까지 분할, 즉 상세화 해야 하는 것일까?

분할을 너무 과도하게 하면 통제는 용이한 반면 관리 비용이 증가하며
분할을 약하게 하면 관리 비용은 감소하지만 통제에 대한 어려움이 있을 수 있다

WBS의 분할 원칙에 대한 기준을 참고하도록 하자
1) 40 시간의 원칙
주 5일, 일일 8시간 근무 환경에서 40시간은 작업 소요 기간이 1주가 된다는 의미이다
즉 WBS 의 최소 크기를 1주 단위로 정하는 것을 말한다

2) 80 시간의 원칙
작업 소요 기간이 2주가 된다는 의미이다
WBS의 최대 크기를 2주로 제한하는 것이 좋다는 말이다


WBS 에는 프로젝트 범위의 모든 것이 기술되어져야 한다. WBS에 없는 것은 프로젝트 범위 밖에 있는 것이다

다음은 WBS의 3가지 구성요소이다
Code of Account, WBS 사전, Work Package

Work Package
WBS의 더 분할한 산출물이다, WBS의 최하위 수준의 작업 요소를 정의한 것이다

Code of Account
WBS의 고유 식별 번호로써, Work Package를 고유하게 식별하는 식별자이다
분류된 위치와 레벨(깊이)를 알 수 있게 하는 분류 체계이다

WBS 사전
수행해야 하는 작업의 명칭, 내용 및 시기 등을 기술한 문서이다
즉 업무, 일정, 계획, 수립 정보를 포함하는 작업요소에 대해 설명된 문서이다


* 범위 검증
말 그대로 범위대로 작업이 되었는지 검증하는 단계이다
이해관계자들로부터 프로젝트 범위를 공식적으로 인정받는 중요한 과정이다
만일 프로젝트가 완료되기 전에 중단되더라도 반드시 해당 단계의 완료 수준과 범위를 문서화 해야 한다

범위검증은 품질 통제와 구별된다
품질 통제가 Q/A 담당자에 의해 품질 기준선에 만족 했는지 심사하는 과정이라고 한다면
범위검증은 고객이 제품 인수를 위해 검증하는 단계라 할 수 있다

만일 품질검사는 만족했는데 고객이 만족하지 못한다는 것은 무슨 뜻이 될까?
바로 요구사항 분석이 실패했다는 것이다
즉 제품은 범위명세 대로 잘 만들었고 품질도 그러한 기준에서 통과 했지만 최종 고객이 만족하지 않는 것은
최초 범위 명세 부터 잘못되었다는 의미가 된다

* 범위 통제
범위를 중간에 변경하는 것이 매우 크리티컬한 것이 된다
범위 통제는 일정 통제, 원가 통제, 품질 통제와 완전하게 통합되어 같이 관리되어져야 한다
그리고 범위 변경은 반드시 변경 통제 시스템를 통해 정형적이고 절차적인 과정을 통해 수행되어져야 한다

범위 변경으로 인해 발생하는 여러 가지 사항들을 면밀히 검토해야 하며 수반되는 일정 및 원가의 변경을
같이 고려해야 하며 적절한 승인절차를 거쳐서 이루어 져야 한다

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

---

앞서 프로젝트를 수행하는 주체인 사람을 관리하는 인적자원관리에 대해 알아 보았다

프로젝트는 사람에 의해 요구되어지고 사람에 의해 수행되어지므로 사람간 커뮤니케이션이 무엇보다
중요하다 할 수 있겠다

PMI에서 정의한 9대 지식영역 중 '의사소통관리'에서 이와같은 커뮤니케이션의 정의, 스킬, 방법론을 다룬다

의사소통관리란?
프로젝트 이해관계자들의 정보 요구사항을 파악하여 필요한 정보를 배포하고, 프로젝트의 성과보고를 수집 및 배포
하기 위한 공식/비공식 의사소통 방법을 이해하고, 모든 이해관계자의 의사소통 요구사항/쟁점사항을 분석하여
효과적으로 관리하는 것

PM(Project Manager)에게 요구되는 많은 능력 중 가장 중요한 능력은 '통합'이며
이러한 통합을 실현하기 위해서 가장 많은 시간을 할애해야 하는 것이 바로 의사소통이다
따라서 PM은 프로젝트 수행 중 대부분의 시간을 의사소통과 관련된 활동에 투자해야 한다

의사소통 세부 프로세스
의사소통 기획 -> 정보배포 -> 성과보고, 이해관계자 관리


* 의사소통 기획
의사소통 기획 단계에서는
누가 어떤 정보를 언제 필요로 하며, 어떤 방식으로 제공할지를 정의하는 단계이다
즉 이해관계자 및 정보, 의사소통 방식등을 식별, 정의하는 단계라 할 수 있다

의사소통 기획과정을 통해 다음과 같은 것들이 정의되어야 한다
- 이해관계자 목록
- 이해관계자들의 정보 요구 사항
  필요한 정보, 제공 형식, 제공 빈도 및 주기, 적시성과 정확성 요건, 전달 방법 등
- 공통 용어집
  

* 정보배포
프로젝트 실행 중에는 다양한 정보들이 발생한다. 이러한 정보를 필요한 사람들에게 시기 적절하게 제공되어야 한다
정보배포는 불규칙적으로 발생하며 비공식적 성격을 띠며 적시성이 강조된다
적시성이라 함은 이슈 발생 시 바로 배포 하는 것이라 할 수 있다
공식적 보고와 같이 규정된 포맷으로 정보를 가공하여 일목요연하게 보고하는 것보다는 이슈 발생 시 적시에
보고, 배포가 더 중요하다는 의미이다

정보 배포 시 정보 전달자와 수신자는 다음과 같은 스킬이 요구된다

정보 전달자 >>
정보가 명확하고 모호하지 않아야 하며 수신자가 이를 올바로 수신하고 적절히 이해했다는 것을 확증해야 할
책임이 있다

수신자 >>
정보를 잘 수신했으며 올바로 이해했다는 것을 확인시켜 줄 책임이 있다

여기서 중요한 것은 전달자 및 수신자는 정보를 적절히 이해했다는 것을 서로에게 확증해 줘야 하는 것이다
단, 이 말이 정보를 동의했다는 것과는 다름에 유념해야 한다
정보를 받아서 무슨 정보인지 알겠다는 뜻과 이 정보에 동의한다는 것은 완전히 다른 개념인 것이다


* 성과보고
현황을 보고 하고 프로젝트 진척도를 측정 및 추정하여 성과정보를 수집하고 이를 적절한 사람에게 보고하도록 한다
성과보고는 정보배포와는 달리 규칙적이고 정형화된 활동이라 할 수 있다
정보배포가 비공식적이고 불규칙적인 보고라 한다면 성과보고는 규칙적이고 공식적인 보고 절차이다
따라서 정보배포가 적시성이 강조된다면 성과보고는 정확성이 강조되는 활동이다 

성과보고서의 종류>>
1) 현황 보고서
프로젝트의 현재 상태를 기술함

2) 진척도 보고서
이미 완수한 성과를 중심으로 기술함

3) 추세 보고서
프로젝트 결과를 기간별로 조사하여 성과가 진보되고 있는지 퇴보되고 있는지를 중심으로 기술함

4) 추정 보고서
미래 예측을 중심으로 기술함

5) 차이 보고서
계획 대비 실적을 중심으로 기술함

6) 기성고 보고서
범위,원가,일정을 통합하여 프로젝트 성과를 기술함
PV(계획가치), EV(기성고), AC(실제원가)의 척도를 사용한다

* 이해관계자 관리
이해관계자라 함은 프로젝트에 관련된 주요한 모든 사람을 일컫는다
이러한 이해관계자를 관리함으로써 이해관계자들의 정보 요구사항을 만족시키고 쟁점을 해결함으로써
프로젝트를 원활히 수행하도록 한다
이해관계자 관리는 PM의 핵심 책임 영역이라 할 수 있겠다

보통 의사소통을 위해 여러가지 수단이 사용된다
예컨데, 이메일, 전화, 편지, 팩스, 회의, 화상회의 등 방법은 다양한다
단, 이해관계자들과 소통하고 이슈를 해결하는데 가장 효과적은 의사소통 방법은 바로
Face To Face 즉 면대면 이다
얼굴을 보고 직접 대면하여 소통하는 것이 가장 효과적이다

지금까지 의사소통 프로세스를 대략 살펴 보았다
의사소통관리가 이렇게 단순히 개념을 열거하는 것으로 학습이 모두 되지는 않을 것이다
원활한 소통을 위해 면밀히 검토하고 부지런히 관리하는 경험을 쌓고 성공담/실패담을 기록해 나감으로써
보다 완벽한 의사소통을 할 수 있을 것이다

다음은 의사소통 관리를 위해 필요한 약간의(?) 개념적 정보이다

* 직급에 따른 정보 욕구(needs)
프로젝트와 연관된 다양한 이해관계자들이 모두 동일한 형태의 정보를 요구하지는 않는다
같은 정보라 할 지라도 정보 수신자에 따라 다른 형태로 제공되어져야 효과적이다
직급에 따라서도 요구되는 정보 성격이 다르다고 할 수 있다

상위 직급의 needs>>
- 외부 정보 및 요약된 정보를 필요로 함
- 지식과 지혜 지향적인 정보를 더욱 요구함

하위 직급의 needs>>
- 내부 정보 및 상세 정보를 필요로 함
- 데이터와 정보 지향적인 정보를 더욱 요구함

* 의사소통의 3 요소
두말해야 잔소리겠지만, 의사소통의 핵심 3요소는 송신자,수신자,메시지 이다
말 하는 사람, 듣는 사람, 내용이 있어야 의사소통임은 당연한 것이다

여기에 덧붙여 의사소통의 4요소라 함은,
송신자,수신자,메시지에 더불어 매체(의사소통 수단)이다

* 의사소통 채널
통상 진행중인 프로젝트에 사람이 더 투입되면 일정을 더 앞당길 수 있다고 생각한다
일정 관리 기법 중, Crashing 기법 역시 자원을 더 투입해 프로젝트 일정을 단축하는 방법이다
그러나 중요한 것은 인원 추가 투입이 반드시 일정을 단축하지는 못한다는 것이다
이는 여러가지 이유가 있는데, 그 중 의사소통 채널 수의 증가도 그 요인으로 작용한다

의사 소통 채널 수는 다음과 같은 공식으로 계산 될 수 있다
n(n-1) / 2

여기서 n은 인원 수를 의미하며 사람이 늘어날 수록 채널 수 역시 증가하게 된다

예를 들어, 기존 4명인 팀원에 추가 인원 2명이 투입되면 의사소통 채널 수의 변화는 다음과 같다
기존 4명 : 4(4-1) / 2 = 6
추가 2명 : 6(6-1) / 2 = 15
즉 기존 채널 수 보다 무려 9개가 늘어나게 된다
의사소통 채널 수가 늘어나게 되면 소통을 위한 리소스를 더 많이 투입해야 하며
소통 오류에 대한 부담도 증가하게 됨을 유념해야 한다

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

---

사람들끼리 모여서 일을 하다 보면 갈등은 피할 수 없는 주제이다
개개인의 성향과 기질이 다른 것은 차치하고서라도 업무의 우선순위, 맡은 역할, 일정 준수 등
프로젝트를 완료하기 위한 하나하나의 과정들에서 갈등은 발생할 수 있다

이번 시간에는 이러한 갈들을 PMI에서는 어떻게 정의하고 관리하는지에 대해 알보도록 하자

프로젝트 수행 중 발생되는 많은 갈등의 원인은 일정과 업무우선순위,자원에 있다
일정을 준수하지 못하거나 일정을 오버하거나 일정 변경 없이 범위가 변경하거나 특정 리소스의 결핍으로 인한
일정 위험을 느낄때, 또한 업무에 대한 우선순위 결정등에서 갈등이 많이 발생하게 된다

프로젝트 초기에 갈등의 원인은 다음의 순위라 할 수 있다
업무우선순위 > 일정 > ...

그리고 보편적인 경우, 그리고 프로젝트가 중반 이후로 갈 수록 갈등의 원인은 다음의 순위로 바뀐다
일정 > 업무우선순위 > 자원 > ....


프로젝트 수행 중 이러한 이슈들은 각 개인들의 견해차이를 발생시키고 결국 사람간 갈등으로 번지게 될 수 있다
PMI에서는 갈등의 당사자는 갈등해결에 1차적 책임이 있으며 갈등 해결에 반드시 참여해야 한다고 말한다
PMP에서 갈등을 해결하는 순서를 다음과 같이 제시한다

갈등 당사자간 사적으로 해결 => PM의 중재 => 공식적 절차

즉 당사자간 해결이 최선이며 이것이 힘들 경우 PM이 중재할 수 있다
만일 PM의 중재에도 갈등의 해결되지 않고 프로젝트에 악영향을 미칠 수 있다면 종국에는 징계와 같은
공식적인 절차를 사용할 필요가 있는 것이다


* 갈등을 바라보는 관점의 변화
현대에 와서 갈등의 평가는 과거와는 달라 졌다

과거의 전통적인 관점에서 갈등은,
특정 문제 유발자 때문이며 갈등 자체가 나쁜것이며, 웬만하면 피하거나 억압하여 갈등이 발생하지 않도록
하는 것이 최선이라 생각했다

그러나 현대의 관점은,
갈등은 피할 수 없는 것이며 변화에 따른 자연적 현상이며 관리할 수 있으며 관리해야 하는 것 그리고
갈등이 꼭 나쁜 것만은 아니며 가끔 이익이 된다는 관점으로 변화하고 있다

* 갈등 해결의 5가지 방법
갈등을 해결하기 위해서는 일방적으로 자기 주장만 할 수 없다
때로는 타협이 필요하며 한발 물러서거나 한발 나가거나 하는 융통성이 필요하다
갈등을 해결하는 5가지 방법에 대해 알아보자

1.철수/회피 (Withdrawal)
자기 주장도 하지 않고 타협도 하지 않고 그냥 회피하는 방법이다
낮은 주장, 낮은 협력으로 다음과 같은 상황에서 이러한 회피를 사용할 만 하다
- 이슈가 사소한 것일 때
- 추가적인 정보가 필요 할 때
- 자기의 의견이 관철될 가능성이 매우 낮을 때

이 방법은 일시적으로 상황을 진정시키는 효과는 있지만 가장 피해야 할 갈등해결 방법이라 하겠다

2. 양보/수용 (Smoothing)
자기의 주장은 낮추고 타협을 중시하는 방법이다
낮은 주장, 낮은 협력으로 다음과 같은 상황에서 이러한 양보를 사용할 만 하다
- 나중을 위하여 신용을 얻고자 할 때
- 조화와 안정이 매우 중요할 때(분위기가 우선일  때)
- 이슈가 갈등 상대방에게 보다 중요한 사안일 때

이 방법은 분위기를 중시하고 좋은 인상을 줄 수는 있지만 갈등의 근본적인 해결 방법은 아니라 하겠다

3. 타협 (Compromising)
자기의 주장도 적당히 하고 타협점도 찾는 방법이다
중간 주장, 중간 협력으로 다음과 같은 상황에서 이러한 타협을 사용할 만 하다
- 목표는 중요하나 더 이상 설득이 힘들 때
- 비슷한 파워를 가진 집단들 끼리의 갈등일 때
- 양측이 어느정도 만족할 수 있는 합의점을 도출할 때

이 방법은 양 당사자간 타협점을 찾는 좋은 방법이긴 하지만 만족도는 다소 떨어질 수 있다 하겠다

4. 강요 (Forcing)
자기의 주장을 강하게 고집하고 타협은 하지 않는 방법이다
높은 주장, 낮은 협력으로 다음과 같은 상황에서 이러한 강요를 사용할 만 하다
- 인기 없는 정책이지만 꼭 필요한 정책을 집행할 때
- 긴급한 사안을 결정해야 할 때
- 갈등 상대방보다 경쟁우위에 있을 때

이 방법은 자신의 주장을 관철시킬 수는 있지만 부작용이 따를 수 있다 하겠다

5. 문제해결/대면 (Problem Solving/Confrontation)
자신의 주장도 강하게 어필하면서 타협점도 적극적으로 찾는 방법이다
높은 주장, 높은 협력으로 다음과 같은 상황에서 이러한 문제해결을 사용할 만 하다
- 매우 중요한 통합된 의견을 도출하고자 할 때
- 공감대를 형성해 지속적인 관계유지가 필요할 때

이 방법은 시간이 오래 걸리는 단점이 있지만 갈등해결을 위한 가장 효과적인 방법이며 근본적인 갈등해결
방법이라 하겠다

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

---

프로젝트를 수행하기 위한 인적자원을 획득하고 관리하는 것에 대해 알아보자

* 팀 획득
팀 획득이란 말 그대로 팀원을 모집하는 것이다. 아래와 같은 방법으로 팀원을 셋팅하게 된다

1. 사전 배정
프로젝트 수행하기 전에 이미 일부 인원이 사전에 배정된 경우가 있다
예를 들어 경쟁 입찰 과정에서 특정 인원 투입이 약속되어 있는 경우, 프로젝트가 특정 개인의 전문성에 달려 있는
경우, 조직에서 사전에 배치 하기를 원하는 경우 등이다

2. 협상
다른 부서 혹은 다른 프로젝트 팀의 인원을 팀원으로 영입할 수 있다
이럴 경우 각 부서장 및 PM과의 협상을 통해 인원을 공급받도록 한다

3. 획득(조달)
조직 내부에 가용할 수 있는 인력이 없거나 부족한 경우, 외부에서 조달할 수 있다
보통의 직원 채용을 예로 들 수 있겠다

* 가상팀(Virtual Team)
보통의 팀은 같은 사무실에 같은 시간에 상주하며 일을 하게 된다
그러나 경우에 따라서는 원격에서 그것도 서로 다른 시간대에 일을 하게 될수 있다
원격으로 떨어져 전자우편이나 화상회의 등을 통해 프로젝트를 수행하는 팀을 가상팀(Virtual Team)이라 한다

다음과 같은 상황일 경우 가상팀으로 팀을 셋팅하게 된다
- 지역적으로 사람들이 프로젝트를 수행할 때
- 재택근무를 하는 사람들이 프로젝트를 수행할 때
- 근무시간이 다른 사람들이 프로젝트를 수행할 때

이러한 가상팀에서는 중요한 것은 의사소통이다
같은 장소에 같은 시간에 얼굴을 마주보며 일을 하지 않기 때문에 의사소통에 더욱 많은 신경을 써야 한다
또한 팀원들 간의 신뢰가 바탕이 되어야 원할한 프로젝트 수행이 가능하다
그리고 지역적으로 나아가 국가적으로 떨어진 사람들끼리 일을 하기 때문에 각 지역,국가의 문화(culture)를
알고 이해하고 배려하는 것이 필요하다

이러한 가상팀은 출장비 및 시,공에 제약을 받지 않는 장점이 있지만
PM이 팀의 통제가 어렵다는 점과 팀원 사이에 분쟁이 발생할 가능성이 높다는 점, 의사소통이 쉽지 않다는 점이
단점으로 작용할 수 있다

이러한 가상팀과 반대되는 개념이 공동 배치(Co-location) 이다
팀의 업무 수행능력을 향상하기 위해 물리적으로 동일한 장소에 배치하도록 한다
나아가 War room 과 같이 마치 전쟁터에서 중앙 상황실과 같은 개념을 도입해 프로젝트 진행 상황을
보다 적극이지고 직접적으로 팀원들과 공유할 수 도 있다


* 킥 오프 미팅(Kick-off meeting)
프로젝트를 본격적으로 수행하기 전에 하는 일종의 착수 회의이다
킥 오프 미팅은 프로젝트 초반에 수행하는 중요한 팀 형성 활동이며
프로젝트의 목표, 팀원의 역할과 책임을 정의하고 공유하는 자리이다
다만 킥 오프 미팅에서는 예산 및 비용, 계약과 관련된 내용은 토의하지 않는 것이 원칙이다

* 팀원들의 동기 부여
팀원들의 동기를 자극하기 위해서는 포상과 같은 직접적인 방법이 있을 수 있으며
기획과정에 팀원을 참여 시키는 방법 등과 같이 간접적으로 동기부여를 할 수 있다

포상 및 보상
- 반드시 성과에 근거해야 한다
- 분명하고 명확하고 실현가능해야 한다
- 상대 평가, 우수 사원 포상과 같은 개념은 제로섬(zero sum) 혹은 윈-로즈(Win-lose) 보상이라 하며
  팀 결속력을 해칠 가능성이 있으므로 주의해야 한다
- 팀원들이 각기 다른 문화권일 경우 보상 방식에 문화를 고려해야 한다

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

---

우리는 흔히 R&R 이라는 말을 많이 사용한다

R&R의 정확한 의미는 무엇인가?
R&R 은 역할(Role)과 책임(Responsibility)을 줄여 표현한 말이다
말 그대로 어떤 역할과 어떤 책임이 있느냐인데, 아래와 같이 상세히 설명할 수 있다

* R & R
역할(Role): 해당 직원이 담당하고 있는 프로젝트 영역을 설명하는 표지. 프로젝트 성공에 필수적인 요소
책임(Responsibility): 프로젝트 활동을 완료하기 위해 프로젝트 팀원에게 수행하도록 배정되는 작업

프로젝트는 결국 사람이 수행한다고 하였다
프로젝트를 수행하는 개개인의 역할과 책임이 분명해야 프로젝트는 원활히 진행되고 구성원들의 만족도
및 책임의식도 증가할 것이다

이러한 R&R은 인적자원을 기획하고 관리하는데 있어 중요한 지표가 되는데 이와 더불어
권한과 역량도 같이 설명되어야 한다

권한(Authority): 의사결정 및 승인의 권한, 프로젝트를 위해 자원을 이용할 수 있는 권한 등
역량(Competency): 프로젝트 수행을 위한 기량과 능력

이렇게 역할,책임,권한,역량이 명확히 식별되고 잘 관리될 때 각 구성원들이 호흡을 맞추며 프로젝트를 원활히
수행하게 될 것이다

그리고 이러한 R&R 을 시각적으로 표현하기 위해 책임배정매트릭스(RAM, Responsibility Assignment Matrix)가 흔히 사용된다


* RAM (Responsibility Assignment Matrix)

일과 사람을 매핑한 도표이다
WBS(Work Breakdown Specification)는 작업을 분류한 체계이며
OBS(Organization Breakdown Specification)는 조직구성을 분류한 체계이다

이 둘을 합친 형태가 바로 RAM 이라 할 수 있다
WBS + OBS = RAM

RAM은 아래 그림과 같은 형태로 일과 사람을 매핑한 표이다

* RACI 포맷
RAM 에 개개인이 정확히 어떤 역할을 하는지 의미를 부여하는 표기 기법이다
R = Responsibile, A = Accountable, C = Consult, I = Inform
즉 책임, 담당, 자문, 정보 제공으로 그 역할을 명시하도록 한다(아래 그림 참조)

그리고 마지막으로 중요한 한가지...
책임과 권한이 다음의 공식을 만족할 때 각 구성원들의 최고의 업무 효율 및 동기를 끌어 올릴 수 있다

책임 == 권한 (책임과 권한이 일치해야 함)

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

---

프로젝트의 3대 제약사항인 범위,시간,원가가 충족되었을 때 비로써 프로젝트의 품질이 보장된다고 하였다

이러한 제약사항 속에 프로젝트를 원활히 수행하는 것은 다름아닌 사람이다
결국 어떤 사람이 어떤 역할과 책임으로 무엇을 어떤 방식으로 수행할지를 관리하는 것이 바로
인적자원관리(Human Resource Management)이다

그리고 인적자원관리 측면에서 인적 자원이란 범위는 프로젝트를 직접 수행하는 구성원 이외에도
고객, 오너, 스폰서, 외부 관계자, 프로젝트 연관자 등 모든 이해관계자가 포함된다

* 인적자원관리 프로세스
인적자원관리는 다음의 과정으로 이루어 진다
인적자원 기획 -> 프로젝트 팀 획득 -> 프로젝트 팀 개발 -> 프로젝트 팀 관리

1) 인적자원 기획
인적자원과 관련해 제일 처음 수행하게 된다
어떤 사람이 필요할지를 계획하고 이에 대한 인력 조달 계획을 수립하며
프로젝트의 R&R(역할 및 책임)을 정의하고 의사소통 관계 및 보고관계를 식별하는 과정이다

2) 프로젝트 팀 획득
말 그대로 사람을 뽑는 것이다. 프로젝트 수행을 위한 적절한 인적 자원을 효과적으로 획득하도록 한다

3) 프로젝트 팀 개발
사람만 뽑아 놓고 일만 시켜 놓았다고 해서 다 되는 것이 아니다
팀원들의 의지를 고취 시키고 역량을 꾸준히 개발 시킨다

4) 프로젝트 팀 관리
개개인의 성과를 파악하고 개선시킨다
사람대 사람간 발생한 갈등을 파악하고 해소시키며 인력의 변경 사항에 대해 관리하는 과정이다

* 조직 구조
조직이 어떠한 보고체계를 가지고 있으며 어떤 구성으로 조직되어 있는지 PM의 권한은 얼마정도 인지,
의사결정의 핵은 누가 쥐고 있는지 등의 조직의 고유 특성 및 구조가 인적자원에 있어 고려사항, 즉 제약사항이
될 수 있다

PMI에서는 조직구조를 다음과 같이 3가지로 구분하고 있다

1. 기능(Functional) 조직
기능조직은 한국 사회에서 가장 많이 볼 수 있는 조직 구조이다
특히 자체 솔루션을 개발하는 조직에서 가장 많이 보이는 구조인데 각각의 고유한 부서가 이미 존재하며
(이러한 부서를 기능부서라 한다) 프로젝트 수행을 위해 각 부서의 특정 인력이 배정되어 프로젝트가 수행되는
조직구조이다.
이러한 조직 구조에서의 PM의 권한은 아주 미미할 수 있다
즉 각 (기능)부서의 부서장이 이미 존재하기 때문에 PM의 의사결정권이 약하며 팀원들 역시 기능 부서장과
PM에 각각 보고해야 하며 프로젝트 수행을 위한 조직구조보다 기존 기능구조의 인식이 더 강해 기능 부서에
소속감이 더욱 강하다

2. 프로젝트화된(Projectized) 조직
기능 조직과 정 반대되는 개념이다
프로젝트 수행을 위해 똘똘 뭉친(?) 조직이며 이 조직의 목표 자체가 프로젝트 성공이 된다
즉 프로젝트를 위해서 조직이 존재하며 프로젝트를 위한 결속력 역시 강하다
이러한 조직 구조에서는 PM의 권한이 막강하다
팀 목표 자체가 프로젝트 성공이기 때문에 PM의 모든 의사결정권을 가지고 있으며 전사적 지원이 이루어 진다
기능 부서 처럼 각 부서의 이해관계에 얽매일 필요가 없어 프로젝트 수행에 효과적인 특성을 보인다
보통 외주를 받아 프로젝트를 수행하는 SI 조직에서 많이 찾아 볼 수 있는 구조이다

3. 매트릭스(Matrix) 조직
기능조직과 프로젝트조직의 중간정도의 특징을 가지고 있다
이러한 조직 구조에서의 PM의 권한은 역시 중간정도라 할 수 있다
PMI에서는 보다 매트릭스 조직을 보다 세분화 하고 있는데,
약한(Weak) 매트릭스, 균형(Balanced) 매트릭스, 강한(Strong) 매트릭스가 그것이다

약한 매트릭스 조직에서의 PM은 촉진자(expeditor) 역할을 하며 기능조직 부서장의 권한보다 적다고 할 수 있다
균형 매트릭스 조직에서의 PM은 기능조직 부서장과 유사한 권한을 행사할 수 있다
강한 매트릭스 조직에서의 PM은 매트릭즈 조직 상 가장 강한 권한을 가지며 기능조직 부서장보다 우위의
결정권을 가질 수 있는 구조이다

그러나 이러한 매트릭스 조직 구조에서도 대표적인 갈등의 주 요인이 권한 관계라 할 수 있다
완전히 프로젝트화 된 조직이 아니면 각 부서의 이해관계가 얽혀 있으며 이에 따른 관계가 갈등이 될 수 있다
PMI 에서는 이중 보고 및 애매한 권한 관계로 갈등이 발생하게 되면 PM이 해결하라고 권고하고 있다

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

---

일정 개발의 기법 중 CCM(Critical Chain Method)라는 것이 있다

이는 각 활동 사이의 여유시간을 별도로 관리하여 일정을 타이트하게 운영하는 기법이다
이전에 살펴 봤던 CPM(Critical Path Method)을 통한 네트워크 및 일정 산출 방식은 동일하지만,
각 활동 사이의 여유 시간은 별도로 떼 내어서 필요시 여유시간을 적절히 공급하겠다는 원칙이다


다음과 같이 전체 일정안에서 각 활동을 수행하는 기간에 여유시간이 포함되어 있을 경우

여유시간을 각 활동사이에서 제거하여 별도로 모아서 관리하도록 하는 기법이다
이렇게 하여 불필요하게 노는시간(?)을 없애 프로젝트를 보다 타이트하게 운영하고자 하는 기법이다

눈치챘겠지만 이 기법은 관리자들이 만든 가장 최근에 등장한 기법이다
결론적으로 쉴 팀을 주지 않고 빡빡하게 일을 시키겠다로 해석될 수 있는데
이 기법에는 다음과 같은 이론이 뒷 받침 하고 있다

1) 학생 증후군(Student syndrome)
보통 학생들은 시험기간이 코 앞에 다가와야 벼략치기를 해서 최대의 집중을 발휘 한다
이렇듯 일이 닥치기 전에는 느긋함을 피우는 비효율적인 것을 예방하기 위해 CCM 기법이 만들어 졌다
그러나 이는 잘못하다가는 프로젝트를 지연시킬 수 있는 위험도 내포하고 있다

2) 파킨슨 법칙(Parkinson's Law)
모든 작업은 납기일을 준수한다. 역설적으로 말하자면 빨리 끝낼 수 있는 일이라도 납기일이 남았다면
천천히 수행하여 납기일만 맞춘다는 법칙이다

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

---

지금까지 프로젝트 일정을 산출하기 위한 사전 프로세스들에 대해 알아 보았다

활동정의, 활동 순서 부여, 활동 자원 산정, 활동 지속 기간 산정이 그 프로세스 들이다
이러한 사전 프로세스를 거치며 어떤 활동이 필요하며 이를 수행하기 위해 어떤 자원이 언제 필요하며
각 활동들간의 연관관계 및 개발 활동들의 소요 기간을 산정하였다

이제 이를 종합적으로 통합하여 프로젝트를 수행하기 위한 전체 일정을 산출하는 방법에 대해 알아보도록 하자

* CPM (Critical Path Method), 핵심 경로법
개별 활동들을 연결하여 '순방향 분석' 과 '역방향 분석'을 수행하여 각 활동의 시작일과 종료일 그리고 여유시간 및 전체 프로젝트 수행 기간을 산출하는 기법이다

* CP(Critical Path)
CPM에서 CP(Critical Path)는 핵심 주요 구간(경로)로써 각 활동들을 연결했을 때 수행 기간이 가장 긴 경로를 
나타내는데 이 구간은 여유시간이 0 이며 전체 프로젝트 소요 기간을 나타내므로 프로젝트 매니저가 가장
신경을 써야 하는 구간이다

다음의 그림을 보자
아래 표는 각 활동과 활동의 연관관계 그리고 개별 활동의 수행 기간까지 산정된 결과를 나타낸다

각 경로별로 수행기간을 계산 해 보면 다음과 같다
Path 1) start -> A -> C -> F -> end : 8일
Path 2) start -> B -> D -> F -> end : 6일
Path 3) start -> B -> D -> G -> end : 10일
Path 4) start -> B -> E -> G -> end : 13일

총 4가지 경로 중 가장 긴 수행 기간을 가지는 구간은 Path 4 가 된다
즉 Path 4 가 CP(Critical Path)가 되며 이는 곧 프로젝트를 수행하기 위한 총 소요시간이 되는 것이다
물론 프로젝트 매니저가 가장 신경을 써야 하는 구간이된다

참고로 위 표에서는 CP 가 1개 였지만, CP 는 경우에 따라 여러개가 될 수 도 있다
즉 최장기간이 동일한 구간이 여러개가 될 수 있다는 것이다
이렇게 CP가 많아지게 되면 프로젝트의 위험(Risk)이 올라간다

그리고 각 활동들의 수행 기간이 일부 변경되는 경우가 발생한다면 CP도 변경될 수 있으므로 주의깊에
살펴 봐야 한다
예를 들어 활동 D의 수행기간이 기존 2일에서 7일로 변경된다면
Path 3 일정이 총 15일이 되어 CP가 Path4 에서 Path3으로 바뀌게 된다

CP는 프로젝트 일정에 주의를 요하는 구간인 만틈 CP의 변경사항을 잘 파악하여 적절히 상황에 맞도록
프로젝트를 수행하여야 할 것이다


이제 순방향 분석과 역방향 분석을 통해 각 활동의 시작일과 종료일 그리고 여유시간을 산출해 보도록 하자

* 순방향 분석(Forward Scheduling)
Start 시점으로 부터 왼쪽 -> 오른쪽으로 계산하는 방식이다
ES(Early Start date): 빠른 착수라 해석하며 바로 앞 활동을 마친 후 착수 할 수 있는 가장 빠른 시점이다
EF(Early Finish date): 빠른 종료라 해석하며 ES 이후 활동이 완료되는 시점이다 

다음과 같이 활동(Activity)에 대한 기간 및 ES,EF를 표기하도록 한다

아래 그림은 각 활동들을 연결하여 ES 와 EF를 계산한 예시이다

1일 부터 시작하여 각 활동이 소요되는 기간을 더해 나가는 방식이다
활동 B의 경우를 보면, A 활동을 마친 후 빠르게 착수 할 수 있는 시점(ES)은 4일이 되겠다
그리고 4일, 시작 이후 B 활동을 마칠 수 있는 시점(EF)은 7일이 되겠다

이렇듯 '순방향 분석'을 통해 각 활동의 ES, EF를 계산할 수 있는 것이다
참고로 위 표에서 CP는 A->D->E->F->G 이며 프로젝트 총 소요시간은 18일이 된다


* 역방향 분석(Backward Scheduling)
순방향 분석과 반대로, End 시점으로 부터 오른쪽 -> 왼쪽으로 계산하는 방식이다
LF(Late Finish): 늦은 종료라 해석하며 바로 뒤 활동을 제때 시작하기 위해 본 활동이 종료되어야 하는 가장
                      늦은 시점을 말한다
LS(Late Start): 늦은 착수라 해석하며 LF 시점에 활동이 완료되기 위해 시작되어야 하는 시점을 말한다

다음과 같이 활동(Activity)에 대한 기간 및 LF,LS를 표기하도록 한다

아래 그림은 각 활동들을 연결하여 LF와 LS를 계산한 예시이다

End 일인 18일 부터 시작하여 활동이 소요되는 기간을 빼 나가는 방식이다
활동 F의 경우를 보면 G활동을 제때 시작하도록 하기 위해 종료되어야 하는 시점(LF)가 13일이 되겠다
그리고 13일에 활동이 종료되기 위해 이 활동이 시작되어야 하는 시점(LS)은 12일이 되겠다

이렇듯 '역방향 분석'을 통해 각 활동의 LF, LS를 계산할 수 있는 것이다

* 여유 시간
여유 시간은 말 그대로 프로젝트 수행 기간 동안 여유를 부릴 수 있는 시간을 말한다
CP 구간은 여유 시간이 0, 즉 여유가 하나도 없는 구간이라 했다
그러나 CP 구간을 제외한 경로에서는 여유 시간이 나올 수 있다

여유 시간은 다음과 같이 두 가지가 존재한다

1) Total Float (TF)
Slack Time 이라고도 하며, 프로젝트 납기일을 지연시키지 않으면서 각 활동이 가질수 있는 여유시간을 말한다
공식: TF = Min {LS-ES , LF - EF}. 즉 LS-EF 와 LF-EF 값 중 작은 값이 TF가 된다
CP(Critical Path) 구간은 은 TF가 0인 구간이다

TF > 0 경우에는 일정에 여유가 있는 것이며 TF = 0 은 일정 여유가 없는 CP 구간임을 의미한다

2) Free Float (FF)
후행(직후) 활동의 착수일(ES)를 지연시키지 않으면서 선행(직전) 활동이 가잘수 있는 여유시간을 말한다
공식: FF = EF - 직후 ES


TF와 FF는 다음과 같이 표기한다

TF와 FF 의 계산 공식을 도식화 해 보면 다음과 같다

아래 그림은 위에서 계산해 왔던 일정을 토대로 TF와 FF를 계산한 결과이다

지금까지 CPM(핵심경로법)을 통해 프로젝트 전체 일정은 물론이고 각 활동의 시작일/종료일을 산출할 수 있었으며
CP구간을 파악하고 프로젝트 수행 중 여유시간(TF,FF)를 도출하는 방법에 대해 알아 보았다

이렇게 산출된 일정이라 할 지라도, 일정을 단축해야 하는 이슈가 발생할 수 있다
PMI 에서는 프로젝트의 스펙(범위)를 변경하지 않고 프로젝트 일정을 단축하기 위한 방법으로 다음과 같은 기법이
제시된다

* 일정 단축 기법
1) Crashing
크래싱이라 발음하며 자원과 비용을 더 투입하여 일정을 단축시키는 기법이다
Crashing 는 프로젝트 전체 구간 중 CP(Critical Path) 구간에 자원을 먼저 할당하여 프로젝트 전체 일정을 줄이는
기법이다. 단 이 기법은 프로젝트 원가가 상승한다는 단점이 존재한다

2) Fast tracking
순차적으로 진행되는 활동들의 연관관계를 병렬로 작업함으로써 일정을 단축시키는 기법이다
통산 소프트웨어 프로젝트에 많이 사용되는 기법(밤샘?)이며 이는 프로젝트위 리스크가 증가할 수 있으며
재 작업 해야 하는 가능성이 있다는 단점이 있다

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

---

이전 글에서 일정관리를 위한 두 가지 프로세스를 정리 했었다

간략히 요약하자면,
범위관리에서 범위기술서를 분할한 WBS(WBS Package)를 다시 분할하여 활동(Activity)을 정의하고
이렇게 정의된 활동들의 연관관계 및 의존성을 식별하여 Project Schedule Network Diagram을 도출하였다

이 다이어그램의 표기방식으로는 PDM(Precedence Diagramming Method), ADM(Arrow Diagramming Method),
CDM(Conditional Diagramming Method)의 3가지 종류가 있었다. 이 중 많이 사용되는 기법이 PDM이다

이제 이 글에서는 하나의 활동(Activity)를 수행하기 위해 소요되는 기간(일정)을 산출하는 방법에 대해 알아 보자

그에 앞서 어떤 작업을 수행하기 위해 어떤 사람이 몇 명이나 필요할까? 또는 어떤 자원이 투입되어야 하는가?
에 대한 정의를 해야 할 것이다. 이러한 자원에 대해 정의하는 프로세스가 '활동 자원 산정' 이다

활동 자원 산정(Activity Resource Estimating)
각 활동 수행에 필요한 자원의 유형과 양(어떤 자원을 언제, 얼만큼 사용 할 것인지)을 산정한다

이 과정에서는 어떤 자원이 언제 필요하다라고 명시한 '활동 자원 요구사항'을 도출하고 '자원 달력'을 수정,
갱신하게 된다. 자원 달력은 근무일/휴일, 각 일자별 특정 인적/물적 자원의 가용현황을 결정 및 표시하는 수단이다

활동이 정의되고 활동에 필요한 자원이 산정되면 이제 본격적으로 개별 활동에 대한 소요 기간을 산정하게 된다

활동 지속 기간 산정(Activity Duration Estimating)
개별 활동들의 작업기간을 산정한다. 이 과정에서 정량적인 기간 값이 결정된다
기간을 산정, 추정하기 위해 여러 기법이 도입될 수 있는데, 통상 모든 추정의 기법이 되는
전문가 판단, 하향식 추정, 상향식  추정, 유추 추정, 모수 추정 기법이 사용될 수 있다

이러한 추정 기법에 대한 내용은 다음에 차근차근 알아 보도록 하고,
여기서는 일정 관리 분야에서 널리 알려진 PERT에 대해 알아 보자 

* PERT (Program Evaluation Review Technique)
'퍼트'라고 발음한다
3가지 추정치를 이용해 일정을 산정한다고 하여 3점 추정치(Three-point Estimating)라고도 한다
3가지 추정치란 비관치(p),최빈치(m),낙관치(o) 를 말한다

p (Pessimistic) : 비관치, 비관적 추정치, 최악의 일정(일정을 최악으로 길게 잡는다)
m (Most likely) : 최빈치, 가장 가능성이 높은 일정
o (Optimistic)  : 낙관치, 가장 좋은 일정, 가장 짧은 일정

이 세가지 값이 추정되면 다음의 공식으로 Mean(평균) 값과 Sigma(표준편차)를 계산한다
Mean(평균)        = (p + 4m + o) / 6
Sigma(표준편차) = (p - o) / 6

이렇게 계산된 Mean(평균)값으로 활동의 소요기간을 도출할 수 있으며,
이렇게 도출 된 평균과 Sigma(표준편차)를 이용하면 달성 확률을 계산 할 수 있게 된다

Sigma(표준편차)는 평균값으로부터 벗어난 정도를 보여주는데,
다음과 같이 신뢰도를 평가하게 된다. 신뢰도란 정규분포에서 표준편차에 따른 확률값을 말한다
Mean +- 1sigma = 68%
Mean +- 2sigma = 95%
Mean +- 3sigma = 99%


공식만 봐서는 이게 무신 말인고 싶다. 간단한 예를 보도록 하자

문) 어떤 작업의 수행기간을 PERT 기법을 이용해 기간을 산정하고 있다.
이 작업에 대한 3가지 추정치는 다음과 같다
p: 36일
m: 21일
o: 6일
이때 이 작업의 수행기간은?

답) 공식에 대입해 보면,
Mean = (36 + 4*21 + 6) / 6 = 21 , 즉 수행기간은 21일이 되겠다

문) 위 작업이 11일에서 31일 내에 끝마칠 수 있는 확률은 얼마나 되는가?

답) 달성확률을 알기 위해서는 Sigma(표준편차)를 계산해야 한다
Sigma = (36 - 6) / 6 = 5, 표준편차는 5일이 된다

이제 신되로 공식에 의거하여, 평균과 표준편차를 이용해 11일에서 31일 내에 마칠 수 있는 확률을 계산해 보자
Mean : 21일
Sigma: 5일

11일 에서 31일은 Mean += X*sigma 공식에 Mean 값과 Sigma 값을 대입해 보면 
11일 = 21 - X * 5 => X는 2가 된다
31일 = 21 + X * 5 => 역시 X는 2가 된다

결과적으로 Mean +- 2sigma 영역에 있으므로 95% 라는 확률 값을 얻을 수 있다
작업을 즉 11일에서 31일 사이에 달성할 수 있는 확률은 95%가 된다

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

---

프로젝트 수행에 있어 아주 중요한 부분이 시간 즉 일정관리 일 것이다

PMI에서도 프로젝트의 3대 제약사항으로 범위,시간(일정),원가(비용)을 꼽고 있다
이 세가지가 만족했을때 프로젝트 결과물에 대한 품질이 보장된다고 하였다

그럼 지금부터 PMI에서 정의한 시간관리의 프로세스를 살펴보도록 하자

활동(Activity) 정의
프로젝트를 착수할 때 '예비프로젝트 범위 기술서'를 정의해야 한다
이 말은 구체적인 프로젝트 스펙을 처음부터 다 정의할 수는 없지만 무슨 일을 해야 한다는 정도의
추상적인 스펙이 나와야 하는데 이를 정의하는 것이 '예비프로젝트 범위 기술서'라 한다

그리고 난 후, 실질적인 프로젝트 범위에 대한 기획단계에서 스펙을 기획,정의하여 범위기술서를 정의하며
이를 더욱 분할,구체화시킨 것이 WBS명세서이다.
또한 WBS를 다시 한번 세세하게 분할한 것이 WBS Package 라 한다

당연하겠지만, 시간관리 즉 일정을 산출할때 가장 중요한 근간이 되는 것이 바로 프로젝트 범위이기 때문에
범위관리에서 산출된 범위기술서,WBS,WBS Package 가 일정산출에 중요 근간 자료가 된다

범위를 구체적으로 정의하고 세부적으로 분할한 WBS(WBS Package)를 더욱 분할하여 '활동(Activity)'을 정의한다
WBS에서 정의된 각각의 세부 범위를 수행하기 위한 활동을 파악하고 정의하는 것이다

지금까지 이야기한 내용을 그림으로 나타내면 다음과 같다

활동 순서 부여
이렇게 하여 활동이 정의되면, 각 활동들 간의 연관관계를 파악해야 한다
이를 '활동순서부여'라 하는데 정의된 활동들간의 관계를 파악하고 각 활동의 순서를 부여하는 것이다

이때 사용되는 기법이 Project Schedule Network Diagram 인데 이는 다음과 같이 나우어 진다
각 활동을 표현하고 활동들간의 연관관계(의존성)을 표현한 다이어그램 표기 기법이라 할 수 있다

1) PDM(선후행 도형법, Precedence Diagramming Method)
각 활동을 노드(node) 위에 표시하고 화살표로 각 활동의 의존관계를 표현한다
노드에 표현된다고 하여  AON(Activity-on-node)라고도 한다
PDM을 이용하면 각 활동들간의 연관관계를 4가지 형태로 표현할 수 있다
- FS(Finish-to-start)
  말그대로, 앞의 작업이 끝나야 뒤 작업을 시작할 수 있는 개념
- FF(Finish-to-finish)
  앞으 작업을 마쳐야 뒤 작업도 마칠 수 있는 개념
- SF(Start-to-finish)
  앞의 작업을 착수해야 뒤 작업을 마칠 수 있는 개념
- SS(Start-to-start)
  앞의 작업을 착수해야 뒤 작업을 시작 할 수 있는 개념

2) ADM(연결선 도형법, Arrow Diagramming Method)
각 활동을 노드가 아닌 화살표(arrow)위에 표현한다
화살표에 표현된다고 하여 AOA(Activity-on-arrow)라고도 한다
ADM으로는 각 활동들의 연관관계 중 FS(Finish-to-start)만 표현 가능하다
기타 연관관계가 필요하면 Dummy Activity(점선)으로 표현할 수 있다

3) CDM(조건부 도형법,Conditional Diagramming Method)
이는 마치 각 활동의 관계를 프로그래밍 처럼 조건에 의해 순환(loop),분기(if)되는 구조를 표현한다


아래 그림은 소프트웨어 프로젝트에서 Project Schedule Network Diagram를 표현한 예시인데,
PDM으로 표현한 것이다.

중요한 것은 Project Schedule Netowrk Diagram 에서는 활동과 활동들간의 연관관계만 표시하지,
소요되는 시간 및 기간정보는 표현하지 않는다는 점이다.

프로젝트의 일정개발은 각 활동을 수행하기 위해 소요되는 자원(리소스)를 산정하고 개별 활동의 기간을 개개별로
산정하여 일을 통합함으로써 완성된다

경우에 따라서는 각 활동들의 연관관계를 보다 세밀하게 정의하기 위해서 선도 및 지연을 정의할 수 있다

Lead(선도)는 FS(Finish-to-start)관계, 즉 앞의 활동이 완료되어야 뒤의 활동을 시작할 수 있는 관계를
조정하여 앞의 활동이 진행 중일때 뒤의 활동을 시작하여 일정을 단축시키는 개념이다

Lag(지연)은 반대로 FS관계에서 앞의 활동이 끝난 후에 일정기간이 지난 뒤 뒤의 활동을 시작하는 개념이다

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

---

프로젝트 관리에서,
주어진 일정과 오픈 예정일은 아주 민감한 부분이죠.

'인간사'에서도 약속을 잘 지켜야 하듯이,
프로젝트도 약속을 잘 지켜 적시 완료를 보장해야 기본을 한 것 이겠죠 

PMBOK 의 프로젝트 관리 9대 지식영역 중, '6.1 시간관리'에 대해 정리합니다.
내용이 방대하지만 나름 핵심만 정리해 봅니다

6.0 시간관리 

* 프로세스 매핑표

 * 일정기획(계획)은 ‘4.0통합영역’ 기획 프로세스그룹의 ‘4.3 프로젝트관리계획개발’ 프로세스에 선행됨

* 시간관리 도식화