인강_요약모음

1. 프로젝트 정의

1) 프로젝트란 전체적인 목적을 향한 일련의 활동들 또는 그 목적의 달성과 관련한 정보 수집, 유일한 제품, 용역 또는 결과를 창출하기 위해 투입되는 일시적 노력을 말한다

2) 운영 업무는 사업 지속을 위한 반복성이 강조되고 지속성을 유지, 관리 하는것이 중요

3) 프로젝트와 운영 업무는 각각 고유한 특성을 가지므로 특성에 맞는 업무처리 필요

 

2.프로젝트 특성

1) 프로젝트는 명확한 목표를 가지고, 한시적이며, 독특하고, 점진적으로 상세화

2) 어떠한 프로젝트든 종료 시간은 정해져 있기 때문에 기간 내 프로젝트를 마무리할 수 있도록 진행

3) 과거의 있던 프로젝트대로 진행 하기보다 새로운 특성과 위험사항을 고려하여 조심스럽게 접근하고 판단

4) 지속적으로 변하는 고객의 요구사항 고려와 준비 필요

 

3.프로젝트 관리의 개념과 필요성

1) 프로젝트란 이해당사자(관계자)를 만족시키기 위하여 다양한 기술, 기법, 지식을 프로젝트에 적용하는 활동

2) 프로젝트 관리자가 프로젝트를 관리 방법론의 체계적인 습득을 통해 실제 프로젝트에 적용함으로써 프로젝트의 성공을 이루기 위해 필요

3) 이해당사자는 프로젝트 수행과 성공여부와 관련하여 긍정적, 부정적 영향을 받는 개인 혹은 조직을 말하며, 이를 만족시킬 수 있느냐 없느냐에 따라 성공이 결정 

 

4.프로젝트 관리 프로세스

 1) 착수(Initiating), 계획(Planning), 실행(Executing), 감시 및 통제(Monitoring & controlling), 종료(Closing)로 구성

 2) 5개의 프로세스는 업종과 관계없이 일정하게 진행

 

5. 착수 - 계획 - 실행 단계

 1) 착수 단계는 '프로젝트 목표 결정, 인도물 결정, 산출물 결정, 제약 문서화, 가정 문서화, 전략 정의, 성과 기준 식별, 자원 요건 결정, 예산 정의, 공식 문서 산출'로 구성 된다.

 2) 계획 단계는 '프로젝트 범위 확인, WBS 작성, 자원 관리 계획 개발, 시간 및 원가 산정치 정련, 통제 계획 검토, 프로세스 계획 개발, 계획 승인 검통'으로 구성

 3) 실행 단계는 '자원 투입, 자원 구현, 진도 관리, 진도 전달, 품질보증절차 구현'으로 구성

 

6. 감시 및 통제 단계 - 종료 단계

 1) 감시 및 통제 단계는 '성과 측정, 통제 제한 범위 정의, 시정 조치 수행, 시정 조치 결과 평가 및 피드백, 계획 적합성 보증, 통제 계획 평가 ,위험 사건 유발 요인 대응, 프로젝트 활동 감시'로 구성

 2) 종료 단계는 '인도물 승인 계획, 교훈 문서화, 종결 촉진,. 제품 기록 및 도구 보관, 자원 해지'로 구성 

 

7. 프로젝트 사례

 1) 프로젝트는 다양한 분야에서 여러가지 형태로 나타난다. 조직혁신 프로젝트, 이벤트 프로젝트, 건설 프로젝트, 교육 프로젝트 등에서 찾아볼 수 있다.

 

8. 프로젝트 실행/성공 가능성 분석

 1) 프로젝트의 실행/성공 가능성은 설계 성공 가능성, 내부적 준비성, 재정적 성공 가능성, 시장에서의 성공 가능성의 네가지 요소로 분석할 수 있다.

 2) 제안 요청서는 사업에 대한 고객의 세부적인 요구사항을 정의하고 제반 제안을 위한 기본틀 제공

 3) 제안서는 사업을 어떻게 수행할 것인지를 포괄적으로 정리하고 고객의 평가를 통해 결정할 수 있는 근거자료를 제시하여 작성한다.

 

9. PM의 결정 

 - 인력, 하드웨어, 소프트웨어 등 자원을 할당받고 운영할 수 있음을 증명해야 함

 - 프로젝트 수행 PM과 자원 운영 권한에 대한 명시가 중요

 

10. PM의 역할

 - 계획작성, 자원요청, 상황보고 역할

 - 책임자, 조정자, 의사소통 채널통합 역할 

 - 의사결정, 관리, 훈련 역할

 - 발주, 계약, 검수 역할

 - 내부부서 지원 및 협력 역할

 

11. PM의 핵심 역량

 - 관리 역량 : 범위, 일정, 원가, 품질, 위험, 구매 관리 역량

 - 기술 역량 : 업종 및 업무 기술 지식

 - 의사소통역량 : 인적자원 관리, 의사소통 리더십

 

12. 프로젝트 매니저의 권위를 증명할 수 있는 문서 : 프로젝트 헌장

 - 프로젝트 헌장 : 경영자 및 스폰서를 대신해서 권한을 위임 받았음을 증명

 

13. 제약 사항

 - 프로젝트 수행자가 결정하지 않고 지켜야 될 사항

 - 제약의 문서화 : 증명 프로젝트의 대표적인 제약은 일정, 원가, 품질 등임

    - 일정, 원가, 품질 등은 문서화 작업을 거쳐야 함

 

14. 프로젝트 헌장

 - 프로젝트에 대한 개략적인 설명과 범위를 정의한 문서

 - 상위 차원에서 프로젝트의 목적과 주요 산출물 및 마일스톤을 명시

 - 팀 구성원과 고객의 프로젝트에 대한 이해도를 높이고, 프로젝트에 대한 합의를 이끌어냄

 - 위험이나 이슈를 조기에 언급하여 프로젝트 성공률을 높임

 - 프로젝트 성공 여부에 대한 측정 기준을 제시

 - 구성요소 : 프로젝트 명, 프로젝트 미션, 프로젝트 목적, 프로젝트 범위, 프로젝트 매니저, 프로젝트 완료일, 고객 인수 기준, 결재

 

15. 프로젝트 착수

 1) 프로젝트 헌장은 프로젝트에 대한 개력적인 설명과 범위를 정의한 문서로 상위관리자에 의해 작성되며 프로젝트 관리자의 임명과 권한 부여와 프로젝트의 목적과 목표를 명시한다.

 2) 프로젝트 착수 프로세스는 프로젝트 목표 결정, 인도물 결정, 프로세스 산출물 결정, 프로세스 제약을 문서화, 프로젝트 가정 문서화, 전략 정의성과 기준 식별, 자원 요건 결정, 예산 정의, 공식적인 문서 산출로 구성

 

16. 범위 기술서 

 - 프로젝트 착수 단계에서 도출된 프로젝트 헌장과 여러 제약 사항 들에 대한 분석을 바탕으로 프로젝트범위에 대한 의사결정과 이해당사자 간의 상호 이해를 위한 문서화된 기준 문서

 - 프로젝트 매니저가 작성

 - 프로젝트 수행 조직과 고객 사이의 프로젝트 범위에 대한 합의의 기준, 프로젝트와 관련된 의사겨정 기준, 프로젝트 종료 여부를 판단하는 기준을 마련하는 것이 그 목적

 

17. 범위기술서의 항목

 - 프로젝트의 성공 기준

 - 우선순위

 - 예산

 - 전반적인 일정

 - 마일스톤

 

18. 인도물과 엑티비티

 - 인도물은 엑티비티의 결과로서 생성

 - 인도물 예 : 리포트, 디자인, 교육시킨 작업자, 소프트웨어 설계서, 도면

 - 엑티비티 예 : 리포트 작성, 디자인 설계, 작업자 교육, 소프트웨어 설계서 작성, 도면 스캔

 

19. WBS(Work Breakdown Structure)

 - 프로젝트의 주요 산출물을 그룹화하여 레벨별로 표시하는 문서

 - 레벨 1: 전반적인 내용을 전개할 수 있는 큰 단위로 분해

 - 레벨 2: 레벨 1보다 더 세부적인 단위

 

20. WBS 작성 절차

 - 범위기술서를 바탕으로 프로젝트의 목적을 인식

 - 프로젝트 목적을 달성하기 위한 기능적 요구사항을 정의

 - 기능적 요구 사항을 달성하기 위한 주요한 액티비티를 정의

 - 관리를 용이하게 하고 액티비티의 누락을 방지하기 위하여 계층적 분할을 실시

 - 액티비티들을 조직화하고 그룹핑

 - 주요 액티비티를 원가와 일정이 산출 가능하고 개인이나 조직에게 할당할 수 있으며 진척도를 관리할 수 있는 수준까지 분할

 

21. WBS사전 

 - WBS 구성요소에 대한 세부사항을 포함하는 문서

 - WBS와 짝을 이루는 문서

 - 각 작업 패키지별로 작업 내용, 자원 요구사항, 일정, 원가, 산출물, 작업 완료 기준, 위험, 인수 기준 등의 정보 관리

 

22. WBS사전 구성요소

 - 워크패킷 ID 정보 : 코드, 워크패킷명, 원가요소

 - 할당 : 수행 조직, 자원할당 대상, 고객 연락처

 - 시간정보 : 착수, 기간, 종료

 - 종속관계 : 종속 WBS 코드

 - 설명(상세) : 제품과 서비스 및 작업

 - 인수기준 : 품질기준, 테스팅 요건, 승인자

 

23. 범위기준선

 - 범위에 대한 업무의 수행 및 평가의 기준 : 프로젝트에서 인정된 변경의 통합이 가능한 계획

 - 범위기술서, WBS, WBS사전

 

24. 범위기준선의 선정

 - 범위기술서, WBS의 작성 -> 이해관계자의 승인 -> 범위기준선 확정

 - 변경 관리에 따라 범위기술서나 WBS변경 시 범위기준선도 변경 

 

25. 범위 계획 

 1) 범위는 프로젝트가 제공해야 하는 제품이나 서비스의 총집합으로 프로젝트 계획 수립 및 통제의 출발점이다.

 2) 프로젝트 계획의 실현 가능성과 구체성은 범위에 따라 좌우되며, 범위 변경은 여타 관리 영역(일정/ 자원/ 비용 등)에 영향을 미친다

 3) 범위 기술서는 프로젝트 범위에 대한 의사결정과 이해당사자간의 상호 이해를 위한 문서화된 기준이며, 작성자는 프로젝트 매니져 이다.

 

26. 일정관리

 1) 일정관리는 프로젝트를 납기내에 완료 할 수 있도록 보증하는 것이다.

 2) 범위 관리는 "무엇"을 정의하기 위한 것이며, 일정관리는 "언제"를 정의 하기 위한 것이다.

 3) 일정관리는 범위관리 및 원과 관리와 밀접하게 통합된다.

 

27.산정 기법

 1) 이전 프로젝트에서의 경험을 바탕으로 공수를 선정한다.

 2) 프로젝트 DB, 방법론을 활용하여 산정한다.

 

28. 주요 공정법

 1) 프로젝트 관리 계획 및 통제 기법으로서, 1956년부터 1958년까지 미국 듀푱사의 건설 계획 추진에 적용된 것

 2) 연관관계 : F-S 관계(Finish - to - Start), S-S관계(Start -to - Start), S-F관계(Start - to Finish), F-F관계(Finish - to - Finish), 지연(Lag), 선행(Lead)

 3) 주요공정을 도출하기 위해서 액티비티 전후 관계 목록을 작성한 후, 네트워크 다이어그램을 작성

 

29. 예산 산정 기법

 - Top Down Estimating : 앞서 수행된 유사한 프로젝트의 실제 비용을 향후 원가 추정의 근거로 사용. 원가 추정에 필요한 정보의 양이 제한적일 때 사용하며, 앞서 수행한 프로젝트가 비슷하거나 추정하는 개인이 전문성을 가지고 있을 때 보다 신뢰할 수 있음. 수행 원가가 적게 들지만 다른 방법에 비해 정확도가 떨어지며 액티비티 원가를 알 수 없음

 - Botton-up Estimating : 개발 작업목록의 비용을 합산하여 프로젝트 총원가를 추정하는 방법. 방법의 정확성은 개별 작업 목록의 규모에 의해 정해짐. 작업 목록의 크기가 작을수록 원가의 정확성은 높아짐

 - Parametric Modeling : 함수 모델에 의해 프로젝트 원가를 추정하는 방법. 정확성은 모델링 도출에 사용하는 데이터가 정확할수록, 모델에서 사용되는 변수가 측정 가능할수록, 규모에 상관없이 Scalable 할 수록 높아짐.

 

30. 프로젝트 원가의 구성

 - 인건비 : 직접인력에게 지출되는 임금형태의 비용

 - 재료비 : 장비 도입이나 자재구입에 소요되는 원가

 - 경비 : 프로젝트 수행을 위해 사용되는 원가 중 인건비와 재료비를 제외한 나머지 금액 

 

31. 원가 기준선 

 - 지금까지의 과정으로 도출한 원가 산정치를 기반으로 형성된 기준선

 - 프로젝트 선과를 측정할 수 있는 주요한 기준이 됨

 - 범위기술서의 예산 제약 조건, 프로젝트 일정과 원가 산정치를 참조해서 설정

 - 프로젝트 결과를 감시하고 통제하는 기준이 되기 때문에 중요하며 다른 일정관리, 품질관리 등과 밀접하게 연결돼 있음

 - 원가기준선은 시간 단계별 프로젝트 예산의 승인된 버전으로 우발사태 예비비는 포함하지만 관리 예비비는 제외

 

32. Overtime의 사용

 - 통산 프로젝트 전체 일정 계산 시 잔업을 포함하지 않음

 - 잔업은 일정과 비용에 영향을 미치므로 관리 및 통제가 필요(주기적 또는 스팟성 잔업 요구사항 발생, 생산성이 낮은 인력에 잔업 발생 등)

 

33. 예비비

 - 예산 초과에 대비하기 위해 계획해 놓은 여유 분의 예산

 - 프로젝트 성격에 따라 10~100% 설정

 - 독립적 성경의 비용 : PM에 의해 통제 가능

 - 예비비의 중요성 : 프로젝트는 불명확한 것을 명확하게 하는 활동이므로 예측할 수 없는 비용의 변동에 적절한 행위를 취하고 비용을 소모하기 위해 반드시 필요

 

34. 예산관리 

 1) 예산 관리는 프로젝트가 승인된 예산 범위 내에서 완료될 수 있도록 보증하기 위한 것이며, 원과 관리는 범위, 일정과 함께 계획 수립의 핵심요소이다.

 2) 범위/일정/원가는 상호 연관되어 있음을 인식하는 것이 중요하다.

   - 일정 ↓ , 범위↓ , 또는 원가 ↑

   - 원가 ↓ , 범위↓ , 또는 일정 ↑

 

35. 예산 산정 및 통제

 1) TOP DOWN estimating이란 Analogous Estimating이라고 하고, Expert judgment의 한 형태이다.

 2) Bottom-up Estimating은 개별 작업 목록의 비용을 합산하여 프로젝트 총원가를 추정하는 것으로, 개별작업 목록의 규모에의해 정확성이 정해진다

 

36. 프로젝트 예산 항목

 1) 예비비 : 예산 초과에 대비하기 위해 계획해 놓은 여유분의 예산

 2) 인건비 : 직접인력(프로젝트에 참여하는 인력)에게 지출되는 임금 형태의 비용

 3) 재료비 : 장비 도입이나 자재 구입에 소요되는 원가

 4) 경비 : 프로젝트 수행을 위해 사용되는 원가 중 인건비와 재료비를 제외한 나머지 금액

 

37. 의사소통계획

 - 필요한 정보의 종류, 제공 대상, 시기 및 제공방법 등과 같이 이해 관계자의 정보 및 의사소통에 대한 필요 사항을 결정 하는 것 

 - Communication Requirements : 이해관계자들의 프로젝트 정보에 대한 요구사항을 문서화 

 - Stakeholder Analysis : 이해관계자별로 정보에 대한 요구를 분석하는 방법

 

38. 원활한 프로젝트 수행을 위한 의사소통 기술 및 방법

 1) Formal Communication

   - 조직의 연결선을 따라 정보가 전달되며 주로 문서로 처리하는 활동

   - 종류 :

    (1) Formal Written : 공식 문서를 발생하는 것(계약서, charter, 프로젝트 헌장 등)

    (2) Formal Verbal : 공식적인 범위 내에서 어떤 발표를 하는 행위(말로 정보를 전달하는 행위)

   - 장점 :

    (1) 문서나 공식기록으로 존재 -> 프로젝트에서 문제 발생 시 확인 가능

    (2) 이해당사자들에게 인지했다는 암묵적 내용

 2) Informal Communication 

  - 조직의 명령 체계와 관계없이 개인의 네트워크를 통해서 이루어지며, 공식적인 의사소통의 경직성을 보완하는 방법

  - 종류 

   (1) Informal Written : 메모, 이메일 등

   (2) Informal Verbal : 회의, 일상적인 대화 등

  - 장점 : 공식적인 의사소통이 갖는 커뮤니케이션의 한계 극복

 3) 근무 장소, 인원 수, 직책 역할 등을 고려하여 상황에 맞는 의사소통 방법을 선택하는 것이 중요

 

39. 이해관계자의 정보 요구사항 충족을 위한 회의 및 의사소통 프로세스 작성

 1) 회의 : 유효한 정보를 공유하여 정보에 대한 상호 이해를 증진시키고 의사결정의 효율성을 높이기 위한 활동

 2) 효율적으로 회의를 이끄는 방법

  - 회의 목적, 개요, 개최시간예고 (필요한 정보를 미리 주고 받아 회의를 진행 ) => 회의 자료 사전 공유 => 자료 숙지 여부에 따른 회의 진행 => 의사결정 위주의 회의 (내용은 사전에 숙지하고 의사결정만 진행)

 3) 바람직하지 않은 회의

  -  HOW에 대한 것만 이야기한다고 답이나오지 않음

  - 회의는 철저한 의사결정 위주로 진행 해야함

  - 회의는 단시간내 진행하며 나머지는 업무 집중 

 

40.이해관계자와의 의사소통 요구사항, 의사소통 기술 및 방법에 따른 의사소통 계획 수립

 1) 의사소통 계획

  - 프로젝트 초기 단계에 정보를 정확하게 식별하여 커뮤니케이션을 할 수 있도록 정의하는 것

 2) 의사소통 수립 시 고려사항

 - 어떤정보가 언제 수집되어야 하는가?

 - 누가 이 정보를 받을 것인가? : PM에게 집중?, 특정 인력이 정보수집 및 처리? 고객에게 직접?

 - 수집된 정보의 취합과 저장에는 어떤 방법을 쓸 것인가? : 여러가지 형태의 다양한 정보를 적절히 저장, 관리

 - 누가 누구에게 보고 할 것 인가? : 모두다 PM에게? 아니면 누가 누구에게?

 - 보고 체계는 어떻게 정의 ? 

 - 정보의 배포 주기는 ? : 

 

41. 의사소통 관리 계획

 1) 의삭소통 관리에서 중요한 것은 이해관계자들의 정보 요구를 식별하는 것

 2) 의사소통 관리는 정보 요구를 식별하고, 해당 정보를 생성 및 제공하여 이를 관리하는 전반적인 과정

 3) 의사소통 프로세스는 의사소통 기획, 정보 배포, 성과 보고, 행정적 종료 등 4단계를 거침

 

42. 의사소통의 종류

 1) 의사소통은 공식적 의사소통(Formal)과 비공식(Informal) 구분

 2) 공식적 의사소통은 복합적 문제해결, 프로젝트 계획, 차터, 주요 계약, 헌장 등

 3) 비공식 의사소통은 회의, 일상적 대화, 메모, 이메일 등

 

43. 효율적인 기법

 1) 효과적인 의사소통을 위해 PM은 의사소통 촉진자로서 의사소통 장애자를 제거

 2) 효과적인 미팅을 도모, 불필요한 회의, 보고 등이 발생하지 않도록 관리

 

44. 프로젝트 품질 목표

 - 품질 목표에는 제품과 관련된 의미와 프로세스와 관련된 의미 존재

 - 제품 관련 품질 목표 : 프로젝트의 납품물이 달성하여야 할 기능이나 성능상의 목표로 이해 가능. 납품물에 따라 산업계에서 표준 규격이나 규제가 있을 수 있음. 또한 경우에 따라서 고객이 신뢰성이나 안정성의 달성 목표를 요구하기도 함

 - 프로세스 관련 품질 목표 : 프로젝트 수행 프로세스와 관련된 표준을 의미. 프로젝트에 적합한 품질 표준을 식별한다는 것은 프로젝트에 적합한 기술, 성능상의 목표와 프로젝트 수행 프로세스를 정의한다는 것

 - 프로젝트에 적합한 수행 프로세스를 정의할 때 고려사항

  1) 프로젝트 수행 환경(기술환경, 팀원 스킬, 납기/원가의 적절성)

  2) 프로젝트에 적합한 수행 프로세느는 프로젝트 성공에 최우선적으로 고려

  3) 모든 상황에 공통으로 적용될 수 있는 수행 프로세스는 존재하지 않음

  4) 고객 요구사항, 회사 방침, 프로젝트 수행 환경 등을 종합적으로 고려하여 최적의 수행 프로세스를 정의

 

45. 품질측정

 1) Peer Review

 - 동료검토, 주기적검토, 설계서를 리뷰하고 리스크 요소 확인

 2) Technical Review

 - 기술적 검토, 기술적 요소 기분으로 전개 -> 기술적 측정 지표를 검토

 3) Customer Survey

 - 고객 설문 방식, 시스템 구축 시 시범운영하여 설문 결과 검토

 4) 품질 검토 회의

 - Peer Review보다 정형화된 형태, 품질 내용 검토를 위한 회의

 

46. 프로젝트 품질 관리를 위해 PM이 파악해야 할 요소

 1) 프로젝트 참여 인력 건강, 안전, 환경 등의 규정

 2) 프로젝트의 요구사항 : 고객 요구사항 반영 여부

 3) 프로젝트의 준수사항 : 일정, 원가, 품질, 범위에대한 기준선이 지켜지는지

 

47. 프로젝트 품질 계획

 - 품질관리 계획 목표 : 합리적인 비용으로 품질 요구사항을 달성하는 것

 - Quality policy(조직의 품질 정책) : 최고경영진이 공포한 품질에 대한 전반적인 의지 및 조직의 방침

 - Benefit / Cost Analysis : 고객의 요구 사항에 적합한 품질을 구현한다고 해도 비용 대비 효율적인 품질관리 활동을 해야함

 - Cost of quality : 제품/서비스의 품질을 확보하는데 필요한 모든 노력의 전체 비용

 - Quality management plan : 프로젝트 관리팀이 품질정책을 어떻게 구현할지 정의

 - Operation definition : 품질 관리 활동을 위한 지침, 개별 활동 지침을 마련해 통일되고 일관성 있는 활동 보장

 

48. 승인된 프로젝트 품질관리 계획의 전사 공유 및 전파

 1) 경인진의 책임 

  - 프로젝트 품질의 목표, 정책, 비전 결정

  - 품질 관련 책임 + 소요 자원 지원

 2) 지속적 개선

  - 프로젝트의 품질 관리 : plan -> do -> check -> act

  - 프로세스 개선 활동 많이 사용 : 프로젝트 품질 유지를 위한 노력이 필요

 

49. 품질의 개요

 1) 프로젝트 초기에 프로젝트의 품질 목표를 정확하게 결정하고 그것들을 어떻게 진행할지를 결정하는 것이 중요

 2) 품질은 고객의 요구 사항 부합, 사용 적합성(Conformance of requirements, Fitness for use)이라는 의미를 갖음

 3) 품질 비용은 품질 목표를 준수하기 위해 사전에 투입되는 예방 비용, 품질 목표에 도달하고 있는지를 측정하는 행위에 들어가는 평가비용, 프로젝트에서 품질 목표 달성에 실패하였을 때 들어가는 실패비용이 있다.

 

50. 품질 관리 계획

 1) 품질 관리 : 프로젝트에서 달성해야 할 목표를 정의하고, 프로젝트 수행 도중 이를 모니터링하여 목표 대비 gap이 발생할 경우 이에대한 적절한 시정 조치를 취하는 활동

 2) 품질 보증 : 프로젝트 품질 표준에 적합하다는 것을 보장하기위해 정기적인 평가 활동

 3) 품질 통제 : 품질 표준 적합 여부 모니터링, 부적합 제거 방법 식별 

 

51. 품질 통제(QC) Tool

 1) Control chart는 어떤 품질의 추이를 측정해서 품질의 내용을 전개하는 방식

 2) Pareto Diagram은 품질상의 문제 원인을 발생 횟수 순으로 그린 히스토그램

 3) Fishbon Diagram은 원인, 결과들을 엮어서 진행하는 다이어그램

 

52. Expectancy Theory

 - 개인별 목표 결정 : 개개인에게 적절한 목표를 결정해야 하며 달성 가능 수준 및 도달 가치 기준에 부합해야 함

 - 달성할 수 없는 목표가 주어질 경우 동기부여가 매우 약해짐

 - 반드시 정확한 내용을 파악하여 달성 가능 가치 범위 이내에서 업무를 지시해야 함

 

53. 효과적인 피드백을 위한 가이드 라인

 - 피드백에 필요한 사항 : 1)팀원들의 목표 달성 및 진행사항 측정, 2)측정 범위 내 전개 가능 여부 확인

 

54. 갈등해결방법

 - 강제 : 의사결정 사항을 상대에게 관철시키는 방법. 힘에의한 결정 및 팀을 이끌고 가는 방식. 굉장히 긴급한 상황이나 프로젝트 진행 시 필수불가결한 요소에 대한 의사결정에만 사용. 그렇지 않을 경우 가장 안좋은 갈등 관리 기법

 - 수용 : 상대 의견을 수용해 신뢰를 구축하는 경우. 단, 무조건 수용이아닌 상황에 맞게

 - 연기 : 결정을 나중으로 미루거나 회피. 사소하거나 진정시킬필요가 있을경우

 - 타협 : 양쪽의 의견을 절충하여 중간점의 결론을 내는 것. 대안을 협상의 테이블로 끌고 와 해결. 서로 뭔가를 희생해서 답을 찾는 LOSE 방법

 - 문제해결 : 양측 모두 납득할 해결책을 찾아 통합된 결정을 얻을 때 사용. 결과가 굉장히 오래 지속되는 장점이 있지만 양쪽 모두를 설득해 해결책을 찾는데 시간이 너무 오래걸리는 단점 

 

55. 프로젝트 팀 관리계획

 - 저마다 다양한 개성을 지는 팀원들에 대한 역량과 책임을 철저하게 고려한 계획부터 출발하여 이들을 적임에 배치

 - 부족하거나 필요한 역량을 채울 수 있도록 교육의 기회를 제공

 - 올바른 동기부여를 통해 팀원들이 처음에 예상하고 계획했던 소기의 성과를 달성할수 있도록 함

 - 팀원들 간의 서로에 대한 신뢰를 바탕으로 결속함으로써 상호간 협력할 수 있는 프로젝트의 수행환경을 조성

 - 발생한 여러 갈등들을 효과적으로 통제할 수 있는 인적자원에 대한 통합 관리

 

56. 팀원 관리 계획서

 - RACI 차트 활용 : 업무 프로세스 상 누가 어떤 수준으로 일해야 할지를 정리한 표. 목표를 달성하기 위해 필요한 과제를 나열하고 이를 효과적으로 수행하기 위한 개인별 R&R을 정리한 것. 실무담당자, 의사결정자, 조언자, 업무 수행결과를 통보받는 사람 등 4가지 역할로 구분

 - 혹은 테스트 포맷의 책임과 역활문서를 통하여 내용을 정의한 문서도 활용 가능 

 

57. Manage Project Team

 - 프로젝트 팀 관리 프로세스는 프로젝트 성과를 향상시키기 위해 팀원들의 성과를 토대로 이슈사항을 해결하고 변경사항을 관리하며 피드백을 제공하는 프로세스

 

58. 변경 요청 분류

 - 프로젝트 변경 시 범위, WBS상의 태스크와 일정, 예산의 변경에 대한 관련된 조직과 개인에게 통보하여 예상되는 영향을 명확하게 시켜야 함

 - 범위 : 범위 변경은 영향 받는 모든 조직과 논의된 후 SOW나 WBS의 개정 후 공표, 분배

 - WBS상의 태스크와 일정 : WBS는 변경을 반영하여 업데이트 되어져야 한다. 또한, 일정상의 변경은 모든 조직에게 통보되어야 한다.

 - 예산 : 예산상의 변경은 경영층과 재무 관리자에게 통보되어져야 한다

 

59. 문서화와 적용

 - 평가되고 분류된 변경 요청 사항들을 문서화하고 실제 프로젝트 계획에 통합하여 적용

 - 변경요청서(문서)에는 다음과 같은 요소를 작성 : 프로젝트명, 프로젝트ID, 프로젝트 매니저, 변경 제목, 일시, 변경 요청자, 변경 요청일, 담당 부서, 변경 이유, 변경 내용에 대한 상세 설명,변경 시 효과, 기각 시 영향, 평가 일정, 평가 범위, 품질 등 

 

60.프로젝트 팀 관리

 - 훌륭한 팀은 처음부터 만들어지는 것이 아니라, PM의 팀원 구성 및 관리능력에 달려있다.

 - PM은 팀원들과 밀접하게 일하면서 그들의 개인적 업무적 요구 사항을 파악하여 적절한 대응을 해야 할 필요가 있다

 - 이에 대한 PM의 적극적/열정적 배려는 프로젝트 팀의 사기를 향상시키며 프로젝트 진척을 방해하는 인력 자원적 요소에 대한 이슈를 해결할 수 있다.

 - 팀 성과 이슈 관리란 팀원들의 업무 성과 내용을 분석하여 개인 및 팀 단위의 성과를 관리하는 것을 말한다

 - 팀원들이 프로젝트의 목적이라는 괘도에서 벗어나지 않도록 건설적인 Feedback의 지속적인 제공은 프로젝트 성공의 주요한 요소이다.

 

61. 아웃소싱 판단 기준

 - 기업이나 프로젝트 조직이 해당 업무에 대한 기술적 노하우, 예산, 인력이 부족한 경우

 

62. 조달범위, 조달형태 및 계약방식 등을 포함한 조달전략 수립

 1) 고가가격 조달 전략

  - 내용 검토 등의 사전 준비가 가장 많이 필요한 계약

  - 제품의 범위나 규모가 명확한 경우에만 가능

  - 계약 전 상당한 시간이 소요됨

  - 업무 범위가 명확하지 않으면 발주 불가, 수주자에게도 위험이 증가하기 때문

  - 발주자 중심의 조달 전략

 

 2) 실비 정산 계약

  - 계약된 이후에 관리해야하는 계약

  - 프로젝트를 수행하는데 실제소요되는 비용을 지불하는 방식

  - 수주자의 리스크가 있는 고정 가격 계약 방식과달리 수주자의 리스크가 없음. 그러나 추가 비용 정산의 상황 발생으로 인한 발주자 리스크 발생

 

 3) 단가 계약 조달 전략

  - 내용이 명확할 때 하는 계약

  - 약정된 단가에서 대가를 지급하는 방식

  - 원가 변동에 대한 위험성이 존재하며, 원가 및 특정 예산 수량 변동 시 어떻게 처리할 것인가가 가장 큰 관건

 

63.조달전략에 따른 조달절차 수립 및 이해관계자의 역량 정립을 포함한 조달 프로세스 수립

 - 조달계획수립 => 공급자유치계획수립 => 공급자유치 => 구매자선정 => 계약관리 => 계약 종결 및 사후관리 

 

64. 조달전략 및 조달 프로세스에 따라 사양 및 요구사항 반영한 조달계획 수립

 1) 적합한 업체 선정

  - 사전조사와 정확한 선정 기준으로 업체 선정

 2) 수행 가능한 업무량 분장

  - 외주 업체가 수행 가능한 업무 배분

  - 과도한 업무 배정 시 문제발생

  - 사전에 업체의 역량을 파악하는게 중요

 3) 철저한 의사소통라인 구축

 4) 철저한 모니터링 및 관리 실시

 

65. 외주업체 선정

 - 외주는 계약관점, 소프트웨어 획득 방법, 개발생명주기에 의해 분류

 

66. 외주 계약

1) 고정 가격 계약 : 규정된 제품(공사/서비스)에 대한 대가가 확정된 계약으로 사전에 잘 정의된 제품에 대해 고정 가격을 정하여 계약

 2) 실비 정산 계약 : 실제 발생한 비용을 업자에게 지불

 3) 단가 계약 : 약정된 단가에서 대가를 지급

 

67. 프로젝트 관리 계획서에 정의된 성과 목표를 달성하기 위한 프로젝트 진도 추적 

 - 고객의 요구사항 -> (베이스라인) 산출품 범위 결정 -> 일정수립 -> 품질의 기준 설정

   * 베이스라인은 서로 직접적인 연관관계로 이루어짐

   * 상황 확인 및 관리 가능한 추진력 노하우 필요, 관련 데이터 통한 진척 상황 수치화를 통해 프로젝트 진도 추적 필요

 

68. 계획 대비 실적 차이를 만드는 요인 

 - 산정의 정확도 : 프로젝트의 일정과 원가에 대한 견적 작성에 대한 정확도

 - 가용 자원의 변동 : 초기 산정 이외의 투입 가능한 인력 및 장비 지원

 - 시장 상황 : 초기 산정 시 고려해야 할 물가, 환율, 유가 등의 요소

 - 잔업의 사용 : 초기 산정 이외의 추가 작업

 - 가격의 일시적 변동 : 인건비, 경비 등의 일시적인 가격 변동 

 *계획대비 실적 차이를 만드는 요인에 대한 전반적인 검토를 수행하고, 이를 기반으로 변경요청서 작성

 

69. 프로젝트의 일정, 원가 비교의 한계

 1) 프로젝트의 규모가 클수록 관리가 어려우므로, 수치화 및 가시화 방법 필요

 2) 프로젝트의 일정과 원가는 비교할 수 없는 별도의 기준임

 

70. 프로젝트의 일정, 원가 비교의 대안 : 기성고

 1) 프로젝트의 수치화 가시화를 위한 이론적 베이스로, 일정과 원가를 통합하여 관리하는 것을 의미

 2) 프로젝트 수치화 및 전개를 통한 프로젝트 상황 파악 및 조치 가능

 3) 정확한 단위 설정을 통한 프로젝트의 진척도 확인을 위한 기준치 제공

 

71. 기성고 측정법

 1) 1/100 : 시작 시 0, 종료 시 100으로 측정(업무 진행중에는 0이며, 업무가 종료되어야 100이 됨)

 2) 50/50 : 시작 시 50, 종료 시 100으로 측정(업무 시작과 동시에 50이며, 업무가 종료되면 100)

 3) 단위 종료 : 동일한 단위에 대해 같은 가중치를 할당하여 측정( ex -1day 10, 2day 20 ...10 day 100)

 4) 마일스톤 : 마일스톤에 따라 가중치 부여 및 EV 할당 가중치(특정 날짜를 정하고 가중치를 부여)

 5) 퍼센트 : 주관적으로 몇 퍼센트에 끝났는지 정의

 

72. 일정 및 원가 성과 지연의 원인 

 - 수행 인력의 업무 이해력 부족

 - 기대치 만큼 수행 역량 부족

 - 교육 미실시

 - 프로젝트 환경 변화

 - 적합한 자원 할당 실패

 - 비현실적 기대 방법

 

73. 일정 및 원가 성과 지연에 따른 변경 요청 

 - Crashing : 자원의 추가 투입으로 인하 일정 단축 -> Critical Path 엑티비티에 투입

   *일정 지연 => 인력 투입 => 일정 단축

 - Fast Tracking : 작업의 전후 관계를 병행 처리

   *문제 발생 => 업무 할당 조정 => 일정 단축

 

74. 진척 관리 시 프로젝트 PM의 할

 1)납기와 예산 내에 프로젝트를 완료하기 위해서 프로젝트 진척 상황과 예산 지출에 대한 추적관리가 필요

 2) PM은 현재 프로젝트 환경에서 어떠한 문제들이 발생하고 있으며, 이를 해결하기 위해서 어떠한 조치를 취해야 하는지를 계획

 

75. 진척 관리를 확인할 수 있는 요인

 1) 산정의 정확도, 자원 가용성의 변동, 인플레이션 등의 시장 상황, overtime의 사용, 가격의 일시적 변동 등의 요인으로 인해 계획대비 실적 차이가 발생

 2) 예산 초과에 대비하기 위해 여유분의 예산 예비비 계획

 3) 프로젝트 계획과 편차를 파악하기 위하여 원가 실적을 모니터링하는 비용 통제가 필요 

 

76.프로젝트 위험 식별 확인 사항

 - 누가 식별할 것인가?, 언제 식별할 것이가?, 어떻게 식별할 것인가?

 - 위험관리의 식별은 모든 이해당사자가 참여

 - 위험은 다양한 형태로 발생, 직급과 직무에 따라 서로 다른 위험을 발견할 수 있음

 

77. 프로젝트 위험 관리

 - 프로젝트에 긍정적 혹은 부정적 영향을 미치는 위험 요인을 식별 및 분석해 대응 방안을 수립하기 위한 체계적 프로세스를 수행하는 것

 - 긍정적인 기회의 발생 가능성과 파급효과는 극대화하고 부정적인 위험사건의 영향력을 최소화 하는 것이 목적

 - 불확실성이 있는 곳에 위험이 존재하므로 불확실성의 정도를 이해해서 문제에 대응할 수 있는 방법을 제공하는 것이 위험 관리의 목적

 

78. 위험 관리 계획서

 - 프로젝트에서 수행할 위험관리의 접근 방법과 역할 등 정의

 - 위험에 대한 평가와 통제로 구분: 프로젝트의 성격, 진행단계, 활용 가능한 정보에 따라 달라질 수 있다는 것을 유의

 - 위험관리 계획서의 세부요소

  *방법론 : 위험관리를 어떻게 수행할 것인지에 대한 방법을 정의한 요소. 주요도구나 기법, 자료의 출처 등을 정의

  *역할과 책임 : 위험관리에 포함된 프로세스나 활동들을 수행할 담당자의 지정과 구성원을 정의

  *책정 예산 : 위험관리를 수행하기 위해 필요 자원과 예산을 기록

  *일정 : 전체 프로젝트의 수행주기에서 어느 시기에 어떠한 위험관리 활동을 수행할 것인지를 계획

  *위험범주

 

79. 리스크 대응 계획 수립

 - 위험을 부정적 위험과 긍정적 위험으로 분류하여 개별적 대응 계획 수립

 

80. 리스크 대응 방법

 - 회피 : 위험요소 피함, 최소화하여 돌아가는 방식. 계획 및 기획 단계에서 위험요소를 식별하고 회피 가능한 방법을 찾는 것이 중요

 - 전달 : 위험을 다른 쪽으로 전개, 처음부터 오지 않은 위험을 피하는 회피와 달리, 전달은 이미 온 위험을 다른쪽으로 넘기는 것

 - 축소 : 위험요소를 측정하여 최소화, 최소화된 위험요소로 진행

 - 수용 : 프로젝트관리의 특이한 방식, 위험요소를 인지하는 대로 놔두는 방식

 

81. 위험 관리 프로세스

 1) 위험관리 계획 : 위험의 식별, 정성/정량적 분석, 대응 계획 수립, 모니터링과 통제를 어떻게 수행할 것인가를 구체적 정의

 2) 위험 식별에는 프로젝트와 관련한 Stakeholder가 참여하여 식별하며, 프로젝트 팀뿐만 아니라 고객과 필요할 경우 해당업무 혹은 기술 분야의 전문가도 참여하는 것이 바람직

 

82. 위험 식별, 분석, 대응 계획 

 1) 위험 관리는 프로젝트 시작에서부터 끝날 때까지 수행하여야 하며, 계획 수립 단계의 위험 식별이 가장 중요

 2) 위험에 대한 대응 계획을 수립한다는 것은 위험의 발생가능성을 줄이는 방안과 위험이 발생하였을 때의 영향력을 줄이는 방안을 생각 할 수 있다.

 3) 위험 대응 계획 수립은 무엇을, 누가, 언제, 어떻게 한다는 구체적인 계획을 포함하여 프로젝트의 상황, 위험 노출도, 비용 대비 효과 등을 고려하여 위험 대응 계획을 수립

 

83.변경통제위원회

 - 변경이 발생하여 통합 변경 통제가 시행되면 변경이 발생되었는지 식별하고 변경통제위원회를 통하여 변경요청을 검토 및 승인하며, 승인된 변경만 계획 및 실행에 반영되도록 해야 함. 또한 그에 따른 성과평가 기준선의 정합성을 유지하는 프로세스

 

84. 변경사항 수용여부 결정

 - 업무범위 변경과 관련된 변경요청사항은 업무범위 변경이 범위 외의 추가 여부를 먼저 확인하고 납기, 원가, 품질 등에 미치는 영향력을 분석한 후 인수 책임자와 프로젝트 관리자 간에 합의를 한 뒤  수용여부를 결정

 - 변경 규모나 심각성에 따라 수용여부를 결정하는 변경통제위원회의 구성원이 달라질 수 있음

 1)  변경 대상

  - 기타 단계별 산출물의 내용 변경 : PM, 관련 PL, QAO, 필요시 개발자, 현업담당자

  - 계약서, 프로젝트 계획서 내 업무범위 변경 : PM, 관련 PL, QAO, 고객 관련 부서장

 2) 변경 규모

  - 5MD 미만의 변경 : PM, 관련 PL, QAO, 필요시 개발자, 현업 담당자

  - 5MD 이상의 변경 : PM, 관련 PL, QAO, 인수 책임자, 고객 관련 부서장

 

85. 변경관리의 단계

 - 변경 필요성 인식과 평가

 - 범위, 일정, 예산에 미치는 영향 평가

 - 관련 조직과 개인에게 변경 통보

 - 문서화와 적용

 - 범위, 일정, 예산에 대한 재산정

 

86. 변경 통제

 - 반드시 절차에 의해 진행

 - 관련 조직과 개인에 통보

  *범위 : 직무권한범위(SOW), 표준작업분류체계(WBS)의 적용 및 문서화, 표준작업분류체계(WBS)의 과업과 재연결

  *예산 : 재무관리자와 내용 검토 및 재연결

 - 수정해야 할 주요 문서 : 프로젝트 계획서, 범위 기술서, WBS, 일정표, 예산 지출 계획서 -> 업데이트 필요

  

87. 변경 관리의 이해

 - 통합 변경 통제 : 변경이 발생하였는지 식별, 변경 요청을 검토 및 승인하며 승인된 변경만 계획 및 실행에 반영하도록 하고 그에 따른 성과평가 기준선의 정합성을 유지하는 프로세스

    * 변경 요소를 식별, 통합적으로 진행, 성과기준선의 정합성을 유지, 전반적인 핵심 요소의 통합적 관리가 중요

 - 범위 통제 : 범위 변경에 최소화되도록 범위 변경 요인에 영향을 미치고, 변경 발생시 영향력을 통제

 - 일정 통제 : 일정 변경을 식별, 변경이 최소화되도록 하며 발생된 변경의 영향을 관리

 - 원가 통제 : 원가 변경의 최소화를 위해 영향력 행사, 원가 초과시 강용예산을 넘지 않도록 하고 원가 생산성을 확인해 향후 원가 상황을 예측, 해당 이해당사자에게 통보

 

88. 변경 관리에서 PM의 고려사항

 - 변경 관리에 대해 항상 중요하게 생각하고, 처리 절차가 명확히 정의되어야 하며 예산이 확보 되어야함

 - 변경의 영향을 반영하기 위하여 프로젝트 설계서 변경

 - 어떤 변경, 어떻게 처리할 것인지, 누가 다룰 것인지 기록

 - 전체 변경 통제 프로세스의 부분으로서, 변경 요청은 PM에게 문서화되어 상신

 

89. 변경 관리 프로세스

 1) 변경 필요성 인식과 평가

 2) 범위, 일정, 예산에 미치는 영향 평가

 3) 관련 조직과 개인에 대한 통보

 4) 문서화와 적용

 5) 범위, 일정, 예산에 대한 재산정

 

90. 프로젝트의 종료의 단계

 1) 프로젝트 최종 리뷰 실시

 2) 프로젝트 리포트(산출물 문서, 성과 문서 등)을 정리 및 제출

 3) 대금 처리

 4) 프로젝트에 할당된 자원 릴리즈

 5) 프로젝트 파일들의 수입과 저장을 통해 향후 프로젝트 이용

 

91. 인수 회의 및 최종 리뷰 회의

 1) 프로젝트 인수 회의는 프로젝트가 달성한 인수 기준의 검증 고객으로부터 인수 승인을 획득한다는 목적을 갖음

 2) 프로젝트 인수 회의는 PMBOK의 Scope Management의 Scope Verification(범위검증)의 단계에 해당

 3) 해당 프로젝트의 경험을 공유하고 향후에 활용

 4) 성공적인 부분을 Best Practice화 하여 반복 적용

 5) "성공적'이라는 판단도 등급을 나누어 차등화하여 적용

 6) 향후 사용 가능한 데이터들의 제시

 7) 변경이 필요한 프로세스 인식

 

92. 프로젝트의 Lesson Learned

 1) "Lesson Learned" : 프로젝트에서 발생한 변경과 그 원인 및 결과를 기록한 문서

 2) 프로젝트 과정에서 얻게되는 교훈들은 해당 프로젝트뿐 아니라 수행 조직의 다른 프로젝트를 위한 자료로써 문서화

 

93. 프로세스의 종료는 범위검증, 계약종료, 프로젝트 종료의 3가지 프로세스로 구성

 1) 범위검증 : 이해 당사자로부터 완료된 프로젝트 인도물의 공식적 인수를 승인 받는 프로세스

   - inspection : 인도물이 기준을 만족해 인수가 가능한지 판별하기 위한 검토, 검사, 워크스루, 측정 등 포함

 2) 계약 종료 : 계약에 의한 행위들이 종료 됐는지를 확인하는 프로세스

   - 계약에 의해 진행된 것들에 대한 종료 행위, 계약에 대한 것들의 처리 및 진행절차

 3) 프로젝트 종료 : 프로젝트를 공식적으로 종료하기 위해서 프로젝트 관리 프로세스 그룹에서 모든 활동을 마무리하는 프로세스

 

94. 프로젝트 종료의 다양한 형태

 1) 소멸로 인한 종료

   - 정상적으로 모두 완료, 고객에게 인도 후 종료, 프로젝트 조직의 후속처리에 대한 부담, 조직팀이 해산되고 조직이 해체

 2) 포함을 동반한 종료

   - 새로운 조직으로 생성되며 오퍼레이션 담당, 프로젝트 조직이 후속 처리에 대한 부담이 적음, 신설되는 조직으로 인도가능

 3) 통합을 동반한 종료

   - 회사 내부에서 진행, 품질관리 프로세스는 회사의 새로운 절차로 채택, 기존 조직으로 환원되는 것이 일반적

 

95. 이 외 비정상적으로 프로젝트가 종료될 경우

 - Lesson Learned에 실패 요소에 관한 부분을 상세히 정리해야하며, 이 때 실패 요소를 어떻게 정리하여 전달하느냐가 중요

 - 중복된 실패를 피하기 위해 후송 프로젝트에서의 실패 요소를 최소화하기 위한 전달 방법 모색

 

96. Lesson Learned

 - 다음 프로젝트를 위한 가이드라인

 - 회사의 지적 자산

 - 베이스라인 설정 및 성과 측정 기준

 - 프로젝트의 경험을 문서화 및 지식화하여 공유

 - 교훈을 자산 삼아 경험과 지식 축적

 - 기업의 유형 및 무형 자산으로 만드는 활동

 

97. Lesson Learned의 내용

 - 성공, 실패 요소, 경험, 지식, 계획 대비 실적차

 

98. Lesson Learned이 공식 업무여야 하는 이유

 - 프로젝트의 지식과 교훈은 전 단계에 걸쳐서 수집되어야 하므로, 단계별 종결 시마다 정리하여 지식화할 필요가 있음

 

99. Change Request 발생 상황

 - 외부 환경이나 정책 변화

 - 제품, 업무 범위 정의 시 누락, 오정의

 - 개선이나 부가가치 증대를 위한 변경

 - 위험에 대한 대응으로 비상 계획의 가동

 

100. Change Request 요소

 - 각 요소가 프로젝트에 미치는 영향

 - Change Request의 진행 절차

 - Change Request의 처리 절차

 - 변경 발생 시 변경 처리 결정 여부

 - 변경 처리 시 영향력 검토

 

101. Change Request 조치

 - 변경 시 미치는 영향력을 고려하여 철저하게 진행

 - 범위, 일정, 품질 간 연결된 베이스라인의 처리 및 관리가 중요

 - 생산성 유지 방법, 생산성 범위 내 베이스라인 통제 방법 등을 고려하여 진행하는 것이 PM의 역할임