R&D project의 사전준비-2014년 공학프로젝트매니지먼트 수업 발표자료

1. 제2장
연구개발 프로젝트 사전 준비
2012105087 정유희

2. 차례
▪ 서론 – 프로젝트가 실패하는 이유
▪ 2.1 PMI와 ISO 25100
▪ 2.2 PMI 프로젝트 관리 모델의 개요
▪ 2.3 PMI 프로그램 관리 모델의 개요
▪ 2.4 프로그램 생애주기와 단계관문 검토
▪ 계획 & 통제

3. 서론 – 프로젝트가 실패하는 이유
1. 비현실적인 납기 요구
2. 고객과의 의사소통 부족
3. 최고 경영진의 참여와 지원 부족
4. 정확한 데이터에 기반하지 않고 감과 배짱으로 추진
5. 관리 프로세스에 대한 고려의 부재
6. 프로젝트의 성공에 대한 기준이 팀 내에 공유되지 않음
7. 프로젝트 계획을 절대 수정하지 않음
8. 위기 관리 실패
9. 관리자의 경험 부족
CRITICAL!

4. 2.1 PMI와 ISO 25100
▪ PMI: Project Management Institute
http://www.pmikorea.kr/
▪ ISO 25100
▪ 프로젝트관리 지침을 제공하는 국제표준
▪ 프로젝트관리에서 모범사례로 여겨지는 개념과 프로세스에 대하여 설명
▪ 2007년 발의되고, 37개국에서 참여하여 2012년 9월 1일에 발표되었음
▪ 글로벌 프로젝트의 발주사, 이해관계 당사자가 되는 외국 회사들의 요구에
맞추어 프로젝트 관리 표준을 지키는 것이 중요해짐
▪ PMBOK: 프로젝트의 요구사항을 충족시키기 위한 지식, 기술, 도구,기법의 응용을 정의한 표준

5. 2.1 PMI와 ISO 25100
▪ 제1장: ISO 21500 표준의 적용범위로서, 모든 형태의 조직에서 모든 프로젝트에
적용 가능하다는 내용을 규정
▪ 제2장: 16개의 주요 용어에 대한 정의를 기술
▪ 제3장: 프로젝트를 수행하는 동안 적용되는 11개의 중요한 프로젝트관리
▪ 제4장: 프로젝트관리를 위한 5개의 프로세스 그룹과 10개의 주제그룹
▪ 부속서 A: 하나의 특정 프로젝트를 가정하여 개별 프로세스간 상호작용 및 각
프로세스 그룹을 주제그룹에 투영하여 프로세스의 논리적 적용순서를 도표를
사용하여 나타낸 참조

6. 2.2 PMI 프로젝트 관리 모델의 개요
1
• 초기화 프로세스 그룹
2
• 개혁 프로세스 그룹
3
• 수행 프로세스
4
• 감시 및 통제 프로세스 그룹
5
• 종료 프로세스 그룹

7. 2.1 PMI 프로젝트 관리 모델의 개요
초기화 프로세스 그룹 (Initiating Process Group)
▪ 새로운 프로젝트나 단계를 시작하기 위해 공식적인 허가를 받기 위한
프로세스들로 구성
▪ 프로젝트 또는 프로젝트 단계를 시작과 프로젝트 목적과 목표를 식별
▪ 프로젝트 관리자에게 프로젝트를 착수할 권한을 부여

8. 2.2 PMI 프로젝트 관리 모델의 개요
 계획 프로세스 그룹(Planning Process Group)
▪ 프로젝트 관리 계획을 개발하며, 프로젝트 범위와 비용을 식별
▪ 정의하고, 발전시키며, 프로젝트 기간 중에 발생하는 활동들의 일정을
개발

9. 2.2 PMI 프로젝트 관리 모델의 개요
 수행 프로세스 그룹 (Executing Process Group)
▪ 요구사항을 달성하기 위해 관리 계획에 정의된 작업들을 완수를 위한
프로세스들로 구성
▪ 프로젝트 계획에 따른 프로젝트 인도물 제공을 지원하는데 사용

10. 2.2 PMI 프로젝트 관리 모델의 개요
 감시 및 통제 프로세스 그룹 (Monitoring and Controlling
Process Group)
▪ 잠재된 문제를 제때에 식별하기 위해서 프로젝트 성과를 정기적으로
관찰하고 측정
▪ 프로젝트관리계획에서 벗어난 변이를 식별하고, 실행을 통제하고 필
요한 수정 조치를 취하기 위해 수행되는 프로세스들로 구성

11. 2.2 PMI 프로젝트 관리 모델의 개요
 종료 프로세스 그룹 (Closing Process Group)
▪ 프로젝트 또는 프로젝트 단계의 모든 활동들을 공식적으로 종결시키거나,
완료된 제품을 다른 조직에 인계하거나, 취소된 프로젝트를 종료

12. 2.2 프로젝트 관리 모델의 개요
iteration

13. 2.2 프로젝트 관리 모델의 개요
위: 전통적 Waterfall 개발방법론/아래: RAD(Rapid Application Development) 방법론

14. 2.2 프로젝트 관리 모델의 개요

15. CASE #1 국내 대기업 H사의 개발 프로세스 정의
개발프로세스
기안서
6.0 종료5.0 개발4.0 설계3.0 분석2.0 착수1.0 준비
계획서
요구사항
분석 명세
요구사항
도출
요구사항
명세 검토
상위설계
상세설계
시험설계
코딩
시험
형상관리
매뉴얼
준비
종료보고
프로젝트
해제

16. 2.3 프로그램 관리 모델의 개요
프로젝트 프로그램
보다 단순하고 하나의 컴포넌트로 구성됨
결과물(output)을 생성
제한된 시간 내에 이루어지며 유한한 자원을
소모
프로젝트 매니저는 프로젝트에 영향을 주는
특정한 공급자들과 상호작용을 함
더욱 복잡함
변화에 적응할 수 있도록 유연하게 구성됨
상호 협력하고 여러 프로젝트와 활동을 할 수
있도록 구성됨
수익(outcome)을 생성
여러 고객들과 연관되어 있음

17. 2.3 프로그램 관리 모델의 개요
1
• 개시하기
2
• 계획하기
3
• 실행하기
4
• 모니터링 및 통제하기
5
• 종료하기
참고: 프로젝트/프로그램/포트폴리오의 차이

19. 2.4 프로그램 생애주기와 단계관문 검토
1
• 프로그램 전 준비
2
• 프로그램 개시
3
• 프로그램 셋업
4
• 프로그램 효익의 인도
5
• 프로그램 종료

20. 2.4 프로그램 생애주기와 단계관문 검토
▪ Governance
프로젝트 관리 이론에서의 거버넌스는 프로그램/프로젝트 상에서 의사 결정이 일
어날 때 이를 관리하는 프레임워크이다.
조직에서 의사 결정은 다음의 세 가지 요소로 인해 이루어진다. 이를 프로그램/프
로젝트 거버넌스의 세 기둥이라고 부른다.
1. 조직의 구조
2. 조직 내의 사람
3. 의사결정에 영향을 미치는 정보

22. 프로그램 전 준비
▪ 프로그램의 전략적 효익을 이해하기.
▪ 프로그램을 시작할 계획을 개발하기.
▪ 프로그램 목표들을 정의하고 조직의 목적과 정렬하기.
▪ 필요, 비즈니스 효익, 프로그램의 기능성과 합리화에 대해 이해시키기 위한 고수
준의 비즈니스 케이스를 개발하기.
▪ 프로그램이 제대로 수행되는 것을 보장하기 위해서 프로그램 전체를 통한 ‘점검
시점’에 대해서 합의하기.

23. 프로그램 개시
▪ 전략 관리 위원회의 다음 단계(프로그램 셋업)로 진행하라는 승인.
▪ 프로그램 헌장 또는 프로그램 위임장
▪ 비즈니스 변경에 영향을 줄 수 있는 능력을 지닌, 적절한 변경 관리자들의 확인.
▪ 스폰서 그룹 및 프로그램 위원회의 잠재적인 구성원들의 확인.
▪ 프로그램 내의 핵심적 의사결정자/이해관계자, 그리고 그들의 기대와 이해관계의 파악.
▪ 후보 프로젝트들과 기타 잠재적인 프로그램 컴포넌트들의 확인.
▪ 임원 스폰서executive sponcer와 프로그램 관리자의 지정.
▪ 프로그램을 관리하기 위한 인프라 스트럭처의 생성.
▪ 프로그램 셋업에 필요한 핵심적 자원의 확인과 배정.

24. 프로그램 셋업
▪ 프로그램의 미션, 비전, 그리고 가치를 조직의 목표들과 정렬시키기.
▪ 프로그램 셋업을 위한 초기의 상세 비용 및 일정 계획을 개발하고 프로그램 나머지
부분을 위한 계획들의 개요를 작성하기.
▪ 제안된 프로그램에 대해서 기술적 가능성과 함께 — 만약 가능하다면 — 경제적 가능
성 조사를 수행하기.
▪ 제조/구매 결정 및 프로그램을 지원할 하청업자의 선정에 대한 규칙을 정립하기.
▪ 어떻게 프로젝트들이 요구되는 효익을 산출할 능력을 인도할 것인가에 대한 계획을
보여주는 프로그램 아키텍처를 개발하기.
▪ 각 프로젝트에 대해서 연관된 기술, 투자, 그리고 규제/법률적 요소들과 관련된문제들
을 다루는 비즈니스 케이스를 개발하기.
▪ 이해관계자와 의사소통하고 지원을 획득하기.

25. 프로그램 효익 인도 단계
▪ 프로젝트들 모니터링하고 통제할 프로젝트 거버넌스 구조를 확립하기.
▪ 프로그램 목표들을 충족하도록 프로젝트들을 시작시키기.
▪ 컴포넌트들이 요구사항을 충족시키는 것을 보장하기.
▪ 계획을 기준으로 진도를 분석하기.
▪ 프로그램 관리 또는 예상된 효익에 영향을 미칠 수 있는 환경적 변화를 확인하기.
▪ 컴포넌트들 간에 공유되는 자원, 공통의 활동 및 기타 의존성들의 조정을 보장하기.

26. 프로그램 효익 인도 단계
▪ 위험을 확인하고 긍정적 및 부정적인 위험들을 관리하기 위한 적절한 조치들이
취해지는 것을 보장하기.
▪ 이슈들을 확인하고 수정 조치들이 취해지는 것을 보장하기.
▪ 효익 재활용을 측정하기.
▪ 변경 요청을 검토하고 추가적인 작업을 적절하게 인가하기.
▪ 한계치들을 유지하고 결과가 기대대로 인도되지 않을 때 수정 조치들을 시작하기.
▪ 이해관계자들 및 프로그램 거버넌스 위원회와 의사소통하기.

27. 프로그램 종료 단계
▪ 이해관계자들과 효익 현황을 검토하기.
▪ 프로그램 조직과 인프라스트럭처를 해체하고 모든 인적, 물적 자원을 적절히 재배치할 조치를
확보하기.
▪ 인도물이 고객에게 인도되고 받아들여진 후에 이슈나 결함이 발생했을 때 제공될 지도와 보수
유지를 보장하는 고객 지원을 제공하기
▪ 습득된 교훈들을 미래의 유사한 프로그램에 사용할 수 있도록 조직 데이터베이스에 기록하기.
▪ 프로그램 생애주기 내에서 확인되었으나 프로그램 범위 밖에 있는, 조직이 추구해야 할 유용한
변화에 대한 권고 및 피드백을 제공하기.
▪ 재사용 및 미래에 있을지도 모르는 감사를 위해서 프로그램과 관련된 모든 문헌들을 저장하고
인덱스를 붙이기.
▪ 운영을 위해 필요한 모든 전환을 관리하기.

28. 계획
기능
▪ 활동의 조정 : 계획은 조직의 모든 계층의 모든 구성원과 부서에 대
해서 수립되며, 구성원들의 활동을 조정하기 위한 기초 청사진을 제
공한다.
▪ 성과 표준의 제공 : 계획은 미래에 대한 객관적이고 합리적인 예측에
근거하여야 한다. 객관적이고 합리적인 예측은 일반적으로 과거의
실적에 대한 분석으로부터 얻어지며, 과거실적에 대한 객관적인 분
석은 성과 표준에 대한 합리적이고 객관적인 기준을 제공한다.
▪ 통제의 기준 : 계획은 목표를 달성하기 위한 행위들과 성과 표준을
제공함으로써 언제 어떤 통제 활동을 할 것인가에 대한 기준을 제공
한다.

29. 계획
종류
▪ 전략strategy
▪ 운영 계획operational plan
▪ 프로젝트 계획project plan
▪ 방침policy
▪ 절차procedure
▪ 규칙rule
▪ 예산budget

30. 통제
▪ 피드백 통제feedback control : 이미 종결된 활동에 대해서, 해당 활
동이 계획대로 수행되었는가를 확인한 후에, 그 결과를 다음 활동의
수행에 반영한다.
▪ 동시 통제concurrent control : 업무 활동의 진행과 동시에 병행해서
수행된다. 가장 전형적인 예로는, 직접적인 현장 감독이 있다.
▪ 피드포워드 통제feedforward control : 예상되는 문제를 사전에 예
방한다.

31. 통제
▪ 효과적 통제의 특징
▪ 합목적성 : 통제는 충분히 공정하고 경영 계획과 성과를 일치시키고자 하는 목적에 잘 부합하는가?
▪ 정확성 : 통제를 방해하는 부정확한 정보가 존재하는가?
▪ 적시성 : 통제는 적절한 시기에 시행되고 있는가?
▪ 경제성 : 효익의 분석 결과 특정 대상의 통제에 의하여 손해보다 이득이 많은가?
▪ 유연성 : 급변하는 환경 변화에 용이하게 대응할 수 있는가?
▪ 이해 용이성 :불필요한 실수를 방지하고 직원의 참여를 유도할 수 있을 정도로 이해하기 쉬운가?
▪ 합리성 : 이 통제가 직원들의 동기를 부여할 수 있을 만큼 합리적인가?
▪ 전략성 : 모든 것에 대한 통제는 불가능하므로 가장 효율적으로 필요한 것만 통제할 수 있는가?
▪ 예외적 사항에 대한 강조 : 충분한 정도의 자율권이 허용되는가?
▪ 다양한 기준 : 여러 개의 기준을 적용하여 통제해야 한다.
▪ 수정 방법의 제시: 편차를 줄이는 여러 수정 조치 방법이 제시되어 있는가?

32. 통제
절차
▪ 통제 영역 결정 : 통제 대상의 부서, 기능, 자원, 성과 등을 결정한다.
▪ 통제 내용 결정 : 달성해야 할 성과 표준과 통제 기준을 결정하고, 필요한 정보를 결정하고, 성과가
통제 기준을 벗어났을 경우 취할 조치를 결정한다.
▪ 감시 및 정보 수집 : 현재의 성과를 파악하기 위해 현재 상태를 모니터링하고 필요한 정보를 수집
한다.
▪ 통제 기준과 현재의 상태 비교 : 현재의 성과를 표준과 비교하고, 수정 조치가 필요한가를 결정한다.
이 단계는 단계 3의 모니터링과 함께 지속적으로 수행한다.
▪ 수정 조치 실행 : 성과와 표준 간의 편차가 기준치 이상일 경우에는 수정 조치를 실행한다. 필요하
다면 문제점과 그 원인을 분석하고, 필요한 조치를 결정하기 위한 의사결정 과정을 밟을 수 있다.
수행 조치를 실행한 후에는 다시 단계 3으로 돌아간다.
▪ 피드백 : 문제 해결 과정, 수정 조치, 그리고 수정 조치를 시행한 결과 등을 포함한 통제의 전 과정
을 기록하여 관리 체계의 개선과 다음 프로젝트의 통제 계획수립에 참고가 될 수 있게 한다.

33. 프로그램 관리 문서들
▪ 변경 요청 분석
▪ 비즈니스 케이스
▪ 최선의 관행 라이브러리
▪ 프로그램 거버넌스 계획
▪ 프로그램 관리 계획
▪ 프로그램 범위 선언 및 프로그램 범위 관리 계획
▪ 프로그램 위험 관리 계획과 위험 범주
▪ 프로그램 의사소통 관리 계획
▪ 프로그램 이해관계자 등록부 및 이해관계자 인벤
토리
▪ 프로그램 일정
▪ 프로그램 작업 분할구조
▪ 프로그램 조달 관리 계획
▪ 프로그램 최종 보고서
▪ 프로그램 헌장과 프로그램의 승인
▪ 프로그램 효익 실현 계획
▪ 프로그램 효익 실현 보고서 및 효익 실현 분석